RAMSynapse
Log inSign up

RAMS Core

PublishedMIL-STD-2165 · IEEE 1522

Testability Analysis

The dependency model behind the detection and isolation figures: which test responds to which fault, and what that leaves ambiguous.

The testability concept page defines what detection and isolation mean and how they are measured: fault detection rate, fault isolation to one item or to a group, false alarm rate. Those are measurements of a finished machine. This module is how the same numbers are produced before there is a machine to measure, and the answer is a single object: a matrix of tests against faults.

Write the failure modes across the top and the available measurements down the side, mark a cell where the test responds to that fault, and every testability question becomes a reading of that grid. A column of zeroes is a fault nothing detects. Two identical columns are faults nothing can tell apart. A row of mostly zeroes is a test earning very little. The detection and isolation percentages are those readings weighted by failure rate, and the diagnostic procedure in the maintenance manual is the same grid searched in a sensible order.

The value is in when it can be done. A dependency model needs a functional breakdown and a list of candidate measurements, both of which exist long before hardware, so the analysis can change what gets built rather than describe what did.

What the analysis actually is

The whole analysis is one matrix: which test responds to which fault, with each fault's rate underneath. Reading down a column gives a fault's signature, reading across a row gives a test's coverage, and every metric the module reports is one of those two readings weighted by rate.
The whole analysis is one matrix: which test responds to which fault, with each fault's rate underneath. Reading down a column gives a fault's signature, reading across a row gives a test's coverage, and every metric the module reports is one of those two readings weighted by rate.

The technique has two names in the literature that mean the same thing. As a dependency model it is a graph: a fault propagates along signal paths to the points where a test can observe it, and the matrix is the reachability of that graph. As a fault-test incidence matrix it is just the table. Either way the analysis is:

StepProduces
Enumerate the faultsUsually the FMECA mode list, with rates attached
Enumerate the candidate testsBuilt-in test, external stimulus, an operator's observation, an off-line measurement
Mark the incidenceThe matrix, one cell at a time, from the design
Read the columnsUndetected faults, ambiguity groups, and the metrics
Read the rowsTest value, redundancy between tests, the diagnostic order

Where it sits, and what it is not

In from the FMECA, out to the built-in test design and to maintainability. The concept page owns the measures; this module owns the model that predicts them.
In from the FMECA, out to the built-in test design and to maintainability. The concept page owns the measures; this module owns the model that predicts them.

MIL-STD-2165 established testability as a programme activity with its own requirements, analysis and demonstration rather than as a by-product of design, and MIL-HDBK-2165 carries the guidance behind it. IEEE 1522 is the modern vocabulary for the metrics themselves, and MIL-STD-1309 is where the terms of test and diagnosis are defined so that two organisations arguing about a false alarm are arguing about the same thing.

Programme stageWhat the analysis is for
ConceptAre the measurements even available? Deciding what must be observable is a design requirement
Preliminary designThe first matrix: detection and isolation predictions against the requirement
Detailed designTest selection and placement, the diagnostic strategy, BIT specification
VerificationThe demonstration compares measured detection and isolation with these predictions

Three things it is not. It is not the FMECA: the modes come from there and this analysis adds only what observes them. It is not a false-alarm analysis: the matrix says what a test responds to, not how often it responds when nothing is wrong, and that needs its own treatment. And it is not a diagnostic tool by itself: it produces the strategy a tool or a manual then implements.

How RAMSynapse approaches this

The Testability module runs on the FMECA's failure modes rather than on a separate list, which is the integration that matters: a mode added to the worksheet appears in the testability model with its rate already attached, and the detection method recorded against that mode is where the matrix starts. Coverage is computed per mode and rolled up by failure rate, so fault detection and isolation figures are weighted results rather than counts of rows.

Because the modes carry their rates from the prediction through the FMECA, the three analyses agree by construction on what the equipment's failure rate is and on how it divides, which is the disagreement most often found when testability is worked in a spreadsheet of its own.

Link on the live registryWhat flows
FMECA → TestabilityFailure modes, their rates and their recorded detection method
Testability → MaintainabilityIsolation results: what a repair has to work through
Testability → dashboardsDetection and isolation coverage as a project figure

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