Unified Namespace 101

OT SCADA Con

Mar 2

If you’ve begun to research MQTT and how to apply it to a manufacturing project, you’ve inevitably seen the term "Unified Namespace" (UNS) thrown around at least a few times.

Since there are many misconceptions—and a lot of information—about the topic of Unified Namespaces hidden behind paywalls, we will set the record straight in this post. Yes we are including the ever popular ISA-95 standard in the list of “information behind a paywall” since it is almost a synonym for Unified Namespaces in a lot of the content out there—and it is a pricey proposition to buy all 9 documents in the standard.

What is a Unified Namespace?

The easiest and shortest answer to this question is:
After you have planned out the naming convention for all of your data across your business in a clear and easy to understand way—so that you can easily integrate all of your technology and devices together through a common data bus—then you have a Unified Namespace.

Diagram of an example Unified Namespace Architecture from Opto22 — Figure 1: Example of a Unified Namespace Architecture from Opto 22

A more detailed definition is that a Unified Namespace is an operating framework for business and industrial data. It gives you access to all the data in your system using a consistently named format across the entire business. This makes data available to any device or software that needs data from other software or devices to function. The Unified Namespace removes the need for specific domain expertise to access data by adding a layer of abstraction away from things like PLC tag addresses. It provides clarity by using an agreed upon naming convention and hierarchical structure to make it easy to find any data you might need across an entire business.

Frameworks like Unified Namespace provide limits for how you name things, which gives you structure and clarity even for large scale systems.

Want to know MORE about Unified Namespaces? Download our eBook, Unified Namespaces: The Ultimate Guide

UNS commonly leverages "new" technology like MQTT and Sparkplug B along with industry standards of modeling processes like ISA-95 to optimize how data is structured across a business. When using MQTT Data is then sent from the various sources to the UNS as MQTT topics/metrics and is available to any client or user subscribing to the topics. In instances where other protocols or methods are used to send data it will usually be converted into an MQTT topic to fit with common UNS implementation standards.

The Benefits of a Unified Namespace:

Easily find the data you are looking for across an entire business
Leverage the naming convention and hierarchical structure of the UNS to easily integrate with the data across devices and software platforms
Use tools like MQTT and Sparkplug B to easily make data available to anything that might need it
You no longer need to know that a pump's speed feedback is address N12:75 in a PLC. The PLC programmer will map those tags to the UNS so anyone can easily access the data based on the naming convention

A Unified Namespace is considered a "single source of truth" for your data. The idea behind this statement is by using the concept of UNS, you eliminate data silos and stagnant data common with "typical" system integration strategies. You don't need to know anything about the data coming field devices, I/O points, or tag naming conventions in the PLC or any business systems in the UNS to integrate data from a PLC into any system where you need data.

This means you can almost think of the Unified Namespace in the context of a SCADA system communicating with a PLC. The Unified Namespace acts similarly to any device, like a PLC, and contains information on all aspects of any system you have integrated into it for the entire business. Then any other system, in this case a SCADA system, can connect to the Unified Namespace and have access to whatever data it needs.

This is in contrast to the "old" way—1:1 connections between various parts of the technology stack like PLCs <-> SCADA Systems <-> MES Systems <-> ERP Systems. Each of these connections might name things differently at each layer, and you would have difficulty integrating your ERP System directly with your SCADA system for example.

Using a Unified Namespace forces you to separate the layers of your tech stack and removes huge amounts of complexity from a typical integration strategy. The controls team manages PLCs and SCADA systems, providing data to the UNS without having to share specific PLC tag addresses. Maintenance has access to data from all of your field devices and manages those, and using modern technology like MQTT can free up IT from worrying about the security implications because security is built into the architecture. By using UNS, you won't need to send your MES team digging into any PLCs to find the specific tags they need for calculating OEE. Likewise, your PLC team will make those available through the UNS, and the MES team can use the naming convention standards to find what they need.

Sparkplug B and Unified Namespace

Conceptually and at the most basic level of a PLC and SCADA system, you can think of UNS as all of your normal process-related data with a strictly defined and enforced naming convention. Pre-Sparkplug B, this could have easily been an MQTT broker with a well-defined naming convention for all of the data you’re sending to the broker. It can also be easily implemented with Ignition and remote tag providers feeding into a central gateway along with reference tags where necessary. In a post-Sparkplug B world, using Sparkplug B gives you a Unified Namespace by default, assuming you are consistent with your topic format and metric naming conventions. Using this concept, we can think of the most basic form of UNS as an MQTT Broker if we want to keep things simple and are using Sparkplug B enabled devices. You'll see this approach in the example architecture from HiveMQ in the diagram below:

