It's easy to discuss how a Unified Namespace (UNS) can help your overall integration strategy. However, this is where most discussions stop—long before any real talk of how to structure your namespace.

At Corso Systems, we like to give the world the tools and information they need to be successful—and then let them reach out to us for help with the really difficult situations. This post will explain using Unified Namespaces in real world scenarios. While we'll explain the concept of mapping UNS to a Domain-Specific Namespace with a few examples below, the main takeaway is that in a Unified Namespace, MQTT is the backbone of your data. Everyone who needs to use it will need to add their own level of abstraction to properly use the data in their system. Then, they can also map it back to the Unified Namespace to update the relevant values going forward.

Unified Namespace Integration Using Ignition

If you have a system with enough scale to use Unified Namespace and MQTT (and you are using Ignition), chances are you will also be using many templates and UDTs (User Defined Types).

One of Ignition’s foundations is the implementation of tags and tag providers. Typically, tags will use a device connection to get values from PLCs. However, MQTT tags are not tied to a device connection and instead come through the Cirrus Link MQTT Engine module as MQTT tags. While it is possible to use these tag directly in your project, since the MQTT Engine shows up as just another tag provider, there are a number of limitations to this approach.

1. First, you can't bind to tags that don't exist yet. So, if you are development in Ignition before your MQTT device is online, you will either need to use a simulated device or create memory tags to use in scripts, bind to your components in windows, etc.

2. Second, you can't use UDTs in the MQTT Engine—it doesn’t know what a UDT is! It can still cause a lot of problems over time for large systems not using UDTs.

3. The final major reason not to directly use MQTT Engine Tags is that if the Device ID changes at any point, it will create a new folder for the tags in the Engine tag provider This means that anything using the old tag path, including history and alarms will be broken!

These three examples expose a limitation of the Unified Namespace concept. While the backbone of your system is made up of MQTT tags and data distributed through an MQTT Broker, the systems connecting with the broker to consume the data have their own way of handling the data. For our purposes, we will refer to this is as a domain-specific namespace.

Ignition can interact with the MQTT broker through the MQTT Engine module, then Ignition handles tags the way it does normally—using a Tag Provider. For anything Ignition-specific, it makes the most sense to use the normal tag provider infrastructure like in every other Ignition project, populating data from the data in the MQTT Engine tags. The main difference compared with a normal application using data from PLC devices, is that with UNS we will want to set up Reference Tags to our MQTT Engine tags in our real-time tag providers.

This allows us to gain the benefits of UNS as a single source of truth—including the consistent naming structure—while leveraging the power of Ignition with UDTs, tag history, scripting, and binding to components in windows. Instead of using an OPC Path to a tag from a device connection as our datasource, a reference tag lets us reference the MQTT Engine tag provider for its values.

We can use reference tags to store tag history like any other tags in Ignition. If the MQTT device name changes, we can update the reference tag path to the new folder in the MQTT Engine Tag Provider without losing data. History and alarms will look similar to the operator, since the tag path will always be consistent regardless of what the tags look like in the Unified Namespace. Reference tags also allow us to take full advantage of UDTs. We can build our UDTs normally, and use parameters to map the UDT member tags to the proper tags in the MQTT Engine Tag Provider.

Another benefit to using reference tags is that we can easily filter out the number of tags we focus on in Ignition as the number of metrics grow on any particular device. We only need to build reference tags for the metrics we need in Ignition. The rest of the data will still exist for any system that needs it, but won't clutter up our Ignition tag providers if we’re using reference tags instead of directly using MQTT Engine tags. Yes, you can also filter down to the relevant tags in the MQTT connections and send less data from the devices, however this will require ongoing maintenance and upkeep. Sending all the data to the MQTT Engine provider then getting only what you need in an Ignition tag provider with reference tags will save you a lot of trouble over time.

Unified Namespace Integration For OEE

Overall Equipment Effectiveness or OEE is another common domain-specific namespace in the context of manufacturing. OEE is typically part of a Manufacturing Execution System (MES) implementation, since it combines data from the plant floor, Enterprise Resource Planning (ERP) systems, and quality control systems for a single Key Performance Indicator (KPI). This KPI will show you the realtime health of your plant, production lines, and individual pieces of equipment.

We have a deep dive post which discusses using ISA-95 in conjunction with Unified Namespaces and why we think it is better to keep your MQTT Topics separate from your ISA-95 equipment model. Integrating data with an OEE system is a perfect example of why!

The Problem with Mixing ISA-95 and Sparkplug B

Typically, an OEE system uses the ISA-95 equipment model concept to build out a model of your process. This makes a lot of sense for tracking OEE at various levels of your process. For example, this model allows you to easily propagate data from equipment to the line level.

Let's say you need to find the following data points in your Unified Namespace for a number of pieces of equipment to calculate OEE:

• Running Status

• Downtime Reason, if not running

• Current Cycle Time

• Design Cycle Time

• Infeed Count

• Outfeed Count

• Scrap Count

If these items are in your namespace (using the Parris method) as a topic like:

spBv1.0/Corso Systems:HQ:Area 1/Message Type/Line 1/Case Packer

or

spBv1.0/Corso Systems\HQ\Area 1/Message Type/Line 1/Case Packer

