AEB System Fails to Activate — Fault Tree Example
A reference fault tree for an Autonomous Emergency Braking (AEB) function that fails to apply braking when a forward collision is imminent. Aligned to ISO 26262-5 hardware safety requirements at ASIL-B, with a 1-year (8,760 h) mission time.
The scenario
An ADAS-equipped passenger vehicle is approaching a stationary obstacle at urban speeds. The Autonomous Emergency Braking function is expected to detect the obstacle, decide that a collision is imminent, command the hydraulic actuator to apply maximum service braking, and arrest the vehicle. The top event of this fault tree is the AEB function failing to activate on demand — not partial activation, not late activation, but no commanded brake torque at all.
ISO 26262-5 classifies AEB as a safety-related function and assigns an ASIL based on severity, exposure and controllability. For a typical urban-AEB function this is ASIL-B, which sets a hardware random-failure target around PMHF < 1×10⁻⁷ /h. The fault tree's role is to show — quantitatively — that the architecture meets that target across sensor, compute, actuation and power supply branches.
Top event and decomposition
The top event is decomposed through an OR gate because any one of four independent failure pathways alone is sufficient to defeat AEB activation:
- Sensor subsystem failure — radar OR camera loss, or sensor fusion mis-classification (modeled as separate basic events with detection coverage).
- ADAS ECU failure — compute fault, memory ECC failure or firmware watchdog timeout. Each branch carries its own λ and DC (diagnostic coverage) per ISO 26262-5 Annex D.
- Brake actuation interface failure — CAN bus signalling fault between ADAS ECU and ESC, or brake-by-wire actuator fault.
- Redundant power supply failure — modelled as an AND gate of the primary 12 V rail and the backup rail, since either supply alone is sufficient.
Failure rates on each leaf are pre-populated using SN 29500-style component data; you can override them with field-return data from your own programme.
Standards alignment
This template demonstrates the deliverable that ISO 26262-5 Clause 9 and Annex E expect for hardware random-failure quantification: an FTA tied to the safety goal "AEB shall apply braking on valid threat detection," with the top-event probability evaluated against the ASIL-B PMHF target. The minimal cut sets exposed by MOCUS feed directly into the safety case argument that no single point of failure (or expected fault combination) can defeat the function.
Use this template
Click Open in FTA Studio above to load the tree directly in the browser — no account, no install. Edit failure rates, restructure gates, run MOCUS to enumerate minimal cut sets, compute Birnbaum / Fussell-Vesely importance, and export an IEC-format JSON or audit PDF for your safety case.
If you want to layer Monte Carlo uncertainty on top — using lognormal failure-rate distributions instead of point estimates — that's the Enterprise edition. Community edition handles all the deterministic analysis above.