Unified namespace explained: one structure every plant system publishes to, how the topic tree follows ISA-95, and when a UNS is worth building
What a unified namespace is, how its topic tree follows the ISA-95 equipment hierarchy, the broker, gateways, payloads, publishers and consumers that make one up, how it compares with point to point integration, MQTT and Sparkplug, where it fits and where it does not, and what to settle before building one. With a drawing of a topic tree.
Key takeaways
- A unified namespace, or UNS, is a single shared structure where every system publishes its current data and any system can subscribe to it, usually built on an MQTT broker with topics named after the ISA-95 equipment hierarchy.
- It replaces many point to point interfaces with one connection per system. A new consumer subscribes to the topics it needs and no publisher changes.
- The hard part is not the broker. It is agreeing the topic structure, the payload format, and which system is the source for each value, then keeping them that way.
- A UNS holds current state, not history. A historian still subscribes and stores the data, and control must never depend on the broker being up.
- It pays off when many systems need the same data. For a site with two systems to connect, a direct interface is simpler.
A site wants conveyor run hours from the PLCs in the CMMS, the same hours in the MES for availability, the belt speed in a new analytics tool, and the state of each conveyor on a dashboard for the morning meeting. Each request becomes another interface: PLC to historian, historian to CMMS, historian to MES, historian to analytics, MES to dashboard. Two years later nobody can draw the interfaces, and adding one more takes a project.
This guide explains the unified namespace: what it is, how the topic structure follows ISA-95, the parts of a UNS, how it compares with point to point integration, where it fits and where it does not, and what to settle before building one. It builds on the guides to system integration, plant protocols and ISA-95. The specifications named are reference points.
One structure, every system
In a unified namespace every system connects once, to a broker, and data is organised in a single tree of topics. Systems that own data publish it to their topics. Systems that need data subscribe to the topics they want. The broker passes each change to every subscriber, and with retained messages it also holds the latest value of each topic for anyone who connects later.
The tree is the part people see. Topics are usually named after the ISA-95 equipment hierarchy, enterprise, site, area, line or unit, then the value, so someone looking for the belt speed of a conveyor can find it by browsing to the conveyor. That shared structure, more than the protocol, is what makes it a namespace rather than a message bus.
The broker is the easy part. The topic structure, the payload format and who owns each value are the project.
The parts of a UNS
A working unified namespace has a handful of parts. The broker and gateways are products. The topic structure, the payload format and the rule that each topic has one publisher are agreements, and they decide whether the namespace stays clean.
| Part | What it does | What to note |
|---|---|---|
| Broker | The MQTT server every system connects to. With retained messages it holds the latest value of each topic | Clustered for availability, inside the industrial DMZ or the site network |
| Topic structure | The agreed naming of every topic, usually enterprise, site, area, line or unit, then the value | Decided before anything publishes, owned by one person or team |
| Edge gateways | Read PLCs and other devices over their own protocols and publish to the broker | One per area or cell, so a device change touches one gateway |
| Payload format | What each message carries: value, timestamp, quality and units | Sparkplug B, or a documented JSON format applied everywhere |
| Publishers | Control systems, MES, CMMS, the laboratory and others that own data | Each topic has one publisher, the system of record for it |
| Consumers | Historian, dashboards, analytics, MES and anything that needs current values | Subscribe to the topics they need. Adding one changes no publisher |
Against point to point
The case for a UNS is the arithmetic of interfaces. With point to point integration the number of possible connections grows roughly with the square of the number of systems, and each one is built, documented and maintained on its own. With a namespace each system connects once. The cost is a central broker that everything depends on, which has to be built to stay up.
| Aspect | Point to point | Unified namespace |
|---|---|---|
| Connections | One per pair of systems that exchange data, growing roughly with the square of the number of systems | One per system, to the broker |
| Adding a consumer | A new interface to every system it needs data from | Subscribe to the topics, no change to publishers |
| Finding data | Knowing which system holds it and how to ask | Browsing the topic tree |
| Current state | Each system holds its own copy, which may differ | The broker holds the latest value of every topic published as retained |
| History | In the historian or each system | Not held by the broker. A historian subscribes and stores it |
| Failure | One interface down affects one pair | The broker down affects everything, so it must be resilient |
MQTT and Sparkplug
Most unified namespaces run on MQTT, a lightweight publish and subscribe protocol designed for unreliable networks, which suits plant data. MQTT itself says nothing about what a topic is called or what a message contains. Sparkplug, an Eclipse Foundation specification published as ISO/IEC 20237, fills that gap for device data with a defined topic structure, a compact payload and birth and death messages that tell subscribers when a device comes and goes. OPC UA also supports publish and subscribe, and the protocols guide compares the options.
Where it fits
A unified namespace suits sites where many systems need the same plant data, where new consumers such as analytics and dashboards keep arriving, and where the integration estate has grown past what anyone can draw. It suits less well where there are two or three systems to connect, where the data is mostly transactional, such as orders and work orders, which suit request and reply interfaces, or where nobody will own the topic structure.
It does not replace the historian, which still subscribes and stores history, or the control network, because control must never depend on the broker. It sits in the plant network design under the zones and conduits of IEC 62443, not exposed to everything.
Before building one
Most of what makes a unified namespace work is decided before any software is installed. A short list of questions, answered first, avoids the common failure: a broker full of topics nobody can interpret.
| Question | Why it matters |
|---|---|
| What problem does it solve? | A UNS pays off when many systems need the same data. For two systems, a direct interface is simpler |
| Who owns the topic structure? | Without an owner, names drift and the tree becomes as messy as the systems it replaced |
| What goes in a payload? | Timestamp, quality and units with every value, in one documented format |
| Which system is the source for each topic? | Two systems publishing the same value is the UNS version of two versions of the truth |
| Where does the broker sit? | In the network design, with the zones and conduits of IEC 62443. A broker reachable from everywhere is a target |
| What happens when it is down? | Control must not depend on it. Consumers need to cope with stale data, and the broker needs redundancy |
Where unified namespaces go wrong
- Topics named by whoever set up each gateway, so the tree is inconsistent from the first week.
- Payloads without timestamps, quality or units, so consumers guess.
- Two systems publishing the same value under different topics.
- The broker treated as a database, with history expected from it.
- A single broker with no redundancy, so one failure stops every consumer.
- Control logic that waits for a value through the broker.
- A broker reachable from the business network without the zones and conduits a plant system needs.
Common questions
What is a unified namespace?
A unified namespace is an architecture where every system on a site publishes its data to one shared, structured namespace, and any system that needs the data subscribes to it. It is usually built on an MQTT broker, with topics organised by enterprise, site, area, line or unit and value, following the ISA-95 equipment hierarchy. The aim is one place to find the current state of the operation, instead of data scattered across systems connected point to point.
Is a unified namespace the same as MQTT?
No. MQTT is the publish and subscribe protocol most unified namespaces are built on, and a broker is the server at the centre. The unified namespace is the architecture and the agreements on top: the topic structure, the payload format, which system publishes each value, and the rule that systems connect through the namespace rather than to each other. A site can run MQTT without having a unified namespace.
What is the difference between a unified namespace and a data historian?
A unified namespace carries the current value of each piece of data and passes changes to subscribers as they happen. A historian stores values over time and answers questions about the past. They work together: the historian subscribes to the namespace and records what it needs. A broker is not a database and should not be used as one.
What is Sparkplug B?
Sparkplug is a specification from the Eclipse Foundation that defines a topic structure, a payload format and state management for industrial data over MQTT, so devices and applications can understand each other without custom mapping. Version 3.0 has been published as ISO/IEC 20237. Many unified namespaces use Sparkplug for device data, and some use a documented JSON format instead.
Does a unified namespace replace ISA-95?
No, it usually builds on it. ISA-95 provides the equipment hierarchy that names the topics, and the information models that describe what passes between operations and business systems. The unified namespace is a way of moving that data. Some people describe the UNS as an alternative to the ISA-95 levels, meaning it lets systems at any level reach data directly. The levels still matter for security, because they set which systems should be allowed to talk.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
Related case studies and tools
- Bridging OT and IT with custom software (case study)
- SQL data platform and ETL optimisation (case study)
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.