MQTT Sparkplug Data Simulation with IoT Simulator

MQTT Sparkplug provides an open and freely available specification for how Edge of Network (EoN) gateways or native MQTT enabled end devices and MQTT Applications communicate bi-directionally within an MQTT Infrastructure. One of the unique aspects of MQTT protocol is that it was originally designed for real time SCADA systems to help reduce data latency over bandwidth limited and often unreliable network infrastructure. Similarly the intent of the Sparkplug specification is to take full advantage of MQTT’s native Continuous Session Awareness capability as it applies to real time SCADA/IIoT solutions.

This article helps you to simulate the Sparkplug B encoding in IoT Simulator. It is crucial to learn about the MQTT Sparkplug Topic Namespace Elements and Sparkplug MQTT Message Types for simulating the data.

Sparkplug MQTT Topics and Messages

Sparkplug Topic Namespace Elements:

All Clients which use the Sparkplug spec will use this default UTF-8 Format Topic namespace.

• namespace: It is the root element that will define both the structure of the remaining namespace elements as well as the encoding used for the associated payload data. Format for namespace is UTF-8 string constant should be used. Similarly the current Sparkplug specification defines two namespaces:
• Sparkplug payload definition A
• namespace element should be “spAv1.0”
• Sparkplug payload definition B
• namespace element should be “spBv1.0”
• group_id: This provides unique logical group ID of MQTT EoN nodes. For group_id the format should be UTF-8 alphanumeric string, except for the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign). Examples of where the [group_id] might be used include Cement industry where MQTT EoN nodes on different department have the different [group_id].
• message_type Element: It provide the indication as to, how to handle the MQTT payload of the message. The following message_type elements are defined for the Sparkplug Topic Namespace:
• NBIRTH – Birth certificate for MQTT EoN nodes.
• NDEATH – Death certificate for MQTT EoN nodes.
• DBIRTH – Birth certificate for Devices.
• DDEATH – Death certificate for Devices.
• NDATA – Node data message.
• DDATA – Device data message.
• NCMD – Node command message.
• DCMD – Device command message.
• STATE – Critical application state message.
• edge_node_id: Unquie identification for the MQTT EoN nodes within the infrastructure. For edge_node_id the format should be UTF-8 alphanumeric string, except for the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign). The edge_node_id travels with every message published, so it should be as short as possible
• device_id: Unquie ID which used to identify the device attached to the MQTT EoN node. device_id is an optional element since some messages will be either originating or destined to the edge_node_id, in that place device_id would not be required. The format of the device_id is a valid UTF-8 alphanumeric String except for the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign). The device_id travels with every message published, so it should be as short as possible.

Simulate Sparkplug MQTT Device & Network

• Download MQTT Simulator and it is a simulation tool which help users to test and develop the MQTT/IoT Applications. For installation and setup of Bevywise IoT Simulator, please refer our help doc and video tutorial.
• After starting the Simulator, create a new MQTT network.
• In new network, create three MQTT EoN nodes by via MQTT Device creation : spBv1.0, Node2, Node3.

Sparkplug MQTT Message Types

Sparkplug defines the Topic Namespace for set of MQTT messages that are used to manage connection state as well as bidirectional metric information exchange that would apply to many typical real-time SCADA/IIoT, monitoring, and data collection system use cases. The defined message types include:

• NBIRTH – Birth certificate for MQTT EoN nodes.
• NDEATH – Death certificate for MQTT EoN nodes.
• DBIRTH – Birth certificate for Devices.
• DDEATH – Death certificate for Devices.
• NDATA – Node data message.
• DDATA – Device data message.
• NCMD – Node command message.
• DCMD – Device command message.
• STATE – Critical application state message.

Creating Sparkplug MQTT Message types in IoT Simulator

MQTT EoN NBIRTH and NDeath Certificate: The first MQTT message that an EoN node MUST publish upon the successful establishment of an MQTT Session is an EoN BIRTH Certificate.

Creating NBIRTH: [namespace/group_id/NBIRTH/edge_node_id]

• Click spBv1.0 and
• Create a MQTT event with “Whole day” configuration with every 5 sec time interval.
• In that give the topic namespace as

• Select QoS as 1 and retain as 1
• Give message as “NBIRTH” and save it

• Now DDEATH will published to subscriber once they subscribe the DBIRTH topic namespace based on the DDATA.

SCADA/IIoT Host Birth and Death Certificates

• The SCADA/IIoT Host Node is any MQTT Client application that subscribes to and publishes messages.
• In an infrastructure, mulitple MQTT Servers provide redundancy and scalability, for that MQTT EoN nodes need to be aware of the “state” of the primary SCADA/IIoT Host application(s).
• The “state” can be acheived by the unique set of Birth/Death Certificates that the SCADA/IIoT Host MQTT Client MUST publish when a new MQTT session is established.
• Topic namespace for SCADA/IIOT Host : STATE/scada_host_id
• It uses an aspect of the MQTT transport called a “RETAINED” publish to maintain the current state of the Primary Host MQTT Client session state to all available MQTT Servers.
• The format of the scada_host_id can be valid String with the exception of the reserved characters of ‘+’ (plus), ‘/’ (forward slash), and ‘#’ (number sign).

