ReliaSim / OEE monitoring vs OEE simulation

OEE Monitoring vs OEE Simulation
One measures the line you ran. The other predicts the line you are about to change.

“OEE software” covers two different kinds of tool. Monitoring software records what the line did, shift by shift, and becomes the plant’s record of every stop. Simulation software models the line and predicts what a change will do before anyone makes it. They are not competitors. Monitoring produces the data a simulation needs, and simulation answers the questions monitoring data cannot.

Two kinds of OEE software

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. Three things keep that record from predicting the line you are about to change:

• There is no history for the change. A buffer you have not installed, a speed you have not run: no trend line on last year’s OEE contains them.
• Losses interact. Ten minutes down on a machine feeding a full buffer costs nothing; the same ten minutes on a starved constraint costs ten minutes of finished product. The report records both identically.
• Loss is not gain. On the bottling line in our case study, Labeler Misalignment carried a 6.79% direct efficiency loss and Filler Micro Stop 6.72%. Removed one at a time in a validated model, the first returned 5.0 points and the second 8.1. The micro stops had been cascading into the machines downstream, where the time was logged as idle on the Labeler, Case Packer and Palletizer rather than under the filler’s name.

Machine OEE also does not add up to line OEE. Five machines at 85% in series give about 44% with no buffering and 85% with unlimited buffering. Real lines land in between, and where depends on stop lengths against the storage between machines. Line OEE vs machine OEE works through it, 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. A typical path:

1 · Export the stop log

One row per stop: 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, across eight distribution types, with Kolmogorov-Smirnov and Anderson-Darling goodness-of-fit tests. It exports the parameters for ReliaSim. That step is 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: it is the reference the model has to reproduce before it predicts anything. Built this way, from per-failure-mode data fitted properly and checked against line history, a ReliaSim model can match measured OEE within 1%. The published proof point: the Fischel & Lange WSC 2020 food plant model was rebuilt in ReliaSim and independently validated by Tom Lange within 1% of both the plant’s measured OEE and the original model, running the same one-year simulation 1,200× faster on the same laptop. See the published OEE validation.

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: 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. In Fischel and Lange’s words, an averaged, single-failure-mode approach makes the gains and losses “less accurate and essentially identical to each other.”
• Planned stops flagged. Rows marked as planned or excluded need to come out, and long non-operating gaps such as a weekend should not 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; ReliaSim’s efficiency divides by every minute of the modeled period. On a 24/7 plant they agree; otherwise 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. Which machine stopped, who responds, how the shift did: monitoring answers that.
• Monitoring in place, and the question is a decision. Which loss to fund, how big a buffer, faster or more reliable, whether the line will make next year’s volume (capacity planning simulation). That is simulation, fed by the data you already collect.

Frequently asked questions