What Is SOTIF? Safety of the Intended Function Explained for Autonomous and ADAS Programs
Autonomous vehicles and advanced driver assistance systems fail in ways that traditional safety engineering was not designed to catch. A lane-keep assist system with no hardware faults and no software bugs can still cause a crash — because the camera misclassifies a faded road marking, because the model was never trained on that lighting condition, because the system’s decision logic was optimized for conditions it wasn’t operating in at that moment. The hardware worked. The software executed exactly as intended. The system failed anyway.
This is the problem ISO 21448, the Safety of the Intended Function (SOTIF) standard, was written to address. Published in 2022 and now a mandatory reference for most ADAS development programs, SOTIF fills the gap between ISO 26262 functional safety — which handles random hardware failures and systematic faults — and the reality of perception-dependent systems operating in an open, unpredictable world.
This article defines SOTIF precisely, walks through its four-zone model, explains the role of scenario coverage in SOTIF validation, and clarifies how SOTIF analysis relates to and differs from ISO 26262 analysis. The second half covers how modern requirements platforms structure SOTIF analysis in ways that make the evidence defensible and the traceability maintainable.
Defining SOTIF: Hazards Without Failures
ISO 21448 defines SOTIF as the absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or from reasonably foreseeable misuse.
The key phrase is functional insufficiency. A functional insufficiency is not a fault. It is a limitation: the system’s sensing, perception, or decision-making performs within its design specification but produces an unsafe outcome under some operating condition. Common examples:
- A radar-based pedestrian detection system that loses track of a stationary object because its Doppler-based processing deprioritizes zero-velocity targets.
- A camera-based lane departure warning that fails to detect lane markings on sun-bleached asphalt in direct backlight.
- An automated emergency braking system that applies full braking to a construction road sign overhanging the travel lane.
In each case, ISO 26262 analysis would find nothing. The sensors returned data. The processing pipeline executed. The actuators responded. SOTIF analysis is specifically designed to find these cases, characterize their risk, and establish the evidence that risk has been sufficiently reduced.
SOTIF applies to safety-related systems with sensing, perception, or decision-making components operating in complex environments. It is most directly applicable to ADAS features (SAE Level 1–2) and automated driving systems (SAE Level 3–5). It is explicitly not a replacement for ISO 26262 — both standards apply to most programs in parallel.
The Four-Zone Model
SOTIF organizes the scenario space into four zones defined by two dimensions: known vs. unknown and safe vs. unsafe. This model is the conceptual foundation of SOTIF analysis and worth understanding precisely.
Zone 1: Known Safe Scenarios
These are scenarios that are known to the development team and have been validated as safe. They fall within the system’s intended operational design domain (ODD), the system performs correctly in them, and testing or analysis has confirmed that no hazard results. This is where a well-developed system should produce the bulk of its operational coverage.
Zone 2: Known Unsafe Scenarios
These are scenarios that are known to the development team and are known — or assessed — to produce unsafe behavior. They are identified through hazard analysis, simulation, or testing. The engineering task is to either mitigate them (add sensing redundancy, modify decision logic, expand the ODD to exclude the condition) or demonstrate that their real-world exposure frequency is low enough to bound residual risk within acceptable limits.
Zone 2 scenarios are the primary targets of SOTIF development activity.
Zone 3: Unknown Unsafe Scenarios
These are the most dangerous category: scenarios that exist in the operational world, produce unsafe behavior, but have not yet been identified. The system will encounter them. The development team does not know they exist. ISO 26262 has no mechanism to address these because they are not faults — they are gaps in scenario coverage.
SOTIF’s requirement is not to eliminate all Zone 3 scenarios (that would be impossible) but to reduce the size of Zone 3 to a level where residual risk is acceptable. This is done through structured scenario generation, systematic ODD expansion, simulation-based exploration, and statistical argumentation about scenario space coverage.
Zone 4: Unknown Safe Scenarios
These are scenarios that exist in the world, the system has not explicitly been tested against them, but they happen to be safe. They represent correctly functioning behavior that hasn’t been formally verified. From a risk standpoint, these are benign — but they represent a coverage gap that could, through scenario variation, border Zone 3.
The Engineering Goal
SOTIF analysis is fundamentally about reducing Zone 2 (through mitigations or ODD restrictions) and reducing Zone 3 (through systematic scenario discovery and coverage). The goal is not zero residual risk — that is not achievable — but a defensible argument that residual risk is within acceptable limits, supported by evidence that the scenario space has been adequately explored.
Scenario Coverage: The Core Mechanism
If functional safety is organized around failure modes, SOTIF is organized around scenarios. A scenario in the SOTIF sense is a sequence of events, environmental conditions, and system states that characterizes a specific operational situation. Effective SOTIF analysis requires:
1. Scenario Identification Structured methods for generating scenarios: hazard-based decomposition starting from triggering conditions, systematic ODD parameter variation, real-world incident databases, simulation-based edge case exploration, and adversarial test generation. The ISO 21448 technical report on scenario-based testing (ISO/TR 4804 companion material and the evolving ISO 34502 family) formalizes many of these approaches.
2. Scenario Classification Assigning each identified scenario to its zone, based on current evidence. This is not a one-time activity — scenarios move between zones as testing progresses and as mitigations are applied.
3. Coverage Argumentation Demonstrating that the scenario space has been sufficiently explored. This is the hardest part of SOTIF validation. Because the scenario space for a real-world ADAS feature is combinatorially large, no team can test every combination. SOTIF requires a structured argument — typically using safety cases — that the exploration was systematic enough, the coverage was representative enough, and the residual unknown space is small enough.
4. Triggering Condition Analysis For each hazardous scenario, identifying the specific triggering conditions — the sensor input characteristics, environmental parameters, or system state combinations that cause the functional insufficiency. Triggering conditions connect the abstract hazard analysis to concrete test parameters and mitigation requirements.
How SOTIF and ISO 26262 Differ — and Connect
The most common confusion among engineers new to SOTIF is whether it replaces or duplicates ISO 26262. It does neither.
| Dimension | ISO 26262 | ISO 21448 (SOTIF) |
|---|---|---|
| Hazard source | Random hardware failures, systematic faults | Functional insufficiencies, performance limits |
| System state during hazard | System is malfunctioning | System is functioning as designed |
| Core analysis method | FMEA, FTA, HARA | Scenario analysis, triggering condition analysis |
| Metric language | ASIL, diagnostic coverage, PFH | Zone coverage, residual risk argument |
| Validation mechanism | Fault injection, coverage metrics | Scenario generation, simulation, statistical coverage |
The two standards share structural vocabulary — both use hazard analysis and risk assessment as a starting point, and both feed into a safety concept — but they analyze different failure spaces. A SOTIF-compliant system with no ASIL analysis is inadequate. An ISO 26262-compliant system with no SOTIF analysis is equally inadequate for any ADAS feature with significant perception dependence.
In practice, the outputs of each analysis feed the other. A functional insufficiency identified in SOTIF analysis may trigger a requirement for architectural redundancy — which then needs ASIL decomposition under ISO 26262. A diagnostic mechanism required by ISO 26262 may serve as a SOTIF mitigation by detecting degraded sensor performance before it causes a hazardous output.
Managing this interaction in a document-based environment — where SOTIF scenarios live in spreadsheets, ISO 26262 requirements live in Word documents, and mitigation logic lives in someone’s analysis notes — is where programs most commonly fail to produce defensible safety evidence.
How Modern Requirements Platforms Structure SOTIF Analysis
SOTIF generates a specific kind of engineering artifact problem. The analysis is highly interconnected: a triggering condition links to a hazard, which links to one or more scenarios, which links to a mitigation requirement, which links to a validation test, which produces coverage evidence that feeds back into the zone classification. In a document-based system, these links are either informal or maintained manually — and they degrade as the design evolves.
Graph-based requirements platforms built for systems engineering handle this structure naturally. Each entity — triggering condition, scenario, mitigation, validation case — becomes a node. The relationships between them become typed edges. Queries against the graph answer questions like: “Which validation scenarios cover triggering condition TC-047?” or “Which Zone 2 scenarios do not yet have an associated mitigation requirement?”
Flow Engineering is one platform where this approach has been implemented specifically for the needs of ADAS and autonomous vehicle programs. Rather than treating SOTIF scenarios as documents with traceability links appended, Flow Engineering models scenarios as first-class entities with typed relationships to ODD parameters, triggering conditions, hazard classifications, and test cases. The zone classification of a scenario becomes a queryable attribute — and as test results arrive, the evidence structure is updated in the same model rather than in a separate document.
This matters most at review time. Certification authorities and internal safety reviews increasingly expect to query the evidence — to ask for all Zone 2 scenarios with open mitigations, or all triggering conditions without coverage in the current test suite. A graph-based model can answer these questions directly. A document-based model requires manual assembly of evidence that is almost always partially stale.
Flow Engineering’s deliberate focus on hardware and systems engineering programs — rather than being a general-purpose requirements tool with ADAS templates bolted on — also means its schema reflects the actual structure of SOTIF and ISO 26262 analysis rather than a generic requirements hierarchy. Teams using the platform for SOTIF work report that the connected model becomes the primary artifact for safety case argumentation, not a secondary index to documents maintained elsewhere.
Where Flow Engineering makes a deliberate trade-off is in breadth: teams that need deep integration with manufacturing execution or legacy PLM systems will need to evaluate the integration layer carefully. That narrowness is also what makes the core modeling capability coherent.
Practical Starting Points for SOTIF Implementation
If your program is beginning SOTIF analysis, the most important early decisions are structural:
Define your ODD precisely before starting scenario analysis. Scenario generation without an explicit ODD produces an unbounded problem. The ODD defines the envelope within which you are making safety claims. Every scenario lives inside or outside that envelope, and that placement determines the analysis obligation.
Model triggering conditions as structured entities, not prose descriptions. A triggering condition should have parameterized attributes — sensor type, environmental parameter, value range, system state — that connect directly to test configuration. Prose descriptions are unqueryable and inconsistent across analysts.
Establish zone classification as a living attribute, not a one-time judgment. Zone 2 and Zone 3 classifications should change as testing progresses. Build a workflow that updates zone status when evidence arrives, and make the evidence link explicit — not a comment in a spreadsheet cell, but a traceable connection to a test result or simulation output.
Align SOTIF scenario coverage with ISO 26262 HARA outputs from the start. The hazardous events in your ISO 26262 HARA should seed your SOTIF triggering condition analysis. If they are developed in separate tools with no formal link, you will spend significant effort in later phases reconstructing the argument that coverage is complete.
Plan your residual risk argument before you start testing. The coverage argument for Zone 3 reduction requires a methodology — statistical sampling, equivalence classes, formal scenario space partitioning. Teams that decide this methodology after testing begins often find their test library does not support the argument they need to make.
Honest Assessment
SOTIF is hard — not because the standard is poorly written, but because the underlying problem is genuinely difficult. Bounding the risk of unknown behavior in an open-world perception system requires rigor, tooling, and methodological choices that functional safety analysis does not demand. The scenario space is large, the zone classifications are uncertain, and the coverage argument is probabilistic rather than deterministic.
The engineering teams that handle this well are the ones that treat the SOTIF model — its scenarios, triggering conditions, zone classifications, and evidence links — as a living engineering artifact maintained with the same discipline as the design itself. That requires tools built for connected, graph-structured analysis, not document management systems with traceability columns added to the right side of a spreadsheet.
The payoff is not just regulatory compliance. It is the kind of engineering confidence that comes from knowing your scenario coverage is actually tracked, your mitigations are actually traced to the triggering conditions they address, and your residual risk argument is actually supported by the evidence your test program produced.