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
- Minimum Technical Requirements for UNS
- MQTT Sparkplug Topic Structure for Unified Namespace
- Parris and Schultz Methods for UNS Structuring with MQTT Sparkplug
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.
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 advantage with things like auto-discovery and defined data types.
Due to the above-stated characteristics, MQTT and Sparkplug meet the minimal technical requirements for a UNS implementation: Open Architecture, Edge Driven, Light weight, and Report by Exception, as described below.
Minimum Technical Requirements for UNS
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.
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.
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.
This topic namespace defined by Spatrkplug 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 delimiter to your Sparkplug topic namespace becomes:
You could also use the following format for your Sparkplug topic namespace:
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 a broker it is connected to.
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:
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:
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.
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.
HiveMQ is a fully Sparkplug compatible MQTT broker available in both on-premise and cloud-managed version. Try it out today and start creating a UNS.
Watch Part 3 of UNS Essentials video series.
About Kudzai Manditereza
Kudzai is an experienced Technology Communicator and Electronic Engineer based in Germany. As a Developer Advocate at HiveMQ, his goals include creating compelling content to help developers and architects adopt MQTT and HiveMQ for their IIoT projects. In addition to his primary job functions, Kudzai runs a popular YouTube channel and Podcast where he teaches and talks about IIoT and Smart Manufacturing technologies. He has since been recognized as one of the Top 100 global influential personas talking about Industry 4.0 online.
Follow Kudzai on LinkedInContact Kudzai