TL;DR:

  • The Unified Namespace (UNS) centralises all industrial data on an MQTT broker, replacing the traditional ISA-95 hierarchical integration approach
  • OPC UA over MQTT (OPC UA PubSub, or Sparkplug B for older infrastructure) provides semantic context: units, data types, alarm states, and device metadata travel alongside the raw values
  • UNS dramatically reduces integration complexity as you add new systems — every data producer and consumer connects to the broker, not to each other

Traditional industrial integration looks like a phone system from the 1980s: machines connect to SCADA, SCADA connects to MES, MES connects to ERP, and every interface is a custom point-to-point integration. Adding a new analytics system means building a new integration with each upstream system. Changing a machine means updating every downstream system that consumes its data. The integrations multiply quadratically as the number of systems grows.

The Unified Namespace architecture replaces this with a single, centralised MQTT broker that every system treats as the ground truth for operational data.

The UNS Principle

In a UNS, every system — PLCs, sensors, SCADA, MES, historians, cloud analytics platforms, AI models — publishes data it produces and subscribes to data it consumes. The MQTT broker is the only thing they connect to directly.

This mirrors how the internet works with DNS and IP routing: no machine needs a direct connection to every other machine. It also mirrors how microservices use a message bus. The manufacturing world is arriving at the same conclusion about thirty years later.

The topic structure in MQTT becomes the namespace that gives the architecture its name:

Factory/Site/Area/Cell/Machine/Measurement

acme-corp/sheffield-plant/assembly/line-3/press-1/temperature
acme-corp/sheffield-plant/assembly/line-3/press-1/pressure
acme-corp/sheffield-plant/utilities/compressor-2/flow-rate
acme-corp/sheffield-plant/quality/vision-system-1/defect-count

Any system that needs the temperature of Press 1 subscribes to that topic. Any new system that needs this data subscribes to the same topic — no additional integration work.

OPC UA’s Role: Semantic Context

Raw MQTT topics carry values without context. Is 42.7 in Celsius or Fahrenheit? Is it a point reading or an average? What’s the engineering unit? What’s the valid range?

OPC UA (Unified Architecture) is the industry standard for giving that context. OPC UA PubSub — the modern specification for OPC UA over MQTT and UDP — lets you publish OPC UA-modeled data to an MQTT broker, carrying the full semantic model: data types, units of measurement, alarm limits, quality indicators, and device metadata.

The result is self-describing data. Any consumer that understands OPC UA can read the topic and know immediately what the data means, how to display it, and how to validate it.

OPC UA PubSub uses JSON or UADP (binary) encoding. The JSON format is straightforward to parse:

{
  "Messages": [{
    "DataSetWriterId": 1,
    "Timestamp": "2026-06-24T10:30:00Z",
    "Payload": {
      "Temperature": {
        "Value": 42.7,
        "StatusCode": {"Code": 0},
        "SourceTimestamp": "2026-06-24T10:29:59.998Z"
      }
    }
  }]
}

The StatusCode carries quality information (0 = Good; non-zero codes indicate instrument faults, communication issues, or out-of-range values). Consumers don’t need to know the source device — the quality is in the data.

Sparkplug B for Older Infrastructure

Not all PLCs and older devices support OPC UA PubSub. For legacy equipment, MQTT Sparkplug B (maintained by the Eclipse Foundation) provides a lighter alternative. Sparkplug B standardises MQTT topic naming and uses Protobuf encoding for payloads. It also adds concepts of device birth/death certificates — messages that announce when a device connects and what data it publishes, so consumers can discover available data automatically.

Most modern IIoT edge platforms (Inductive Automation Ignition MQTT Engine, Cirrus Link MQTT Modules, HiveMQ Edge) speak both OPC UA PubSub and Sparkplug B. The choice depends on whether your field devices support OPC UA natively. If they do, go OPC UA PubSub. If they’re older Modbus, Profibus, or HART devices, use an edge gateway running Ignition or Cogent DataHub to bridge them to Sparkplug B on the broker.

The ISA-95 Comparison

The traditional ISA-95 reference architecture organises plant data in a strict hierarchy: Level 0 (sensors) → Level 1 (PLCs) → Level 2 (SCADA) → Level 3 (MES) → Level 4 (ERP). Data flows up this stack through interfaces defined at each layer boundary.

The UNS doesn’t eliminate these organisational layers, but it removes the rigid point-to-point integration between them. Instead of MES calling SCADA’s API, MES subscribes to the topics it needs from the broker. Instead of ERP waiting for daily MES reports, ERP subscribes to production completion events in real time.

This change has practical consequences for how quickly you can build new capabilities. An analytics team that wants to correlate machine OEE with quality data doesn’t need to negotiate access to SCADA and MES APIs separately. They subscribe to both from the broker. A new machine in the plant starts publishing to the broker; everything that needs its data starts consuming without any reconfiguration of existing systems.

Implementation Stack

A practical UNS stack for a mid-size plant:

Broker: HiveMQ Platform or EMQX (both production-grade, clustered, with OPC UA PubSub and Sparkplug B support). For smaller deployments, HiveMQ Edge is a free option that runs at the plant level.

Edge gateway: Inductive Automation Ignition Edge (most widely deployed, excellent Sparkplug support, has OPC UA server built in) or Cogent DataHub. The gateway connects to PLCs via OPC UA, Modbus, Siemens S7, or other protocols and translates to the broker namespace.

Broker-side storage: Most teams pair the MQTT broker with a time-series database (InfluxDB, TimescaleDB, or Timeseries Insights in cloud) by subscribing a writer service to all topics. This creates a historian without a separate historian license.

Analytics and applications: Any system that can speak MQTT or has an OPC UA client can participate. Node-RED for light automation and alerting. Python or Node.js services for analytics. Cloud MQTT bridges (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) for cloud connectivity.

Getting Started

The simplest path to a UNS proof of concept:

  1. Stand up a free HiveMQ Edge or EMQX Community broker on a local server or VM
  2. Define your topic namespace for one production line following the hierarchy pattern
  3. Use Ignition Edge with the MQTT Transmission module to publish from existing PLCs to the broker
  4. Connect Node-RED as a consumer to display data and validate the topic structure
  5. Once the pattern proves out, document the namespace conventions and expand

The namespace design is the hardest part. Spend time getting the hierarchy right before connecting more systems — changing it later means updating every subscriber.

The industry momentum behind UNS is significant. HiveMQ, AWS, and the Eclipse Sparkplug working group are all investing in the pattern. Most major SCADA vendors (Ignition, Wonderware, Kepware) now have native MQTT/UNS integration. If you’re designing new plant automation or a greenfield factory, building around UNS from the start avoids the integration debt that most manufacturers are now trying to pay down.