Industrial IoT Development for Manufacturing & Automation
Manufacturers do not lose OEE because they lack data, they lose it because a stop reason arrives a shift late, a counter double-counts, and the MES says the line ran while the machine sat idle. We instrument the shop floor at the source: read PLC tags over OPC-UA, latch discrete stop/run signals, correlate them with MES work orders and energy draw, and stamp everything to a common clock. The result is a KPI you can act on inside the cycle, not reconcile at the end of the month.
Challenges specific to Manufacturing & Automation
Manual stop-reason capture is late and wrong
Operators tag downtime on a clipboard or a kiosk minutes after the fact, so micro-stops vanish, reasons get lumped into 'other', and the availability number nobody trusts drives the wrong improvement projects.
Cycle counters double-count or miss parts
Polling a PLC counter tag too slowly aliases fast cycles, while reading a debounced photo-eye on a slow scan misses parts during jams, so the performance KPI drifts from the actual throughput the line produced.
MES says running while the machine is idle
When the only signal is the work-order state in the MES, a blocked or starved machine still shows as productive, hiding the real constraint and inflating availability against a planned production time that was never validated against the asset.
Energy and production data live in separate islands
Submeter kWh sits in a building-management system and part counts sit in the MES, so nobody can compute energy-per-good-part or catch a heater or compressor drawing load while the line is supposedly stopped.
Quality rejects are not tied to the producing cycle
Vision or gauging results land in a separate database with their own timestamp, so a scrap spike cannot be traced back to the specific machine, tool change, or work order that produced it, and first-pass yield is an estimate.
OPC-UA and legacy buses choke a flat plant network
Subscribing to thousands of PLC tags at a fast publish rate, plus Modbus polling of legacy assets on the same VLAN as MQTT telemetry, saturates the link and induces jitter that corrupts the very timestamps the KPIs depend on.
How GizanTech solves them
- Edge stop-reason latching with state machine. An edge gateway watches the PLC run/stop and fault tags, latches the exact stop edge to the millisecond, and classifies it via a state machine (planned, blocked, starved, fault) before the operator ever sees the kiosk, so micro-stops and reasons are captured automatically per ISA-95 production-event semantics.
- Hardware-counted throughput, reconciled to PLC. We count parts on the gateway with a debounced discrete input or a high-rate OPC-UA subscription on the cycle tag, then reconcile against the PLC's own counter each shift, so performance KPIs reflect true ideal-cycle vs actual-cycle without aliasing or double counts.
- MES/ERP context binding per work order. The gateway binds each production event to the active work order, part number, and ideal cycle time pulled from the MES/ERP over a REST or OPC-UA bridge, so availability is measured against validated planned production time instead of an assumed calendar.
- Unified energy-per-part correlation. We bring Modbus or M-Bus submeter kWh into the same timestamped stream as the part count, computing energy-per-good-part and flagging baseload draw while the line is stopped, exposing compressor, heater, and idle-state waste the BMS never attributed to production.
- Quality event join at the producing cycle. Vision and gauging verdicts are tagged with the same machine clock and work-order key as the cycle that produced them, so first-pass yield and scrap reasons resolve to a specific asset, tool, and order, closing the quality leg of OEE with real data.
- Store-and-forward time-series pipeline. Telemetry is buffered at the edge with monotonic timestamps, published over MQTT Sparkplug B with report-by-exception to cut bandwidth, and forwarded to a time-series store, so a network blip never loses a stop event or skews the KPI clock the dashboards rely on.
| Shop-floor source | Connectivity | KPI it feeds | Latency need | Failure prevented |
|---|---|---|---|---|
| PLC run/stop & cycle tag | OPC-UA subscription (report-by-exception) | Availability + Performance (true cycle) | Sub-second on the stop edge | Late, lumped stop reasons that mislabel availability |
| Discrete machine signal (photo-eye / counter) | 24V digital input, debounced at the edge | Performance (good-part throughput) | Per-cycle, no missed/aliased pulses | Counter double-count and parts lost during jams |
| MES / ERP work order | REST or OPC-UA bridge to the MES | Availability vs validated planned time | Per work-order change (seconds) | Idle machine logged as running productive time |
| Energy submeter | Modbus RTU/TCP or M-Bus poll | Energy-per-good-part + idle baseload | 1-5 s poll, aligned to cycle clock | Hidden baseload draw while the line is stopped |
| Vision / quality gauge | MQTT / OPC-UA verdict, machine-clock stamped | Quality (first-pass yield, scrap reason) | Tied to the producing cycle, not wall-clock | Scrap untraceable to the cycle, tool, or order |
Go deeper
Industrial IoT Development for other industries
Frequently asked questions
Do we have to replace our PLCs or MES to get OEE?
No. We read your existing PLCs over OPC-UA or Modbus and bridge to the MES/ERP you already run, so the edge gateway sits alongside the control system as a read path and never touches the safety or control logic on the line.
How do you capture stop reasons without relying on operators?
The gateway latches the run/stop and fault tags directly from the PLC and classifies the stop with a state machine before any human input, so micro-stops and blocked/starved states are recorded automatically; the operator kiosk only confirms or refines a reason that is already captured.
Why measure parts at the edge if the PLC already counts them?
PLC counters are reliable per shift but easy to alias when polled slowly, and they reset or roll over in ways that corrupt a live rate. We count on the gateway per cycle and reconcile to the PLC counter each shift, giving an accurate live performance KPI and a trustworthy shift total.
Can you combine energy data with production data?
Yes. We poll energy submeters over Modbus or M-Bus into the same timestamped stream as the part count and work order, so you get energy-per-good-part and can see baseload draw while the line is stopped, which the building-management system never attributes to a machine or order.
What protocol do you publish telemetry over, and is it bandwidth-safe?
We standardize on MQTT, typically Sparkplug B, with report-by-exception so only changes are sent instead of polling thousands of tags at a fixed rate, and we segment the telemetry network from control traffic so the publish load never induces jitter that corrupts KPI timestamps.
How accurate are the OEE numbers compared to our current reports?
Because availability is measured against validated planned time, performance uses true ideal-versus-actual cycle, and quality is joined to the producing cycle, the OEE is computed from source events rather than reconstructed from spreadsheets, so it is auditable to the second instead of estimated a shift late.