Nowadays, every industrial manufacturing plant is transforming towards a more digitalization approach. At the same time, seemingly everyone is trying to make their manufacturing plants and process smart and Industry 4.0 compliant due to varied benefits to the manufactures and their customers.

To achieve digitalization the base is DATA, the data needs to be collected, transformed, and leveraged.

But in an industrial manufacturing plant there are many different machines, sensors, MES, SCADA, devices, and applications from different vendors are in use to do different things. This can't be avoided unless all machine vendors agree to follow a common industrial communication/integration specification.

If there are few components to integrate then it may not be an issue, but when there are hundreds in numbers there comes the challenge to integrate and maintain these systems.

To overcome this spaghetti integration architecture there are common specifications developed like OPCUA, MTConnect are few of them.

But the problem is OPCUA is still a complicated protocol specification, and many users and developers struggle to follow and implement this. Not all devices in the shopfloor can be integrated with OPCUA.

Spaghetti IT/OT Architecture with many interfaces and integration

Current Challenges With Many Industrial Protocols:

• Data interoperability is a significant challenge to implement smart manufacturing solutions. 
• Data transformation challenges
• Many industrial protocols and interfaces to integrate with
• OPCUA is still a challenge for integration and difficult in learning, not so easy standardized available communication specification

What is/are the Solution(s)?

To follow a common industrial communication standard, right? But as I discussed earlier it’s not that easy and still there is not much interest with the vendors I feel.

OPC UA and MTConnect are some standards which try to solve these issues, but their adoption and integration is still low.

OPC UA was developed to achieve device interoperability that is independent of the proprietary APIs of device manufacturers. 

OPC UA is complex to implement and integrate for many till now and MTConnect is a read-only protocol. There is also some level of tight coupling that exists in this standard of integration.

So many users want to have

So how about a message based and publish-subscribe architecture which can give the OT and IT layer integration more flexibility, decoupled and easy to integrate solution. Does this make sense? I think yes.

Let's talk a bit about MQTT before going further in our discussion:

MQTT is a publish/subscribe message base protocol and very popular with IOT based applications. It is used with devices having less bandwidth and power usage. It is a lightweight, TCP-based, and Data-agnostic and secure protocol.

With MQTT message-based architecture a decoupled architecture can be achieved and MQTT also easy to learn and integrate. It has basically a topic and payload structure to publish the messages from and to a MQTT broker.

MQTT Pub/Sub Architecture

Many people tried to use it in smart manufacturing use cases but there were some problems.

• There is no standard followed and structure defined to publish and subscribe the messages/payloads
• Topics are not easily discoverable to other apps and devices which wish to subscribe/publish messages
• No structured definition for payloads
• Difficult to transform payloads by subscribing MQTT clients

So, users or apps can publish messages in any custom format and topic which is difficult to understand and transform by any Mqtt Subscriber client.

To overcome the above challenge Sparkplug B comes to rescue.

So, what is MQTT Sparkplug B?

MQTT Sparkplug B is an open-source software specification that provides MQTT clients with an interoperability protocol to seamlessly integrate data from various applications, devices, sensors, and other elements of MQTT infrastructure. 

Sparkplug allows IIoT deployments to decouple the data between hardware and software sources. With Sparkplug, new data sources are immediately discoverable to other system components.

It basically says how the "topic" and "payload" must be formed and structured and sent to the Mqtt Sparkplug enabled broker.

The Architecture:

Principles and mechanisms of Mqtt Sparkplug B architecture:

Pub / Sub: It uses MQTT as a publish / subscribe architecture for the underlying application transport layer and decouples producers and consumers of data.

Report by Exception (RBE): Data and device state is only updated if it changes. This saves bandwidth and computing power for all components as only new and fresh data is sent over the network. (Similar to MTConnect)

Continuous Session Awareness: It informs all clients that care about the real-time information of the device online/offline state if it changes. This concept also makes sure that data in transit is continued to be sent to devices if they change state from offline to online again.

Death and Birth Certificates: Sparkplug introduces Death and Birth Certificates that are used for the management and discovery of device state. Birth certificates encapsulate information about the device and the data it can and will send. Death certificates are using the MQTT Last Will and Testament mechanism to push device offline information to all interested applications.

