RAMSynapse
Log inSign up

Testability · Chapter 3

From Components to Systems

How the property composes across series structures and redundancy.

Coverage numbers are computed per unit and experienced per system, and the translation follows the same rate-weighted logic as every other rollup in this Concepts row, with one twist of its own: diagnosis has boundaries. A failure detected inside a box is not necessarily isolated at the platform; a symptom visible at the system level may implicate three boxes and the cables between them. This chapter rolls coverage up, follows the undetected fraction to its two destination ledgers, examines the boundary problem, and turns coverage into an allocatable budget.

Rolling coverage up

System-level detection coverage is the failure-rate-weighted average of unit coverages:

FFD_sys = Σ(λᵢ × FFDᵢ) / Σλᵢ

and the weighting produces the familiar Pareto behaviour: the units that fail most set the system's coverage, and a single high-rate, poorly instrumented unit drags the whole platform. A worked rollup on the drive cabinet from the maintainability book, reusing its rates:

Unitλ (per 10⁶ h)Unit FFDUndetected λ
Power module1200.956.0
Fan tray2000.984.0
Contactor group250.6010.0
Encoder interface450.904.5
Controller card600.971.8
Cabinet450FFD_sys = 0.94226.3

Two readings. First, the system detects 94.2% of its failure rate, a respectable headline. Second, and more usefully, the undetected-λ column is the design agenda: the contactor group, a modest contributor to failures, is the largest single contributor to silent failures, because its 60% coverage leaves 10 per 10⁶ hours unannounced. The undetected column is a different Pareto from both the failure-rate one and the downtime one, and it points investment at monitors rather than at components or spares. Isolation rolls up the same way, with the ambiguity structure attached: system FFI is the rate-weighted share of detected failures whose signature resolves to one unit, and the cross-unit ambiguity groups (next section) live in exactly this rollup.

Where the undetected fraction goes

Every failure takes one of two roads. Detected, it enters the announced ledger: the repair clock starts, availability pays the downtime, and the record is truthful. Undetected, it enters the latent ledger: unavailability grows with the exposure interval, redundancy quietly thins, and a protective function's silence becomes a probability of failure on demand.
Every failure takes one of two roads. Detected, it enters the announced ledger: the repair clock starts, availability pays the downtime, and the record is truthful. Undetected, it enters the latent ledger: unavailability grows with the exposure interval, redundancy quietly thins, and a protective function's silence becomes a probability of failure on demand.

The complement of detection coverage is not a rounding error; it is a population of failures with a different physics of consequence. An undetected failure pays no downtime today and compounds instead:

  • In the availability ledger, it is the latent unavailability of the sawtooth model: invisible until the next proof test, periodic exercise, or demand, contributing λT/2 on average across its exposure interval. The undetected 26.3 per 10⁶ hours of the cabinet above, if exercised only by a quarterly functional check, is quietly worth more steady-state unavailability than several of the announced failure modes put together.
  • In the redundancy arithmetic, it is the assumption-killer: a standby channel with an undetected fault converts the pair's q² promise back into a single string, and nobody has been told. This is why the availability systems chapter lists detection among the product rule's fine print, and why redundant architectures deserve the richest monitoring, not the poorest: the whole value of the second channel rides on knowing its state.
  • In the safety ledger, it is the raw material of hidden dangerous failures: the fraction of a protective function's failure rate that neither self-reveals nor gets caught between proof tests is the core of its probability of failure on demand, and fault-tree analyses of protection systems are, operationally, audits of the undetected fraction.

The unifying discipline is to treat 1 − FFD as a first-class design output with its own budget and its own review, rather than the residue left over after the detection slides are done. The question "which modes are in the undetected fraction, and what exercises them, how often?" is the single most productive question a testability review can ask.

Diagnosis across boundaries

Coverage claims live at levels, and the levels do not automatically compose. The platform's continuous monitoring detects that the navigation function is degraded; the cabinet's BIT isolates to a card group; the shop's test equipment convicts the card; and between these levels sit the classic boundary pathologies. Cross-unit ambiguity: a symptom consistent with the sensor, the processing card, or the cable between them forms an ambiguity group that spans organizational boundaries, and the cable (the suspect with no BIT of its own) is routinely the actual culprit and the last to be checked. Level mismatch: a mode detected at the platform but only isolable at the shop still costs a removal-and-pipeline cycle per event; detection without matching isolation buys awareness, not speed. Interface ownership: when the group spans two suppliers' boxes, each vendor's unit-level analysis can be simultaneously flawless and jointly useless, because nobody's dependency model contains the interconnect.

The design responses are structural, which is why they belong in this chapter rather than the design one alone: partition the system so that diagnostic boundaries coincide with replaceable-unit boundaries; give interconnects explicit test coverage (loopbacks, wrap tests, boundary-scan chains across connectors in electronics); and write the isolation requirements at the maintenance level where the action happens (isolate to one LRU at the line; to one SRU at the shop), so that every coverage number has an echelon attached, exactly as every repair time did in the maintainability book.

Budgeting coverage

Like every property in this row, testability becomes manageable when the system target is decomposed into unit budgets. A platform requirement (detect 95% of failure rate; isolate 90% of detections to one LRU, 98% to three; false alarms below a stated rate) flows down the same tree the reliability allocation used, weighted by the same λs, and lands on each unit's designer as a pair of numbers they can trade against locally: monitors and test points against coverage, thresholds and persistence against false alarms. The budget's audit trail is the dependency model: each unit's claimed FFD and ambiguity structure, rolled up, either reproduces the platform numbers or shows exactly where the shortfall lives.

Two allocation habits pay for themselves. Weight the budget by consequence, not just rate: modes feeding safety functions or redundancy health deserve detection floors regardless of their λ, because their undetected cost is measured in the PFD and q²-collapse ledgers rather than in repair hours. And budget the false alarms too: an unallocated false-alarm requirement migrates to whichever unit was designed last, and the platform's credibility is then set by its noisiest box. The coverage budget, the false-alarm budget, and the undetected-fraction review together make testability a managed property; the alternative, discovered in service one RTOK Pareto at a time, is the expensive version of the same information.


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