As vehicles take on more driving responsibility through Advanced Driver Assistance Systems (ADAS) and autonomous features, the safety question is shifting. Traditional functional safety covers what happens when hardware or software fails. Safety of the Intended Functionality (SOTIF) covers a different challenge: making sure the system performs safely even when every component works exactly as designed. An automatic braking system that mistakes a road marking for an obstacle is a SOTIF problem, and ISO 21448 gives teams a structured way to find and fix those gaps before vehicles reach the road.

SOTIF complements ISO 26262 and functional safety by covering hazard sources that traditional safety standards were never built to address. This guide covers SOTIF’s core concepts, its relationship to ISO 26262, and the lifecycle process for achieving compliance.

What Is SOTIF?

SOTIF, defined in ISO 21448:2022, is a standard for reducing hazards that come from design limitations and predictable misuse rather than component failures. A camera sensor that works correctly but can’t detect a pedestrian in heavy rain is one example. A driver who over-relies on a Level 2 system and stops paying attention is another. In both cases, the hazard comes from the gap between what the system was designed to handle and what actually happens on the road.

The standard started as a planned extension of ISO 26262 but grew into its own document. The current version, published in 2022, covers Society of Automotive Engineers (SAE) automation Levels 1 through 5 and requires field monitoring after deployment.

Where SOTIF Applies

The standard applies to any system where safe operation depends on sensors and algorithms reading the environment correctly. That includes ADAS features like automatic emergency braking, lane keeping, and adaptive cruise control at SAE Levels 1 through 5. It does not cover hardware or software faults (that’s ISO 26262) or cybersecurity threats (that’s ISO/SAE 21434).

SOTIF vs. ISO 26262

Both standards aim to reduce risk in automotive systems, but they cover different types of hazards:

• ISO 26262 (functional safety): Covers what happens when something breaks. A radar sensor fails, a software bug sends the wrong command, or a circuit degrades over time. Teams assign a safety integrity level (ASIL) based on severity and define diagnostic coverage accordingly.
• ISO 21448 (SOTIF): Covers what happens when everything works but the design falls short. The braking system functions correctly but doesn’t detect a pedestrian in heavy rain. Every component operates as specified, but the specification didn’t account for that scenario.

A system can be fully ISO 26262 compliant and still have unaddressed SOTIF risks. The two standards are addressed through separate compliance arguments, and together they form a more complete safety case.

Core Concepts Behind SOTIF

Before getting into the lifecycle process, it helps to understand three concepts that come up throughout the standard.

Functional Insufficiencies and Triggering Conditions

ISO 21448 defines two types of design gaps. The first is when the specification itself is incomplete or wrong. The second is when the spec is fine but the system can’t meet it under all conditions, like a camera that misses pedestrians in low-contrast lighting.

A functional insufficiency is activated by a triggering condition. Weather, lighting, unusual road features, or driver behavior can all produce a hazardous output at the vehicle level.

The Four Scenario Categories

ISO 21448 classifies all scenarios along two axes, knowledge and hazard, into four areas. Each area drives a different type of engineering activity:

• Area 1, known and not hazardous: Normal operation in well-understood conditions. This is the target state where teams want to keep as many scenarios as possible.
• Area 2, known and hazardous: Scenarios identified as causing hazardous behavior. These are the primary target for design improvement, because the team knows about them and can act on them directly.
• Area 3, unknown and hazardous: Scenarios that cause hazardous behavior but haven’t been identified yet. Broad validation campaigns are the main tool for finding and moving these into Area 2.
• Area 4, unknown and not hazardous: Scenarios that are safe but not yet documented. These may migrate to Area 1 as knowledge grows.

The goal of all SOTIF activities is to reduce the risk in Areas 2 and 3 until residual risk meets acceptance criteria. This makes it a continuous process, not a one-time certification event.

Operational Design Domain (ODD)

The ODD is the set of conditions your system is designed to operate in: speed ranges, weather limits, road types, lighting, and geography. Everything inside the ODD is subject to SOTIF analysis. Everything outside it is not. If your analysis shows risks you can’t control, narrowing the ODD (for example, limiting operation to dry roads or speeds below 60 mph) is a recognized way to bring residual risk down.

The SOTIF Lifecycle Process

The SOTIF lifecycle is iterative by design, with feedback loops between hazard analysis, design measures, and verification activities. Teams move back and forth between identifying hazardous scenarios, refining the design, and gathering evidence that residual risk is acceptable.

Hazard Analysis and Risk Assessment

Traditional HARA under ISO 26262 focuses on what could happen if a component fails. SOTIF HARA shifts that lens to scenarios where the system works correctly but the environment exceeds its performance envelope. Risk parameters like severity, exposure, and controllability are applied to triggering events instead of failure modes. Clauses 6 and 7 of the standard govern this process.

Identifying Triggering Conditions

Clause 7 covers how teams systematically find the conditions that activate design gaps. Common methods include system-level safety analysis, component-level failure analysis, fault trees, and simulation. The ASAM overview provides additional context on how these methods fit together.

Setting Safety Goals and Acceptance Criteria

The standard (Clause 8) does not prescribe a specific residual risk number. Instead, teams draw on four principles to set their own acceptance criteria:

• GAMAB (Globally At Least as Good): Risk must be no worse than comparable existing systems.
• ALARP (As Low As Reasonably Practicable): Reduce risk until further reduction would cost far more than the safety benefit.
• Positive Risk Balance: The system must prevent more harm than it introduces.
• MEM (Minimum Endogenous Mortality): The system should not meaningfully increase a person’s overall mortality risk.

