AD-20 — SOTIF (ISO 21448): Safety of the Intended Functionality

FACT — Published in 2018 (with its scope expanded in the 2022 edition), ISO 21448 adds a question that is critical to automotive safety engineering: AD-19 covered ISO 26262, which governs what happens when something in the system breaks — but what happens when nothing breaks, and the system still causes an accident while operating exactly as designed? A camera-based classifier, with no hardware fault present, can confidently misclassify an unusual object outside its training distribution. This is the domain of SOTIF (Safety of the Intended Functionality) — and as AI/ML-heavy perception systems have become central to ADAS/AD stacks, SOTIF has become just as central to the safety case.

In this lesson, you will learn:

1. Why ISO 26262 Is Insufficient on Its Own — the difference between a fault and a functional insufficiency.
2. SOTIF’s Scope and Which Automation Levels ISO 21448 Covers — from an L1-L2 focus expanding upward.
3. The Four-Area Scenario Framework — Known Safe, Known Unsafe, Unknown Unsafe, Unknown Safe.
4. Shrinking Area 3: The SOTIF Development and Verification Loop — and why “zero” can never be proven.
5. Triggering Conditions — the concrete environmental/scenario triggers that expose a performance insufficiency.
6. Case Study: A Rare Object Classification Failure — moving a scenario from Area 3 to Area 1/2.
7. ISO 26262 vs. SOTIF Side by Side, and Their Joint Role in the Safety Case.

---

1. Why ISO 26262 Is Insufficient on Its Own

In AD-19, we saw that ISO 26262 governs risk arising from the malfunctioning behavior of E/E systems — concrete, detectable fault events such as a short circuit, memory corruption, or a software lockup. But the most critical component of a modern ADAS/AD stack — the perception layer — can make a wrong decision without “malfunctioning” in that classical sense at all:

CRITICAL — Consider a camera-based object classifier: the camera hardware is sound, the image sensor is functioning correctly, the neural network compiles and runs without a code defect — in other words, there is no “fault” in the ISO 26262 sense whatsoever. Yet the network can still misclassify an unusual object it never saw in its training set (an overturned trailer, a truck carrying an oddly shaped load, an unusual animal in the roadway), or — as covered in AD-05 — fail to correctly process valid sensor data because of a physical sensor limitation (low sun glare, dense fog). The system is operating “exactly as designed” — the scenario coverage of that design is simply insufficient. This is, by definition, outside the scope of ISO 26262.

ISO 21448 (SOTIF — Safety of the Intended Functionality) exists precisely to close this gap: it evaluates whether the intended function itself (or the performance limits of the algorithms/sensors realizing it) can produce hazardous outcomes in the complete absence of a fault.

---

2. SOTIF’s Scope and Which Automation Levels It Covers

The first (2022) edition of ISO 21448 scoped itself primarily around L1 and L2 systems (driver assistance functions where the driver retains continuous supervisory and takeover responsibility) — because at these levels, the assumption that “the human driver is the final safety net” still holds, at least in part. But because complex perception/decision algorithms play just as central a role in L3-L5 systems, SOTIF methodology in industry practice and in ongoing standards work is increasingly being extended to higher automation levels.

ASSUMPTION — The precise scope of ISO 21448’s applicability to higher automation levels (L3+) and the content of future revisions depend on the standards committee’s ongoing work; the “L1-L2-focused, expanding upward” framing given in this lesson is a conceptual summary — consult the official ISO 21448 text for the current edition and scope boundaries.

---

3. The Four-Area Scenario Framework

At the heart of ISO 21448 is a conceptual model that partitions the space of all possible driving scenarios ($\Omega$) into four areas:

SOTIF Four-Area Scenario Framework:

                    KNOWN                    UNKNOWN
                 ┌───────────────────────┬───────────────────────┐
   SAFE          │                       │                       │
                 │   AREA 1              │   AREA 4              │
                 │   Known Safe          │   Unknown Safe        │
                 │   (verified,          │   (not yet discovered,│
                 │   safe scenarios)     │   but harmless)       │
                 ├───────────────────────┼───────────────────────┤
   UNSAFE        │                       │                       │
                 │   AREA 2              │   AREA 3              │
                 │   Known Unsafe        │   Unknown Unsafe      │
                 │   (known, managed via │   ★ MOST DANGEROUS ★  │
                 │   ODD/functional      │   (not yet discovered,│
                 │   restriction)        │   and hazardous)      │
                 └───────────────────────┴───────────────────────┘

        Goal of the SOTIF development loop: systematically shrink
        Area 3, moving scenarios into Area 2 or Area 1.

