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/Mmax 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 Mmax |
| 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 answer to the second question is a closed list. There are four kinds of scheduled task, and a failure mode either qualifies for one of them or it does not:
| Scheduled task | What it does | Applicable when | The failure pattern it suits |
|---|---|---|---|
| On-condition | Inspects for a defined potential-failure condition and acts before the function is lost; the item stays in service until it shows the condition | A measurable degradation precedes failure, with enough warning to act on and enough consistency to plan against | Any mode with a physical ramp behind it: detectability, not age, is the qualifying property |
| Scheduled restoration | Reworks or overhauls at or before a stated age to restore the item's resistance to failure, whatever its measured condition | An age exists at which the conditional probability of failure climbs, most units survive to reach it, and the work genuinely restores the original resistance | Wear-out, β > 1 |
| Scheduled discard | Retires the item at a stated life limit | The same age condition, plus an item that can only be replaced rather than restored | Wear-out, β > 1; one-shot and life-limited parts |
| Failure-finding | Checks whether a hidden function has already failed, and repairs it if so; it prevents nothing | The failure is not evident to the operating crew in normal duty, and no on-condition or age-based task applies | Constant hazard, β ≈ 1: the pattern is irrelevant, because the task does not touch the failure process |
Two structural facts about the list matter more than the names. The middle pair need an age to work against. Against a genuinely constant hazard, scheduled restoration or discard buys nothing at all and simply consumes life at no benefit. The induced-failure penalty is additional and applies where the item has an infant-mortality region (the wear-in of pattern F), which is the common real case and is why intrusive scheduled work can make reliability worse rather than merely neutral. And all four carry an interval, but the intervals come from different places. The age tasks read theirs off the fitted life distribution: the 13,000-hour B10 replacement argument on the railway page is a scheduled-restoration interval derived exactly that way. An on-condition interval has to be computed from the detection window, and a failure-finding interval from a hidden-failure allowance, and those two are where most RCM reviews stop short: the task gets named in the worksheet and its number is left to whatever the maintenance calendar already offered. MSG-3 arranges the same decision into its own task list, adding lubrication and servicing as a category and splitting the checks by how they are performed; the four above are the ones the analysis turns on. The two non-tasks, run to failure and redesign, sit outside the list and are what remains when nothing in it is both applicable and worth doing.
The P-F interval sizes an on-condition task. A degrading item passes two points on its way down: a potential failure, the earliest condition an inspection can recognise (a motor-current signature drifting, a crack reaching detectable length, a bearing changing its vibration spectrum), and the functional failure at which it stops doing its job. The elapsed time between them is the P-F interval, and it is the whole basis of condition-based maintenance. A task that cannot fit inside that window is not applicable however good the sensor, which is why an on-condition proposal without a P-F estimate behind it has not yet been analysed. With inspection interval I and P-F interval P, an inspection is certain to fall inside the window only if I ≤ P, and the warning guaranteed to survive the inspection that finds the condition, the net P-F interval, is
Pnet = P − I
Because the P point is unobserved and can fall anywhere between two inspections, practice halves the interval again:
I ≤ P / 2
so that at least one inspection lands inside the window even if one is missed or comes back inconclusive, and so that at least half the window survives as lead time. The factor of two is common condition-monitoring practice rather than a requirement written into any standard.
Work it on the level crossing's barrier drive, whose rising hazard is exactly what makes the degradation visible (the testability page develops that point). Two windows meet on this item and they are not the same quantity. The testability page's four years is a population age trend, the hazard ramp from h(8,760) = 11 per 10⁶ h to h(43,800) = 47 per 10⁶ h, and what it supports is a scheduled-restoration date. The drive's P-F interval of 600 hours is the other thing entirely: one item's distance between a motor-current signature that has begun to drift and a boom that will not lower. That 600 hours is illustrative, unlike the proving-switch numbers below, which are the crossing's canonical values. The sizing rule gives
I ≤ 600 / 2 = 300 h
twelve and a half days. The crossing's access calendar does not offer that. Corrective night possessions can be called nightly, which is where the railway page's seven-hour access wait and 24-hour overrun come from, but a planned inspection slot is granted only fortnightly, so the shortest interval a scheduled on-condition task can actually hold is I = 336 h. That exceeds 300 hours, so the task fails its own sizing rule; and the warning it guarantees, Pnet = 600 − 336 = 264 h, is eleven days, against a possession that has to be booked further ahead than that. Delivered instead by continuous remote monitoring, the same task has an inspection interval measured in minutes: detection happens effectively at the potential-failure point, and close to the full 600 hours is available for scheduling. The threshold works in two steps. Where the access calendar exceeds the P-F interval the manual task is not applicable at all; where it exceeds half the P-F interval the task no longer meets the sizing convention, and its net warning has to be checked against the planning lead time explicitly. It is the second of those that disqualifies the manual task here, which is the same conclusion the railway page reaches from coverage and access delay, reached here from the detection window instead.
A failure-finding interval is solved for, not chosen. The task prevents nothing, so it cannot be justified on failure rate; what it controls is how long a hidden failure stays hidden, and its currency is therefore the average latent unavailability of the dormant item between checks, the sawtooth of the availability foundations:
Ulatent = λDU × T / 2
One quantity, three names: the availability topic calls it Qavg, functional safety calls it PFD, and it is the testability page's Ulatent. The form holds while λDU·T ≪ 1, and while the proof test is assumed to reveal the whole dangerous undetected mode with the test and repair themselves taking negligible time; a partial-coverage proof test leaves a residual term no interval can buy back. Because Ulatent is linear in T, an allowance allocated by the safety or availability case inverts straight into the interval:
T = 2 × Ulatent / λDU
The level crossing's barrier-down proving switch is this calculation in its cleanest form. The switch confirms that the boom is physically down, its dangerous undetected rate λDU is 0.9 per 10⁶ hours, and nothing in normal operation exercises it. Against an allocated allowance of 1.0 × 10⁻³ of latent unavailability:
T = 2 × 1.0 × 10⁻³ / (0.9 × 10⁻⁶) = 2,222 h = 93 days
taken as a 90-day cycle, T = 2,160 hours, which achieves
Ulatent = 0.9 × 10⁻⁶ × 2,160 / 2 = 9.7 × 10⁻⁴
inside the allowance. Nothing about that interval came from a calendar, and nothing about it could have come from the failure-rate Pareto either: the switch is 0.046% of the crossing's total rate and would be last on any λ-weighted list, while the SIL 4 argument draws a factor of about a thousand from its unavailability.
That is why an interval sized this way is a safety parameter and not a scheduling preference. Fold the check into the annual visit because somebody is on site anyway, and the same arithmetic returns 0.9 × 10⁻⁶ × 8,760 / 2 = 3.9 × 10⁻³: the hidden unavailability rises by the ratio of the intervals, 8,760 / 2,160 = 4.1, and the argument resting on it fails silently, because nothing observable changes on the day the interval slips. An interval that was solved for is a requirement with a derivation attached, and it belongs in the maintenance contract on the same footing as a failure rate, stated with the allowance it was computed from, tracked so that a missed check raises an event through FRACAS, and defended against the consolidation pressure that folds small checks into large visits. The same standing applies to an on-condition interval whose consequence class is safety: the P-F window owns that number, not the depot's planning cycle.
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.