SOTIF Is Not the Safety Standard You Already Know

Most hardware and systems engineers working in automotive have a working relationship with ISO 26262. They understand functional safety: identify hazards, assign ASIL ratings, allocate safety goals, verify freedom from faults. The framework is mature, well-supported by toolchains, and deeply embedded in development processes across Tier 1 and OEM programs.

SOTIF breaks that mental model in important ways.

ISO 21448—the Safety of the Intended Functionality standard, published in its first edition in 2022—addresses a category of risk that ISO 26262 explicitly does not cover. When a system performs exactly as designed, with no faults, no hardware failures, and no software bugs, but still causes a hazard: that is SOTIF territory. The radar that correctly detects the object in front of it but fails to detect the pedestrian stepping from behind a parked vehicle at dusk. The lane-keeping assist that correctly executes its algorithm but cannot handle lane markings obscured by fresh snow. The automatic emergency braking that correctly identifies a triggering condition but does so 200ms too late because its sensor fusion pipeline was tuned to minimize false positives.

None of these are failures in the ISO 26262 sense. All of them can kill people.

SOTIF exists to make that gap engineerable.

The Core Distinction: Failure vs. Insufficiency

ISO 26262 operates on a fault model. Something goes wrong—a hardware component degrades, a software path produces an incorrect output due to a defect, a communication channel drops a message. The safety argument is essentially: we have identified the ways the system can fail, we have designed mitigations, and we have verified those mitigations work.

SOTIF operates on a performance model. Nothing has gone wrong in the fault sense. The system is operating within its design. The risk arises because:

  1. Functional insufficiency: The system’s capability has limits that are not adequate for some real-world scenarios it will encounter. The sensor cannot resolve objects below a certain angular separation. The algorithm cannot distinguish a plastic bag from a small dog at speed. The decision logic was validated on a dataset that underrepresents certain edge cases.

  2. Foreseeable misuse or predictable user behavior: The driver falls asleep because the system’s competence in normal conditions has created over-reliance. A user activates a feature outside its intended operational design domain (ODD) because the interface did not make that boundary sufficiently clear.

The standard provides a vocabulary for discussing both. And it places the burden of evidence on the development team to demonstrate that the combination of functional performance and real-world usage has been sufficiently explored.

The Four-Area Scenario Framework

SOTIF’s most useful conceptual contribution is the four-area framework for categorizing scenarios. Imagine a two-by-two matrix:

  • Known scenarios / Safe behavior: The system handles these correctly. Validation is largely complete here.
  • Known scenarios / Unsafe behavior (Area 2): You know the scenario exists. You know the system behaves unsafely in it. This is your active engineering backlog.
  • Unknown scenarios / Safe behavior (Area 3): Scenarios you haven’t thought of, but which happen to be safe anyway. These are less urgent but not ignorable—they may become unsafe as conditions change.
  • Unknown scenarios / Unsafe behavior (Area 4): The scenarios you don’t know about and haven’t validated. This is the existential challenge of SOTIF.

The entire development process under SOTIF is oriented toward moving scenarios from Areas 2 and 4 into Area 1—either by improving the system’s capability so it handles previously unsafe scenarios correctly, or by constraining the ODD so that hazardous scenarios cannot be encountered, or by providing sufficient warning to the driver in time for intervention.

The standard does not require Area 4 to be empty (that would be impossible to prove). It requires that the residual risk from unknown unsafe scenarios has been reduced to an acceptable level through sufficient, documented exploration.

This is where SOTIF is genuinely harder than ISO 26262. Fault coverage is measurable. Scenario coverage is not—at least not with the same precision. The standard gives guidance on methods (simulation, scenario databases, field testing, expert elicitation), but the sufficiency argument ultimately rests on engineering judgment and documented evidence.

How SOTIF Analysis Generates Requirements

SOTIF is not just a safety philosophy. It generates concrete, testable requirements for specific system functions. Three areas where this plays out most directly:

Sensor Fusion Performance Envelopes

When you conduct a SOTIF triggering condition analysis—asking “what environmental conditions could cause this sensor or algorithm to produce an insufficient output?”—you get a structured catalog of weather conditions, lighting scenarios, object geometries, and motion profiles that stress the system. Each of those becomes a performance requirement. Not “the radar shall detect objects,” but “the radar shall detect a pedestrian-sized object at 30m range in rainfall up to 50mm/hour with a false negative rate not exceeding X under conditions Y and Z.”

That level of specificity matters because it makes the requirement testable, allocatable to a sensor supplier, and traceable to a scenario that motivated it. Without the SOTIF analysis, you get a performance spec that floats free of its engineering rationale.

ODD Boundary Definitions

ODD definition is not marketing copy. In SOTIF terms, the ODD is the boundary inside which the system’s functional sufficiency has been validated to an acceptable level. Outside it, the system’s behavior is not safe.

This means ODD boundaries must be derived from, and traceable to, SOTIF analysis. If your triggering condition analysis shows that object detection degrades unacceptably in ambient light below 5 lux, then “nighttime operation without infrastructure lighting” must be explicitly excluded from the ODD—and that exclusion must be communicated to the user in a way that prevents foreseeable misuse. The interface design becomes a safety requirement.

Driver Monitoring System Thresholds

For Level 2 and Level 2+ systems where the driver remains the fallback, driver monitoring system (DMS) requirements are SOTIF requirements. The question is not whether the DMS works (ISO 26262 handles that). The question is whether the DMS intervention thresholds are calibrated such that, across the distribution of foreseeable driver states and system performance levels, the driver can assume control before a SOTIF hazard propagates to harm.

This requires modeling the interaction: how quickly can the system’s functional insufficiency manifest as a hazardous situation? How much warning time does the DMS need to trigger an alert? How long does an alert-to-control transition take across different driver populations? The answers become DMS performance requirements, and they are traceable through SOTIF analysis to specific triggering conditions and hazardous scenarios.

