SOTIF HARA: Hazard and Risk Assessment according to ISO 21448 - Part 2

In the previous blog post, we talked about what a SOTIF HARA is and what is the process to create one. This this blog post we talk about acceptance criteria for SOTIF.

Acceptance Criteria: The New Discipline

If "unreasonable risk" is the question, Acceptance Criteria (AC) is what makes the answer defensible. AC is the quantified definition of acceptable: a measurable threshold the system must demonstrably meet before its residual risk can be called reasonable.

This is what separates SOTIF from wishful thinking. A safety goal says what the system must not do. Acceptance criteria say how good it has to be, in numbers you can test against. Without AC, "the risk is acceptable" is an opinion. With AC, it's a claim you can verify.

The discipline is in being specific. "The system shall reliably detect obstacles" is not an acceptance criterion. "The system shall detect stationary lead vehicles in fog with visibility above 50 m at a false-negative rate below X per Y km" is. The first is a hope. The second is an engineering target you can build toward and measure against.

Fig: The SOTIF acceptance-criteria decision path 

ISO 21448 deliberately prescribes no fixed number. Instead, it points to four established principles that teams use to justify the criteria they set:

• GAMAB (Globalement Au Moins Aussi Bon, "globally at least as good"). The system must be no more dangerous than what it replaces: a competent human driver, or the previous-generation system. Introducing the technology shouldn't make things worse.

• ALARP (As Low As Reasonably Practicable). Risk is reduced until the cost of further reduction would far outweigh the safety benefit gained. 

• MEM (Minimum Endogenous Mortality). The risk introduced by the technology should not exceed the baseline of natural human mortality.

• PRB (Positive Risk Balance). Any new risk the system introduces must be outweighed by the net safety benefit it delivers. It has ethical rather than purely statistical roots.

Each rests on a different reference point (a human driver, the prior system, natural mortality, net societal benefit), and each carries its own strengths and limitations depending on the function and the data available. Crucially, they aren't interchangeable formulas you drop numbers into. They're rationales: arguments for why a chosen criterion is defensible rather than arbitrary. In practice they're often combined. A team might argue that its system is at least as safe as a human driver, and that residual risk has been driven as low as reasonably practicable, and therefore that the risk is acceptable.

Worked Through: The GAMAB Chain

To see what an acceptance criterion actually looks like underneath, it helps to take one framework all the way to a number. GAMAB lends itself to that: its logic is self-contained, and ISO 21448 Annex C works it through a short formula chain, from a human baseline to a concrete validation distance. The same kind of quantification applies to the others. The reference point and the arithmetic differ, but the goal is identical: turn "acceptable" into something testable.

Baseline, kilometres between crashes

B=M/A

M is annual vehicle-kilometres travelled (from road-transport statistics such as FHWA);

A is the annual crash count for this specific crash type (from crash databases such as NHTSA CRSS).

B is how far an average human drives, on average, between crashes of this type.

Acceptable harm rate, per kilometre

AH=1/(B×Y)

Y is a safety margin scaled to the severity of the crash type.

AH is how often, per kilometre, the system may be permitted to cause a harm of this type and still meet the criterion.

Validation target, kilometres to prove it

 T=−ln⁡(1−α)/AH

α is the statistical confidence level.

T is the zero-incident validation distance: how far the system must drive without a hazardous event of this type to demonstrate, at that confidence, that it actually meets the criterion.

Where SOTIF HARA Goes Wrong in Practice

SOTIF is newer than ISO 26262, and the discipline around it is still maturing. The common failure modes:

• Unreasonable risk as a gut call. Declaring a risk acceptable without acceptance criteria to back it turns the central judgement of SOTIF into an opinion. The AC is the evidence.

• Aspirational acceptance criteria. "The system shall be safe" or "shall reliably detect obstacles" are not criteria. If it can't be measured, it can't be verified, and it isn't AC.

• Confusing SOTIF and ISO 26262 hazards. Treating a performance limitation as a malfunction, or the reverse, sends the analysis down the wrong branch. The test is simple: did something break, or did a correctly-functioning system reach its limit?

Conclusion: Making the Intangible Measurable

The hardest thing about SOTIF is that its hazards don't announce themselves. There's no failure to catch, no fault code, no broken component, just a capable system quietly reaching the edge of what it can do. Left unquantified, "our system's limitations might hurt someone" is a statement no engineering programme can act on.

Acceptance Criteria is the mechanism that turns that statement into a bounded, measurable problem. It replaces we think it's safe enough with here is the threshold, and here is the evidence we met it. Get the acceptance criteria right (specific, measurable, defensible) and the rest of the SOTIF process becomes tractable.

That's the real contribution of SOTIF HARA: not a new rating table, but a discipline for making acceptable risk something you can actually prove.