Series reliability of many parts
A Socratic walk-through of series reliability of many parts — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #Why does a machine built from a thousand excellent parts still fail almost every week?
Every component in the machine has been qualified. Each one is 99.9 per cent reliable over a week — one failure in a thousand part-weeks, which by any ordinary standard is excellent. The purchasing department is satisfied, the supplier audits are clean, and the machine has a thousand such parts in it.
It breaks down almost every week. The instinct in the room is to hunt for the bad component, because a machine that fails weekly surely contains something that is not as good as claimed. Before we go looking, though, it is worth asking a question that has nothing to do with any particular part: if every one of those numbers is exactly true, how often should this machine work for a whole week? Because if the honest answer is "about a third of the time", then there is no bad part to find, and the search would waste months.
Reasoning it through
REASONING #Take the simplest possible case first. Two parts, each 99.9 per cent reliable, and the machine needs both. What is the chance the machine survives a week? It survives only if the first part survives and the second does. Assuming for the moment that the two failures are unrelated, that is 0.999 times 0.999 — about 99.8 per cent. A small loss, and the intuition that "excellent parts make an excellent machine" survives intact.
But notice the operation we just performed. We did not subtract; we multiplied. And multiplication of a number just below one, repeated, does something that addition never does. With ten parts we are at 0.999 to the tenth power, about 99 per cent. Still fine. With a hundred, 90.5 per cent. With five hundred, 60.6 per cent. With a thousand, 0.999 to the thousandth power is 36.8 per cent.
Sit with that last figure, because it is the whole answer. The machine of a thousand excellent parts works through an entire week only about one week in three. It does not need a weak component to fail weekly. It fails weekly because a small per-part risk, compounded a thousand times, is a large risk — survival decays exponentially in the number of parts, and 0.999 to the thousandth is very nearly one over e, which is where the familiar 37 per cent comes from.
Now ask the design question the other way round, because that is where this becomes useful rather than merely alarming. If we want the machine to survive a week nine times in ten, what per-part reliability does a thousand parts demand? We need the thousandth root of 0.9, which is about 0.9999 — one failure in ten thousand part-weeks, ten times better than what we have. That is the point that catches organisations out: the requirement on each part scales with the count of parts, so doubling the part count is not a small change to the specification, and a component that was entirely adequate at a hundred parts is simply not adequate at a thousand. Reliability is a property of the assembly, and no amount of inspecting individual parts against a fixed threshold will reveal that the threshold itself was set for a smaller machine.
Two qualifications, and they are real ones. This is the series case — every part required, no substitutes. Wherever a designer has provided redundancy, the arithmetic flips: two parallel parts fail only if both fail, so their failure probabilities multiply instead of their reliabilities, and the block becomes far more reliable than either part. Real machines are a mixture of series chains and redundant blocks, and the mixture is exactly what a reliability engineer is drawing when they build a block diagram.
The second qualification is that we assumed independence, and independence is often false. Parts share a power supply, a temperature, a batch of material, a maintenance crew, a vibration environment. Such common causes make the true system reliability worse than the multiplication predicts, not better, and they are the reason that redundancy bought by duplicating an identical unit disappoints so regularly — two identical pumps on one dirty fuel line are not two independent chances.
The analogy
THE ANALOGY #Think of a chain of a thousand links, each one forged to a standard that lets it fail once in a thousand liftings. Nobody assesses a chain by the average quality of its links, because the chain holds only while every link holds — the chain's strength is not the mean of its links but a property of the whole run.
a chain's links fail one at a time and visibly, whereas a machine's parts often fail together for a shared reason — a heat wave, a bad batch, a wrong lubricant — so the independent multiplication is an optimistic floor rather than an exact answer.
Clarifying the model
THE MODEL #The refinement that connects the steps is that "excellent" is not a property a part can have on its own. It is a claim about a part relative to how many of it will be required at once, and the same 99.9 per cent is generous in a ten-part instrument and hopeless in a thousand-part one. That reframes what a specification is for: it is not a quality bar, it is a budget allocated from a system target across a part count.
The misconception worth correcting is the search for the culprit. A weekly failure feels like evidence of a defect, and it usually triggers an investigation into the last thing that broke. But if the parts are behaving exactly as specified, the failures will not repeat in the same place — a different component each week, each one blameless, and every investigation ending with "no fault found". That pattern is itself the signature of a part-count problem rather than a part problem, and reading it correctly is the difference between redesigning the architecture and chasing ghosts.
What actually helps follows directly from the exponent. Reduce the number of parts in series, which is why integration and fewer connectors buy reliability that better connectors cannot. Add redundancy where a chain cannot be shortened, and make the redundant paths genuinely different so a common cause cannot take both. And derate: run each part well below its limit, which raises the per-part figure that everything else is compounded from.
A picture of it
THE PICTURE #How to readthe horizontal axis is the number of parts in series, every one of them 99.9 per cent reliable per week. The bars are the chance the whole machine survives the week; the line is the chance at least one part has failed. Nothing about the parts changes across the chart — only how many of them there are.
What became clearer
WHAT CLEARED #The machine is not failing because something in it is bad. It is failing because survival is a product, not a sum, and a thousand factors just under one multiply down to about a third. The part-count sits in the exponent, so it is the architecture and not the component that decides weekly reliability — and the only fixes that work are the ones that change the exponent, the independence, or the base.
Where to go next
ONWARD #- How a reliability block diagram mixes series chains and redundant blocks in one calculation.
- Why identical redundancy so often fails to deliver, and what diverse redundancy costs instead.
- Where the constant-failure-rate assumption behind these numbers stops being reasonable.
Key terms
TERMS #| Term | What it means |
|---|---|
| Series reliability | the case where every element is required, so system reliability is the product of the element reliabilities. |
| Redundancy | a parallel arrangement in which the block survives if any path does, so the failure probabilities multiply instead. |
| Common-cause failure | a single condition that takes out several parts at once, breaking the independence the multiplication assumes. |
| Derating | operating a part below its rated stress to raise its individual reliability. |
Every term the collection defines is gathered in the glossary.