IIoT in SCADA and MES systems for industry
A sensor that reaches nowhere is a lost number. IIoT creates value when a shop-floor reading becomes real-time supervision, a handled alarm, searchable history and a production indicator. That is the work of SCADA and MES layers — and they are different layers with different questions.
SCADA and MES are not the same thing
The confusion is common and expensive in projects. The most direct way to separate them is by the question each one answers.
SCADA
Supervisory Control and Data Acquisition
“What is happening right now?”
- ›Mimic screens with the current process state
- ›Alarms by limit, rate of change and communication failure
- ›Trend history for root-cause analysis
- ›Time scale: seconds
MES
Manufacturing Execution System
“What was produced, how much and at what cost?”
- ›Production orders, reporting and batch traceability
- ›OEE broken down into availability, performance and quality
- ›Operator-classified downtime reasons
- ›Time scale: shift, day, order
Industrial Data Integration Flow
ESP32
Sensor collection & edge device
MQTT
Lightweight telemetry transport
SCADA / MES
Production supervision and management
Dashboards
Real-time visual supervision
Alarms
Incident and event notification
History
Trend database
Industrial indicators
OEE and productivity calculation
Where the ESP32 fits in this architecture
The ESP32 is an excellent edge acquisition node. It reads the sensor, converts the measurement, applies any required filter and publishes — normally over MQTT, as JSON. It does not supervise or calculate OEE: its role is to deliver reliable data, with a timestamp and identity, to the system that does.
Production counting is the clearest example: the number that feeds OEE is valid only if no pulse is lost along the way, and this is where a button-example debounce imposes a production ceiling nobody calculated. The ESP32 production counter tutorial covers the four points that determine whether this number is reliable.
Three decisions determine whether this integration will hold up in production:
- ›Identity and topic: each device publishes to its own predictable topic, so the supervisor knows where the data came from without guesswork.
- ›Heartbeat and Last Will: silence must become an alarm. Without LWT, a fallen node looks like a node with a constant value.
- ›Secure transport: MQTT over TLS on port 8883, with a certificate. Plain-text telemetry crossing the corporate network will not pass an audit.
OT/IT architecture considerations
The boundary between the automation network (OT) and the corporate network (IT) is where most IIoT projects get stuck — usually because of security, not technology. Principles that prevent rework:
- ›Traffic direction: the shop floor publishes outward; the outside world does not open a connection into the cell.
- ›Edge broker: an intermediate broker at the boundary decouples the two networks and survives a link outage without losing telemetry.
- ›Sized retention: trend history grows quickly. Define aggregation and purge before filling the disk, not afterward.
- ›An owner for each alarm: an alarm nobody handles becomes noise, and noise trains operators to ignore it. Fewer, better alarms.
See it assembled end to end
The layers described above exist as a deployed platform: acquisition, supervision, production reporting, history and maintenance from the same data source.