Operational Scenarios using the PEGASUS format - Part 2
- Sahil Subodh Bane
- Jul 14
- 3 min read
In the previous blog post, we looked at the different layers of an operating scenario. In this blog post, we will look at the different abstraction levels, and why it matters for ISO 26262 HARA and SOTIF HARA.
The Three Abstraction Levels of Operating Scenarios
Each operating scenario can be described in 6 layers as described in the the previous blog post. In addition, each operating scenario can be described in 3 different abstraction levels.
Functional scenarios - They are natural-language descriptions on a semantic level, written for people to read and reason about. The vocabulary is specific to the use case. Ours would read simply: "A vehicle in the adjacent lane cuts in ahead of the ego vehicle on the highway."
Logical scenarios - These scenarios turn a functional description into a parameter space. Each influential factor becomes a parameter with a range, optionally carrying a probability distribution, expressed in a formal notation. In the example in the previous blog post, this is described as driving on low mu, and following a vehicle in front, which is traveling at 40m/s and a distance of 40m in front.
Concrete scenarios - These scenarios pick one specific representative from that parameter space, with every value fixed. Cut-in gap 12 m, ego speed 120 km/h, merging vehicle 8 km/h slower. A concrete scenario is directly executable, whether in simulation or on a test track.
The three form a pipeline: a functional scenario is formalised into a logical one, which is instantiated into any number of concrete ones. Each step down trades human readability for machine executability. A functional scenario is easy to discuss and impossible to run; a concrete scenario is easy to run and says nothing on its own about coverage.
Putting the Two Axes Together
Because the two axes (6-layer operating scenario description and 3 layer abstraction) are independent, a complete scenario specification always names a position on each. You describe what is in the scene using the six layers, and how tightly it is specified using the abstraction level. A logical scenario still has all six layers; it just expresses their contents as ranges rather than fixed values.
It is worth knowing that the model has evolved since PEGASUS. ASAM OpenSCENARIO 2.0 and ISO 34501 introduce a fourth level, the abstract scenario, slotted between functional and logical to capture relationships and constraints in a formal but still unparameterized way. The three-level pipeline remains the conceptual core, but the newer standards give teams an extra rung.
Why This Matters for HARA and SOTIF
Operating scenarios are not an academic exercise. They are the raw material of the situation analysis step in an ISO 26262 HARA , and the foundation of the coverage argument in SOTIF. When a HARA asks "what can go wrong, and when," the "when" is a scenario. When SOTIF asks whether a system's residual risk is acceptable, the evidence is performance measured across a scenario space.
A structured format is what makes scenario coverage a measurable quantity rather than an anecdote. Logical scenarios in particular let a team argue that they have covered a defined parameter space, not just the handful of concrete cases someone happened to think of. That argument is only possible if the scenarios were described in a common, layered, parameterized way in the first place.
Conclusion
PEGASUS did not make the driving world less complex. It made that complexity describable. The six layers tell you what to look at, from the road surface up to the digital messages in the air. The abstraction levels tell you how far to zoom, from a sentence anyone can discuss down to a single executable test case.
Together they turn the impossible-sounding instruction "test against reality" into something an engineering program can actually structure, measure, and defend. That is what a good scenario format buys you, and it is why the PEGASUS vocabulary has outlived the project that created it.