SOTIF (Safety of the Intended Functionality, ISO 21448)
SOTIF (Safety of the Intended Functionality, ISO 21448) addresses hazards without malfunction: the system works exactly as specified, but the specification or sensor performance is insufficient for the real-world situation — central for driver assistance and AI-based functions. The classic example: a camera fails to detect an obstacle in low sun or heavy snowfall, even though the system is fully intact.
How does SOTIF differ from classical safety?
Classical functional safety according to ISO 26262 asks: What happens if the system does not do what it should? SOTIF asks: Is what the system is supposed to do sufficient in every conceivable situation? Anyone mixing the two disciplines reaches for the wrong toolbox:
| Discipline | Core hazard | Right tools |
|---|---|---|
| Classical safety (ISO 26262) | Malfunctions: hardware failures, software bugs | Diagnostics, diversity, hardware redundancy, degraded operating modes |
| SOTIF (ISO 21448) | Functional insufficiencies: performance limits, unforeseen scenarios | Scenario analysis, sharpened specification, complementary sensors (fusion), validation in the real operating context |
Identical redundancy — say, a second camera of the same type — does not help against a performance limit: it merely duplicates the same weakness. And in a purely fault-oriented analysis such as a classical FMEA, hazards without a clear fault pattern remain completely invisible.
The scenario methodology of ISO 21448
The methodological core of SOTIF is the systematic division of possible operating scenarios into four areas: known or unknown, combined with safe or unsafe. The goal of the SOTIF activities is to systematically shrink the unsafe areas: known unsafe scenarios are mitigated through functional improvements, sharpened specifications or operational restrictions; the area of unknown unsafe scenarios is illuminated as far as possible through scenario analysis, simulation and validation in the real operating context. A residual risk of unknown scenarios remains — the standard requires making it defensibly small.
Why SOTIF is central for AI and machine learning
Machine learning functions have no specification in the classical sense: their behaviour emerges from training data, not from a requirements document. Their weaknesses are therefore inherent performance limits, not malfunctions — and thus exactly the class of hazards the SOTIF methodology is made for. As learning components enter safety-related functions, the centre of gravity of safety work is shifting across industries from pure fault management towards the systematic assurance of the intended function.
SOTIF in practice: a separation with real consequences
The distinction between malfunction and functional insufficiency is not an academic exercise. Teams without a clear separation quickly treat a performance limit like a malfunction and produce expensive measures that do not address the actual problem. In practice, it pays to interlink SOTIF analyses closely with functional safety: both consider the same system, the same scenarios and the same architectural elements — and every change to the system boundary affects both analyses at once. Those who maintain the results model-based and connected via trace links, rather than in separate documents, keep both strands of evidence consistent when changes occur.