MQTT Sparkplug has emerged as the industrial standard for achieving interoperability in manufacturing data systems. While many understand the basics of MQTT, Sparkplug's specific architectural patterns and operational behaviors remain unclear to many engineers. This comprehensive guide explains Sparkplug's network architecture, component interactions, and operational sequences that enable plug-and-play interoperability in industrial environments.

Understanding Sparkplug architecture is essential for developers building edge applications, SCADA integrations, and industrial data infrastructure that requires vendor-neutral interoperability.

‍

What is MQTT Sparkplug

MQTT Sparkplug is a specification that defines how to use MQTT in industrial applications to achieve interoperability between devices and applications from different vendors. While MQTT provides the messaging infrastructure, Sparkplug adds standardized:

• Topic namespace structure
• Payload encoding using Protocol Buffers
• State management mechanisms
• Birth and death certificates
• Command structures
• Metrics definitions with data types

This standardization eliminates the integration challenges that plague raw MQTT implementations where each vendor interprets the protocol differently.

‍

‍

Sparkplug Network Architecture

Sparkplug defines a specific network architecture with well-defined components and their roles:

‍

Edge of Network (EoN) Nodes

Edge of Network nodes sit at the periphery of the network, closest to industrial equipment. They:

• Gather data from physical devices (sensors, PLCs, machines)
• Normalize data into Sparkplug format
• Publish data to the MQTT broker
• Manage devices connected behind them
• Receive commands from host applications

EoN nodes can represent:

• Gateway devices aggregating multiple sensors
• PLCs with MQTT Sparkplug capability
• Edge computers running data collection software
• Industrial PCs interfacing with legacy equipment

‍

Devices

Devices are industrial equipment or sensors connected behind Edge of Network nodes. They:

• Generate process data (temperature, pressure, flow rates)
• Receive commands from host applications via the EoN node
• May or may not have direct network connectivity

Devices don't communicate directly with the MQTT broker—they communicate through their parent EoN node, which handles Sparkplug protocol details.

‍

MQTT Broker

The MQTT broker serves as the central message hub. It:

• Receives published messages from EoN nodes
• Routes messages to subscribed host applications
• Manages client connections and sessions
• Stores retained messages when required
• Handles Quality of Service guarantees

The broker doesn't interpret message content—it simply routes messages based on topic subscriptions.

‍

Primary Host Applications

Primary host applications are typically SCADA systems, historians, or analytics platforms. They:

• Subscribe to all Sparkplug messages from the broker
• Maintain awareness of all EoN nodes and devices
• Build hierarchical representations of the infrastructure
• Send commands to EoN nodes and devices
• Publish their own state for EoN nodes to monitor

Primary host applications have special responsibilities including monitoring the entire Sparkplug infrastructure and managing redundancy scenarios.

‍

Sparkplug Topic Namespace Structure

Sparkplug defines a strict topic namespace that ensures consistency:

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

spBv1.0: Version identifier (Sparkplug B version 1.0)

group_id: Logical grouping (organization, facility, department)

message_type: One of several defined types:

• NBIRTH: Node birth certificate
• NDEATH: Node death certificate
• DBIRTH: Device birth certificate
• DDEATH: Device death certificate
• NDATA: Node data
• DDATA: Device data
• NCMD: Node command
• DCMD: Device command
• STATE: Primary application state

edge_node_id: Unique identifier for the edge node

device_id: Unique identifier for the device (optional for node-level messages)

Example topics:

spBv1.0/Factory_A/NBIRTH/Press_Line_1/
spBv1.0/Factory_A/DDATA/Press_Line_1/Press_Station_1
spBv1.0/Factory_A/STATE/Primary_SCADA

‍

Primary Host Application Operational Behavior

Understanding the sequence of operations when a primary host application connects is crucial for implementing compliant applications.

‍

Connection Sequence

Step 1: Connect to MQTT Broker

The primary host sends an MQTT CONNECT message to establish a session with the broker. This includes authentication credentials and session parameters.

Step 2: Subscribe to Root Element

The host subscribes to the root namespace element to receive all Sparkplug messages:

spBv1.0/#

