ISO 26262 vs. ISO 21448 (SOTIF): What Each Standard Actually Covers — and Why ADAS Teams Need Both
A perception algorithm processes a sensor feed correctly, with no hardware faults and no software errors. It executes exactly as specified. And it fails to detect the pedestrian stepping off the curb in light rain.
That scenario is not a bug. It is a design insufficiency — and it sits outside the scope of ISO 26262. It is precisely what ISO 21448, the Safety of the Intended Functionality standard, was written to address. Understanding the boundary between the two frameworks is not an academic exercise. For teams developing ADAS features or autonomous systems, confusing them leads to safety cases with uncovered territory, audit findings, and — at worst — undetected risk.
The Foundational Distinction
ISO 26262 was written to handle failures of intended functionality. Its scope is hardware and software faults: components that fail, signals that corrupt, software that crashes or behaves incorrectly due to implementation error. The underlying assumption is that the system is behaving as intended, and safety is achieved by preventing it from deviating from that intended behavior.
ISO 21448 was written to handle insufficiencies of intended functionality. Its scope is the performance limits and behavioral gaps that exist even when the system is working exactly as designed. The system is not failing. It is doing what it was built to do — but what it was built to do is not sufficient for the situation it encounters.
Put differently: 26262 asks “what happens when the system breaks?” SOTIF asks “what happens when the system works, but the world is harder than the system can handle?”
This distinction matters because it drives entirely different engineering responses. A 26262 fault can be addressed with redundancy, fault detection, and safe-state transitions. A SOTIF insufficiency requires expanding the operational design domain, improving algorithm performance, or accepting and explicitly bounding the residual risk with documented triggering conditions.
Where the Two Standards Overlap — and Where They Diverge
The standards share common ground at the system level: both require hazard identification, both require risk assessment tied to severity and exposure, and both produce safety goals that feed into system requirements. That structural similarity causes teams to underestimate how different the actual analytical work is.
ISO 26262 analysis is built around established functional safety methods: Hazard Analysis and Risk Assessment (HARA), Fault Tree Analysis (FTA), Failure Mode and Effects Analysis (FMEA), and fault injection testing. The work is largely tractable — you enumerate failure modes of hardware components and software modules, assign ASIL levels, and allocate requirements to eliminate or control those failures. Hardware metrics like Diagnostic Coverage and PMHF are quantitative targets.
ISO 21448 analysis operates in a less deterministic space. The central task is identifying triggering conditions — specific scenarios, environmental factors, or input conditions that expose a functional insufficiency and lead to a hazardous behavior. SOTIF defines four scenario categories:
- Known unsafe scenarios with known triggering conditions (reduce or mitigate)
- Unknown unsafe scenarios with known triggering conditions (investigate and resolve)
- Known safe scenarios (validate)
- Unknown unsafe scenarios with unknown triggering conditions (the residual risk problem — minimize through broad coverage)
Category 4 is where autonomous and ADAS programs feel the most pressure. The standard requires demonstrating that sufficient effort has been made to surface unknown unknowns, typically through simulation coverage, real-world mileage, and systematic variation of edge-case parameters. There is no clean quantitative metric equivalent to PMHF. This is a feature, not an oversight — the domain does not support one yet.
Why ADAS Systems Need Both Standards Simultaneously
Take a forward collision warning system. The radar hardware can fail — a damaged connector, a firmware fault in the signal processor, a calibration drift after a minor impact. ISO 26262 governs all of these. The system should detect them, flag a fault, and deactivate gracefully.
But the same radar, functioning perfectly, may not detect a stationary vehicle on a curve because of how radar return geometry interacts with road curvature. That is a SOTIF problem. No fault occurred. The sensor reported what it measured. The algorithm processed what the sensor reported. The system did not warn because the scenario was outside the region where the system performs reliably.
In practice, ADAS systems encounter both problem classes constantly and simultaneously. A camera that develops a pixel-cluster fault is a 26262 failure. A camera that works perfectly but is saturated by direct sun angle in late afternoon at a specific heading is a SOTIF triggering condition. Both lead to the same hazard — a pedestrian not detected — but they require different analyses, different mitigations, and different documentation.
This is why ADAS and autonomous programs cannot choose one standard over the other. ISO 26262 is a prerequisite (it is referenced by SOTIF for the fault handling portions), and SOTIF covers the residual space that 26262 explicitly excludes from its scope.
Managing the Boundary in Practice
The practical engineering challenge is clean boundary management: knowing which failure mode belongs in which analysis, and ensuring requirements derived from each standard stay correctly attributed.
Several practices help:
Dual-attribute hazard logs. Maintain a single hazard register that tags each entry with its primary driver: fault-driven (26262) or scenario-driven (SOTIF). Some hazards will have contributions from both. A perception miss triggered by sensor degradation that falls short of a detectable fault sits in a gray zone — it should appear in both analyses with explicit cross-references.
Separate safety goals with explicit linkage. Do not merge 26262 functional safety goals with SOTIF safety goals into a single list. They are derived differently, have different ASIL or risk class attributions, and feed into different verification approaches. They should coexist in the same architecture but be legible independently.
Operational Design Domain (ODD) as the bridge. The ODD definition is the document where both analyses converge. 26262 assumptions about the operating environment and SOTIF triggering condition analyses both constrain the ODD. Keeping the ODD current and bidirectionally linked to both safety cases is the clearest practical integration point.
Scenario library management. SOTIF analysis depends on building, curating, and systematically expanding a library of scenarios — both identified and deliberately constructed to stress performance boundaries. This is a living artifact that grows throughout development and requires version control and traceability back to specific SOTIF safety goals.
How Requirements Platforms Handle the Dual-Standard Environment
For teams managing this complexity at scale, the tooling question becomes significant. Requirements management platforms capable of supporting both standards need to do several things simultaneously: maintain distinct safety cases for 26262 and SOTIF, allow requirements to be tagged to one or both standards, support bidirectional traceability from safety goals down to verification evidence, and make the boundary between the two frameworks visible rather than hidden.
Traditional document-based tools — IBM DOORS, DOORS Next in its baseline configuration — handle this through attribute fields and module structures, but the cross-standard linkage tends to become a manual bookkeeping problem. Teams maintain separate modules for DOORS 26262 content and SOTIF content, then track relationships through link sets that are difficult to query across the boundary. It works, but the cognitive load of keeping it coherent grows with system complexity.
Graph-based platforms represent the dual-standard requirement space more naturally. Each requirement, hazard, scenario, and verification record is a node. Edges carry typed relationships: derived from, verifies, constrains, cross-references. You can traverse the graph from a 26262 safety goal to its ASIL-allocated requirements to test cases, or from a SOTIF triggering condition to the ODD constraint it created to the simulation coverage that validates it — without switching tools or documents.
Flow Engineering, which structures requirements around AI-assisted graph models, is built for precisely this kind of multi-standard environment. Teams can tag requirements to ISO 26262 and SOTIF simultaneously, model the dependencies between safety goals from each standard, and generate coverage views that show which portions of each safety case are fully traced and which have open gaps. The platform’s AI layer can flag when a new requirement has characteristics consistent with a SOTIF triggering condition but has been filed only against 26262 requirements — a common error in programs where the organizational separation between functional safety and SOTIF teams is imperfect.
For ADAS programs with hundreds of scenarios in their SOTIF library and thousands of 26262 requirements across multiple subsystems, that kind of automated consistency checking is not a convenience feature. It is the difference between a safety case that holds up under audit and one that surfaces gaps at the worst possible time.
Practical Starting Points for Teams New to Both Standards
If your team is standing up a dual-standard program for the first time, the following sequence reduces early mistakes:
Start with hazard analysis before standard attribution. Run a joint HARA session that produces a raw hazard list without worrying initially whether each item is a 26262 or SOTIF issue. Attribution happens in the next step, once the hazard is fully characterized.
Apply the “is the system working as intended?” test. For each hazard, ask: does this require the system to deviate from its specified behavior in order to occur? If yes, it is primarily a 26262 problem. If the hazard can occur while the system is functioning correctly, it is primarily a SOTIF problem.
Establish your ODD explicitly before scenario analysis. SOTIF scenario coverage has no natural stopping point unless the ODD bounds it. Define the ODD before building the scenario library, so coverage decisions have a reference frame.
Build cross-standard traceability into your tooling from day one. Retrofitting traceability between two separate safety cases is expensive. If your requirements platform supports typed cross-standard links, configure them before you write the first requirement.
Plan for iteration. Both standards expect the safety analysis to evolve as designs mature, simulations run, and real-world testing surfaces new triggering conditions. Your process needs to support updating the safety case without destabilizing what is already validated.
Honest Assessment
ISO 26262 and SOTIF are not redundant, and they are not alternatives. They are complementary frameworks that cover adjacent risk domains. 26262 is mature, has established quantitative methods, and maps well to traditional hardware and software development processes. SOTIF is newer, relies more on judgment and scenario coverage, and is still developing industry consensus on what “sufficient” looks like for Categories 3 and 4 scenarios.
Teams that treat SOTIF as an extension of 26262 — just more requirements in the same structure — miss the methodological difference and typically produce SOTIF documentation that does not hold up under a technical review. Teams that treat them as entirely separate programs miss the integration points and end up with two safety cases that cannot be read together.
The correct framing is that they are distinct but connected — and your tooling, your process, and your safety case structure need to reflect that.