Fault Tree Analysis

Description

Fault tree analysis (FTA) is a deductive, top-down method that starts from one undesired system-level event, such as an automated braking function failing to brake for an obstacle, and works backwards to the combinations of lower-level events that could cause it. The analyst builds a tree of logic gates beneath that top event: an OR gate means any one of its inputs is enough to cause the event above it, an AND gate means all of its inputs must occur together, and the branches end in basic events such as a hardware failure, a human error or a software error. Solving the tree gives its minimal cut sets, the smallest combinations of basic events that produce the top event (a set with a single event is a single point of failure), and, when each basic event has a probability, the probability of the top event, which can be checked against a target or used to set a probability budget for each part. In a system with a machine-learning component, the model's errors enter the tree as basic events of their own, which unlike random hardware failures happen during normal operation at a rate that has to be measured on test or operational data, often depend on conditions such as weather or occlusion that can be added beneath it as conditioning events, and can be correlated from one input to the next. Working down from an acceptable top-event probability turns the model's share into a budget for its error rate, which becomes a performance requirement on the model; the tree shows where model errors matter in the system and how much error it can tolerate, but not why the model makes them.

Example Use Cases

Safety

An avionics team designing an emergency braking system for taxiing aircraft, in which a neural network detects 'No Entry' signs, builds a quantitative fault tree for loss of the restricted-area alert, budgets the detector's misses beside the hardware failures, converts that budget into a maximum per-frame miss probability for the network, and checks on recorded taxi data whether misses in successive frames are independent, as the calculation assumes.

A driving-automation developer analysing the top event 'object not detected in time' adds weather, occlusion and lighting as triggering conditions beneath the camera detector's miss event. Quantifying the tree with rates measured on its own test drives shows which conditions dominate, and it uses the result to decide where a second sensor is needed before widening the vehicle's operating domain.

A hospital pharmacy planning to add a machine-learning dose checker beside pharmacist review draws a tree for 'harmful overdose reaches the patient', with an AND gate requiring both the checker and the pharmacist to miss the error. The analysis shows the claimed risk reduction holds only if the two misses are independent, so the team plans an audit of whether pharmacists check less carefully once the checker is live.

Limitations

The tree explains only the top events the analysts choose and the causes they think of. Hazards nobody posed as a top event, and losses that arise from interactions between parts that each worked as specified, do not appear, so a fault tree needs a prior hazard identification to decide which top events matter.
A probability for a model-error event is only as good as the data it was measured on. A miss rate estimated on test data holds for the conditions and input mix in that data and changes when the operating environment shifts, so the top-event probability can be badly wrong in conditions the test set under-represents. The main aerospace safety-assessment guidance gives no method for such performance failures, so each assessment has to justify its own.
Quantifying a tree usually assumes basic events are independent, and machine-learning errors often are not: misses on successive camera frames are correlated, and one condition such as fog can degrade a model and the sensor or person meant to back it up at the same time. Unmodelled dependence makes an AND gate look far more protective than it is, so dependence must be checked on data or modelled explicitly.
The model appears in the tree as one or a few basic events, so the analysis says how often the model may err and where its errors matter, not why it errs or which inputs cause the errors. The triggering conditions added beneath a model-error event are only those the analysts already suspect, and finding others needs analysis of the model and its data.
Building and maintaining a tree for a large system is laborious, and it must be revised whenever the architecture or the model changes. Quantification needs a probability for every basic event, and for software, human and model events those numbers are often unavailable or disputed; aviation software guidance, for example, does not accept software reliability rates in the system safety assessment.

Resources

Research Papers

Fault Tree Handbook (NUREG-0492)

Software Packages

Public Fault Tree Analyser (PFTA)

Public Fault Tree Analyser (PFTA): free and open-source fault tree analysis - public-fta/pfta

Tutorials

Fault Tree Handbook with Aerospace Applications (Version 1.1)

Documentations

IEC 61025:2006 Fault tree analysis (FTA)

Related Techniques

