UNS 101: Understanding the Unified Namespace

UNS 101: Understanding the Unified Namespace

In the last two years, I’ve spoken to hundreds of professionals in the industrial space, and the Unified Namespace (or UNS) design pattern has been a consistently difficult concept for them to wrap their heads around.

The Unified Namespace is nothing magical. But it is a different approach than we have taken in the past.

The Unified Namespace can be broken down into “Unified,” which is to standardize and organize with one central approach, and “Namespace,” the structure of the system. In a database, the namespace is the tables’ columns and relationships. In MQTT, the namespace is the topics and payloads.

In the past, all data in an industrial environment went to a SCADA system, and in many cases, the data was “unified” in the screens. These screens provided the process view of the production. The Quality team may have installed specialty equipment or test stands with their own logging methodology into a database on a local computer. Reports detailing the quantity of defects would then be generated and sent to the Quality team the following day or week. The Asset Maintenance team used an ERP or CMMS like Maximo to initiate and manage maintenance work orders. All these systems were separate and not integrated, meaning that the system’s user persona could only see the data from their own system. Because the data from these systems never merged, the Maintenance tech could not use process data to generate maintenance orders, and the Quality engineer could not see the process instrumentation when bursts of defects were created.

Over time, these teams recognized the value in having cross-team data to do their job more effectively, so they decided to integrate the different systems with point-to-point integrations. The SCADA was integrated with the Quality database, which was integrated with the CMMS/ERP system.

However, as the integrations were built, the teams discovered there was not usually just one Quality database; there were separate databases for each stage of each line. Some were put in place 12 years ago, logging data to a CSV file. Others had a local database. And still others reported to the central instance of Microsoft SQL Server. In the Asset Maintenance department, some of the machines only had a local HMI, while others were managed through the central SCADA. The machines with Rockwell PLCs had symbolic addressing, but many old PLCs with memory-based addressing required a map to understand them.

These challenges are exactly what has driven demand for a UNS. With a UNS, users can integrate each data source into a standardized and logical namespace so any system or person who needs industrial data can easily identify and select the data they need. The challenge in building a UNS is that data from multiple sources is not standardized. In some cases, the required context may be stored in a third-party system, and the source systems may not communicate over MQTT.

Enter Industrial DataOps.

Using the right Industrial DataOps solution, users can consume the source OPC, SQL, REST, and CSV data and then add context within data models to make the payloads usable for all data consumers. A DataOps solution should be able to publish to an MQTT broker (embedded or third party), and also sit on the other side of the UNS, so if the Quality engineer wants data in a more familiar MySQL database, they can subscribe to the datasets they need and have the data logged to their database.

Frequently Asked Questions

Are all my defined models the components of the UNS?

The UNS is the payloads (models) and the organization of the payloads (topic hierarchy).

Is the UNS standard or actually proprietary?

No two production lines or manufacturing plants are the same. The UNS typically uses the ISA-95 enterprise hierarchy of Site, Area, Line, Zone, Asset to define the topic namespace. I think of this as more of a logical, widely accepted organizational model than a standard. Beyond that, it is up to the builders to define the data and what standards they want to use.

Is Sparkplug required for a UNS?

When it comes to data standards, I generally don’t recommend Sparkplug because it is overly complex and constraining for the UNS, but I have seen some customers adopt this approach. I recommend using JSON payloads.

How do I use the namespace once I’ve built it?

One thing many people forget is that they are not creating a UNS for its own sake. The goal is to get data into the hands of the people who need it within their company. So, when you define your UNS, you should consider the users of the data, what systems they have and use, and make sure the data is structured and available for them.

For more on this topic, please read the article, “Data models: The key to scaling your unified namespace.”

About the author

This article was written by John Harrington, Chief Product Officer at HighByte, focused on product management, customer and partner success, and company strategy. His areas of responsibility include market research, customer use cases, product priorities, go-to-market, and financial planning.