Networking
MQTT and Sparkplug: a shared contract for industrial data
MQTT carries messages but does not define a data model. Sparkplug fills that gap by standardizing topic names and payload structure.
What is the difference between MQTT and Sparkplug B?
Short answer
MQTT is a lightweight publish/subscribe transport that routes messages through a broker, with free-form topic names and payloads. Sparkplug B is a specification built on top of MQTT. It defines a topic namespace, a protobuf payload, and birth and death certificates that track node state. Plain MQTT defines no data model.
Transport versus data model
MQTT is a lightweight publish/subscribe protocol that routes messages through a broker. A client publishes to a topic, and every client subscribed to that topic receives the message. Topic names and payload format are left to the designer. One team might publish pump speed as JSON on 'pump/speed' while another uses a completely different scheme, and the broker does not reconcile the two.
Sparkplug B adds the missing rules. Topics follow the pattern spBv1.0/group/message type/edge node/device. Payloads are protobuf messages. When an edge node connects, it publishes a birth certificate (BIRTH) listing its metrics. When the connection drops, a death certificate (DEATH) is published through MQTT's last-will mechanism. Devices can also report by exception, sending only changed metrics.
Worked example: one edge node, three devices
Hypothetical example: one edge node monitors 3 devices, each with 20 metrics. In a plain MQTT design with one topic per metric, the count is 3 × 20 = 60 topics, and the team defines every name, payload and rate itself.
With Sparkplug B, each device sends one DBIRTH message that carries its metric names, data types and starting values. Later DDATA messages carry only the metrics that changed. A consumer can follow all devices with one wildcard subscription per message type, instead of managing 60 separate topics.
On the consumer side, a DDEATH or NDEATH message tells the application that the device or node is offline, so its values should be marked stale.
Common mistakes
The first mistake is calling any MQTT setup 'Sparkplug'. When topic names and payloads are free-form, each application speaks its own dialect and the others cannot read it.
The second mistake is skipping death certificates. If an edge node disconnects silently, consumers may keep treating the last values as current. The last-will setting and NDEATH handling must be tested, not assumed.
The third mistake is using retained messages carelessly. A retained message is delivered to new subscribers even after its source has gone away, so it can look live when the source is off. Decide deliberately which topics retain values.
Follow-up questions
Does Sparkplug B need a separate broker?
No. Sparkplug B runs on a standard MQTT broker. The requirement is that publishers and subscribers follow the Sparkplug topic layout, the payload structure and the birth and death rules.
Does Sparkplug B replace OPC UA?
Usually not, because the two work at different levels and for different purposes. Sparkplug B is often chosen for lightweight data flow from edge devices to a central system, while OPC UA suits information models with browsing and method calls. The choice should follow the data contract.
Sources
Example numbers are hypothetical, not measured field results.
Read the full guide.
Full library
DataOps
Prepare OPC UA data for AI
Turn a tag value into a usable observation with units, quality, timestamps and asset context.