Unified Namespace: a reference architecture with a real ISA-95 topic schema

A unified namespace (UNS) is a single, hierarchically ordered, event-driven data space in which every system in the plant publishes its current state and subscribes to the states of the others - in practice almost always over an MQTT broker. This article supplies what most concept pieces leave out: a complete topic schema based on ISA-95, naming rules with the reasoning behind them, a sober assessment of Sparkplug B, a criteria grid for choosing a broker, and a straight answer to the question of when a unified namespace is simply overkill.

What a unified namespace is - and what it is not

A unified namespace is the current state of the entire operation, in one place, in one structure, readable by everyone. Technically it consists of three things: a publish/subscribe message broker, a binding topic hierarchy, and the agreement that every system publishes its data there and subscribes from there to everything it needs from others. The German-language Wikipedia article describes the concept briefly as an IIoT approach and states verbatim: "An MQTT broker is frequently used as the middleware infrastructure for implementing the unified namespace" (translated from the German original). That article does, however, carry a quality-assurance notice for factual shortcomings, which illustrates how thin the German-language literature on the subject still is.

The boundaries matter more than the definition. A UNS is not a database: it holds the last known state of every signal, not its history. It is not a data lake: raw data lands there for later analysis, whereas a UNS holds a curated, named present. It is not an MES and not a SCADA system: both remain producers and consumers at the broker. And it is not a product you order - the work sits in the naming convention and in the discipline to hold to it.

The problem behind it: point-to-point integration in the automation pyramid

The classic ISA-95 layering - field, control, supervisory control, operations management, enterprise planning - is a functional model, not a network architecture. Dennis Brandl and Charlotta Johnsson wrote in the ISA magazine InTech (October 2021) that the pyramid structure is a traditional implementation but is not prescribed by the standard. In practice the pyramid became the wiring template anyway: every system talks to the one above it and the one below it, and every cross-connection gets an interface of its own.

The problem is not the individual interface but the number of them. If every system potentially has to exchange data with every other, the number of possible couplings grows quadratically. Every new machine and every new analysis tool forces a new coupling to each system whose data it needs - and after three years nobody can say which figure reached which dashboard by which route.

No plant actually builds all 66 couplings. The effect shows up more subtly: a new energy monitoring system needs machine states that so far only the MES knows; a maintenance analysis needs cycle times that so far only reach the SCADA system. In a UNS those signals sit ready under a known name - the new consumer subscribes to them without anyone touching the controller. What this means for coupling MES and ERP is covered in MES-ERP interface: which integration pattern holds up when.

The topic hierarchy: ISA-95 as a namespace, not as a pyramid

The ISA-95 topic hierarchy of a UNS takes from the standard not the layers of the pyramid but the role-based equipment hierarchy. The OPC UA companion specification for ISA-95 (OPC 10030) defines these levels verbatim: an enterprise is "a collection of sites and areas", a site is a "physical, geographical, or logical grouping determined by the enterprise", an area is a corresponding grouping below the site, a work centre is "the grouping of equipment scheduled by the Level 4 or Level 3 functions" and a work unit is "any element of the equipment hierarchy under a work centre". In discrete manufacturing, work centre and work unit are usually called production line and work cell.

That yields a topic schema with five location levels, followed by the device, a signal category and the signal itself. Under the OASIS standard MQTT separates the levels with a forward slash; + stands for exactly one level, # for any number of them. The following unified namespace example shows a fictitious plant with an injection moulding machine in hall 2, line 3, cell 7:

<enterprise>/<site>/<area>/<line>/<cell>/<device>/<category>/<signal>

exampleworks/schwerin/hall-2/line-03/cell-07/imm-0712/state/operating-mode
exampleworks/schwerin/hall-2/line-03/cell-07/imm-0712/state/fault-active
exampleworks/schwerin/hall-2/line-03/cell-07/imm-0712/process/cycle-time
exampleworks/schwerin/hall-2/line-03/cell-07/imm-0712/process/mould-temperature
exampleworks/schwerin/hall-2/line-03/cell-07/imm-0712/counter/good-parts
exampleworks/schwerin/hall-2/line-03/cell-07/imm-0712/counter/scrap
exampleworks/schwerin/hall-2/line-03/cell-07/imm-0712/energy/active-power
exampleworks/schwerin/hall-2/line-03/order/active
exampleworks/schwerin/hall-2/line-03/kpi/oee/shift

Subscribe to every good-parts counter in hall 2:
exampleworks/schwerin/hall-2/+/+/+/counter/good-parts

