Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| en:safeav:ctrl:vctrl [2026/06/02 23:06] – momala | en:safeav:ctrl:vctrl [2026/06/02 23:42] (current) – momala | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== Validation View ===== | + | ====== Validation View ====== |
| Planning and control must be validated as a system function, not only as isolated algorithms. A planner may produce a technically correct trajectory, and a controller may track a reference path accurately, but the combined behavior can still be unsafe if perception is delayed, localization drifts, prediction is wrong, or the actuation path introduces latency. The validation view therefore focuses on the complete decision–execution loop and asks whether the autonomous vehicle behaves safely, predictably, | Planning and control must be validated as a system function, not only as isolated algorithms. A planner may produce a technically correct trajectory, and a controller may track a reference path accurately, but the combined behavior can still be unsafe if perception is delayed, localization drifts, prediction is wrong, or the actuation path introduces latency. The validation view therefore focuses on the complete decision–execution loop and asks whether the autonomous vehicle behaves safely, predictably, | ||
| Line 7: | Line 7: | ||
| <!-- Figure comment: Validation view from component verification to system and operational validation --> | <!-- Figure comment: Validation view from component verification to system and operational validation --> | ||
| - | ==== Validation Levels ==== | + | ===== Validation Levels |
| The validation process can be understood as a progression from local correctness to system-level safety. This progression is especially important in the planning and control layer, because the behavior of the system depends on tightly coupled interactions between the decision layer, the planner, the controller, the vehicle model, and the environment. | The validation process can be understood as a progression from local correctness to system-level safety. This progression is especially important in the planning and control layer, because the behavior of the system depends on tightly coupled interactions between the decision layer, the planner, the controller, the vehicle model, and the environment. | ||
| Line 21: | Line 21: | ||
| In the V-model perspective used throughout the handbook, planning and control occupy the portion where implementation evidence must be mapped back to the system requirements. The chapter does not need to repeat the general V-model explanation here. It is enough to show that planning and control are evaluated at several points along that validation chain: first as modules, then as integrated functions, and finally as part of the complete autonomous vehicle. | In the V-model perspective used throughout the handbook, planning and control occupy the portion where implementation evidence must be mapped back to the system requirements. The chapter does not need to repeat the general V-model explanation here. It is enough to show that planning and control are evaluated at several points along that validation chain: first as modules, then as integrated functions, and finally as part of the complete autonomous vehicle. | ||
| - | ==== What Must Be Validated ==== | + | ===== What Must Be Validated |
| The validation question is not simply “does the algorithm work?” It is “does the vehicle behave safely and correctly when the algorithm is embedded in the full autonomy stack?” That means the evaluation must cover the following aspects together: | The validation question is not simply “does the algorithm work?” It is “does the vehicle behave safely and correctly when the algorithm is embedded in the full autonomy stack?” That means the evaluation must cover the following aspects together: | ||
| Line 36: | Line 36: | ||
| Planning and control are sensitive to the assumptions behind the system. A small change in localization accuracy, actuation delay, road friction, or prediction uncertainty may produce a very different trajectory outcome. For this reason, validation should not be framed as a single pass/fail test on one nominal case. It should be framed as a collection of evidence showing that the system remains acceptable across the planned range of operating conditions. | Planning and control are sensitive to the assumptions behind the system. A small change in localization accuracy, actuation delay, road friction, or prediction uncertainty may produce a very different trajectory outcome. For this reason, validation should not be framed as a single pass/fail test on one nominal case. It should be framed as a collection of evidence showing that the system remains acceptable across the planned range of operating conditions. | ||
| - | ==== Validation Logic ==== | + | ===== Validation Logic ===== |
| The planning and control layer is best validated through a chain of evidence. First, the team defines a maneuver or mission objective. Then the system assumptions and operating constraints are specified. Next, scenarios are generated to exercise the maneuver under controlled variation. After that, simulation, closed-loop execution, and physical confirmation are used to check the system response. Finally, the results are expressed in measurable metrics and tied back to the safety argument. | The planning and control layer is best validated through a chain of evidence. First, the team defines a maneuver or mission objective. Then the system assumptions and operating constraints are specified. Next, scenarios are generated to exercise the maneuver under controlled variation. After that, simulation, closed-loop execution, and physical confirmation are used to check the system response. Finally, the results are expressed in measurable metrics and tied back to the safety argument. | ||
| Line 48: | Line 48: | ||
| This is why scenario execution, digital twin fidelity, and timing realism matter. If the virtual environment is too abstract, the test may not reveal the same failure modes that appear in the real vehicle. If the virtual environment is too expensive or too detailed, the test program may not scale to a useful number of scenarios. Validation therefore needs a balance between breadth and realism. | This is why scenario execution, digital twin fidelity, and timing realism matter. If the virtual environment is too abstract, the test may not reveal the same failure modes that appear in the real vehicle. If the virtual environment is too expensive or too detailed, the test program may not scale to a useful number of scenarios. Validation therefore needs a balance between breadth and realism. | ||
| - | ==== Evidence Types ==== | + | ===== Evidence Types ===== |
| For this chapter, the most useful evidence types are trajectory evidence, timing evidence, and safety evidence. | For this chapter, the most useful evidence types are trajectory evidence, timing evidence, and safety evidence. | ||
| Line 61: | Line 61: | ||
| These evidence types should be collected together, not separately. A vehicle that tracks a path accurately but violates safety margins is not acceptable. A vehicle that avoids collision but behaves erratically or unpredictably is also not acceptable. The validation view therefore requires a combined reading of the metrics rather than a single score. | These evidence types should be collected together, not separately. A vehicle that tracks a path accurately but violates safety margins is not acceptable. A vehicle that avoids collision but behaves erratically or unpredictably is also not acceptable. The validation view therefore requires a combined reading of the metrics rather than a single score. | ||
| - | ==== Why This View Matters ==== | + | ===== Why This View Matters |
| The planning and control layer is the point where autonomous behavior becomes visible in the physical world. A mistake here is not only a software error; it is an action error. That is why this subsection must be treated as a bridge between the planning algorithms described earlier and the scenario-based test methodology that follows. It prepares the reader to ask the right questions: what should be tested, at what level, under which conditions, and with what evidence. | The planning and control layer is the point where autonomous behavior becomes visible in the physical world. A mistake here is not only a software error; it is an action error. That is why this subsection must be treated as a bridge between the planning algorithms described earlier and the scenario-based test methodology that follows. It prepares the reader to ask the right questions: what should be tested, at what level, under which conditions, and with what evidence. | ||
