Safety engineering for autonomous vehicles now converges on one practical discipline: autonomous driving scenario-based testing. The aim is simple to state and difficult to execute — identify, generate, and validate the scenarios that are both representative of real driving and sufficiently adversarial to stress the system. ISO 34502:2022, published in November 2022, provides guidance for a scenario-based safety evaluation framework for automated driving systems on limited access highways.
On the data and tooling side, ASAM OpenSCENARIO 2.0.0, released July 20, 2022, and subsequent updates have pushed the industry toward more expressive, reusable scenario definitions. The strategic advantage is not simulation volume for its own sake but traceability. A scenario library that links real-world events, synthetic variations, and pass/fail criteria becomes the backbone for regression testing, especially when software updates are frequent and the safety case must remain valid across versions.
A credible testing program typically follows a staged pipeline, and the most mature teams treat it as a closed-loop system rather than a linear milestone. First, define the ODD precisely and prove containment: geography, roadway class, speed range, weather, lighting, and behavior at ODD boundaries. Second, build a scenario catalog from multiple sources: naturalistic driving data, crash typologies, disengagement narratives, and expert-designed adversarial cases.
Third, execute at scale in simulation and X-in-the-loop: software-in-the-loop, hardware-in-the-loop, and sensor-in-the-loop where sensor physics and timing matter. Fourth, validate on closed courses and proving grounds: controlled repeats, corner-case choreography, and independent verification of safety-critical behaviors. Fifth, operate on public roads with safety gates: progressive rollout, monitoring, post-incident learning, and strict release criteria for model and map updates.
The key is that every stage must produce evidence that can be reused. A safety case is not a PDF — it is an evidence pipeline. That pipeline becomes even more important because autonomy is increasingly software-defined. UNECE R156 forces developers to treat software updates as a regulated lifecycle, not a feature pipeline. This matters for the toughest safety debates in 2026: whether a given system's safety claim still holds after an over-the-air update.
The industry has learned, sometimes the hard way, that the hardest failures are rarely single-point sensor faults. They are cross-domain failures where perception, planning, human factors, and cybersecurity interact in a way that no single team owns. ISO/SAE 21434 pushes that ownership problem into engineering processes by requiring structured cybersecurity risk management across concept, development, production, operations, maintenance, and decommissioning.
Operational safety doesn't end at the vehicle. One of the most consequential evolutions is the teleoperation safety net autonomous vehicles increasingly rely on — often called remote assistance or teleassist, and sometimes more controversially remote driving. The distinction matters. Remote assistance typically means providing guidance: routing around a blocked lane, confirming a safe path, or authorizing a conservative maneuver without continuous joystick control.
Remote driving implies direct vehicle control over a network, and with it comes latency risk, packet loss, authentication requirements, and a very different safety argument. Regulators and first responders are pushing for clearer interfaces and accountability: in practice, a safe teleoperation design needs explicit operating envelopes, formal handoff protocols, strong identity and access management, and a fail-safe minimum-risk maneuver if the link degrades.
