MQTT Sparkplug B, or Not to B? Unified Namespace Architecture Considerations

The Unified Namespace (UNS) has proven to be a popular architecture for folks undergoing a digital transformation initiative.  At the core of the unified namespace architecture is a centralized repository of structured data which any application or device can subscribe or publish data to.  Utilizing a hub and spoke architecture provides the benefit of decoupling your data from the application layer – each node only needs to subscribe and publish to data within the UNS rather than create discrete connections to each device/application in your ecosystem. 

Figure 1 – Sample UNS Hub & Spoke Architecture

What protocol makes the most sense for a UNS?  Perform a bit of research on the topic and you’ll find this topic to be as polarizing as politics in some circles.  (There is an Industry 4.0 Community Discord server which industry experts actively debate these topics daily. Reach out to me if you are interested in participating and I’ll send you an invite.)  

Our research has shown that the prevailing opinion is that that MQTT (Message Queuing Telemetry Transport) is the best fit protocol to handle the real-time aspects of a UNS.  An MQTT broker is an intermediary entity that receives messages published by clients, filters the messages by topic, and distributes them to subscribers. The reasons most manufacturers choose MQTT is it:

• Is an open architecture and accessible by all consumers.
• Reports by exception. Only changes are reported (publish/subscribe).
• Is edge driven and intelligence pushes the payload.
• Is lightweight and doesn’t take down the network.

Enter MQTT Sparkplug B

While MQTT is an open standard, there are no specifications regarding the format of the Topic Namespace.  Subscribers must be able to know where to find and how interpret the data, which requires that all participants settle on a common format.  Along came the Sparkplug specification which had three main goals:

• Define an MQTT Topic Namespace “optimized for the SCADA/IIoT solution sector.”
• Define MQTT State Management which provides subscribers with device status through birth, death, and state messages.
• Define the MQTT Payload which “remain true to the original, lightweight, bandwidth efficient, low latency features of MQTT while adding modern encoding schemes targeting the SCADA/IIoT solution space.”

In our opinion, state management and the lightweight payload are the main advantages to using MQTT Sparkplug B; however, the topic namespace definition is critical when implementing a UNS.  Therefore, let’s look at the details of the Sparkplug B Topic Namespace:

namespace/group_id/message_type/edge_node_id/[device_id]

For the purposes of this article, we’re assuming that we’re using off the shelf implementations of Sparkplug B.  In that case both the namespace element and message_type elements are handled by the vendor.  The namespace element refers to the specific Sparkplug implementation being used and the message_type element indicates how to handle the payload of the message.  That leaves the user the group_id, edge_node_id, and device_id elements to configure for our use cases.

According to the specification:

• The group_id element is a logical grouping of Edge of Network (EoN) nodes.
• The edge_node_id element identifies the EoN node within the system which is publishing to the infrastructure. The group_id/edge_node_id combination must be unique within the MQTT infrastructure.
• The device_id element identifies a physical device attached to the EoN node.
• The group_id, edge_node_id, and device_id elements’ format is not specified and can contain any characters other than the reserved characters of +, /, or #.

ISA-95 Part 2

To reiterate our definition of a UNS: it is a centralized repository of structured data in which any application of device can subscribe or publish data to.  The structure of the data is key so as there will be an understanding of where to look for the data.  ISA-95 Part 2 defines a common model for a production plant hierarchy as:  Enterprise\Site\Area\Line\Cell .  This has been an industry standard for years with regards to modeling a production plant and thus many feel it makes sense to use to model data within the UNS.

Let’s look at this with an example enterprise called NeoBrewWorx.  In this company we’ll have a bottling line which has a PLC and we’ll want to add data from our ERP and CMMS systems.  We would model this with a folder for each device/application at the line level as follows:

• NeoBrewWorx (Enterprise)
  • Andover, MA (Site)
    • Bottling (Area)
      • Bottling Line 1 (Line)
        • PLC (Device)
        • MES (Application)
        • CMMS (Application)

UNS, Sparkplug B, & ISA-95 Part 2

Using the above example what would our topic namespace look like if we wanted to publish to the UNS with a Sparkplug B client?  If we adhere to the specification, the edge_node_id and device_id would be reserved for the client node and PLC respectively.  That leaves us just the group_id which we can absolutely put the entire path such as: ‘NeoBrewWorx\Andover\Bottling\BottlingLine1’.  If we assume we’d do the same with a Bottling Line 2 and other areas & lines we’d end up with something like this if we were to query the entire namespace with a Sparkplug B client:

• NeoBrewWorx\Andover\Bottling\BottlingLine1
  •  edge_node_id
    • device_id
• NeoBrewWorx\Andover\Bottling\BottlingLine2
  •  edge_node_id
    • device_id
• NeoBrewWorx\Andover\Brewing\BrewingLine1
  •  edge_node_id
    • device_id

As you can see, we’ll need to transform the group_id to get the desired namespace.  While this is possible, it defeats the purpose of ‘modeling’ at the edge and forcing consumers of the data to transform the data.

Conclusion: MQTT Sparkplug B or ???

If you asked ten industrial solutions architects about the proper way to architect a UNS, you’ll get ten responses.  While Sparkplug has its place – it is not suited to handle the requirements of a Unified Namespace.  The following are some rules of thumb we use when building out a UNS architecture:

• Use Sparkplug B where it’s best suited – at the edge with IIoT devices such as PLCs and smart sensors.
• We’ve recommended some additional resources at the bottom in which you’ll find methodologies from two of the leading folks on the topic today – David Schultz and Matthew Parris. We recommend the ‘Parris Method’ for your group_id and specify the full path to the asset utilizing backslashes as delimiters.
• Publish edge data to an intermediate Sparkplug B namespace. This could potentially be on several different brokers throughout your plant – there is no right or wrong answer here.
• Use a tool such as the Intelligence Hub from HighByte to build the UNS MQTT broker with the ISA95 topic path and add contextualized JSON payloads to the relevant topic path.
• Allow operational and business users to subscribe to the data with their preferred systems.

Figure 2 – HighByte Enabling Enterprise UNS Broker

While the concepts of a unified namespace architecture can be simplified – in practice there is quite a bit to it – and there is no user manual or established standards to get there.  There is a plethora of resources out there to help – online communities, blog posts, podcasts, etc.  If you are going through this journey and want to chat or need some help – please reach out.  We’re always happy to discuss and see if there is any way in which we can assist you on your journey.

Unified Namespace Architecture Resources:

• MQTT Sparkplug B Specification
• HiveMQ Sparkplug Essentials
• UNS architectural options with HighByte Intelligence Hub
• Industry 4.0 Community Discord – search for the “Parris” and “Schultz” methods. Contact me for an invite to the server.
• 4.0 Solutions Podcast: Using MQTT & UNS Architectures at Enterprise Level – Part 2

Industry 4.0 Manufacturing Increasing the Competitiveness of Industrial Manufacturing

While the promise of the digital transformation journey is exciting, weeding through the IoT trends in manufacturing and finding a place to start can be overwhelming. NeoMatrix can help cut through the industry jargon and help you achieve quick wins, shortening your time to value.