The # wildcard captures all message types, group IDs, edge nodes, and devices. This ensures the primary host receives complete visibility into the entire Sparkplug infrastructure.

Step 3: Subscribe to Own STATE Topic

The primary host subscribes to its own STATE topic:

spBv1.0/{group_id}/STATE/{host_app_id}

This allows the host to monitor its own published state and detect if another instance takes over in redundant configurations.

Step 4: Publish STATE Message (ONLINE)

The primary host publishes a STATE message indicating it's online:

Topic: spBv1.0/Factory_A/STATE/Primary_SCADA
Payload: { "state": "ONLINE", "timestamp": 1234567890 }

Edge nodes monitor this topic to know which primary host application is active. When the state is ONLINE, edge nodes know they can send data and expect to receive commands.

‍

Maintaining State

The primary host continuously publishes STATE messages at regular intervals to confirm it remains online. If edge nodes stop receiving STATE updates within a configured timeout period, they assume the primary host has failed.

‍

Graceful Shutdown

When shutting down gracefully, the primary host publishes a STATE message with "OFFLINE" before disconnecting. This informs edge nodes immediately rather than waiting for timeout detection.

‍

Edge of Network Node Operational Behavior

Edge nodes follow a specific sequence when connecting to the Sparkplug network.

‍

Connection Sequence

‍

Step 1: Connect to MQTT Broker

The edge node sends an MQTT CONNECT message, establishing a session with the broker. Importantly, this CONNECT message includes a Last Will and Testament (LWT) that the broker will publish if the edge node disconnects unexpectedly.

The LWT is configured as an NDEATH message:

Topic: spBv1.0/Factory_A/NDEATH/Press_Line_1/
Payload: { "timestamp": 1234567890 }

‍

Step 2: Subscribe to Commands

The edge node subscribes to command topics so it can receive instructions from the primary host:

spBv1.0/Factory_A/NCMD/Press_Line_1/#
spBv1.0/Factory_A/DCMD/Press_Line_1/#

NCMD receives commands directed at the node itself, while DCMD receives commands for devices behind the node.

‍

Step 3: Subscribe to Primary Host STATE

The edge node subscribes to the primary host's STATE topic:

spBv1.0/Factory_A/STATE/Primary_SCADA

This allows the edge node to know when the primary host is online, offline, or has changed (in redundant configurations).

‍

Step 4: Publish NBIRTH (Node Birth Certificate)

The edge node publishes its birth certificate containing all metrics it will publish:

Topic: spBv1.0/Factory_A/NBIRTH/Press_Line_1/
Payload: {
 "timestamp": 1234567890,
 "metrics": [
   {
     "name": "Node_Control/Rebirth",
     "datatype": "Boolean",
     "value": false
   },
   {
     "name": "Properties/Version",
     "datatype": "String",
     "value": "v1.2.3"
   }
 ]
}

The NBIRTH includes:

• All metrics the node will publish
• Data types for each metric
• Initial values
• Metadata and properties

‍

Step 5: Publish DBIRTH Messages (Device Birth Certificates)

For each device behind the edge node, publish a DBIRTH message:

Topic: spBv1.0/Factory_A/DBIRTH/Press_Line_1/Press_Station_1
Payload: {
 "timestamp": 1234567890,
 "metrics": [
   {
     "name": "Temperature",
     "datatype": "Float",
     "value": 25.3
   },
   {
     "name": "Pressure",
     "datatype": "Float",
     "value": 101.2
   },
   {
     "name": "Humidity",
     "datatype": "Float",
     "value": 68.5
   }
 ]
}

Each DBIRTH declares all metrics that specific device will publish.

‍

Report by Exception

After publishing birth certificates, the edge node operates in "report by exception" mode—only publishing data when values change rather than sending all data continuously.

When a temperature sensor reading changes from 25.3°C to 25.8°C:

Topic: spBv1.0/Factory_A/DDATA/Press_Line_1/Press_Station_1
Payload: {
 "timestamp": 1234567895,
 "metrics": [
   {
     "name": "Temperature",
     "value": 25.8
   }
 ]
}

Notice only the changed metric is included, reducing bandwidth consumption dramatically.

