What Is SOTIF (ISO 21448)? Safety of the Intended Functionality Explained

A camera-based automatic emergency braking system does everything its designers intended. It detects objects. It calculates closing speed. It applies the brakes when thresholds are crossed. No hardware fails. No software has a bug. The system works exactly as specified.

And then it fails to brake for a pedestrian in heavy fog, because the design envelope never accounted for that sensor degradation condition. Someone is injured.

ISO 26262 would not have caught this. Its scope is hardware and software faults — random failures and systematic errors in components doing the wrong thing. This vehicle did the right thing, for conditions that no longer applied. That is the gap ISO 21448, known as SOTIF (Safety of the Intended Functionality), was written to close.

What SOTIF Actually Addresses

SOTIF defines a failure class that functional safety frameworks explicitly exclude: hazardous behavior that arises from the limitations or performance insufficiencies of a system’s intended design, not from faults in it. The system specification is correct. The implementation matches the specification. The hazard still exists.

This matters because modern driver assistance and autonomous systems are perception-driven, decision-making systems operating in open, uncontrolled environments. A radar-based adaptive cruise control system designed to maintain following distance was never designed to handle a vehicle cutting in at close range at highway speed. The AEB system calibrated on a test track dataset may not generalize to a construction zone with unusual lane markings. In both cases, failure occurs at the boundary of the design’s competence, not at a fault in its execution.

ISO 21448 was first published in 2022, developed within the automotive context with ADAS and autonomous driving functions (SAE Level 0–2 principally, with guidance toward Level 3+) as its primary scope. Its logic has immediate relevance to any engineered system where:

• Sensors or perception algorithms interpret real-world input
• Machine learning or trained models contribute to decisions
• The system must operate across a wide, poorly-bounded operational design domain (ODD)
• Human factors affect whether the system performs as expected

This includes collaborative robotics, medical devices with imaging or sensing components, and unmanned systems — any domain where “the system did what it was told” does not guarantee safety.

How SOTIF Differs from ISO 26262 Functional Safety

The cleanest way to separate these two standards is to ask what kind of “wrong” they address.

ISO 26262 asks: Did the system do something it was not supposed to do? A sensor sends corrupt data. A microcontroller has a stuck-at fault. A software module executes an unintended branch. These are malfunctions — deviations from the design. ISO 26262 defines a process for detecting, containing, and mitigating those deviations through ASIL (Automotive Safety Integrity Level) assignment, hardware fault metrics, and systematic software development practices.

ISO 21448 asks: Did the system do exactly what it was supposed to do, in a situation where that behavior was hazardous? The camera truly could not detect the pedestrian in those lighting conditions — not because the camera malfunctioned, but because the camera’s specified performance was insufficient for that scenario. The AEB algorithm applied its decision logic correctly, but the triggering scenario was outside the set of conditions the algorithm handles competently.

This is a design adequacy question, not a fault containment question. SOTIF compliance requires engineering teams to:

1. Define the Operational Design Domain explicitly and completely
2. Identify triggering conditions — specific scenario characteristics that cause performance insufficiency
3. Assess and bound the hazard potential of those triggering conditions
4. Design and verify mitigations that reduce scenario exposure or improve performance within it

The two standards are complementary. A fully ISO 26262-compliant system can still violate SOTIF. A SOTIF-aware design process that ignores functional safety is also incomplete. For autonomous systems in particular, both frameworks must be applied in parallel, with clear documentation of how each addresses distinct hazard types.

The Four Zones of SOTIF Analysis

ISO 21448 introduces a scenario classification model built around two axes: known versus unknown scenarios, and safe versus unsafe behavior within those scenarios. The intersection of these axes produces four zones that define both the current state of a system’s safety case and the direction of engineering effort.

Zone 1 — Known Scenarios, Unsafe Behavior These are identified hazardous scenarios: the engineering team knows they exist, and analysis confirms the system behaves hazardously within them. Zone 1 represents unacceptable residual risk. Mitigations must be designed and verified until Zone 1 is empty, or the scenarios are transferred to Zone 2 through design improvement.

Zone 2 — Known Scenarios, Safe Behavior These are identified scenarios where the system behaves safely — either because it performs adequately, or because mitigations bring the hazard to acceptable levels. Zone 2 is the target state for all known scenarios. Growing Zone 2 is the measurable objective of SOTIF engineering work.

Zone 3 — Unknown Scenarios, Unsafe Behavior This is the most important zone for autonomous systems engineering, and the hardest to address. These are hazardous scenarios the engineering team has not yet identified. The system behaves unsafely within them, but no one has discovered the scenarios yet. Systematic methods — functional safety analysis, scenario generation, simulation coverage, real-world operational data — are used to discover and migrate Zone 3 scenarios into Zone 1, where they can be addressed.

Zone 4 — Unknown Scenarios, Safe Behavior These are scenarios that have not been explicitly analyzed but where the system behaves safely anyway — either by inherent robustness or by coverage overlap from known-safe design. Zone 4 represents acceptable residual risk, but teams should be cautious about relying on it: a Zone 4 scenario can become Zone 3 under changed conditions or system modifications.

