MQTT and Sparkplug for Industrial IoT

MQTT (Message Queuing Telemetry Transport) has become the protocol of choice for Industrial IoT (IIoT) and edge-to-cloud communication, driven by its lightweight footprint, publish-subscribe architecture, and reliable delivery guarantees. The Sparkplug specification, maintained by the Eclipse Foundation, extends MQTT with industrial-specific semantics — standardized topic namespaces, rich data models using Protocol Buffers, and state management through birth/death certificates. This article provides a comprehensive technical analysis of MQTT and Sparkplug for industrial applications, covering architecture, QoS levels, topic design, security, broker HA configurations, latest protocol developments including MQTT over QUIC (2025), and a comparison with OPC UA Pub/Sub.

MQTT Architecture — Publish-Subscribe Model

Unlike traditional point-to-point protocols (Modbus TCP, OPC DA) where each client must know the address of every data source, MQTT uses a centralized broker that decouples publishers from subscribers:

  +-------------+     PUBLISH: "temperature/zone1 = 85.3 C"  +-------------+
  |  Sensor     | ------------------------------------------> |   MQTT      |
  |  Publisher  |                                              |   Broker    |
  +-------------+                                              |             |
                                                               | ---+---+---|
  +-------------+     SUBSCRIBE: "temperature/zone1"           |    |   |   |
  |  SCADA      | <------------------------------------------  |    |   |   |
  |  Subscriber |                                              |    |   |   |
  +-------------+                                              +----+---+---+
                                                                    |   |
            +-------------------------------------------------------+   |
            |               SUBSCRIBE: "temperature/#"                  |
            | <---------------------------------------------------------|
            |
            v
  +-----------------+
  |  Cloud Platform  |
  |  (AWS/Azure/GCP) |
  +-----------------+

Key architectural benefits for industrial use:

• Decoupling — Publishers and subscribers have no knowledge of each other. Adding new data sources or consumers requires no changes to existing systems.
• Scalability — A single MQTT broker can handle 100,000+ concurrent connections and millions of messages per second. Modern brokers (HiveMQ, EMQX, VerneMQ) support horizontal clustering.
• Bandwidth Efficiency — MQTT minimum packet header is only 2 bytes. For bandwidth-constrained environments (cellular, satellite, LoRaWAN backhaul), this is a critical advantage over HTTP-based protocols.
• Store-and-Forward — Persistent sessions and retained messages ensure data is not lost when subscribers are offline. The broker queues pending messages and delivers them on reconnection.
• Last Will and Testament (LWT) — When a publisher disconnects unexpectedly, the broker publishes a pre-configured LWT message. Subscribers instantly know that the remote device is offline, without waiting for a polling timeout.

Quality of Service (QoS) Levels

MQTT defines three Quality of Service levels that control the delivery guarantee for each message. Choosing the right QoS for each data stream balances reliability against network overhead:

QoS Selection Guidelines for IIoT

• Fast-Change Analog Data (temperature, vibration, speed): QoS 0. The temporal value of the data is higher than absolute delivery guarantee.
• Status and State Data (running/stopped, valve open/closed): QoS 1. Every state transition matters. A duplicate status update is harmless; a missed transition can cause incorrect system state.
• Command and Alarm Data (start motor, acknowledge alarm, setpoint change): QoS 2. Commands must execute exactly once. A duplicate "start motor" command or a missed command both have safety and operational consequences.
• Configuration Data (device parameters, calibration values): QoS 2. Configuration integrity is critical.

Topic Hierarchies and Design Patterns

MQTT topics are UTF-8 strings organized in a hierarchical slash-separated namespace. Topic design is one of the most consequential architectural decisions in an MQTT deployment:

Topic Wildcards

• + (single-level) — Matches exactly one topic level. Example: factory/+/temperature matches both factory/zone1/temperature and factory/zone2/temperature.
• # (multi-level) — Matches any number of remaining levels. Must be the last character in the topic filter.

Industrial Topic Design Pattern

  {site}/{area}/{line}/{equipment}/{measurement_type}/{attribute}

  Examples:
  izmir/assembly/line3/robot01/temperature/pv
  izmir/assembly/line3/robot01/status/mode
  ankara/power/boilerB/pressure/drum_pressure

Design principles:

