What is Unified Namespace in OPC UA?

Glossary · PubSub

Unified Namespace

A Unified Namespace is an architectural pattern, not an OPC UA feature: one broker-hosted, hierarchically named, always-current view of plant state that every producer publishes into and every consumer reads from. OPC UA supplies the semantics and the southbound connection; MQTT usually supplies the namespace itself.

What the pattern actually asserts

Three claims. First, every system integrates once against the namespace rather than point to point against every other system. Second, the namespace holds current state, not a message history, so a new consumer can start cold and be correct. Third, the naming hierarchy mirrors the physical or ISA-95 structure of the plant, so a topic path is self-explanatory. Nothing in there is specific to OPC UA - but nothing else supplies the typed, browsable source data as well.

Deriving topics from browse paths

The useful mechanism is generating the topic hierarchy from the OPC UA address space instead of hand-maintaining a mapping table. OPC Publisher supports topic templates at WriterGroup, DataSetWriter or Node level, and an automatic mode where browse paths from the root folder i=84 become the MQTT topic hierarchy, with MQTT reserved characters escaped as backslash-x followed by the ASCII code. Pair it with a low-overhead message format such as SingleRawDataSet or SingleDataSetMessage so each topic carries one clean value.

The current-state problem

MQTT is a message bus, not a database, and OPC UA PubSub over UDP has no retained state at all. To make the namespace actually current you need one of: MQTT retained messages, Sparkplug birth certificates, or KeyFrameCount 1 so that every PubSub message is a complete snapshot. Skip this and the pattern degrades into a message stream that a restarted consumer cannot interpret, which is the most common way a Unified Namespace project quietly fails.

Keeping the semantics on the way through

The gateway is where type information usually dies. Non-reversible JSON produces bare numbers that cannot be round-tripped, and once those messages are in the broker or the lake the types are unrecoverable. Publish reversible JSON, or publish DataSetMetaData alongside the data, or at minimum keep the companion-specification BrowseNames in the topic path so a consumer can look the model up. A namespace of untyped floats named by whatever the integrator typed is not a Unified Namespace, it is a tag list with slashes in it.

Example

Address space to topic hierarchy, derived rather than hand-mapped

OPC UA browse path from i=84
  Objects / Plant1 / Line3 / Press / Force            ns=4;s=Press.Force

MQTT topic (DataSetRouting: UseBrowseNames)
  plant1/line3/press/Force

Payload (SingleDataSetMessage, reversible JSON)
  { "Value": { "Type": 11, "Body": 812.4 },
    "SourceTimestamp": "2026-09-08T06:11:04.2100000Z" }

# StatusCode Good is 0 and is omitted - absent means Good, not missing.

The mistake people make: Building the namespace by hand from a spreadsheet of tags. Every namespace-index change, PLC download or firmware update then desynchronises it silently, and nobody notices until a consumer reads a topic that has been static for three weeks. Derive the hierarchy from browse paths so the model is the single source of truth.

Defined in: Not defined by IEC 62541. Built from Part 14 - PubSub plus MQTT; compare Sparkplug 3.0.0.

Related concepts

Sparkplug B DataSetWriter Key frame Non-reversible JSON encoding Reversible JSON encoding Namespace index

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.