What a reliability engineer actually gets asked for
The reliability function produces asset-level numbers: time between failures, time to repair, availability per unit, a criticality ranking, a spares policy. All of it is correct, and all of it is per machine.
Then someone asks whether the line makes the volume, or which of two fixes to fund, or whether a bigger surge tank is worth the floor space. Those are questions about a system under interacting failures, and no amount of per-asset availability adds up to an answer. The machines don't fail independently of each other's consequences. When one stops, its neighbors starve or block, and the cost lands somewhere else.
You can close that gap without abandoning the reliability work you already did. The distributions you fitted are exactly the input a line model needs.
Where the block diagram stops
A series reliability block diagram multiplies availabilities, so five 85% machines give 44%. It has nowhere to put the storage that lets a real line do better. An RBD answers a question about configuration, while a line’s output is a question about dynamics, and dynamics need a clock. For the long version, see reliability block diagrams vs simulation and what a RAM analysis can and can’t tell you.
Reliability as architecture, not as a parameter
In a general-purpose discrete-event model, reliability is usually a number you type into a machine, like a downtime percentage or one MTBF and one MTTR. The model then behaves as though the machine has a single way of failing.
Real machines have many. A capper has a plow area, a glue station, a picker tree, a compression stage and a magazine, each with its own failure behavior and each racing the others. In ReliaSim® the unit operation carries its failure modes natively. Every mode gets its own time-to-failure and time-to-repair distribution, fitted from your own event data, and the engine resolves which one fires first.
Why averaging the modes destroys the ranking
The published model behind our validation carries twenty-plus unit operations with up to twenty failure modes each. Collapse those to one averaged mode per machine and the ranking you came for disappears. Gains and losses come out, in the paper's own words, essentially identical to each other.
So keep the modes separate. A ranking is only useful if the differences between its entries survive the modeling.
What reliability does to a line
A failure's cost is its own downtime plus what it does to the machines on either side. That second part is recorded under their names, not under its own.
In our bottling line, 120 one-minute micro stops at the Filler landed as idle time on the Labeler, the Case Packer and the Palletizer. Three machines logged a cost caused by a fourth. An availability calculation can't produce that number, because availability is defined per asset and the cost crossed assets.
See starved vs blocked and micro-stops vs breakdowns.
Rank by what comes back, not by what it cost
You can measure the payoff. Take two failure modes with near-identical recorded losses and ask the model what each returns when removed. On our bottling line, the lower-ranked one returned 1.21× its loss and the higher-ranked one 0.73×. One was cascading into its neighbors, while the line absorbed some of the other’s downtime at no cost. Direct loss doesn’t rank the fix, and micro-stops vs breakdowns works through the example.
Forecasting when a component will fail is a different discipline with its own tools. This answers what the line would produce under a change nobody has made yet. See why condition monitoring can’t answer that.
Validation you can go and check
A model that predicts a configuration nobody has built should first reproduce one somebody measured. A peer-reviewed WSC 2020 plant model agreed with measured OEE within one percentage point across a full year, and its ReliaSim rebuild was independently re-validated to the same bar.
Why run speed matters for reliability work
Ranking every failure mode by what it returns means one full re-run per mode. Sizing a buffer properly means a sweep, not three sizes somebody nominated in a meeting. You can’t afford either if a run takes minutes.
ReliaSim simulates a year of the five-machine bottling demo in 0.154 seconds, so you can stop nominating scenarios and start sweeping them. How big should a buffer be? shows a full sweep.
Where each tool fits
RBD tools such as BlockSim, ExtendSim (same inventor) and ReliaSim each answer a different question best, and most teams that do this well use more than one. The comparisons set out where each fits.
What you need to start
You need the stop and start times your historian already records. The per-mode time-to-failure and time-to-repair distributions are fitted from them, and you set or adjust them in the Interrupt Designer. If you’ve already done a RAM study, you have most of what a line model needs. It was just aggregated to the wrong level.
Frequently asked questions
Can a RAM study predict line OEE?
Not on its own. RAM gives per-asset availability, but line OEE depends on how those assets interact through buffers and on where the constraint sits. The RAM output is a valid input to the line model, not a substitute for it.
Is MTBF enough to size a buffer?
No. Take two machines with the same MTBF and MTTR, one stopping rarely and for a long time, the other often and briefly. They need very different buffers, because a buffer absorbs short frequent interruptions far better than rare long ones. See how big should a buffer be.
What failure data do I need before starting?
You need time-stamped stop and start events per machine, ideally with a fault name. A Line Event Data System export is ideal. Where a mode has too few events to fit, it can be represented by an estimate and flagged as one.
How is this different from predictive maintenance software?
Condition monitoring forecasts when a specific asset will fail. Line simulation forecasts what the line produces under a configuration that doesn't exist yet, including what fixing a failure returns.
Do I need simulation expertise to use it?
No. The models are built from a production graph instead of written as code, and the browser Sandbox shows validated bottling-line models and their engine results with nothing installed.
Open a validated model, not a trial
The bottling-line models in the Sandbox’s Lines tier come from one real line, with the failure modes exposed and the engine’s saved results for each. There’s nothing to download, no license and no sign-up.
Open the Sandbox →