The Unified Namespace (UNS) demystified - Part 5 on Industrial Data Platforms

Some concepts gain more traction than others, and Unified Namespace (UNS) is one that stands out. Upon popular request: welcome to Part 5 on working with Industrial data.

This is part 5 in our series on Industrial Data Platforms and this one is long overdue (and it’s also a bit more technical) 🙂 In this article we explore the Unified Namespace as a possible design pattern (or even an ‘aspirational state’) when building an Industrial/Operational Data Platform. We want to talk about some myths and make sure you understand that the UNS is not a completely new product you buy off-the-shelf.

Be sure to review the previous parts for essential background information if you are new to our blog: Part 1 (The IT and OT view on Data), Part 2 (Introducing the Operational Data Platform), Part 3 (The need for Better Data), and Part 4 (Breaking the OT Data Barrier: It's the Platform). 

❗ Heads up!
The Unified Namespace is a concept. It is not a product you can just buy off the shelf. Implementing an Operational Data Platform using UNS as a design pattern is more an organizational topic than a technical one. 

Enter: The Unified Namespace (UNS)

Let’s circle back to the definition we already shared in our previous article and see how the UNS can help us achieve the requirements from our envision Operational Data Platform. This definition is based on the work of many in this field and popularized by people like Walker Reynolds. 

A Unified Namespace is
(1) an organized and centralized data broker, 
(2) depicting data in context from your entire business
(3) as it is right now. 

Let’s tackle the 3 parts of this definition one by one:

(1) An Organized and Centralized Data Broker 

• Organized: The UNS is organized in a structured manner, often using hierarchical models such as the ISA-95 model, that reflect the physical and logical structure of the business (e.g., plant, production line, machine). 

• Centralized: The UNS acts as a single, central hub where data from various sources across the enterprise is collected, integrated, and managed. This eliminates the need for point-to-point connections between disparate systems (see also Part 4 in which we described this problem in more detail).

• Data Broker: As a data broker, the UNS orchestrates the flow of data between producers (e.g., sensors, machines, databases) and consumers (e.g., BI tools, applications, users). It ensures that data is available where and when it is needed. The data broker is a publish - subscribe type of system 

(2) Depicting data in context from your entire business

• Data in Context: Data is enriched with context to make it meaningful and actionable. Context can include metadata such as timestamps, machine IDs, location, status, and other relevant attributes.

• Entire Business: The UNS provides a comprehensive view of operations by integrating data from all parts of the business, including production, maintenance, quality, asset management and even typical IT data like ERP orders. This integrated view enables better decision-making and operational efficiency.

(3) As it is right now

• Right now: The UNS reflects the current state of the business by providing real-time data access. This means that data is continuously updated and available instantly, representing the most up-to-date status of operations. 

• As the UNS is a broker holding the current state, it is really important to understand that the broker is not holding any historical data! Historical data can be stored in an historian or database which is just one of the applications consuming data from the UNS. 

If we put everything together, we get this diagram:

The Unified Namespace (UNS) with its components: Data sources, Data Broker, Data Storage and Applications. Source: IT/OT Insider.

Components in a Unified Namespace architecture

➡️ (Left - light blue) Data Sources

The left section of the diagram shows various Data Sources that feed into the platform, for example: 

• Cloud (L5) Data: Data from IIoT devices and other cloud-based sources,

• Engineering & GIS Data: Includes digital twins and GIS systems, 

• Local Time Series Data Sources: Data from Historians, SCADA systems and PLCs,

• MOM Data: Manufacturing Operations Management data from MES, LIMS, and BMS systems and many more

Different protocols can be used, but the most common ones are OPC, MQTT, Direct Database Connections, REST API’s (for the new and shiny stuff) and more… 

❗ Heads up!
Some people mistakenly think that the MQTT protocol is required to build a Unified Namespace, or even worse that MQTT = UNS. That is absolutely not true. MQTT is just one of the possible protocols out there to integrate data. Having said that, MQTT is definitely a more open protocol compared to OPC, but from a functional point of view OPC UA and MQTT support everything you need. 

Preferably, the different data sources expose their own data models (e.g. following the ISA95 standard) to the central data broker (possible via OPC-UA, MQTT, but also offered by different SCADA/Historian/Engineering vendors). If a data model cannot be exposed, it should still be possible to model it in the data broker. 

➡️ (Mid - dark blue) Central Data Broker

At the core of the diagram is the Central Data Broker, it is here where the data and different data models from all sources get combined. The broker is the central hub to which all applications will connect to get their data or make new data available. 

There are some challenges! One of the most important ones being organizational: who is going to be responsible for the data modeling? Who ‘owns’ the data? A central team? The engineers in a plant? This is where data governance concepts come into play. 

❗ Heads up!
The publish-subscribe model facilitates efficient and scalable data distribution by decoupling data producers (publishers) from consumers (subscribers). Publishers, such as sensors and machines, send data to the central data broker, which organizes it into topics. Subscribers, including BI tools and applications, receive real-time updates by subscribing to these topics. However, the data sources can also be consumers of data (e.g. an MES system wants to consume ERP orders) and an application can also become a publisher (e.g. the result of a machine learning model is made available to other applications via the UNS).

Here is an analogy from our daily lives:
You could see the central data broker as a social media platform. On this platform, users (publishers) post updates (data) about various topics, such as news, sports, or personal activities. Other users (subscribers) follow these topics to receive updates in real-time. Just like you don't need to know every person posting updates to get the latest news on your favorite sports team, in the UNS, data consumers (subscribers) automatically receive the relevant information from data sources (publishers) without needing direct connections. 

➡️ (Right - green) Applications 

On the right side, the diagram lists various Applications that consume the data from the platform, these applications are used by the Users of the platform. This is where we see the scaling possibilities in action! No more interface spaghetti, but structured ways of grabbing whatever information we need. With context! 

➡️ (Right - red) Data Storage

As we mentioned before, storing data is not a part of the core functionality of a data broker. But we obviously want that as well! Your data store is in essence also just an application consuming data from the broker and making that data available again to the platform. Different options are available, both on-premise and in the cloud (or even in hybrid forms). 

One of the main questions is what data we will be storing? Raw? Cleaned? Validated? This is where the “medallion architecture” comes into play! Data stores are tiered into 3 levels:

• Bronze: Raw data (as it comes in, for time series data you need a platform which is able to handle sensor data at scale),

• Silver: Cleaned data (for sensor data, you still need a platform which is time series native but you are now storing cleaned data only).

• Gold: Prepared data ready for analysis (comparable to a data warehouse, a concept we introduced in part 1) .

I discussed this concept earlier this year with Bert Baeck (CEO and co-founder at Timeseer.AI) in this 4 minute video: 

❗ Heads up!
The UNS is not a replacement for your current data historians or databases. It connects all the dots, but does not provide (long term) storage. 

Quick Start Guide 

Introducing a Data Platform can seem daunting, but with a structured approach, you can begin to realize its benefits. Here's a step-by-step guide to help you:

1. Define The Objectives

   1. Define Your Why: Understand what you aim to achieve. Common goals include improving real-time decision-making, enabling predictive maintenance, and enhancing operational efficiency (revise our article “why your why matters” for more inspiration).

   2. Identify Users and their Use Cases: Select initial use cases that will benefit most from real-time data integration, such as monitoring production lines or optimizing energy usage. Make sure to involve the users as well as part of your change process. 

   3. KEEP IT SIMPLE ! 

2. Assess Your Current State

   1. Inventorize Data Sources: Identify all the data sources within your organization, including sensors, machines, SCADA systems, MES, and other IIoT devices.

   2. Evaluate Connectivity: Determine the existing protocols and methods used for data communication (e.g., MQTT, OPC UA, APIs).

   3. KEEP IT SIMPLE ! 

3. Choose the Right Tools

   1. Select a Central Data Broker: Choose a data broker that supports your communication protocols and scales with your needs. 

   2. Data Storage Solutions: Decide on data storage technologies for raw, cleaned, and processed data. Remember: there is no one-size-fits all, the decision on which data broker and store you need depends on your use cases, but also your already existing infrastructure.

   3. KEEP IT SIMPLE ! 

4. Start small, but simply start

   1. Choose your first data sources and first applications. Start with simple applications that provide quick wins, like real-time monitoring dashboards. But make sure you develop something from head to tail such that you hit many stages in the process. 

   2. KEEP IT SIMPLE ! 

5. Iterate, Adapt & Scale

   1. Collect Feedback: Gather feedback from users of your initial applications to understand their needs and challenges.

   2. Expand Use Cases: Gradually expand by adding new data sources and applications. Each new use case should build on the existing infrastructure.

   3. Optimize and Improve: Continuously optimize your setup based on feedback and performance metrics. Ensure that the system remains scalable and secure.

Prerequisite: Governance and Data Ownership

It is not ‘sexy’, we know. But governance is actually a decisive part of the platform/broker decision. Without good governance there is nothing to scale with. You will end up making your systems spaghetti even bigger. 

(Having a mandate and buy-in from your stakeholders is equally important!)

We are looking for your data platform story! 

🎉Do you have a Data Platform story to share?  We would love to have you on the podcast or (if you prefer written only) write down your case study! Let me know via david@itotinsider.com . 

Further Reading

We have organized our 30+ articles in three categories: Organization, Change, and Technology. Make sure to check them out!

Acknowledgements 

Special thanks to Ivo Everts, Sr. Strategic Architect at Databricks for his time and valuable input. 

Looking for an image to share?