What Is SOTIF? A Systems Engineer’s Guide to ISO 21448

Imagine a lane-keeping assist system that functions exactly as its designers specified. No transistor fails. No software exception is thrown. Every component behaves precisely within its rated tolerances. And yet, in a specific lighting condition on a curve with faded markings, the system confidently applies corrective steering and puts the vehicle in the opposing lane.

No failure occurred. The system did what it was designed to do. The design itself was the hazard.

This is the problem ISO 21448 — the Safety of the Intended Functionality standard, universally abbreviated SOTIF — was created to address. Published by ISO in 2022 after years of development, SOTIF fills a gap that ISO 26262 (functional safety) was never intended to cover.

Why ISO 26262 Isn’t Enough

ISO 26262 is the foundational functional safety standard for road vehicles. Its logic is well-understood: identify hazards, assess risk, assign Automotive Safety Integrity Levels (ASILs), and demonstrate through design and verification that the probability of hazardous failures is acceptably low. The standard’s entire analytical machinery — FMEA, FTA, diagnostic coverage metrics — is oriented around component and system failures.

That framing works well when the hazard is “the brakes fail to apply.” It works poorly when the hazard is “the perception system confidently misclassifies a stopped emergency vehicle as a guardrail in backlit conditions.” The second scenario involves no failure. The sensors are working. The classifier is running. The software is executing. The design itself, when confronted with a foreseeable but challenging real-world condition, produces dangerous output.

SOTIF formalizes the recognition that performance limitations — insufficient discrimination, overconfidence in edge cases, sensitivity to environmental variation — are a distinct category of hazard. The standard applies specifically to systems with automated or assisted driving functionality (ADAS and ADS), where sensor-based perception and algorithmic decision-making can produce hazardous behavior without any component degrading.

The two standards are explicitly complementary. ISO 26262 handles: “What if this function fails to perform?” SOTIF handles: “What if this function performs, but the design isn’t adequate for what it encounters?”

Core Concept: The Four Scenario Quadrants

SOTIF organizes its analytical framework around a two-axis classification of scenarios. Understanding this is prerequisite to understanding everything else in the standard.

Axis 1: Known vs. Unknown. Has the engineering team identified this scenario, or is it outside the current awareness of the development program?

Axis 2: Safe vs. Unsafe. Does this scenario, when it occurs, lead to hazardous system behavior?

This produces four quadrants:

• Known, Safe: Scenarios the team has identified and verified produce acceptable behavior. The goal is to maximize coverage here.
• Known, Unsafe: Scenarios the team has identified that produce hazardous behavior. These require design changes, operational constraints, or mitigations.
• Unknown, Safe: Scenarios outside the team’s awareness that happen to be benign. These don’t require action but may become known through testing or field data.
• Unknown, Unsafe: Scenarios outside the team’s awareness that produce hazardous behavior. These represent residual risk — you can’t eliminate what you haven’t found.

The entire SOTIF workflow is, in essence, a disciplined program to move scenarios out of the “unknown” categories and into “known,” then eliminate or mitigate “known, unsafe” scenarios until residual risk falls to an acceptable level. The standard accepts that unknown unsafe scenarios cannot be reduced to zero; the acceptance criterion is that their contribution to overall risk is sufficiently small.

The SOTIF Workflow

Step 1: Define the Operational Design Domain

The Operational Design Domain (ODD) is the set of conditions under which the system is designed to operate: road type, speed range, lighting conditions, weather, geographic region, traffic density, and so on. The ODD is not a marketing statement — it is a formal engineering input.

SOTIF analysis is scoped to the ODD. Scenarios inside the ODD where the system fails to perform safely are SOTIF problems. Scenarios outside the ODD are handled by ODD exit procedures and user communication, not by SOTIF validation directly.

Getting the ODD right matters because it determines the scope of the entire safety argument. An ODD defined too narrowly excludes foreseeable real-world conditions and creates field risk. Defined too broadly, it demands validation coverage the team cannot reasonably achieve. The ODD boundary is itself a design decision with safety implications.

Step 2: Identify Triggering Conditions

Triggering conditions are the specific situational factors that cause the system to behave in ways that could be hazardous. For a camera-based perception system, triggering conditions might include: low sun angle directly into the camera, wet road reflections creating ghost lane markings, partial occlusion of a pedestrian by a vehicle door, construction zone lane markings that contradict permanent markings.

Identifying triggering conditions is a structured engineering activity, not a brainstorm. It draws on failure mode analysis of the perception pipeline, knowledge of sensor physics, review of prior incidents and near-misses in the domain, and systematic coverage of the ODD space. The output is a candidate list of scenarios that require evaluation — the raw material for the quadrant analysis described above.

Step 3: Evaluate Known Unsafe Scenarios

For each identified triggering condition that produces (or could produce) hazardous behavior, SOTIF requires both a severity assessment and an analysis of the causal chain. The questions are: How severe is the potential harm? How frequently might this triggering condition be encountered within the ODD? And what is the probability that the triggering condition leads to hazardous behavior given the current design?

This is where SOTIF intersects most directly with ISO 26262 methodology. Risk assessment uses the same severity, exposure, and controllability parameters that feed into ASIL determination — but the analytical target is performance inadequacy, not failure rate.

Design changes at this stage might include algorithm retraining, sensor fusion configuration changes, expanded ODD exclusions, or additional monitoring logic that triggers safe state transitions when sensor confidence falls below threshold.

