Services
ISO 26262, ISO 21448 and ISO/PAS 8800 are not three competing rulebooks. They are three views of the same question — can this vehicle hurt someone, and how do we know? Here is what each one actually covers, where the boundaries sit, and why the boundaries are the dangerous part.
Start here
The fastest way to know which framework applies is to ask what has to go wrong for a person to be harmed. The three answers below are mutually exclusive as causes — and jointly exhaustive as an argument.
Something in the electrical/electronic system breaks or was built wrong — a random hardware fault, a systematic design fault, a software defect — and the resulting malfunctioning behaviour leads to a hazard.
The system is faulted. Remove the fault and the hazard disappears.
Nothing is broken. Every requirement is met. The function is simply not capable enough for the situation it meets — or a person uses it in a way that was foreseeable but not designed for.
The system is fault-free. You cannot debug your way out; you have to improve the function or restrict its operational domain.
The insufficiency exists because a component was learned rather than written. Its behaviour comes from data, an optimisation process and an architecture — none of which can be reviewed clause by clause.
The system is fault-free and the function was well specified, but the evidence model from the other two standards does not fit.
Side by side
Print this and put it on the wall. Most cross-team arguments about "whose finding is this?" are resolved by the second row.
| Dimension | ISO 26262 Functional safety | ISO 21448 SOTIF | ISO/PAS 8800 Safety and AI |
|---|---|---|---|
| Question answered | Does the system fail dangerously? | Is the system good enough when nothing fails? | Is the learned component trustworthy enough to carry a safety role? |
| Cause of the hazard | Malfunctioning behaviour of E/E systems — random hardware faults and systematic faults in hardware and software | Functional insufficiencies of the intended functionality, and reasonably foreseeable misuse by persons | Insufficiencies rooted in data, training, model architecture, generalisation and distributional shift |
| System state | Faulted | Fault-free | Fault-free, correctly implemented — but statistically derived |
| Risk classification | ASIL A–D from severity, exposure and controllability | Scenario space split into known/unknown × safe/unsafe (Areas 1–4); goal is to shrink Areas 2 and 3 | AI safety requirements derived from the allocated safety goals, with performance and robustness targets per ML property |
| Core technique | Safety mechanisms, diagnostic coverage, freedom from interference, dependent failure analysis | Triggering condition analysis, ODD definition, scenario-based verification and validation, functional modification | Dataset specification and coverage, training and evaluation rigour, uncertainty estimation, out-of-distribution detection, runtime monitoring |
| Central evidence | Hardware architectural metrics (SPFM, LFM, PMHF), systematic capability, verification reports | Residual risk in the unknown-hazardous scenario space against defined acceptance criteria | Quantified model performance and its insufficiencies, traced to the data and the operational domain |
| Typical failure it catches | A stuck-at fault in a sensor interface commands unintended braking | Perception under-performs against low sun, spray or an unusual object pose — no component is faulty | A pedestrian class collapses for an under-represented appearance because the dataset never contained it |
| Primary artefact | Item safety case, safety plan, FSC/TSC, confirmation measure reports | SOTIF argument, scenario catalogue, validation strategy and acceptance rationale | AI safety case for the component, dataset and model documentation, monitoring concept |
| When it applies | Any safety-related E/E system in a road vehicle | Any function that senses, interprets or decides under uncertainty — ADAS and automated driving above all | Any AI/ML component that contributes to a safety-related function |
Scroll the table horizontally on narrow screens.
Why it matters
Each one was written because the previous one had run out of road. The history is not trivia — it tells you exactly what each framework is blind to.
2011
ISO 26262 first edition — second edition 2018
2022
ISO 21448 published as a full standard
2024
ISO/PAS 8800 published for safety and AI
Functional safety rests on a quiet assumption: that the correct behaviour of the item is known, and the only problem is making the electronics deliver it reliably. For an airbag controller or an electric power steering ECU, that assumption holds. The specification is short, the environment is bounded, and "correct" is unambiguous.
Automated driving broke the assumption. When the item has to decide whether a shape at 80 metres is a stopped vehicle or an overhead sign, the hard part is no longer delivering the specified behaviour — it is knowing what the specified behaviour should be. A perfectly fault-free implementation of an insufficient specification is still a hazard, and ISO 26262 has no clause for it.
SOTIF took the hazards that remain when nothing is broken and gave them a structure. Its central move is to stop reasoning about components and start reasoning about scenarios: the known-safe ones, the known-unsafe ones you must engineer away, and — the hard part — the unknown-unsafe ones you have not met yet.
The corresponding concept is the triggering condition: the specific circumstance that activates a latent insufficiency. Low sun at a particular elevation. A cyclist carrying a large flat object. Retro-reflective road works markings. None of these are faults. All of them are hazards.
The practical consequence. Under ISO 26262 you reduce risk by adding safety mechanisms. Under SOTIF you reduce risk by improving the function, restricting the operational design domain, or proving the residual unknown space is small enough to accept. These are entirely different engineering programmes with different budgets.
SOTIF tells you that insufficiencies exist and must be bounded. It does not tell you how to develop, evaluate and argue about a component whose behaviour was learned. That is the gap ISO/PAS 8800 fills: an AI safety lifecycle that sits alongside the existing ones and produces evidence the other two standards can consume.
It covers the things that decide whether a machine-learned function is safe long before anyone runs a scenario test — how the dataset was specified and shown to cover the ODD, how training and evaluation were separated, how performance degrades at the edges of the distribution, how the system detects that it is out of distribution at runtime, and what architectural measures contain a wrong answer when one is produced anyway.
None of this is optional once you want to operate. Germany's autonomous driving act (StVG §1d–1l) and the implementing AFGBV ordinance allow SAE Level 4 vehicles to operate in a defined operational area — but demand a technical supervisor, a demonstrable risk-minimal state, data recording, independent technical assessment and a dossier the KBA will accept. At UNECE level, R157 and its successors do the same for type approval. The EU AI Act adds obligations on data governance, logging and human oversight for AI in safety components.
The regulator does not receive three standards. It receives one argument. If your evidence is organised by standard rather than by hazard, you will spend the last three months of the programme re-organising it under time pressure.
The ecosystem
There is only ever one hazard list. The standards do not partition the vehicle — they partition the causes. That single idea is what makes an integrated safety argument possible.
Each safety goal gets an ASIL. Safety mechanisms, diagnostics and architectural measures reduce the probability that a fault produces the hazard.
The same safety goals are re-examined assuming zero faults. Triggering conditions, ODD limits and scenario coverage bound the performance risk.
Where a branch-B insufficiency lives inside a learned component, 8800 supplies the lifecycle and the evidence that branch B assumes exists.
The seams
In our experience the findings that hurt most are never inside one standard. They sit exactly on the boundary, where each team assumes the other one owns it.
Seam 01
A safety mechanism is implemented to ASIL D and verified perfectly — against a requirement that was itself insufficient. Functional safety confirms the implementation; nobody confirms the intent.
Fix: derive SOTIF-relevant requirements from the same safety goals and trace them in the same requirement baseline, not in a parallel document set.
Seam 02
A triggering condition is logged as an environmental edge case when it is really a dataset gap. The team responds with more road testing instead of a dataset change, and the same failure returns two releases later.
Fix: classify every triggering condition by whether its root cause is sensing physics, specification, or the training distribution — and route it accordingly.
Seam 03
The model is evaluated thoroughly, on hardware whose fault behaviour was never analysed for it. Accelerator memory faults, quantisation and non-deterministic scheduling all sit outside the ML evaluation and outside the classic FMEDA.
Fix: treat the inference platform as part of the item, with dependent failure analysis that includes the model's sensitivity to corrupted computation.
Practice areas
Each practice can be engaged on its own. All of them are written to land in the same safety case.
01 / Functional safety
Item definition, HARA and ASIL determination, functional and technical safety concepts, hardware and software safety requirements, confirmation measures and the safety case.
02 / Intended functionality
ODD specification, triggering condition analysis, the Area 1–4 scenario space, acceptance criteria, scenario-based V&V strategy and field monitoring.
03 / Artificial intelligence
AI safety lifecycle, dataset specification and coverage, model safety requirements, robustness and OOD evidence, runtime monitoring and the AI safety argument.
Cross-cutting
The integration itself is a deliverable. These engagements are what turn three conformant workstreams into one argument.
Most teams we meet are strong in one branch, competent in the second, and have never written the third down. Let's find out which is which.