Training teaches the driving model. Validation asks whether it works safely enough. That requires far more than counting road miles.
What gets validated?
Developers test perception, prediction, planning, control, sensor performance, fallback behaviour, operational limits, cybersecurity interactions and the complete vehicle response. The exact methods depend on whether the system is modular, end-to-end or hybrid.
Common validation methods
- Road testing: real traffic, weather and human behaviour.
- Log replay: rerun recorded sensor data through a new software version.
- Closed-loop simulation: the virtual world reacts to the system’s steering, braking and acceleration decisions.
- Scenario variation: change lighting, weather, traffic participants or road geometry.
- Software-/hardware-/vehicle-in-the-loop: test progressively more of the production stack.
- Regression testing: verify that a software improvement does not break previously safe behaviour.
Why “long-tail” scenarios matter
Rare events — unusual roadworks, emergency vehicles, strange pedestrian behaviour or uncommon combinations of weather and traffic — may be too infrequent to collect safely at scale on public roads. Simulation and synthetic data help developers expose the system to more of these cases.
Why end-to-end AI changes validation
With a large learned driving model, behaviour can emerge from the interaction of many learned parameters rather than from a short hand-written rule. This increases the importance of repeatable closed-loop testing, model introspection, scenario coverage and evidence that performance remains stable across software changes.
Validation vs safety case
Validation produces evidence. A safety case organizes that evidence into a structured argument explaining why the automated driving system is acceptably safe for its intended use.