What is a Unified Namespace?
A Unified Namespace (UNS) is an architectural pattern in which every system in an organisation publishes its current state to one central, hierarchically organised data hub, usually an MQTT broker, to which any other application can subscribe. Every data point, event or status is assigned a unique location in the namespace, comparable to a file structure but for live data. The result is a single source of truth for the current state of the plant or business, instead of a tangle of point-to-point interfaces. That makes the UNS a key building block for OT convergence and Industry 4.0.
🧠 Where does the term Unified Namespace come from?
The term was popularised by Walker Reynolds, an IIoT architect and founder of 4.0 Solutions. He describes designing the first unified namespace for a salt mine in upstate New York between 2003 and 2005. Through his training courses and videos the concept was later picked up widely by vendors such as HiveMQ, HighByte and Inductive Automation.
Reynolds lists several characteristics that set a UNS apart from an ordinary data bus:
- Single source of truth - there is one place where the current state of the business lives
- Structured like the business - the hierarchy follows sites, areas, lines and machines, not the systems that happen to supply data
- Edge-driven - data is published as close to the source as possible, by a PLC, edge device or gateway
- Report by exception - a source only publishes when a value changes, which saves bandwidth
- Lightweight and open - based on open protocols and vendor-agnostic
A UNS is therefore not a product you buy, but a way of organising data. In principle it holds the current state. Historical data belongs in a historian, time series database or data lake that subscribes to the UNS.
🔄 How does it differ from traditional OT integration?
In the classic automation pyramid and the Purdue Model, data travels upwards layer by layer: from PLC to SCADA, to MES and finally to ERP. Every new application needs its own interface. With n systems that all need to talk to each other, the number of interfaces grows to n·(n−1)/2: 45 for 10 systems, 190 for 20.
| Traditional model | Unified Namespace model |
|---|---|
| Point-to-point connections | A single publish/subscribe layer with a central topic structure (hub-and-spoke) |
| Pull: systems poll for data periodically | Event-driven: sources publish on change |
| Ad-hoc data flows and per-system naming | Standardised hierarchy and naming |
| A new consumer means a new interface at the source | A new consumer subscribes without touching the source |
| Separate IT and OT silos | OT convergence through a shared namespace |
A UNS does not replace systems, but makes them accessible and interoperable through a shared data model. SCADA, MES and ERP keep doing their own jobs.
🔧 What are the components of a UNS?
| Component | Role in the UNS |
|---|---|
| MQTT broker (e.g. HiveMQ, EMQX, Mosquitto) | Central publish/subscribe engine that distributes messages to subscribers |
| SCADA connections (e.g. Ignition) | Publish statuses and alarms, receive setpoints via the UNS |
| Edge devices and gateways | Translate field protocols such as Modbus, S7 or OPC UA to MQTT and publish measurements |
| MES and ERP | Subscribe to events and publish orders, recipes and schedules |
| Historian and analytics | Subscribe to UNS data for storage, reporting and analysis |
| Contextualisation layer (e.g. HighByte, Node-RED) | Adds units, asset names and order context; see Industrial DataOps |
MQTT is the de facto transport protocol. Version 3.1.1 became an OASIS standard in October 2014 and ISO/IEC 20922 in 2016; MQTT 5.0 followed in March 2019. By default a broker listens on TCP port 1883, or 8883 with TLS. Three MQTT features are essential for a UNS:
- Retained messages - the broker keeps the last value per topic, so a new subscriber immediately receives the current state
- QoS levels 0, 1 and 2 - from at most once to exactly once, chosen per data stream
- Last Will and Testament - the broker automatically announces when a source drops off unexpectedly
🗂️ How do you design the topic structure?
Most UNS designs follow the equipment hierarchy of ISA-95 (internationally IEC 62264): enterprise → site → area → work centre → work unit. In practice the two lowest levels are usually called line (production line) and cell (machine or work cell). A topic then looks like this:
acme/rotterdam/packaging/line3/filler/status
Below that, fixed namespaces are often used for the type of data, such as edge for raw source
data, metrics for calculated KPIs or erp for order information.
There is also Sparkplug, an Eclipse Foundation specification that defines topic names, the message format
(Protobuf) and state management for edge nodes. Sparkplug 3.0 has been published as ISO/IEC 20237 since
2023. Sparkplug topics have a fixed, technical structure (spBv1.0/group/message_type/edge_node/device). That is why many architectures combine a Sparkplug
layer for connectivity with a separate, ISA-95-structured UNS for contextualised data.
| Aspect | Plain MQTT (ISA-95 topics) | MQTT Sparkplug B |
|---|---|---|
| Topic structure | Free to choose, mirrors the business | Fixed: spBv1.0/... |
| Payload | Usually JSON, human-readable | Protobuf, compact and typed |
| Source state | Handled yourself (e.g. retained and LWT) | Built in via birth and death messages |
| Readability for IT | High | Lower, requires decoding |
| Typical use | Contextualised business data | Connectivity between edge and SCADA |
🏭 What is a UNS used for in practice?
| Application | How the UNS helps |
|---|---|
| Batch production | Real-time sharing of batch data between PLC, MES and LIMS |
| Predictive maintenance | Sensors publish vibration data; an AI model subscribes and predicts failures |
| Energy management | Real-time energy consumption shared with dashboards and reports |
| KPI monitoring | SCADA publishes live status; Power BI or an OEE dashboard subscribes |
| IT/OT data lake | Historian and analytics tools collect via a single uniform data layer |
| Digital twin | The twin reads the current state straight from the namespace |
For very large data volumes or long-term retention of message streams, the MQTT broker is often bridged to Apache Kafka, which is better suited to replaying historical events.
🧭 How do you implement a UNS step by step?
- Start with a use case - for example OEE for one line or energy consumption per area. A UNS that does not solve a problem becomes a data graveyard.
- Design the hierarchy - fix the ISA-95 levels and naming rules: lowercase, no spaces, optionally a version in the topic.
- Choose the broker and architecture - a cluster for high availability, possibly a local broker per site that bridges to a central broker.
- Connect the sources at the edge - with gateways that translate existing protocols; in brownfield plants the PLC logic stays untouched.
- Add context - units, asset names, order numbers and quality status, so data is usable without explanation.
- Secure it from day one - see the next section.
- Connect consumers and measure - historian, dashboards and MES; after a few weeks, evaluate whether the use case delivers the intended result.
🔐 How do you secure a Unified Namespace?
A UNS makes data widely accessible, and that enlarges the attack surface. A broker that holds all process data and can pass on setpoints is an attractive target for attackers, so security has to be designed in.
- Authentication and authorisation - every client logs in with a certificate or strong credentials; ACLs per topic following least privilege
- Encryption - TLS on port 8883, never unencrypted traffic across network boundaries
-
Segmentation of sensitive
topics - for example
acme/rotterdam/+/+/+/safety/#read-only; safety functions must never depend on the UNS - Restrict write access - only designated systems may publish setpoints, with validation on the PLC side
- Network placement - brokers on the IT/OT boundary usually sit in an IDMZ; edge devices open outbound connections, so no inbound ports into the OT zone need to be opened
- Audit trail - log who publishes or subscribes to what and feed it into security monitoring
- Standards - design according to Security by Design and the zones and conduits model of IEC 62443
For Dutch organisations in scope of the Cybersecurity Act (the Dutch transposition of NIS2, in force since 15 August 2026), a UNS broker belongs in the risk assessment and the asset register. It is a central junction between IT and OT.
❓ Frequently asked questions
Is a Unified Namespace the same as MQTT?
No, a Unified Namespace is an architectural pattern and MQTT is a protocol. MQTT is, however, the most common transport for a UNS, because it is lightweight, supports publish/subscribe and offers retained messages. A UNS can in principle also be built with other technology, such as OPC UA PubSub or Kafka.
Does a Unified Namespace store historical data?
A Unified Namespace in principle holds only the current state of each data point. For historical data, a historian, time series database or data lake subscribes to the UNS and stores the values itself. This keeps the broker lightweight and fast.
Do I need Sparkplug B for a Unified Namespace?
Sparkplug B is not required for a Unified Namespace. It provides fixed conventions for topics, payloads and the state of edge nodes, which makes interoperability between vendors easier. Many organisations combine Sparkplug for connectivity with an ISA-95 topic structure for contextualised data.
Does a Unified Namespace replace the Purdue Model?
A Unified Namespace does not replace the Purdue Model as a security model. The UNS changes how data flows, from layer-by-layer to hub-and-spoke, but network zones, firewalls and an IDMZ are still needed. Many architectures place brokers per zone and link them through controlled connections.
What does a Unified Namespace cost?
The cost of a Unified Namespace depends mainly on the chosen broker, the number of edge gateways and the effort needed to design the hierarchy. Open-source brokers such as Mosquitto are free, while commercial brokers with clustering and management come with licence fees. Most of the work is usually in connecting and contextualising existing sources.
Is a Unified Namespace suitable for existing plants?
A Unified Namespace works well in existing plants, because edge gateways translate existing protocols to MQTT without changing the PLC programs. You can start per line or per area and extend the namespace step by step.
📌 In summary
A Unified Namespace is the modern backbone of real-time industrial data sharing: one central place, structured like the business, where every system publishes its current state. With MQTT as transport, an ISA-95 hierarchy as structure and security according to IEC 62443, a UNS provides scalable, event-driven access to all information, without the proliferation of hundreds of point-to-point connections.