ReliaSim Manufacturing simulation software

Manufacturing Simulation Software

Manufacturing Simulation Software for High-Speed Production Lines
Rate-based, reliability-driven, validated before it predicts

ReliaSim is desktop production line simulation software for high-speed, high-volume operations — filling, packaging, bottling, converting and continuous process. It models your line from the event data you already collect, finds the constraint that is really limiting output, and shows what each change is worth before you commit capital to it.

1%of measured OEE — the published validation bar the method has met
~1200×faster than the original tool, rebuilding that same published model
1990the year Andrew Siprelle created discrete rate simulation

What manufacturing simulation software is for

A plant already knows a great deal about its line. The historian records every stop, the loss tree attributes the minutes, and OEE grades each shift against the plan. All of that describes what happened. None of it can tell you what a change will do — a buffer you have not installed, a line speed you have not run, a failure mode you have not yet eliminated.

That is the job of manufacturing simulation software: to answer counterfactual questions about a production system before you spend money on them. Which machine is actually costing throughput? Is the fix at the top of the Pareto worth more than the one below it? How big should the accumulation table be? Would a second capper pay back, or would better reliability on the first one do the same job for less?

Those questions are hard for a reason. Machines on a line are coupled. A stoppage on one blocks the machines upstream of it and starves the ones downstream, buffers absorb some stops and not others, and the cost of any single loss depends on where it sits. A spreadsheet adds losses as if they were independent, and arithmetic on averages overstates what a line will produce. A simulation plays the line forward through time, so that interaction emerges from the model instead of being assumed away.

Why high-speed lines break item-based simulation

Most general-purpose simulation was built for discrete assembly, where every item is tracked as its own entity through the system. That is the right architecture for a job shop. Point it at a filler running hundreds of units a minute, though, and the model has to schedule and move every one of those units individually — for every machine, for every simulated day.

“For years, simulation has worked well in discreet industries like automotive, where each piece of material is treated as an entity. The models are based on item architecture, which is all about pieces and parts. But if you apply that to food production, the model will take longer to run than the actual product, which would make it useless.”
— Andrew J. Siprelle, founder, in Food Engineering

The answer he arrived at in 1990 — originally called “bulk flow” — was to model material as flow rather than as items. ReliaSim’s engine is built on that idea. Material moves at a rate; the model only does work when something changes that rate: a machine stops, a buffer fills or empties, a repair completes. The cost of a run is driven by how often rates change, not by how many units the line makes — which is why year-long runs are cheap and thousands of them are affordable. A full year of the five-machine demo bottling line simulates in about a third of a second. The longer argument is at discrete rate simulation.

Item-based versus rate-based, on a high-speed line

QuestionItem-based (discrete event)Rate-based (ReliaSim)
What the engine tracksEvery unit as an entityFlow rates, and the events that change them
Cost of higher line speedMore entities, longer runsUnchanged — rate is a parameter
What drives run timeHow many units are madeHow often a rate changes
Experiment size in practiceThe few scenarios someone pickedExhaustive sweeps — thousands of runs
Best fitJob shops, routed parts, item identityFilling, packaging, bulk and continuous flow

How ReliaSim models a production line

A model is assembled from a deliberately short vocabulary, described in full on the capabilities page:

Every constraint and converter carries its own interrupt signature: multiple failure modes per unit operation, each with its own time-to-failure and time-to-repair distribution, triggered on competing, cumulative or wall-clock criteria. That is where reliability data lands, and it is what makes blocking and starving emerge from the model rather than being scripted into it. Models are text-based, so they diff and version like source code.

Build, validate, predict

The ReliaSim method is a fixed sequence, and the middle step is the one that makes the third worth anything.

1 · Build

Draw the line as it actually runs — the right machines, in the right order, with buffers where they physically are — and set nominal rates and conversions. Then parameterize each failure mode. With line event data, ReliaStats fits the distributions for you (downtime data analysis is its job); for a line that does not exist yet, the Interrupt Designer lets you choose the shapes deliberately.

2 · Validate

Compare the model to the historian failure mode by failure mode, not just in total. A model that matches annual OEE while getting the individual modes wrong will still answer your questions — incorrectly. Bivariate validation ships with every license.

3 · Predict

Only then change something: remove a failure mode, resize a buffer, change a rate, add a machine. The simulation re-runs the whole system, so the answer includes every knock-on effect the change has downstream.

Validation evidence you can check

Most simulation accuracy claims are a vendor’s word. This one is a paper. In their 2020 Winter Simulation Conference paper, Fischel and Lange built a per-failure-mode discrete rate and reliability model of a multi-line food plant — over twenty unit operations, up to twenty failure modes each — and set its validation bar at agreement within 1% of overall system OEE between a one-year simulation and the plant’s actual data. It met it.

