OEE (Overall Equipment Effectiveness) summarizes in a single percentage how effectively a machine runs during planned time. The formula is simple; what is hard is collecting the input data reliably. Wrong state information, a rolled-over counter or inconsistent downtime codes quietly spoil the calculation and produce a number such as “OEE 85%” that inspires confidence but is wrong.
OEE = Availability × Performance × Quality. For this you need machine state from the PLC, total and reject piece counters, an ideal cycle time and a standard downtime reason code.
The formula
| Component | Formula | Data needed |
|---|---|---|
| Availability | Run time ÷ Planned production time | Machine state, plan (shift, planned breaks), downtime durations |
| Performance | (Ideal cycle time × Total count) ÷ Run time | Total count counter, ideal cycle time (per product) |
| Quality | Good count ÷ Total count | Good/reject piece counters |
| OEE | Availability × Performance × Quality | All of the above |
Example calculation (hypothetical): Planned time is 480 min; stops total 60 min → run time 420 min, availability 87.5%. If the ideal rate is 60 pieces a minute, 25,200 pieces are expected in 420 minutes; if 21,000 were actually made, performance is 83.3%. If 20,160 of the 21,000 produced are good, quality is 96%. OEE = 0.875 × 0.833 × 0.96 = 70%.
Which data should be collected?
- Machine state: an enumerated state such as running, stopped, idle, faulted, planned maintenance. A single “running” bit is usually not enough.
- Total piece counter and reject piece counter (or good piece counter).
- Ideal cycle time: by product or recipe; it should come from the MES/ERP (recipe transfer).
- Downtime reason code: operator selection or automatic detection by the PLC.
- Shift and plan information: planned break and maintenance times are subtracted from the calculation.
- Timestamp and quality: every data point with its source time and quality (data quality and timestamps).
Designing downtime codes
Downtime codes are the “why?” layer of OEE. A good structure:
- Keep it short and hierarchical. A few main groups (planned, fault, material, setup/changeover, quality) with reasons beneath. Hundreds of codes make accurate operator selection impossible.
- Separate planned from unplanned. It is the basic distinction for the availability calculation.
- Detect automatically where possible. Reasons the PLC knows (for example “infeed sensor empty”) should not be left to operator guesswork.
- Carry the same meaning on all lines. If the same code means different things on different lines, comparison becomes meaningless.
- Give code management an owner. It must be clear who can add and change them.
Common data mistakes
| Problem | Effect | Countermeasure |
|---|---|---|
| Counter rollover or reset | Negative or enormous production quantity | Delta calculation; reset detection |
| Stops split at a shift boundary | Stops are wrongly allocated to two shifts | Timestamped event records; a split rule at the boundary |
| Micro-stops (seconds) | Invisible performance loss | Adequate state sampling; define a small-stop threshold |
| Stale or Bad data | Wrong state and counters | Filter by quality; manage the gap explicitly |
| Clock offset | Stops and production do not match | Synchronize with NTP |
| Non-standard ideal cycle time | Performance comes out too high or too low | Approved cycle times per product |
The data path
PLC data is collected with Kepware Server, converted into event records on state transitions with OPC Router and written to an SQL database (moving PLC data into SQL). Recording a state change as an event takes less space than sampling every second and also gives downtime more accurately. Buffering is needed against data loss in connection outages. To match energy data to production see aligning energy data with production.
Frequently asked questions
What is a good OEE value?
It varies by industry and product; rather than tying yourself to a single number such as “world class”, focus on your own line’s trend over time and its loss reasons.
Do I need a separate system for OEE?
No; you can start with a database where the right data is collected and a simple report. MES and OEE software offer extra features but do not solve data quality problems.
Should the operator or the PLC choose the downtime reason?
The PLC should detect automatically what it can; for the rest the operator should choose from a short code list.
