What Is a Unified Namespace (UNS)? One Source of Truth for Factory Data

In a factory, PLCs, SCADA, historians, MES, ERP and cloud analytics are usually wired to each other one by one. As the number of systems grows, the number of connections grows quickly, and every new application has to be integrated with each existing system again. The Unified Namespace (UNS) is an architectural approach that removes this sprawl by moving the integration to one shared point.

The core idea

In a UNS, systems connect not to each other but to a single central namespace. Producing systems (PLCs, SCADA, MES, sensor gateways) publish into it; consuming systems (dashboards, analytics, ERP, AI) subscribe to the parts they need. Producers do not need to know their consumers, and consumers do not need to know their producers.

The namespace is usually built on an MQTT broker and follows the ISA-95 equipment hierarchy:

acme/istanbul/packaging/line-3/filler-02/temperature

Each level (enterprise, site, area, line, asset, metric) says where the data is and what it belongs to, so the topic path itself carries context.

Why it beats point-to-point integration

• Connections grow linearly: Every system talks only to the namespace; N systems need roughly N connections.
• It is event-driven: Data is published when it changes. You subscribe instead of polling.
• New consumers are easy to add: A new application can subscribe to the namespace without touching the source systems.
• Context is consistent: Data arrives with meaningful names and shared models, so each project does not have to re-interpret it.

What a UNS is not

• It is not a product. It is the combination of an MQTT broker, data models and a well-defined naming scheme.
• It is not a database. A UNS carries the latest state; long-term history needs a historian or a time-series database.
• It is not magic. Without naming discipline, ownership and access control it can quickly turn into a messy topic tree.

How to build one

1. Keep the scope small. Start with one line or site and show one use case (for example downtime tracking) end to end.
2. Define the hierarchy. Document the enterprise–site–area–line–asset structure and naming rules in ISA-95 terms. (Topic naming guide)
3. Model the data. Turn raw tags into asset models with units, timestamps and quality. Templates are how you apply the same model to hundreds of assets.
4. Publish and monitor. Set up a broker, connect producers and define access rules (which client can read or write which branch).
5. Add consumers. Derive dashboards, analytics and ERP connections from the namespace.

Relationship to Sparkplug

Sparkplug B is a specification that standardizes the topic structure, payload format and state management on MQTT. A UNS can be built with Sparkplug or with plain MQTT: Sparkplug makes it easier to know data freshness through device discovery and “birth/death” messages, while plain MQTT gives more freedom in the payload format. To experiment with the topic structure, try our Sparkplug B & UNS Topic Builder.

Things to watch

• Naming governance: Who may add a new branch? How are names changed? Settle this up front.
• Security: The broker should be protected with TLS, clients authenticated and authorization defined per branch. For where brokers sit in an OT network, see the network segmentation principles.
• Data quality: If the unit, timestamp and quality of a published value are unclear, a UNS only distributes bad data faster.
• Payload size and rate: Instead of publishing every change, suppress noise with mechanisms such as deadband.

UNS with HighByte Intelligence Hub

HighByte Intelligence Hub is an industrial DataOps platform that applies the “connect–model–condition–publish” steps of this architecture without code. It connects to sources such as OPC UA, MQTT, SQL and REST, builds asset models with reusable templates and publishes the namespace through an embedded MQTT broker (MQTT v3.1.1/v5, with Sparkplug A and B support). See our DataOps & UNS solution page for details.