OEE per Line From MES and Historian Data, No New MES

Can you calculate OEE per line from the MES and historian data you have?

Yes: a food or ingredients plant can calculate OEE per line from the MES, historian and downtime data it already holds, with no new MES. Döhler rolled Litmus Edge out to multiple plants within three months of kick-off.

Yes. A food, beverage or ingredients plant already holds everything OEE needs: machine states and speeds in the historian, counters in the MES or the PLC, orders and rated speeds in SAP PP, reason codes in the downtime log. What is missing is one definition across lines and plants, and an explanation of the losses. This guide gives the formula, a worked example with its assumptions, the systems involved, where it fails and what it costs. The shift lead keeps the decision.

By Tom Joseph · Last updated: 14 October 2026

What an OEE model does that a dashboard per plant cannot

One OEE per line, one definition across plants. Availability from the line-state tags in the historian (AVEVA PI, FactoryTalk Historian, Ignition tag history), performance from the counter against the rated speed per SKU in the SAP PP routing, quality from the good count minus the checkweigher and metal-detector rejects. The same formula in every plant, so 68% in Plant A means what 68% means in Plant B.

Micro-stops become visible. Stops shorter than the reason-code threshold (often two to five minutes) never reach the downtime log. The model reconstructs them from counter plateaus and state tags, then clusters them by machine, SKU and shift. On a filling line that is usually where the performance loss hides.

Speed loss gets a cause. The ramp after a CIP, a reduced-rate setpoint left over from the previous SKU, starvation from the mixer upstream, blocking from the palletiser downstream: the model separates them from the tags around the bottleneck machine instead of lumping them into one percentage.

Tomorrow's loss is flagged today. From the order sequence in SAP PP, the SKU, the changeover and the machine's recent behaviour, the model names the line most likely to lose availability next shift and the probable reason. The shift lead decides whether to pull the changeover forward or hold the plan.

The shift log stops being retyped. Free-text shift-log entries and downtime comments are classified into the reason-code tree, so the Pareto is built on what happened and not on a 30% bar labelled 'other'.

Data you already have, and what it gives OEE

Data you already have	Where it lives	What it yields
Machine state and speed tags	Historian (AVEVA PI / OSIsoft PI, Rockwell FactoryTalk Historian, Ignition) via OPC UA from the PLC	Availability, and the raw material for micro-stop and speed-loss detection
Production counters, good and reject counts	MES (Siemens Opcenter Execution Process, Ignition with the Sepasoft OEE Downtime module) or PLC counters	Performance and quality per run
Production orders, SKU, planned quantity, routing with rated speed	ERP (SAP PP)	Ideal cycle time per SKU and planned production time
Downtime reason codes	MES or the operator terminal	The Pareto of logged stops; the gaps show what was never coded
Shift log and handover notes	Paper, Excel or a shift-log tool	The why behind a stop, which the tags cannot carry
Checkweigher, metal detector and X-ray reject counts	Inspection equipment and the CCP log	Quality loss, and the CCP deviations that must stay in the batch record
Edge and cloud layer	Litmus Edge, Azure IoT Operations, Microsoft Azure	One namespace across plants, so the same tag means the same thing everywhere

What it needs from your systems

The model reads; it does not replace. The historian stays the historian, the MES stays the MES, and your ICT partner and OT integrator keep the network, the servers and the hosting. What Crux Digits builds is the layer in between: a line model per plant in which every tag, counter and order has one meaning, following the ISA-95 hierarchy your MES already uses (enterprise, site, area, line, cell). Where that model does not exist yet, an edge platform such as Litmus Edge or Ignition supplies it by publishing the PLC data over OPC UA or MQTT into one namespace; where it exists, we connect to it.

The minimum for a first line: three months of historian data for the bottleneck machine at one-second resolution or better (state, speed, fault word), the production counters for the same period, the order table from SAP PP with the SKU and rated speed, the downtime log with its reason-code tree, and the shift log, even on paper. The clocks must agree: a counter in the MES that runs two minutes ahead of the historian makes every micro-stop land in the wrong order. The model runs where your data already runs, in your Azure tenant or on a plant server, and writes its results back to the dashboard the shift lead already looks at, not to a new screen.

Food safety sets a boundary that the architecture must respect. HACCP, BRCGS and IFS Food require the CCP records and the batch record to be complete and unaltered, and GMP requires that nobody can tell afterwards that a value was changed by a system that should not have touched it. The OEE model therefore has read access only: it never writes to the batch record, never clears a CCP deviation and never closes a quality hold. It can tell you that metal-detector rejects doubled after a changeover; QA decides what that means for the batch.

What an OEE model does not fix

It does not fix a counter that resets at midnight, a rated speed in SAP PP that nobody has updated since the line was rebuilt, or a reason-code tree in which 'other' is the largest bar. The audit starts there, and a plant that disputes its own ideal cycle time will dispute every performance figure built on it. Agree the rated speed per SKU with the line lead before the first chart is shown.

It does not make one OEE for the plant useful. A plant OEE of 71% hides the filler at 58% behind the mixer at 84%; per line, per shift, per SKU is the level at which a loss has a cause and an owner. Do not aggregate above the line unless the board asks for it, and then show the line figures underneath.

