What is the difference between MQTT and Modbus for SCADA?

Modbus is a polling-based protocol where a master requests data from each device sequentially. MQTT is a publish-subscribe protocol where devices push data to a broker when values change. Modbus operates at the field device level over serial or Ethernet. MQTT typically operates at the edge-to-cloud level. Most architectures use both: Modbus between PLCs/RTUs and edge gateways, and MQTT from gateways to SCADA/cloud.

What is Sparkplug B and why does it matter?

Sparkplug B is a specification that standardizes MQTT for industrial SCADA applications. It defines topic naming conventions, payload encoding using Protocol Buffers, birth/death certificates for device state awareness, and report-by-exception data publishing. Without Sparkplug B, every MQTT industrial implementation uses custom topics and payloads, preventing interoperability between vendors.

Which MQTT QoS level should I use for industrial data?

QoS 1 (at least once delivery) is the most common choice for industrial sensor data, providing guaranteed delivery with acceptable overhead. Use QoS 0 for high-frequency, non-critical data like vibration waveforms. Use QoS 2 for critical events like alarms and control commands where duplicate delivery could cause issues. Sparkplug B typically uses QoS 0 for data and QoS 1 for birth/death certificates.

MQTT for Industrial Automation

MQTT Protocol Fundamentals

MQTT is a publish-subscribe messaging protocol designed for constrained devices and unreliable networks. Originally developed by IBM in 1999 for satellite pipeline monitoring, MQTT has become the de facto standard for IoT communication. Unlike traditional SCADA polling (request-response), MQTT uses an event-driven, publish-subscribe model where devices publish data to topics on a central broker, and subscribers receive data from topics they have subscribed to. This decoupled architecture reduces bandwidth usage, simplifies network configuration, and scales efficiently to thousands of devices.

MQTT Architecture

The Broker

The MQTT broker is the central message hub that receives publications from devices and distributes them to subscribers. Popular industrial-grade brokers include HiveMQ, EMQX, Mosquitto, and the Ignition MQTT module from Cirrus Link. The broker handles authentication, authorization, message routing, quality of service enforcement, and retained message storage. A single broker can manage millions of concurrent connections and route thousands of messages per second.

Topics and Topic Structure

MQTT topics are hierarchical UTF-8 strings using forward slash delimiters. A well-designed topic hierarchy for industrial applications might follow the pattern: site/area/device/measurement, for example plant1/compressor_room/compressor_3/discharge_pressure. Wildcards enable flexible subscriptions: the single-level wildcard (+) matches one level, and the multi-level wildcard (#) matches all remaining levels. A SCADA system subscribing to plant1/# receives all data from the entire plant.

Quality of Service (QoS) Levels

QoS 0 (At most once): Fire and forget. No delivery guarantee. Lowest overhead, suitable for high-frequency sensor data where occasional loss is acceptable
QoS 1 (At least once): Guaranteed delivery with possible duplicates. The broker acknowledges receipt. Most common for industrial data where delivery matters but duplicates can be handled
QoS 2 (Exactly once): Guaranteed single delivery using a four-step handshake. Highest overhead but ensures no duplicates. Used for critical events like alarms and commands

Sparkplug B for SCADA

The Sparkplug B specification, developed by Cirrus Link and now an Eclipse Foundation standard, addresses MQTT's lack of standardization for industrial applications. Raw MQTT defines no payload format or topic naming convention, meaning every implementation is custom. Sparkplug B standardizes these elements, enabling plug-and-play interoperability between devices, edge nodes, and SCADA/MES applications from different vendors.

Sparkplug B Key Features

Standardized topic namespace: spBv1.0/group_id/message_type/edge_node_id/device_id provides consistent, predictable topic structure
Birth and death certificates: Devices publish NBIRTH (node birth) messages on connection and the broker publishes NDEATH messages when devices disconnect, giving subscribers real-time awareness of device availability
Report by exception: Devices publish only changed values (NDATA/DDATA messages), reducing bandwidth by 80-95% compared to periodic polling of all points
Protobuf payload encoding: Google Protocol Buffers provide efficient binary serialization, reducing payload size by 50-80% compared to JSON
Metric types: Supports Int8 through Int64, Float, Double, Boolean, String, DateTime, and DataSet types matching industrial data requirements
State awareness: The SCADA host publishes its STATE topic so edge nodes know whether the host application is online and can store-and-forward data during outages

MQTT vs Traditional SCADA Protocols

Traditional SCADA protocols like Modbus and DNP3 use polling: the master periodically requests data from each device. This approach is bandwidth-inefficient because every poll returns all values whether they changed or not, and latency equals the poll cycle time divided by the number of devices. MQTT's publish-subscribe model delivers data immediately when values change, providing lower latency for events while consuming less bandwidth for stable values. However, MQTT does not replace Modbus or DNP3 at the field device level. Instead, edge gateways translate between field protocols and MQTT for northbound communication to SCADA, historians, and cloud platforms.

Security

MQTT supports TLS/SSL encryption for transport security, username/password authentication, and client certificate authentication. The broker enforces topic-level access control lists (ACLs) that restrict which clients can publish or subscribe to specific topics. For industrial deployments, always enable TLS 1.2 or 1.3, use certificate-based mutual authentication (mTLS), and configure ACLs to prevent devices from subscribing to topics outside their scope. Sparkplug B's standardized topic namespace simplifies ACL configuration because the topic structure is predictable.

Edge Gateway Architecture

In most industrial MQTT deployments, edge gateways bridge field devices to the MQTT broker. An edge gateway connects to field devices via serial (Modbus RTU), Ethernet (Modbus TCP, Ethernet/IP, OPC UA), or I/O and translates the data into MQTT publications. Gateways from vendors like Opto 22 (groov EPIC), Inductive Automation (Ignition Edge), and Cirrus Link provide built-in Sparkplug B support. The edge gateway also provides store-and-forward capability, buffering data locally during network outages and publishing the backlog when connectivity is restored.

Cloud Integration

MQTT's lightweight protocol makes it ideal for connecting industrial data to cloud platforms. AWS IoT Core, Azure IoT Hub, Google Cloud IoT, and other cloud services provide managed MQTT brokers with built-in integration to cloud analytics, storage, and machine learning services. Sparkplug B-aware cloud connectors automatically decode the standardized payloads and map industrial data to cloud data models. NFM Consulting implements MQTT-based IIoT architectures that connect field operations to cloud analytics while maintaining on-premises SCADA control for operational technology.