Two decisions here are deliberate. First, every device carries a stable identifier (imm-0712) rather than a descriptive name - machines get moved, sold and replaced, and the identifier should survive that. Second, there is a category level (state, process, counter, energy) so that a consumer can subscribe to every counter or every energy value in a hall without knowing each signal individually. What turns those counters into a cleanly defined KPI is set out in Calculating OEE: formula, worked example and data sources.

Payload and state management: why Sparkplug B makes the difference

A topic schema brings order, but it says nothing about what is in the payload and how a consumer learns the current state if it only connects after the last change. In the simplest setup the broker solves that itself: MQTT has the RETAIN flag. The OASIS standard MQTT 5.0 (March 2019) requires the server to store a message marked that way and to deliver it to a new subscriber for each matching topic - unless that subscriber's Retain Handling subscription option limits this (values 1 and 2). A dashboard that connects at 06:12 therefore sees the state of every machine immediately - the broker is the state mirror.

This approach has three gaps. The payload is unstructured - each publisher decides for itself whether a bare number, a JSON object or a string arrives. There is no typing. And nobody knows whether a stored value is current or whether the machine has been off the network for two hours. A pragmatic minimum is therefore a uniform JSON payload with value, unit, quality and timestamp. Anyone who needs firmer guarantees than that ends up at Sparkplug B.

{
  "value": 12.4,
  "unit": "s",
  "quality": "good",
  "ts": "2026-09-21T06:12:03.412Z",
  "source": "opcua:ns=3;i=1042"
}

Eclipse Sparkplug, according to its specification, defines an MQTT topic namespace, a payload format and session state management. Version 3.0 - revision history dated 21 October 2022, document status 3.0.0 of 16 November 2022 - has also been published as ISO/IEC 20237 since November 2023, as the Eclipse Foundation announced. The mechanics: an edge node announces itself with an NBIRTH which, per the specification, MUST contain every metric it will ever publish in that session - with name, data type and value. As its MQTT will message it registers an NDEATH, which the broker publishes automatically when the connection drops. After that come NDATA messages, which MUST contain every metric that has changed since the last NBIRTH or NDATA (report by exception). The payload is encoded with Google Protocol Buffers, and metrics can carry numeric aliases.

Important for the comparison: Sparkplug sets the retain flag on NBIRTH and NDATA to false per the specification; only the host application's STATE message is retained. The state mirror therefore does not sit in the broker but in the host application, which reconstructs it from birth certificates and data updates. That is cleaner - the application always knows whether a value is alive - but a plain MQTT client with no understanding of Sparkplug can do little with the tree.

The honest costs: Sparkplug topics have the fixed form spBv1.0/group_id/message_type/edge_node_id/[device_id] - only three location levels, and / is forbidden inside the identifiers. An eight-level ISA-95 path therefore has to be folded into group_id, edge_node_id or the metric names. The choice of tooling is narrower, because consumers have to decode protobuf and rebuild the session state; troubleshooting gets harder, because nobody can read along with a simple client. In return you get typing, liveness signals and behaviour that several vendors implement the same way. Many installations therefore split the two: Sparkplug between edge and broker, and above it a readable ISA-95 tree in JSON, fed from the Sparkplug data by a translator.

Choosing and running the broker: the criteria that count in year two

The MQTT broker in a unified namespace is a single point of failure by construction: if it fails, nothing publishes and nothing subscribes. That is not an argument against the concept, but it is an argument for treating the broker like a production system - with an owner, monitoring, a maintenance window and a plan for the outage. For the selection, then, the throughput figures on the product page matter less than the properties that cause or spare you trouble in the second year of operation.

The high-availability options deserve some honesty: a broker cluster does not remove the single point of failure, it moves it to the cluster and its network. For many plants a single, monitored broker with a rehearsed restart and edge buffering is more realistic than a cluster nobody in house can run.

Edge filtering: what should never enter the UNS in the first place

What belongs in the UNS is what has changed - not what has just been sampled. A controller delivers a mould temperature cyclically every 100 ms; the dashboard, the energy monitor and the database only need it when it moves. Without filtering logic at the edge a UNS becomes a cost problem: the broker distributes millions of identical values, the database stores them, and nobody can say when something actually happened.

