Practice 01 · Functional safety
The foundation. Everything else in your safety argument rests on being able to show that when the electronics fail — and they will — the vehicle does not become dangerous.
Scope
ISO 26262 addresses hazards caused by malfunctioning behaviour of electrical and electronic systems in road vehicles — and only those.
Boundary condition. If the hazard occurs while every component is working exactly as specified, it is out of scope here and belongs in SOTIF. Getting this boundary right on day one saves months of misfiled findings.
Random hardware faults occur unpredictably during the operating life of a hardware element — a transistor degrades, a solder joint cracks, a cosmic ray flips a bit. They cannot be designed out, only detected and controlled, and they are quantified with failure rates and metrics.
Systematic faults are built in: a requirement was ambiguous, an interface was misunderstood, a timing analysis was wrong, a compiler option was unsafe. They exist in every copy of the product from the moment of manufacture, and the only defence is process rigour — which is why so much of the standard is about how you work rather than what you build.
Every hazardous event is classified along three axes — severity of the potential harm, exposure to the operational situation, and controllability by the driver or other road users. The combination yields ASIL A through D, or QM where no ASIL applies.
The ASIL then drives everything downstream: which methods are recommended or highly recommended, what hardware architectural metrics you must reach, how independent your confirmation measures must be, and whether an independent safety assessment is required at all. It is the single most consequential judgement in the whole lifecycle.
The automated driving twist. Controllability was written for a driver who is watching the road. Above SAE Level 3 that assumption evaporates, and controllability arguments that were routine in ADAS quietly stop holding. We see more invalid ASIL classifications from stale controllability rationales than from any other single cause.
The lifecycle moves from item definition and HARA to safety goals, then to a functional safety concept that says what must happen to keep each goal intact, then to a technical safety concept that allocates it to hardware and software with fault tolerant time intervals and safe states. Hardware development adds quantitative evidence — FMEDA, SPFM, LFM, PMHF — and software development adds architecture, unit design, and verification against the ASIL-appropriate method table.
Around all of it sits safety management: the safety plan, the development interface agreement with each supplier, tool qualification, and the confirmation measures — reviews, audit and assessment — that make the argument independent rather than self-declared. The output is the safety case: the reasoned argument, supported by the work products, that the item is acceptably safe.
Deliverables
Work products, reviewed and traceable — written to survive an independent assessment rather than to fill a template.
Signals
Connections
ISO 26262 is where the safety goals are born. Both other branches inherit them — which is exactly why the three cannot be run as independent projects.
SOTIF asks what happens to those identical safety goals when nothing is broken. Same hazards, same goals, entirely different causal chain — and a different set of countermeasures. If your SOTIF analysis has its own separate hazard list, something has already gone wrong.
Part 6 of ISO 26262 assumes software you can specify, review and unit-test. A trained network has no unit to test in that sense. ISO/PAS 8800 supplies the equivalent rigour for learned components — while the inference hardware they run on stays firmly inside ISO 26262.
An independent review three months early costs a fraction of one three weeks late.