ISO 21448 SOTIF Explained: Triggering Conditions, Scenarios, and What Safety Engineers Get Wrong

Why ISO 26262 Alone Isn't Enough for ADAS

ISO 26262 was designed to address failures of electrical and electronic systems — hardware faults, software bugs, systematic design errors. It does this well. But ADAS and automated driving systems introduce a category of hazard that ISO 26262 doesn't cover: the system performs exactly as designed, with no faults, and still causes harm.

A lane-keeping system that confidently steers into the adjacent lane because road markings were obscured by sun glare. An automatic emergency braking system that brakes unnecessarily at highway speed because a billboard image was misclassified. No hardware failed. No software crashed. The system did what it was designed to do — it just wasn't designed to handle that scenario.

This is the domain of ISO 21448: Safety of the Intended Functionality (SOTIF).

The Core SOTIF Distinction: Known vs. Unknown

SOTIF analysis divides the world into four regions (per ISO 21448 Figure 1):

Area 1: Safe and known — Scenarios where the system behaves correctly and safely. No action required.

Area 2: Unsafe and known — Scenarios where the system is known to behave unsafely (triggering conditions identified). These must be mitigated or validated out before release.

Area 3: Safe and unknown — Scenarios the development team hasn't considered where the system happens to behave safely anyway.

Area 4: Unsafe and unknown — The most dangerous region: scenarios not yet identified where the system will behave unsafely.

The objective of SOTIF validation is to demonstrate that Areas 2 and 4 are sufficiently small — that you've identified and mitigated the known unsafe scenarios, and that you have sufficient evidence to claim the unknown unsafe scenarios won't be encountered at a rate that creates unacceptable risk.

What Is a Triggering Condition?

A triggering condition is a scenario element that causes the intended functionality to produce an unsafe output. It's not a fault. It's a legitimate real-world situation where the system's performance envelope is exceeded or where the system misinterprets valid sensor data.

Examples for a camera-based ADAS function:

• Sun glare directly into the camera at dawn/dusk
• Lane markings obscured by snow, dirt, or construction tape
• Adversarial road markings (painted to confuse the classifier)
• Rare object types not well-represented in training data (unusual vehicle shapes, animals, debris)
• Sensor degradation from dirt accumulation on the lens

Triggering conditions are identified through:

• Systematic functional analysis of the ADAS function and its sensing chain
• Literature review of known failure modes from similar systems
• Field testing and simulation with out-of-distribution scenarios
• Machine learning model boundary analysis (where applicable)

SOTIF Hazardous Events Are Different from ISO 26262

In ISO 26262, a hazardous event is a malfunctioning behavior in an operational situation. In SOTIF, the hazardous event arises from the intended behavior in a triggering condition.

A key practical difference: SOTIF risk can often be mitigated by restricting the Operational Design Domain (ODD) — defining tighter conditions under which the function operates — rather than adding hardware redundancy.

The SOTIF Validation Argument

ISO 21448 doesn't provide a deterministic compliance checklist. It requires a sufficiency argument: you must demonstrate that your validation activities were extensive enough to give confidence that unknown unsafe scenarios are rare enough to be acceptable.

This argument typically rests on:

1. Scenario coverage metrics — What fraction of the anticipated ODD scenarios were exercised in simulation, on test track, and in field testing?

2. Functional safety requirements validation — Test evidence that the safety-relevant ADAS functions perform within specified bounds across the ODD.

3. Statistical argument from field data — For systems in fleet deployment, naturalistic driving data showing actual encounter rates and system performance.

4. Comparison to reference system — Demonstrating that the ADAS function performs at least as well as the reference (e.g., an attentive human driver) in the ODD.

The validation argument needs to be documented, traceable, and linked to specific triggering conditions. "We tested a lot" is not a SOTIF argument.

SOTIF and ISO 26262: Where They Overlap

Some scenarios generate both a SOTIF concern and a functional safety concern. A camera that degrades in rain may produce an unsafe output (SOTIF) and may also trigger a software fault detection mechanism that initiates a safe state (ISO 26262). The SOTIF analysis and the functional safety concept need to be consistent about what happens at the boundary.

ISO 21448 explicitly calls for consistency with ISO 26262: SOTIF requirements shall be considered together with functional safety requirements in the Technical Safety Concept, and SOTIF validation activities shall be coordinated with functional safety verification.

In a harmonized workflow, SOTIF scenarios link directly to ISO 26262 hazardous events, SOTIF mitigations trace to TSC requirements, and validation evidence covers both standards in a single record.

How ISO WIZ Handles SOTIF

ISO WIZ includes a dedicated SOTIF wizard that guides you through triggering condition identification, scenario categorization by area (1–4), SOTIF hazardous event documentation, mitigation and ODD restriction management, and validation completeness assessment. All SOTIF artifacts link bidirectionally to the related ISO 26262 safety goals and hazardous events, so cross-standard consistency is enforced by the platform — not by manual cross-checking.