Is a scenario the same as a scene?

No. A scene is a snapshot; a scenario concerns development over time.

Does concrete always mean every trajectory is predetermined?

Not necessarily. The framework and level of specification determine what is fixed and what execution resolves.

Does OpenSCENARIO define all pass criteria?

A scenario representation does not replace the complete evaluation design.

AI Glossary / Reinforcement learning and robotics / Intermediate

Scenario (vehicular automation)

Definition

In vehicular automation, a scenario describes how a traffic setting and its participants evolve over time, including relevant actions, events, and environmental conditions. It can support system design, simulation, and testing. A scenario is more than a single snapshot: it captures a temporal development. Its level of detail can range from an informal description to a parameterized family or a particular executable instance.

What it means

A statement such as a vehicle approaches a slower vehicle describes the essential story, but leaves many details unspecified. Speeds, separation, road geometry, weather, and participant behavior can make different instances of that story very different tests.
A scene generally describes a snapshot of the environment and participants at a time. A scenario describes development across time. A test case adds matters such as the system under test, execution conditions, and evaluation criteria. These distinctions help teams avoid assuming that a scenario description alone defines what counts as a successful result.

How it works

Begin with the behavior or operating condition to examine. Describe the road setting, relevant actors, initial conditions, actions, and events. Decide which aspects are fixed and which may vary.
A functional scenario can express the idea in ordinary language. A logical description defines parameters, ranges, or constraints. A concrete instance specifies particular values or behavior sufficiently for the intended execution. Terminology and the exact boundary between levels vary across frameworks, so document the convention being used.
Select instances that serve the test objective, including meaningful boundary conditions and interactions. Use a supported representation, such as an appropriate ASAM OpenSCENARIO format, when exchanging scenario descriptions between tools. Record tool versions, models, and settings because a common description does not eliminate differences between execution environments.
Define evaluation criteria separately and examine whether the scenario was actually executed as intended. A failed setup, unrealistic actor behavior, or an invalid parameter combination can undermine a result. Scenario testing provides evidence about the tested conditions; it does not establish complete coverage of all possible driving situations.

Three practical examples

A development team tests how an automated vehicle responds when a slower vehicle enters its lane under several specified gaps and speeds.
A perception team varies lighting and occlusion within a scenario family to study where detection performance changes.
A validation team reproduces a recorded traffic interaction in simulation and documents the assumptions introduced during reconstruction.

Think of it this way

Think of a scenario as a short traffic script. A scene is one frame from that script, while a test case also states what is being evaluated and how the outcome will be judged. Different actors, timing, and conditions can turn the same basic script into very different tests.

Worked example

Consider an invented logical scenario in which one vehicle follows another on a straight road. The following vehicle's initial speed can be 15, 20, or 25 meters per second. The initial bumper-to-bumper gap can be 20 or 40 meters, and the chosen road condition can be dry or wet.
A full combination of these discrete choices contains 3 × 2 × 2 = 12 parameter combinations. This counts only the listed values; it does not cover every intermediate speed, gap, road condition, or possible behavior.
For one concrete instance, let the following vehicle travel at 20 meters per second, the leading vehicle at 15 meters per second, and the initial gap be 40 meters. If both maintain constant speed on the same path, the closing speed is 20 − 15 = 5 meters per second. The simplified time to close the gap is 40 / 5 = 8 seconds.
After three seconds under those assumptions, the gap is 40 − 5 × 3 = 25 meters. These calculations help check scenario initialization and progression. They are not a safe-following recommendation: braking, reaction, friction, vehicle dimensions beyond the defined gap, and changes in behavior are not modeled. A pass criterion must be specified separately.

Illustrative case study

In this fictional case, Pine Mobility creates a scenario family for approaching slower traffic. An early dashboard reports twelve successful runs, but reviewers discover that several runs used the same default gap because a parameter was not passed correctly.
The team adds checks on the executed initial conditions and records the realized trajectories. It also separates successful scenario execution from successful vehicle behavior. A run can be technically valid while revealing an undesirable system response.
The final report states exactly which combinations were exercised, which assumptions were used, and what the results support. It avoids presenting the scenario count as a percentage of all real-world driving covered.

Common misconceptions and mistakes

A scenario is not merely a map, a single image, or a list of parameter values without temporal meaning. Nor is a scenario file automatically a complete test specification.
Another mistake is counting generated cases as evidence of useful coverage. Many cases can be redundant, invalid, or unrepresentative. Parameter combinations also need constraints so that physically or logically inconsistent instances are not mistaken for meaningful tests.
Passing every selected scenario does not prove universal safety. Interpretation depends on selection, model fidelity, execution validity, and the evaluation criteria.

Business use

Scenario descriptions help organizations communicate test intent, reproduce cases, and compare system changes. They can organize evidence across simulation and other testing methods when assumptions are traceable.
Maintain links between scenarios, requirements, results, and known limitations. Review whether the chosen variations exercise important behaviors rather than merely increasing run counts. Distinguish simulated evidence from evidence collected with physical vehicles in relevant conditions.

Check your understanding

How many listed combinations are in the example?

Answer: Twelve.

What is the simplified closing time for the concrete instance?

Answer: Eight seconds if both speeds remain constant.

Why does twelve successful executions not establish complete coverage?

Answer: Only a small set of specified conditions and assumptions has been exercised.

Related terms

scene
situation
functional scenario
logical scenario
concrete scenario
ASAM OpenSCENARIO
test case
operational design domain

Learn next

Learn next how scenario abstraction levels support test generation. Study constraints, execution validation, and coverage arguments before interpreting a collection of scenario results as broad evidence about vehicle behavior.

Sources

ASAM OpenSCENARIO DSL, Scenario Abstraction: https://openscenario.asam.net/ASAM_OpenSCENARIO_DSL/current_dsl_v2.x/conceptual-overview/scenario-abstraction.html ASAM OpenSCENARIO 2.0, Key Terminology: https://openscenario.asam.net/ASAM_OpenSCENARIO_DSL/v2.0.0/conceptual-overview/key_terms.html Ulbrich and colleagues, Defining and Substantiating the Terms Scene, Situation, and Scenario for Automated Driving: https://citeseerx.ist.psu.edu/document?doi=082fa126e0fec5ffb240b3fc634c3cd6d4edb7ed&repid=rep1&type=pdf

Previous: Scatterplot smoothing Next: Scene text