Definition
OEE (Overall Equipment Effectiveness) is the product of availability, performance, and quality rates, used to measure equipment utilization and production efficiency. Edge gateways and industrial gateways can collect data from PLCs, CNC machines, and robots, calculate OEE at the edge, and report it to MES, achieving real-time OEE dashboards for production lines.
Calculation formula
OEE = Availability × Performance × Quality. Availability = Actual operating time / Planned production time, considering downtime due to failures, changeovers, and material shortages; Performance = Actual output / Theoretical output (based on standard cycle time), considering idle time and speed reductions; Quality = Number of conforming products / Total output, considering scrap and rework. World-class OEE is about 85% or higher, while general enterprises are around 60–70%.
Data Acquisition
OEE calculation requires collecting equipment operating status (running/downtime/fault), production output, cycle time, and quality rate. Industrial gateways obtain data from PLCs, CNC systems, and robots via Modbus, OPC UA, EtherNet/IP, etc.; barcode scanners and vision inspection can provide output and quality data. Edge gateways can calculate OEE locally, reducing the amount of uploaded data; alternatively, raw data can be uploaded to MES for unified calculation.
Application Value
OEE helps identify six major losses: breakdowns, changeovers, idling, slowdowns, startup and shutdown defects, and operational defects. Through OEE dashboards, trend analysis, and root cause tracing, it supports lean production, TPM, and continuous improvement. It is one of the core KPIs of MES.
Time Boundaries of the Three Ratios
The product holds only inside one time window
Overall equipment effectiveness is the product of three ratios. Change the time window of the numerator or the denominator of any one of them, and the product no longer means "how much of scheduled time became good product." Availability is the share of planned production time that was actually running. Performance is how fast that running time was against standard takt. Quality is the share of that output that was good. The three uses of "that" have to be the same shift, the same order, or the same reporting day. Multiplying a month's availability by one day's quality produces a number with no operational meaning.
Standard takt comes from the process document, not from average output over the past week. Average output already contains slowdown and idle time. Use it as the theoretical value and performance stays near a perfect score, with the loss hidden. The definition of "good" also has to be written in advance: does a piece that passes after rework count as good for the shift, and does scrap found only downstream count as a loss of the earlier operation? If the basis is not in the point list, a different statistician changes the result.
Planned stops do not belong in availability
Before calculating, mark out planned production time. If meals, no orders, or planned maintenance go into the denominator, availability is pulled down by time when there was no production task. The machine looks poor, and maintenance has nothing to act on. Faults, changeovers, waiting for material, and blocked discharge should stay inside planned time, and they should carry a reason code. A stop with no reason code can only be "unknown." Software must not default it to a performance loss or a quality loss.
The collector has to distinguish running, stopped, and powered off. One automatic bit in the controller is often not enough, because the bit stays true while the machine spins empty and output does not increase. That time belongs in performance, not availability. The meaning of a count pulse has to be fixed: one piece, one mold, or one box. Rejects from vision or from manual entry have to match total output over the same interval. If they do not match, do not publish a ratio precise to a decimal place just to fill the cell.
Takt basis and the pass/fail rule
Changeover is an easy place to go wrong. If changeover is still recorded as running, performance falls. If it is recorded as powered off, availability falls. The two recordings point improvement in opposite directions. Pick one by plant convention and keep it. Another error is a theoretical takt taken from an ideal cycle while the floor includes the specified load and unload. Performance then stays below expectation for a long time, the crew edits the numerator to "make it even," and the indicator loses its value for comparison.
Lagging quality data also breaks the product. Shift output enters the denominator the same night, rejects are entered the next day, that day's quality looks too high, and the next day cannot be tied back to output. Allow write-back by batch, and keep a record of the change. Edge calculation is appropriate only when reason codes and the time window already agree, so the three ratios can be computed and reported. While the point list is still moving, handing raw starts, stops, and counts to MES to compute in one place is less likely to fork. Do not write the ratio from one sample up as the machine's capability. The sample has to cover at least a changeover, a fault, and a normal shift.
A handover between shifts also cuts an unfinished order into two pieces. If the previous shift's downtime reason is not closed at handover, the first hour of the next shift is recorded as reason unknown, and the loss structure on the weekly report drifts every week. Closing time, unfinished quantity, and work-in-process location should be part of the handover data, not something reconstructed from memory the next day.