How Does a Unified Namespace (UNS) Work?

In Part 1: What is a Unified Namespace and Why does it Matter? of this Unified Namespace (UNS) series, we gave an introduction to what a UNS is. In this article, we will discuss how it works.

Introduction

The Unified Namespace (UNS) is a consistent manner of organizing the structure and events of your manufacturing business, such that all participants of your enterprise network know where to go to find the data they need. In this way, the UNS is the single source of truth for all data and information within an organization. Moreover, it acts as the central hub/broker for all exchanged information.

But how does it actually work?

The secret is to treat every smart thing that uses an IIoT communication protocol as a node in your ecosystem. A thing that publishes data into a central hub, the UNS, and consumes from it. In other words, the data that the node publishes into the UNS becomes consumable by all parts of your organization, while the node also consumes data, from the UNS, that is published by other nodes.

For example, in manufacturing, all shop-floor components, sensors, machines, PLCs, SCADA, and robots would publish data to the Unified Namespace. Enterprise applications such as MES, ERP, and Cloud Analytics subscribe to the UNS to receive data as events, they then use that information to execute tasks and in some circumstances, publish relevant data back into the UNS for other nodes to consume.

If you have a background in IT, you may be tempted to think of UNS as an Event-Driven System (EDS). Indeed, there are similarities, but only to a certain degree. As opposed to EDS, where you only publish notable events, UNS allows you to publish each and every data change that happens. The Unified Namespace is the hub for most recent data in your enterprise and is accessible through a single unified interface.

Where does the Unified Namespace Live?

One question that get asked a lot on this topic is, “If the UNS is a central repository of information, where does it actually live?” It’s a great question.

Well, since the data and information from a UNS is presumed to be accessible by every network participant in a unified way, it doesn’t matter where that data lives. You could implement a UNS structure in a database and have every client query the database for the latest value. However, an MQTT broker is the most commonly used middleware infrastructure for UNS implementation.

A diagram of MQTT broker used to house UNS

The MQTT broker is merely the technology used to make data available efficiently and in a scalable manner. The Unified Namespace is more of a design approach and strategy that creates a contextual data structure and common endpoint for systems to connect and exchange information. In the words of Walker Reynolds of 4.0 Solutions, who popularized the UNS in the context of industrial digital transformation, “The Unified Namespace is omnipresent and lives everywhere and nowhere.”

Best Practices for Structuring a UNS

Now that we’ve established what UNS is and is not, let’s get into the practical details of structuring a Unified Namespace for your manufacturing organization.

The good news is, standards like the ISA-95 specify how to organize data of manufacturing businesses in a hierarchical structure, in a way that makes it easy for anyone with the proper permissions to access it.

ISA-95 Common Data Model

Although there are no hard-and-fast rules for structuring your UNS, the ISA 95 provides a solid format to use as a guideline (it is the only industrial standard). It’s a great starting point.

However, for some organizations, ISA 95 doesn’t reflect the true structure of their businesses. In that case, it is best to create a system that is unique to your business.

To build your Unified Namespace structure, it is best practice to use ISA 95 levels to create pockets of information that make up your enterprise hierarchy. The Cell level holds information that is relevant to that specific Work Cell. Line holds information that is relevant to a particular Production Line. And you repeat the same convention for your Area and Enterprise levels.

Once you’ve conceptualized what your Unified Namespace structure should look like to fill your needs, you’ll need a tool to build out the hierarchical folder structure and push it to the broker, in this case, MQTT-based UNS. Typically this tool is an IIoT platform that allows you to create nested directories and map them onto an MQTT topic structure for hierarchical discoverability using wildcards or the Sparkplug topic namespace. The Ignition Gateway from Inductive Automation would be an example of this.

Ultimately, you want to end up with a combination of two things – (1) A broker that maps namespaces from the disparate industrial systems into one standardised topic structure, and (2) Well defined data models. This implies that your UNS must be able to address the realities of incompatible industrial data structures using a data transformation layer. This is where tools like HighByte can help transform substandard variables and structures from legacy PLCs, and various data stores before publishing into your Unified Namespace.

Integrating Common Industrial Components into UNS

Here is a look at how data from common industrial components into UNS could look.

Integrating SCADA into UNS

A SCADA system would subscribe to the UNS to receive all data that is required to allows plant operators to efficiently run production. It would also publish back to the UNS commands to be executed by nodes on the plant-floor.

Integrating Historian Data to Unified Namespace

Since the UNS doesn’t capture historical data, a Process Historian would subscribe to topics of interest and store historical data for later retrieval. Further, in a typical plant some components would frequently query the Historian for information, so the Historian could publish back frequently queried information into the UNS for interested nodes to consume without having to establish static connections to ask for the data.

Integrating MES into UNS

In addition to handling raw materials and executing work orders, an MES also needs data from the plan-floor to enable it to calculate to business performance metrics such as OEE. Hence, it would subscribe to the UNS to receive the data, perform calculations and then publish back performance indicators into the UNS for consumption by nodes that need it to run with context.

Integrating ERP into Unified Namespace

At any given moment, some node in your UNS ecosystem might need to know what is running on a particular production line. Therefore a query or webhook event could be deployed on the ERP for the purpose of publishing such a dataset into the UNS.

Integrating Analytics System to UNS

Since the Unified Namespace harmonizes data from different sources to create context in real-time, its structure could be used as the basis for logging contextual data in a data warehouse to simply analytics by avoiding the application of ETL processes to extract data from disparate data stores.

Broker Federation for UNS Structuring

In most cases, manufacturing organizations want to deploy a data broker at the plant-floor for low latency processing and flexibility among other reasons. In such a case, you can use broker federation to build a UNS by deploying a broker with its own local UNS at each site, and then transmitting all the local UNSes into one enterprise-wide UNS struture on a centralized broker.

Broker Federation for UNS Structuring

What’s more, Broker Federation isn’t only limited to site level. You could deploy a broker at each production line, or every machine within a site and then pass the local UNS up to enterprise through site level.

Conclusion

In this article, we discussed how a Unified Namespace works and how to structure it. In part 3 of this series, we will look at the finer details of how MQTT and Sparkplug can be used to implement a UNS.