The indicator: OEE
OEE says how much of the planned time turned into good pieces at the ideal speed. It breaks down into three factors, each tied to one family of losses.
Availability = run time ÷ planned time
Performance = (ideal cycle time × pieces produced) ÷ run time
Quality = good pieces ÷ pieces produced
OEE = availability × performance × quality
To try the formula with your own numbers there is the OEE calculator with an Excel template; the guide to calculating OEE explains the losses behind each factor.
What the dashboard shows
- OEE per machine and shift, with availability, performance and quality shown apart.
- The six big losses and the Pareto of stop causes.
- Micro-stops hour by hour: the short stops nobody records, rebuilt from the machine states.
- The trend after a die change, to see whether a press slows down before the week is lost.
- The version for the shop floor, full screen on a TV, always on.
The data to read from the PLC
| Signal | Where it sits in the PLC | What it is for |
|---|---|---|
| Stroke or part counter | A counter in a data block | Pieces produced and performance |
| Machine state | A status word or a few bits: running, stopped, in alarm, in setup | Run time and micro-stops |
| Stop reason | A code entered from the operator panel, if there is one | The Pareto of causes |
| Scrap | A rejected-parts counter, or quality control | Quality |
| Die or program | A number or a string | The right ideal cycle time for each piece |
Orders and ideal cycle times per item often sit in the MES or the ERP, for example on SQL Server, and the shift calendar in an Excel file: they are connected as cloud sources.
The steps in Muvia Industrial
An edge node is installed on the shop floor, on Debian, Ubuntu or Raspberry Pi 4, and enrolled with a token.
On the node you add the Siemens S7 driver: the PLC's address and the signals to read, at the frequency you choose. If the network to the cloud drops, the node keeps the data in a local buffer and sends it when the connection returns.
Orders, cycle times and shifts arrive from the cloud sources.
Muvia has no packaged OEE module: your team writes the calculation once, in a Python function that a flow runs every morning for each machine and shift, and that writes a table of OEE and losses.
The dashboard reads that table; the shop-floor version runs in kiosk mode on a TV, and an alarm warns when a press's OEE drops below the chosen threshold.
The pitfalls of PLC counters
- Counters that restart from zero: after a PLC restart, or on reaching their maximum value, counters go back to zero. The calculation must work on increments and recognise the jump, not subtract the first value from the last.
- Strokes and pieces: with a multi-cavity die one stroke makes several pieces. The number of cavities per die must be joined to the counter.
- Read frequency: if states are read once a minute, a twenty-second stop may not show up. For micro-stops, read states more often, or read a stop counter kept by the PLC.
- Planned setup or loss: a die change counts as a stop in OEE, but some companies take it out of planned time. Decide once and write it in the function.
- Shifts across midnight: the night shift must be assigned to the day it starts, with an explicit rule.
Frequently asked questions
Usually not, if counters and states already exist in a readable data block. If something is missing, such as a stop reason, it has to be added in the PLC by whoever maintains its program.
The Siemens S7 driver can also write, but OEE only needs reads: no value is written to the PLC.
No. Your team writes the calculation once, in a Python function: that way the definitions of planned stop and ideal cycle time stay yours. Muvia runs it every morning for each machine and shift.
The same node also reads OPC UA, by polling or subscription, and Modbus TCP. The OEE calculation does not change.