Reliability Block Diagram vs Line Simulation
Availability Is Not Throughput
A reliability block diagram answers a precise question: what fraction of the time is this system able to run? For a production line people often ask it a different one — how much will the line make? — and the diagram answers that one poorly as soon as there is storage between the machines.
What a reliability block diagram calculates
A reliability block diagram (RBD) draws a system as blocks, each with its own reliability or availability, connected in series (the system needs every block) or in parallel (the system needs at least one, or some k of n). For repairable equipment, each block’s steady-state availability is its share of time up, and the diagram combines the blocks:
The RBD arithmetic
| Arrangement | Formula |
|---|---|
| One block | A = MTBF / (MTBF + MTTR) |
| Series — all blocks needed | A = A1 × A2 × … × An |
| Parallel — any one block suffices | A = 1 − (1 − A1)(1 − A2)…(1 − An) |
That arithmetic is exact under its assumptions, and the assumptions are the whole story. Every block fails and is repaired on its own clock, independently of the others. In a series diagram, the system is down whenever any block is down — immediately, and for exactly as long.
A production line is not a series diagram
Draw a bottling line as an RBD and it looks like a textbook series system: Filler, Capper, Labeler, Case Packer, Palletizer, and the line needs all five. So multiply. On the five-machine bottling line in our case study, the per-machine availabilities — 84.3%, 75.9%, 88.5%, 97.9% and 84.3% — multiply to 46.7%. The line’s tracked OEE was 54.3%. And because OEE also carries speed and quality losses, any such loss on that line would make the availability gap wider still, not narrower.
Seven and a half points is not rounding error. Two things the multiplication cannot see account for gaps like it.
Storage decouples failures
Where there is storage between two machines — a buffer, a surge table, an accumulating conveyor — a stop on one does not immediately stop the other. The downstream machine keeps drawing on stock; the upstream machine keeps filling space. The series diagram charges every stop to the whole line the instant it happens. The physical line charges it only once the storage runs out, so for any stop shorter than that, the series product overstates the loss.
Idle machines do not wear on the running clock
A machine that is starved or blocked is not running. If its failures accrue with operating time — jams, misfeeds, wear — it is not moving toward the next one while it waits. The product formula assumes every block keeps failing on its own clock regardless of the others, so even a close-coupled line with no storage at all tends to do better than the product predicts.
Illustrative example — not a result
Five identical machines, close-coupled with no storage, each 90% available (MTTR/MTBF = 1/9). Two textbook answers for line availability:
| Assumption | Line availability |
|---|---|
| Failures on wall-clock time, independent (series RBD) | 0.95 ≈ 59.0% |
| Failures only while running (a stopped line pauses every clock) | 1 / (1 + 5 × 1/9) ≈ 64.3% |
Whether a given failure mode runs on operating time or on the calendar is a property of that failure mode, not of the line, and it has to be decided per mode. ReliaSim’s interrupts support competing, cumulative and wall-clock criteria for exactly that reason.
Decoupling has limits too, which is why this ends up as a simulation question rather than a better formula. A buffer adds no capacity and removes no downtime; it covers a stoppage only while it has stock to give. At 60 units a minute, riding out a 40-minute failure would take 2,400 units of storage, so long stops propagate regardless. Bound it and the range is wide: five machines at 85% each run near 44% with no buffering and 85% with unlimited buffering, and real lines land somewhere between, depending on buffer size against stoppage length. That argument is in Is 85% OEE achievable on your line?
Availability is not throughput, even when the RBD is right
Suppose the availability figure were exact. It still would not be line output, because a block diagram leaves out most of what sets output:
- Rates. An RBD has no rates. Output is set by the flow the line can sustain, and machines with different speeds — or converters that change the unit, from bottles to cases to pallets — do not appear in a block diagram at all.
- Starved and blocked. A block is up or down. A stopped machine on the floor may be down, starved or blocked, and only the first is its own fault. See Starved vs Blocked.
- Which fix pays. Because the diagram treats every block’s downtime as line downtime, it ranks improvements by availability. On a real line the same minutes cost different amounts: in our bottling line case study, two failure modes with near-identical direct losses returned 1.21× and 0.73× their loss when each was removed.
- Speed against failure rate. Running faster raises output only until failures that rise with rate eat the gain. Fischel and Lange found that throughput has an optimum rather than rising steadily. A static availability number has no rate to trade against.
Where the reliability block diagram is the right tool
None of this makes RBDs wrong. It makes them the tool for a different level of the system — and the published study behind our validation work used them exactly there.
Fischel and Lange’s WSC 2020 model of a multi-line food plant put a reliability block diagram inside each rate-affecting unit operation, carrying that unit’s failure modes — up to twenty on each of more than twenty unit operations — and letting its failure rate scale with production rate. The line itself did not come from a block diagram: it came from discrete rate coupling through the valves, tanks and conveyors between the units. That model agreed with measured OEE to within 1% over a one-year run. It was rebuilt in ReliaSim and independently validated by Tom Lange within 1% of both measured OEE and the ExtendSim model, running roughly 1200× faster on the same laptop. The detail is in Within 1% of measured OEE.
RBDs fit well:
- Inside a unit operation. A machine with several failure modes behaves like a series of modes — any one stops it — and its availability is the block’s natural output.
- Where nothing decouples. A shared utility or a control system with no storage behind it stops everything it serves, and series/parallel arithmetic describes that honestly.
- Early redundancy questions. Does a second unit in parallel pay for itself in availability? An RBD answers quickly, before there is enough detail for a line model.
- Per failure mode, never averaged. The paper is blunt about why: “Had an averaged, single-failure-mode-per-unit-operation approach been followed, the gains and losses would be less accurate and essentially identical to each other.”
Where line simulation takes over
The handoff is storage and rate. Once the question is output from a line with buffers, accumulating conveyors, differing speeds or a product mix, the answer depends on the sequence of events: which machine stopped, for how long, and how full the storage was at the time. A simulation plays that sequence forward. It takes the same per-failure-mode inputs an RBD uses and adds what the diagram leaves out.
Which tool answers which question
| Question | RBD | Line simulation |
|---|---|---|
| Availability of a machine or redundant subsystem | Yes — its natural output | Yes — carried as an input |
| Line throughput with storage between machines | Not from block-diagram arithmetic — some RAM packages add a throughput simulation on top of the diagram | Yes |
| Starved and blocked time per machine | No | Yes |
| Which failure mode to fix first | By availability only | By output recovered |
| How big a buffer should be | No | Swept against efficiency |
| Speed against failure rate | No | Yes, where failure rate is tied to rate |
The inputs are the same for both: time to failure and time to repair for each failure mode. When a plant has event history, fitting them is downtime data analysis; when it does not, ReliaSim’s Interrupt Designer lets you enter them directly. If you are weighing tools for the line model itself, see manufacturing simulation software.
Frequently asked questions
What is a reliability block diagram?
A diagram of a system as blocks, each with its own reliability or availability, arranged in series (every block needed) or parallel (at least one needed). It calculates system reliability or availability from the blocks’ values, assuming they fail independently.
Can a reliability block diagram calculate production line throughput?
Not directly. An RBD produces availability. Line throughput also depends on machine rates, unit conversions and the storage between machines, none of which a block diagram represents. On a line with storage between machines, a series RBD overstates the loss.
Why does a series RBD understate a line’s output?
It assumes a stop anywhere is a stop everywhere, immediately, and that every machine keeps failing on its own clock. Storage lets neighbours keep running through a stop, and a machine that is starved or blocked is not accumulating operating time toward its next failure.
How do you calculate series and parallel availability?
Series: multiply the block availabilities, A = A1 × A2 × … × An. Parallel, where any one block suffices: A = 1 − (1 − A1)(1 − A2)…(1 − An). Each repairable block’s steady-state availability is MTBF / (MTBF + MTTR).
When should I use an RBD instead of line simulation?
For a unit operation’s failure modes, for equipment with no storage to decouple it, and for early redundancy decisions. Use line simulation once the question is output from a line with buffers, differing rates or a product mix.
See decoupling on a running line
The ReliaSim Sandbox runs a bottling line in your browser. Stop a machine and watch how far the stop travels before the storage runs out. No signup.
Open the sandbox → The published validationWant to see it on a real line first? Read the case study — or schedule a call.