The problem
AEB prevents or reduces collisions, but it can also brake unintentionally, which itself can cause rear-end crashes. Engineers use FMEA bottom-up and FTA top-down to find weak points and decide where safety mechanisms are needed. This project applies both methods to one AEB architecture and compares what each reveals, producing concrete improvement recommendations.
Objectives
- Define an AEB architecture with components, interfaces and functions.
- Carry out a design FMEA with severity, occurrence and detection ratings and action priorities.
- Build fault trees for missed braking and unintended braking top events.
- Compute top-event probabilities and minimal cut sets from assumed failure rates.
- Recommend and evaluate safety mechanisms using both analyses.
What you need
Tools and toolboxes
- Spreadsheet (Excel or LibreOffice Calc) — Holds the FMEA worksheet with ratings, action priorities and actions.
- MATLAB — Computes fault tree probabilities, minimal cut sets and importance measures with a small script.
- Python (optional) — Alternative for fault tree computation and cut-set enumeration.
- A diagramming tool (draw.io or similar) — Draws the architecture, block diagrams and fault trees.
- Simulink with Automated Driving Toolbox (optional) — Uses an AEB example model to understand signal flow and failure effects.
Software
- Spreadsheet software
- MATLAB or Python
- A diagramming tool
- Simulink with Automated Driving Toolbox (optional)
Extra parts and data
None beyond the software above.
Key concepts
- Design FMEA
- A bottom-up method that lists how each component can fail, the effect at vehicle level, the cause, and current prevention and detection, then prioritises actions.
- Fault tree analysis
- A top-down method that starts from an undesired event and breaks it into combinations of lower-level faults using AND and OR gates.
- Minimal cut set
- A smallest combination of basic events that causes the top event. A single-event cut set is a single point of failure.
- Action priority
- A rating from the AIAG-VDA FMEA approach that combines severity, occurrence and detection to rank which failure modes need action first.
Step-by-step guide
- 1
Define the AEB architecture
Draw an architecture with a front radar and front camera, a fusion and AEB decision function on an ADAS ECU, a CAN or Ethernet link to the brake controller, the brake controller with its hydraulic actuator, wheel speed sensors and a driver warning HMI. List each component's functions and interfaces. State operating assumptions such as speed range and target types. This diagram is the basis for both analyses.
Checkpoint: An architecture diagram with a component and function table.
- 2
Prepare the FMEA structure
Set up the FMEA worksheet with structure, function and failure analysis columns: component, function, failure mode, effect at vehicle level, severity, cause, prevention control, occurrence, detection control, detection rating and action priority. Define rating scales in a separate sheet with clear descriptions for each level, so different team members rate consistently. Agree the scales before analysing. Fill in two example rows together as a team to calibrate how the scales are used.
Checkpoint: A worksheet template and rating scale sheet agreed by the team.
- 3
Identify failure modes
For each component and function, list failure modes: radar loses targets or reports ghost targets, camera misclassifies, fusion outputs a stale object list, AEB logic triggers on a false target, CAN message lost or delayed, brake controller ignores or over-applies a request, wheel speed sensor fails. Write effects at vehicle level, distinguishing missed braking from unintended braking, and list causes.
Checkpoint: A filled failure analysis with effects separated into missed and unintended braking.
- 4
Rate and prioritise
Rate severity from the effect, occurrence from the cause and prevention control, and detection from the detection control. Compute action priority as high, medium or low using the AIAG-VDA logic implemented in the spreadsheet. Sort and identify the high-priority items. Discuss any high-severity item with low priority, because ratings can hide serious effects if occurrence is underestimated. Record who rated each row and the date, so the history of changes is clear.
Checkpoint: A sorted FMEA with action priorities and a short list of high-priority failure modes.
- 5
Build the missed-braking fault tree
Define the top event: AEB does not brake when a collision is imminent within its specified operating range. Decompose it: no object detected (radar and camera both miss, or fusion fails), decision not made (logic fault, wrong threshold), request not delivered (network fault) or brake not applied (brake controller or actuator fault). Use AND gates where redundancy exists and OR gates where any fault suffices.
Checkpoint: A fault tree diagram for missed braking with labelled gates and basic events.
- 6
Build the unintended-braking fault tree
Define the top event: AEB applies strong braking without a real obstacle. Decompose it into ghost targets from radar or camera that fusion accepts, logic or calibration faults, corrupted network messages accepted by the brake controller and brake controller faults. Note how this tree differs from the first: redundancy that helps missed braking, such as accepting either sensor, can increase unintended braking.
Checkpoint: A second fault tree with a written note on the redundancy trade-off.
- 7
Quantify the trees
Assign assumed failure rates or probabilities to basic events, clearly labelled as illustrative and drawn from generic reliability handbook ranges or reasoned estimates. Write a MATLAB or Python script that computes top-event probability for a mission time, enumerates minimal cut sets and calculates Fussell-Vesely or Birnbaum importance. Check the script against a hand calculation for a small sub-tree. Keep the failure rate table separate from the tree structure so values can be changed easily.
Checkpoint: Top-event probabilities, minimal cut sets and importance rankings, with a hand-checked sub-tree.
- 8
Compare FMEA and FTA findings
Compare the high-priority FMEA items with the most important cut sets. List what each method found that the other missed: FTA reveals combinations of faults and single points of failure; FMEA reveals detection gaps and individual causes. Identify single-event cut sets as candidates for safety mechanisms. Note any findings that appear in both analyses, as these are the strongest candidates for action. Discuss why some findings appear in only one method.
Checkpoint: A comparison table of findings from each method with single points of failure highlighted.
- 9
Propose and evaluate improvements
Propose safety mechanisms: message counters and CRC on the brake request, plausibility checks between radar and camera, a brake controller check that requests match the object situation, and sensor self-diagnostics. Update the FMEA detection ratings and the fault tree structure with each mechanism, recompute priorities and probabilities, and report the improvement per mechanism. Rank mechanisms by the improvement they give, and note any that help one top event but harm the other.
Checkpoint: Before and after action priorities and top-event probabilities for each mechanism.
- 10
Report
Present the architecture, FMEA, both fault trees, quantification, comparison and improvements. Explain clearly that failure rates are assumptions, so conclusions are about relative improvement, not absolute safety. Relate the work to ISO 26262 activities such as safety analyses at system level. Include the spreadsheet and scripts as appendices. Add a summary page of the top recommendations for a design team. Close with suggestions for how the analysis would be updated as the design matures.
Checkpoint: A report with both analyses, quantified improvements and stated assumptions.
Testing & validation
- FMEA covers every component and function in the architecture.
- Fault tree script verified against a hand calculation.
- Minimal cut sets and importance measures computed for both top events.
- Improvements shown in both FMEA priorities and fault tree probabilities.
Expected results
A design FMEA and two quantified fault trees for an AEB system, with a comparison of the methods and evaluated safety mechanisms that reduce single points of failure.
Take it further
- Add common-cause failures, such as a shared power supply, to the fault trees.
- Inject the analysed faults into a Simulink AEB model and observe vehicle-level effects.
- Extend to a dynamic fault tree for time-dependent failures.
- Link FMEA items to safety requirements in Requirements Toolbox.
Viva and review questions
Why build two separate fault trees?
Missed braking and unintended braking have different causes and are affected oppositely by some design choices, so each needs its own analysis.
What is a single-event cut set telling you?
That one basic fault alone causes the top event, which is a single point of failure and a priority for a safety mechanism.
Why are your probabilities not absolute safety figures?
The failure rates are assumed for illustration, so the analysis is valid for comparing designs, not for claiming a real system's failure rate.
What does FMEA find that FTA might miss?
Weak detection controls and individual causes of failure that may not appear clearly in a top-down tree.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.