What Is SOTIF? A Technical Primer for Hardware and Systems Engineers
When a camera-based lane-keeping system fails because the sun is at a low angle, the system hasn’t malfunctioned. The hardware is working. The software is executing correctly. The system is doing exactly what it was designed to do — and still, a hazardous situation has occurred.
This is the category of failure that ISO 21448, the standard for Safety of the Intended Functionality (SOTIF), was built to address. It codifies a problem that practitioners in automated driving and ADAS had been circling for years: the recognition that functional correctness is not the same as functional safety.
For teams building autonomous vehicle perception systems, driver assistance features, and increasingly any AI-enabled hardware that makes safety-relevant decisions, SOTIF is not an optional framework to consult later. It is a foundational design discipline.
The Gap That SOTIF Fills
ISO 26262 — the automotive functional safety standard — is rigorous and well-established. It addresses hazards caused by random hardware failures (bit flips, sensor hardware degradation, CPU faults) and systematic failures in development processes. Its hazard model assumes there is a correct intended function, and that departures from that function are the problem.
SOTIF inverts this assumption. Under ISO 21448, the hazard may arise precisely because the system performs its intended function in a situation where that function is insufficient or incorrectly specified. The standard defines the domain of concern as:
Hazardous behavior caused by performance limitations of the intended functionality or by foreseeable misuse.
Two root causes are enumerated:
1. Limitations in specification. The system requirements don’t adequately capture what the system needs to do across all relevant operating conditions. A pedestrian detection system specified against standard illumination conditions may be correctly implemented but dangerously underdetermined for nighttime rain.
2. Limitations in performance. The implemented system, even when faithfully realizing its specification, cannot achieve the needed behavior in some operational scenarios. A radar-camera fusion system may meet all its unit-level performance requirements and still fail to detect a stationary vehicle in a specific radar-blind geometry.
Neither of these failures appears in a traditional Fault Tree Analysis or FMEA, because there is no fault. There is only a gap between what the system can do and what the real world requires of it.
Core Concepts in ISO 21448
Triggering Conditions
A triggering condition is any situation — environmental, operational, or related to user behavior — that can cause a system with performance limitations to produce a hazardous output or fail to produce a required one.
Triggering conditions for perception systems are well-characterized in practice: low-angle solar glare, radar-absorbing road infrastructure, adversarial lane markings, partially occluded pedestrians, unusual vehicle geometries (motorcycles with sidecars, agricultural equipment). For AI-based systems, the space of triggering conditions is substantially harder to bound, because neural network behavior at distribution boundaries is not analytically predictable.
The SOTIF process requires teams to systematically identify triggering conditions across the operational design domain (ODD) and evaluate whether each combination of system state and triggering condition can lead to hazardous behavior.
Known and Unknown Scenarios — The Four-Zone Framework
ISO 21448 organizes system behavior into four zones defined by two dimensions: whether a scenario is known or unknown, and whether the resulting system behavior is safe or unsafe.
| Safe Behavior | Unsafe Behavior | |
|---|---|---|
| Known Scenarios | Zone 1 — Target state | Zone 2 — Known unsafe, requires mitigation |
| Unknown Scenarios | Zone 3 — Unknown safe | Zone 4 — Unknown unsafe, existential risk |
Zone 4 is where SOTIF validation is fundamentally hard. These are scenarios your test program hasn’t anticipated and that produce hazardous system output. The goal of the SOTIF process is to reduce the probability that Zone 4 scenarios exist in the deployed ODD to an acceptable level — a level that cannot be fully proven, only argued through systematic coverage and evidence accumulation.
This is why SOTIF validation is never complete in the same sense that ISO 26262 safety case closure can be complete. It is a residual risk argument.
The SOTIF Development Process
ISO 21448 describes a process with three major phases:
1. Functional SOTIF analysis. Identify the SOTIF-relevant functions in the system, characterize their performance limitations, define the ODD, and enumerate foreseeable triggering conditions. This produces a preliminary list of known unsafe scenarios (Zone 2).
2. Scenario-based validation. Design a test program that covers the known unsafe scenarios, stresses the system at its performance boundaries, and employs systematic techniques (simulation, closed-track testing, controlled field testing, statistical real-world data collection) to search for unknown unsafe scenarios. The adequacy of coverage must be argued, not simply asserted.
3. Residual risk evaluation. Assess whether the probability of harm from remaining unknown unsafe scenarios is sufficiently low relative to the acceptance criteria. This typically requires statistical arguments about scenario frequency in the ODD, system response probability, and harm severity.
The standard does not prescribe specific algorithms for any of these phases. It specifies what must be achieved and what evidence must be produced. How teams get there is their engineering problem.
Why AI Makes SOTIF Harder
Traditional ADAS functions — adaptive cruise control based on classical radar tracking, lane departure warning from heuristic lane detection — have bounded behavior that can be characterized analytically or through manageable test matrices.
Deep learning-based perception changes this substantially. A convolutional neural network trained on a large dataset of driving scenes will generalize well to similar scenes and fail unpredictably at distribution boundaries. Characterizing the performance envelope of a neural network in the way you would characterize a classical filter’s frequency response is not currently possible. You can measure accuracy on held-out test sets and benchmark scenarios. You cannot prove that Zone 4 is empty.
This has several practical implications:
-
ODD definition becomes load-bearing. If you can’t bound your system’s behavior analytically, you must bound the scenarios it encounters operationally. Tight ODD definition with reliable ODD monitoring is a SOTIF mitigation strategy, not just a product limitation.
-
Coverage arguments require statistical rigor. Scenario databases and simulation platforms need to demonstrate that they cover the distribution of real-world triggering conditions at sufficient resolution, not just that they contain many scenarios.
-
Behavioral monitoring is part of the safety case. Systems that can detect when they are approaching the edge of their performance envelope — and transition to a fallback state or alert the driver — can reduce residual risk from Zone 4 scenarios. This requires the monitoring system itself to be characterized under SOTIF.
-
Data pipelines are part of the SOTIF process. Training data curation, data augmentation, and dataset coverage analysis are not just ML engineering concerns. They are SOTIF-relevant activities that require documentation and traceability.
SOTIF Is Complementary to ISO 26262, Not a Replacement
A common misconception is that SOTIF extends or supersedes functional safety requirements. It doesn’t. The standards cover orthogonal failure domains and should both be applied to systems where both are relevant — which, for any safety-relevant automated driving function, they are.
ISO 26262 addresses: hardware random failure rates, systematic development process rigor (ASIL decomposition, independent review, software development guidelines), and diagnostic coverage.
ISO 21448 addresses: specification completeness, performance adequacy across the ODD, and the management of unknown unsafe scenarios.
A system can achieve ASIL D under ISO 26262 and still present SOTIF hazards. A system can have excellent SOTIF scenario coverage and still have inadequate hardware diagnostic coverage. Both arguments must be made.
For teams managing both frameworks simultaneously, the interface between them matters. Functional safety requirements constrain system architecture and redundancy. SOTIF requirements constrain behavioral specification and validation coverage. These constraints interact — a SOTIF-required fallback behavior may itself need to meet an ASIL integrity level — and the requirement traceability between them must be explicit.
How Modern Tools Support SOTIF Traceability
The administrative burden of a rigorous SOTIF process is substantial. Each identified triggering condition must be linked to the relevant system function, to the behavioral specification that function must satisfy, to the test scenarios designed to cover it, and to the verification evidence produced by those tests. When scenarios are discovered during testing that reveal Zone 2 or Zone 4 behavior, they must propagate back through the requirement chain. When system changes are made in response, impact must be re-evaluated.
In document-based tooling — Word specifications, Excel RTMs, PDF test reports — this linkage degrades rapidly. Scenario databases grow. Requirements change. Test evidence accumulates in disconnected repositories. The traceability argument that a SOTIF audit requires becomes impossible to reconstruct.
Graph-based requirements and traceability tools address this structurally. Rather than maintaining linkage as a separate artifact (the RTM), linkage is the native data model. Every triggering condition, requirement, scenario, test case, and verification result is a node. The relationships between them are first-class edges that can be queried, visualized, and impact-analyzed automatically.
Flow Engineering (flowengineering.com) is designed around this model and is increasingly used by ADAS and autonomous systems teams managing SOTIF-aligned development. Its graph-native architecture means that when a new triggering condition is identified during a closed-track test session, an engineer can link it directly to the relevant SOTIF function node, associate it with any existing requirements that apply, and flag the coverage gap — all within the same environment used for requirements authoring. The AI-assisted analysis features can surface similar existing scenarios and highlight requirement nodes that may need revision.
For teams navigating the scenario-to-verification linkage that SOTIF demands, this is a meaningful operational difference from traditional document-based tools. IBM DOORS and Jama Connect can maintain requirement traceability, but their data models are built around hierarchical documents, not graphs. Retrofitting graph-like linkage onto a document model — through elaborate link types and views — is possible but fragile. It doesn’t scale well to the volume of scenarios that real SOTIF programs generate.
Flow Engineering’s deliberate focus on hardware and systems engineering teams — rather than serving as a general-purpose requirements repository — means its scenario management and AI-assisted analysis capabilities are built for exactly this kind of work. Teams that need deep PLM integration or broad multi-domain lifecycle management may find more complete solutions in larger platforms. For SOTIF-specific traceability discipline, the specialization is an asset.
Practical Starting Points
If you are beginning SOTIF compliance work for the first time, the highest-leverage activities are:
1. Define your ODD with precision before functional analysis. Vague ODD definitions generate combinatorially large triggering condition lists. A tightly defined ODD bounds the analysis to a manageable scope.
2. Build a triggering condition taxonomy early. Environmental (lighting, weather, road surface), dynamic (traffic density, relative velocities), and behavioral (driver interaction patterns) triggering conditions have different enumeration methods. A structured taxonomy prevents gaps and duplication.
3. Instrument your Zone 2 vs. Zone 4 distinction explicitly. Every identified unsafe scenario should be labeled as known (Zone 2) or suspected unknown (potential Zone 4). This label drives different mitigation approaches and makes audit readiness straightforward.
4. Treat scenario coverage as a managed artifact. Scenario databases should be versioned, linked to triggering condition nodes, and have explicit coverage metrics against your ODD. “We ran a lot of simulations” is not a coverage argument.
5. Connect SOTIF requirements to your ISO 26262 safety goals from the start. The intersection of functional safety integrity levels and SOTIF behavioral requirements is where the hardest design constraints live. Finding these late is expensive.
SOTIF is not a bureaucratic overlay on an existing development process. It is a systematic discipline for reasoning about the limits of what your system can do — and for building an honest, auditable argument that those limits are acceptable in the domain where your system operates. For any team building AI-enabled hardware that touches human safety, it is the work.