The gap ISO 26262 doesn’t cover
ISO 26262 is the foundational functional safety standard for automotive electrical and electronic systems. It is well understood, widely implemented, and genuinely effective at what it does: managing risk from hardware failures, software errors, and systematic faults. If a sensor fails, a microcontroller produces a wrong output, or a memory corruption event cascades into a safety-critical command, ISO 26262 has a framework for detecting, containing, and mitigating that failure.
But consider a different scenario: the sensor works perfectly. The software executes exactly as designed. The system behaves precisely as its developers intended. And someone still gets hurt.
This is the problem ISO 21448 — the Safety of the Intended Functionality standard, abbreviated as SOTIF — was created to solve.
SOTIF was formally published in 2022, though its technical report predecessor (ISO/PAS 21448) circulated from 2019. It targets a class of hazards that have become increasingly prominent as automated driving and advanced driver assistance systems (ADAS) have matured: hazards that emerge not from faults, but from the inherent limitations of intended functionality combined with foreseeable misuse by real users in real environments.
What SOTIF actually addresses
The standard applies to systems where intended behavior — the designed, non-faulted operation — can still produce unsafe outcomes under certain conditions. The most common context is ADAS and autonomous driving functions, but the principle extends to any safety-critical system where machine perception, prediction, or decision-making operates under uncertainty.
Three core concepts anchor the standard:
1. Performance limitations Every sensing, processing, or actuating system has boundaries on what it can reliably do. A camera-based lane detection system may perform acceptably in clear daylight but degrade in glare, fog, or unusual lane markings. A radar system may have reduced resolution at specific object geometries. A machine learning classifier trained on one distribution of road users may underperform when encountering edge cases outside that distribution. None of these represent faults. They are limitations — and SOTIF analysis requires that they be identified, characterized, and bounded.
2. Triggering conditions A triggering condition is a specific combination of inputs, environment states, or use-case characteristics that exposes a performance limitation and produces hazardous behavior. Glare at a particular sun angle is a triggering condition for a camera system with limited dynamic range. A driver who misinterprets the system’s capability boundary and removes their hands from the wheel at highway speed in a situation the system cannot handle is a triggering condition created by foreseeable misuse. SOTIF demands that triggering conditions be systematically identified — not just acknowledged as a class of risk but enumerated, analyzed for likelihood and severity, and addressed through design modifications or residual risk acceptance.
3. The Operational Design Domain (ODD) The ODD is the defined set of operating conditions within which a system is designed to function safely. This includes environmental parameters (weather, lighting, road type, speed range), geographic constraints, traffic conditions, driver engagement requirements, and more. The ODD is not a disclaimer — it is an engineering artifact that must be precisely specified and defended. SOTIF analysis is largely an exercise in characterizing what happens at the boundaries and beyond the boundaries of the ODD, and ensuring that either the system handles those conditions safely or fails in a controlled, detectable, and recoverable way.
How SOTIF differs from ISO 26262: a structural distinction
Understanding the relationship between the two standards requires clarity on what each is counting as a hazard source.
ISO 26262 operates from the premise that a correctly specified, correctly designed system is safe — and that the job of functional safety engineering is to ensure the system actually behaves as specified in the presence of faults. The ASIL framework, the safety goals, the hardware diagnostic coverage requirements — all of it is oriented toward fault detection, fault tolerance, and safe state transitions when something breaks.
SOTIF starts from a more uncomfortable premise: a correctly implemented system may still be unsafe if the specification itself captures behavior that is hazardous under foreseeable conditions. It does not address what happens when the system breaks. It addresses what happens when the system works exactly as designed and that turns out to be insufficient.
This distinction has direct consequences for how requirements must be written. ISO 26262 safety goals describe what the system shall do in the presence of faults. SOTIF behavioral safety requirements describe what the system shall do across the full range of operating conditions, including conditions near the edges of the ODD, conditions involving degraded sensor inputs, and conditions involving foreseeable user behavior that departs from ideal.
The two standards are complementary and are often applied together in automotive systems engineering programs. A complete safety case for an ADAS feature needs both: ISO 26262 covers the fault dimension, SOTIF covers the limitation and misuse dimension.
Foreseeable misuse: the human behavior variable
One of SOTIF’s most practically demanding requirements is the formal treatment of foreseeable misuse. This is not about edge cases no one could anticipate. It is about the entirely predictable ways that real users interact with systems that are not always used as intended.
A driver using adaptive cruise control on a road type for which it was not designed. A user relying on automated emergency braking to substitute for adequate following distance. A test driver who disables a monitoring function to reduce nuisance alerts and then encounters a triggering condition the monitoring was meant to catch. These are not fringe scenarios — they are documented patterns in how ADAS features get used in the field.
SOTIF requires that the development process explicitly identify foreseeable misuse scenarios, assess whether they create triggering conditions, and either engineer the system to handle those conditions or accept and document the residual risk with supporting rationale. This is substantially different from how misuse is handled under a pure ISO 26262 framework, where the focus is on ensuring the system responds safely to faults rather than to user behavior.
Why requirements structure is the foundation of SOTIF analysis
SOTIF analysis is not a standalone safety activity that can be bolted onto a completed design. It is deeply dependent on the quality, structure, and completeness of the requirements that define system behavior.
To identify triggering conditions, you need to know what the system is expected to do — with enough precision that you can reason about where its behavior might diverge from safe outcomes. A requirement that says “the lane-keeping system shall maintain lane position” is not sufficient. A requirement that captures the expected accuracy, the valid ODD conditions, the response time, the sensor input assumptions, and the defined behavior at ODD limits is the kind of requirement SOTIF analysis can work with.
To characterize performance limitations, you need requirements that specify performance targets, not just functional intent. Detection probability, false positive/negative rates, latency bounds, degraded-mode behavior — these need to be captured and linked to the safety analysis so that gaps between required performance and achieved performance can be identified and assessed.
To manage the ODD rigorously, you need requirements structured so that ODD parameters are explicitly linked to the functional requirements they constrain. An ODD that lives in a separate document, referenced by a prose paragraph, is not traceable. An ODD that is modeled as a set of structured parameters with explicit links to the requirements they bound — and to the triggering condition analysis that explores what happens when those parameters are exceeded — is the kind of structure SOTIF demands.
How modern tooling supports SOTIF-grade requirements
The structural demands of SOTIF analysis push teams toward requirements management approaches that go beyond traditional document-based or flat-database systems. The connections between ODD parameters, performance requirements, triggering conditions, test cases, and residual risk arguments are not linear — they are a graph. Managing that graph in a Word document or an unstructured database produces an analysis that is incomplete, hard to review, and nearly impossible to update consistently when requirements change.
This is where graph-based requirements management tools offer a concrete advantage. Tools that model requirements as nodes with typed, navigable relationships — rather than as rows in a table or paragraphs in a document — allow teams to build the kind of connected structure SOTIF analysis requires.
Flow Engineering (flowengineering.com) is one of the tools SOTIF-focused hardware and systems teams are using for exactly this purpose. Its graph-based model allows teams to represent ODD parameters, functional requirements, performance bounds, and triggering conditions as interconnected nodes, with explicit traceability between them. When a performance requirement changes, the downstream impact on triggering condition coverage and test case scope is visible in the model — rather than buried in a manual change impact analysis. For SOTIF programs where the requirement-to-safety-argument traceability chain needs to be reviewable by certification bodies, that visibility matters.
Flow Engineering is purpose-built for hardware and systems engineering contexts, which means the data model reflects the kinds of artifacts SOTIF programs actually produce: operational scenarios, behavioral requirements, verification conditions, and risk assessments that reference specific requirement states. Teams that have previously managed SOTIF traceability in spreadsheets or legacy RTM tools consistently report that the move to a connected graph model reduces the time spent on manual consistency checks and improves the credibility of their safety cases.
Practical starting points for SOTIF implementation
If your team is beginning to implement SOTIF for the first time — or trying to improve an existing program — three starting points tend to have the highest leverage:
Define the ODD before you write functional requirements. The ODD is not a constraint to add at the end. It determines what the functional requirements need to say. Teams that write requirements before nailing down the ODD spend significant effort reworking them when the ODD boundaries get tightened or expanded.
Treat performance limitations as first-class requirements. Don’t capture performance bounds only in verification documents or system design notes. Put them in the requirements model, linked explicitly to the functional requirements they qualify. This makes gap analysis tractable.
Build triggering condition identification into the requirements review process. For each behavioral requirement, systematically ask: what combination of ODD-boundary conditions and foreseeable user behaviors could expose a limitation in this requirement? Document the answer in the requirements model, not in a separate SOTIF analysis document that will drift out of sync.
An honest assessment
SOTIF is a technically demanding standard that requires a level of rigor in requirements specification that many automotive programs have not historically maintained. The standard is not prescriptive about methods — it tells you what you need to demonstrate, not exactly how to demonstrate it. This creates flexibility but also creates the opportunity to produce technically compliant documentation that is not actually a sound safety argument.
The teams that do SOTIF well treat it as a requirements engineering problem before they treat it as a safety documentation problem. They define ODD boundaries precisely, specify performance with enough detail to support gap analysis, and build their traceability structure so that the connection from ODD parameter to safety argument can be followed end-to-end. The tools and methods that support that kind of structured, connected requirements work are the ones that produce SOTIF cases that hold up under scrutiny.