Availability is bought with three different currencies, and design's first job is choosing the exchange rate between them. Because A = MTBF/(MTBF + MTTR) only constrains a ratio, every availability target opens a trade space: fail less, recover faster, or architect so that failures do not interrupt at all. The wrong mix is expensive in both directions (gold-plated components propping up a starved spares budget, or heroic logistics compensating for a fragile design), and the right mix is an economic decision that shifts over the system's life. This chapter covers the three levers, the support system as an engineered product, the management of planned downtime, and the programme that keeps the whole account honest.
The three levers
| Lever | What it buys | Where it runs out | The analyses behind it |
|---|---|---|---|
| Fail less | Fewer downtime events at their source | Cost curve steepens; the last nines cannot be bought with MTBF alone | Reliability's design levers: margins, derating, simplification |
| Recover faster | Shorter events: design MTTR plus the whole logistics tail | The budget floor: even instant repair leaves the event's disruption | Maintainability's levers plus the support system below |
| Continue anyway | Failures that cost no mission time at all: redundancy, failover, degraded modes, buffers | Cost, weight, common causes, and the switchover's own risk | The composition rules; RBD and Markov trades |
The levers interact more than they compete. Redundancy multiplies the value of fast repair (the q² argument from the systems chapter); condition monitoring serves all three at once by converting unscheduled events into scheduled ones; and a degraded mode is only worth its complexity if the operations concept actually permits running in it. The practical method is to price each lever against the same downtime budget line: euros per avoided minute per year, computed with the availability model rather than intuition, because the model is where the nonlinearities (q², the logistics tail, the common-cause floor) live.
Engineering the support system
Operational availability makes the support system a design object with requirements, not an afterthought with a warehouse. Its elements each map to a slice of the downtime ledger:
- Spares drive MLDT harder than anything else. Stock levels, positioning (on-site shelf versus regional depot versus manufacturer), and repair-pipeline turnaround together set how often a failure waits for a part; sparing-to-availability models optimise stock against the Ao target directly, and the radar table showed why an on-site spare can outperform any feasible component upgrade.
- People and equipment coverage set the queueing behaviour: crew shifts, callout arrangements, test-equipment count. A single shared crew turns the parallel product rule optimistic exactly when the site is busiest.
- Transport, access and process fill the administrative slice: permits, approvals, customs for cross-border spares, the work-order system's own latency.
- Documentation and training protect the repair times the maintainability demonstration proved; both decay in service unless owned.
The contractual mirror of all this is performance-based logistics: instead of buying spares and repairs as transactions, the customer buys the outcome (availability, at a price per achieved percentage point or per mission-capable hour) and leaves the supplier to optimise the machinery behind it. Defence acquisition developed the model because Ao is its sustainment key performance parameter; the civilian version is the availability clause in a service-level agreement. Both work for the same reason the Ai/Ao split exists: they place the logistics ledger in the hands that can act on it, and they make the clock definitions a negotiated, audited artefact rather than a reporting convenience.
Planned downtime is designed downtime
The scheduled side of the ledger responds to design as strongly as the unscheduled side:
- Architect for online maintenance. Hot-swappable units, N+1 configurations that tolerate one member being serviced, isolation valves and bypass paths: each converts a system outage into a component outage. The maintainability design levers apply doubled, because access and interchange time spent inside a live system is availability spend at full price.
- Aggregate and compress the windows. The nuclear refuelling outage is the master class: years of preparation, a critical-path plan, prestaged parts and crews, and every task not on the chain parallelised, because the outage's length is a headline economic number. Scaled down, the same discipline applies to a factory shutdown week or a radar's maintenance night.
- Convert unscheduled to scheduled. Condition monitoring and prognostics move failures from the expensive ledger to the cheap one: a bearing replaced in a planned window at half-life costs a fraction of the same bearing seizing on shift. This is RCM's on-condition logic wearing its availability hat, and its value case is computed in exactly the downtime-budget currency this book has been using.
The availability programme
The programme structure mirrors reliability's and maintainability's, with the support system as a co-equal design object throughout: at concept, the Ao target is set together with the support concept and the clock definitions, then split into a downtime budget across subsystems and ledgers; through design, the RBD availability models and Markov studies of the redundant clusters track the budget while sparing models size the logistics; verification demonstrates the inherent quantities (MTBF and MTTR can be tested; Ao cannot, only modelled) and exercises the failovers; and operation closes the loop by measuring Ao against prediction, with each downtime hour categorised to its owner through FRACAS. The framing documents are the ones already met in this book: the availability mathematics standardised in MIL-HDBK-338B and MIL-HDBK-470A, the sustainment-metric structure of the DoD RAM-C rationale (which is also where materiel availability, the fleet-wide form, is framed), the railway lifecycle's RAMS process under EN 50126, and the IEC dependability vocabulary and mathematical-expressions standards beneath them all.
One programme habit repays special attention: write the Ai-to-Ao gap into the review agenda. The two numbers diverge for identifiable, ownable reasons (spares, queues, admin, definitions), and a standing review of the gap's composition is the cheapest availability instrument a programme owns: it catches the starving spares budget before the fleet does, and it keeps the design team from being prosecuted for the logistics ledger's sins.