Step 4: Address Unknown Unsafe Scenarios

You cannot enumerate what you haven’t discovered, but you can create systematic processes that surface unknown scenarios before they become field incidents. SOTIF calls for:

• Structured test coverage of the ODD, designed to stress the system across parameter ranges rather than just validating nominal conditions
• Simulation-based scenario generation that explores edge cases beyond what structured human analysis produces
• Field data collection and monitoring that flags unexpected system behavior for post-hoc analysis
• Functional insufficiency analysis that reviews the perception system’s inherent limitations and asks where those limitations could manifest as unsafe behavior

The acceptance criterion for residual unknown unsafe risk is not zero — it is sufficiently small relative to a reference risk level (typically the risk level of a comparable manually driven vehicle).

Step 5: Validation and the Safety Case

SOTIF requires a documented safety case that demonstrates the residual risk from both known and unknown unsafe scenarios is acceptable. This is not a checkbox. It is a structured argument supported by evidence from analysis, simulation, closed-course testing, and real-world driving.

The validation strategy must address the statistical challenge inherent in demonstrating sufficiency: rare events require large sample sizes to characterize. This drives heavy reliance on simulation and scenario-based testing methodologies, with real-world miles providing confirmation rather than serving as the primary evidence base.

How SOTIF Interacts with Functional Safety in Practice

In a real development program, SOTIF and ISO 26262 run in parallel, share inputs, and produce interleaved outputs. The hazard analysis and risk assessment (HARA) required by ISO 26262 identifies hazardous events and their risk levels. SOTIF analysis identifies which of those hazardous events can occur through performance limitations rather than component failures, and builds the additional analytical and validation layer accordingly.

Safety goals from ISO 26262 propagate into system requirements. SOTIF triggering conditions and mitigation strategies also propagate into system requirements — often the same requirements documents, sometimes the same requirements. A requirement that a perception system must trigger a safe state transition when confidence in lane detection falls below a calibrated threshold is simultaneously a SOTIF mitigation and a functional safety design element.

This overlap is where tooling matters. Safety arguments that exist in disconnected Word documents and spreadsheets become incoherent quickly when requirements change, sensor configurations evolve, or ODD boundaries are revised. The traceability chain from hazard to requirement to test case must survive revision.

Tracing SOTIF Through the System: Where Modern Tooling Helps

The analytical work described above generates significant structured data: triggering conditions, scenario classifications, risk assessments, mitigation measures, requirements, and test cases. In a SOTIF program of any meaningful scale — a production ADAS feature with a realistic ODD — this is hundreds of linked artifacts that must stay consistent with each other as the design evolves.

This is an area where AI-native requirements management tools built for systems engineering have demonstrated real operational value. Teams at automotive suppliers and OEMs are using tools like Flow Engineering to model SOTIF scenarios as graph-connected entities, tracing each triggering condition through hazard analysis into specific system requirements and onward to validation evidence. Because Flow Engineering’s underlying data model is graph-based rather than document-based, the impact of a design change — say, a revised ODD boundary that moves a previously excluded condition inside the scope of the system — propagates visibly through the trace graph. Engineers can see which requirements are affected, which test cases need to be updated, and where gaps in coverage exist.

The practical benefit is not just speed. It is argument integrity. A SOTIF safety case submitted to a certifying authority or customer engineering team needs to demonstrate that every identified unsafe scenario either has a mitigation reflected in requirements or has been assessed and accepted as residual risk within bounds. That argument is defensible when the links are explicit and traceable. It is not defensible when the traceability lives in a manually maintained RTM spreadsheet that was last updated three sprints ago.

Flow Engineering’s deliberate focus on systems engineering use cases — rather than trying to serve all software development workflows — means the tooling maps naturally onto the SOTIF workflow’s artifact structure. The trade-off is that teams needing deep integration with general-purpose issue trackers or software-centric CI pipelines may need to bridge that gap explicitly.

Practical Starting Points for SOTIF Programs

If your team is beginning a SOTIF analysis for the first time, three priorities will determine whether the program is analytically sound or a compliance exercise:

Invest in ODD definition before scenario analysis. A poorly defined ODD produces either an unmanageably large scenario space or a safety argument that doesn’t cover foreseeable operation. ODD definition is engineering work, not documentation work.

Build the triggering condition taxonomy with domain physicists, not just safety engineers. The people who understand sensor physics, environmental variability, and the failure modes of machine learning systems are the people who will find the scenarios that matter. Safety engineers structure the analysis; domain experts populate it.

Design your requirements structure to carry SOTIF provenance from the start. Retrofitting SOTIF traceability into a requirements baseline built for ISO 26262 alone is painful and error-prone. If your requirements management tool can represent SOTIF scenario-to-requirement links natively, use that capability from concept phase.

Honest Assessment

SOTIF is methodologically sound but operationally demanding. The standard correctly identifies a gap in the functional safety framework and provides a structured approach to filling it. The difficulty lies in the inherent challenge of characterizing unknown unknowns — by definition, you can’t be sure you’ve found enough of them.

For teams building perception-dependent ADAS and ADS features, SOTIF compliance is not optional, but compliance alone isn’t the goal. The goal is a design and validation program rigorous enough that the system performs safely across the conditions it will actually encounter. SOTIF gives you the framework. Operational discipline, domain expertise, and coherent tooling give you the argument.