From Components to Systems

Components carry the failure physics, but requirements are written against systems, and the translation between the two levels is pure structure: which items must work for the system to work, and which can cover for each other. This chapter covers the four structural building blocks (series, active parallel, k-out-of-n, standby) and the honest limits of redundancy. The same structures are the vocabulary of reliability block diagram analysis and, viewed from the failure side, of fault trees; here the aim is to understand what the arithmetic does and why it behaves the way it does.

The series product law

In a series structure every element must survive for the system to survive, so with independence the probabilities multiply:

R_sys = R₁ × R₂ × … × Rn

and under constant failure rates the multiplication becomes addition in the exponent: λ_sys = Σλᵢ. This additivity is why parts-count style prediction can exist at all, and why a system budget can be allocated down a product tree by splitting a rate.

The product law's consequence deserves more respect than it usually gets, because it is the quiet reason complex systems disappoint. Multiply many numbers slightly below 1 and the result collapses:

Five hundred parts, each 99.9% reliable over the mission, deliver a system that fails four missions in ten. Three practical morals follow. First, part count is a reliability decision: every component added, however good, taxes the system, which is why simplification sits alongside derating in the design-for-reliability toolkit. Second, the weakest items dominate: rates add, so the top handful of contributors usually carry most of the system rate, and a Pareto of predicted rates is the cheapest improvement map a programme ever gets. Third, uniform excellence is the wrong target: pushing every part to aerospace grade wastes money the top ten contributors could have used.

Active redundancy

Put n items in active parallel (all energised, any one sufficient) and the system fails only if all fail:

R_sys = 1 − (1 − R₁)(1 − R₂)…(1 − Rn)

Redundancy is the only technique that lets a system be more reliable than its parts, and at high component reliability it is spectacular: two independent 0.99 channels give 0.9999 mission reliability, turning a 1-in-100 mission risk into 1-in-10,000. The general form is k-out-of-n: the system works while at least k of n identical items work, with reliability given by the binomial sum of the ways at least k can survive. The workhorse case is 2-out-of-3, R_sys = 3R² − 2R³, the classic voting arrangement that tolerates one failure while letting the majority out-vote a channel that fails dirty (producing wrong output rather than silence). That last property is why control and protection systems pay 2oo3's premium over simple duplication: a duplex pair can detect disagreement but cannot tell which channel lied.

Redundancy's fine print, before the limits in the last section even enter:

• Diminishing returns are steep. With 0.90 blocks: one channel 0.90, two 0.99, three 0.999. Each added channel multiplies the improvement by the same (1 − R) factor but adds the same cost, weight, and power, so the economic case usually stops at two or three.
• The mean improves much less than the mission reliability. For identical constant-rate units in active parallel, MTTF grows only as the harmonic series: 1/λ, 1.5/λ, 1.83/λ for one, two, three units. Redundancy reshapes the survival curve (flat early, steep late), which is exactly what a short mission wants; it does not buy proportional mean life.
• Basic reliability gets worse. Every redundant channel adds parts that fail and demand maintenance. Mission reliability rises while logistics reliability falls; both must be tracked, and the allocation topic shows how programmes budget the two separately.
• Repairable redundancy is a different game. If a failed channel can be repaired while its partner carries the load, availability rises dramatically with repair speed; the analysis moves to Markov or simulation territory, and maintainability becomes the dominant parameter.

Standby redundancy

An alternative to running all channels hot is to hold spares in reserve and switch on failure. With a cold standby (unpowered, accruing no failures) and a perfect, instantaneous switch, a unit plus n − 1 spares survives the mission if fewer than n failures occur in it, which for a constant-rate unit is the Poisson sum:

R(t) = e^(−λt) × Σ (λt)^k / k! for k = 0 … n−1

Cold standby beats active parallel on paper (the spare spends no life while waiting), but the paper advantage is routinely eaten by the machinery that delivers it. The switch must detect the failure, decide, and transfer the load: its own reliability multiplies the whole arrangement, and an imperfect switch quickly becomes the dominant term. Detection is rarely perfect, and an undetected primary failure silently converts the pair back into a single string. Between cold and hot sit warm standbys (partially energised, reduced dormant rate, faster takeover), trading standby aging against switchover time and shock. The engineering questions that decide the architecture (how does the failure announce itself, how long may the changeover take, what does the interruption do downstream) are system design questions, not statistical ones; the statistics only price the answer.

Where redundancy stops working

Every formula above multiplied independent probabilities, and independence is precisely what fails first in real installations. A common-cause failure defeats all channels through one shared mechanism: the same contaminated fuel batch in both engines, the same firmware defect in all three voters, the cooling loss that takes out the whole cabinet, the maintenance error repeated on each channel in turn during the same shift. Once common causes exist, the naive product arithmetic overstates redundancy by orders of magnitude; if even a small fraction β of a channel's failure rate is shared, the redundant pair's failure rate floors at roughly βλ no matter how many channels are added: a redundancy ceiling set by the coupling, not the channel quality.

The quantitative side of this (modelling common-cause groups, computing how much of the system risk each component or coupling actually drives) is where fault tree analysis and its importance measures earn their place: an importance ranking is what turns "redundancy has limits" from a slogan into a list of which limits, in this design, are worth money to remove. The qualitative side is a design review habit: for every redundant pair, ask what single event, part, person, or line of code touches both. There is always at least one answer.