• Left-to-Right Specificity — Broad categories on the left, specific attributes on the right. This maximizes wildcard subscription benefits.
• Stable Hierarchy — Avoid embedding variable information (timestamps, sequence numbers) in topic levels. Use the payload for variable data.
• Separation of Data Types — Use topic levels to distinguish data categories (measurement vs. status vs. command vs. configuration). This enables fine-grained security ACLs at the broker level.
• Include Site Identifier — For multi-site deployments, always include a site/plant identifier as the first topic level.

Sparkplug B — Industrial Payload Standard

Standard MQTT has no prescribed topic structure or payload format. The Sparkplug B specification (part of the Eclipse Tahu project) fills this gap by defining a standardized topic namespace and payload format specifically for industrial automation:

Sparkplug Topic Namespace

  spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}

Message Types

• NBIRTH / DBIRTH — Birth certificates. Published when an edge node or device connects. Contains the full metric list.
• NDEATH / DDEATH — Death certificates. Published via MQTT LWT when an edge node disconnects unexpectedly.
• NDATA / DDATA — Data messages containing current metric values.
• NCMD / DCMD — Command messages from SCADA/HMI to control edge nodes or devices.
• STATE — Primary/standby state of MQTT brokers in a high-availability cluster.

Payload Format (Protobuf)

Sparkplug uses Google Protocol Buffers (protobuf) for efficient binary serialization of metric data. The payload structure includes:

• Timestamp — 64-bit timestamp (milliseconds since Unix epoch) for when the data was sampled.
• Metrics — Array of metric objects. Each metric has: name (string identifier), alias (optional integer alias for reduced payload size), timestamp (per-metric timestamp), dataType (protobuf enum: Int32, Int64, Float, Double, Boolean, String, Bytes, Dataset, Template), value (the actual data value), properties (optional metadata: engineering units, quality code, limits).
• Seq — Sequence number (monotonically increasing). Subscribers detect missed messages by tracking gaps in sequence numbers.

MQTT 5.0 Features for Industrial Use

MQTT 5.0 (released 2019, widely deployed from 2022 onward) introduced several features particularly valuable for industrial deployments:

• Session Expiry Interval — Configurable session persistence. An edge device can request the broker to keep its session alive for a specified period (e.g., 24 hours) after disconnection.
• Message Expiry Interval — Time-to-live (TTL) for individual messages. A temperature reading that is 60 seconds old is likely irrelevant.
• User Properties — Custom key-value metadata in the MQTT header. Industrial applications can attach context: quality code ("GOOD", "UNCERTAIN", "BAD"), originating PLC timestamp, or security classification.
• Reason Codes — More informative acknowledgment codes. Instead of binary success/failure, MQTT 5.0 provides specific reasons: "No matching subscribers," "Topic alias invalid," etc.
• Topic Aliases — Map long topic strings to short numeric IDs (2 bytes). For devices publishing thousands of messages per second, this reduces network overhead by 50+ bytes per message.
• Flow Control — Broker and client negotiate receive maximum (maximum number of unacknowledged QoS 1/2 messages), preventing slow subscribers from being overwhelmed.

MQTT over QUIC (2025)

The most significant recent evolution of MQTT is the adoption of QUIC (RFC 9000) as an alternative transport protocol. QUIC, which powers HTTP/3, provides several advantages over TCP for industrial MQTT:

• Connection Establishment — QUIC establishes connections in a single round trip (0-RTT for resumed connections) vs. TCP three-way handshake + TLS 1.3 negotiation (2–3 round trips). For devices on high-latency cellular or satellite links, this translates to dramatically faster reconnection times.
• Multiplexing Without Head-of-Line Blocking — TCP multiplexes multiple MQTT streams over one connection, but a lost packet blocks all streams until retransmission. QUIC provides independent stream multiplexing.
• Connection Migration — A MQTT connection over QUIC survives IP address changes. An edge device moving between cellular towers maintains its MQTT session without reconnection — transformative for mobile industrial assets.
• Built-in Encryption — QUIC mandates TLS 1.3 encryption as part of the transport layer. There is no "plaintext QUIC" — eliminating the common security mistake of deploying plaintext MQTT.
• Deployment Status (2025–2026) — EMQX 5.x and HiveMQ 4.x added QUIC support in 2024. VerneMQ and Mosquitto are in development. MQTT over QUIC is standardized as an OASIS Technical Note (MQTT-TN-001).

