MQTT and Sparkplug B for Industrial Plants: How Plant Data Reaches the Cloud Without Breaking the PLC

The problem MQTT solves

OPC UA is a client asking a server for data. That works inside the plant. Across a WAN or to a cloud it means a hole in the firewall towards the PLC, a connection per consumer, and polling traffic. MQTT turns it around: devices publish small messages to a broker, and any number of applications subscribe to the topics they care about. The PLC side only ever makes an outbound connection, which the firewall team can live with.

MQTT in five ideas

1. Broker. The server everything connects to. Mosquitto (open source), HiveMQ, EMQX, AWS IoT Core, Azure IoT Hub.
2. Topic. A path string such as plant1/line2/filler/temperature. Subscribers use wildcards: plant1/line2/# for everything under the line.
3. Publish and subscribe. Publishers never know who reads; subscribers never know who wrote. That decoupling is the whole point.
4. QoS. 0 at most once, 1 at least once, 2 exactly once. Plants use 1.
5. Retained messages and last will. The broker can keep the last value for new subscribers and announce when a client drops.

MQTT is tiny (a two-byte header), works over TLS, and runs on anything from an edge PC to a microcontroller.

Why plain MQTT is not enough

MQTT says nothing about what is in the message or how topics are named. Every vendor invented its own JSON, and a SCADA could not tell a temperature from a timestamp. Sparkplug B (from the Eclipse Foundation) fixes this with three rules:

• A topic namespace: spBv1.0/GroupID/MessageType/EdgeNodeID/DeviceID.
• A payload format: Protocol Buffers with metrics that carry name, data type, timestamp, value and metadata such as units.
• State management: an edge node publishes a BIRTH message listing every metric when it connects, DATA messages with only changed metrics afterwards, and the broker publishes its DEATH if it disconnects. Subscribers therefore always know the full tag list and whether the data is live.

The architecture that works

• Edge: a gateway or the PLC itself publishes Sparkplug. Ignition Edge with MQTT Transmission, Opto 22 groov EPIC, Moxa and Advantech gateways, Node-RED with the Sparkplug node, Beckhoff and Siemens MQTT libraries.
• Broker: on site for resilience, with a bridge to a cloud broker.
• Consumers: SCADA (Ignition's MQTT Engine builds tags from BIRTH messages automatically), historian, cloud analytics, dashboards.

Report by exception, from the edge, over one outbound connection, is what lets a plant with 20,000 tags run on a 4G link.

Adding MQTT to an existing PLC

• Siemens S7-1500: the LMQTT library from Siemens, or a gateway reading OPC UA and publishing Sparkplug.
• Rockwell: ControlLogix has no native MQTT; use Ignition Edge, a Red Lion or a Moxa gateway, or the EtherNet/IP to MQTT module.
• Any PLC: Node-RED on an industrial PC reading Modbus, S7 or OPC UA and publishing Sparkplug, which the Node-RED IIoT course builds step by step.

Security

TLS on every connection, per-client credentials or certificates, and topic-level access control on the broker. The broker sits in the industrial DMZ described in SCADA cybersecurity basics; the PLC never listens on an inbound port.

Frequently asked questions

Does MQTT replace OPC UA? No. OPC UA is the plant-floor interface with a rich model; MQTT is the transport to everything above it. Most architectures use both, and OPC UA over MQTT pub-sub exists for the future.

Can MQTT control a machine? It can carry commands, but it has no real-time guarantee. Use it for monitoring and setpoints, not for interlocks.

Which broker for a first project? Mosquitto on the edge PC, with Ignition or Node-RED subscribing.