🛡️ OpenADSafety#

Note

🚧 This section is currently under construction.

The goal of OpenADS is to provide a complete toolchain and reference implementation that can become the basis for a commercialized, safety-certified level 4 automated driving system. This involves technical, process-related, and regulatory requirements regarding system safety and security as specified, for example, as outlined by UNECE/TRANS/WP.29/2026/139.

OpenADS itself is not a certified product out of the box. Instead, it aims to provide reusable modules, reproducible development environments, traceable interfaces, simulation scenarios, and automated validation pipelines that can contribute evidence to a later approval and certification process.

Safety Architecture#

Click the diagram to enlarge. Links inside the diagram stay clickable.

Note

This figure is derived from UNECE/TRANS/WP.29/2026/139. It is modified and extended.

Cross Topics#

Many relevant norms, standards and literature have been published to build a viable safety case. These do not necessarily fit into one builing block, so that they are described as cross topics. Following, a few relevant elements are outlined. However, this should by no means be considered a complete list.

Functional Safety (FuSa)

❓ Did we build the functions right?

To achieve a safety-certified automated driving stack, functional safety according to ISO 26262-3:2018-12 (Road vehicles - Functional safety - Part 3: Concept phase) is required. For OpenADS, this means not only implementing algorithms correctly, but also defining clear system boundaries, assumptions, interfaces, failure reactions, and verification evidence for safety-relevant behavior.

Typical functional-safety work products around an OpenADS-based stack include:

Item definition and system context, including sensors, actuators, middleware, compute platform, and external interfaces.
Safety goals derived from hazardous events and mapped to relevant system functions.
Functional and technical safety requirements for perception, localization, planning, control, and supporting infrastructure.
Safety mechanisms such as plausibility checks, timeout supervision, degraded operation, and safe-state handling.
Verification evidence from reviews, tests, simulation, static analysis, and integration campaigns.

Hazard and Risk Analysis (HARA)

A Hazard and Risk Analysis identifies potentially hazardous events caused by malfunctioning behavior and evaluates their risk based on severity, exposure, and controllability. In automated driving, HARA is usually performed at vehicle or item level and then refined into subsystem requirements.

For OpenADS, a HARA should typically answer questions such as:

Which vehicle functions are in scope, and under which operational situations are they allowed to operate?
What happens if a module provides stale, missing, inconsistent, or physically implausible output?
Which hazards can arise from invalid perception objects, wrong localization, infeasible trajectories, or missing actuation commands?
What is the expected fallback behavior if communication, computation, or map data are unavailable?

Examples of malfunctioning behavior in an OpenADS-based stack could include missed detection of a relevant obstacle, an invalid route through a non-drivable area, or a trajectory that violates vehicle-dynamics constraints. The HARA output should lead to explicit safety goals and to a documented safe state or fallback strategy.

Automotive Safety Integrity Levels (ASIL)

The HARA results determine the required Automotive Safety Integrity Level, ranging from QM for non-safety-related quality management up to ASIL D for the highest integrity requirements. ASIL classification affects the required rigor for architecture, development, verification, tool qualification, and independence of confirmation measures.

For OpenADS, an important implication is that not every module necessarily carries the same ASIL. Some functions may remain QM, while others require stronger safety mechanisms and more stringent verification. Modularization helps isolate responsibilities, but it does not replace safety engineering. ASIL decomposition, interface assumptions, and freedom-from-interference arguments still need to be justified explicitly.

Examples of measures that may support ASIL-oriented architectures include:

Redundant or diverse information channels for safety-critical inputs.
Runtime monitors for heartbeat, latency, range, and plausibility checks.
Deterministic fallback behavior if a module violates timing or consistency assumptions.
Traceable requirements and bidirectional links between requirements, code, tests, and evidence.