Two Standards, Two Categories of Risk in Automotive Safety

ISO 26262 and ISO 21448 SOTIF govern two distinct — and equally important — categories of safety risk in automotive electrical and electronic systems. ISO 26262 addresses risks caused by malfunctions: hardware failures, software faults, and systematic errors in the system’s components. ISO 21448 addresses risks that arise even when every component is functioning correctly, because the system’s intended functionality is itself insufficient to handle all real-world scenarios safely.

The distinction matters enormously in practice. A lidar sensor that stops functioning due to an electronic fault falls under ISO 26262 — it is a malfunction. The same lidar sensor that fails to detect a pedestrian in heavy rain because its detection algorithm was not designed for that condition falls under ISO 21448 — the sensor is working, but its intended functionality is insufficient. Autonomous driving systems face both categories of risk simultaneously, which is why both standards must be applied together during development and certification.

According to ISO, the two standards are explicitly designed to be complementary: ISO 26262 handles the “fault” space, while ISO 21448 handles the “insufficiency” space. Together they form the primary safety framework for advanced driver assistance systems (ADAS) and automated driving functions recognised by regulators and OEMs across the global automotive industry.

ISO 26262: Managing Faults and Failures with ASIL Classification

ISO 26262 is the foundational functional safety standard for road vehicles, applicable to all electrical and electronic (E/E) systems in production passenger cars. It establishes a structured process for identifying hazards caused by malfunctions, assigning safety integrity requirements, and verifying that those requirements are met through design, implementation, and testing.

The ASIL Framework

The standard’s central tool is the Automotive Safety Integrity Level (ASIL), which classifies the required rigour of safety measures based on three parameters: severity of potential harm, exposure frequency to the hazardous situation, and controllability — the probability that a driver can intervene to prevent harm. The combination of these three factors produces an ASIL rating from A (lowest) to D (highest), or QM (Quality Management) where no specific safety requirements apply.

ASIL D requirements are typically applied to systems where a failure could cause life-threatening injury and where the driver has little ability to intervene — for example, electronic braking systems or steering-by-wire. ASIL decomposition allows engineers to split a single ASIL D requirement across two independent subsystems, each carrying ASIL B, provided sufficient independence can be demonstrated.

Scope and Coverage

ISO 26262 covers the full safety lifecycle: from hazard analysis and risk assessment (HARA), through functional safety concept definition, system design, hardware and software development, integration testing, and production release. The standard applies to series production vehicles up to 3,500 kg, though its principles are widely applied to heavier vehicles and motorcycles through related standards. According to SAE International, ISO 26262 compliance has become a baseline expectation for automotive tier-1 suppliers and OEMs worldwide.

A critical limitation of ISO 26262 becomes apparent in advanced autonomous systems: the standard was designed for systems where hazards arise from component failures. It does not address what happens when all components are working perfectly but the system still makes a wrong decision — for instance, a perception algorithm that misclassifies a stationary object as a dynamic one. That gap is precisely what ISO 21448 was created to fill.

ISO 21448 SOTIF: When a Correctly Functioning System Is Still Unsafe

ISO 21448, published in 2022, defines the Safety Of The Intended Functionality (SOTIF) framework for road vehicles. SOTIF addresses a category of risk that ISO 26262 explicitly excludes: safety hazards that arise not from system failures, but from the system’s intended behaviour being insufficient to handle the full complexity of real-world driving scenarios.

The motivating insight behind SOTIF is that modern automated driving functions rely on machine learning-based perception systems — cameras, radar, lidar — whose performance is inherently probabilistic. A camera-based pedestrian detection system may achieve 99.9% accuracy in standard conditions, yet fail systematically in specific edge cases: low-angle sunlight, unusual clothing patterns, or partially occluded objects. These are not faults — they are limitations of the intended design. SOTIF requires engineers to identify, analyse, and mitigate these limitations before deployment.

The Operational Design Domain (ODD)

A central concept in ISO 21448 is the Operational Design Domain (ODD), which defines the specific conditions under which a system is designed to operate safely. The ODD encompasses environmental conditions such as weather (rain, fog, snow), lighting (day, night, glare), road type (highway, urban, rural), and geographic constraints. SOTIF validation requires engineers to demonstrate that the system performs safely within its ODD, and that transitions beyond ODD boundaries are handled safely — typically by requesting driver takeover or bringing the vehicle to a safe stop.

“ISO 21448 requires engineers to demonstrate not just that the system does not fail — but that the system’s intended behaviour is itself safe across the full range of scenarios it will encounter in operation.”

Known and Unknown Hazardous Scenarios

