Operations Excellence

How to Calculate OEE From PLC Data: A Step-by-Step Guide for Industrial Teams

Most OEE programs fail not because teams don't understand the formula — but because they can't reliably source the three inputs: runtime, output, and rejects. Here's how to do it correctly from PLC signals.

Why most OEE calculations are wrong

OEE is Availability × Performance × Quality. The formula is simple. The problem is data quality. Most plants calculate OEE from shift logs filled in after the fact — which means runtime is estimated, output is rounded, and rejects are underreported. The result is an OEE number that looks reasonable in a presentation but bears no relationship to what actually happened on the machines.

Step 1 — Define Availability from machine state signals

Availability = Actual Runtime / Planned Production Time. Your PLC outputs a discrete signal for machine state: running (1) or stopped (0). You need to capture this at a high enough frequency — typically every 1–5 seconds — to accurately calculate runtime. Edge devices connected via Modbus or OPC-UA read these signals and timestamp each state transition. Planned production time comes from your shift schedule: total shift duration minus planned breaks. Do not subtract unplanned downtime from planned time — that's what Availability measures.

Step 2 — Calculate Performance from cycle time data

Performance = (Actual Output / Ideal Output) = (Actual Output × Ideal Cycle Time) / Actual Runtime. Ideal cycle time is the rated speed of the machine — how many parts it should produce per minute at full speed. PLCs typically output a part counter that increments with each production cycle. Read this counter at regular intervals to get actual output. If your PLC doesn't output a counter, derive output from cycle time: measure the duration between consecutive part signals and compare to ideal. Performance below 80% usually indicates speed losses — reduced machine speed, micro-stoppages under 5 minutes, or feeding delays — all of which are invisible without sub-minute data capture.

Step 3 — Capture Quality at the machine level

Quality = Good Parts / Total Parts Produced. This is the hardest input to automate because quality rejections often happen downstream — at inspection, assembly, or the next operation. For real-time OEE, you have two options: capture reject signals at the machine where they occur (some CNCs and presses output reject counts via PLC), or allow operators to log rejection events through a connected interface tied to the current job and machine. The key is linking each rejection to the specific machine, shift, and job it came from — not just the end-of-day tally.

Step 4 — Structure the data in operational context

Raw PLC signals mean nothing without context. A runtime calculation needs to know which shift it belongs to, which job was running, which operator was responsible, and what downtime events occurred during the period. This is why a flat time-series historian is not sufficient for OEE calculation. You need a system that maps machine signals to your production hierarchy — shift schedules, job assignments, planned vs unplanned stops — so that every OEE calculation is automatically contextualized and comparable across lines, shifts, and time periods.

Common mistakes and how to avoid them

Do not include planned maintenance in Availability losses — it is excluded from planned production time. Do not aggregate daily OEE by averaging hourly figures — use the underlying counts. Do not use the same ideal cycle time for all products on a multi-SKU machine — product mix changes ideal output. Do not calculate OEE from memory or manual estimates — you will get 70% on paper every time regardless of actual performance.

Turn this blueprint into action

Book a demo to convert this strategy into a practical pilot and scale plan.

Got questions about Factobrain? Ask Facto →