What is a Unified Namespace (UNS)?

A Unified Namespace (UNS) is a single, structured place where every system in a plant publishes its current operational data and from which every other system reads it. Each value has a predictable address built from the plant hierarchy (site, area, line, machine), so a consumer finds data by where it comes from instead of by which PLC register holds it.

Why plants need one

For many industrial organizations, Operational Technology (OT) data lives in disconnected silos:

• Legacy PLCs trapped behind proprietary serial protocols.
• SCADA systems tightly coupled to specific HMIs.
• Historian databases that require a PhD in SQL to query.
• Ad-hoc, brittle integrations patched directly into ERP/MES platforms.

The result is often a fragile spaghetti architecture. In that environment, every new integration project tends to increase maintenance effort, naming inconsistency, and change risk more than teams expect.

Proxus approaches this fundamental problem differently: by placing a Unified Namespace (UNS) at the absolute center of the architecture. If you are evaluating this as a production software layer rather than only an architecture pattern, see the Proxus Unified Namespace software page.

• Shared: Operational context across consumers
• Phased: Recommended adoption model

Observed performance depends on workload shape, node capacity, and deployment design.

How a Unified Namespace works

A Unified Namespace is not a piece of software you buy; it is an architectural design pattern. In production, that pattern still needs software for connectivity, topic governance, permissions, buffering, history, and observability. It dictates that all operational data flows through a single, well-structured central broker.

In a UNS architecture:

• Every data point has a predictable, semantic location (the MQTT topic path).
• Naming is rigidly consistent across the entire enterprise, usually inspired by ISA-95.
• All consuming systems see the exact same view of the factory without requiring custom data mappings.

Instead of building N × M point-to-point connections (where adding one new software system requires connecting it individually to 30 existing machines), each component acts independently:

• It Publishes what it produces to the UNS.
• It Subscribes only to the payload branches it needs from the UNS.

This topology breaks down data silos, significantly reduces integration friction, and creates an environment where adding a new predictive maintenance algorithm or an ERP bridge is much simpler.

Why MQTT?

MQTT (Message Queuing Telemetry Transport) is the commonly preferred transport protocol for UNS implementations because it inherently:

• Minimizes bandwidth: Devices publish only when data changes (Report-by-Exception), not by continuously polling static values.
• Ensures reliability: Persistent Quality of Service (QoS) queues help prevent data loss during network blips.
• Scales predictably: Modern brokers can support very large topic and subscriber counts when sizing, payload discipline, and downstream consumers are designed appropriately.
• Enforces security: It operates on outbound connections with built-in TLS encryption and strict Access Control Lists (ACLs).

The MQTT broker transports messages between publishers and subscribers. A usable UNS additionally requires governed topic ownership, asset identity, schemas, quality, authorization, lifecycle rules, and consumer contracts.

The ISA-95 Hierarchy: Standardized Data Organization

Proxus models its namespace on the ISA-95 equipment hierarchy, which organizes production data into an intuitive five-level pyramid:

Enterprise (e.g., "Proxus_Global")
 └─ Site (e.g., "Istanbul_Factory")
 └─ Area (e.g., "Assembly_Line_1")
 └─ Equipment (e.g., "Robot_Arm_04")
 └─ Metrics (e.g., "Temperature", "Status", "OEE")

This structure ensures that:

1. Humans can navigate the data tree intuitively without constantly referring to variable mapping spreadsheets.
2. Wildcard subscriptions reduce consumer-specific mappings: A consumer can subscribe to a governed topic pattern such as Istanbul_Factory/Assembly_Line_1/+/+/OEE. New equipment becomes discoverable through that pattern only when it follows the approved namespace, payload, identity, and access-control contract.
3. Context is preserved: The topic path itself exposes where the data originated. An anonymous value 72 means nothing; Istanbul/Line1/Oven/metrics/Temperature = 72 means everything.
4. Legacy systems adapt: A 25-year-old PLC is read by a gateway and becomes just another standard "Equipment" node.

A Concrete Example

In a beverage bottling plant, your topics look like this:

ProxusMfg/Istanbul/Bottling/Line3/FillerMachine/metrics/Temperature
ProxusMfg/Istanbul/Bottling/Line3/FillerMachine/state/Running
ProxusMfg/Istanbul/Bottling/Line3/FillerMachine/events/MaintenanceAlert

Payloads: JSON or Sparkplug B

