MQTT and Sparkplug B for Industrial IoT: Topics, QoS, State Management and Architecture
On this page
MQTT is a lightweight publish/subscribe messaging protocol. It was designed for unreliable, low-bandwidth links (its origins were in oil pipeline telemetry) and has become the standard way to move data from industrial edge devices to IIoT platforms, historians and cloud services. Sparkplug B is a specification on top of MQTT that defines what industrial data looks like and how devices report their state.
This guide explains both, and how to design reliable architectures with them.
How MQTT works
| Concept | Explanation |
|---|---|
| Broker | Central server that receives all messages and forwards them to subscribers |
| Client | Any device or application that connects to the broker; it can publish, subscribe or both |
| Topic | Hierarchical string that labels a message, for example siteA/packaging/line1/filler/speed |
| Publish | A client sends a message to a topic |
| Subscribe | A client asks the broker for messages on topics, with wildcards + (one level) and # (all remaining levels) |
Publishers and subscribers do not know about each other; they only know the broker. This decoupling is MQTT’s main architectural benefit: new consumers can be added without changing the data sources.
Connections are initiated by clients to the broker, so field devices make outbound connections only. That fits industrial security practice: no inbound connections into the plant are needed when the broker sits in a DMZ or the cloud.
Versions and ports
- MQTT 3.1.1 (OASIS standard, also ISO/IEC 20922) is still widely deployed.
- MQTT 5.0 (OASIS, 2019) adds reason codes, session and message expiry, shared subscriptions, user properties, request/response patterns and topic aliases.
- Default ports: 1883 (unencrypted) and 8883 (TLS). WebSocket transports are also common.
Quality of service, retained messages and last will
| Feature | What it does | Industrial use |
|---|---|---|
| QoS 0 | At most once; no acknowledgement | High-rate telemetry where an occasional loss is acceptable |
| QoS 1 | At least once; duplicates possible | Most industrial data; consumers must tolerate duplicates |
| QoS 2 | Exactly once (four-step handshake) | Rarely needed; higher overhead |
| Retained message | Broker stores the last message on a topic and gives it to new subscribers | Current value or state available immediately |
| Last Will and Testament (LWT) | Broker publishes a predefined message if a client disconnects unexpectedly | Detecting that an edge device is offline |
| Keep alive | Client and broker check that the connection is alive | Detects half-open connections over cellular or VPN links |
| Persistent sessions | Broker keeps subscriptions and queued QoS 1/2 messages for a reconnecting client | Avoids missing messages during short outages |
Important: QoS applies to each hop (publisher → broker, broker → subscriber) separately. End-to-end reliability also depends on the clients’ own buffering, which is why store-and-forward at the edge is essential in industrial systems.
Why plain MQTT is not enough for industry
MQTT deliberately defines no payload format and no topic structure. Different vendors therefore publish JSON, CSV, binary or proprietary formats under any topic naming scheme. Consumers cannot know:
- What data type and units a value has
- Whether a value is current or stale
- Whether the device that published it is still online
- What tags a device will publish
Sparkplug B addresses exactly these problems.
Sparkplug B
Sparkplug is maintained by the Eclipse Foundation. Sparkplug 3.0 was published in 2022 and later adopted as an international standard (ISO/IEC 20237).
Topic namespace
spBv1.0/<group_id>/<message_type>/<edge_node_id>/[<device_id>]Message types
| Message | Meaning |
|---|---|
| NBIRTH / DBIRTH | Edge node or device comes online and publishes all its metrics with names, data types and current values |
| NDATA / DDATA | Changes only (report by exception), referencing metrics defined in the birth message |
| NDEATH / DDEATH | Edge node or device goes offline; NDEATH is registered as the MQTT Last Will so the broker sends it automatically |
| NCMD / DCMD | Commands to an edge node or device (for example write a value, request a rebirth) |
| STATE | Published by the primary host application (for example SCADA) so edge nodes know whether it is online |
What Sparkplug adds
- Defined payload (Protocol Buffers encoding) with metric names, data types, timestamps and quality.
- State awareness: consumers know when a device is online, and values from an offline device are marked stale.
- Report by exception with sequence numbers, so gaps can be detected and a rebirth requested.
- Auto-discovery: birth messages describe all metrics, so SCADA and other hosts can build tags automatically.
- Primary host awareness: edge nodes can buffer data while the primary host application is offline and send it when it returns.
Unified namespace
A unified namespace (UNS) is an architecture in which all plant systems publish their current data and events to a broker (or a set of connected brokers) in a consistent hierarchy, typically modelled on the ISA-95 equipment hierarchy:
enterprise/site/area/line/cell/<data>Applications (MES, historian, dashboards, analytics) subscribe to what they need instead of maintaining point-to-point interfaces.
Design considerations:
- Agree naming and data model governance before connecting many systems.
- Decide which data uses Sparkplug (strongly typed, stateful) and which uses plain JSON topics (for example contextual or transactional information).
- A UNS distributes current state and events. Transactions that need guaranteed, acknowledged processing (for example ERP postings) still need appropriate patterns. See MES Integration Guide.
Typical architecture
- Edge: PLCs and devices are read with native drivers or OPC UA by an edge gateway, which publishes via MQTT/Sparkplug. See OPC UA Explained.
- Site broker: in the site operations zone or DMZ, serving SCADA, historian and MES.
- Enterprise/cloud broker: bridged from site brokers for enterprise analytics.
- Consumers: SCADA, historians, MES, analytics and data platforms.
Security
- TLS on all connections (port 8883), with server certificate validation.
- Client authentication: client certificates or username/password; unique credentials per device.
- Authorisation (ACLs): each client may publish or subscribe only to its own topics. Commands (NCMD/DCMD) need particularly strict control.
- Network placement: brokers in a DMZ or cloud; connections initiated outward from the plant.
- Broker hardening and monitoring: disable anonymous access, monitor connections, rate-limit clients.
See ISA/IEC 62443.
Broker selection criteria
For an overview of broker and connectivity products, see Connectivity Software Compared.
| Criterion | Questions |
|---|---|
| Protocol support | MQTT 3.1.1 and 5.0? Sparkplug-aware features? WebSockets? |
| Scale | Number of connections, messages per second, message size |
| Availability | Clustering, failover, persistence, bridging between sites |
| Security | TLS, certificate authentication, fine-grained ACLs, integration with identity systems |
| Operations | Monitoring, logging, management UI and APIs |
| Deployment | On-premise, edge, container, managed cloud service |
| Licensing and support | Open source vs commercial, support availability |
Troubleshooting
| Symptom | Likely causes | Checks |
|---|---|---|
| Client cannot connect | Wrong port/TLS setting, certificate not trusted, credentials rejected | Broker logs; test with a known-good client; certificate chain |
| Frequent disconnects | Keep-alive too short for the link, duplicate client IDs (one client kicks the other off), network NAT timeouts | Client IDs must be unique; adjust keep-alive; broker logs |
| Data missing after outage | QoS 0, non-persistent session, no edge buffering | Use QoS 1, persistent sessions and store-and-forward |
| Stale values not detected | Plain MQTT without state handling | Use Sparkplug or LWT with retained state topics |
| Sparkplug host shows wrong or missing tags | Missed BIRTH, sequence gap | Trigger a rebirth; check sequence numbers and host configuration |
| Broker overloaded | Too many high-rate topics, large payloads, wildcard subscriptions on everything | Reduce rates, report by exception, targeted subscriptions |
Frequently asked questions
Is MQTT better than OPC UA?
They solve different problems. MQTT is an efficient, decoupled transport; OPC UA provides rich information models and secure client/server access. Many architectures use OPC UA to read from equipment and MQTT/Sparkplug to distribute data to many consumers.
What QoS should I use for industrial data?
QoS 1 is the usual choice: it guarantees delivery at least once with moderate overhead. Consumers must handle duplicates. QoS 0 is acceptable for high-rate, non-critical telemetry.
What is a Sparkplug death certificate?
It is the NDEATH message that an edge node registers as its MQTT Last Will. If the node disconnects unexpectedly, the broker publishes it, so every consumer immediately knows that the node’s data is no longer current.
Key takeaways
- MQTT is a lightweight publish/subscribe protocol with a broker, hierarchical topics, QoS levels, retained messages and last will.
- Sparkplug B adds a defined payload, birth/death state management, report by exception and auto-discovery.
- A unified namespace can reduce point-to-point integration but needs governance.
- Secure brokers with TLS, per-client authentication and strict ACLs.
Related tutorials
Before you apply this in a plant: this article is for education. Always check the current edition of the relevant standards, the manufacturer's documentation for your exact product and version, and your site's procedures. Safety-related work needs qualified personnel. See our editorial policy.