The awkward part is not that there are four causes. It is that they share almost nothing: different mechanism, different analysis, different evidence, different team. ISO 26262 was written for one of them. It is still the backbone of automotive safety. It is no longer the whole argument.
One hazard, four causes
Take lane centering, which keeps a car between the painted lines on a motorway while the driver stays responsible for it. Four things work in series: a camera that sees the lines, a model that decides where the lane runs, a controller that turns that into a steering demand, and an actuator that obeys. Break any one and the outcome is identical. The car moves sideways at speed without being asked, and the severity, exposure and chance of catching it never change.
Ask what produced it and the one hazard becomes four unrelated problems. A cracked joint sends the controller a torque value nothing ever measured. Glare off wet tarmac erases the lines while the camera meets every clause of its specification. A compromised gateway puts a counterfeit steering message on the bus. Or the model meets a lane marking absent from its training data and commits to the wrong one.
Only the first is a malfunction. In the other three nothing misbehaved: each part did what it was built, trained or told to do, and the car still went where it should not. Which of the four it is settles the analysis that catches it, the evidence that closes it, and whose name is on it.
The four are not sealed off from each other. ISO/PAS 8800 layers onto ISO 26262 and ISO 21448 rather than replacing them, so that unseen marking is an AI insufficiency and a SOTIF one at once, and a fault in the accelerator running the model is still ISO 26262 work.
The fence ISO 26262 drew around itself
ISO 26262 states its territory in one sentence: the absence of unreasonable risk due to hazards caused by malfunctioning behaviour of electrical and electronic systems. Two phrases carry the weight. Malfunctioning behaviour covers any departure from specified behaviour, from a random hardware fault or a systematic one in the requirements, the design, the timing or the code. E/E systems means electrical, electronic and programmable electronic, not mechanics or chemistry, unless a malfunction reaches them.
It is then explicit about what it leaves outside. It does not address the nominal performance of a function: a sensor specified for daylight that misses a pedestrian at night has not malfunctioned. It does not address electric shock, fire or toxic fumes unless a malfunction caused them. And its guidance on the interaction with cybersecurity sits in an informative annex, without saying how to engineer against an attacker.
These were scoping decisions, not oversights. The usual reading is that they made a first edition possible, and that they held while safety-relevant electronics ran hand-written software with little outside exposure. Assistance systems stopped warning and started acting, vehicles became connected, perception moved to trained networks. Each of those shifts produced a document. Shock and fire never joined this map.
The siblings, and what kind of document each one is
| Leading document | Hazard source | Published as | What the analysis looks for |
|---|---|---|---|
| ISO 26262 | An E/E system malfunctions | International Standard, second edition 2018 | Random hardware faults, systematic faults |
| ISO 21448 | It reaches its performance limit | International Standard 2022, publicly available specification 2019 | Triggering conditions, and foreseeable misuse |
| ISO/SAE 21434 | Someone attacks it on purpose | International Standard 2021, jointly with SAE | Assets, threat scenarios, attack feasibility, risk treatment |
| ISO/PAS 8800 | A learned model meets what it never saw | Publicly available specification, 2024 | Data coverage, model evaluation, an AI assurance argument |
Where ISO 21448 applies, the system is working. The hazard comes from a performance limitation, a specification that never anticipated the situation, or foreseeable misuse: a blinded sensor, an algorithm confused by a scene, a driver who misread the limits. Analysts hunt triggering conditions, not broken parts.
ISO/SAE 21434 replaces the random fault with a motivated adversary. A failure rate says nothing about someone choosing where to push, so the analysis becomes assets, threat scenarios, attack feasibility and a treatment decision per risk.
ISO/PAS 8800 covers what cannot be argued by reading the code. A learned model has no requirement traceable to a line of logic, so the argument moves to the data it was trained and tested on, the insufficiencies of its outputs, and the assurance case tying them together.
The law that reads your safety case
The standards themselves stay voluntary. What became compulsory is narrower. UN R155 and R156, in force since 2021 and applying to all new EU vehicles since July 2024, require certified cybersecurity and software update management systems; the second General Safety Regulation made a list of assistance systems mandatory on the same date. UN R157 covers automated lane keeping, not the supervised feature above. Search their normative text for ISO 26262 and you will not find it. The approval file gets built from its work products regardless, because that is where the state of the art sits.
One item, four arguments
Two arrangements suggest themselves: run the lifecycles back to back, or side by side with a team on each. Both fail alike. The item definition feeds four analyses. Hazard severities become safety impact ratings in the threat assessment. Cybersecurity controls become failure modes and latency in the budget. SOTIF triggering conditions become data requirements for the AI lane.
What works is one set of facts and four arguments. Anything factual about the item, where its boundary runs, what can go wrong, how it is built, gets written once and read by all four. What each lane keeps is the reasoning. Splitting the safety case four ways is the obvious move and the wrong one, because each argument retains a risk the other three need to see.
It is also where mitigations collide. Authenticating bus messages buys integrity and spends part of the fault-tolerant time interval. Diagnostics for random hardware faults buy coverage and spend the compute headroom a perception model needs. Neither trade is visible from inside the lane that made it, which is why it belongs in the architecture phase.
Where the backbone ends
ISO 26262 has not been demoted. Its subject is still the E/E system that does the wrong thing, and the rest of the map exists because a system can do exactly the right thing and still hurt somebody. Knowing where it stops is now part of knowing it.
The Automotive Safety Standards Map concept page covers the territory in sixteen chapters: who writes the documents, how the lifecycles interlock, and one feature traced through every one.
Abbreviations & Key Definitions
- E/E - Electrical and Electronic, including programmable electronics.
- ISO 21448 - The standard for the Safety of the Intended Functionality.
- ISO 26262 - The standard for functional safety of road vehicles.
- ISO/PAS 8800 - The publicly available specification for safety and artificial intelligence.
- ISO/SAE 21434 - The standard for road vehicle cybersecurity engineering.
- SOTIF - Safety of the Intended Functionality: hazards while the system performs as specified.
- UN R155, R156, R157 - UN regulations on cybersecurity, software updates and automated lane keeping.
Photograph: spray on a wet autobahn, by Andreas Bunen, CC BY-SA 3.0, via Wikimedia Commons; cropped, and the crop is under the same licence.




Comments
Loading comments