Testability is the most literal design-for-X discipline in this row: coverage is exactly as good as the monitors, test points, and partitioning drawn into the hardware, and no later phase can add what the architecture withheld. It is also the discipline with the strongest industrial success story, because electronics solved its own testability crisis by building test access into the silicon itself. This chapter covers the design levers, the craft of honest built-in test, the programme that manages coverage as a budget, and the production and field machinery that keeps the diagnosis truthful for decades.
The levers of design for test
| Lever | What it buys | The check |
|---|---|---|
| Partitioning along diagnosable boundaries | Ambiguity groups that match replaceable units; symptoms that name their box | Dependency-model signatures versus the LRU structure |
| Monitors and sensors placed for diagnosis | Detection of the high-rate and high-consequence modes where they happen | The undetected-λ Pareto from the systems chapter |
| Test points and stimulus paths | Reach for initiated tests; observability where CBIT cannot listen | Coverage of the modes assigned to the IBIT layer |
| Loopbacks and wraparound paths | Interconnect and end-to-end path coverage; the cable stops hiding | Cross-unit ambiguity groups in the rollup |
| Boundary scan and scan design | Structural test access in dense electronics, from board to system chain | Scan-chain coverage in manufacturing and the shop |
| Standard test interfaces and reporting | One diagnostic language across units, suppliers, and echelons | Integration of unit BIT into the platform's health picture |
| Status memory and time-stamping | Intermittents caught in the act; the crew report corroborated | CND rates: the intermittent that left no trace is a design gap |
Two of these deserve expansion. Partitioning is the quiet king: isolation resolution is set less by how many tests exist than by where the replaceable-unit boundaries fall relative to what the tests can distinguish, and a partitioning chosen for packaging convenience routinely manufactures ambiguity that no later BIT budget can undo. And boundary scan (the IEEE 1149.1 architecture) is the discipline's exemplary lesson: faced with boards too dense to probe, the electronics industry standardised a shift-register test path through every compliant device, making interconnect testing a structural property of the design rather than a heroic act of fixturing. The general moral generalises beyond electronics: test access designed in as infrastructure is cheap and permanent; test access improvised afterwards is expensive and partial.
Designing BIT honestly
Built-in test earns its coverage numbers only if it is engineered as a measurement system with a credibility budget, and the design habits that keep it honest are known:
- Assign every significant mode to a layer deliberately. The mode-by-layer assignment table from the foundations chapter is the BIT specification: continuous monitors for what operation exercises, power-up checks for readiness, initiated tests with real stimulus for the paths operation never drives, proof tests for the dormant remainder. Unassigned modes are the undetected fraction being chosen by default.
- Design the thresholds with the false-alarm budget open on the desk. Persistence counts, condition gating, and sensor voting are the levers; each buys false-alarm mass with detection latency, and the right setting differs between a nuisance caution and a flight-safety annunciation. A threshold set without a false-alarm budget is a credibility liability with a delivery date.
- Keep evidence for the intermittents. Latched fault words, environmental snapshots at trip time, and time-stamped event logs are what separate a fixable intermittent from a career of cannot-duplicates; the crew's report deserves corroborating data, not a shrug at retest.
- Verify the verifier. BIT hardware and monitors fail too; their failure modes belong in the FMEA like everyone else's, detected or conceded explicitly. A dead monitor is the purest form of hidden unavailability: it silences exactly the alarm someone is relying on.
The testability programme
The programme structure mirrors its siblings', with the dependency model in the role the prediction plays for reliability:
| Phase | The question | The activities |
|---|---|---|
| Concept | What must be detected, isolated to what, at which echelon, with what false-alarm ceiling? | Coverage and false-alarm targets, allocated down the tree with the λ budgets |
| Design | Will this architecture meet its coverage budget? | Dependency modelling from the FMEA; BIT layer assignment; partitioning and test-access reviews |
| Verification | Does the built system detect and isolate as claimed? | Fault-insertion demonstration: seeded faults, scored detections and isolations, statistical accept/reject |
| Production | Can the factory and shops test what the design promised? | Test-programme development, boundary-scan and ATE integration, echelon test equipment |
| Field | Is the diagnosis staying truthful? | CND/RTOK tracking, threshold tuning under change control, dependency-model updates |
The lineage documents are the ones already met in the overview: MIL-STD-2165 established the managed-programme form and survives as the MIL-HDBK-2165 guidance; IEC 60706-5 carries the international thread with its insistence that testability be considered early, when access is an architecture question rather than a retrofit; and the demonstration machinery (physically inserting a statistically designed sample of faults and scoring the system's answers) is the direct sibling of the maintainability demonstration, often run on the same events. The characteristic programme failure is phase-lag: a BIT design frozen against an FMEA two revisions old, demonstrating coverage of a failure-mode inventory the hardware no longer has. The dependency model is only an asset while it is configuration-managed with the design it describes.
Test in production and through the fleet's life
The same access that diagnoses field failures is the factory's quality instrument: boundary-scan chains and built-in self-test find assembly defects before power-up, and the shop's test programmes are the isolation layer of last resort for everything the line conceded. Designing these together, rather than as three uncoordinated test worlds (factory, line, shop), is what keeps a failure's story consistent as it moves through the echelons; the RTOK epidemic is very often a disagreement between test levels wearing the costume of unreliability.
In service, testability is the property most exposed to quiet decay, because it is software-adjacent: thresholds get "temporarily" widened to silence a nuisance, monitors get masked during a troubleshooting campaign and never unmasked, test programmes drift from hardware modifications. The countermeasure is to treat the diagnostic configuration as configuration: BIT thresholds, masks, and test-programme versions under the same change control as the hardware they judge, with the FRACAS CND/RTOK Pareto as the standing audit that catches decay early. A fleet whose no-fault-found stream is flat or falling is a fleet whose diagnosis is still telling the truth; that trend line is the simplest health indicator the whole discipline owns.