‍

Birth Certificates and Automatic Discovery

Birth certificates enable automatic discovery and configuration in SCADA systems.

‍

Building the Tree Hierarchy

When a primary host application like Ignition Gateway receives NBIRTH and DBIRTH messages, it automatically builds a hierarchical tree structure representing the infrastructure:

Factory_A
├── Press_Line_1 (Edge Node)
│   ├── Press_Station_1 (Device)
│   │   ├── Temperature
│   │   ├── Pressure
│   │   └── Humidity
│   └── Press_Station_2 (Device)
│       ├── Temperature
│       └── Force
└── Assembly_Line_1 (Edge Node)
   └── Robot_Arm_1 (Device)
       ├── Position_X
       ├── Position_Y
       └── Position_Z

SCADA engineers can browse this tree structure, drag metrics onto visualization canvases, and build HMI screens without manual configuration. The structure updates automatically as edge nodes and devices connect or disconnect.

‍

Data Types in Birth Messages

Birth messages include data type information, enabling SCADA systems to present appropriate input controls:

• Boolean: Checkbox or toggle
• Float/Double: Numeric input with decimals
• Integer: Numeric input without decimals
• String: Text input
• DateTime: Date/time picker

This eliminates guesswork about how to interpret and display data.

‍

Example Birth Message Payloads

Let's examine real birth message examples:

‍

Device Birth Certificate - Temperature Sensor

json

{
 "timestamp": 1234567890,
 "metrics": [
   {
     "name": "Outdoor_Temperature",
     "datatype": "Float",
     "value": 0.7
   },
   {
     "name": "Outdoor_Humidity",
     "datatype": "Float",
     "value": 72.3
   }
 ]
}

This birth certificate from a weather monitoring device declares it will publish temperature and humidity as floating-point values, with current values of 0.7°C and 72.3% respectively.

‍

Metric Properties

Metrics can include properties providing additional context:

json

{
 "name": "GPS_Location",
 "datatype": "Object",
 "value": {
   "latitude": 51.5074,
   "longitude": -0.1278
 },
 "properties": {
   "engineering_units": "degrees",
   "location_name": "London Office"
 }
}
```

Properties might include:
- Engineering units (°C, PSI, RPM)
- Physical location
- Calibration dates
- Serial numbers
- Manufacturer information

## Commands in Sparkplug

Commands enable host applications to control edge nodes and devices.

### Rebirth Command

The rebirth command instructs an edge node to republish its birth certificates:
```
Topic: spBv1.0/Factory_A/NCMD/Press_Line_1/
Payload: {
 "timestamp": 1234567900,
 "metrics": [
   {
     "name": "Node_Control/Rebirth",
     "value": true
   }
 ]
}

Use cases for rebirth:

• Primary host restarted and needs current structure
• Configuration changes require updated birth certificates
• Troubleshooting missing or stale data

‍

Custom Commands

Edge nodes can define custom commands specific to their functionality:

json

{
 "name": "Get_Current_MQTT_Server",
 "datatype": "String",
 "value": "broker1.factory.com"
}

This command requests which MQTT broker the edge node is currently connected to—useful in redundant broker configurations.

‍

Another example:

json

{
 "name": "Set_Sample_Rate",
 "datatype": "Integer",
 "value": 1000
}
```

This command instructs a device to change its sampling rate to 1000ms (1 second).

## Death Certificates and Connection Monitoring

Death certificates notify the infrastructure when components disconnect.

### NDEATH (Node Death)

Published automatically by the MQTT broker when an edge node disconnects unexpectedly (using the Last Will and Testament):
```
Topic: spBv1.0/Factory_A/NDEATH/Press_Line_1/
Payload: {
 "timestamp": 1234567890
}
```

When the primary host receives an NDEATH message, it updates its tree structure to show the edge node and all its devices as offline. SCADA displays can change colors or show alerts indicating communication loss.

### DDEATH (Device Death)

Published by the edge node when a device behind it disconnects:
```
Topic: spBv1.0/Factory_A/DDEATH/Press_Line_1/Press_Station_1
Payload: {
 "timestamp": 1234567890  
}
```

This allows granular tracking of which specific devices are offline versus the entire edge node being disconnected.

## Sparkplug Compliant vs. Sparkplug Aware Brokers

Understanding the distinction between compliant and aware brokers is important for architecture decisions.

### Sparkplug Compliant Brokers

A Sparkplug compliant broker is any MQTT broker that supports:

- Quality of Service levels 0, 1, and 2
- Last Will and Testament
- Retained messages

Any standard MQTT broker (Mosquitto, HiveMQ, EMQ X) is Sparkplug compliant and can route Sparkplug messages correctly.

### Sparkplug Aware Brokers

A Sparkplug aware broker provides additional features specifically supporting Sparkplug workflows:

**Birth/Death Certificate Retention**

Sparkplug aware brokers retain NBIRTH, DBIRTH, NDEATH, and DDEATH messages and make them available under a special topic namespace:
```
$sparkplug/certificates/#

