What is a Unified Namespace (UNS)?

The Unified Namespace — UNS for short — describes a shared, hierarchically named data space that holds the current value of every relevant data point in a company. Sources publish into it, consumers subscribe from it. Neither side knows the other; they only know the name of the information.

The term comes from practice, not from a standard — it was coined and popularized mainly in US automation consulting. It describes an architectural pattern: event-driven rather than poll-driven, named rather than hard-wired, one source of truth rather than many copies.

The namespace always holds the current value: whoever queries it gets the value from just now, not the history. This closeness to real time is the real gain over nightly exports — and it’s why sensors and IIoT devices can connect without detouring through the supervisory level: they publish to their place in the structure and are then available to every authorized system.

In the classic pyramid, each level passes data to the next: field level, control, SCADA, MES, ERP. The model has carried automation for decades — and it has three traits that get in the way today:

• Context gets lost along the way. What each level condenses anew can no longer be traced back to its source further up.
• Every level is a project. A new analysis requires changes in several systems — and across several areas of responsibility.
• The path is one-way. Little flows back down, and when it does, it’s a special-case route.

The UNS breaks up this sequence. It doesn’t replace the levels — control and MES stay what they are — but it takes away their role as data courier.

There’s also a second problem that only shows up at scale. Where systems are coupled point to point, the number of connections grows quadratically: six directly connected systems produce fifteen links, ten produce forty-five. Through a shared namespace, it’s six or ten connections respectively. That’s exactly where the pattern’s scalability comes from — and why the effort really pays off from the second site onward. More on interoperability

The pyramid organizes devices by level. The namespace organizes data by meaning.

The structure follows the company’s real-world order, not the order of its software. A hierarchy along site, area, line and equipment has proven effective — in ISA-95 terms, that corresponds to the levels Enterprise, Site, Area, Work Center (roughly a line) and Work Unit.

This structure isn’t arbitrary: it follows ISA-95, listed internationally as IEC 62264-1 (Enterprise-control system integration — Part 1: Models and terminology). Following it means speaking the same language as MES and ERP vendors.

The full path of a value then looks something like:

group/plant-north/hall-2/line-3/filler/temperature

Alongside it are the other values of the same unit:

group/plant-north/hall-2/line-3/filler/pressure group/plant-north/hall-2/line-3/filler/status group/plant-north/hall-2/line-3/filler/order

A consumer that needs all temperatures from hall 2 subscribes to group/plant-north/hall-2/# and filters — it doesn’t need to know which equipment is there or who supplies it. When a new line is added, it publishes under the same pattern and is immediately visible, without changing any existing system.

Three rules have proven useful for the naming convention: lowercase throughout, no special characters or spaces, and no technology in the name. filler describes the equipment and survives a controller swap; plc-3-db12-dw4 describes the wiring and dies with it.

In the end, what matters isn’t the exact convention itself, but that it’s defined once and then used consistently everywhere.

The UNS is an organizing principle, but it needs a place where messages converge. That place is a broker: it accepts whatever sources publish and delivers it to everyone who has subscribed to it. Sources and consumers never know each other directly — they only know the broker and the name of the information.

• MQTT is the most common transport for this: lightweight, publish-subscribe based, designed for unreliable connections. However, it only describes how a message travels, not what’s in it.
• Sparkplug B closes this gap. The Eclipse Foundation specification (currently version 3.0) gives MQTT messages a fixed structure for states, measurements and liveness signals — and defines how a consumer can tell that a source has gone offline. Without this convention, nobody knows whether a value is stale or the equipment is down.
• OPC UA (IEC 62541) brings its own information model and is often used alongside it: OPC UA close to the machine, MQTT with Sparkplug for broad distribution.

The broker itself is interchangeable. What isn’t interchangeable is the naming built on top of it — which is why the choice of software is the smaller decision.

1. Define the naming

   Structure and naming convention are agreed on as binding — for all plants, not just the first. It’s paperwork, and the most important hour of the whole project.

2. Connect the sources

   Controllers, sensors, databases and legacy systems publish into the namespace — via standard connectors rather than custom builds.

3. Add context

   Master data joins the live values: setpoints, orders, equipment attributes. Only then does the namespace become readable for applications that don’t know the equipment itself.

4. Connect consumers

   Dashboards, ERP, historian and analytics models subscribe to what they need. New consumers can be added without any source noticing.

• Not a product. There’s no software whose installation creates a UNS. There is software that supports one well or poorly.
• Not a data store. The UNS holds the current value. History belongs in a historian or a data lake that reads from the namespace.
• Not a replacement for MES or ERP. These systems remain authoritative for their processes. The UNS is where they meet.
• Not a protocol. MQTT is common, so is OPC UA; both are transport mechanisms, not the organizing principle itself.

• Naming after software instead of the plant. Derive the structure from an existing system, and you inherit its quirks — and its lifespan.
• Trying to do everything at once. A namespace starts with one area and grows. Attempts to model every source upfront rarely make it into production.
• Unclear ownership. If nobody owns the layer, it doesn’t get operated, only patched up.
• No operational visibility. A namespace where a source silently fails delivers false confidence — not missing data, but stale data.

pronubes is the platform between the shop floor and IT. It captures production data securely, normalizes it and brings it into a shared structure — and feeds decisions back into the processes as setpoints.

• pronubes Zones maps sites, areas, systems and data flows hierarchically — the naming is maintained, not just documented.
• pronubes Edge translates between OPC UA, MQTT, REST, SQL and file formats, and buffers data when a connection drops.
• pronubes Insights shows which source is delivering, which has gone quiet, and how old a value is.

That keeps the namespace from staying just a diagram — it becomes an operated part of the landscape. More about the platform