Area	Knowledge State	Safety State	Example	Engineering Response
Area 1 — Known Safe	Known	Safe	Clear-weather cruising on a well-marked, straight highway	Verified operational envelope; the goal is to grow this area
Area 2 — Known Unsafe	Known	Unsafe	Dense fog known to blind the sensor suite; an intersection geometry outside the ODD	Function is restricted/disabled under these conditions (ODD limitation)
Area 3 — Unknown Unsafe	Unknown	Unsafe	An edge-case combination engineers never anticipated or tested	SOTIF’s primary target: systematic scenario discovery shrinks this area, moving scenarios into Area 2 (known and managed)
Area 4 — Unknown Safe	Unknown	Safe	An untested scenario that, in fact, poses no risk	Moves into Area 1 as verification coverage expands; carries no risk but consumes verification effort

INTERPRETATION — This is precisely where the core philosophical difference from ISO 26262’s more deterministic, fault-tree-based approach lies: in ISO 26262, an “unknown fault mode” is a finite set that FMEA/FTA systematically works to discover; in SOTIF, Area 3 is, by definition, a potentially unbounded scenario space that is unknown in advance. SOTIF therefore cannot claim a certainty like “Area 3 = 0” — it can only commit to shrinking it systematically and measurably.

---

4. Shrinking Area 3: The SOTIF Development and Verification Loop

The SOTIF process resembles ISO 26262’s V-Model but is fundamentally iterative, because the goal is managing an unprovable negative (that Area 3 is empty):

The SOTIF Loop (Iterative):

  1. Functional/Scenario Analysis
     (Enumerate known triggering conditions)
              │
              ▼
  2. Risk Assessment
     (Which scenarios fall into Area 2/3?)
              │
              ▼
  3. Verification & Validation (Simulation, Field, HIL)
     ── New edge cases are discovered ──►  Area 3 → Area 2 (now a known constraint)
              │
              ▼
  4. Field Monitoring
     ── Rare events observed in production ──►  New entry points into Area 3
              │
              └──────────────► back to Step 1 (loop repeats with new information)

The concept of acceptable residual risk can be formalized as follows: given the total scenario space $\Omega = A_1 \cup A_2 \cup A_3 \cup A_4$, as verification effort grows,

$\lim_{T \to \infty} |A_3(T)| = \varepsilon, \qquad \varepsilon > 0$

— that is, even as test/simulation time ($T$) grows without bound, it cannot be proven that Area 3’s size reaches exactly zero. The goal of SOTIF engineering is to shrink $\varepsilon$ down to a socially/regulatorily acceptable residual risk level. This is a fundamentally different assurance logic than ISO 26262’s quantitative, “provable” targets like PMHF.

---

5. Triggering Conditions

In SOTIF scenarios, the accident is not initiated by a hardware fault but by a specific Triggering Condition — a particular environmental or operational circumstance that exposes a performance insufficiency:

• Unusual lighting/weather combinations: A low-angle sunset sun + wet asphalt reflection + oncoming headlight glare all coinciding at once — none of which individually causes a problem in isolated testing, but whose combination exceeds camera dynamic range (see AD-04, §2.3) as an edge case.
• Object classes underrepresented in training data: Unusual vehicle types (a long agricultural load trailer), rarely seen animals, roadway debris — object categories the network has never “seen” can be confidently, and wrongly, classified.
• Moments where sensor physical limits intersect: Dense fog + simultaneous LiDAR degradation from backscatter + radar mistakenly filtering out a static object (a parked truck) — three individually manageable weaknesses coinciding at the same moment.

EXAMPLE — A white tractor-trailer, under bright midday sun against an overcast sky background, can have nearly the same brightness/color values as the sky itself. The camera hardware is sound, the classification code has no defect — but due to insufficient optical contrast, the neural network may interpret the trailer as “clear road/sky.” This is a classic SOTIF scenario: no fault occurred, only a physical limit of visual perception was exposed. Mitigation runs through cross-validating this ambiguity with radar’s and LiDAR’s independent range measurements (sensor fusion, AD-07) — not relying on a single modality.

---

6. Case Study: A Rare Object Classification Failure

EXAMPLE — An OEM’s perception team, reviewing production fleet field telemetry, notices that a horse trailer parked on a highway shoulder is flagged with low confidence as an “unknown object” in some camera frames. This scenario had never appeared in any test set before — meaning it sat in Area 3 until it surfaced in production.

The SOTIF loop engages: (1) the event is captured through field monitoring, (2) engineers reproduce the scenario in simulation and real-world driving and analyze the root cause (the training data lacked, or underrepresented, horse-trailer examples), (3) the dataset is expanded and/or the radar-camera fusion logic’s confidence threshold is tuned for this object class, (4) the new scenario is added to the regression test suite.

