Functional Hazard Analysis · Chapter 6

Common Pitfalls

The mistakes seen in practice and the guards against them.

The characteristic failure of an FHA is not a wrong number. It is a missing row, and a missing row costs more than every other error in the safety programme combined, because nothing downstream can find it.

PitfallWhat it looks likeThe guard
Analysing boxesA worksheet whose first column is a list of equipmentThe first column is a function; the equipment does not exist yet
Only lossEvery row begins "loss of"Generate the grid: loss, partial, misleading, inadvertent, mistimed
Misleading output missedNo row where the system is confidently wrongThe row that usually carries the catastrophic classification
Phase ignoredOne row per functional failure, one classSame failure, two phases, two rows, two classes
Annunciation ignoredNo distinction between a flagged failure and a silent oneTwo rows, and the difference is usually a whole class
One function at a timeEvery row is a single function failing on its ownThe grid cannot generate combinations; add the pairs where one function is the fallback for the other
Classifying before describingColumn 5 filled, column 4 thinThe effect is the evidence; write it first, in the aeroplane's terms
Severity deflationAn argued path from Catastrophic down to Hazardous, one adjective at a timeClassify from consequence alone; mitigation moves probability, not severity
Crew action assumed silentlyA reversion to the standby buried inside the effect textState it as an assumption; it becomes a requirement on training and layout
Benign conditions assumedEffects written for daylight, calm air and a rested crewReasonably expected adverse operational and environmental conditions
At-risk time abusedA phase-limited condition averaged over the whole flightApply the criterion per flight or per cycle for phase-limited conditions
At-risk time inventedA window justified by a fleet-average weather statisticWindows are defined phases, not statistics; otherwise carry the whole flight
The band read as a rule"It is 1.2E-9, so we fail"The bands are orders of magnitude; the guidance allows a factor on them
The single-failure rule negotiatedAn extremely improbable single failure argued as acceptableNo probability argument buys relief, and a set of dependent failures is one failure
DAL treated as a budgetAn assurance level quoted as though it were a failure rateIt governs process rigour against errors, which have no rate
Sharing a level without independenceA + C claimed with no argument for how the two developments differThe independence argument is the deliverable, not the assignment
No verification columnConditions with objectives and no plan for showing complianceEvery condition names its fault tree, test or analysis
Written onceAn assessment dated at concept, never reopenedAllocation and integration both create new conditions; re-run at both
No merge recordFewer rows than the grid, no explanationRecord why rows were combined; it is the first question a reviewer asks

Four of these are worth a sentence more.

Missing the misleading row is the expensive one. Everything else in the assessment can be corrected later at the cost of rework. A missing failure condition produces an architecture with no defence against it, discovered either in a late review or in service, and both discoveries arrive after the design is fixed.

Severity deflation is structural, not personal. A catastrophic classification triggers the most expensive obligations in the programme, so the pressure to argue it down is permanent and comes from people acting reasonably. The only defence is procedural: classify from the consequence before any mitigation is considered, and require that a change of class be justified by a change in what actually happens, not by a change in how likely it is.

The single-failure rule is not a probability statement, and treating it as one is the most common misreading in this material. It is a statement about structure, and the definition of a single failure includes any set of failures that cannot be shown independent. That is why it is answered with a cut-set order and a common cause analysis rather than with a number.

An assurance level is not an item property. Saying an item "is DAL B" says how carefully it was developed. It does not say how reliable it is, it does not imply a failure rate, and it cannot be substituted for one in an availability argument. The two columns come from the same classification and answer different questions.


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