How do I set up an edge data collector for streaming PLC and sensor data to OEE dashboards?

Here’s a practical way to set up an edge data collector for streaming PLC and sensor data into OEE dashboards.

1) Define the data path

Typical flow:

PLC / sensors → edge collector → message broker / time-series store → OEE app / dashboard

The edge collector should:

• read tags from PLCs and sensors
• normalize and timestamp data
• buffer locally if network fails
• publish to a central system or cloud

2) Pick the right edge hardware

Use an industrial PC or gateway with:

• industrial temperature rating
• dual Ethernet if possible
• SSD storage for buffering
• UPS or reliable power
• optional serial/fieldbus ports if needed

Common choices:

• Industrial x86 gateway
• DIN-rail Linux gateway
• Ruggedized IPC

3) Choose protocols

Use whatever your PLCs and devices support:

• OPC UA for modern PLCs
• Modbus TCP/RTU for simpler devices
• EtherNet/IP
• PROFINET via compatible gateway/software
• MQTT for outbound publishing
• REST/HTTP if you have API-based sources

If you can, standardize on OPC UA at the edge and MQTT outward.

4) Select edge software

Your edge collector software should support:

• multi-protocol ingestion
• tag polling or subscriptions
• local store-and-forward
• timestamping and deadband filtering
• transformation/rules
• secure MQTT/TLS or HTTPS publishing

Examples of approaches:

• Industrial IoT platform agent
• OPC UA client + MQTT bridge
• Custom service using Node-RED, Python, or Go
• SCADA/historian edge connector

5) Model the OEE data correctly

For OEE, you usually need more than raw sensor values.

Core OEE signals

• State machine data: running, stopped, faulted, idle
• Counter data: good parts, scrap, total count
• Cycle time / takt time
• Downtime reasons
• Speed / rate
• Availability events

Useful derived fields

• machine_id
• line_id
• shift_id
• product / job order
• timestamp
• event_type
• duration
• reason_code

Make sure you have:

• a unique machine identifier
• consistent timestamps
• clear status transitions
• counters that don’t reset unexpectedly without detection

6) Build the edge pipeline

A simple architecture:

1. Poll or subscribe to PLC tags
2. Normalize into a common schema
3. Filter noisy changes
4. Aggregate at an appropriate rate
5. Buffer locally
6. Publish to MQTT broker, Kafka, or HTTP endpoint

Example transformations:

• Convert raw bit states into machine states
• Map PLC alarm codes to reason codes
• Calculate part count deltas
• Detect start/stop events from tag transitions

7) Add local buffering and failover

This is critical on the shop floor.

Implement:

• local queue or disk-backed buffer
• retry with exponential backoff
• message acknowledgment
• resend after connection loss
• data compression if bandwidth is limited

Goal: no data loss during short outages.

8) Secure the connection

Use:

• TLS for MQTT/HTTPS
• device certificates or strong credentials
• network segmentation
• firewall rules
• least-privilege accounts for PLC reads
• no direct inbound access to PLC networks from the cloud

Best practice:

• edge device sits in OT network
• central dashboards are in IT/cloud network
• data flows outbound only

9) Time synchronization

OEE depends on accurate timestamps.

Use:

• NTP on edge devices
• PLC clock sync if supported
• consistent timezone handling
• UTC for storage, local time for display

If devices have poor clocks, let the edge collector timestamp on receipt.

10) Store and publish to a dashboard backend

Common backends:

• Time-series DB: InfluxDB, TimescaleDB
• Streaming bus: MQTT, Kafka, Azure IoT Hub, AWS IoT Core
• Historian: Ignition, OSIsoft/AVEVA PI, etc.

For OEE dashboards, you often want:

• event stream for state changes
• time-series for counts and rates
• relational store for shifts, products, and reason codes

11) Dashboard layer

Your OEE dashboard should calculate:

• Availability
• Performance
• Quality
• OEE = A × P × Q

It should also show:

• machine status timeline
• top downtime reasons
• shift performance
• alarm/fault frequency
• scrap vs good counts

12) Testing and validation

Before rollout:

• validate tag mappings against PLC values
• test network outage recovery
• compare edge counts with PLC/HMI totals
• verify timestamp accuracy
• simulate bad data and reconnection
• confirm OEE calculations with known production scenarios

13) A simple recommended stack

If you want a straightforward setup:

• Edge device: industrial Linux gateway
• Ingestion: OPC UA client and/or Modbus poller
• Local processing: Node-RED or Python service
• Transport: MQTT over TLS
• Storage: InfluxDB or TimescaleDB
• Dashboard: Grafana or an OEE-specific web app

14) Example architecture

PLC tags

• MachineRunning
• PartCount
• FaultCode
• GoodCount
• ScrapCount

Edge collector

• subscribes/polls every 500 ms to 2 s
• detects state changes
• buffers locally
• publishes JSON payloads like:

{
  "machine_id": "LINE1_PRESS3",
  "timestamp": "2026-08-04T14:22:10Z",
  "state": "running",
  "part_count": 12458,
  "good_count": 12390,
  "scrap_count": 68,
  "fault_code": 0
}

Backend

• stores events and aggregates
• dashboard computes OEE by shift, day, product

15) Common pitfalls

Avoid:

• polling too fast and overloading PLCs
• relying only on raw counters without state data
• bad timestamp handling
• no buffering during outages
• mixing machine states and reason codes without a clear model
• insecure remote access to OT devices

---

If you want, I can also give you:

1. a reference architecture diagram,
2. a bill of materials for a real deployment, or
3. a sample edge collector implementation using Node-RED, Python, or MQTT/OPC UA.