Constraint-Level track · step 1 of 4. This model is a single constraint carrying interrupts.
At a glance
| Experiment | Single Run |
| Duration | 90 days |
| System efficiency | 53.4% |
| Production | 6.92M bottles · ~69,200 pallets |
| Output unit | bottles |
What this model is
The whole Bottling Line modeled as one Constraint at 100 bottles/min, with five Interrupts competing on it — this is the line-level rollup. The 5-Constraint model (next card to the right) splits the same line into five per-machine Constraints. Same plant, same answer — close-coupled machines make the line-level rollup and the per-machine view equivalent for throughput.
The line
| Node | Type | Detail |
|---|---|---|
| Buffer 0 | Buffer | ∞ supply |
| Bottling Line | Constraint | 100 bottles/min · 5 interrupts |
| Buffer 1 | Buffer | ∞ capacity |
The five interrupts
Each of the five machines on the real line contributes one interrupt, rolled up onto the single Constraint. They compete: whichever fires first stops the line, and the others keep running down their own clocks.
| # | Interrupt | Time to failure | Time to repair |
|---|---|---|---|
| 1 | Filler | Weibull(30, 1) | Weibull(5, 1) |
| 2 | Capper | Weibull(30, 1) | Weibull(5, 1) |
| 3 | Labeler | Weibull(30, 1) | Weibull(5, 1) |
| 4 | Case Packer | Weibull(30, 1) | Weibull(5, 1) |
| 5 | Palletizer | Weibull(30, 1) | Weibull(5, 1) |
All five carry the same distributions, which is deliberate: this model is the control.
Read those parameters carefully. 30 is the scale parameter, not the MTBF — it is the running time by which 63.2% of runs have ended. It happens to equal the mean here only because the shape is 1, which makes the Weibull an exponential with a constant failure rate and no wear-in or wear-out. At any other shape the two numbers differ, and quoting a scale as "the MTBF" is the usual way a fitted failure mode gets misread. See time to failure.
These parameters are not invented for the demo. They are fits to the same plant's real event data, aggregated to the machine level. The LEDS-Level track keeps that data drilled down to its 36 named failure modes instead of rolling it up.
A model file note: the file holds six interrupt entries, not five. The extra is an unnamed Interrupt 0 — an unused placeholder that contributes nothing to the results below. The measured 5.8 minutes between stops is consistent with five interrupts competing, not six.
What the run produced
Measured over 90 simulated days:
| Measure | Value |
|---|---|
| System OEE | 53.4% |
| Throughput | 6,917,065 bottles |
| Total downtime | 1,007.2 hours |
| Failure events | 11,964 |
| Mean time between failures | 5.8 min |
| Mean time to recover | 5.1 min |
The figure worth pausing on is 5.8 minutes, against a per-interrupt mean of 30.
Two different things are being named here, and the demo is a good place to separate them:
- The 30 is an input — a parameter of one failure mode's distribution, in isolation.
- The 5.8 is an output — what the Constraint actually did, with all five interrupts competing against each other for 90 days.
Five independent risks race, and the node stops when the first of them fires — so competing risks do not average, they accumulate, and the node stops far more often than any one interrupt would make it. See competing risks.
The 5.8 is what the run produced. It is not a formula evaluated. Every stop in those 90 days happened because one of five clocks reached zero first, then reset while the others kept their positions, through 11,964 events. The number is the outcome of that sequence.
There is no shortcut that would have told you 5.8 in advance. Five identical interrupts at a constant failure rate is the simplest competing case there is, and even here the answer depends on how the stops interleave and how long each repair holds the line down. Change one shape parameter, give the machines their own failure modes, add a buffer or let a stage sit starved and accumulate no risk while it waits, and there is less to calculate rather than more — which is the reason this is a simulation and not a spreadsheet.
That 5.8 is MTBF in the standard sense — total operating hours divided by the number of failures, running time only, with repair carried separately as the 5.1-minute MTTR. The two combine into availability the usual way: 5.8 ÷ (5.8 + 5.1) = 53.4%, which is exactly the OEE reported above. Worth noticing on this line because repair is nearly half the cycle here; on a line with rare failures and quick fixes, availability sits close to 100% and the same arithmetic barely moves. See time to failure for how the intervals relate.
Downtime by interrupt — and why the ranking is meaningless
| Rank | Interrupt | Downtime | Share | |
|---|---|---|---|---|
| 1 | Palletizer | 200.0 hrs | 19.9% | |
| 2 | Case Packer | 198.9 hrs | 19.8% | |
| 3 | Filler | 194.7 hrs | 19.3% | |
| 4 | Capper | 189.0 hrs | 18.8% | |
| 5 | Labeler | 188.6 hrs | 18.7% |
Five statistically identical interrupts produced a ranked list, and the ranking is noise. Run it again with a different seed and the order changes. Nothing about the Palletizer makes it the worst machine; it happened to land on top this time.
This is the single most useful thing in the model, because a real Pareto chart looks exactly like this one and is usually read as if it meant something. Before treating a ranking as a priority list, the question worth asking is whether the gaps between the bars are bigger than the noise. Here they are not. On the LEDS-Level track, where the same plant's data is kept drilled down, one failure mode carries 20% of all downtime on its own — that is what a real, actionable difference looks like next to this.
If you eliminated the top interrupt
Removing the Palletizer interrupt would recover roughly 9.3% of operating time — about 1,200,287 additional bottles. But since the five are interchangeable, that figure is what removing any one of them buys, not what removing the worst one buys. There is no better or worse choice available in this model, which is precisely why the next models exist.
Questions it answers
- "Where's the bottleneck?" — at the line level there isn't a structural one, and the model shows you why
- "Why is the line at ~53% efficiency?"
- "Why is the line's MTBF so much shorter than any machine's?"
- "How does this compare to the 5-Constraint model?"
Where to go next
| If you want to see | Go to |
|---|---|
| The same line split per machine, with blocked-and-starved time | Five Constraints in Series |
| Bottles converted to cases and pallets | Two Constraints, Three Converters |
| Whether buffers help | Adding Inline Buffers |
| Multi-run output and a sensitivity sweep | Buffer Options — LEDS |
| The same topology against real named failure modes | One Constraint, LEDS-Level Interrupts |
The same topology on the other track
One Constraint, LEDS-Level Interrupts runs this structure against LEDS-level interrupt data. It reports 53.2% efficiency against 53.4% here — the throughput prediction barely moves. What changes is what the model can tell you about the cause: five interchangeable interrupts become 36 named failure modes, and a meaningless ranking becomes a clear one.
Open it
This model ships with ReliaSim® and runs in the browser sandbox — no install required. Open 1 Constraint in the sandbox.
Every figure on this page is the published result for the model as it ships. Open it and re-run to reproduce.