Repository navigation
SOTIF and ISO 26262
ISO 26262 asks what happens when something in the system breaks. ISO 21448, SOTIF (safety of the intended functionality), asks what happens when nothing breaks but the system still gets it wrong. LionDriver needs both: openpilot's parts rarely fail, but its driving model often misjudges. This page explains SOTIF from the start for someone who has never used it, and shows how it shares work with ISO 26262. It explains and links. The analysis is in WP-C-05, WP-C-06 and WP-C-07, and the validation in WP-V-02, WP-V-03 and WP-V-04; nothing here is analysis content.
Every figure is drawn at each wiki sync by tools/wiki/sotif_animations.py.
Each ID, rating, status and number it draws is checked against the record it comes from, and the counts are computed
from the WP-C-05 and WP-C-06 tables. When a record changes, the build fails instead of showing old text.
The same thing can happen for two reasons. A malfunction is ISO 26262's business: a part fails, and the cure is to detect and contain the fault. A functional insufficiency is SOTIF's: every part works as designed, but the design or its performance is not good enough for the situation, and the cure is to improve the function, restrict where it may be used, or show by validation that the risk is acceptable.
LionDriver keeps one hazard log (WP-C-03 §7). A SOTIF hazard SH-0x has the same number as the HARA hazard H-0x with the same effect on the vehicle, and reuses its severity and controllability ratings. Only ISO 26262 turns them into an ASIL; SOTIF records exposure only to set validation targets. Some causes belong to both: a performance limit that a safety goal's fault tree also carries, and the driver who stops watching, which is foreseeable misuse in SOTIF and a rated entry in the HARA. Attacks belong to ISO/SAE 21434 and its TARA (WP-C-09), in the same log; see Cybersecurity and ISO/SAE 21434.
A triggering condition (TC) is something in the world the function cannot cope with. It exposes a functional insufficiency (FI): of performance (P), when the design is right but a part is not good enough there, or of the specification (S), when the design itself is wrong there. The result is a hazardous behaviour (SH), harmful only if the driver does not step in. WP-C-06 evaluates each chain: acceptable, needs modification (WP-C-07 or an ODD restriction), or needs validation (WP-V-03).
Every situation is known or unknown to us, and hazardous or not. SOTIF work moves situations out of area 3 (unknown, hazardous) into area 2 (known, hazardous) by analysis and exploration, and out of area 2 into area 1 (known, not hazardous) by modifying the function, restricting the ODD or informing the user. The record version is WP-C-05 Figure 2-1.
The acceptance criterion is "no worse than a human driving the stock car". Turned into a rate of hazardous behaviour and a demonstration with no failure at 95 % confidence, it needs far more driving than one test car can do. So WP-V-02 splits it into scenarios, each tested many times in simulation, on a closed course and in replay, and states in the release argument (WP-K-02) what this does not show.
Area 3 cannot be listed, only searched. WP-V-04 sets the search methods, the triage of every odd event (a malfunction found there goes to the ISO 26262 side), and the rule that says when to stop: new kinds of trouble must stop turning up.
The two standards meet in the safety envelope. The torque cap that contains a fault also bounds whatever the model gets wrong, so one controllability test supports a claim on each side of the safety case (What is a safety case?). That is why a gap in it counts twice. The ISO 26262 chain of the same requirement is followed on From hazard to test.
- Standards at a glance: how the standards divide the work.
- Building a fault tree: performance limits marked [SOTIF] in the SG-02 tree.
- Glossary for the work product and ID codes.