SotIF for the Functional Safety Engineer

SOTIF - Safety of the Intended Functionality, standardized as ISO 21448:2022 - addresses hazards that occur without any system fault: the E/E system works exactly as specified, but the specification or its performance is insufficient for a real-world situation. A radar reporting a phantom target from guardrail multi-path is not a fault; it is a functional insufficiency activated by a triggering condition. ISO 26262 covers hazards from malfunctioning E/E behaviour (faults); ISO 21448 covers hazards from performance limitations and specification gaps. For ADAS and automated driving, both are needed, and the two lifecycles run in parallel on the same architecture with shared work products.

A fault is an abnormal condition inside the system - a broken sensor, a corrupted memory cell, a software bug - that causes behaviour to deviate from specification; ISO 26262 owns it. A functional insufficiency is a limitation of the specified function itself: the sensor operates within spec but its specification cannot handle low sun, or the detection algorithm was never specified for a scenario it meets in the field. The practical triage asks three questions - is there an E/E deviation from specification, is it a performance-versus-specification issue, is ML involved - routing each issue to ISO 26262, SOTIF, or SOTIF plus ISO/PAS 8800. Misclassification sends the issue into the wrong lifecycle with the wrong countermeasures.

A triggering condition is a specific scenario element or environmental condition that activates a functional insufficiency and turns it into hazardous behaviour - for example, radar multi-path on a motorway guardrail producing a phantom stationary target that triggers unjustified emergency braking. Triggering conditions play the role in SOTIF that faults play in ISO 26262: they are catalogued systematically (HAZOP guide-words and inductive analysis over the sensor chain are the standard methods), linked to the insufficiencies they activate, and drive both the functional modifications that mitigate them and the verification scenarios that must be tested. The guide builds a full triggering-condition catalog for an AEB function as its running example.

First choose an explicit acceptance philosophy - GAMAB, MEM, ALARP or a positive risk balance - then decompose the target using the three-factor risk model into scenario exposure, hazard-given-behaviour and severity-given-hazard components, anchored to baseline data such as NHTSA crash statistics. Verification exercises known triggering conditions (Area 2) across a five-level pipeline; validation must also bound the risk from unknown scenarios (Area 3), which is where statistics enter: the zero-event Poisson stopping rule tells you how much observation without a hazardous event is needed to claim the target with confidence. Field monitoring then continues the argument after release, feeding re-evaluation when reality disagrees.

The guide has 12 chapters, from the FuSi-to-SOTIF scope gap and a clause-by-clause tour of ISO 21448:2022, through the fault-versus-insufficiency decision tree, HARA extension, acceptance targets, functional modifications, verification and statistical validation, to ML-aware safety with ISO/PAS 8800 and ISO/IEC TR 5469, the joint safety case and field monitoring - supported by more than 50 diagrams and tables. A continuous AEB worked example runs from HARA extension to field monitoring. A free account starts you off, and the Pro and Expert plans unlock more of the library.