ISO 21448 distinguishes between two types of hazardous scenarios: known hazardous scenarios (where the triggering conditions and failure modes are already understood) and unknown hazardous scenarios (where the triggering conditions have not yet been identified). The standard requires a systematic process to enumerate known scenarios, mitigate them through design improvements or operational restrictions, and then use simulation, closed-track testing, and real-world driving data to reduce the space of unknown scenarios to an acceptably low residual risk level. As noted by IEEE, this scenario-based validation methodology represents a fundamental shift from the fault-tree and FMEA approaches central to ISO 26262.

Side-by-Side: Scope, Methods, and Certification Requirements

The most precise way to understand the difference between ISO 26262 and ISO 21448 is to examine their scope, hazard model, primary methods, and certification outputs side by side. The two standards diverge at the most fundamental level — the definition of what constitutes a safety problem.

Hazard Model

ISO 26262 uses a fault-based hazard model. The primary analytical tools are Hazard Analysis and Risk Assessment (HARA), Failure Mode and Effects Analysis (FMEA), and Fault Tree Analysis (FTA). The goal is to identify all ways in which component failures can lead to hazardous vehicle behaviour, assign ASIL levels to the resulting safety goals, and verify through design and testing that those goals are met.

ISO 21448 uses a scenario-based hazard model. The primary analytical tools are functional insufficiency analysis, triggering condition identification, and statistical validation through simulation and real-world driving. The goal is to identify all scenarios — both within and at the boundary of the ODD — where the system’s intended behaviour produces unsafe outcomes, and to demonstrate that the probability of such outcomes is acceptably low.

Primary Methods Compared

• ISO 26262: HARA, FMEA, FTA, ASIL decomposition, hardware diagnostic coverage metrics, software unit testing, independence requirements between safety-relevant elements.
• ISO 21448: ODD definition, triggering condition analysis, scenario catalogue development, simulation-based testing, closed-track validation, real-world driving data analysis, machine learning performance metrics.

Output Artefacts

ISO 26262 produces a Safety Case — a structured argument, supported by evidence, that the system meets all ASIL-derived safety requirements. ISO 21448 produces a SOTIF Safety Argument — a structured demonstration that the residual risk from functional insufficiencies is acceptable across the system’s ODD. Both artefacts are required for regulatory type approval in markets that recognise the UN Regulation No. 157 framework for automated lane keeping systems, as published by UNECE.

Applying Both Standards in Autonomous Driving Development

In practice, applying ISO 26262 and ISO 21448 together requires a coordinated safety engineering process that begins at system concept and continues through to production validation. The two standards share a common foundation — both require systematic hazard identification, risk assessment, and documented evidence of safety — but their methods, tools, and acceptance criteria differ substantially.

Where the Standards Intersect

The interface between the two standards is most visible in the treatment of perception systems. A camera-based object detection module must satisfy ISO 26262 requirements for hardware reliability (diagnostic coverage, safe failure fraction) and software development process (ASIL-appropriate coding guidelines, unit test coverage). Simultaneously, it must satisfy ISO 21448 requirements for detection performance across the full ODD — including edge cases, adverse weather, and challenging lighting conditions. Engineers must manage both sets of requirements within a single development programme, using a unified safety plan that coordinates HARA outputs with SOTIF triggering condition analysis.

IP and Patent Strategy Implications

For R&D engineers and IP professionals, the dual-standard framework creates distinct patent filing opportunities. ISO 26262 compliance innovations — novel ASIL decomposition architectures, hardware redundancy topologies, or software safety mechanisms — are well-established patent categories. ISO 21448 SOTIF compliance is generating a newer wave of patent activity around scenario generation algorithms, simulation-based validation methods, ODD monitoring systems, and machine learning safety metrics. Tracking patent activity in both domains is essential for competitive intelligence, freedom-to-operate analysis, and identifying white-space opportunities in autonomous driving safety technology. WIPO patent data shows sustained growth in automotive functional safety filings across both standards domains.

Regulatory Trajectory

The regulatory landscape for autonomous driving safety is converging on explicit recognition of both standards. UNECE Regulation No. 157 (automated lane keeping systems) references both functional safety and SOTIF as requirements for type approval. National regulators in the EU, Japan, South Korea, and China have incorporated similar dual-standard requirements into their autonomous vehicle approval frameworks. The NHTSA in the United States has referenced both ISO 26262 and ISO 21448 in its automated driving system safety guidance, signalling alignment with the international regulatory consensus. For engineering teams developing autonomous systems for global markets, compliance with both standards is not optional — it is the baseline expectation for market access.

For IP professionals, this regulatory convergence means that patent portfolios covering both fault-based and insufficiency-based safety mechanisms are increasingly valuable. Companies that hold broad patent positions across ASIL-compliant hardware architectures and SOTIF-compliant scenario validation methods are well-positioned as autonomous driving technology matures toward higher SAE automation levels. Monitoring patent activity through a platform such as PatSnap’s IP intelligence tools enables teams to identify competitive threats and filing opportunities before they become market-critical.