Unified Namespace (UNS): What It Is, Principles and Architecture with MQTT and Sparkplug B

The Unified Namespace (UNS) is an industrial data architecture pattern in which every system in an organisation, on the shop floor and in the business, publishes and consumes its data in a single hierarchical, real-time namespace, normally implemented as a topic tree on an MQTT broker. Instead of connecting every system to every system, everything talks to the namespace: it is the single source of the organisation's current state. This guide develops the concept in depth: definition, principles, structure, technical architecture with MQTT and Sparkplug B, how it differs from a data lake or a historian, and how we implement it with Captia Connect.

What the Unified Namespace is: definition

A working definition: the Unified Namespace is a centralised publish-subscribe structure holding the current state of all business-relevant data, organised in a semantic hierarchy that mirrors the physical and functional structure of the organisation. Three words carry the weight of the definition:

• Unified. One namespace for the whole organisation. The PLC value, the quality result, the meter reading and the work order status live in the same tree, under the same naming convention. There is no silo per department.
• Namespace. What is shared is not a database or an API: it is a hierarchy of names with agreed semantics. Each node in the tree says what the data is and where it lives, and that address stays stable even when the technology underneath changes.
• Current state. The UNS holds the live snapshot of the plant right now. It is not a historical archive: the archive is a consumer that subscribes to the UNS and persists what flows through it.

The term is associated with Walker Reynolds and the Industry 4.0 community that popularised it from the 2010s onwards, but the pattern belongs to no vendor: it is an architectural decision that can be implemented with open components. That neutrality is an essential part of its value.

The problem it solves: point-to-point integration

Without a UNS, every data need is met with a direct integration: the MES reads from the SCADA, the dashboard queries the MES, the ERP receives a nightly CSV from the historian. With a few systems the pattern works; with each new system, the number of possible connections grows combinatorially, and each connection is its own development, with its own format, its own credential and its own way of failing. The architecture literature calls it integration spaghetti.

The UNS reverses the direction of the integrations. Each system connects once, to the namespace, as a producer, a consumer or both. Adding system number twenty costs one connection, not nineteen. And because producers and consumers do not know each other, replacing one system does not break the rest: the contract is the namespace, not the technology publishing into it.

This same problem, told from the perspective of the project of connecting the plant to corporate systems, is developed in our guide to OT/IT integration with a unified namespace: that piece walks the implementation roadmap; this one goes deep into the concept and its architecture.

The four principles of the UNS

1. The UNS is the single source of current state. Any system that wants to know what is happening asks the namespace, not the machine and not another application. If a value matters to the business, it is published into the UNS; if it is not in the UNS, it does not exist for the rest of the organisation.

2. Event-driven architecture. Data is published when it changes and consumers react when it arrives. There is no polling and there are no scheduled extracts in the small hours: the value travels the moment it is born, and whoever needs it receives it with seconds of latency, not hours.

3. Data is born at the edge and rises normalised. Protocol translation, engineering units, origin timestamps and reading quality are resolved at the edge, once, before publishing. Every consumer sees the same version of the data, with the same semantics.

4. Open, decoupled architecture. The UNS leans on open standards (MQTT as transport, Sparkplug B as semantics, ISA-95 as the reference hierarchy) precisely so that no component is irreplaceable. The broker can be swapped, the gateway can be swapped, and the namespace, which is the real asset, remains.

Structure: the ISA-95 hierarchy as the skeleton

A namespace needs a backbone, and the usual starting point is the ISA-95 equipment hierarchy: enterprise, site, area, line, cell or unit. Signals hang from that physical skeleton and, in parallel branches, the worked-up functional data:

enterprise/site/area/line/machine/signal

acme/valencia/mecanizado/linea-2/cnc-07/husillo/temperatura
acme/valencia/mecanizado/linea-2/cnc-07/estado
acme/valencia/mecanizado/linea-2/oee/turno-actual
acme/valencia/energia/cuadro-general/potencia-activa

The golden rule is that the hierarchy describes what the data is and where it lives, never who consumes it: no branches called erp or dashboard. And the most profitable decision of the whole project is agreeing the naming convention in writing (levels, language, capitalisation, units) before the second machine is connected. Many organisations also separate a raw branch, exactly as the data leaves the gateway, from a functional branch with worked-up indicators such as line status or per-shift OEE, to which business consumers subscribe.

Technical architecture: MQTT and Sparkplug B