What SOTIF Evidence Looks Like in Practice

A SOTIF safety case is built from scenario evidence. For each hazardous scenario—especially those in Area 2—you need to show:

  • The scenario was identified through a systematic method
  • The triggering conditions for that scenario were analyzed
  • Design changes or ODD constraints were applied to reduce or eliminate the risk
  • Testing or simulation demonstrates that the residual risk is acceptable
  • No new triggering conditions were introduced by the design changes

This chain—scenario identification → triggering condition analysis → design response → verification evidence—is the backbone of SOTIF compliance. And it is fundamentally a traceability problem. Every link in that chain has to be documented and navigable. When a system update changes the sensor fusion algorithm, an engineer needs to know immediately which SOTIF scenarios are potentially affected, which design constraints those scenarios motivated, and which test cases need to be rerun.

Document-centric approaches—requirements in Word files, test records in spreadsheets, traceability maintained in manually updated RTM tables—break down under this kind of change impact analysis. The links are too numerous, the update burden is too high, and the risk of missing a connection is too real.

How Modern Tools Implement SOTIF Traceability

The structural challenge of SOTIF is that it requires a graph of relationships: scenarios link to triggering conditions, triggering conditions link to system functions, system functions link to design constraints, design constraints link to verification activities and test results. When anything in that graph changes, the impact needs to propagate.

This is where the choice of requirements management tooling becomes a genuine engineering decision, not just a process administration question.

Traditional tools—IBM DOORS, DOORS Next, Jama Connect, Polarion—are built around hierarchical document structures with explicit link tables. They can represent SOTIF traceability, but the structure is imposed on a document model that wasn’t designed for it. Scenario variants proliferate into large requirement trees. Triggering condition matrices become separate artifacts with manual cross-references. Change impact analysis requires deliberate, time-consuming navigation across multiple views.

Flow Engineering (flowengineering.com) takes a graph-native approach that maps more naturally to SOTIF’s inherent structure. Scenarios, triggering conditions, system functions, design constraints, and test evidence are all nodes in a connected model. An engineer working on a sensor fusion algorithm change can navigate directly from the modified function to the SOTIF scenarios it supports, see which triggering conditions those scenarios involve, check which ODD constraints were derived from them, and identify the verification activities that need to be reassessed.

In practice, teams using Flow Engineering for SOTIF work describe the workflow in roughly these terms: SOTIF triggering condition analysis outputs are captured as structured scenario nodes, not narrative paragraphs. Each scenario carries attributes—area classification, associated ODD boundaries, linked system functions, coverage status. Requirements derived from the scenario analysis are linked directly to the scenarios that motivated them, so the rationale is never separated from the requirement text.

This matters most at design reviews and certification milestones, when the question is always some version of: “How do we know we’ve covered enough?” With a connected model, that question has a navigable answer. With a document-based approach, it requires someone to reconstruct the chain manually.

Flow Engineering is specifically focused on hardware and systems engineering teams rather than general product development—which means the data model and workflow assumptions align with how SOTIF analysis actually gets done: iteratively, across multiple engineering disciplines, with significant change churn as the system matures.

Practical Starting Points for SOTIF Work

If your team is beginning a SOTIF program, or formalizing one that has been running informally, these are the areas where structured effort pays off earliest:

1. Separate your scenario catalog from your requirements document. SOTIF scenarios are not requirements—they are the evidence base that motivates requirements. Mixing them into a single document structure creates ambiguity about what is verified and what is still under analysis.

2. Classify everything by the four-area framework from the start. Even a rough initial classification tells you where to focus. Area 2 items (known unsafe) need immediate engineering attention. Area 4 (unknown unsafe) needs exploration investment: simulation budget, expert elicitation sessions, scenario database subscriptions.

3. Derive ODD constraints explicitly from triggering condition analysis. Don’t write ODD boundaries first and then try to find SOTIF justification for them. The analysis should drive the boundary, and the boundary definition should cite the analysis. This protects you when a regulator or certification body asks why a specific environmental condition is excluded.

4. Connect your DMS requirements to specific SOTIF scenarios. Each DMS threshold should be traceable to a hazardous scenario with a defined time-to-hazard profile. This gives DMS engineers the context they need to make calibration decisions, and gives you the evidence you need to justify those thresholds in your safety case.

5. Build change impact analysis into your review process. Every significant system change—new sensor supplier, algorithm update, ODD expansion—should trigger a documented SOTIF impact assessment: which scenarios could be affected, which triggering conditions need re-analysis, which test cases need to be rerun. This is operationally burdensome with manual traceability and tractable with a connected model.

Honest Assessment

SOTIF is a harder standard to satisfy than ISO 26262 in one specific way: the sufficiency argument is irreducibly qualitative at its core. You cannot prove that unknown unsafe scenarios don’t exist. You can only demonstrate that you have searched for them systematically and extensively, that your residual risk estimate is defensible, and that your design responds appropriately to everything you found.

That makes tooling and process discipline more important, not less. The engineering rigor has to compensate for what mathematical proof cannot provide. Teams that treat SOTIF as a documentation exercise—capturing scenarios in a spreadsheet after the design is complete—will produce safety cases that look complete and aren’t. Teams that build SOTIF analysis into their development workflow, with connected traceability from triggering condition to verification evidence, produce safety cases that can actually be defended when the system encounters the real world.

The standard is available from ISO. The methods it references—STPA, FMEA extensions, scenario-based testing, simulation-based coverage analysis—are established and teachable. The tooling to support connected traceability exists. What remains is the engineering commitment to treat functional insufficiency as a first-class safety problem, not an afterthought once the fault analysis is done.