What Is a Unified Namespace (UNS)?

The Unified Namespace (UNS) is a design pattern that standardizes and organizes all industrial data into one central, event-driven architecture. Instead of connecting SCADA, ERP, CMMS, and quality databases through fragile point-to-point integrations, UNS consolidates OT and IT data into a single MQTT-based topic hierarchy with JSON payloads, making every data point accessible to any system or person that needs it.

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

What is a Unified Namespace in manufacturing?

A Unified Namespace (UNS) is a design pattern that consolidates all industrial data from SCADA, ERP, CMMS, and quality systems into a single, standardized MQTT topic hierarchy with JSON payloads. Instead of point-to-point integrations between separate systems, UNS lets any person or system access the data they need from one central namespace, organized typically using the ISA-95 hierarchy of Site, Area, Line, Zone, and Asset.

Why do manufacturers need a Unified Namespace instead of point-to-point integrations?

Point-to-point integrations become unmanageable as manufacturing systems multiply. Separate SCADA, quality databases, and CMMS systems mean maintenance technicians cannot see process data and quality engineers cannot see instrumentation during defect bursts. A UNS eliminates this fragmentation by integrating each data source into a standardized namespace, giving cross-team visibility without building individual connections between every system.

Is Sparkplug required to build a Unified Namespace?

No. According to HighByte Chief Product Officer John Harrington, Sparkplug is not required for a UNS. He generally does not recommend Sparkplug because it is overly complex and constraining for UNS implementations. Instead, he recommends using JSON payloads published to an MQTT broker, which provides more flexibility for defining data models and topic structures.

What is the role of Industrial DataOps in a Unified Namespace?

Industrial DataOps solutions consume source data from OPC, SQL, REST, and CSV systems, then add context within data models to make payloads usable for all consumers. A DataOps solution publishes standardized data to an MQTT broker and can also subscribe on the other side of the UNS, allowing users like quality engineers to receive data in familiar formats such as MySQL databases.

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

For a comprehensive overview of UNS architecture, see What Is a Unified Namespace and How Does It Work in Manufacturing? on IIoT World.

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.