When new primary host applications connect, they can query this namespace to immediately understand the current infrastructure state without waiting for edge nodes to republish birth certificates.

‍

Last Will and Testament Updates

Normally, the Last Will and Testament timestamp is set when a client first connects and never updates. If an edge node has been connected for 25 hours and then crashes, the NDEATH message contains a 25-hour-old timestamp.

Sparkplug aware brokers can update the LWT timestamp periodically, ensuring NDEATH messages contain accurate disconnection times.

‍

Benefits of Sparkplug Aware Brokers

While not required by the specification, Sparkplug aware brokers provide:

• Faster primary host application startup (immediate infrastructure view)
• Accurate death certificate timestamps for better troubleshooting
• Reduced network traffic (no need to request rebirths)

‍

Building Sparkplug Applications

When building Sparkplug applications—whether edge nodes or host applications—follow these best practices:

‍

For Edge Node Applications

1. Implement Complete Connection Sequence: Follow all steps in order—connect, subscribe to commands and STATE, publish NBIRTH, publish DBIRTH messages.

2. Include Rebirth Handling: Always implement the rebirth command so primary hosts can request updated birth certificates.

3. Report by Exception: Only publish data when values change to minimize network traffic.

4. Use Appropriate Data Types: Choose data types that accurately represent your metrics (Float for sensors, Integer for counters, Boolean for states).

5. Handle STATE Changes: Monitor primary host STATE and adjust behavior when primary host goes offline or changes.

‍

For Primary Host Applications

1. Subscribe to Root Element: Use spBv1.0/# to receive all messages.

2. Build and Maintain Tree Structure: Process birth certificates to build hierarchical views that update with death certificates.

3. Publish STATE Regularly: Send STATE messages at regular intervals so edge nodes know the primary host is active.

4. Handle Redundancy: If implementing redundant primary hosts, use STATE messages to coordinate which instance is active.

5. Implement Command Interface: Provide user interfaces for sending commands like rebirth or custom device commands.

‍

Reference the Sparkplug Specification

The complete Sparkplug specification is available from the Eclipse Foundation. When building Sparkplug applications, always reference the official specification for:

• Complete message format details
• All defined metric data types
• Topic namespace rules
• Quality of Service requirements
• Protocol Buffers encoding details

The specification ensures your implementation is compatible with all other Sparkplug compliant devices and applications.

‍

Summary

MQTT Sparkplug defines a comprehensive architecture for industrial data systems with well-specified component roles and operational behaviors. Primary host applications subscribe to all messages, publish their state, and build hierarchical views of the infrastructure. Edge of Network nodes gather device data, publish birth certificates declaring available metrics, and report changes by exception to minimize bandwidth.

Birth and death certificates enable automatic discovery and configuration, eliminating manual integration work. Commands allow host applications to control edge nodes and devices. Sparkplug aware brokers provide additional features like birth certificate retention and accurate death timestamps, though standard MQTT brokers work fine for most implementations.

Understanding these architectural patterns and operational sequences is essential for building interoperable industrial IoT systems that deliver the plug-and-play vision of Industry 4.0. By following Sparkplug's standardized approach, organizations achieve vendor-neutral data infrastructure that scales efficiently from pilot projects to enterprise-wide deployments.

‍