Practice 02 · Intended functionality
Nothing is broken and the vehicle is still unsafe. SOTIF is the discipline of bounding the risk that comes from a function simply not being good enough — and proving how much of the world you have actually seen.
Scope
ISO 21448 addresses hazards arising from functional insufficiencies of the intended functionality, and from reasonably foreseeable misuse — in the absence of any fault.
The test. If you removed every fault from the system and the hazard could still occur, it is a SOTIF hazard. Most perception, prediction and planning hazards in automated driving are on this side of the line.
A radar that cannot separate a stationary vehicle from an overhead gantry is not broken — it is operating within its physical limits. A classifier that has never seen a particular object pose is not defective — it is generalising, and generalisation has edges. A driver who takes their hands off the wheel because the system usually copes is not sabotaging you — they are behaving in a way you could have foreseen.
ISO 21448 groups these into two root sources: performance limitations of the sensing, algorithmic and actuation chain, and specification insufficiencies where the intended behaviour was defined for a world narrower than the real one. Foreseeable misuse is treated as a first-class hazard cause, not an afterthought.
The insufficiency is latent until something activates it. That something is the triggering condition — the specific combination of scenario elements that turns a limitation into a hazardous behaviour. Sun elevation and azimuth. Wet retro-reflective markings. A motorcycle in a lane-split geometry. Snow on the sensor fascia at a particular temperature.
The engineering work is systematic identification of these conditions, and it is genuinely hard: they are combinatorial, they interact, and by definition the dangerous ones are the ones nobody has thought of. Which is why the standard reframes the problem in terms of scenario space rather than requirement lists.
The central model
Every scenario the vehicle can meet is either known to you or not, and either hazardous or not. The whole SOTIF programme is a campaign to move area by area.
Scenarios you have identified and in which the function behaves acceptably. This is the area you want to grow — and the area your validation evidence actually demonstrates.
You know the function fails here. Engineering response: improve the function, add a degradation or fallback, or cut the scenario out of the ODD. Every item here must be closed or explicitly accepted.
The dangerous quadrant. Failures you have not met yet. You cannot enumerate them, so the argument has to be statistical, structural and continuous — coverage rationale, architectural containment, and field monitoring that keeps converting Area 3 into Area 2.
Scenarios you have not characterised in which the function happens to cope. Harmless, but not evidence — you cannot claim credit for behaviour you have not observed.
The acceptance question. SOTIF does not ask you to eliminate Area 3 — that is impossible. It asks you to argue that what remains is small enough, and to state the criterion you are judging "small enough" against, before you start testing. Programmes that leave the acceptance criterion until validation almost always discover they have been collecting the wrong data for a year.
Deliverables
A SOTIF programme is only as good as its scenario evidence. We build the chain from ODD to catalogue to coverage claim so it holds together under scrutiny.
Signals
Connections
SOTIF sits in the middle. It inherits its hazards from functional safety and delegates much of its hardest evidence to the AI branch.
The HARA is shared. SOTIF should not produce its own hazard list — it should take the existing safety goals and ask what threatens them when the fault assumption is removed. Where a SOTIF countermeasure is implemented in E/E hardware or software, that implementation goes straight back into the ISO 26262 lifecycle at the right ASIL.
SOTIF says "the perception function under-performs in this triggering condition." It does not say why, and it offers little guidance on how to develop the component so it does not. When the component is learned, ISO/PAS 8800 supplies the dataset, training and evaluation evidence that closes the loop from symptom to root cause.
If the honest answer is "we don't know", that is the engagement — and it is a better starting point than most.