That model was built in ExtendSim. The same model was rebuilt in ReliaSim and independently validated by Tom Lange: within 1% of both the plant’s measured OEE and the original ExtendSim model, running the same one-year simulated duration roughly 1200× faster on the same laptop. The full account is in the published OEE validation case study.

Scatter plot of source availability against simulated availability, one marker per interrupt, with a y equals x match line and 95% prediction and 99% confidence bands. Every point sits on the match line.
Source vs. simulated availability on the bottling line demo model, one marker per failure mode, with 95% prediction and 99% confidence bands. The same per-mode comparison is built into the product, so it is how you validate your own line.

What you can ask of it

Where is the real bottleneck?

The constraint timeline shows which machine is limiting the line at each moment — rarely one fixed station. Finding the hidden bottleneck · theory of constraints simulation.

How big should the buffer be?

Sweep capacity with every interrupt in play and see where the curve bends. How big should a buffer be?

Which failure mode first?

Remove each one, re-run, and rank by throughput recovered rather than minutes lost. Which loss to fix first

What will this do to OEE?

Predict line OEE for a change before you make it, from per-machine interrupt data. OEE simulation

Faster, or more reliable?

Running faster makes more product and causes more failures, so there is an optimal speed. Five decisions every line faces

Block diagram, or simulation?

Multiplying availabilities assumes machines fail independently; buffers break that assumption. RBD vs simulation

ReliaSim constraint timeline for the Filler, Capper, Labeler, Case Packer and Palletizer across one day, each row colored by state: up, down, blocked, starved and partial states.
A constraint timeline across one simulated day: each machine’s time split into up, down, blocked and starved. Downtime that looks identical on a loss report rarely lines up like this.

Because runs are cheap, those questions are answered exhaustively rather than for three hand-picked scenarios. The buffer sweep behind the buffer guide is 7,770 runs — 1,864 simulated years in 31.8 seconds. Every run starts from a fixed seed, so the same question asked twice gives the same answer. With the AI / MCP add-on, you can also ask the model questions in plain language, and every figure in the reply traces back to an engine run.

Industries and results

Rate-based simulation applies wherever material moves as flow rather than as a queue of parts. The method behind ReliaSim has been used by production teams in more than 300 organizations since 1995, across food & beverage, packaging & CPG, chemicals, oil & gas, pharma & life sciences, electronics & automotive and aerospace & defense.

Most of that project work predates ReliaSim as a product; it was done with the discrete-rate method ReliaSim now packages, and each case study says which tool ran the model. All case studies.

Desktop, air-gap compatible, yours

ReliaSim runs on Mac (Apple Silicon) or Windows 11. Models, historian extracts and results stay on your machine, inside your firewall; only license and version checks touch the internet, and those can be deferred for air-gapped sites. There is no SaaS version, by design — the security page covers what IT reviewers ask. A model built on a licensed seat can be opened and run by anyone using the free demo, so a plant manager or a capital review board can check the scenarios themselves.

When you need something else

ReliaSim is opinionated, and it is not the right tool for every simulation problem. Being plain about that saves everyone time:

Frequently asked questions

What is manufacturing simulation software?

Software that builds a working model of a production system — its machines, rates, buffers and failure behavior — and runs it forward through time, so you can test changes such as a new buffer, a faster line speed or an eliminated failure mode before making them on the real line.

How is ReliaSim different from discrete event simulation software?

Discrete event tools track every item as an entity, which suits job shops and assembly. ReliaSim uses discrete rate simulation: material moves as flow and the engine works only when a rate changes. On high-speed filling and packaging lines that keeps year-long runs fast enough to run thousands of scenarios.

How accurate is it?

The method was validated in a peer-reviewed 2020 Winter Simulation Conference paper to within 1% of measured OEE over a one-year simulation, per failure mode. That model was rebuilt in ReliaSim and independently validated by Tom Lange within 1% of both the measured OEE and the original ExtendSim model, running 1,200× faster on the same laptop. Handled correctly — per-failure-mode data, fitted distributions, validation against your historian — your own line’s model can match its measured OEE within 1% before it is used to predict.

What data do I need to build a model?

Line event data — a CSV of machine stop and start times, recorded to the second — plus nominal rates and the line’s layout. Named failure modes give the most useful answers. Without history, the Interrupt Designer lets you enter failure and repair distributions directly.

Does ReliaSim run in the cloud?

No. It is desktop software for Mac (Apple Silicon) and Windows 11. Your models and data stay on your machine, and it is compatible with air-gapped networks.

Can I try it before buying?

Yes. The browser Sandbox runs eight bottling-line models with no download or sign-up, and the desktop demo is free. Full licenses are annual per user (see pricing), and academic licenses for teaching and non-commercial research are free.

Run a production line model now

The Sandbox runs eight bottling-line models in your browser — every number from a live engine run. No download, no sign-up.

Open the Sandbox → See pricing

Want to see it on your own line? Schedule a call.