These criteria need to be locked down before verification and validation begins.

Design and Development Measures

For Area 2 scenarios (Clause 9), teams reduce residual risk through technical changes to the system design: sensor redundancy, algorithm improvements, ODD restrictions, and driver monitoring enhancements. The standard also requires field monitoring infrastructure to be designed in before deployment, so teams can keep collecting data on triggering conditions after the vehicle reaches the road.

Verification and Validation Under SOTIF

SOTIF splits V&V into two tracks. The first evaluates known scenarios through targeted testing (Clause 10). The second uses statistical methods to estimate residual risk from scenarios the team hasn’t identified yet (Clause 11). You need both to build a complete safety argument.

Scenario-Based Testing and Simulation

SOTIF testing uses three levels of scenario abstraction: abstract scenarios define the situation, logical scenarios add parameter ranges, and concrete scenarios specify exact values for execution. Testing spans Software-in-the-Loop (SIL), Hardware-in-the-Loop (HIL), and vehicle-level environments. At higher automation levels, simulation is the only practical way to reach statistically meaningful scenario coverage.

Field Testing and Validation

The validation campaign must be sized for statistical confidence, meaning any hazardous scenario type exceeding a defined frequency threshold should appear in the dataset with sufficient probability. Most programs combine physical driving data with simulation results to get there. After deployment, Clause 13 requires ongoing field monitoring that feeds real-world data back into the analysis loop, so new triggering conditions get classified and addressed.

Residual Risk and the Release Decision

The release decision (Clause 12) distributes the vehicle-level acceptance criterion across individual scenario categories, with each carrying its own residual risk allocation. Development evidence and validation evidence must be kept statistically independent, so the data used to build the system cannot also be used to validate it.

Common SOTIF Implementation Challenges

Most ADAS and autonomous driving programs run into the same friction points when implementing SOTIF:

• Sensor performance limits: Adverse weather and low-contrast conditions degrade camera and radar output even when the hardware works correctly. Sensor fusion (combining LiDAR, radar, and camera) and ODD restrictions help, but characterizing every edge case is time-intensive.
• AI and ML decision-making gaps: A single missed detection might not cause a problem, but when the same error happens repeatedly as a vehicle closes in on an obstacle, it can lead to a collision. ISO/PAS 8800, published in December 2024, complements ISO 21448 with safety guidance specifically for AI-based systems.
• Foreseeable driver misuse: One Level 2 system was linked to at least 13 fatal crashes where drivers over-relied on automation. ISO 21448 explicitly treats these as specification insufficiencies at the human-machine interface level.

What all three challenges share is a need for strong traceability between ODD definitions, triggering conditions, design decisions, and validation evidence. When those connections break, gaps stay hidden until a test or an audit forces them into the open. Jama Connect® is a requirements management and traceability platform that helps teams keep those artifacts linked as they evolve across the SOTIF lifecycle.

How to Build a Strong SOTIF Safety Case

A well-built safety case is what gets your system through the release decision. Clause 12 requires a structured argument showing that residual risk across all scenario categories meets the acceptance criteria you defined earlier. The safety case pulls together evidence from every stage: HARA results, triggering condition analyses, design measure rationale, and V&V reports demonstrating that Areas 2 and 3 have been reduced to acceptable levels.

The key structural requirement is that development evidence (the work you did to identify and fix hazards) stays separate from validation evidence (independent testing that confirms your fixes hold). That separation is what gives the argument its weight, because validation data that wasn’t used during development provides a genuine independent check.

Getting Started With SOTIF Compliance

If you’re starting SOTIF work on a new ADAS or autonomous driving program, the most important thing is to begin hazard analysis and scenario classification early, before design decisions lock in assumptions that are expensive to revisit. Define your acceptance criteria, build your ODD, and set up traceability between scenarios, design measures, and validation evidence from the start. Teams that treat the safety case as something they assemble at the end consistently spend more time and money than teams that build it as they go.

Jama Connect offers a free 30-day trial that includes Live Traceability™ across your full SOTIF artifact chain, connecting ODD specifications, triggering conditions, design measures, and V&V evidence in one place.

Frequently Asked Questions About SOTIF

What is the difference between SOTIF and functional safety?

Functional safety under ISO 26262 covers what happens when hardware or software fails. SOTIF covers what happens when everything works correctly but the design doesn’t account for a specific scenario. The two standards require separate compliance arguments, and both are typically needed for any ADAS or autonomous driving program.

Does SOTIF apply to all levels of driving automation?

Yes, from Level 1 driver assistance through Level 5 full autonomy. The standard applies whenever a system depends on sensors and algorithms for situational awareness. Higher automation levels require deeper analysis, more rigorous ODD definitions, and more extensive field monitoring after deployment.

How do you validate that residual risk is acceptable under SOTIF?

Teams start by defining acceptance criteria, then classify scenarios into the four areas and apply targeted V&V to Areas 2 (known hazardous) and 3 (unknown hazardous). The final release argument must show that residual risk in each scenario category meets the defined threshold, with development evidence and validation evidence kept statistically independent.

Can a system be ISO 26262 compliant but not SOTIF compliant?

Yes. ISO 26262 covers component and system failures, but it doesn’t address scenarios where the sensor, algorithm, or driver interaction falls outside the design envelope. A complete safety case for any ADAS program needs both standards.