Fault tree analysis, standard by standard
Nearly every safety standard asks for fault tree analysis, and almost none of them asks for the same thing. The gate symbols are shared; the target numbers, the vocabulary for expressing them, the evidence a reviewer expects and the point in the lifecycle where the tree is produced all differ by domain. This page is the map: what each standard wants from FTA, where they genuinely agree, and where an assumption carried across from another industry will get a submission returned.
The one thing they agree on
Every standard here treats the fault tree as a deductive technique. You begin with an undesired system-level event and reason backwards to the combinations of lower-level failures that could produce it. That is the opposite direction from FMEA, which starts at a component and reasons forwards. The distinction matters because it determines what the analysis can and cannot show: a fault tree is complete with respect to the top event you chose and silent about everything else, which is why standards pair it with an inductive technique rather than accepting it alone.
They also agree on the notation. IEC 61025 defines the symbols, the semantics of each gate and the cut-set algorithm; the domain standards below reference it rather than redefining it. A tree drawn to IEC 61025 is readable by an assessor in any of these industries. What changes is everything around it.
What each one asks for
| Standard | Domain | Integrity scale | Where FTA sits |
|---|---|---|---|
| IEC 61025 | Any | — | The technique itself: symbols, gate semantics, cut sets, quantification |
| IEC 61508 | Functional safety (generic) | SIL 1–4 | Named for PFD / PFH verification of a safety function; the parent of most domain standards |
| IEC 61511 | Process industries | SIL 1–4 | Verifies that a Safety Instrumented Function achieves the SIL that LOPA required |
| ISO 26262 | Automotive | ASIL A–D | Deductive analysis at ASIL C and D; ASIL decomposition; hardware metrics |
| ARP 4761 | Civil aerospace | DAL A–E | The quantitative core of the System Safety Assessment |
| EN 50126 | Rail | SIL 1–4 | Hazard rate apportionment through the RAMS V-cycle |
| MIL-STD-882 | Defence | RAC matrix | Named in the hazard-analysis tasks feeding the Safety Assessment Report |
The ASIL ↔ DAL ↔ SIL crosswalk lays out how those integrity scales line up — and, more usefully, where the correspondence breaks down. They are not interchangeable: SIL is a property of a function and its demand rate, ASIL is derived from severity, exposure and controllability of a hazardous event, and DAL is a development-assurance level rather than a probability target at all. Treating a table of equivalences as a conversion is one of the more common ways a cross-domain safety case goes wrong.
Where the domains actually differ
What the number has to mean
IEC 61508 and IEC 61511 want an average probability of failure on demand, or a failure rate per hour for continuous-mode functions. ISO 26262 wants a probabilistic metric for random hardware failures, expressed per hour over the vehicle lifetime. ARP 4761 wants a probability per flight hour against the 14 CFR 25.1309 severity classes. EN 50126 wants a tolerable hazard rate per hour, apportioned down through the system hierarchy. These are not the same quantity dressed differently — mission time, demand mode and the population being averaged over all differ, and a number computed for one and reported against another is simply wrong.
How much independence you have to prove
Redundancy only helps to the extent that the redundant paths fail independently, and every standard here knows it. What differs is how much proof they demand. Common-cause failure modelling is mandatory in nuclear and process work, expected in rail, and in automotive it is the specific gate on whether an ASIL decomposition is permitted at all. In aerospace, Common Cause Analysis is a named companion activity that feeds back into the tree rather than a parameter inside it.
Who reads it, and what they are looking for
A tree written for an internal design review and a tree written for an external assessor are different documents. EN 50126 brings an Independent Safety Assessor; ARP 4761 submissions are read by FAA or EASA specialists whose job is finding the gap. Both expect the reasoning to be legible without the author present — which is a structural constraint on the tree, not a formatting one. Structuring a tree for review covers what that means in practice.
When in the lifecycle it is produced
Under IEC 61511 the fault tree comes after LOPA has set a target, and its job is verification. Under ARP 4761 the tree evolves from PSSA to SSA as the design firms up, so an early tree is a design tool and a late one is evidence. Under EN 50126 it appears repeatedly at different levels of the V. Producing the right artefact at the wrong phase is a common and expensive mistake — the analysis may be perfectly correct and still not be the deliverable that was asked for.
Standards referenced here without a page of their own
Several standards come up throughout this site because the pages above depend on them, but do not yet have a reference page: ISO 14971 (medical device risk management), IEC 60601-1 and IEC 62304 (medical electrical equipment and software), DO-178C and DO-254 (airborne software and hardware, the development-assurance side of ARP 4761), and NUREG-0492, the U.S. Nuclear Regulatory Commission's Fault Tree Handbook, which remains the most complete treatment of the technique ever written. Where one of these governs your work, the worked templates for that industry are the fastest way to see how the analysis is usually laid out.
Where to start
If you are new to the technique, read IEC 61025 first — everything else assumes it. Then read the page for the standard that governs your project, and work through the worked example, which builds a complete tree from a blank page and quantifies it. If you already have the analysis in a spreadsheet, import it directly rather than redrawing it.