MQTT moves messages but does not say what is inside them: one device might publish {"temp": 24} as JSON, another 24.0 as raw bytes. A UNS needs an agreed payload, with the value, its source timestamp, quality and unit travelling together. Sparkplug B, an Eclipse specification, is one answer: Protocol Buffers payloads with typed metrics, and BIRTH and DEATH messages that announce a node's metrics and its disconnects. Documented JSON is another, and is often simpler for a single-site start. The trade-offs, and how to write the payload contract, are in the practical guide.

In Proxus, devices can publish JSON into the gateway's built-in MQTT broker, while polled controllers are read by protocol drivers; both land in the same namespace. Sparkplug B is supported on the outbound side, so the namespace can be published to Sparkplug-aware consumers.

How Proxus Executes the UNS

Proxus is built to serve as the core of a UNS. Instead of bolting an open-source MQTT broker onto legacy SCADA (see Proxus compared with a standalone MQTT broker), Proxus uses a highly-concurrent actor-based architecture:

This architecture is intended to keep live distribution, buffering, and downstream consumption separated so they can scale more cleanly than point-to-point integration patterns.

Worked Example: Fixing the Spaghetti

The following is an illustrative scenario, not a customer case. Picture a bottling facility in Istanbul (called "ProxusMfg" in the topic paths). The team needed to monitor three distinct lines in real-time and correlate line-wide OEE.

Before UNS (The Chaos)

• Siemens S7-1200 PLCs on each line talked to isolated local HMIs over Profinet.
• The MES system polled each PLC directly every 10 seconds via a custom driver.
• The ERP (SAP) ran a batch job every 15 minutes to pull the MES database.
• BI dashboards queried a heavily delayed SAP data warehouse.
• The Bottleneck: Adding a new predictive-maintenance consumer required another source-specific mapping, security review, and deployment change.

After UNS with Proxus

• Three Proxus edge gateways read the S7 PLCs and publish normalized data into the namespace on the hub.
• The MES drops its custom polling driver and simply subscribes to ProxusMfg/Istanbul/Bottling/+/+/metrics/OEE.
• The ERP receives production counts through an outbound target instead of a 15-minute batch pull.
• A predictive-maintenance tool subscribes only to the vibration and current topics, while anomaly rules on the gateways flag drift and flatlines locally.

Result: The new AI consumer could be added largely through configuration rather than a fresh round of custom point-to-point integration work.

Why Teams Adopt UNS

The Unified Namespace is best treated as a data-distribution pattern, not a slogan. Its value comes from making operational data easier to reuse across systems without rebuilding the same integration path for each new consumer.

Building a UNS still requires governance, naming discipline, and careful rollout. Proxus is designed to handle much of the implementation surface: physical connectivity, payload handling, edge buffering, and central distribution.

When this may not be suitable

• Lower-frequency telemetry may not justify full distributed complexity.
• Small single-line plants may prefer simpler architectures first.
• Strict legacy constraints may require phased adoption.
• Safety-critical closed-loop control should remain in PLC/Safety PLC layers.

Outcomes depend on workload profile, hardware capacity, and deployment topology.

Frequently Asked Questions

How does this article differ from the other UNS articles?

This article explains the concept: what a UNS is, why it exists and how it differs from the Automation Pyramid. Unified Namespace architecture: a practical guide is the design reference: naming, payloads, state, ownership and testing. The UNS rollout roadmap is the order of work, in five phases from a pilot line to the plant.

Can UNS work with OPC UA?

Yes. UNS does not replace OPC UA - it complements it. OPC UA excels at local machine-to-machine reads; MQTT excels at scalable pub/sub distribution. Edge Gateways read via OPC UA and publish to the UNS via MQTT.

How do I handle data quality in a UNS?

Use Smart Filtering at the edge to eliminate noise before data enters the UNS, and enforce strict topic naming governance. The OT DataOps pipeline ensures data is clean, contextualized, and semantically consistent across all consumers.

References

1. ISA-95 (IEC 62264) - Enterprise-control integration standard defining the hierarchical model adapted for UNS topic design. ISA-95
2. MQTT v5.0 OASIS Standard - Publish-subscribe protocol serving as the UNS transport layer. mqtt.org
3. Eclipse Sparkplug Specification - Payload standardization for MQTT-based IIoT interoperability. sparkplug.eclipse.org

Next, read Unified Namespace architecture: a practical guide for the design rules, see how Proxus runs the namespace, or go to the Unified Namespace concepts in the documentation.