Rajesh Sekar is a Simulation Engineer at EnerTherm Engineering, specialising in computational fluid dynamics (CFD), finite element analysis (FEA), and thermal process simulation. He holds a degree from Cranfield University and brings extensive experience in simulation-based product development from the automotive, aerospace, and energy sectors.
Computational Fluid Dynamics (CFD)Finite Element Analysis (FEA)Discrete Element Modelling (DEM)Thermal Process Simulation & Optimisation
Using Sparkplug B and TLS 1.3 to safely bridge PLCs for 15-25% energy cost savings.
The MQTT protocol for industrial energy IoT is an open, lightweight publish-subscribe messaging network standard designed to transmit high-frequency energy consumption data from programmable logic controllers (PLCs) to cloud-based analytics platforms with minimal bandwidth and latency. In modern manufacturing and process industries, optimising energy consumption is no longer just an environmental goal; it is a critical operational necessity. Bridging legacy factory-floor controllers with cloud-based intelligence requires an architecture that is secure, non-invasive, and highly efficient.
Traditional industrial communications rely on heavy, poll-response architectures that saturate network infrastructure and demand complex firewall configurations. By implementing the Message Queuing Telemetry Transport (MQTT) protocol, specifically tailored for industrial environments through the Sparkplug B specification, facilities can establish a secure, one-way stream of vital utility data. This technical guide examines how to connect PLCs with MQTT to create an enterprise-grade industrial energy Internet of Things (IoT) infrastructure.
The Role of the MQTT Protocol for Industrial Energy IoT
To understand why MQTT is the preferred transport layer for industrial energy IoT, systems engineers must first analyse the fundamental limitations of traditional industrial communications when applied to cloud telemetry.
Understanding the Publish-Subscribe Architecture
Unlike client-server models where a client directly requests data from a specific server, MQTT operates on a decoupled publish-subscribe (pub-sub) model. The architecture consists of three core components:
Publisher: The data producer, typically an edge gateway or an MQTT-enabled PLC, which sends telemetry to specific topics.
Subscriber: The data consumer, such as an enterprise energy management platform, which registers interest in specific topics.
Broker: The central message clearing house, responsible for receiving published messages and routing them to authorised subscribers.
This decoupling means that the publisher and subscriber do not need to know each other's IP addresses, nor do they need to be online at the same time. This architecture significantly reduces the processing load on edge hardware.
Why Traditional Polling Fails in Energy Monitoring
Traditional industrial protocols such as Modbus TCP or OPC-UA Client-Server rely on continuous polling. Under this mechanism, a central server sends a request to a PLC, and the PLC replies with the requested register values. While this works well for deterministic local control within a local area network (LAN), it fails as a cloud telemetry strategy for several reasons:
Network Congestion: Polling forces the system to transmit data at fixed intervals, even if the value has not changed. This generates vast quantities of redundant traffic.
Latency: If a critical anomaly occurs immediately after a poll cycle, the cloud system remains unaware of the event until the next scheduled poll, delaying critical operator intervention.
Scalability Barriers: As the number of monitored points grows from hundreds to thousands across multiple sites, the network bandwidth and server processing requirements increase linearly, eventually saturating cellular and wide-area network (WAN) links.
The Power of Lightweight Payload Deliveries
MQTT was engineered from its inception to minimise packet overhead. The protocol's fixed header is a mere 2 bytes, compared to the hundreds or thousands of bytes required for HTTP or OPC-UA session handshakes. This extreme efficiency makes it ideal for transmitting high-frequency energy data over constrained networks. It allows factories to stream granular electrical, gas, and steam metrics back to centralised analytics engines without degrading the performance of operational control networks.
Bridging Legacy PLCs to Cloud Energy Intelligence
The vast majority of manufacturing plants operate on brownfield sites populated by legacy PLCs. These controllers manage critical physical processes but are incapable of communicating directly with cloud platforms.
Interfacing with Modbus and OPC-UA
To capture energy telemetry, systems integrators must extract data from existing controllers. Devices like Siemens S7, Allen-Bradley ControlLogix, and Modicon PLCs typically expose data via Modbus RTU/TCP or OPC-UA.
Because legacy PLCs lack native MQTT stacks, systems engineers install Edge of Network (EoN) gateways on the local machine network. The gateway acts as a protocol translator. Locally, the gateway acts as an OPC-UA client or a Modbus master, polling the designated PLC registers at high speeds. Once the gateway ingests this raw register data, it packages the metrics into an MQTT payload and publishes them to the cloud broker.
The Non-Invasive Architecture: Read-Only Data Ingestion
In highly regulated environments such as chemical plants, pharmaceutical facilities (complying with GMP), or food production lines (complying with HACCP), altering a PLC programme to export data is highly discouraged. It requires re-validating the system, introducing substantial operational risk.
To maintain operational integrity, engineers deploy a non-invasive, read-only data ingestion architecture. The edge gateway is configured to read specific parameters from the PLC memory maps (such as DB blocks in Siemens S7 or holding registers in Modbus) without any capability to write back to the controller. The MQTT broker is configured to deny write-back permissions to any external subscribing system. This strictly one-way data flow guarantees that the physical process cannot be manipulated from the cloud, preserving safety and validation states.
Multi-Utility Stream Aggregation
To build an accurate industrial energy profile, the gateway must aggregate data from six distinct utility streams:
Electricity: Transmitting real-time parameters including active power (kW), reactive power (kVAR), current (A), voltage (V), power factor, and totalised energy (kWh).
Gas: Monitoring volumetric flow rates (m³/h), cumulative consumption, pressure, and temperature to calculate mass-equivalent thermal energy.
Water: Capturing volumetric flow and totalised consumption to track cooling and process water.
Steam: Measuring mass flow rate (kg/h), temperature, and pressure to calculate thermal output and identify boiler inefficiencies.
Optimising Bandwidth via Report-by-Exception (RBE)
Energy monitoring systems often process vast quantities of data. Tracking voltage, current, and active power across a facility with dozens of large machines can easily generate thousands of updates per second. If all this data is pushed continuously, the local network and the cloud ingress will choke.
The Mechanism of Exception-Based Reporting
The MQTT protocol for industrial energy IoT relies on the Report-by-Exception (RBE) mechanism to optimise network utilisation. Under an RBE strategy, the edge gateway polls the local PLC registers at high speed (for example, every 50 or 100 milliseconds) to ensure transient anomalies are captured.
However, the gateway does not publish an MQTT message unless the value deviates from the last published value by more than a preconfigured engineering deadband. If the energy consumption of a boiler or fan remains stable, the gateway maintains silence, sending only periodic keep-alive heartbeats to prove it is online.
Quantifying Network Bandwidth Reductions
The efficiency gained through Report-by-Exception can be mathematically modelled. The data reduction ratio (Rdata) represents the percentage of network transmissions eliminated by moving from continuous polling to RBE:
R
Compressed Air: Monitoring standard volumetric flow (Nm³/h), system pressure, and dew point to calculate compressor specific power.
Oil: Tracking volumetric flow of heating or fuel oils.
By mapping these distinct data types from various PLC sources into a unified MQTT payload structure, the system translates fragmented raw data into organised utility streams.
Standardising Data with MQTT Sparkplug B (ISO/IEC 20237:2023)
While plain MQTT is highly efficient, its data-agnostic nature is a major disadvantage in complex industrial deployments. Plain MQTT does not enforce a specific payload format or topic structure. A publisher can send JSON, XML, or a raw hex string, leaving it up to the developer to write custom parsers for every single device.
This interoperability gap is solved by layering the MQTT Sparkplug B specification (ISO/IEC 20237:2023) over the transport protocol.
Solving the Inherent Payload Problem of Plain MQTT
Sparkplug B defines a standardised, structured framework for topic namespaces and payload schemas specifically for industrial telemetry. Under Sparkplug B, the topic namespace is strictly formatted as:
group_id represents the logical category, such as a specific factory floor or production site.
message_type dictates the function of the message (e.g., NBIRTH, NDEATH, DDATA).
edge_node_id identifies the physical gateway.
device_id represents the specific PLC or meter attached to the gateway.
This rigid hierarchy enables subscribing systems to automatically discover and map incoming data streams into a cohesive corporate asset model without requiring manual configuration.
Feature
Modbus TCP
OPC-UA (Client/Server)
MQTT Sparkplug B
Transport Protocol
TCP
TCP / HTTP
TCP
Network Architecture
Polling (Request-Response)
Polling (Request-Response)
Publish-Subscribe (Decoupled)
Payload Structure
Raw Register Bytes (No Schema)
Rich Information Model
Protocol Buffers (Binary Schema)
Bandwidth Efficiency
Low (Continuous Polling)
Medium (Heavy Session Headers)
High (Report-by-Exception)
State Awareness
None
Built-in (Session Keep-Alives)
Birth/Death Certificates (LWT)
Firewall Configuration
Open Inbound Ports Required
Open Inbound Ports Required
Outbound Port 8883 Only
Primary Use Case
Local Controller-to-Device
Local Machine-to-Machine
Cloud Telemetry and Enterprise IoT
Birth and Death Certificates: Maintaining Device State
One of the biggest concerns in industrial SCADA and energy monitoring is knowing whether the telemetry received is accurate and current. Plain MQTT lacks a built-in mechanism to determine if an edge node is truly online, apart from a simple ping.
Sparkplug B solves this by introducing state awareness through Birth and Death certificates. When an edge gateway connects to the broker, it publishes a Node Birth (NBIRTH) and Device Birth (DBIRTH) payload. This message advertises every metric, data type, and scale factor that the gateway will transmit.
If the edge gateway loses its connection (for instance, during a cellular network dropout), the MQTT broker immediately utilises the Last Will and Testament (LWT) mechanism to publish a Node Death (NDEATH) message. The subscribing cloud application is instantly notified that the data stream is offline, preventing stale measurements from skewing real-time carbon intensity and energy calculations.
How Protocol Buffers (Protobuf) Compress Telemetry
Plain MQTT deployments often utilise JSON because it is human-readable. However, JSON is text-heavy and consumes significant bandwidth. Sparkplug B mandates the use of Google Protocol Buffers (Protobuf) for payload serialisation.
Protobuf compiles structured data into a highly optimised binary format. In a Sparkplug B payload, metric names (like Compressor_2_Active_Power_kW) are sent only once in the birth certificate, alongside an integer alias. Subsequent data messages send only the integer alias and the raw value, packaged as a dense binary stream. This reduces payload size by 40 to 70 per cent compared to JSON, making high-speed energy streaming feasible over cellular connections.
data
=
1−
NpollNchange
Where:
Rdata is the data reduction ratio (expressed as a fraction between 0 and 1).
Nchange is the number of out-of-deadband value changes detected and published over a given timeframe.
Npoll is the total number of local poll cycles executed by the gateway over that same timeframe.
To illustrate, consider an electrical meter monitoring a base-load refrigeration compressor. The edge gateway polls the meter's active power register every 100 milliseconds. Over a 24-hour period, this results in:
Npoll=10 polls/sec×86,400 sec/day=864,000 polls
If the engineering deadband is set to ±2per cent of the compressor's nominal load, the compressor's power consumption only crosses this deadband boundary $8,640$ times throughout the day as load fluctuates slightly (Nchange=8,640).
Applying the formula:
Rdata=1−864,0008,640=1−0.01=0.99
This demonstrates a 99 per cent reduction in data packets sent over the WAN. Instead of streaming 864,000 individual frames, the gateway transmits only 8,640 messages.
Managing High-Frequency Metering Streams
While RBE dramatically reduces bandwidth, high-frequency analogue measurements can suffer from signal noise, which triggers rapid, micro-fluctuations around the deadband limit, a phenomenon known as 'thrashing'. To prevent thrashing from eroding the benefits of RBE, systems engineers deploy three technical strategies at the edge gateway:
Hysteresis Bands: Requiring the value to breach the deadband limit and remain beyond a secondary, tighter threshold for a minimum duration before a publish is triggered.
Analogue Smoothing Filters: Applying moving-average or low-pass digital filters to the raw PLC register values to eliminate high-frequency electrical noise before assessing the deadband.
Time-Based Throttle Limits: Enforcing a maximum publish rate (e.g., no more than once per second) for highly volatile parameters, ensuring that peak fluctuations are smoothed while maintaining network bandwidth limits.
Securing Energy Streams: TLS 1.3, X.509, and IEC 62443 Compliance
Connecting operational technology (OT) to cloud-based systems presents significant cybersecurity challenges. Manufacturing networks are historically isolated, meaning many legacy protocols like Modbus TCP do not include any encryption or authentication.
The Vulnerabilities of Industrial Control Networks
If a cloud platform attempts to access a local PLC using a traditional client-server architecture, it requires configuring port forwarding in the corporate firewall. This exposes ports such as 502 (Modbus TCP) or 4840 (OPC-UA) to the public internet. Port scanners and malicious actors can easily discover these open ports, presenting a direct vector for cyber attacks, ransomware, and process disruption.
One-Way Secure Push Architecture
The MQTT protocol eliminates this vulnerability through its outbound-only connection architecture.
The edge gateway acts as an MQTT client and initiates an outbound TCP connection through port 8883 to the cloud broker. The broker does not connect down to the gateway. Once the outbound TCP socket is established, data flows strictly from the client up to the broker. The plant's firewall blocks all inbound connection attempts. This 'invisible' posture prevents external entities from scanning or accessing the internal plant network.
Implementing TLS 1.3 and X.509 Certificates
To secure the outbound telemetry tunnel, all MQTT traffic must be encrypted using Transport Layer Security (TLS) version 1.3. TLS 1.3 provides major advantages over older standards (such as TLS 1.2), including a streamlined cryptographic handshake that reduces network latency and the elimination of obsolete, vulnerable cipher suites.
In addition to encryption, identity verification is strictly enforced using X.509 certificates:
Mutual Authentication (mTLS): The edge gateway validates the identity of the cloud broker using the broker's public certificate. Simultaneously, the broker requires the edge gateway to present a valid client-side X.509 certificate.
Certificate Authority (CA) Verification: Both certificates must be signed by a trusted, private enterprise CA. Any device attempting to connect without a valid, pre-authorised certificate is immediately disconnected at the network boundary.
Device-Specific Tokens: Gateways can be further isolated by mapping certificate common names (CN) to specific MQTT topic permissions, ensuring that a compromised gateway on one production line cannot publish to or subscribe to topics of another.
This architecture ensures compliance with IEC 62443-4-2:2019, the international cybersecurity standard for industrial automation and control system components. By utilising outbound-only connections, TLS 1.3 encryption, and X.509 client certificate authentication, the pipeline establishes a secure, read-only data flow that meets the requirements for Security Level 4 (SL4), isolating critical control loops from cyber threats.
Implementing Omni Vision for Real-Time Energy Consumption
For manufacturing and process plants seeking to transition from manual, spreadsheet-based tracking to automated energy intelligence, implementing these secure MQTT pipelines requires a structured, end-to-end framework. The Omni Vision Energy Intelligence Platform is designed to bridge this gap, integrating physical instrumentation, secure PLC connectivity, and advanced cloud-based AI analytics.
Technical Deployment Timeline and Architecture
The platform operates on a standardised 8 to 16-week turnkey deployment model, minimising engineering overhead for plant staff:
Weeks 1-4: Audit & Design: Engineers analyse existing PLC architectures, identifying Modbus addresses and OPC-UA nodes corresponding to utility meters.
Weeks 5-8: Non-Invasive Hardware Integration: Edge gateways and precision sensors are installed. Gateway communication is configured with zero-write access to ensure no interference with plant operations.
Weeks 9-12: Telemetry Calibration: MQTT Sparkplug B payloads are mapped and tested over secure, outbound-only TLS 1.3 connections.
Weeks 13-16: Cloud Activation: EPSA’s cloud-based AI analytics engine is activated, establishing historical baselines and beginning real-time anomaly detection.
Driving Operational Cost Reductions and ROI
Once the MQTT-enabled data flow is established, the platform runs continuous analytics to map energy consumption to physical output:
Granular Asset Mapping: Monitoring consumption at the facility, department, and individual equipment levels.
Production-Linked KPIs: Correlating energy variables with physical metrics (e.g., energy consumed per batch, cost per tonne of finished product).
24/7 AI Anomaly Detection: Identifying energy leaks (such as stuck-open steam valves, compressed air leaks, or short-cycling chillers) as they occur, enabling operators to implement corrective actions to prevent costly waste before it impacts utility bills.
This granular visibility enables targeted, operator-led interventions that consistently deliver 15 to 25 per cent energy cost reductions with a predictable, sub-12-month return on investment (ROI).
Audit-Ready Compliance and Net-Zero Roadmaps
In addition to driving financial savings, the precise telemetry captured via the MQTT protocol for industrial energy IoT serves as the foundation for corporate sustainability initiatives:
Scope 1 and 2 Emissions: The platform automates the calculation of Scope 1 (direct fuel combustion) and Scope 2 (purchased electricity) carbon emissions, eliminating the errors associated with manual utility bill extraction.
By utilising the MQTT protocol to bridge the operational technology floor with cloud-level AI intelligence, industrial facilities unlock the precise, secure, and low-latency data streams required for operators to optimise utility streams, manage peak demands, and execute verifiable decarbonisation strategies.
This article reflects the independent analysis and editorial opinion of EnerTherm Engineering. Product names, trademarks, and brands mentioned belong to their respective owners. EnerTherm Engineering is not affiliated with, endorsed by, or a licensee of any third-party software or product mentioned unless explicitly stated.