The UNS is a pattern, not a product, but its reference implementation rests on two standards that fit together as layers:

MQTT as transport. A publish-subscribe protocol standardised by OASIS, lightweight, tolerant of bad networks and with mechanisms such as the last will to detect dropped clients. Its model of hierarchical topics with wildcards is exactly the shape a namespace needs: subscribing to acme/valencia/mecanizado/# is subscribing to an entire area of the plant. How it compares with OPC UA's client-server approach is covered in OPC UA versus MQTT.

Sparkplug B as semantics. MQTT says nothing about the payload; Sparkplug B, an open specification from the Eclipse Foundation, defines it: a predictable topic structure, typed metrics in an efficient binary format, state management with birth and death certificates, and report by exception. Any consumer knows at all times whether a value is live or stale. We dedicate a full article to the specification: Sparkplug B: what it defines and when to use it.

On top of those two layers, the minimal UNS architecture has three pieces:

• Edge gateways on the plant network, reading each machine in its native protocol, normalising and publishing into the namespace. If the network drops, they store in a persistent local buffer and publish the backlog on return.
• An MQTT broker as the meeting point, on premises, in a private cloud or in a public cloud: edge and consumers connect only to it.
• Subscribed consumers: historian, dashboards, MES, ERP, analytical models. Each listens to the branches it cares about and none knows the producers.

This is also the backbone of a complete plant data architecture; how the UNS fits with the persistence and consumption layers is developed in our guide to the industrial data platform.

UNS versus data lake, historian and ESB

UNS versus data lake. The data lake stores data at rest for later analysis; the UNS distributes current state in motion. They do not compete: the data lake is a natural consumer of the UNS. Confusing them leads to attempting historical analytics against a broker or real-time distribution against a warehouse, and neither works well.

UNS versus historian. The plant data historian persists process time series and serves them for querying. In a UNS architecture it is one more subscriber: it listens to the namespace and records. The UNS keeps no history; it guarantees that whatever history is kept is complete and coherent, because everything travelled through the same channel.

UNS versus ESB or corporate middleware. An enterprise service bus also centralises integrations, but it orchestrates transactions between IT applications with per-pair transformations. The UNS is simpler and more radical: it does not orchestrate, it publishes. Semantics are not negotiated connection by connection; they are fixed once in the namespace, which is what makes it operable by a plant team without a middleware department.

How Captia Connect implements a UNS

Captia Connect is the edge data acquisition layer with which we build this pattern in real plants. Its fit with the UNS is direct:

• Multi-protocol acquisition at the edge. Reading PLCs, sensors, meters and SCADA systems over MQTT, OPC UA, Modbus TCP and Modbus RTU over RS-485, among other protocols, so existing machines take part in the namespace without modification. That is the territory of PLC connectivity and edge ingestion.
• Normalisation at source. Signals are translated into agreed business names and units before publishing, so the namespace receives clean data, not register addresses.
• Buffering and persistence without connectivity. If the link to the broker drops, capture continues and the backlog is published on return, so the upstream history remains complete.
• Secure connectivity and flexible deployment. Secure transmission towards the broker and on-premises, hybrid or cloud deployment depending on the plant.

Upstream of the namespace, Captia.ai consumes that same data for web SCADA, dashboards, rules, alerts and workflows: proof that, with the UNS well built, every new consumer is a subscription rather than an integration project.

Common mistakes when building a UNS

Treating it as a product to buy. Installing a broker does not create a UNS, just as buying shelves does not create a library. The asset is the naming convention and the discipline of publishing everything through the same channel.

Leaving the hierarchy for later. A namespace with improvised names degenerates into the chaos it set out to solve, only inside a broker. The convention is agreed in writing before the second machine is connected.

Publishing raw, unnormalised data. If every consumer has to guess units and scales, the UNS has only moved the problem. Normalisation at the edge is not optional.

Using it as a historical archive. The UNS is current state in motion. History lives in a consumer that persists, not in the broker.

Allowing "provisional" point-to-point integrations. Every direct connector opened "just for now" is debt the namespace will have to absorb later. The discipline is uncomfortable the first week and profitable every year after.

Frequently asked questions about the Unified Namespace

If you are considering building a Unified Namespace in your plant, at Captia Connect we implement exactly this architecture, from MQTT integration and OT/IT integration to the design of the naming hierarchy. The detail of the complete architecture is in our industrial data platform guide.