A dependency model is easy to build and easy to build optimistically, and an optimistic one produces exactly the report the programme wanted.
| Pitfall | What it looks like | The guard |
|---|---|---|
| Counting faults instead of weighting them | 90 per cent detection because 9 rows of 10 are covered | Weight every figure by failure rate; the rates come with the modes |
| Isolation quoted over all faults | A design with poor detection reporting excellent isolation | Isolation is a share of what is detected, and the base is stated |
| A fault list that is not the FMECA's | A separate spreadsheet, drifting from the worksheet within a month | One mode list, read from the FMECA, rates attached |
| Items instead of modes | One row for "valve", not one for fails-open and one for fails-shut | Modes, because different modes have different signatures |
| Optimistic cells | A one wherever the test "should" respond | The source of each cell recorded: path, simulation or judgement |
| Only tests that already exist | The matrix built from the current BIT, so the answer is the current BIT | Candidate tests include ones nobody has built; that is how they earn funding |
| Detection and isolation treated as one goal | A single testability percentage in the requirement | Two requirements, because two different tests satisfy them |
| No false alarm figure | Detection and isolation reported, believability unaddressed | The third number, from test design and field data, beside the other two |
| The level of repair left unstated | "95 per cent isolation" with no unit named | The level is the first line of the report |
| A test that responds late | A parametric drift marked detected because the threshold is crossed eventually | Detected at the point it matters, or recorded as detected only at the scheduled check |
| Multiple faults ignored silently | Signatures computed one at a time, no note of it | Stated as an assumption; two faults can name an innocent item |
| The strategy written by hand | A manual whose fault tree disagrees with the BIT's order | Derive both from the matrix |
| Ambiguity groups sorted by size | A five-way group of reliable parts chased before a two-way group carrying a fifth of the rate | Sort by rate, and by removals, not by size |
| The model frozen | The matrix at PDR, the design three revisions later | Re-run when a mode is added, an α corrected, or a signal path removed |
Two of these deserve a closing sentence each. Building the matrix only from tests that already exist is the one that wastes the analysis entirely: run that way, it can only ever confirm what the current design achieves, and its most valuable output, the case for one more observation point, cannot appear. The worked example's bias monitor is exactly such a test, and it is worth 6.2 points of isolation for the price of a sense resistor.
And the missing false alarm rate is the one that quietly invalidates the rest. Detection and isolation describe what the equipment can determine. Whether anybody acts on that determination is decided by how often it has been wrong before, and a diagnostic system that cries wolf is functionally identical to one with no coverage at all.