Name	Description	Assurance Goals
System-Theoretic Process Analysis	System-Theoretic Process Analysis (STPA) is a hazard analysis method developed by Nancy Leveson at MIT that treats safety as a control problem: a loss can occur when parts of a system that have not failed interact unsafely, for example when a controller acts on a wrong belief about the process it controls. The analysis has four steps: define the losses to prevent and the system-level hazards that lead to them; model the system as a control structure of controllers, the control actions they issue and the feedback they receive; identify unsafe control actions; and write loss scenarios explaining how each could arise. An unsafe control action is one of four types (not providing an action causes a hazard, providing it causes a hazard, providing it too early, too late or in the wrong order, or stopping it too soon or applying it too long), and loss scenarios cover causes such as missing or wrong feedback, a flawed control algorithm, or a controller's process model (its internal picture of what it controls) that no longer matches reality. In a system with machine-learning components, a learned model appears in the control structure as a controller whose control algorithm and process model were learned from data, or as a feedback source, such as a perception model, whose errors mislead a controller; loss scenarios include training data that missed an operating condition, a shift from training to deployment conditions, and operators who over-rely on the model, and published adaptations also model data collection, training and evaluation as control loops, so that a scenario can trace an unsafe control action back to a development decision such as an incomplete reward function. The output is a traceable set of unsafe control actions, loss scenarios and the safety constraints and requirements derived from them, which the team uses to change the design and to decide what to test; it analyses a model of the system before or alongside testing, and it gives no probabilities.	Safety
Machine Learning Failure Mode and Effects Analysis	Machine Learning Failure Mode and Effects Analysis (ML FMEA) applies the process form of failure mode and effects analysis, a long-established worksheet method in which a team lists what could go wrong at each step of a process, rates each failure and acts on the worst first, to the pipeline that produces a machine-learning model rather than to the model alone. The team works through the pipeline one step at a time (in the 2025 reference version: collect data requests, collect data, ingest data, validate data, preprocess data, train, tune, analyse, deploy and validate the model, and analyse feedback from the field) and, prompted by guide words such as missing, incorrect or too late, records for each step how the resulting model could fail, the effect on the wider system, the pipeline causes, and the current practices that would prevent or catch the failure. Each row is rated for severity, occurrence and detection, and the product of the three, the risk priority number, ranks the rows so that recommended actions and owners go to the highest risks first; severity is taken from the system-level hazard analysis, because the harm a model failure can do depends on the system it sits in. The method's authors publish a pre-populated template listing typical failure modes, causes and mitigations for each step, which a team tailors to its own model and application. The result is a worksheet of ranked pipeline failure modes, their controls and assigned actions, kept up to date as the pipeline changes; it looks at failures one at a time in how the model is built and does not by itself analyse how the deployed system behaves.	Safety
Signal Temporal Logic Monitoring	Signal temporal logic (STL) monitoring checks the signals a system produces over time, such as speeds, distances, positions or a model's outputs, against safety requirements written in signal temporal logic, a formal language for stating how real-valued signals must behave over time intervals (for example, 'whenever the gap to the vehicle ahead falls below 10 m, speed drops below 5 m/s within 2 s'). Each requirement is built from comparisons of signals with thresholds, joined by logical operators and by timed operators such as 'always within [a, b]', 'eventually within [a, b]' and 'until'. For each trace the monitor computes a robustness value, a margin to the requirement rather than robustness to adversarial inputs: its sign says whether the requirement is met (positive) or violated (negative), and its size is a tolerance: any signal whose values stay closer than that to the observed ones at every instant gets the same verdict. Monitors run offline on logged or simulated traces, or online on live signals, where a requirement that looks ahead in time can be decided only once enough of the signal has arrived. RTAMT, the named tool, is an open-source Python library with an optional C++ back-end that builds such monitors from a written specification and connects to ROS and MATLAB/Simulink; its online monitors accept only requirements whose future time windows are bounded and give each verdict after a delay equal to the requirement's time horizon, and it reports the robustness value but does not act on it, so stopping or correcting the system is left to a separate safeguard.	Safety