• Set QoS to “1” and Retain to “1”
• Select message type as JSON and click + button.
• In that add NBIRTH metric like:
• ONLINE_STATE and ONLINE TIME.
• Give the Key as ONLINE_STATE, select “constant”, give value as TRUE and click ADD
• Next click + button and
• Give Key as ONLINE_TIME, select “System variable” and select “$Current_time from list
• next click ADD and save the JSON.
• Once the DBIRTH occurred, publish the DCMD by clicking the action icon
• on the left side, now the NCMD will send commands to connected EoN nodes.
• Next the subscribe the DCMD topic in SCADA/IIOT to get the Update metric from spBv1.0.
• These are the Sparkplug set of MQTT Message Types that are used to manage connection state. Next connect the Bevywise IoT Simulator to built-in MQTT Broker or connect to any other MQTTBroker to start the Spatkplug Simulation. Likewise create Sparkplug message type for other Nodes.

Specifications of MQTT Sparkplug

Currently there are two Sparkplug defined encoding schemes that this specification supports.

• Firstly the Sparkplug A encoding scheme based on the very popular Kura open source Google Protocol Buffer definition.
• Secondly the Sparkplug B encoding scheme that provides a richer data model developed with the feedback of many system integrators and end user customers using MQTT.

With the rich data model and standardized messaging of Sparkplug B in place, organizations can now think beyond individual nodes and devices. To truly leverage this real-time data across an entire plant or enterprise, the Unified Namespace (UNS) provides a structured and centralized way to organize, share, and consume all operational data seamlessly.

Unified Namespace (UNS) Integration with MQTT Sparkplug

To extend the Sparkplug MQTT simulation and align with modern IIoT and Industry 4.0 architectures, the Unified Namespace (UNS) serves as a centralized framework for managing and exchanging data.

The UNS acts as the single, centralized data backbone of an enterprise, bringing together all real-time and historical information from the edge to the cloud under a unified, hierarchical structure.

What is Unified Namespace (UNS)?

A Unified Namespace is an event-driven data architecture where all plant-floor systems, equipment, and enterprise applications communicate through a common MQTT broker infrastructure.

It represents the current state of the business in real time, making every data point available and consumable by any system or application that subscribes to it.

Role of MQTT Sparkplug in UNS

The MQTT Sparkplug B specification naturally fits as the messaging and data definition layer for UNS.

While UNS defines how data is organized, Sparkplug defines how data is communicated — ensuring reliable, state-aware, and structured messaging between all IIoT components.

By combining UNS and Sparkplug B:

• All nodes, devices, and applications share a common topic and payload structure.
• Real-time context is maintained through Birth/Death and Data messages.
• Systems can auto-discover metrics, properties, and state without custom integration.
• Enterprises can scale horizontally across multiple plants and edge networks.

Typical UNS Topic Hierarchy with Sparkplug B

A well-designed UNS structure often mirrors the enterprise’s physical layout:

UNS/
 ├── PlantA/
 │   ├── Area1/
 │   │   ├── Line1/
 │   │   │   ├── Machine01/
 │   │   │   │   ├── spBv1.0/PlantA/DBIRTH/Machine01
 │   │   │   │   ├── spBv1.0/PlantA/DDATA/Machine01
 │   │   │   │   └── spBv1.0/PlantA/DCMD/Machine01
 │   │   │   └── Machine02/
 │   │   └── Line2/
 │   └── Area2/
 └── PlantB/
        

Explanation of the Architecture

• UNS (Universal Namespace)
  
  
  • Think of it as a folder system for your factory.
  • It organizes plants, areas, lines, and machines so everything has its place.
• Hierarchy Levels
  
  
  • PlantA / PlantB → Each factory location.
  • Area1 / Area2 → Different sections inside the plant.
  • Line1 / Line2 → Production lines in each area.
  • Machine01 / Machine02 → Individual machines on a line.
• Sparkplug Topics in Each Machine
  
  
  • DBIRTH → Machine announces it is online.
  • DDATA → Machine sends its data (temperature, speed, etc.).
  • DCMD → Machine receives commands from the control system.
  • These topics are namespaced under spBv1.0 and match the UNS path so data and commands go to the right machine.
• Why This Architecture Matters
  
  
  • Mirrors the physical layout of the enterprise, making it easy to track and manage machines.
  • Lets SCADA, MES, and analytics tools consume data in context (they know exactly which plant, area, line, and machine the data came from).
  • Keeps communication organized, scalable, and easy to navigate.

In short, the UNS structure in Sparkplug B is like a well-labeled filing system for all your machines. Every device has a clear place to send and receive messages, so your control and analytics systems always know where the data is coming from and where commands should go.

UNS and Sparkplug B Architecture Overview

The following diagram illustrates how UNS integrates with MQTT Sparkplug B within an IIoT ecosystem.

Benefits of Integrating UNS with Sparkplug B

• Centralized visibility: All real-time data is published into a single namespace accessible to every system.
• Plug-and-play scalability: New equipment or applications can be added without re-engineering data pipelines.
• Standardization: Unified topic and payload structure across all plants and systems.
• Low latency: MQTT provides efficient, event-driven data transfer with minimal overhead.
• Resilience: Sparkplug’s session awareness ensures accurate online/offline status tracking.

Empower Your Enterprise with Unified Data

MQTT Sparkplug B combined with a Unified Namespace provides a structured, real-time view of all operational data across your enterprise. This approach enables seamless scalability, plug-and-play integration, and faster decision-making across plants and systems.

With our MQTT broker, you can implement this architecture effortlessly, ensuring reliable, state-aware messaging for every device and application. Connect your systems, streamline operations, and unlock actionable insights across your entire IIoT ecosystem.

Download our MQTT broker and bring your IIoT systems to life today.