An FMECA starts at an item and works forward: this capacitor shorts, and here is what that does. A fault tree starts at the far end and works backward: this is the failure we cannot tolerate, and here is every combination of events that produces it. One is inductive and covers everything shallowly; the other is deductive and covers one thing exhaustively.
That difference decides what each is for. A fault tree is the tool for a failure condition somebody has already decided matters, usually because an FHA classified it and attached a budget to it. It answers two questions at once, and the second is the one that gets forgotten:
- How probable is it? A number, to compare with the objective.
- What has to happen for it to occur? The minimal cut sets, which say whether the architecture is acceptable at all, and which survive when the failure rate data is doubtful.
Where it sits
In the ARP4761 process a fault tree appears twice. In the PSSA it runs top-down on a proposed architecture, dividing an objective into budgets the items have to meet, and it is the analysis that tells a programme its architecture cannot work before the architecture is built. In the SSA it runs bottom-up on the implemented design, with real item rates from the prediction and mode data from the FMECA, and it shows that the objective is met.
The standard does not insist on the tree itself. Wherever a fault tree is called for, an equivalent dependence diagram or a Markov analysis may be used instead, and the choice is largely one of readability and of whether the system changes state during the mission.
What it is not
- Not a model of the system. It is a model of one way the system fails. Ten failure conditions mean ten trees, and they may share basic events and disagree about them if nobody checks.
- Not an FMECA, and not derivable from one. An FMECA enumerates single-item modes; a fault tree assembles combinations. Neither can be mechanically produced from the other.
- Not a reliability model with time in it. A static tree evaluates one mission or one interval. Repair, reconfiguration, imperfect switching and order-sensitive behaviour belong to Markov analysis.
- Not a way to give software a failure rate. Development errors can and should appear in a tree, but qualitatively: they show where an independence claim rests on the development process rather than on physics.
Where the discipline comes from
Fault trees came out of Bell Laboratories in 1962, on the launch control system of the Minuteman missile, and were taken up first by aerospace and then by the nuclear industry, whose 1981 handbook, NUREG-0492, fixed most of the notation still in use. IEC 61025 is the international standard for the technique itself. NASA's Fault Tree Handbook with Aerospace Applications (2002) is the freely available modern treatment, and the source of the symbol table this module follows. In civil aviation, SAE ARP4761 is what makes the analysis a certification artefact rather than an engineering preference: it supplies the process the tree lives in, the exposure-time forms for latent failures, and the reporting the authority expects.
| Programme stage | What the tree is doing |
|---|---|
| Concept | Testing whether a proposed architecture can meet an objective at all |
| Preliminary design | Allocating budgets down to items, and issuing them as supplier requirements |
| Detailed design | Absorbing real rates, exposure times and common cause results; finding the order-one cut sets |
| Certification | The compliance argument for each failure condition, with its cut sets and assumptions |
| In service | Re-quantified when field data contradicts an assumed rate or an assumed independence |