OEE Monitoring Software: Equipment Effectiveness from Live Machine Data
Overall Equipment Effectiveness (OEE) may be the most-quoted metric in manufacturing — and at the same time one of the worst measured. In many plants it is assembled from shift sheets, Excel spreadsheets, and memory: by Friday, Tuesday night’s downtime is nothing more than an estimate. If you truly want to understand your bottlenecks, you need your machines’ states — captured automatically, time-stamped, in context.
This guide shows how to build the data foundation for OEE and downtime monitoring with IronFlock: from machine connectivity through capturing downtime reasons to a live dashboard per line.
The problem: second-hand OEE
Typical symptoms of a manually compiled OEE:
- Delay instead of reaction. Metrics arrive days after the event — too late to intervene during the running shift.
- Incomplete downtime capture. Short stops of a few minutes never make it onto any tally sheet, yet they add up to the biggest availability loss.
- Unclear causes. “Machine was down” is not a cause. Without structured reasons, you cannot prioritize what to fix first.
- Every machine is a special case. CNC machines, PLC-controlled lines, and legacy equipment report their states over different protocols — or not at all.
Step 1: capture machine states automatically
The foundation of any OEE view is availability — and availability lives in the machine states. IronFlock captures them with the collector apps for factory data extraction, straight from the brownfield reality:
- MTConnect Collector for CNC machine tools (such as HAAS, Mazak, DMG Mori, Fanuc, Okuma) — MTConnect delivers operating states, programs, and axis values standardized, out of the box.
- Industrial Collector for PLC-controlled equipment: OPC UA and Modbus work today; Siemens S7 and Allen-Bradley are in early access — S7-1200/1500 controllers can already be read through their built-in OPC UA server.
- Modbus Collector as the lightest-weight path when cycle counters and status words are available over Modbus TCP.
- IO-Link Collector for retrofits: where the controller gives up no states, retrofitted sensors (current, vibration, light barriers) deliver the running/stopped signals.
All collectors normalize the raw data into named measurements with timestamp and quality flag and use the same table schema — including a dedicated status table for machine states. Configuration happens entirely in the browser; a demo mode generates realistic data before the first machine is connected.
All states and counters land in the project database — a dedicated time-series database per project, on which everything downstream builds.
Step 2: document downtime reasons in a structured way
Not every piece of information comes from the controller. Why a machine was down — changeover, missing material, breakdown — is often known only to the team at the line. For that, Board Studio offers forms: operators record downtime reasons directly on the board, structured instead of on paper, with a change history. Alongside the automatic state capture, this creates the cause dimension that turns an availability number into a basis for improvement.
Step 3: make OEE visible — per machine, line, and site
On the shared data foundation, you build the analysis without code:
- Live boards in Board Studio. Availability and performance metrics, state timelines, and part-count trends by drag-and-drop — with sub-second latency from edge to screen, no polling.
- Split Charts. A chart configured once fans out automatically per machine, line, or site — ideal for the shift leader’s view across the whole floor.
- Alarms on downtime. The built-in alarm system watches live telemetry and escalates by email or SMS — with conditions per severity level and auto-resolve as soon as the machine is running again.
- Questions in natural language. With Physical AI you ask “How was OEE on line 2 last week?” — the Data Explorer translates the question into a database query and answers with a number, a table, or a live chart; on request, the Dashboard Generator turns it into a complete board.
For logic beyond that — say, a full OEE calculation with target cycle times and quality data — a consuming app builds read-only on the collector data through cross-app data access. An OEE dashboard that computes availability, performance, and quality per line is the documented showcase of this architecture: collection and analysis stay cleanly separated, and each layer can be extended independently.
The three OEE factors and their data sources
OEE is the product of availability, performance, and quality — and each factor needs a different data source. The value of a shared platform lies in bringing all three together in the same database:
| OEE factor | Data needed | Source with IronFlock |
|---|---|---|
| Availability | Machine states (running / stopped), downtime reasons | Collector status table; board forms for reasons |
| Performance | Part counters, cycle times, target speeds | Counters from PLC/CNC via collector; targets as app parameters |
| Quality | Good/bad parts, scrap reasons | Counters from the controller or form input at the line |
The practical advice that follows: start with availability. It is the factor with the biggest leverage, machine states are the easiest to capture automatically, and even a pure availability board gives every shift handover something concrete to discuss. Performance and quality follow once part and scrap counters are connected — and nothing about the data model changes, because all collectors use the same schema.
Why the data foundation makes the difference
| Situation | Manual OEE tracking | With IronFlock |
|---|---|---|
| Short stops | Fall through the cracks | Captured automatically, to the second |
| Downtime reasons | Tally sheet, after the fact | Form on the board, with change history |
| Metric available | Days later | Live, per machine and line |
| Multiple sites | Separate Excel worlds | One project database, Split Charts |
| Alerting | Word of mouth | Email/SMS by severity level |
Frequently asked questions
Do I need an MES to measure OEE?
No. For availability and downtime monitoring, the machine states from the collector apps plus the downtime reasons from a board form are enough. An existing MES can be connected in addition — IronFlock apps are regular container workloads and can communicate with existing systems.
How do I capture downtime reasons without overloading operators?
Through forms directly on the board at the line: a few structured fields, predefined reasons, change history included. The automatic state capture supplies the start and duration of the downtime — the operator only adds the cause.
Does this work with older existing machines?
Yes — that is the normal case. Machines with OPC UA, Modbus, MTConnect, IO-Link, or BACnet connect directly; Siemens S7 and Allen-Bradley are in early access. Equipment with no digital interface at all can be captured with a sensor retrofit (such as IO-Link current sensors) — purely hardwired equipment needs a gateway or a retrofit.
Can I compare OEE across lines or plants?
Yes. All states live in the same project database; Split Charts fan out any analysis automatically per machine, line, or site. With Physical AI, you can also ask comparison questions directly in natural language.
Where to go next
Use the getting started guide to connect a first gateway and install a collector in demo mode — your first machine-state board takes shape in minutes, without touching the equipment. The protocol details are in factory data extraction, the visualization in the IoT dashboards guide.