The engineering mandate of SOTIF is directional and measurable: shrink Zones 1 and 3, grow Zone 2, and bound the residual risk in Zone 4 to an acceptable level. What counts as acceptable is not arbitrary — ISO 21448 requires comparison to a reasonable reference system (typically a competent human driver in the automotive context) and statistical evidence that the modified system does not introduce new, unreasonable risk.

Why This Matters Practically for ADAS, Autonomous Driving, and Robotics

SOTIF’s implications are not abstract. They translate into concrete engineering obligations that teams regularly underestimate.

Operational Design Domain definition is load-bearing. Many teams describe ODD in product documentation terms — “highway driving in good weather” — without the precision SOTIF requires. SOTIF demands a structured ODD that is specific enough to support scenario derivation. If your ODD cannot generate a testable trigger condition, it is too vague.

Triggering conditions must be enumerated, not gestured at. A triggering condition is a specific combination of scenario parameters that causes performance insufficiency. “Poor lighting” is not a triggering condition. “Headlamp illumination below 50 lux combined with a pedestrian in dark clothing at lateral offset greater than 2.5 meters” is approaching one. The specificity is necessary because verification is required.

Machine learning components require special treatment. Trained models present a particular SOTIF challenge: their failure modes are not computable from inspection, their performance boundaries are empirical, and their behavior in out-of-distribution inputs is fundamentally uncertain. SOTIF requires ML components to have defined operating conditions and documented evidence of performance within those conditions. This is a significant validation burden that many teams underestimate during early-stage development.

Human-machine interaction is in scope. ISO 21448 explicitly addresses misuse and reasonable foreseeable misuse — driver or operator behavior that interacts with system limitations to produce a hazard. A lane-centering system that correctly hands back control but gives the driver inadequate warning is a SOTIF concern, not purely a UI design issue. This extends the analysis surface considerably for Level 2 ADAS where human oversight is still required.

How Structured Requirements Tools Support SOTIF Analysis

SOTIF compliance generates a documentation and traceability obligation that quickly overwhelms informal processes. For a moderately complex ADAS function, a thorough scenario analysis can produce hundreds of triggering conditions, each requiring an associated mitigation, a verification method, and a closure argument. Managing that in a spreadsheet or disconnected document set is a practical path to gaps.

The structural problem is that SOTIF analysis is inherently relational. A triggering condition exists within a scenario. A scenario is bounded by ODD parameters. A mitigation addresses one or more triggers. A test case provides evidence that the mitigation is effective. A residual risk argument references both the trigger and the mitigation. These are not independent rows in a table — they are nodes in a graph, and the safety case depends on the integrity of the connections between them.

This is exactly the problem graph-based requirements management tools are built to solve. Flow Engineering (flowengineering.com) is one tool that addresses this architecture directly. Rather than storing requirements as flat documents or rows in a relational database, Flow Engineering represents system elements — requirements, scenarios, triggers, mitigations, test cases — as nodes in a connected model. Relationships between them are first-class objects: you can query the model to ask whether every identified triggering condition has a linked mitigation, or whether every mitigation has at least one verification artifact attached.

For SOTIF specifically, that connectivity is the difference between a living safety case and a document that becomes stale as the design evolves. When a sensor specification changes, a connected model surfaces every trigger condition that depended on the previous sensor performance boundary — an update that would require manual cross-referencing in a document-based system.

Flow Engineering’s AI-assisted requirements analysis also supports the Zone 3 challenge: identifying scenario coverage gaps. By analyzing existing scenario definitions against ODD parameters, the tool can surface combinations that have not been addressed, which is a structured proxy for the much harder problem of unknown-unknown scenario discovery.

Teams using document-centric tools like IBM DOORS or Jama Connect can implement SOTIF traceability within those systems, and many do — but doing so typically requires constructing custom traceability matrices and manual link maintenance that adds process overhead and introduces audit risk when links are not kept current. The effort is tractable; it simply requires discipline that a connected model enforces structurally.

Practical Starting Points

If your team is beginning a SOTIF analysis for the first time, the following sequence reduces rework:

Define ODD before scenarios. Scenario derivation is only as complete as the ODD it is derived from. Invest time in making the ODD explicit, parameterized, and bounded before moving to triggering conditions.

Map your HARA output to SOTIF. Your ISO 26262 hazard analysis likely contains scenario descriptions. Use them as a starting set for SOTIF scenario identification, then extend to cover performance-insufficiency triggers that the fault-based HARA did not need to address.

Classify scenarios by zone explicitly. It is tempting to skip the zone taxonomy and go straight to mitigations. The zones matter because they force you to distinguish between “we know about this and have addressed it” and “we know about this and have not addressed it yet” — a distinction that matters in certification and that is easy to obscure in a flat list.

Build traceability as you go. Retrofitting traceability onto a completed SOTIF analysis is painful and error-prone. Link triggers to mitigations and mitigations to test cases as each element is created, not at the end.

Plan for Zone 3 discovery throughout development. Define when and how operational data, simulation results, and field feedback feed back into the scenario inventory. SOTIF is not a one-time analysis — it is a living process, and the mechanism for updating it should be designed in.

The fundamental insight of ISO 21448 is simple and important: a system that works correctly in conditions it understands can still cause harm in conditions it does not. Engineering teams that treat safety as a fault-prevention problem are solving only part of the challenge. SOTIF provides the framework for the rest.