In most plants, systems are connected point to point: PLC to SCADA, SCADA to historian, historian to MES, MES to ERP. Every new application means a new connection, a new mapping and a new maintenance burden. A Unified Namespace (UNS) turns this structure around: every system publishes its current state into one shared namespace, and anyone who needs data reads it from there.
A UNS is not a product but an architectural rule: “Data is published once, to a known address; consumers do not need to know the publisher.” In practice it is usually built with an MQTT broker and an ISA-95-style topic hierarchy.
The structure of a UNS
Publishers (PLCs, edge gateways, MES, ERP) send their data to the broker under hierarchical topic names. The hierarchy typically runs from enterprise to cell: enterprise / site / area / line / cell / measurement. Consumers (historian, analytics, dashboards, MES) subscribe to the branches they need. The broker is the single source of truth for current state.
What a UNS is not
- It is not a historian. A UNS carries current state; for history, a historian subscribes to the UNS and records data.
- It is not just MQTT. MQTT is a common carrier; the real value lies in naming and data-model discipline.
- It does not replace MES or ERP. They can also be publishers and consumers of the UNS.
- It is not a package you buy. Products help; the real work is naming and ownership decisions.
Step-by-step setup
- Define the naming hierarchy. The ISA-95 levels are a good start. Choose lowercase, space-free, ASCII names; names should be permanent, and only values should change.
- Choose the broker topology. A redundant in-plant broker, bridged to a central broker if needed. The broker sits in a DMZ at the IT/OT boundary, and the OT side makes outbound connections only.
- Connect the publishers. Legacy devices need an edge gateway: Kepware Server collects the data and publishes it with IoT Gateway; OPC Router can transform and publish source systems. Newer devices can speak MQTT or OPC UA PubSub directly.
- Define the data model. Every message should carry value, unit, source timestamp and quality. Sparkplug B provides this structure and the BIRTH/DEATH lifecycle ready-made; alternatively use a documented JSON schema (choosing the data model).
- Add consumers. Historian, dashboards, analytics and MES subscribe only to the branches they need.
- Set up governance. The owner of each branch, schema versioning, publish-rate rules and topic-based access lists should be written down.
Topic name examples
| Level | Meaning | Example name |
|---|---|---|
| Enterprise | The organization’s root name | enterprise |
| Site | Physical location | enterprise/site-1 |
| Area | Production area or department | enterprise/site-1/filling |
| Line | Production line | enterprise/site-1/filling/line-2 |
| Cell | Machine or station | enterprise/site-1/filling/line-2/filler |
| Measurement | Data point | …/filler/temperature |
Common mistakes
- A flat “topic soup”: topics with no hierarchy, named by each team on its own, turn the UNS into a mess.
- Ownerless branches: topics with no clear responsible party go stale over time.
- Publishing everything every second: publishing on change (deadband) is often enough.
- Leaving security to the end: TLS, authentication and topic-based access should be designed from the start.
- Skipping quality and time: a value alone is not enough (data quality and timestamps).
Start with a small pilot
Pick a single line, roughly twenty to fifty measurements and one consumer (for example a dashboard). Test naming and the data model in this pilot, then extend to other lines and systems. For using OPC UA and MQTT together see OPC UA or MQTT?; for terminology see the glossary.
Frequently asked questions
Is Sparkplug B mandatory for a UNS?
No. It is a common choice because it provides a shared payload format and device lifecycle rules, but a UNS can also be built with a documented schema.
Where is historical data kept in a UNS?
A historian application subscribes to the UNS and records data with timestamps. The UNS itself carries current state.
Do I have to use the ISA-95 hierarchy?
It is not required, but it is a good start because it offers a familiar and extensible structure. What matters is that the hierarchy is consistent and permanent.
