Overall Equipment Effectiveness (OEE) is the single most useful metric for identifying where production time is being lost. But many manufacturers hesitate to measure it because they assume it requires a full MES implementation. It does not. With the right data collected at the PLC level and a lightweight IIoT stack, you can have actionable OEE dashboards running in days — not months.

What OEE Actually Measures

OEE = Availability × Performance × Quality. World-class OEE is considered 85%+. Most plants we work with start in the 55–70% range — not because their machines are unreliable, but because they are not measuring the losses systematically.

OEE Factor	What It Measures	PLC Data You Need
Availability	% of planned time the machine was running	Machine run/stop state + downtime reason codes
Performance	% of actual output vs theoretical maximum	Part count + cycle time + target cycle time
Quality	% of parts produced without defects	Good part count + reject count (or rework flag)

Step 1 — Define the Data Points in Your PLC

Most PLCs already have the raw signals you need. The issue is that they are not structured for OEE reporting. Before touching any IIoT middleware, define a data block (or equivalent structure) in the PLC that aggregates these signals into clean, time-stamped values:

→Machine state: RUNNING / IDLE / FAULT / CHANGEOVER / PLANNED_STOP (use an integer enum, not a bit field)

→Downtime reason code: integer mapped to a reason table (e.g. 1=material shortage, 2=tooling change, 3=mechanical fault)

→Part counter: cumulative good part count (reset at shift start)

→Reject counter: cumulative rejected/reworked parts

→Cycle time: actual cycle time of last part (ms), updated on each part completion

→Target cycle time: configured value in ms — the theoretical maximum performance

→Shift start/end: timestamps driven by shift schedule logic already in most PLCs

Key principle: Define machine states explicitly. The biggest OEE measurement error is not distinguishing planned stops (changeover, maintenance windows) from unplanned downtime. Planned stops should reduce planned production time, not appear as availability losses.

Step 2 — Extract Data with Node-RED via OPC-UA or MQTT

Node-RED is the fastest way to connect PLC data to a time-series database without writing a custom application. It runs on a lightweight industrial PC or a Raspberry Pi alongside the line.

For Siemens S7-1500 PLCs: use the node-red-contrib-s7 node or expose the data block via OPC-UA (built into S7-1500, no licence required) and use node-red-contrib-opcua. For Rockwell systems: use the EtherNet/IP node or FactoryTalk Optix as a data bridge. For other PLCs: if they support MQTT publish natively (Beckhoff TwinCAT 3 does via TF6701), subscribe directly.

A typical Node-RED flow for OEE data collection:

Poll or subscribe to the OEE data block every 1–5 seconds (or on change for state transitions)

Add a timestamp to every message payload using the Inject node or msg.timestamp

Transform the payload to InfluxDB line protocol format using a Function node

Write to InfluxDB using the influxdb-out node

Step 3 — Store in InfluxDB

InfluxDB is purpose-built for time-series data and handles millions of data points efficiently on modest hardware. For a single line OEE project, InfluxDB OSS (open source, free) on a 4-core industrial PC with 8GB RAM and a 256GB SSD stores years of 1-second data.

Structure your data with these measurements (tables) and tags:

InfluxDB measurements:

machine_state,line=line1,shift=A state=2i,reason_code=0i 1700000000

production,line=line1,shift=A good_count=1245i,reject_count=12i 1700000000

cycle_time,line=line1 actual_ms=4820i,target_ms=4500i 1700000000

Tag your data by line, shift, and product — this is what allows Grafana to filter and aggregate OEE by these dimensions.

Step 4 — Build OEE Dashboards in Grafana

Grafana connects natively to InfluxDB and provides all the panels you need for OEE reporting. The key calculations are done as Flux queries (InfluxDB's query language):

Availability

Sum(time in RUNNING state) / Sum(time in RUNNING + IDLE + FAULT states) for the shift

Performance

Sum(good_count × target_cycle_time) / Sum(time in RUNNING state)

Quality

Sum(good_count) / Sum(good_count + reject_count)

OEE

Availability × Performance × Quality — calculated as a derived metric in Grafana

Add a Stat panel showing current shift OEE with colour thresholds (red below 65%, yellow 65–80%, green above 80%), a time series showing OEE trend across the shift, and a bar chart showing downtime by reason code — this last panel is usually the most actionable for the production team.

What This Costs and How Long It Takes

Hardware: one industrial PC running Node-RED + InfluxDB + Grafana. A used industrial PC (Advantech, Siemens IPC) costs under 500 USD. Software: Node-RED (free), InfluxDB OSS (free), Grafana OSS (free). Connectivity: OPC-UA on S7-1500 is free. EtherNet/IP nodes for Rockwell are free.

Engineering time depends on how clean the existing PLC code is. If the machine states are already well-structured in the PLC, adding the OEE data block and building the Node-RED + Grafana stack takes 2–3 days. If the machine state logic needs to be built from scratch, allow 1–2 weeks including testing.

The result is a self-hosted, vendor-neutral OEE system that your maintenance team can access from any browser on the factory network. No cloud subscription. No licence fees. No vendor lock-in. If your production data eventually warrants a full MES, the data model you built here maps cleanly onto most MES platforms — you have not wasted the investment.

OEE Monitoring Without a MES: Getting Actionable Data from Your PLC