Persistent Connections: All devices, gateways and applications are by default always on and use persistent TCP connections.

Auto discovery: Applications and devices can auto-discover what data (and the corresponding topic) will get sent by all participant in the Sparkplug deployment as well as the online/offline devices that are connected to the MQTT broker.

Standardized payload definition: The Sparkplug data format for all messages is standardized and can be decoded and encoded by all communication participants. (We will discuss this in detail)

Below is a typical MQTT Sparkplug B architecture representation.

MQTT Sparkplug B Architecture

The payload and topic structure definition for Sparkplug B:

Sparkplug defines a standard format for MQTT topic paths.

namespace/group_id/message_type/edge_node_id/device_id

Let's understand what all these elements depict in a topic.

Let's understand a topic structure.

spBv1.0/Sparkplug B Devices/DDEATH/Raspberry Pi/Pibrella 

1. ‘Group ID’ : Sparkplug B Devices
2. ‘Edge Node ID’ : Raspberry Pi
3. ‘Device ID’ : Pibrella
4. This is a DDEATH message based on the DDEATH Sparkplug Verb

So, what are the various "Message Type" defined by Sparkplug specification? Let’s have a look below:

• NBIRTH – Birth certificate for Sparkplug Edge Nodes
• NDEATH – Death certificate for Sparkplug Edge Nodes
• DBIRTH – Birth certificate for Devices
• DDEATH – Death certificate for Devices
• NDATA – Edge Node data message
• DDATA – Device data message
• NCMD – Edge Node command message
• DCMD – Device command message
• STATE – Sparkplug Host Application state message

Sparkplug B specification uses a more efficient format for messaging which is based on Google Protocol Buffers or popularly known as "protobuf". If you have worked or heard about gRPC you might know some details about this.

It’s a binary format for transmitting messages over a network which use very low bandwidth due to binary messaging format. This is very useful in OT layer where some of the machines may be connected over WLAN or have network bandwidth issues. The "Protobuf" messaging format can reduce the burden in this case. It can also achieve higher data throughput, machines connected over cellular data can get more benefits.

Protobuf also gives us more flexibility to transmit more complex datatypes. The protobuf specification for Sparkplug B can be found here.

The "Report by Exception" principle of Sparkplug specification saves bandwidth and computing power as the "Data and device state is only updated if it changes."

What are the components involved in the Sparkplug architecture?

Sparkplug Architecture consists of the following components:

1. SCADA / IIoT Host
2. Edge of Network (EoN) Nodes
3. Devices / Sensors
4. MQTT Application Nodes
5. MQTT Broker

The SCADA / IIoT Host, sometimes also referred to as Primary Application, is the supervising application responsible for monitoring and control of the MQTT EoN nodes and their respective devices and sensors.

An Edge of Network (EoN) node is one of the key roles in any Sparkplug system. EoN nodes usually provide physical or logical gateway functions for sensors/devices who don’t implement Sparkplug themselves and let them participate in the MQTT Topic namespace. 

MQTT Application Nodes are nodes participating in the Sparkplug communication and can produce and consume messages but are not the IIoT host. The MQTT broker is the central data distribution component and the single source of truth.

Devices and Sensors may or may not be MQTT enabled. If MQTT enabled, they can directly publish the messages to the MQTT broker. If not MQTT enabled, then those devices and sensors can be integrated to the Edge Nodes which are MQTT capable.

I hope you get an overview of MQTT with Sparkplug architecture and how we can design and implement a decoupled and more flexible and easier to integrate and maintainable IIOT architecture using this.

For more information and deeper understanding, please go through the specification below. The specification is managed by the Eclipse Foundation as part of the Eclipse Tahu project. 

End Note:

The Sparkplug specification builds on top of MQTT (V 3.1.1 and 5.0) is to create a framework that is tailor-made for the requirements for IIoT systems.

It provides the context data needed to define tag values for use with OT. By only sending data changes and using a publish-subscribe pattern, network traffic is significantly reduced. protobuf binary messaging format is a low in size messaging format which also reduces the load on network.

With Mqtt + Sparkplug B specification we can achieve a modern decoupled architecture for the Industry 4.0 use cases and the IT/OT integration will be smoother and easier to understand and integrate systems.