What is a Unified Namespace and how do you design one?

The idea: a shared namespace instead of point to point

In point-to-point integration every new system needs its own interface to every system it must connect to. In a UNS each system connects only to the namespace: a system that produces data publishes, a system that consumes data subscribes. A new consumer can then be added without changing the publisher.

The namespace carries the plant’s “current truth”: the state of a line, the counter of a machine, the stage of a production order. Keeping history for the long term is a separate problem and is usually solved with a historian or a database; a UNS can feed those systems too.

Hierarchy and naming

The hierarchy narrows the physical location of a measurement from left to right. A common structure inspired by the ISA-95 equipment hierarchy looks like this:

enterprise/site/area/line/cell/metric

In this structure queries such as “all states on a line” or “temperature across all sites” can be expressed with a subscription filter. The principles of topic design apply to naming: lower case, stable names and no values in the topic. The MQTT topic builder generates examples and subscription filters from this structure.

Decide the number of levels and the names up front, together with the teams concerned. When a name changes, every publisher and subscriber that depends on it is affected.

Current state and events

A UNS holds two kinds of data and they need to be kept apart. State is how something is right now: the line is running, the temperature is 72. If state topics are published with retain, a new subscriber receives the last known value immediately. An event is something that happens at a moment: a batch completed, an alarm started. Retain does not suit event topics; a new subscriber sees only the most recent event and misses earlier ones.

Every message should carry the source timestamp, unit and quality. Only a timestamp tells you how old a retained state value is. Online/offline status and a Last Will can announce whether the source is alive (see MQTT in production for details).

Payload contract and Sparkplug

The topic name tells you where; the payload carries the meaning. A data contract defines the fields, types, units and version for each message type. You can define the structure yourself (for example in JSON) or use a specification such as Sparkplug B. Sparkplug brings a particular topic structure and a Protobuf payload; your own structure is more flexible but documenting and applying it consistently is up to you. In either case a version field makes it possible to change the structure later.

Governance: who owns what?

The technical part of a UNS is set up quickly; the hard part is keeping the rules alive:

• Naming owner. Who decides to add a new area, line or metric?
• Publishing rights. Which system may publish to which subtree? Restrict each publisher to its own subtree through broker authorisation.
• Change process. How do subscribers find out when a payload field changes?
• Broker operation. The broker is a critical component; redundancy, monitoring and capacity must be planned separately.

Common mistakes

• Dumping raw tags into topics. Publishing PLC tag names as they are fills the namespace with technical detail; create names that mean something to the consumer.
• Data without timestamps. You cannot tell whether retained values have gone stale.
• Mixing commands and state. Keeping write commands and state information in the same topic creates confusion and a security risk; commands belong in separate, authorised topics.
• Treating the UNS as the solution on its own. A namespace does not by itself solve data ownership or quality.

The role of OPC Router

In a UNS the data sources speak different protocols: OPC UA, SQL, SAP, REST. The layer that reads from these sources, converts the value to the defined schema and publishes it to the namespace (or reads from the namespace and writes to a destination) is an integration layer. OPC Router can take that role with its MQTT Client and Sparkplug connections; topic hierarchy, payload schema and outage behaviour are set in the project together with the data contract. To get started see the Industrial IoT and MQTT solution page and the MQTT guide.