The unified namespace, or UNS, is an architectural idea that has reshaped how industrial data flows. Rather than wiring every system directly to every other system, a UNS makes one place where the current state of the entire operation lives - and everything reads from and writes to that single hub. This page defines what a unified namespace is, how it is built, and how it differs from traditional point-to-point integration.
What Is a Unified Namespace? in one line: A unified namespace is a single, structured, real-time hub that holds the current state of an entire operation, organized to mirror the physical business. Every device and application publishes to it and subscribes from it, so the UNS becomes the one source of truth instead of a web of direct point-to-point connections.
Traditional plant and field integration is point-to-point: the SCADA talks to the historian, the historian to the ERP, the MES to the SCADA, each with its own custom connection. With N systems you can end up with N-squared brittle links, and adding one new application means touching many others. This is the 'spaghetti' architecture every operations team eventually inherits.
A unified namespace inverts that. Every system connects once to a central broker and publishes its data to a hierarchical, self-describing structure. Any consumer subscribes to the part of the namespace it needs. Adding a new analytics tool, dashboard, or AI model becomes a subscription - no new field integration - because the data it needs is already in the namespace.
The 'namespace' is a topic hierarchy that mirrors the ISA-95 model of the business - typically Enterprise / Site / Area / Line (or, in the field, Region / Field / Pad / Well / Device). A tubing pressure might live at permian/eastfield/pad12/well3/tubing_pressure. Crucially, the UNS holds current state, not just a stream of events: any consumer connecting fresh can read the last known value of everything immediately.
In practice a UNS is almost always built on an MQTT broker using the Sparkplug B specification, which standardizes the topic layout, payload encoding, and state handling that make the namespace consistent and discoverable. Edge devices and gateways publish report-by-exception, so the namespace reflects reality with minimal bandwidth - important for distributed oilfield operations on cellular links.
A UNS is not a replacement for SCADA - it is a data architecture that SCADA participates in. Your SCADA still supervises and controls; it publishes its tags into the namespace and can subscribe to context (production targets, work orders) from other systems. The historian subscribes to archive it; analytics subscribes to model it; the ERP subscribes to the numbers it needs.
For a distributed oil and gas operator, a UNS gives one coherent, real-time picture of every well, pad, and facility that any tool can tap without a bespoke integration. A cloud SCADA that speaks MQTT and Sparkplug B - such as Merobix - can act as both a publisher and a consumer of the namespace, and can also bridge legacy Modbus and DNP3 devices into it so polled equipment shows up in the UNS alongside native MQTT devices.
It is one central, always-current, organized data hub that holds the state of your entire operation. Every system publishes its data there and reads what it needs from there, so instead of many direct connections between systems, everything connects once to the hub - the single source of truth.
No. MQTT (with Sparkplug B) is the technology most commonly used to build a UNS, but the unified namespace is the architectural concept - a single, structured, real-time source of truth. You could in principle build a UNS on other technology; in practice MQTT plus Sparkplug B is the standard implementation.
No. A UNS is a data-sharing architecture, not a control or archival system. Your SCADA still supervises and controls and your historian still archives; they participate in the namespace by publishing to it and subscribing from it. The UNS eliminates the tangle of custom point-to-point integrations between them.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.