Broker High-Availability Configurations

For industrial deployments where downtime affects production, MQTT broker high availability is essential:

1. Active/Standby (Cold/Hot Failover)

One broker serves all clients; a standby broker synchronizes its state. On failure, clients reconnect to the standby. Implementation options include DNS-based failover, Virtual IP (VIP) with keepalived, or shared database backend (PostgreSQL, Redis).

2. Active/Active Cluster (N-Node)

Multiple brokers form a cluster where each broker is a full member. Clients connect to any broker, and the cluster distributes messages to all connected subscribers:

• Full Mesh (EMQX, VerneMQ) — Each broker connects to every other broker using distributed message routing (e.g., Plumtree for VerneMQ).
• Raft Consensus (HiveMQ, NanoMQ) — Uses the Raft consensus algorithm. Preferred where split-brain scenarios must be avoided.
• Mnesia/ETCD Backend (EMQX) — Uses Mnesia (Erlang) or ETCD for distributed metadata. Scales to hundreds of broker nodes.

The Sparkplug specification includes a STATE message that SCADA clients use to determine which broker is currently primary, enabling them to follow the active broker without manual reconfiguration.

Security: TLS, Authentication, and ACLs

MQTT security in industrial environments must address three dimensions: transport encryption, client authentication, and access authorization.

Transport Layer Security (TLS)

Always use MQTT over TLS (port 8883). Never deploy plaintext MQTT (port 1883) in production.

• TLS 1.3 Minimum — Use TLS 1.3 whenever possible.
• Certificate Validation — Both broker and clients should validate each other certificates. Use a private CA hierarchy: Root CA to Intermediate CA (per site) to Device Certificate (per edge node).
• Cipher Suites — Prefer TLS_AES_128_GCM_SHA256 for constrained devices and TLS_AES_256_GCM_SHA384 for server-side connections.
• Certificate Revocation — Implement OCSP stapling or CRL distribution points. For constrained devices, consider short-lived certificates (valid for 30 days) that are automatically renewed.

Authentication Methods

Access Control Lists (ACLs)

Broker-level topic authorization enforces least-privilege access:

MQTT and Sparkplug vs. OPC UA Pub/Sub

When to Use Each

• Choose MQTT + Sparkplug when: Collecting telemetry from remote or mobile assets over cellular or satellite links; deploying edge gateways to thousands of sensors; building cloud-connected IIoT solutions; needing the lightest possible protocol footprint; requiring store-and-forward for intermittent connectivity.
• Choose OPC UA Pub/Sub when: Needing deterministic real-time communication on the plant floor; requiring the rich semantic information model for vendor-neutral data exchange; building complex multi-vendor systems; needing application-layer security independent of transport.

In many practical architectures, both protocols coexist: OPC UA handles plant-floor real-time control while MQTT/Sparkplug provides edge-to-cloud telemetry. ASP OTOMASYON regularly designs hybrid architectures leveraging the strengths of both.

ASP OTOMASYON A.Ş. and its subsidiaries OPCTurkey and ASP Dijital provide end-to-end industrial engineering solutions for process automation, data operations and AI.

---

References & Further Reading

1. OASIS MQTT — Message Queuing Telemetry Transport Standard v5.0 — Official OASIS standard for MQTT, covering QoS levels, topic wildcards, session management, and MQTT 5.0 features including message expiry and user properties.
2. Eclipse Tahu — Sparkplug B Specification for Industrial IoT — Official Eclipse Foundation Sparkplug B specification defining the standard topic namespace, Protobuf payload format, birth/death certificates, and state management for IIoT deployments.
3. Cirrus Link Solutions — MQTT and Sparkplug for Industrial Automation — Official Cirrus Link documentation on MQTT/Sparkplug architecture patterns, including edge gateway configuration, topic design, and cloud platform integration.
4. QUIC Transport Protocol — RFC 9000 — Official IETF specification for QUIC, the emerging MQTT transport protocol providing 0-RTT connection establishment, connection migration, and built-in TLS 1.3 encryption.
5. HiveMQ — Enterprise MQTT Broker for Industrial IoT — Official HiveMQ documentation on MQTT broker high-availability clustering, security configuration, and Sparkplug B support for industrial deployments.