Implementing Unified Namespace (UNS) With MQTT Sparkplug

In part 1 of this Unified Namespace (UNS) series, What is a Unified Namespace and Why does it Matter?, we gave an introduction to what a UNS is. In part 2, How Does a Unified Namespace Works?, we dived deeper into concepts of UNS and best practices for structuring it. In part 3, we will cover why MQTT Sparkplug is best suited for implementing UNS, what are the minimum technical requirements for UNS, MQTT Sparkplug topic structure for Unified Namespace, and Parris and Schultz methods for UNS structuring with MQTT Sparkplug.

Introduction

Two main functions characterize the Unified Namespace (UNS). First, to act as a single source of truth for all data and information in an organization. Second, it serves as the central messaging broker, such that, instead of using many point-to-point communication interfaces, you route messages through a single communication interface.

But what is the most efficient way of implementing this abstract UNS concept?

You need a technology that allows you to organize data in a central location based on your organizational structure and events. Data centralization gives every network participant access to information – they will know where and how to find relevant information. Additionally, the technology needs to make the data transparent and available to all who have the authority to access it. While a few communication technologies may fit the profile, MQTT is by far the most commonly used technology for implementing the UNS.

Why MQTT Sparkplug is Best Suited for Implementing UNS

MQTT is the most commonly used messaging protocol for the Internet of Things (IoT). The protocol is lightweight, event-driven, and connects devices using the publish-subscribe communication pattern. Data producers and consumers communicate via topics through a centralized server, an MQTT broker.

MQTT Publish-Subscribe Communication Model

On the other hand, MQTT Sparkplug is an open-source software specification that provides MQTT clients the framework to seamlessly integrate data from their applications, sensors, devices, and gateways within the MQTT infrastructure in a bi-directional and interoperable way. Sparkplug defines a consistent MQTT topic namespace, state management, and payload to achieve this.

It’s important to mention that Sparkplug and flat MQTT are equally capable of implementing UNS. However, Sparkplug has added advantages with things like auto-discovery and defined data types.

Decoupled Architecture with MQTT and Sparkplug Creating a UNS

Minimum Technical Requirements for UNS

Open Architecture

MQTT and Sparkplug specifications are publicly available for implementation. As such, many organizations have adopted these specifications, making it easy to swap or add components from different IIoT vendors into the UNS data ecosystem.

Light weight

The creators of MQTT originally built it to monitor oil pipelines over satellite; so they designed it to have minimum overhead to fulfill the bandwidth-efficient and reliability requirements. Additionally, MQTT uses a binary protocol, which significantly reduces the overhead on the wire.

Report by Exception

MQTT Sparkplug’s Report by Exception rule ensures that data producers publish data to the UNS only when they detect changes in the monitored value. Reporting changes only enables the UNS to maintain the current state of its architectural components without continuously polling the data sources to establish a current state.

Edge Driven

Data is pushed into the UNS (MQTT Broker) by nodes at the edge of the network as a single source of truth as opposed to collecting modeled machine data from different intermediary sources.

MQTT Sparkplug Topic Structure for Unified Namespace

In a publish-subscribe architecture, subscribers can use MQTT topic structure to filter messages with wildcard subscriptions. It allows you to design hierarchical data access and specify data source location to implement a UNS. Using the ISA-95 common data model Enterprise/Site/Area/Line/Cell is recommended to map your organizational structure onto the MQTT topic structure.

As mentioned earlier, Sparkplug extends the functionality of MQTT by specifying a well-defined topic namespace like below.

spBv1.0/group_id/message_type/edge_node_id/[device_id]

This topic namespace defined by Sparkplug can also be used for your Unified Namespace structure with the added benefit of session state management and consistency in data structures. However, Sparkplug restricts the number of topic elements you can have, such that you quickly run out of elements to map your ISA-95 organizational structure.

The good news is that approaches have been developed within the Industry 4.0 community to accommodate longer hierarchical structures in the Sparkplug topic namespace. Most notably by Matthew Parris and David Schultz.

Parris and Schultz Methods for UNS Structuring with MQTT Sparkplug

The Parris Method

In the Parris method, you put your entire enterprise structure in your GroupID using delimiters to separate the categories. For example, using a colon as a delimiter to your Sparkplug topic namespace becomes:

spBv1.0/Plant1:Area3:Line4:Cell2/NDATA/<edge_node_id>

You could also use the following format for your Sparkplug topic namespace:

spBv1.0/Plant1:Area3/DDATA/Line4:Cell2/<device_id>

However, it’s advisable to avoid using the edge_node_id as part of your ISA 95 hierarchy. Because this could cause some conflict as the edge_node_id element has to uniquely identify an MQTT Edge of Network (EoN) Node within your infrastructure, as per the Sparkplug specification.

While the Parris method is simple to use, there is a challenge. An MQTT application receiving the Sparkplug message by subscribing to spBv1.0/# needs to break apart the GroupId and republish into flat MQTT topics to convert from a flat structure back to an expanded tree structure. For example,

spBv1.0/Plant1:Area3:Line4:Cell2/# => /Plant1/Area3/Line4/Cell2/#

Because the GroupID is globally unique (from the perspective of the Enterprise), the data can move around to any broker using standard MQTT bridges, without topic conflicts. An IIoT platform, therefore, is not required between each MQTT broker to decode and then re-encode the data up one level in the topic hierarchy.

Additionally, the use of delimiters within the GroupID allows you to standardise how your applications parse topic, across your enterprise. Otherwise, each application would need to be hardcoded to align with the topic hierarchy provided by the broker it is connected to.

Schultz Method

The basis for the Schultz method is that you don’t have to use a single MQTT broker to build a Unified Namespace. Instead, you can deploy multiple brokers at various levels (Area, Line, Cell) of your enterprise to facilitate communication at their level using a local UNS. Then use an IIoT platform to consume all low-level UNSes and republish everything to the Enterprise Unified Namespace.

To get a clear picture, imagine you have deployed one broker per area at a manufacturing Site. You could have each device publishing to its area broker using the topic namespace:

spBv1.0/Area/NDATA/Line

Schultz Method of Defining a UNS Structure via an Area MQTT Broker

After that, you can use an IIoT platform to subscribe to the Area brokers and then publish everything out to an Enterprise broker using the topic namespace:

spBv1.0/Enterprise/DDATA/Site/Area

Schultz Method of Defining an Enterprise UNS

This would allow you to create a Unified Namespace with a hierarchical structure not limited by the number of elements in the Sparkplug topic namespace.

While this approach allows you to avoid delimiters that might require some complicated parsing mechanisms, it introduces a lot of complexity and operational overhead.

Conclusion

To summarize, the Unified Namespace allows for a consistent and standardized way of organizing and accessing data across different departments and systems. This allows for easier collaboration and information sharing, leading to improved efficiency and decision-making. It also allows for better tracking and traceability of products and materials, reducing errors and waste. Overall, the unified namespace helps to streamline and optimize the manufacturing process, thus accelerating digital transformation.