What is Sparkplug B (Pros and Cons, in simple words)

In the field of Industrial IoT, standards are playing an increasingly important role in ensuring interoperability between devices from different manufacturers. One such standard is Sparkplug B. This aims to define communication in MQTT-based networks. The advantages and disadvantages of Sparkplug B in MQTT networks are discussed in the following article.

What is Sparkplug B?

Sparkplug B is an open standard of the Eclipse Foundation and comprises one specification. The emergence of Sparkplug B can be traced back to MQTT’s conscious decision not to define any standards for the structuring of MQTT messages. This openness has made the protocol very popular in the IoT world. However, this flexibility also leads to problems, especially when it comes to interoperability between different systems. Difficulties can arise when different devices and applications need to communicate seamlessly via MQTT. Sparkplug closes precisely this gap with its focus on SCADA environments. To this end, the standard defines uniform data formatting and uniform state management within MQTT.

An evolution of Sparkplug A: Sparkplug B builds on the principles of Sparkplug A. Sparkplug A is an earlier initiative to extend the MQTT standard, but it did not catch on. Sparkplug B further developed the concepts and objectives of Sparkplug A and transformed them into a robust specification. This addresses the requirements of modern infrastructures and has thus found greater acceptance in the industry.

Terminology and architecture

Sparkplug defines a clear terminology and architecture for the organization of messages to ensure the unambiguity and efficiency of data transmission.

Sparkplug’s architecture consists of several key components:

• MQTT Server (Broker) as the core of the Sparkplug architecture. This serves as a node for message transmission between edge nodes and the primary host application.
• Edge nodes are located at the edge of the network (e.g. IPCs, gateways, PLCs). These collect data from sensors and actuators and forward it to the broker.
• Edge deviceas a physical device that captures (sensor) or generates (actuator) data.
• Primary host application: The central application that processes the data. For example, a SCADA system that is responsible for monitoring, controlling and optimizing production processes.

Sparkplug B vs. MQTT

To illustrate the added value of Sparkplug, Level 0 to Level 5 of the “Data Access Model” (source: Matthew Parris) are shown below. The Data Access Model serves as a framework for data access. It outlines the essential levels that are crucial for interoperability between data sources and consumers in an industrial context. Undefined levels promote flexibility at the expense of greater integration effort, as each implementation must be interpreted and integrated individually. Sparkplug B complements the MQTT standard as follows.

Sparkplug B Topic Namespace

The standard defines the topic namespace and thus a clear MQTT topic structure as follows: spBv1.0/group_id/message_type/edge_node_id/[device_id]. This structure enables the identification and grouping of data streams in an IIoT network and consists of the following components:

• spBv1.0 signals the use of Sparkplug encoding.
• Group ID allows edge nodes to be grouped logically (e.g. according to geographical locations or functional units).
• Message Type distinguishes between different types of MQTT messages (e.g. DDATA for device messages)
• Edge Node ID and Device ID for a unique identifier for edge devices, which enables direct communication and clear assignment of data streams.

A practical example of a manufacturing company with a site in Prague would be the structure: spBv1.0/ExampleCompany:Prague/DDATA/MillingArea1:Line1/Cell1

Message Types

Sparkplug defines different types of MQTT messages (message types), which are specified in the topic namespace and fulfill special functions:

• NBIRTH – Birth certificate for Sparkplug Edge Nodes. Is used to announce the initial registration of an Edge Node in the network and to transmit its metadata.
• NDEATH – Death certificate for Sparkplug Edge Nodes. Used to inform the network about the orderly shutdown or unexpected failure of an Edge Node.
• DBIRTH – Birth certificate for devices. Similar to NBIRTH, but for individual devices to report their presence and configuration to the network.
• DDEATH – Death certificate for devices. Informs the network when a device is shut down, whether this is due to a planned shutdown or an error.
• NDATA – Edge Node data message. Transmits the actual operating data from an edge node, for example measured values or status information.
• DDATA – Device data message. Transmits operating data from individual devices, such as measured values or sensor data, to the network.
• NCMD – Edge Node command message. Enables the transmission of control commands to an edge node in order to trigger certain actions or change configurations.
• DCMD – Device command message. Wie NCMD, jedoch speziell für das Senden von Befehlen an einzelne Geräte konzipiert.
• STATE – Sparkplug Host Application state message. Transmits the status of the Sparkplug Host Application, including availability and health status, to the network.

Sparkplug B Payload

Sparkplug payloads use Google Protocol Buffers to provide a compact method of data transmission. These payloads contain metrics, metadata and status information that make it possible to provide updates on the status of devices and sensors. Each payload follows a defined structure that standardizes the reading and writing of data. The following example shows an NDATA message that is published in the spBv1.0/ExampleCompany:Prague/DDATA/MillingArea1:Line1/Cell1. This configuration causes the host application to update the value of the Supply Voltage, CNCOperationMode and ActFeedrate.

Pros and cons of Sparkplug B

Sparkplug B presents both significant advantages and challenges in an industrial context that need to be carefully weighed up:

Pros:

• • Payload definition and interoperability: By using consistently interpreted data types across the MQTT ecosystem, Sparkplug B leads to higher interoperability.
  • Session Management: It provides a standard for managing the session state of all connected components, which facilitates coordination and synchronization.
  • Defined topic naming: By structuring the MQTT topic namespace, Sparkplug promotes clarity and consistency in communication.

Cons:

• • Complexity: The reliance on ProtoBuf may be familiar to IT professionals, but can present additional complexity for OT professionals who are less familiar with this coding mechanism.
  • Bandwidth savings vs. complexity: For manufacturing systems connected with Ethernet cables, the bandwidth savings that Sparkplug B brings may not justify the increased complexity.
  • Limitations in the topic elements: Sparkplug imposes restrictions on the number of topic elements, which can potentially limit its scalability and compatibility with complex organizational structures such as ISA-95.

Conclusion

Sparkplug B addresses key challenges in scaling an MQTT based infrastructure in Industrial IoT environments. The definition of a standard for topic namespace, payloads and session management can bring significant benefits, especially in SCADA environments. However, the standard also comes with significant limitations, including the deviation from the widely used ISA-95 model, the dependency on ProtoBuf and restrictions on the topic elements. These can potentially lead to scaling problems.

Companies should therefore carefully examine their specific requirements, taking into account factors such as their existing organizational structure, the expertise of their employees and the nature of their systems.

i-flow Industrial Unified Namespace (UNS)

About i-flow: At i-flow, we are dedicated to empowering manufacturers with the world’s most intuitive software to seamlessly connect factories at scale. Over 400 million data operations daily in production-critical environments not only demonstrate the scalability of the software, but also the deep trust our customers place in i-flow. Close cooperation with our customers and partners worldwide, including renowned Fortune 500 companies and industry leaders such as Bosch, Sto and Lenze, is at the heart of our business.

About the software: i-flow provides the central tools for the implementation and operation of a scalable Industrial Unified Namespace Architecture.

1. Connectivity Layer: With more than 200 connectors, you can integrate common OT and IT systems into your UNS with just a few clicks.
2. Harmonization Layer: The i-flow software harmonizes source data before it is made available in a central message broker.
3. Message broker: i-flow comes with a fully integrated MQTT broker, but also supports existing brokers (e.g. MQTT, Kafka).
4. Microservices: Combine, aggregate and transform OT and IT data via i-flow microservices, for example to calculate KPIs or realize complex integrations.