Scenario design is the point where planning and control validation becomes concrete. A control or planning function cannot be evaluated only through abstract claims such as “the planner is safe” or “the controller is robust.” It must be tested in situations that represent the intended operational design domain, with parameters that can be varied systematically and outcomes that can be measured consistently. For this reason, scenario design is the bridge between system requirements and executable validation cases.

The purpose of this subsection is to show how a validation idea becomes a testable scenario. The basic progression is simple: a use case is described in natural language, that description is turned into a structured logical scenario, and then the logical scenario is instantiated into concrete test cases. This structure allows the same planning or control function to be tested across many variations of speed, distance, road geometry, actor behavior, visibility, and vehicle state.

<!– Figure comment: scenario funnel from functional scenario to logical scenario to concrete test cases –>

A useful way to organize validation is to distinguish three levels of scenario abstraction.

The functional scenario is the most accessible starting point. It tells the reader what type of driving situation is being examined, but it does not yet define a test. The logical scenario turns that situation into a parameterized family of cases. This is where validation becomes systematic, because the same scenario can be repeated with different values for speed, distance, weather, road shape, and other variables. The concrete scenario is the final executable instance. It is the single run that appears in simulation, on a test track, or in a monitored field trial.

This three-step structure is especially useful for planning and control because these functions are highly sensitive to context. A lane change that is safe at low speed and with a large gap may become unsafe when the lead vehicle is faster, when the adjacent lane contains a moving actor, or when the controller reacts too late. Scenario abstraction therefore helps the engineer separate the behavior that should remain stable from the factors that are deliberately varied.

A good scenario is more than a scene description. It should define the elements that matter to the validation question.

These elements define the test context and prevent ambiguity. If a scenario does not explicitly specify the initial state, the actor behavior, or the environmental constraints, then it is difficult to reproduce the test or interpret the result. The goal is not to overspecify every detail, but to identify the variables that change the planning and control response.

For planning and control, the most important scenario variables often include vehicle speed, initial separation, relative speed, road curvature, lane availability, traffic density, and timing delay. Those are the factors that tend to change whether a maneuver is safe, whether a controller can track the trajectory, and whether the system can recover when conditions become difficult.

Once the scenario family is defined, the next step is to select concrete cases that stress the planning or control logic in meaningful ways. This is where design of experiments becomes useful. Rather than testing one nominal case repeatedly, the engineer deliberately varies the scenario parameters so that the same maneuver is evaluated under different conditions. This reveals which factors have the strongest effect on safety and performance.

For example, a lane-change scenario can be parameterized by:

1. ego speed,
2. lead vehicle speed,
3. gap to the target lane,
4. presence of a faster vehicle in the adjacent lane,
5. lateral offset,
6. road curvature,
7. localization error,
8. controller delay.

By varying these parameters systematically, the validation team can identify boundary conditions. Some cases may be clearly safe, some clearly unsafe, and some close to the operational limit. The purpose of scenario design is to expose those limits early, before the system is accepted as safe for deployment.

This is also where scenario-based validation becomes more useful than mileage alone. Distance driven tells us how much the vehicle has moved. Scenario coverage tells us what kinds of situations the vehicle has actually faced. For planning and control, the second is much more informative than the first.

Different validation questions require different scenario families. The table below gives a practical organization.

Each family should be translated into a logical scenario description and then into a set of concrete test cases. The same maneuver can be repeated across different speeds, actor behaviors, road geometries, and environmental conditions, which makes it possible to compare outcomes and identify trends rather than isolated events.

A scenario is only useful if its output can be interpreted consistently. For planning and control, the result should be expressed through clear labels and quantitative metrics.

These labels are useful because they tie the scenario directly to system behavior. They help distinguish between a planner that is merely inefficient, a controller that is merely slow, and a system that is actually unsafe. The purpose of scenario design is not only to generate runs, but to make the runs interpretable.

Scenario design is the foundation for the later validation methods. Simulation, software-in-the-loop, hardware-in-the-loop, formal falsification, test-track execution, and field trials all depend on having scenarios that are well-defined and reproducible. If the scenario itself is vague, then the test evidence becomes weak, even if the simulator or test track is highly realistic.

For that reason, this subsection should be read as the preparatory stage for the test-method section that follows. It defines what should be tested, how the test family should be structured, and which parameters should be varied. The next subsection can then explain how those scenarios are executed through simulation, formal methods, and physical testing.