Result: the scenario has now moved into Area 2 (Known Unsafe → managed) or, with sufficient improvement, into Area 1 (Known Safe). But closing this one incident does not mean Area 3 is now empty — only that this specific triggering condition now belongs to the known set. This iterative discover-and-close loop is exactly why SOTIF is directly intertwined with the edge-case engineering we cover in AD-24: SOTIF’s strategic framework is operationalized by AD-24’s tooling (rare-event mining, synthetic scenario generation, fleet-scale field monitoring).

---

7. ISO 26262 vs. SOTIF, Side by Side

Dimension	ISO 26262 (AD-19)	ISO 21448 — SOTIF
Core Question	“What happens if something breaks?”	“What happens if a wrong decision is made without anything breaking?”
Root Cause	Random hardware fault, systematic software bug	Sensor physical limitation, algorithmic generalization gap, human misuse
Analysis Tool	HARA → ASIL (S/E/C matrix)	Scenario analysis → four-area framework (shrinking Area 3)
Assurance Logic	Quantitative, provable targets (PMHF, SPFM, LFM)	Iterative residual-risk management; “zero” can never be proven
Typical Mitigation	Redundancy, lockstep, watchdogs, ASIL decomposition	Sensor fusion, ODD restriction, field monitoring, synthetic/real data expansion
Primary Layer of Concern	Hardware, power electronics, embedded software	Perception, decision-making, ML models

CRITICAL — A complete safety case requires both standards; neither substitutes for the other. A perception system that passes ISO 26262 but has never undergone SOTIF analysis can still strike a pedestrian without experiencing a single “fault” — because, by ISO 26262’s own definition, that event isn’t a fault at all, merely an insufficiency in the system’s intended function.

---

Frequently Asked Questions (FAQ)

Q: Does SOTIF only concern camera/perception systems?

INTERPRETATION — Predominantly yes, since the notion of a performance insufficiency shows up most visibly in ML-based perception layers. But in principle SOTIF applies to any “fault-free but insufficient” behavior — e.g., a planning algorithm making a decision that is logically valid but practically hazardous under a rare, legal-but-unusual combination of traffic rules also falls within scope.

Q: How much testing is enough to shrink Area 3?

WARNING — There is no precise numerical answer to this, and it is one of SOTIF’s most debated aspects. Mileage-based test targets (e.g., “X million km driven”) are not considered sufficient on their own, because the probability of rare/critical scenarios naturally appearing in random driving is very low — which is why targeted scenario-based testing, synthetic data generation, and field monitoring are complementary to mileage testing, not a substitute for it.

Q: Are SOTIF and ISO 26262 run by the same team?

FACT — Usually not; they require different expertise. ISO 26262 teams typically come from a classical hardware/system reliability engineering background, while SOTIF teams often come from machine learning validation, data science, and simulation engineering backgrounds. Coordination between the two teams is nonetheless critical, since some mitigations (e.g., sensor fusion) serve both standards’ objectives simultaneously.

---

Summary

• SOTIF closes the gap left by ISO 26262’s fault-driven framework: a system can produce a hazardous outcome without experiencing any fault, purely because of the performance limits of its intended function (sensor physical constraints, ML generalization gaps).
• The full scenario space is partitioned into four areas: Area 1 (Known Safe), Area 2 (Known Unsafe, managed via ODD), Area 3 (Unknown Unsafe — the most dangerous), Area 4 (Unknown Safe).
• The SOTIF development process is iterative: scenario analysis, risk assessment, verification, and field monitoring continuously move scenarios from Area 3 into Area 2/1 — but Area 3 being fully empty can never be proven, only its residual size ($\varepsilon$) reduced to an acceptable level.
• Typical SOTIF triggers: unusual lighting/weather combinations, object classes underrepresented in training data, and multiple sensor weaknesses coinciding simultaneously.
• SOTIF is the strategic framework behind the edge-case engineering covered in AD-24; together they form the discipline of systematically discovering and mitigating rare, previously unforeseen driving situations.

Sources and Verification Note

This lesson is grounded in ISO 21448:2022 (Road vehicles — Safety of the intended functionality), its complementary standard ISO 26262:2018, and SAE J3016 terminology. The four-area framework and the residual-risk formalization are an educational interpretation of the standard’s general conceptual structure; statements about ISO 21448’s expanding scope toward higher automation levels (L3+) are marked ASSUMPTION — consult the official standard text for the current edition and scope boundaries. The horse-trailer case study is a conceptual illustration and does not reference a specific manufacturer incident.

Next Lesson

• AD-21 — Automotive Cybersecurity: ISO/SAE 21434, TARA and UNECE R155/R156: Having covered faults (AD-19) and functional insufficiencies (AD-20), we now turn to the third and final hazard lens — deliberate, malicious interference. We examine how the very same braking/steering systems can be intentionally targeted by an attacker, and the regulatory framework built to govern that risk.