Two kinds of OEE software
OEE monitoring
Collects machine states, counts and stop reasons from the line, through an MES, a historian or a dedicated OEE tracking system. It calculates Availability × Performance × Quality against planned production time, ranks the losses, and puts them in front of operators and supervisors while there's still time to act.
OEE simulation
Builds a model of the line from its rates, buffers and per-failure-mode downtime, and checks the model against measured OEE. Then it runs the model forward with a change in place, such as a buffer, a line speed or an eliminated failure mode. The output is a prediction, with its spread.
Monitoring and simulation, side by side
| OEE monitoring | OEE simulation | |
|---|---|---|
| The question | What happened, and what's happening now? | What will happen if we change this? |
| Time direction | Past and present | Future and counterfactual |
| Inputs | Machine signals, counts, operator reason codes | Stop history, rates, layout, storage |
| Outputs | OEE by shift, loss Pareto, downtime log | Predicted throughput and OEE, gain per fix, buffer curves |
| Used by | Operators, supervisors and CI teams, every shift | Engineers, CI and capital planning, per decision |
| What it can’t do | Test a change that hasn’t been made | Work without good input data |
What monitoring does well
Nothing in a simulation replaces a good monitoring system. It shows a stop as it happens, attributes the lost minutes, gives each shift a number to beat, and builds the event history every later analysis depends on. Accounting for what already happened is a loss tree’s job, and it does it well.
Where measured OEE stops
A monitoring system describes the line you ran. It has no history for a change you haven’t made, and it records interacting losses as if they were independent, so removing a loss rarely gives back what the report says. Why measured OEE can’t predict a change works through it. Line OEE vs machine OEE covers why five 85% machines can make a 44% line, and which loss to fix first covers the ranking problem.
From monitoring data to a validated prediction
The two kinds of software meet in the event data. Here’s a typical path.
1 · Export the stop log
The log has one row per stop, with where (the machine), why (the reason or interrupt code) and when (a start and an end, or a start and a duration). Most historians and downtime tracking systems already record it.
2 · Fit failure and repair distributions
ReliaStats separates the log into failure modes and fits a time-to-failure and a time-to-repair distribution to each. It tries eight distribution types and checks the fit with Kolmogorov-Smirnov and Anderson-Darling tests, then exports the parameters for ReliaSim®. This step is called downtime data analysis.
3 · Build and validate the line model
ReliaSim models the line with those interrupts, then compares simulated availability with observed availability for every failure mode. Here the monitoring data gets a second job as the reference the model has to reproduce before it predicts anything.
4 · Predict, then measure
Change one thing in the validated model and read the predicted OEE and throughput. Once the change is made on the line, the monitoring system shows what actually came back, and that becomes the next check on the model. More on OEE simulation.
Making monitoring data simulation-ready
- Timestamps to the second. Short stops vanish in rolled-up minutes, and they often cost the most throughput.
- Named failure modes, not one downtime bucket per machine. One averaged mode per machine flattens the gains and losses (published OEE validation).
- Planned stops flagged. Rows marked as planned or excluded need to come out, and long non-operating gaps such as a weekend shouldn’t count as time a machine ran without failing.
- Unambiguous dates. Many plants export dates day-first, which a parser expecting month-first will silently scramble.
- A known denominator. OEE divides by planned production time, and ReliaSim’s efficiency divides by every minute of the modeled period. On anything but a 24/7 plant they differ by the unscheduled time. Asset efficiency vs OEE has the arithmetic.
Which do you need?
- No reliable stop records yet. Start with monitoring. Without event data, a simulation is limited to failure assumptions entered by hand in the Interrupt Designer.
- Monitoring in place, and the question is operational. Monitoring tells you which machine stopped, who responds, and how the shift did.
- Monitoring in place, and the question is a decision. Use simulation, fed by the data you already collect. It answers questions like which loss to fund, how big a buffer, faster or more reliable, whether the line will make next year’s volume (capacity planning simulation).
Frequently asked questions
Is OEE simulation software a replacement for OEE monitoring?
No. Monitoring records what the line did and is the data source. Simulation uses that record to predict the effect of a change before it’s made. A plant that simulates still needs to monitor.
What data from an OEE monitoring system does simulation need?
It needs the stop log, with the machine, reason code, and start and end time of each stop recorded to the second. It also needs nominal rates, the line layout and the storage between machines.
Why doesn’t fixing the top loss on the Pareto return all its minutes?
Losses interact. Buffers absorb some stops, so removing them returns less, while other stops cascade downstream and return more.
Why does simulated efficiency differ from my OEE dashboard?
Usually it’s the denominator. See the Asset Efficiency vs OEE guide.
Can I simulate OEE for a line with no monitoring data?
Yes, by entering failure and repair distributions directly in the Interrupt Designer. The predictions are then only as good as those assumptions, so validate the model against event data once the line is running.
How close can simulated OEE get to measured OEE?
The method has been validated within 1% of measured OEE on a real plant, with the model built from per-failure-mode data and checked against the line’s own history. See the published OEE validation.
See OEE predicted on a line model
The bottling-line models in the Sandbox’s Lines tier come with the engine’s saved results, including what the line gets back when each interrupt is removed and how efficiency changes with buffer size. There’s nothing to download and no sign-up.
Open the Sandbox → OEE simulationWant to see it on your own line? Schedule a call.