ReliaSim® vs ExtendSim
The same validated model in both engines, 1,200× faster

The same model, two engines

In their 2020 Winter Simulation Conference paper, Fischel and Lange modeled a real multi-line food plant, not a teaching example. The model is a per-failure-mode discrete rate and reliability model. It carries up to twenty failure modes on each of more than twenty unit operations.

Its structure matters for what follows. A reliability block diagram sits inside each rate-affecting unit operation, carrying that unit’s failure modes and letting its failure rate scale with production rate. The line itself comes from discrete rate coupling through the valves, tanks and conveyors between the units. The authors built it in ExtendSim, and it’s the featured case study on ExtendSim’s own reliability block diagram page.

The validation bar they set was agreement within 1% of overall system OEE between a one-year simulation and the plant’s actual data. The model met it. The paper also explains why the per-mode detail is necessary.

The independent validation

That published model was rebuilt in ReliaSim and independently validated by Tom Lange, a co-author of the paper. The ReliaSim model came within 1% of the plant’s measured OEE, the same bar the original met, and it agreed just as closely with the original ExtendSim model.

Those are two different checks, and both matter. Agreement with the plant says the rebuild reproduces reality as well as the published model did. Agreement with the original model says the two engines, given the same structure and the same failure data, produce the same answers. So the comparison below isn’t about which tool is more accurate, because on this model they agree. It’s about what the same accurate answer costs in time.

The paper is two pages and open access, so you can check the original model yourself. Our write-up of the study is the published OEE validation case study.

The clock

Both models were run on the same laptop over the same one-year simulated duration. ReliaSim finished roughly 1,200× faster in real clock time. Because the hardware and the simulated horizon were held the same, the ratio compares the engines, not the machines they ran on.

The paper reports the validation, not run times. The timing comes from the independent validation of the rebuild. For a sense of scale on a smaller line, a thousand one-year runs of ReliaSim’s five-machine demo bottling line take about two and a half minutes on a laptop. That’s 0.154 seconds per simulated year.

What the speed buys

A one-year run that takes a long time is a run you do a few of, and the meeting becomes an argument about which candidates to pick. When the same run costs seconds, the hand-picked scenarios stop being a constraint.

• Sweeps instead of guesses. The buffer sweep behind how big should a buffer be? is 7,770 runs, or 1,864 simulated years, in 31.8 seconds.
• Every failure mode, removed one at a time. Ranking losses by what the line gets back takes one full re-run per failure mode, which means hundreds of one-year runs on a model the size of the food plant’s. Two failure modes with near-identical direct losses can return very different amounts. See micro-stops vs breakdowns and which loss to fix first.
• Distributions, not single runs. Replications are cheap enough that every answer comes with its spread.

The discipline doesn’t change with the clock. You still build the model, gather per-failure-mode data and validate before predicting. The engine itself is on capabilities.

Where ExtendSim fits

ExtendSim is a general-purpose simulation toolkit. Its product line covers discrete event simulation, discrete rate simulation and reliability block diagramming, and modelers can build their own custom blocks. If you need several modeling methods in one environment, item-level logic alongside flow, or a component library you extend yourself, it’s the broader tool, and ReliaSim doesn’t try to match it. ReliaSim is deliberately narrower. It covers high-speed and bulk-flow production lines with a short vocabulary of constraints, converters, buffers and interrupts, and a build, validate, predict method around it.

The two tools also share a history. Andrew Siprelle created discrete rate simulation in 1990, as “bulk flow” simulation. Its first paper, with David Parsons at WSC 1995, was built using Extend. ExtendSim’s Rate Library later built a second generation on that work, including Damiron and Nastasi’s 2008 linear-programming approach and Krahl’s 2009 paper. The full account is on the discrete rate lineage page. Both discrete rate engines trace back to the same inventor.

Frequently asked questions