Nothing in the previous chapters happens by itself. Short repairs are built, not wished for, and the building happens in the same window where reliability is decided: while the layout, the partitioning, and the diagnostic architecture are still drawings. This chapter covers the design levers, the programme machinery that makes maintainability a managed property with budgets and evidence, and the discipline that chooses the maintenance itself: which tasks, at which intervals, for which failure modes.
The levers of design for maintainability
| Lever | What it shortens | The check |
|---|---|---|
| Accessibility | Disassembly and reassembly: reach, clearance, nothing stacked on the failure-prone | Access and layout reviews against the task analysis |
| Modularity and LRU partitioning | Interchange: pull one unit, not a nest of parts | LRU/SRU structure review; level-of-repair analysis |
| Built-in test and diagnostics | Localization and isolation: the dominant elements in electronics-dense designs | Testability analysis: coverage and ambiguity numbers |
| Standardization | Preparation: common fasteners, common tools, common procedures | Tool-count and parts-variety audits |
| Captive and keyed hardware | Reassembly errors: bolts that stay put, connectors that fit one way | Design rules; maintainer-in-the-loop mockup trials |
| Self-verification | Checkout: the system proves its own health after repair | Verification coverage in the test design |
| Human factors | Everything: lifting weights, work postures, lighting, labelling, error traps | Task analysis with real technicians, early mockups |
Two habits separate programmes that get this right from those that discover it in service. First, the maintainer is a design input: the stated skill level, tools, and environment from the definition are design constraints, and a repair that works only for the engineer who designed the unit fails its own specification. Second, the failure modes choose the priorities: levers are applied where the λ-weighted downtime Pareto from the systems chapter says the downtime actually lives, not uniformly. Gold-plating access to a unit that never fails is the maintainability version of gold-plating every part's quality grade.
The maintainability programme
Maintainability runs the same phased programme logic as reliability's, with its own documents and its own evidence chain:
| Phase | The question | The activities |
|---|---|---|
| Concept | What maintenance environment, and what downtime can operations afford? | Maintenance concept (echelons, skills, support equipment); MTTR/M_max allocation down the structure |
| Design | Will this design meet its repair-time budgets? | Maintainability prediction; maintenance task analysis; testability allocation; access and human-factors reviews |
| Verification | Can we prove it, on hardware, with real technicians? | Maintainability demonstration: inserted-fault samples, statistical accept/reject against MTTR and M_max |
| Production and fielding | Does the delivered system match the demonstrated one? | Documentation and tooling delivery, training, support-equipment fielding |
| Field | What are repairs actually costing? | Maintenance data collection, observed-versus-predicted comparison, FRACAS closure |
The document lineage behind this structure is worth knowing because its vocabulary persists in every specification. The US military standards of the 1960s established the quantitative programme (prediction methods in the MIL-HDBK-472 lineage, demonstration in the MIL-STD-471 lineage, programme requirements in MIL-STD-470's); the 1990s acquisition reform folded the requirement documents into guidance, with MIL-HDBK-470A, Designing and Developing Maintainable Products and Systems, as the consolidated handbook of the discipline. On the international side the IEC 60706 series, Maintainability of Equipment, carries the equivalent design-phase, verification, and data-collection guidance under the IEC dependability umbrella. As with reliability, the task names survived the documents: allocate, predict, analyse tasks, demonstrate, measure.
One programme artefact deserves special emphasis because everything else references it: the maintenance concept. Written at concept stage, it states who maintains the system, where, with what skills, tools, and test equipment, and to what echelon structure. Every repair-time number in the programme is conditional on it; every prediction, demonstration, and contract percentile silently cites it. Programmes that let the maintenance concept drift (a depot consolidation here, a skill-level change there) invalidate their maintainability evidence without touching the hardware.
Choosing the maintenance itself
Maintainability determines how fast maintenance goes; a separate discipline decides what maintenance should be done at all, and its modern form began as a heresy. The reliability-centred maintenance studies of the airline industry, consolidated in Nowlan and Heap's 1978 report for the US Department of Defense, examined the assumption underneath traditional overhaul schedules (that equipment wears out on a calendar, so periodic restoration preserves reliability) and found it false for most complex-equipment failure modes: the majority showed no wear-out region that scheduled overhaul could exploit, and intrusive overhaul itself induced infant-mortality failures. The conclusions rebuilt preventive maintenance on three questions that RCM still asks of every failure mode:
- What are the consequences? Safety, operational, economic, or hidden: the consequence class, not the failure rate, decides how hard to fight the mode.
- Is there an applicable task? A task is applicable only if the mode has a detectable degradation to inspect for (condition-based), a genuine wear-out age to restore at (the β > 1 signature from the reliability foundations), or a hidden function needing a periodic check.
- Is it worth doing? Otherwise: run to failure, or redesign if the consequences forbid it.
The aviation lineage of this logic (through the MSG series of scheduled-maintenance development documents) and its standardised evaluation criteria (SAE JA1011) matter to the maintainability engineer for one structural reason: the RCM output, the preventive task set and its intervals, is the other half of the maintenance workload that the design must make fast. A condition-monitoring task nobody can reach, or a periodic check that demands half a day of disassembly, is an RCM decision defeated by a maintainability one. The two analyses share the failure-mode inventory (the FMEA) and should share their review table.
The loop back from the field
Maintainability's field feedback is unusually rich because maintenance generates records by its nature: every work order carries times, parts, and findings. The loop's products, when a programme bothers to close it: observed MTTR and percentiles against the demonstrated values, with drift flagged to its cause (documentation rot, training decay, spares aging, or plain optimism in the prediction); no-fault-found rates per unit, the tell-tale of overpromised isolation coverage and the quiet destroyer of spares budgets; and elapsed-versus-man-hour ratios exposing where crew sizes, not designs, set the downtime. Routed through FRACAS alongside the failure findings, and through life data analysis where repair-time distributions themselves need refitting, this record is what turns the next programme's maintenance concept from an aspiration into an engineering document. The platform view of that loop belongs to the next chapter.