Functional safety: ISO 26262 and ASIL
The standard for keeping failures of electrical and electronic systems from injuring people. Hazard analysis, ASIL levels and safety mechanisms.
What it covers
Designing so that a sensor giving a wrong value, software hanging or a bit flipping in the MCU does not lead to a dangerous situation, and showing that with evidence.
Sequence
- HARA (hazard analysis): rate each malfunction scenario for severity (S), exposure (E) and controllability (C)
- Determine the ASIL: QM, A, B, C, D (D is the strictest)
- Safety goal: "no unintended acceleration"
- Functional safety requirements → technical safety requirements → down to hardware and software requirements
- Verification at each stage and writing the safety case
| Example | ASIL (roughly) |
|---|---|
| Steering, brakes | D |
| Airbag | D |
| Headlamps | B |
| Infotainment | QM |
Examples of safety mechanisms
- Lockstep cores (two cores do the same calculation and compare)
- RAM/Flash ECC, periodic self-tests
- Watchdog, program-flow monitoring
- Redundant sensors and plausibility checks (difference between two values, rate-of-change limits)
- Transition to a safe state on failure (zero torque, warning lamp)
On the software side
Depending on the ASIL, coding rules (MISRA), unit-test coverage (MC/DC), static analysis and requirements traceability are required. Memory protection (MPU) and timing separation keep software of different safety levels from interfering with each other.