The Four-Quadrant Model
ISO 21448 Clause 8 organizes the risk space into four quadrants based on whether a scenario is known or unknown and whether the system behavior in that scenario is safe or unsafe.
The development process for SOTIF is essentially a systematic effort to move scenarios from the "unknown" quadrants to the "known" quadrants, and to move known unsafe scenarios to safe through design changes or operational domain restrictions.
Known unsafe scenarios are the primary target of SOTIF design work. These are triggering conditions you have identified — through analysis, simulation, or testing — where the system's intended functionality produces an unsafe outcome. For a forward collision warning system, a known unsafe scenario might be: "large vehicle on a perpendicular approach at high speed in a low-light parking structure." The system's algorithm does not detect this configuration reliably, and a collision warning is not issued in time.
Unknown unsafe scenarios represent the residual risk — the scenarios you have not yet identified where the system will behave unsafely. SOTIF validation (Clause 9) is designed to quantify and reduce this residual by exposing the system to a sufficiently large and diverse set of scenarios. The goal is not to eliminate unknown unsafe scenarios (that is impossible) but to demonstrate that the remaining residual risk is acceptable.
Triggering Conditions: The Core SOTIF Concept
A triggering condition in ISO 21448 is a specific operational scenario — defined by environmental conditions, traffic situation, driver state, and system state — that causes the system's intended functionality to produce an unsafe output.
Triggering conditions have three components:
The functional insufficiency: The specific limitation in the system's design or algorithm that becomes relevant. For a camera-based pedestrian detection system: "detection recall drops below 85% when pedestrian contrast against background is less than 10%."
The scenario characteristics: The specific combination of conditions that activates the functional insufficiency. "Night time, road surface wet, pedestrian wearing dark clothing, approach angle less than 30 degrees from vehicle longitudinal axis."
The resulting system behavior: What the system does (or fails to do) when the triggering condition occurs. "Pedestrian detection not triggered; collision warning not issued; driver not alerted in time to brake."
The triggering condition catalog drives three downstream activities:
- Design iteration: Can the functional insufficiency be reduced or eliminated by improving the algorithm, adding a sensor modality, or increasing processing capability?
- ODD restriction: Can the triggering condition be excluded from the system's operational design domain — the defined set of conditions under which the system is intended to operate?
- Validation: Can the triggering condition be tested, and does the system behavior in that scenario meet the risk acceptance criteria?
What Safety Engineers Get Wrong
Confusing Triggering Conditions with Failure Modes
A triggering condition is not a failure mode. A failure mode is a deviation from specified behavior. A triggering condition is a scenario where specified behavior is insufficient.
Concretely: if a radar sensor has a specified range of 150 meters, a hardware fault that reduces the range to 80 meters is a failure mode — handled by ISO 26262. If the radar specification allows range degradation under wet conditions, and the system designer did not account for wet conditions in the ODD, then the wet condition scenario is a triggering condition — handled by SOTIF.
Many SOTIF analyses begin by listing hardware failure modes and calling them triggering conditions. This conflation wastes effort and misses the actual SOTIF risk.
Failing to Separate SOTIF Scope from ISO 26262 Scope
Every SOTIF-relevant system also has ISO 26262-relevant components. The camera module has a hardware fault rate. The processing SoC has a systematic fault potential. These are ISO 26262 concerns.
The SOTIF concern is the algorithm running on that SoC: what does it do when it is working perfectly, on fault-free hardware, but the input data contains a scenario it was not trained on?
Treating the ODD as a Legal Disclaimer
The Operational Design Domain is not a terms-and-conditions document that limits liability. It is an engineering boundary with safety consequences. If the system is designed and validated for ODD conditions A, B, and C, and a consumer uses the system in condition D, the system's behavior in condition D is unvalidated.
ISO 21448 Clause 5.3 requires that ODD conditions be specified with sufficient precision that they can be detected by the system or communicated to the driver. Specifying "dry roads only" is insufficient unless the system can detect road conditions or communicate them to the driver in a way that reliably prevents use in wet conditions. An ODD that cannot be enforced or communicated is not an adequate SOTIF risk control.
Skipping Field Data Feedback
ISO 21448 Clause 9 specifies field monitoring as a required activity — not an optional post-launch nice-to-have. The standard requires collection of operational data to identify triggering conditions not found during pre-launch validation (the "unknown unsafe" quadrant), and it requires a process for incorporating those findings into updated triggering condition catalogs and, where necessary, ODD restrictions or software updates.
Most programs treat Clause 9 as out of scope for the development phase. This creates a compliance gap: the SOTIF analysis claims that residual risk is acceptable based on pre-launch validation coverage, but there is no mechanism to catch the triggering conditions that pre-launch validation missed. Field monitoring is the safety net for unknown unsafe scenarios.
SOTIF and ISO WIZ
ISO WIZ includes a structured SOTIF module that manages triggering conditions as first-class objects, linked to their functional insufficiencies, their ODD scope restrictions, their validation test cases, and their field monitoring requirements.
The integration with ISO 26262 is automatic: SOTIF triggering conditions that produce hazardous events are linked to the corresponding HARA hazardous event. The severity assessment is shared, not duplicated. When the HARA is updated, the linked SOTIF triggering conditions are flagged for review.
The field monitoring module tracks Clause 9 requirements as ongoing process items: what data is being collected, what thresholds trigger a review, and what the update process is when a new triggering condition is identified in the field. This closes the loop between pre-launch validation and post-launch operation — the loop that most programs currently manage through ad-hoc processes, if at all.