Breakdowns & Backups Lab.
Picture three machines in a row. If any one of them breaks, the whole line stops. Each machine breaks down and gets fixed at random times, so how much of the year does the line actually run? Watch it break and recover. Then give the middle machine a backup. See why the backup helps less when one problem, like a power dip, can knock out both.
Uptime depends on the layout, not just the machines
Each machine works 96.77% of the time. The line needs all three working at once, so you multiply the three numbers together: the line runs 90.63% of the time. That’s 821 hours a year stopped, 2.9 times what one machine loses on its own (283 h). Try scenario 2 to give the middle machine a backup.
Scenarios
Layout
The shared-cause slider needs a backup. Switch the layout to add M2B.
Speed (simulated hours per real second)
Changing a setting restarts the run from hour zero. It keeps the same seed, the number that picks the random breakdowns, so you can repeat any run exactly.
Simulation vs formula, over time
simulated, time up ÷ time so far: – simple formula 90.631%
| Measure | Formula | Simulated |
|---|---|---|
| Line uptime (availability) | 90.631% | – |
| Middle stage (M2) | 96.774% | – |
| Line downtime, h/yr | 820.7 | – |
| Line stops per year | 198.5 | – |
| Average length of a stop, h | 4.13 | – |
Each machine, simulated:M1 –M2 –M3 –formula 96.77%
The ± is a 95% range for the simulated number, in percentage points (pp). The long-run value is very likely somewhere inside it. To get it, the run is cut into 20 batches, and the range comes from how much the batches’ averages differ (a batch-means interval). It shows up once each batch covers 20 repair times and the run has seen 100 stops. The formula column’s stop counts and lengths also assume every breakdown has its own cause.
40 separate one-year runs, line uptime in each (seeds 1001–1040)median 90.47% · lowest 89.02%
How the model works, how it’s checked and what it leaves out
How it works
Three machines in a row, M1–M2–M3, all exactly alike. MTBF is the average time between breakdowns and MTTR is the average repair time. Each machine’s availability, the share of time it’s working, is A = MTBF ÷ (MTBF + MTTR). The line only runs when all three run, so it’s up A × A × A = A³ of the time. With the backup, the middle stage only stops if M2 and M2B are both down. Each is down 1 − A of the time. If they break for separate reasons, both are down together (1 − A)² of the time, so the stage is up 1 − (1 − A)². The whole line is then A × [1 − (1 − A)²] × A. Downtime is (1 − A_line) × 8760 h/yr, where A_line is the whole line’s share of time up and a year has 8,760 hours.
In the simulation, each machine breaks after a random wait that averages MTBF. That clock keeps ticking even while the line is stopped. Each repair takes a random time that averages MTTR, and every machine has its own repair crew. The random times follow an exponential distribution. That’s the usual model when a breakdown is just as likely in any hour. Each machine draws from its own seeded stream of random numbers.
The shared cause uses the beta-factor shock model. M2 and M2B each break on their own at a rate of (1 − β)/MTBF. On top of that, shared shocks arrive at a rate of β/MTBF and knock out whichever of the pair is running. So each machine still breaks at 1/MTBF in total, and its own availability is still A. The exact answer with β comes from a Markov chain. That’s a model that tracks which of three states the pair is in: both up, one down or both down. It also tracks how often the pair moves between them.
How it’s checked
Availability always stays between 0 and 1 (0% and 100%). Raising MTBF or cutting MTTR never lowers it. When every breakdown has its own cause, the simulation settles on the formula’s answer. Seven settings were tested, from MTBF 40 h with MTTR 24 h up to MTBF 500 h with MTTR 1 h. Over 2,000,000 simulated hours, all seven landed inside their 95% ranges, within 0.2 percentage points. Each machine has its own random numbers. So, run by run, adding another machine to the row can only take uptime away, and adding M2B with β = 0 can only add it.
With β above 0, the simulation settles on the Markov answer, not the simple formula. At MTBF 120 h, MTTR 4 h and β = 10%, the middle stage is down 22.4 h/yr, against the formula’s 9.1. One run of 2,000,000 simulated hours (seed 7) read 99.759%. That’s 0.014 percentage points from the Markov value of 99.745%, and 0.137 below the simple formula’s 99.896%. Then 300 separate runs of 200,000 h averaged 99.7441% ± 0.0014, against 99.7446% exact. The ± here is one standard error, a measure of how much an average like this wobbles. Across eight settings, the 95% range caught the exact value in 92–97% of runs (200–400 seeds each). That’s close to the 95% it promises. Fixed seeds mean every trace can be repeated.
What it leaves out
Here a machine can break even while the line is stopped, but in real life a stopped machine usually can’t. Real repair crews may be shared or short-staffed, and the switch over to the backup can fail. Real lines often have storage space between machines (buffers), so one stop doesn’t halt everything. Then there’s planned maintenance and waiting for parts. Machines also get more or less likely to break as they age, and some keep running at reduced speed instead of stopping.
Each of these pushes the simple formula off in a known direction, and most need a Markov model or a simulation. The speed of the products in the animation is just for show. It tells you whether the line can move product, not how much it makes per hour.