How to Implement a Unified Namespace: Plain MQTT or OPC UA

This article was created with AI assistance.

A Unified Namespace is usually built on plain MQTT. It doesn't have to be — and the alternative fixes several problems MQTT-based UNS projects run into once they scale past the pilot.

1Introduction to UNS

A Unified Namespace (UNS) is a single, live, hierarchical source of truth for operational data across a plant or enterprise. Instead of wiring point-to-point integrations between every PLC, SCADA system, MES, and cloud application, every system publishes into — and subscribes from — one shared namespace. It has become a foundational pattern in Industry 4.0 and Digital Transformation initiatives because it decouples data producers from data consumers: adding a new consumer means subscribing to existing data, not building yet another custom interface to yet another data source.

The typical implementation: MQTT broker + ISA-95 topic hierarchy

The most common way to build a UNS today is around an MQTT broker as the central nervous system. Devices, PLCs, and applications publish and subscribe to topics, and the broker fans messages out to whoever is listening. The topic tree is usually organized to mirror the ISA-95 equipment hierarchy — enterprise, site, area, production line, and work cell/asset — so a topic name alone tells you where in the physical plant a value came from, for example enterprise/site/area/line/cell/tagName.

A typical MQTT-based UNS: publishers push to a broker organized as an ISA-95 topic tree; subscribers read what they need — but nothing about the tree is discoverable from the protocol itself.

Pros and cons of MQTT-based UNS

2An Alternative: OPC UA as the Core Protocol

OPC UA is an IEC 62541 standard maintained by the OPC Foundation, built specifically to solve the problems above. Relevant to a UNS, it provides:

• A browseable, discoverable address space — the information model is a hierarchy of objects, variables, and methods that any client can walk and inspect at runtime, no external documentation required
• A well-defined payload format for published data, carrying value, quality, and both server and source timestamps as standard parts of every reading — not an ad-hoc JSON shape each team has to agree on
• True report-by-exception, with server-side monitored items supporting both absolute and percent-based deadbands, so only meaningful changes go over the wire
• Native support for both real-time and historical data through the same address space and the same client APIs
• Built-in support for alarms and events, not a separate system bolted on afterward
• A lighter footprint on the wire than it gets credit for: despite MQTT's "lightweight" reputation, MQTT/JSON payloads commonly run three times or more the size of the equivalent OPC UA binary-encoded payload for the same data

OPC UA also supports a Publish-Subscribe transport mode of its own — including over MQTT — so choosing OPC UA as the core protocol doesn't mean giving up MQTT transport where it's useful; it means the payload, the address space, and the semantics riding on top of it are finally standardized.

Implementing UNS with oBox Suite

oBox Suite from One-Way Automation is a modular platform for building exactly this kind of OPC UA-centric UNS. Its three main modules are:

• Protocol Converter — south-bound connectivity to virtually any industrial data source: PLCs, RTUs, SCADA and DCS systems, CNC machines, and robots from mainstream and legacy vendors alike
• Model Designer / Data Harmonizer — a WYSIWYG, web-based editor for building a hierarchical, ISA-95-aligned address space, turning raw tags into meaningful objects (for example, a Pump with Temperature and Pressure attributes) instead of a flat list of points
• Data Logger — stores and forwards data, both real-time and historical, to downstream databases and messaging systems

That combination gives a UNS built on oBox Suite a few concrete advantages over a bare MQTT broker:

• Southbound connectivity to virtually any industrial data source through the Protocol Converter module
• A WYSIWYG, browser-based editor for the address space, with a real hierarchical structure — not a topic-naming convention enforced by hand
• Support for a layered deployment: local site-level edge instances that push harmonized data up to a centralized cloud instance
• Multiple, standards-based interfaces for higher-level applications to consume the same data:
  • OPC UA — real-time data via standard OPC UA subscriptions and monitored items; Pub/Sub over MQTT or brokerless UDP; and historical data, both raw and processed
  • REST API for lightweight application integration
  • MCP for straightforward integration with AI-based solutions
  • A built-in MQTT broker, so applications that only know how to subscribe over MQTT are still fully supported

UNS built with OPC UA and oBox Suite: harmonized address space at the edge, layered up to a centralized cloud instance, exposed through OPC UA, REST, MCP, and MQTT.

3MQTT-Only vs. OPC UA + oBox Suite

4Wrapping Up

Plain MQTT is a perfectly reasonable way to get a UNS pilot running quickly, and its ecosystem is hard to beat for raw reach. But the gaps that show up once a UNS moves past a pilot — no standard payload, no history, no synchronous calls, no browsing — aren't quirks of a particular broker; they're gaps in MQTT itself. OPC UA closes all four by design, and a platform like oBox Suite turns that into a practical UNS implementation: south-bound connectivity to the plant floor, a real hierarchical address space you build visually instead of by naming convention, and northbound access over OPC UA, REST, MCP, or MQTT — so applications that only speak MQTT still aren't left out.