MQTT and Unified Namespace Integrations
Please note that this post will not discuss how MQTT/Sparkplug B and ISA-95 should be considered in the context of a Unified Namespace. For more information on interactions between MQTT/Sparkplug B and ISA-95, please also read these posts:
In this post, we will refer to Vanilla MQTT and Sparkplug B. Vanilla MQTT is simply MQTT without using Sparkplug B.
How Does Vanilla MQTT Support a Unified Namespace?
Before Sparkplug B, combining Unified Namespaces with MQTT made a lot of sense. MQTT and its topic structure, plus a standardized naming convention across your Unified Namespace essentially gives you a semantic hierarchy for free. However, without rules for structuring your topics with MQTT, you risk creating very complex topic names—and no way to easily manage them—as your system scales.
Out of the box, MQTT doesn't enforce or support a Unified Namespace approach to your topic naming conventions. You can name any of your topics anything you want so you could easily break an agreed upon naming convention, You can however plan out your overall naming convention ahead of time allowing you to combine a UNS approach with MQTT very easily. You can save a lot of headaches when implementing your Unified Namespace by planning out a naming convention for your MQTT topics ahead of time.
This is not to say Sparkplug B is a silver bullet or a free lunch for solving the naming convention problem. There is still a lot to take into account when using either vanilla MQTT or Sparkplug B to implement a Unified Namespace.
The concepts in this post will still apply if you were using non-Sparkplug B enabled devices and needed to strictly define your topic naming conventions.
An example of a vanilla MQTT topic is:
CorsoSystems/WaterTreatment/Pumps/Pump_1/SpeedWhere Does Sparkplug B Fit In?
For the sake of a Unified Namespace Architecture, Sparkplub B defines our topic namespace format for us—and vanilla MQTT does not. (Also, understand that we’re not discussing the technical details of payloads and metrics.) Since Sparkplug B uses a particular format, this will remove some of the work when determining your topic namespace. You will still need to work on determining the appropriate naming convention for your use case—whether you are using Sparkplug B or not.
The format for a Sparkplug B topic:
spBv1.0/Group ID/Message Type/Edge Node ID/Device IDUsing the example above, here’s how we might send our Speed value as a metric in the payload, so it is not part of the topic definition:
spBv1.0/WaterTreatment/Message Type/Pumps/Pump_1Sparkplug B is designed for true edge networks with multiple edge devices sending data to your MQTT Broker. So, for example it can be a little cumbersome to properly identify your Group ID, Edge Node ID, and Device ID if you are using a single PLC inside a factory.
How to Use MQTT to Connect Your Systems to the Unified Namespace
A diagram of an MQTT broker used to house UNS
If you think of the Unified Namespace as a tool built on top of MQTT data, then most of the job of connecting your devices to the Unified Namespace is handled by publishing data to the broker.
This is well illustrated in the diagram from HiveHQ, the popular cloud-based MQTT Broker. Their example specifies Sparkplug B, however you can also use vanilla MQTT to connect to the broker.
Please notice that we said "most of the job" above. It is important to understand that the Unified Namespace gives you the structure for your data as it flows through the system. However, it does not describe how the data is used in "Domain Namespaces" or the structure of data in the systems you integrate with the Unified Namespace.
For example, a piece of equipment might have a "Running Status" and "Downtime Reason", or a "Production Count" and "Cycle Time." You will send these to your Unified Namespace from your PLC. On the other side of the Unified Namespace in your MES system, you’re set up to track OEE. This system likely uses the concept of the equipment model from ISA-95, so you can track OEE for individual pieces of equipment, production lines, production areas, and even entire sites. With the OEE example for our domain specific namespace, you would map the values from the PLC to specific points in the OEE calculation engine for that piece of equipment. You will need to understand how to map the data from the Unified Namespace to the relevant point in the OEE tracking system. The same applies to anything you have integrated with the Unified Namespace.
How Does Sparkplug B Make My Life Easier?
Sparkplug B is a framework layered on top of MQTT. We like to think that frameworks are limiting to give us structure, and this is especially true with MQTT.
Without using Sparkplug B as a guiding principle for structure, it’s far too easy to build long and complex MQTT topics. It is even possible for different people to create entirely different topics for the exact same data points, depending on how they see their system integrating with the whole!
Sparkplug B gives you guidance and less flexibility for creating topic formats. But, this allows you to be creative in how you structure the topics to achieve your goals. Additionally, you can simplify your overall architecture—and have more flexibility with how you pass data into the broker—by passing along payloads capable of storing multiple metrics.
You will still need to define your Unified Namespace structure even when using Sparkplug B since it simply gives you a framework to follow.
Sparkplug B Seems Great, What's the Catch?
You still must define your specific topic parameters and metrics. Sparkplug B doesn’t do all the work for you.
You can’t subscribe to individual metrics in a Sparkplug B topic (We will discuss this more in a future post)
You still need to ENFORCE the structure across the Unified Namespace and all of your integrations.
Depending on your architecture, you may still need to do a fair amount of integration work.
While monolithic brokers can give you a single integration point, over time you may experience performance and bandwidth issues.
Distributed brokers can help reduce load and bandwidth at any single point in the network, however you will have more work to do for getting data into/out of the system.
The Sparkplug B concepts and topic structures may not map directly to MES and non-industrial data, and require more work. See our ISA-95 and Sparkplug B post for a detailed example.
Depending on the systems you are integrating, you may need to carefully map the Unified Namespace data to to the domain namespace.
An example in Ignition: having to map tags in the MQTT Engine to Reference Tags in a Tag Provider before using them in a typical Ignition system.
As your systems scale, you will inevitably need to adapt, refactor, or spend an inordinate amount of time planning everything up front.
One way to simplify this is by building scripts to manage your naming conventions so you can make global changes quickly.
Wrapping Up
MQTT and Sparkplug B feel like a match made in heaven with Unified Namespaces (UNS). They simplify how you get data into a Unified Namespace, and the MQTT Broker technology simplifies integrating many different platforms together.
But, you don't get a free lunch and you still have plenty of work to do for a successful implementation. Using MQTT/Sparkplug B along with a Unified Namespace is a huge step in the right direction for just about any manufacturing project!
If you have questions on any of these topics or would like help implementing your Unified Namespace, please reach out and let us know!
