Key takeaways
- OEE is availability × performance × quality; each rests on its own data source and definition.
- The value of OEE depends on definitions; comparing lines without written planned-time and ideal-cycle definitions is misleading.
- If counter reset, shift boundary and missing-data rules are not defined up front, impossible values such as performance above 100% appear.
- Instead of averaging percentages, add up times and counts and calculate the ratio from the totals.
OEE is easy to calculate: availability, performance and quality are multiplied. The hard part is making the data underneath those three ratios beyond argument. Different people can find different OEE values for the same line; the cause is usually definition and data rather than formula. This article collects the six mistakes we see most often and their remedies.
The formula and what the three ratios mean
The three ratios are defined as:
- Availability = run time / planned production time
- Performance = (ideal cycle time × total count) / run time
- Quality = good count / total count
OEE is the product of the three. For example, if a shift has 480 minutes of planned time, 420 minutes of run time, an ideal cycle of 30 seconds (0.5 minutes), 700 units produced and 686 good units: availability is 420 / 480 = 87.5%; performance (0.5 × 700) / 420 = 83.3%; quality 686 / 700 = 98%; OEE is about 71.5%. The OEE calculator shows the same calculation together with the loss breakdown.
Mistake 1: Starting without defining planned time
Which stops are included in planned production time (breaks, planned maintenance, changeovers, waiting for raw material) directly changes OEE. Some plants remove planned maintenance from planned time, others count it as downtime. What matters as much as which you choose is that the choice is written down and fixed; otherwise the OEE of two periods cannot be compared.
Mistake 2: Taking the ideal cycle from the actual speed
Performance is measured against the ideal cycle time. If the ideal cycle is derived from the line’s current, slowed speed, performance artificially approaches 100% and the loss from slowing down becomes invisible. The ideal cycle should be defined per product from a fixed reference such as the machine’s design speed or proven best speed, and changes to it should be recorded. If performance goes above 100% the ideal cycle has usually been defined too slow, or a counter has been misread.
Mistake 3: Misreading counters
PLC counters are usually continuously rising totals; to get a quantity you need the difference between two readings. When a counter resets (start of shift, machine restart, rollover) the difference comes out negative. Put the reset case under a rule: if the difference is negative, take the new value as the increase or flag that reading as invalid.
If total count and good count come from separate sources, verify that both are read in the same time window and with the same reset logic; otherwise good count can come out larger than total. This pattern is covered in the SQL schema guide and the SQL table designer.
Mistake 4: Recording downtime without a reason
Machine state (running/stopped) alone gives the loss of availability but not its cause. Without a downtime reason you cannot know which loss to act on. You can gather the reason from automatic (alarm, status code) and manual (operator selection) sources; if you use both, there must be a written rule about which one applies.
Short stops (micro-stops) are often not recorded at all and show up as a performance loss; decide whether you want to track them separately. The classic OEE loss classification (the six big losses: breakdowns, setup and adjustments, minor stops and idling, reduced speed, start-up rejects, production rejects) gives a framework for making that distinction.
Mistake 5: Not splitting records at shift and day boundaries
A stop can start at a shift change and end in the next shift. Writing the event only to the shift where it started distorts the OEE of both shifts; durations should be split at shift boundaries. Time zone and daylight-saving rules can also move the boundary; storing times in UTC and converting to local time in reporting reduces this problem.
Mistake 6: Averaging percentages
Averaging the OEE of two lines does not give the plant’s OEE. If one line is planned for 10 hours and the other for 2, the line with the longer planned time should weigh more in the result. The correct aggregation is to add up times and counts and calculate the ratio from the totals. The same rule applies when aggregating daily values to a month.
Instead of aiming at a single number, track the availability, performance and quality components separately; the components show which loss to act on.
Targets and validation
Figures such as the often-quoted “85% world class” can be a starting point but are not a valid target for every process; set the target using your own definitions and your own history.
To validate the data pipeline, compare one shift against a manually kept record; flag performance above 100% and missing telemetry separately. The OEE data model guide walks through this validation step by step, and the OEE and production performance solution page shows the data flow.
Frequently asked questions
What is a good OEE value?
There is no single universal target. Fix the planned-time and ideal-cycle definitions first, then follow change over time with the same definition.
Should I calculate OEE in the PLC or in the MES?
More important than where the calculation happens is that the input data (counter, state, downtime reason) is defined and verifiable. You can build a flow that collects the data and transfers it to a database; the formula can be calculated in an SQL view or in a BI tool.
Why does performance exceed 100%?
Performance can exceed 100% when the ideal cycle time is defined slower than the actual speed or when a counter reset is misread. Flag it as an error and review the ideal cycle.