It does not predict what the data has never seen. A model trained on three months of summer SKUs has no view of the Christmas SKU with the fragile cap. It predicts well where the pattern repeats: the ramp after every CIP, the capper that starts micro-stopping when the ambient temperature passes 26 degrees, the Monday morning start-up. For the rest, the shift lead is still the sensor.

And it does not replace the shift lead. The model proposes a cause and a probable loss; the shift lead sees the evidence (the tag trace, the counter plateau, the shift-log entry) and decides. A plant where the model's output is an order rather than an explanation gets a shift team that stops logging reasons, and the data decays within a quarter.

A filling line, with the assumptions stated

The OEE formula is OEE = Availability × Performance × Quality. Availability is run time divided by planned production time. Performance is ideal cycle time times total count, divided by run time. Quality is good count divided by total count (oee.com). An OEE of 85% is often called world class; most plants sit closer to 60% (oee.com, World-Class OEE).

Take an illustration, not a client result. Assume a juice filling line in one of several Dutch plants, two eight-hour shifts a day, with a 30-minute planned CIP and changeover per shift, so planned production time is 15 hours. The downtime log shows 2.25 hours of coded stops, so run time is 12.75 hours and availability is 85.0%. The rated speed for this SKU in SAP PP is 12,000 bottles an hour, an ideal cycle time of 0.3 seconds. The counter shows 127,500 bottles, so performance is (0.3 s × 127,500) / (12.75 h × 3,600 s) = 83.3%. The checkweigher and metal detector rejected 2,550 bottles, so quality is 124,950 / 127,500 = 98.0%. OEE is 0.850 × 0.833 × 0.980 = 69.4%.

The dashboard stops there. The model goes on. In this illustration, the historian shows the filler running at 9,600 bottles an hour for the first 40 minutes after each CIP while the product temperature settles, and the capper's state tag toggling 28 times a shift for 20 to 60 seconds, below the two-minute reason-code threshold, so none of it is in the downtime log. Together these two patterns account for about 7 of the 16.7 performance points lost (two ramps of 40 minutes at 2,400 bottles an hour short, plus 56 micro-stops averaging 40 seconds). The model names them, shows the traces, and predicts the ramp loss for tomorrow's order sequence. Whether to change the CIP recipe or swap the capper's star wheel remains the shift lead's and the maintenance planner's decision.

What a point is worth you set yourself. If the plant values one hour of effective line capacity at €1,500 (replace this with your own figure), one OEE point on this line is 0.15 effective hours a day, about €225 a day, or roughly €56,000 over 250 production days. Recovering four points on one line is then in the order of €225,000 a year, before anything is spent on a new machine.

Three fixed steps, excl. VAT, all code and models handed over. An AI audit and strategy for €2,500, one to two weeks: we take three months of historian, counter, order and downtime data from one line, calculate OEE per shift and SKU to one agreed definition, and show which losses are coded, which are hidden and what the data can and cannot explain. You keep the OEE definition, the data map and the loss Pareto. A Production-ready MVP for €20,000, four to six weeks: the OEE model on one line in one plant, micro-stop and speed-loss explanation, a next-shift prediction, running next to the current dashboard. You keep a working model on your own data. Production from €50,000, from eight to twelve weeks: all lines across your plants on one namespace, connected to the historian, the MES and SAP PP, in your Azure tenant or on site, with the shift lead's screen as the output. The audit is credited in full if you continue within 60 days. See AI implementation, AI for manufacturing, data engineering and machine learning. Crux Digits works from Utrecht, on site in your plants, alongside your ICT partner and OT integrator.

Frequently asked questions

Can we calculate OEE without an MES?

Yes, if the PLC exposes counters and states and a historian or edge platform (AVEVA PI, FactoryTalk Historian, Ignition, Litmus Edge) records them. The MES makes it easier, because it already carries the order, the SKU and the reason codes; without it, those come from SAP PP and the shift log.

Why do our plants report different OEE for the same kind of line?

Usually because the definition differs: one plant counts the CIP as planned downtime and another as a stop, one uses the nameplate speed and another the agreed rated speed per SKU. One namespace and one formula across plants is the first thing the audit fixes, before any model.

How does the model find micro-stops that are not in the downtime log?

From the historian: a state tag that flips to fault and back within a minute, or a counter that stops incrementing for 40 seconds, is a stop whether or not anyone coded it. The model clusters those events by machine, SKU and shift and shows the traces, so the shift lead can see them rather than take them on trust.

Does it touch our HACCP, BRCGS or IFS records?

No. The model has read access only. It never writes to the batch record, never clears a CCP deviation and never closes a quality hold. It can report that rejects rose after a changeover; what that means for the batch is QA's decision, as the standards require.

What does OEE per line with AI cost?

At Crux Digits: an AI audit and strategy for €2,500 (one to two weeks), a Production-ready MVP for €20,000 (four to six weeks) on one line, and production from €50,000 (from eight to twelve weeks) across lines and plants, all excl. VAT, with code and models handed over. The audit is credited in full if you continue within 60 days.