The Unified Namespace (UNS) explained
Bridging IT and OTThe Unified Namespace (UNS) is not a product you can buy off the shelf—it’s a design pattern. At its core, a UNS is a centralized data structure that organizes and contextualizes real-time data from across an entire business ecosystem. It brings together data from various sources, such as machines, sensors, ERP systems, and databases, and makes it available in context and real-time. Think of it as an aspirational state for how data should be structured within an industrial organization.
This concept is becoming increasingly essential in modern industrial settings, where data from operational technology (OT) and information technology (IT) systems often remain siloed, making it difficult to extract meaningful insights. A unified namespace helps break these silos, enabling better decision-making and improving overall efficiency.
David explains: Understanding the UNS in just 20 minutes
Why Does UNS Matter?
In today’s world, businesses are swimming in data—tons of it. However, most of this data is often isolated in separate systems, which makes it hard to transform it into useful, actionable information. The issue isn’t that we lack data or advanced algorithms—it’s that the data is disorganized, inaccessible, or both.
For instance, projects like predictive maintenance often fail because technicians waste too much time manually sifting through spreadsheets. AI initiatives stall, not because of weak algorithms, but due to messy, uncontextualized data. By implementing a UNS, companies can access clean, organized data across applications in real time, allowing for streamlined decision-making and improved data-driven outcomes.
Breaking It Down: The Core Components of a UNS
A Unified Namespace organizes data in three fundamental ways:
Contextualization:
Imagine a manufacturing plant generating thousands of data points per second from various sensors. To make sense of this, you need to contextualize the data. A UNS places data in the context of the business—whether it’s understanding which machine the data belongs to, what product is being produced, or what batch is currently running. This contextualized information gives actionable insights, such as correlating sensor readings with production outputs.
Real-Time Access:
Unlike traditional systems that rely on outdated reports or batch processing, a UNS provides real-time insights into what is happening across the enterprise at any given moment. This means that whether you’re in production, management, or IT, you have access to the most up-to-date data, enabling quick and accurate decisions.
Data Organization:
The UNS doesn’t just dump data into a lake, where it risks becoming a swamp of unstructured information. Instead, it structures the data according to models like ISA-95, which reflect the hierarchy of your business—from the enterprise level down to individual machines on the shop floor.
Challenges to Implementing a UNS
Despite its potential, creating a UNS isn’t as simple as flicking a switch. The process involves substantial modeling—building templates and structures that can scale with the business. Moreover, dealing with data quality is critical. In the OT world, data quality can be harder to define compared to IT, as discrepancies are not always immediately apparent.
Still, once the UNS is in place, it can transform the way data is handled. It’s worth noting that one of the biggest hurdles companies face is organizational alignment. For a UNS to succeed, teams from across IT, OT, and business units must collaborate effectively. Without the right alignment, even the best-designed systems can fall short.
Here is the full Transcript of David’s video:
I’m going to explain the Unified Namespace, or UNS for short. It’s a concept that’s been around for a while but is gaining quite a bit of traction right now. I’ll talk about the concept, but more importantly, I’m going to share some of my personal experiences with you.
I’m David. I worked in the chemical industry for 12 years as an end user. Today, I manage analytics for industry, which is an IT/OT solution provider—that’s my day job. In addition to that, I also write for the IT/OT Insider. In my day job at Analytics for Industry, I mostly work with food and beverage customers and critical infrastructure, among other verticals. Through IT/OT Insider, I’m exposed to all kinds of sectors worldwide, from both an end-user perspective and a technology provider perspective. That exposure gives me some great insights.
So, first things first—the Unified Namespace is not a product you can buy off the shelf. It’s a concept, and you should think of it as an aspirational state—something you want to achieve when building your operational data platform. But what is it? And do you need one? Consider this: you have machines, sensors, databases, and ERP systems, all generating tons of data, often in silos. It’s hard to make sense of it and turn it into something useful.
For example, predictive maintenance is difficult because technicians waste time digging through Excel sheets. AI projects fail, not because of a lack of algorithms, but because the data isn’t well organized. If you want to build a data-driven organization, you need fast, secure, and contextual access to your data across all applications.
Instead of reinventing the wheel for every data use case, you want to invest in a data platform. You don’t just want to throw your data into a data lake, which can quickly become a data swamp if you’re not careful. You need a structured operational data platform built to work with manufacturing sensor IoT data. What does it mean to work with sensor data? First of all, we’re obviously talking about time-series data. Time-series data flows in at varying rates—sometimes fast, sometimes slow. You might be dealing with tens of thousands of sensors, or even more. The scale isn’t the most important factor; what matters is how your time-series data looks, because it flows in as it comes. This means that, to work with that time-series data in applications further along the line—whether it’s downloading into Excel, integrating with Power BI, or running Python scripts—you’ll need to interpolate the data at scale, which adds complexity.
Storing time-series data is something many platforms can handle. What’s more important is adding a contextualization layer—understanding the context of the manufacturing process, the infrastructure, and the assets involved. This means understanding the physical assets, production lines, and everything that goes along with them. You need to know what role each asset plays, what data points are associated with them, and the broader production context, such as what batch is running, which operator is working, and what product is being made.
And, of course, you have to manage data quality because garbage in is garbage out. Data quality in the sensor world is different from the IT world, and establishing when data is correct is harder.
As I said at the start, the Unified Namespace, or UNS, is a design pattern—it’s not a product. The concept helps you organize your data into an operational data platform. So, let’s start with a definition: what is a UNS? A Unified Namespace, in my understanding, is an organized and centralized data broker that depicts data in context from across your entire business—not just from one line or silo, but from the entire business as it is right now. It provides real-time insights.
The key points are context and organization. Your data should be organized, typically following models like ISO 95, which reflects the hierarchy of your business. This could be a plant, a production line, or even down to a specific machine.
Beyond organization, you also need context to go alongside your sensor data. You want to easily find out what product was produced, what maintenance actions were taken, and even the results of quality tests in the lab. You should be able to overlay these contexts on top of your sensor data and allow applications to extract this context along with the sensor data.
For example, “Give me the temperature profile of that batch” or “Give me the average steam production over the last 100 CIP cleaning-in-place cycles.” You want that context to be readily available to everyone who needs it. In my experience, a major barrier to data-driven projects is the lack of readily available context. I’ve seen up to 70-80% of the time spent on data-driven projects go towards finding, contextualizing, and cleaning the data.
The third point is real-time. A Unified Namespace shows you what’s happening right now, potentially across the entire organization, without outdated reports or delays—just instant access to your latest data.
But there are challenges. First, organizing data doesn’t just happen. You still need to model it. Yes, templates can help, but someone has to build those templates. And who decides what the perfect model is? This is all part of data governance. Personally, I prefer a use-case-based approach rather than trying to build the perfect data model from the start. Start with a problem, like predictive maintenance, and build a namespace for that use case. You might end up with multiple models or namespaces coexisting—and that’s perfectly fine.
Another challenge is storing your data. It’s not just about accessing real-time data; you also need to store historical data. The UNS gives you access to real-time data, but you still need a way to store the data, whether in a traditional historian or a more modern approach. You might end up with a hybrid architecture where you have both local and cloud components working together.
When storing data, you also need to decide whether you’ll store raw data, clean data, validated data, or all three. This is where architectures like the medallion or Delta Lake architecture come in, with tiers for raw, clean, and prepared data.
From an IT perspective, it’s important not to build everything from scratch. Use the foundations you already have—if you have OPC, you don’t need to replace it with MQTT, for example.
So, is the Unified Namespace the solution for all your data-sharing problems? No. It’s a very good concept to build your vision around, but it’s not a solution on its own. It’s a way to think about making data available in a centralized way for all users and applications.