and you had all of the metrics as part of your topic, then you could simply map them and be done. But, if it is that simple, you may want to learn why they weren't already mapped to your OEE system!

In most cases, you will need to map these values from the ground up since they will likely not be integrated into your Unified Namespace. Or if you do have them, the Unified Namespace may have been started from the plant floor level moving up—in which case you won’t have all of the ISA-95 terminology in your topic structure.

The PLC that the data is coming from is the first place to look for it. You may need to start by examining an I/O list in Excel created when the system was commissioned. This should have the tags to look for and which PLC will have them. The process of finding the data leads us to the first reason we don’t recommend mixing the ISA-95 equipment model with your topic structure.

For example, let’s say you have a photo eye for your infeed count on a bottling line. It’s in your ISA-95 equipment model as:

• Corso Systems

• HQ

• Area 1

• Line 1

• Bottling Machine

Great, now lets say you have it set up to look at the MQTT Topic:

Within this topic, you configured a metric as part of a payload called "Infeed Count":

No issues so far: you have the data you want, it is going where you expect it to go, and you can now track your infeed count without any hassle.

But, on Friday night while the bottling line is humming along, something happens to the photo eye. Maybe it just dies, maybe someone bumped into it while they were walking by and it is out of alignment, or it’s just not working for some other reason. This will cause your infeed count to drop to 0, wreaking havoc on your OEE data. On Monday morning, you’ll need to track down and resolve the issue.

First, you’ll look at MES system to see if there is an issue with the calculation engine, or something in the database. You don't see anything obvious, so you start digging deeper. You look in a few places and after an hour or so figure out that the infeed counter is not triggering. You'd normally expect to see it trigger many times per minute. After realizing this, you’ll need to find where the data for that metric is coming from—but when you look at the binding, you see:

Now, you will still need to go figure out where this is coming from! You’ll need to locate a list of "which I/O points go with what equipment,” and you’ll need to store an additional set of information to reference, or you’ll have to manage a lot of metadata for all of your metrics to store that in the ISA-95 structure. And while you can certainly do either or both of these options, what will happen when someone implements a new line in a year—and they haven’t read through 100% of the Unified Namespace spec, and they miss mapping the additional metadata required?

Either way, you must figure this out—and it will potentially take at least a couple of hours to track it all down.

Solving the ISA-95 and Sparkplug B Conundrum

How do we solve or prevent this problem? First, we’ll keep the ISA-95 equipment model very far away from our Sparkplug B definitions. In fact, we'll make a bold statement:

If you mix ISA-95's Equipment Model with your Sparkplug B topics, you are not properly supporting your company or your engineers.

Instead, we would recommend using the following topic definition. Assume we are looking at the data coming from a PLC named PLC-BTL-1 with the Infeed Counter coming from IO Point 3 on the I/O card in Slot 7:

In our SCADA system's Domain Namespace (where someone might need to map this to a value on the screen or store tag history) we would map this definition to a tag called Infeed Counter, and either put it in a UDT for the Bottling Line, a general OEE function, or in an organized folder structure. Now, the people who need the data in the context of the Infeed Counter for the Line 1 Bottling Machine can find it.

In the OEE system, you’ll know that you are looking at the Infeed Counter because you have the value mapped to that point in the OEE Engine's Domain Namespace.

You will make troubleshooting this system much easier by giving the metric a human readable name and a reference to an I/O point—where applicable. You can look at the mapping in the OEE system and immediately see what functional area the data is coming from, what it controls, which device type (“PLCs”), and the specific device (“PLC-BTL-1”) the data is coming from.

Since it is an I/O point in that PLC, you get the description you would find on an electrical drawing or an I/O list along with the specific I/O point. If you wanted to take it one step further, you could even add in a location name. Although at some point, you will add so much complexity it takes longer to parse the metric than to go find the photo eye in the field.

In our previous example, the moment you look at the mapping you will know where to look to see if the PLC is getting data that isn't making it to the OEE engine, or if the signal from the photo eye isn't making it into the PLC.

The Ideal Solution

In an ideal world you would be able to configure your broker to ingest Sparkplug B data and output vanilla MQTT Topics with the metrics from a Sparkplug B Payload mapped to individual topics.

This would let you take advantage of the compression capabilities of Sparkplug B for sending large amounts of data, and would allow you to take advantage of MQTT’s topic structure saving you a lot of time and hassle in building out the semantic hierarchy in your Unified Namespace.

Plugins like this exist for HiveMQ, and building this functionality out using another broker would be possible and should be high on the priority list for broker developers to implement.

Wrapping Up

As we explained in our other posts about configuring and implementing a Unified Namespace, part of the work (and arguably some of the most important effort) is understanding how to map your Unified Namespace data to the local Domain Namespaces of every system connected to the Unified Namespace.

Spending the time to plan which systems you might eventually want to connect to your Unified Namespace is a worthwhile use of time, as we have demonstrated in this post. Likewise, keeping your topic naming conventions as platform-and-area-of-focus agnostic as possible (while modeling your data similar to the way people will look for it) will help ensure the success of your Unified Namespace implementations.

If you have questions about how to properly name your topics in a Unified Namespace, want to see more examples of what we have done, or have any questions, please reach out and let us know!