Availability composes across a system the way reliability does, with one deep difference: repair is part of the state. A reliability structure only asks which items are working; an availability structure also asks who is fixing what, with which crew, detected how quickly. That extra dimension is what makes repairable-system modelling its own craft, and what decides whether the simple product rules apply or a state model must take over. This chapter covers the composition rules and their fine print, works a radar station end to end, and turns the result into the budgeting discipline that makes availability targets manageable.
The composition rules
For steady-state availability with independent items, the structure rules mirror reliability's, and they are cleanest in unavailability terms (q = 1 − A):
- Series (all items needed): availabilities multiply,
A_sys = ΠAᵢ; for small q this is the addition ruleQ_sys ≈ Σqᵢ. Downtime budgets in minutes per year therefore add straight down a series chain, which is what makes them allocatable. - Active parallel (any one suffices), each item with its own repair capability: unavailabilities multiply,
Q_sys = Πqᵢ. This is redundancy's availability magic: two independent 99.8% channels make a 99.9996% pair, because the system is only down while both are down at once, and each failure's exposure window is only as long as its own repair. - k-out-of-n follows the same binomial logic as the reliability version, computed on the qᵢ.
The parallel rule's dependence on repair is worth pausing on, because it is the whole difference between availability redundancy and mission-reliability redundancy. The pair's unavailability is roughly the chance the second unit fails during the first one's repair: shorten the repair and the coincidence window shrinks with it. Redundancy and maintainability are therefore multiplicative allies: q² improves quadratically with everything that improves q, and a fast, well-provisioned repair loop is what keeps a redundant system living on the q² side of its arithmetic.
When the product rules break
Each product-rule assumption is a real-world failure mode:
| Assumption | How reality breaks it | What it does to the number |
|---|---|---|
| Independent failures | Common causes: shared power, cooling, software, environment (the CCF argument) | Floors Q_parallel at the coupled fraction; q² becomes βq |
| Dedicated repair per item | One crew or one test stand shared across the site; repairs queue | Effective MDT grows with utilisation; the second failure waits |
| Immediate detection | Standby channel fails silently; found only at test | The pair runs as a single string for the latent interval; the λT/2 ledger from the foundations chapter applies |
| Instant, perfect switchover | Failover takes time, sometimes fails, sometimes disturbs the load | Every demanded switchover contributes its own downtime term |
When these couplings matter, the honest tool is a state model: enumerate the system's states (both up; one up, one in repair; both down; one up, one failed-undetected…), attach failure, repair, detection, and test transitions, and solve for state probabilities. That is Markov modelling, the availability world's workhorse for exactly the situations where "who is repairing what" changes the answer: shared crews, imperfect switching, latent failures, staged degradation. Its cost is state explosion on large systems, which is why practice layers the tools: product-rule arithmetic (RBD availability) across the broad system, Markov (or simulation, once logistics networks and spares stocks enter) zoomed onto the few redundant clusters where the couplings live.
The radar station, end to end
The overview's surveillance radar, worked as one table. A transmitter has MTBF 2,000 h and a 4-hour active repair; the station needs continuous coverage; all values are illustrative:
| Configuration | Per-channel downtime per failure | q per channel | Station unavailability | Downtime per year |
|---|---|---|---|---|
| Single channel, spare on site | 4 h | 0.0020 | 0.0020 | 17.5 h |
| Single channel, spare 2 days away | 48 h | 0.0234 | 0.0234 | 205 h |
| Dual channel, spares on site | 4 h | 0.0020 | q² ≈ 4.0 × 10⁻⁶ | 2.1 min |
| Dual channel, spares 2 days away | 48 h | 0.0234 | q² ≈ 5.5 × 10⁻⁴ | 4.8 h |
Four lessons, one table. Logistics dominates the single string: moving the spare off-site multiplied downtime twelvefold with identical hardware. Redundancy is spectacular but honest: the on-site duplex earns minutes per year, four orders below the single string. Redundancy amplifies whatever repair regime it is given: the off-site duplex is a hundred times worse than the on-site one, because q² squares the logistics as faithfully as it squares the design. And the last row is still optimistic: it assumes both channels never share a power feed, a cooling fault, a software load, or a lightning strike, and that the standby channel's health is genuinely known (the previous section's fine print). Real dual-channel stations spend their engineering exactly there: separation, diversity where affordable, and built-in test that keeps the second channel's silence honest.
Budgeting downtime
An availability requirement becomes manageable the moment it is converted into a downtime budget and allocated like any other budget: the station's 99.95% becomes 4.4 hours per year, split across the antenna group, transmitters, processing, power, and communications in minutes, each line owned by a designer who can trade failure rate against repair time against sparing inside it. Because small unavailabilities add in series, the ledger arithmetic is as simple as reliability allocation's, with one extra column: every line's q decomposes into an MTBF part, an MTTR part, and an MLDT part, so the budget simultaneously constrains the design and the support system.
Planned downtime deserves its own ledger line rather than an exclusion clause. The nuclear exemplar from the overview is the discipline at its most mature: a refuelling outage is a project with a critical path, planned years ahead, rehearsed, and compressed by parallelising every task that maintenance task analysis can take off the chain, because each saved hour is an hour of production bought at planning cost. The general rule scales down from there: scheduled work should be aggregated into windows, moved off the operational calendar where the mission allows, and designed for (the design chapter returns to hot-swap and online-maintenance architecture); a budget that only tracks unscheduled downtime quietly hands the schedulers an unlimited account.