Fault Tree Analysis · Chapter 6

Common Pitfalls

The mistakes seen in practice and the guards against them.

Fault trees fail quietly. The arithmetic is elementary, the tool always returns a number, and almost every serious error in a tree produces a result that looks entirely reasonable.

PitfallWhat it looks likeThe guard
A vague top event"Loss of braking" with no phase and no annunciation stateTake the wording from the classified failure condition, or do not start
Undeclared boundariesTwo branches quantified to different resolutionsScope, resolution, initial state and externals, written in the report
Skipping levelsA gate whose inputs are three levels below its outputOne immediate cause at a time; the skipped level held the shared event
AND gates asserted, not arguedTwo channels multiplied with no independence evidenceEvery AND is a claim the common cause analyses have to support
Repeated events multipliedThe same basic event in two branches, treated as twoBoolean reduction to minimal cut sets before any arithmetic
Mission time everywhereA latent monitor given the flight time as its exposureEvery basic event declares revealed, latent with interval T, or unavailable
Latency arithmetic guessedAn average exposure of T/2 substituted for the standard formsUse the four combination forms; the one-half is an average over flights
Reading the number firstA compliant total with an order-one cut set inside itCut sets by order, before the total
Order-one excused by probabilityA single failure defended as being extremely improbableNo probability argument relieves the single-failure rule
Conditional probabilities hiddenAn inhibit gate carrying 0.05 with no noteEvery conditional in the report, with the reasoning
Approximation unstatedA rare event sum presented as an exact resultSay which; where cut sets are not small, evaluate exactly
Units mixedPer-flight probability compared with a per-flight-hour objectiveOne average flight length for the whole programme
Software given a rateA basic event for "software fails" with a number under itErrors enter qualitatively; assurance level, not probability
Success and failure logic mixedNOT gates and complemented events used casuallyNon-coherent trees change what a cut set means; use a success tree deliberately
Diamonds left standingUndeveloped events at quantification timeCount them: they are unfinished work with no probability attached
A tree per analystTwo trees sharing a basic event at two different ratesBasic events resolve to items in one data set
Assumed intervals never issuedA 750 h test interval that exists only inside the modelIntervals become maintenance requirements, or the argument expires
Never re-runA tree quantified once at preliminary designRe-quantify at each design change, and when field data contradicts a rate

Four of these deserve more than a row.

The order-one cut set is the finding that gets argued with. It arrives with a small probability attached, and the discussion turns to whether the probability is small enough. It is not that kind of rule: a catastrophic condition may not result from a single failure, a single failure includes any set of failures that cannot be shown independent, and the answer is an architecture change. The arithmetic is not part of the conversation.

Exposure is where the orders of magnitude live. On the worked example, changing one test interval from 750 hours to a power-up check moved a branch by a factor of 375, with no new hardware and no better components. Nobody reviews exposure times with the attention they give to failure rates, and the exposure column is where the answer actually comes from.

Independence is a claim about the whole lifecycle, not about the drawing. Two channels can be electrically separate and still share a maintenance procedure, a calibration constant, a software component, a supplier's manufacturing process or a design assumption. The zonal, particular-risk and common-mode analyses exist to test exactly that, and an AND gate drawn before they are done is provisional.

The conditional probability is usually the answer. Trees are built from rates that trace to handbooks and field data, and then one inhibit gate carries a number somebody argued over lunch. On this module's example that number swings the result by two orders of magnitude and decides compliance. Report it in the open, run the sensitivity, and let the reader see what the case rests on.


Want to see this on a live system model? Request a walkthrough.