• —Change detection instead of sampling rate: publish when a value changes by more than a deadband - for counters and states, on every change. Add a heartbeat at a fixed interval so that a standstill stays distinguishable from a failure.
• —Aggregation at the edge: minimum, maximum and mean per minute for process values whose individual samples nobody consumes; the raw value stays in a local historian if it is needed.
• —Buffering during network outages: the edge client stores locally and re-delivers with QoS 1 as soon as the broker is reachable. Sparkplug uses the host application's STATE signal for this; without Sparkplug you need your own store-and-forward logic.
• —Timestamp at the source: the timestamp comes from the controller or the edge device, not from the broker - otherwise re-delivered messages carry the time of delivery. Time synchronisation via NTP is mandatory.
• —Handle standstill deliberately: a stopped machine publishes no process values, but it does publish its state. Silence must never be read as "running unchanged"; hence a state signal plus heartbeat plus death certificate.

A worked example with assumed figures: a line with twelve machines delivers 40 signals each on a 100 ms cycle - 4,800 values per second, around 415 million a day. With change detection and per-minute aggregation only a few percent of those remain, and those are the ones that carry the information. Everything the filter removes would otherwise have to be transported, stored and, at some point, deleted again - on every consumer, not just in the database.

How OPC UA and the UNS fit together

Unified namespace versus OPC UA is a false opposition: OPC UA supplies the information model at the machine, the UNS distributes the state across the operation. An OPC UA server on the controller describes which variables exist, what type they have and how they belong together - with companion specifications, even across vendors. An edge gateway subscribes to those nodes, applies the filtering logic and publishes them under the ISA-95 topic. The NodeId travels into the payload as an origin reference, not into the topic path - topics should stay readable in plant terms, and ns=3;i=1042 is not.

One alternative to the gateway is OPC UA PubSub over MQTT as defined in OPC 10000-14. There the OPC UA side publishes to the broker itself, with a topic structure of the form <Prefix>/<Encoding>/<MqttMessageType>/<PublisherId>/…, where the prefix defaults to opcua per the specification and the encoding is json or uadp. Metadata and status messages are sent with RETAIN=True, data messages with RETAIN=False. That is type-safe and standards-compliant, but it follows the publisher structure rather than the plant hierarchy. Anyone who wants an ISA-95 tree needs a mapping layer here too.

The choice between OPC UA client/server, OPC UA PubSub and native MQTT per machine is a protocol decision with its own criteria, and it is covered in OPC UA or MQTT? A decision guide for connecting machines. For the UNS architecture in production this rule is enough: OPC UA where the information model is created; MQTT where many consumers need the same state.

When a unified namespace is overkill

A UNS only pays for itself once several systems need the same data. Three situations argue against building one: a handful of machines at a single site, one single consuming system - usually a dashboard or a time-series database - and nobody in house willing to run a broker as a production system. In that position a broker is an extra component that can fail, plus a naming convention nobody uses.

The threshold is not a machine count but a consumer count. Where the operator role is missing, the direct connection is not the worse solution but the more honest one.

Rolling it out in stages: a realistic path

Building a unified namespace works when it starts small and every stage answers an organisational question: who runs this, and who is allowed to change the schema? A suggested path in four stages:

1. 01

   Stage 1 - one line, one broker, one dashboard

   One broker on-premise, one edge gateway on one line with change detection, one dashboard as the only consumer. The goal is learning: which signals exist, what they are called, how often they change. Owner: the person who set the gateway up. Schema: still a draft.

2. 02

   Stage 2 - put the naming convention and role model in writing

   The schema becomes a written document, with the rules from Tab. 01 and a list of permitted categories and signal names. ACLs separate write and read rights per subtree; TLS with client certificates becomes mandatory. From now on a named office approves changes to the schema - without it, the tree falls apart.

3. 03

   Stage 3 - further lines and the second site via a bridge

   Further lines follow the same schema; the second plant gets its own broker, and a bridge mirrors selected subtrees - KPIs and states, no raw process values. Owner: a role with a deputy. Broker monitoring belongs in the same monitoring system as the MES.

4. 04

   Stage 4 - writing systems and releases

   Only now do systems publish whose messages have an effect: setpoints, order starts, releases. That needs its own subtree, its own ACLs and acknowledgement by the receiver. Starting here too early turns the data space into a control path without the safety mechanisms of a controller.

Conclusion

A unified namespace is the answer to a scaling problem, not to a technology problem. The value does not come from the broker but from a topic hierarchy that follows the plant, from naming rules that hold for ten years, and from clear ownership of both. Sparkplug B, OPC UA PubSub and broker clusters are tools for particular places in the architecture - not prerequisites. Anyone with a second consuming system should start with one line, one broker and a written schema, and take the stages in the order described.

If you would like to examine how such a namespace would work with your existing controllers, your MES and a shopfloor dashboard, our solutions for machine data and production KPIs show which building blocks the path from signal to shared data space requires.