Maintainability's quantitative core mirrors reliability's with the clock reversed: instead of asking how long a working item survives, it asks how long a failed item stays failed. Repair completion time is the random variable, a distribution describes it, and everything a programme quotes (MTTR, percentile times, downtime, man-hours) is a summary of that distribution. This chapter builds the machinery: the maintainability function, the point measures and their traps, the anatomy of a corrective action, the distributions that fit real repair data, and how the numbers are estimated and demonstrated.
The maintainability function
Let T_m be the time to complete a maintenance action, measured from its start under stated conditions. The maintainability function M(t) = P(T_m ≤ t) is the probability that the action is finished by elapsed time t. It is the mirror image of the reliability function: R(t) starts at 1 and falls as failures accumulate; M(t) starts at 0 and rises as repairs complete. A maintainability requirement is a point pinned onto this curve: "90% of corrective actions complete within 60 minutes" is M(60 min) ≥ 0.90, no more and no less.
The analytic workhorse is the constant-repair-rate model. If completions arrive with constant rate μ among still-open repairs, then
M(t) = 1 − e^(−μt), with mean repair time 1/μ
exactly parallel to the exponential life model, and convenient for the same reason: it makes the availability mathematics linear and gives closed forms for repairable-system models. It carries the same warning label, too. Real corrective actions are not memoryless: a repair that has run three hours is usually a difficult repair, not a fresh one, so the true completion rate is not constant. The exponential repair model is an engineering convenience to be used where its errors do not matter (long-run availability arithmetic) and avoided where they do (percentile commitments, staffing decisions).
Point measures and their traps
| Measure | What it is | The trap |
|---|---|---|
| MTTR (or M̄ct) | Mean corrective time: total active corrective time divided by the number of repairs, at a stated level of repair | Active time only, at one echelon; it is not the downtime the operator feels |
| M̄pt | Mean preventive maintenance time per action | Often quoted per action while the burden driver is frequency × duration |
| M_max | Percentile corrective time, classically the 90th or 95th | The commitment that actually protects operations; a mean cannot |
| MDT | Mean downtime: active repair plus logistics delay plus administrative delay | The number availability actually feels; blaming MTTR for an MDT problem fixes the wrong thing |
| MLDT | Mean logistics delay time: waiting for spares, people, transport | A support-system property, not a design property; separate the ledgers |
| MMH/OH | Maintenance man-hours per operating hour | Labour, not elapsed time: three technicians for one hour is one hour of MTTR and three of MMH |
Two of these traps sink real programmes often enough to name explicitly. First, the mean-versus-percentile trap: repair-time distributions are strongly right-skewed, so the mean is dragged upward by a minority of long repairs and can sit far above the median. A fleet can meet a 40-minute MTTR while a repair in ten blows a two-hour maintenance window, which is why demanding requirements are written on M_max percentiles, with MTTR as a companion. Second, the MTTR-versus-MDT trap: MTTR is a design property measured wrench-in-hand; downtime adds everything the support system wraps around it. Both matter, but they are owned by different people and fixed by different budgets. A contract that specifies only MTTR has quietly declined to buy short downtime.
Units carry the same discipline as reliability's: repair times in hours or minutes at a stated level of repair, man-hours as a separate ledger, and every number tagged with the maintenance conditions (skill level, tools, documentation state) it was measured under.
Anatomy of a corrective action
The corrective clock decomposes into task elements, and the decomposition is where design meets the stopwatch. The classic chain (the military handbooks enumerate localization, isolation, disassembly, interchange, reassembly, alignment, and checkout; preparation is the practical step in front of them):
| Element | The question it times | The design lever that compresses it |
|---|---|---|
| Preparation | Tools, safety isolation, documentation in hand | Standard tools, captive hardware, clear procedures |
| Fault localization | Which subsystem is misbehaving? | Monitoring, alarms, operator indications |
| Fault isolation | Which replaceable unit is at fault? | Built-in test resolution: the testability coverage numbers |
| Disassembly (access) | Can the unit be reached? | Layout, access panels, nothing-on-top-of-anything design |
| Interchange | Remove and replace the unit | Modularity, connectors over solder, guides and keying |
| Reassembly | Put the system back together | Fewness of fasteners, impossible-to-invert fits |
| Alignment and calibration | Does the new unit need tuning? | Self-calibration, stored settings, no-adjustment design |
| Checkout | Is the system verifiably healthy again? | Built-in verification, unambiguous pass indications |
The split matters because the elements respond to different investments, and because their weights have shifted historically: in electronics-dense systems the diagnosis pair (localization plus isolation) commonly dominates the total, which is why testability coverage is the first number to check when a predicted MTTR looks unreachable. The elemental times are also the raw material of prediction: maintainability prediction methods in the MIL-HDBK-472 lineage estimate a design's repair times by scoring or tabulating exactly these elements against the design's features, long before hardware exists to time.
Repair-time distributions
Repair-time data across industries shows a stubbornly consistent shape: most actions cluster around a typical value, and a long right tail of difficult cases (misdiagnosis, seized fasteners, missing spares, second faults found) stretches far beyond it. The lognormal distribution is the classic model for exactly this behaviour, and has been the default for corrective repair times since the discipline's military-handbook era. Its parameters read naturally: the median t_med is the "typical repair", and the shape σ measures the spread of the multiplicative factors that make real repairs run long or short. Key working relations:
- mean = t_med × e^(σ²/2): the mean exceeds the median, always, by the tail's pull
- percentile: t_p = t_med × e^(z_p·σ), with z_p the standard normal quantile
A worked instance shows the arithmetic a requirement writer needs. Take a repair population with median 24 minutes and σ = 0.7. The mean is 24 × e^0.245 = 30.7 minutes: already 28% above the median. The 95th percentile is 24 × e^(1.645 × 0.7) = 76 minutes: more than three times the median, and that, not 24 or 31, is the number a maintenance window must absorb. The same design would honestly report MTTR ≈ 31 min and M_max(95%) ≈ 76 min, and both belong in the specification.
| Distribution | Where it fits maintenance data | Notes |
|---|---|---|
| Lognormal | Corrective repair times, diagnosis-heavy work | The default; matches the multiplicative, long-tailed reality |
| Exponential | Analytic availability models | Convenience model; wrong shape for percentile commitments |
| Normal | Well-practised, fixed-scope tasks (routine servicing, scheduled swaps) | Fits when variation is additive and small |
| Weibull | Mixed task populations, empirical fits | Flexible fallback when data rejects the lognormal |
Estimating, predicting, demonstrating
Three different evidence sources feed the same measures, in programme order. Prediction comes first: while the design is on paper, elemental task times are estimated from the design's features (access, fasteners, test resolution, module weight) using the tabulated and scoring methods of the MIL-HDBK-472 lineage, rolled up per failure mode and weighted by the predicted failure rates. The output is a predicted MTTR and percentile per unit and per system, and its honesty depends on two inputs the maintainability engineer does not own: the failure-rate weights and the claimed fault-isolation coverage.
Demonstration converts the prediction into evidence on real hardware: a sample of faults is physically inserted or simulated, technicians of the specified skill level repair them using the specified documentation and tools, and the observed times are tested statistically against the requirement (the MIL-STD-471 lineage catalogues the sampling plans and accept/reject mathematics, built around the lognormal assumption). The classic demonstration failure modes are selection bias in the fault sample (only the easy faults get inserted) and condition drift (an engineer hovering behind the technician is not a stated condition).
Field measurement is the final authority and the messiest: real event logs mix active time with logistics and administrative delay, clocks start and stop inconsistently, and multiple-technician actions blur elapsed time against man-hours. The working rules: define the clocks before collecting (what starts MTTR, what starts MDT), record man-hours separately from elapsed time, and keep level-of-repair boundaries explicit so bench times and flight-line times never average together. Cleanly collected, field repair data closes the loop exactly as failure data does for reliability: it recalibrates the predictions, exposes the ambiguity groups the testability analysis overpromised on, and hands FRACAS its maintainability-flavoured findings.