HiveMQ's example diagram of an MQTT broker used to house UNS — HiveMQ example diagram of an MQTT broker used to house UNS

With Sparkplug B, it’s easy to add or change nodes in the system to support changing technology over time, without breaking your existing integrations. It can also eliminate duplicate work and duplicate data inherent in the older 1:1 integration style when connecting devices and systems together. If new technology is released, you can quickly and easily integrate it into your current business by leveraging the flow of data through the your Unified Namespace.

As you can see from the architectures in the diagram above, each specific device has data translated into the Unified Namespace through Sparkplug B. This means you don't need to be a PLC expert to get data from the PLC or field level device as you would be in a non-Unified Namespace situation.

Sparkplug B will get you MOST of the way to a Unified Namespace, however you still need to define your metrics for various devices to fit into the UNS.

A Basic Unified Namespace Example with Sparkplug B

Using the Sparkplug B Topic namespace example, we will describe a few examples of how metric naming can impact your system.

Using the Sparkplug B specification, we have the definition of the base Sparkplug B Topic:

spBv1.0/Group ID/Message Type/Edge Node ID/Device ID

Let's assume we are building out a UNS for a water treatment plant. To keep things simple, the facility is called Creekside, and we are at the Main influent portion of the process. We are looking at a valve, a motor, a temperature transmitter, and a level transmitter.

Below, we’re mapping Creekside to our Group ID, Main Influent to our Edge Node ID, and the various instruments to our Device ID in our topic definitions:

spBv1.0/Creekside/Message Type/Main Influent/P-101
spBv1.0/Creekside/Message Type/Main Influent/XV-101
spBv1.0/Creekside/Message Type/Main Influent/LIT-101
spBv1.0/Creekside/Message Type/Main Influent/TIT-101

Assuming we have the signals, there are many ways we can define metrics in a Unified Namespace with varying levels of success. If our PLC has tags with the following naming convention, there are a number of ways we can build out our naming convention:

  
    P-101
    XV-101
    LIT-101
    TIT-101
      
    Speed Command
    Position Command
    Level
    Temperature
  
    Speed Feedback
    Position Feedback

We can easily use the names for each metric in the table for each device. This would allow us to be very specific about which values we are looking at when we see the MQTT data come across.

However, when we go to use this data in a system like Ignition, we would need to handle each individual device type as its own case and account for that when we are building Ignition tags from the MQTT tags.

Or instead, we could take a more generalized approach similar to PlantPAX from Rockwell where we name commanded values CV For Control Value, Instruments and Feedback values are called PV for Process value.

In that case, our table from above would now look like:

  
    P-101
    XV-101
    LIT-101
    TIT-101
      
    CV
    PV
    PV
    PV
  
    CV
    PV

A more generalized naming convention would allow us to get the process values for all of the devices when subscribing to them. This can help reduce development overhead when handling lots of tags in systems like Ignition where you are using scripts to interact with data.

The Power of Frameworks: Limits Enhance Creativity and Capability

We are not here to tell you that using CV/PV or device specific language will make the most sense in all scenarios. But, we are saying that you have the option within the Unified Namespace and Sparkplug B Framework to name your metrics whatever makes the most sense for your business.

It doesn't matter WHAT you use for your naming structure as long as it makes sense for your business. You will need to enforce its usage across the entire tech stack, and be consistent.

Using a framework like Unified Namespaces will free up the time you would spend determining tag names and understanding how to integrate a new piece of equipment into your process. You can give your OEM supplier, your team, and anyone involved with the actual integration the naming spec and instructions for how to integrate with your Unified Namespace. As part of their commissioning scope, you can work through their UNS integration and verify that everything matches your expectations.

Wrapping Up

Unified Namespaces can be a powerful tool for Manufacturing Operations Systems of any size. UNS makes it easy to integrate many different technologies together. It allows sharing data across many different disciplines and helps you to easily add new technology, vendors, and team members to your organization with less training overhead.

Frameworks like Unified Namespace give you clearly defined limitations, freeing you from having to make hundreds of decisions each time you need to integrate new data into your workflow.

We will have more posts covering MQTT, Sparkplug B, Unified Namespaces, and how to utilize them to take your manufacturing operation to the next level. To learn more about UNS, check out our eBook, Unified Namespaces: The Ultimate Guide (free download for PDF or ePub, low cost Kindle option also available).