Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| en:safeav:ctrl:sim [2026/06/02 23:09] – momala | en:safeav:ctrl:sim [2026/06/02 23:45] (current) – momala | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== Scenario Design ===== | + | ====== Scenario Design |
| 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. | 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. | ||
| Line 7: | Line 7: | ||
| <!-- Figure comment: scenario funnel from functional scenario to logical scenario to concrete test cases --> | <!-- Figure comment: scenario funnel from functional scenario to logical scenario to concrete test cases --> | ||
| - | ==== Scenario abstraction levels ==== | + | ===== Scenario abstraction levels |
| A useful way to organize validation is to distinguish three levels of scenario abstraction. | A useful way to organize validation is to distinguish three levels of scenario abstraction. | ||
| Line 20: | Line 20: | ||
| 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. | 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. | ||
| - | ==== What a scenario must describe ==== | + | ===== What a scenario must describe |
| A good scenario is more than a scene description. It should define the elements that matter to the validation question. | A good scenario is more than a scene description. It should define the elements that matter to the validation question. | ||
| Line 37: | Line 37: | ||
| For planning and control, the most important scenario variables often include vehicle speed, initial separation, relative speed, road curvature, lane availability, | For planning and control, the most important scenario variables often include vehicle speed, initial separation, relative speed, road curvature, lane availability, | ||
| - | ==== From scenarios to validation cases ==== | + | ===== From scenarios to validation cases ===== |
| 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. | 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. | ||
| Line 55: | Line 55: | ||
| 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. | 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. | ||
| - | ==== Scenario families for planning and control ==== | + | ===== Scenario families for planning and control |
| Different validation questions require different scenario families. The table below gives a practical organization. | Different validation questions require different scenario families. The table below gives a practical organization. | ||
| Line 69: | Line 69: | ||
| 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. | 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. | ||
| - | ==== Scenario outputs and labels ==== | + | ===== Scenario outputs and labels |
| 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. | 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. | ||
| Line 83: | Line 83: | ||
| These labels are useful because they tie the scenario directly to system behavior. They help distinguish between a planner that is merely inefficient, | These labels are useful because they tie the scenario directly to system behavior. They help distinguish between a planner that is merely inefficient, | ||
| - | ==== Why this matters for the rest of the chapter ==== | + | ===== Why this matters for the rest of the chapter |
| Scenario design is the foundation for the later validation methods. Simulation, software-in-the-loop, | Scenario design is the foundation for the later validation methods. Simulation, software-in-the-loop, | ||
