Fault tree analysis (FTA) is a deductive analytical technique that maps the logical combinations of component failures and events that can lead to a specified undesired top-level event. You start with the hazardous outcome you want to prevent and work backward, systematically identifying the combinations of conditions that could cause it.
In robotics and automation, FTA answers the question: “How many ways can this system fail in a way that causes harm?” The answer shapes architecture decisions, redundancy requirements, and the reliability targets that safety functions must achieve.
| FTA element | What it represents |
|---|---|
| Top event | The hazardous outcome being analyzed (e.g., “unexpected robot motion injures person”) |
| AND gate | Both input events must occur simultaneously for the output event to occur |
| OR gate | Either input event alone is sufficient to cause the output event |
| Basic event | A component failure or basic initiating event (typically has failure rate data) |
| Undeveloped event | An event not analyzed further — either because it’s beyond scope or data is unavailable |
| Cut set | A minimal combination of basic events whose simultaneous occurrence causes the top event |
Why FTA is used in functional safety
IEC 61508 and ISO 13849 require quantitative or qualitative arguments that safety functions achieve their required integrity levels. FTA is one of the primary techniques for making that argument.
When you claim that a safety function achieves SIL 2, you’re claiming the probability of dangerous failure per hour is below a specific threshold. FTA is how you demonstrate that the architecture and components you’ve chosen can meet that threshold. The analysis identifies the minimal cut sets — the smallest combinations of component failures that lead to system failure — and lets you calculate or bound the overall failure probability.
For systems using ISO 13849, FTA supports the architecture categorization and performance level calculations by making explicit the fault detection and redundancy structure of the safety function.
FTA is also diagnostic. A well-constructed fault tree reveals the dominant failure modes — the cut sets with the highest contribution to overall failure probability. These are the places where additional redundancy, improved diagnostics, or more reliable components will have the most impact on system safety.
How to construct a fault tree
Step 1: Define the top event precisely. A vague top event produces a vague analysis. “Robot motion harms person” is too broad. “Unexpected robot motion occurs while person is in hazard zone with perimeter guarding bypassed” is specific enough to analyze. The top event should be one of the hazardous outcomes from your HARA, linked to a specific hazard scenario.
Step 2: Identify the direct causes. What immediate conditions, taken alone or in combination, would directly cause the top event? Use AND gates when multiple simultaneous conditions are required. Use OR gates when any single condition is sufficient. Document your reasoning — the logic structure of the tree is the analysis, and it needs to hold up under review.
Step 3: Expand each cause until you reach basic events. Each intermediate event in the tree gets expanded in the same way: what immediate causes would produce this event? Continue until you reach basic events — component failures, environmental conditions, or human errors for which you have data or can make a bounded estimate.
Step 4: Identify and evaluate cut sets. A minimal cut set is the smallest combination of basic events whose simultaneous occurrence causes the top event. Single-event cut sets (single points of failure) are high priority — any single component failure that causes the top event is a serious architecture concern. Two-event cut sets with high failure rates are the next priority.
Step 5: Calculate or bound failure probability. Using component failure rate data (manufacturer specifications, SN 29500, OREDA, or other sources), calculate the probability of each cut set occurring and combine them to get an overall failure probability estimate. Compare against the target from your HARA.
FTA for robotics: common patterns
Perimeter guarding failure. A common top event for industrial robots operating in shared-space or mixed-mode environments. The tree typically includes: guarding detection failure AND motion not stopped, with both branches expanding into hardware failures, signal failures, and control logic failures. Redundant guarding inputs and independent monitoring channels improve this tree significantly.
Loss of safe-speed monitoring. For collaborative robots, the top event might be “robot exceeds safe speed limit during human-robot collaboration mode.” The tree expands to: speed monitoring failure AND unsafe speed commanded. Each branch then expands to the sensor, control, and communication failures that could produce it.
Navigation hazard in AMR applications. For autonomous mobile robots, a common top event is “AMR fails to stop before collision with person.” The tree expands into sensor failure modes (detection failure), control system failures (stop command not executed), and human behavior scenarios (person enters path faster than detection range allows). This tree typically reveals that detection range and stopping distance under sensor degradation are the dominant cut sets.
What good FTA looks like in an assessed safety case
Assessors evaluating a fault tree want the same properties they want from every safety case artifact: traceability, documented rationale, and consistency.
The top event traces back to the HARA. The fault tree should reference the hazard it analyzes and the required integrity level derived from the risk assessment. An FTA in a safety case with no explicit connection to a HARA entry is floating — it exists, but it doesn’t support the argument.
Gate logic is documented. Why is the relationship between these two events AND rather than OR? The tree structure implies a causal model. That model should be justified, especially at the higher levels of the tree where the assumptions have the most impact on the overall probability estimate.
Component data is sourced. Where do the failure rates come from? Manufacturer specifications, applicable databases, or reasoned conservative estimates? An FTA without sourced data is an assertion, not an analysis. Assessors will ask, and the answer needs to be documented in the tree or its accompanying notes.
Cut sets are identified and prioritized. The analytical output of the FTA is the cut set evaluation. A tree with no cut set analysis is an incomplete analysis.
ASAP maintains FTA artifacts with links to the hazards they analyze and the safety requirements they support. When a component is revised, the tree can be updated in context with the rest of the safety case rather than as an isolated document requiring manual re-integration.
FAQ: Fault Tree Analysis
What is fault tree analysis (FTA) in functional safety?
Fault tree analysis is a deductive technique that maps the combinations of component failures and events that can cause a specific top-level hazardous event. You start with the hazardous outcome and work backward to identify the minimal combinations of basic failures — cut sets — that would produce it. FTA is used to demonstrate that a safety architecture meets its required probability of dangerous failure and to identify the dominant failure modes that drive system-level risk.
What is the difference between FTA and FMEA in functional safety?
FTA is top-down: you start with a hazardous outcome and work backward to its causes. FMEA is bottom-up: you start with component failure modes and work forward to their effects on the system. Both are used in functional safety, often together. FTA is better for identifying combinations of failures that lead to a specific outcome. FMEA is better for ensuring all failure modes of all components have been considered.
What is a minimal cut set in fault tree analysis?
A minimal cut set is the smallest combination of basic events whose simultaneous occurrence causes the top event. “Minimal” means removing any event from the set would mean the top event no longer occurs. Single-event minimal cut sets (single points of failure) are the most critical — they mean one component failure alone can cause the top hazardous event. Identifying and eliminating single-event cut sets is a core goal of fault tree analysis in safety architecture design.
How does fault tree analysis relate to SIL or PL requirements?
FTA provides the quantitative basis for claiming a safety function achieves a specified integrity level. If your HARA determined that a safety function must achieve SIL 2 (probability of dangerous failure per hour below 10² to 10³), your FTA — using component failure rate data — demonstrates that the architecture you’ve designed can meet that target. Without FTA (or a comparable quantitative analysis), the SIL or PL claim is unsupported.
What failure rate data sources are used in fault tree analysis?
Common sources include: manufacturer-supplied failure rate data for specific components, IEC 61709 and SN 29500 for electronic components, OREDA for process industry equipment, MIL-HDBK-217F for military electronics (used conservatively), and IFA data tables for safety components. The source matters — assessors will ask where your failure rates came from, and unsourced rates don’t support the argument. Document the source alongside the value.
This post covers general functional safety engineering principles and is for educational purposes only. It is not engineering advice. Consult a qualified functional safety professional and your applicable standards body before making safety-critical design decisions.
ASAP maintains FTA artifacts linked to the hazards and safety requirements they support, so your fault tree analysis stays current as the design evolves. See how it works.