RAMSynapse
Log inSign up

FMECA · Chapter 6

Common Pitfalls

The mistakes seen in practice and the guards against them.

FMECA fails quietly. The worksheet is always finished, always long, and almost always reviewed by someone reading the severity column and nothing else. Every entry below produces a document that looks complete.

PitfallWhat it looks likeThe guard
The end effect never leaves the item"Capacitor short-circuits → DC link collapses → DC link collapses"The end effect is stated at the system boundary in the operator's words, or the row is not finished
Severity credited with the guardA Class I mode called Class III because a trip catches itClassify with compensating provisions removed; the guard gets its own column and its own analysis
One severity for all phasesA mode that is catastrophic in one phase carried at its mildest classificationPhase-dependent ratings, and the phase named in the end effect
Detection filled in with "BIT"Coverage assumed at item level, mode by mode never checkedAsk what the test measures and whether this mode changes it; an undetected Class I mode is a finding
α that never sums to oneA mode added later, the others left aloneΣα = 1 per item, checked mechanically
Generic α on a part with field dataA published distribution used where the fleet's own returns existThe α source is a recorded column; returns replace the library, not the other way round
β used as a fudgeCriticality tuned to a tolerable number by moving ββ takes one of four values, and the reason is written beside it
Criticality summed across classesA single "total criticality" for an item or a systemSum within a class only; there is no meaningful total
The exposure is the whole missionA start-up-only mode given the full mission timet is the exposure of that mode, phase by phase
The worksheet is written at one indenture levelEverything at part level, so no end effect is visible; or everything at box level, so no mode isThe level is a ground rule per assembly, and the effect columns cross levels by construction
RPN thresholds hiding severity"Below 100, no action", with severity 9 and low occurrence and detection scoresRank severity first; an action-priority table, not a product of ordinal scales
Interfaces owned by nobodyEvery box analysed, every connection between them unanalysedInterfaces are items with their own rows: connectors, harnesses, protocols, shared supplies
Software and human action out of scope by defaultA card's modes analysed, the code that drives it notScope is a ground rule; excluded classes are recorded as excluded
The analysis stops at the reportFindings raised, never dispositioned, the worksheet never re-runEvery finding has an owner and a decision; α and λp are refreshed from returns
Combinations smuggled in"Both channels fail" appearing as a rowOne failure per row; combinations belong in a fault tree or an RBD built from these mode rates

Two of these deserve a closing sentence each. Detection filled in without checking is the one that costs most, because it is the column the rest of the programme trusts most: a testability analysis, a diagnostic requirement and a safety argument can all be built on a BIT that was written to fill a cell, and none of the three has any way to discover it. The worked example's card is the illustration in reverse: the four modes that carry its entire catastrophic criticality are exactly the four where the detection column says "none", and the analysis is only worth anything because somebody wrote none rather than BIT.

And the worksheet that stops at the report is the most common of all. An FMECA is not a deliverable, it is a register: the modes stay, the ratios move as returns arrive, and the severity classes outlive several design iterations. A worksheet whose α column has never been touched by field data is still describing the assumptions it was born with, however many revisions its cover page has.


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