OPC UA, MQTT, and the Unified Namespace: How Plant Data Should Move

A Unified Namespace is a single, structured, real-time hub where every system in the plant publishes its current state, and any system that needs that state subscribes to it instead of asking the source directly. OPC UA and MQTT are not competitors to it, they are the two transports that make it practical: OPC UA carries meaning at the edge, MQTT carries messages across the plant. The point of the architecture is to stop building point-to-point integrations, because a plant that has been integrated point-to-point for fifteen years cannot be changed without breaking something.

That is the short version. The longer version is worth having, because the Unified Namespace is described so often as a philosophy that engineers are left unsure what they are actually supposed to build. It is a concrete thing. You can draw it, specify it, and tell whether you have one.

This is the piece that sits underneath everything else in OT data to cloud architecture. Before you can decide where data should be stored, you have to decide how it moves.

The problem this solves

Take a plant with a SCADA system, a historian, an MES, a quality system, a maintenance system, and a cloud analytics platform. Six systems. Connect each one to each other one and you have fifteen interfaces. Add a seventh system and you are building six more.

In eighteen years of plant work I have never seen that mesh documented accurately. It grows one urgent request at a time: someone needs production counts in the quality system, so a direct connection gets built on a Friday. Three years later nobody knows it exists until it breaks, and the person who wrote it has left. The real cost is not the interfaces, it is that the plant becomes unchangeable. Replacing the MES means finding and rebuilding every private connection into it, and nobody can tell you what they all are.

The Unified Namespace inverts this. Every system publishes what it knows to one place, in an agreed structure, as it happens. Every system that needs something subscribes to it. Six systems means six connections, not fifteen. Adding a seventh means one more, and the new system finds what it needs already there.

Two consequences follow, and they are the ones that matter in practice. Publishers do not know who consumes their data, so adding a consumer changes nothing upstream. And the current state of the plant exists in one readable place, which is a genuinely new capability in most facilities.

What OPC UA actually is

OPC UA is a machine-to-machine communication standard built for industrial equipment. The part that matters here is that it is not only a protocol, it is an information model. A tag is not a bare number: it carries a data type, engineering units, a quality status, a timestamp, and a position in a browsable address space. A client can connect to a server it has never seen and discover what is there.

That last property is the one people underuse. Browsability means a device describes itself. Companion specifications extend this to particular equipment classes, so a device can present itself in a form consumers already understand rather than as a numbered register that needs a spreadsheet to decode.

OPC UA runs in two modes. Client/server is the familiar one: a client connects to a server and requests or subscribes to values. PubSub, added later, lets a server broadcast to many consumers without individual sessions, which is what makes OPC UA viable for the many-consumer pattern a Unified Namespace needs.

What MQTT actually is

MQTT is a lightweight publish and subscribe messaging protocol. Publishers send messages to a named topic on a broker. Subscribers register interest in topics and receive messages as they arrive. Publisher and subscriber never meet and do not need to be online at the same moment.

It was designed for constrained networks, and the design choices show: small headers, a persistent connection that survives being idle, and three delivery guarantees to choose from. At most once sends and forgets. At least once guarantees arrival but may duplicate. Exactly once guarantees arrival exactly once at the cost of a four-step handshake.

Two features get misused often enough to be worth naming now. Retained messages mean the broker keeps the last message on a topic and gives it to any new subscriber immediately, so a system that connects at 3am still learns the current state rather than waiting for the next change. Last Will and Testament lets a client register a message the broker publishes on its behalf if it disconnects unexpectedly, which is how other systems find out a publisher died rather than went quiet.

The division of labour

The question "OPC UA or MQTT" is the wrong question, and it comes up constantly. They solve different problems and a real architecture uses both.

OPC UA belongs at the edge, close to equipment, where the hard problem is meaning. What is this value, what units, what quality, which asset does it belong to. That is what an information model is for, and MQTT has nothing equivalent.

MQTT belongs above that, where the hard problem is movement. Many consumers, unreliable networks, systems coming and going, a firewall between the plant and everything else. MQTT's outbound-only connection matters here more than any feature: the edge client connects out to the broker, so no inbound port into the control network needs opening. Security teams accept that architecture in a way they do not accept the alternative.

The usual shape is an edge gateway that speaks OPC UA downward to equipment and MQTT upward to the broker, translating the model into a topic structure as it goes.

Sparkplug B: the part that makes MQTT usable in OT

Plain MQTT has a gap that matters on a plant. The payload is an arbitrary blob, so every integration invents its own format, and you are back to bespoke work. It is also stateless: a subscriber receiving a value has no way to know whether the publisher is alive and the process is genuinely steady, or the publisher died an hour ago.

Sparkplug B is an open specification that closes both gaps.

It defines the payload, so a message carries typed metrics with timestamps in an agreed binary encoding that every compliant tool can read. It defines the topic structure, so namespaces are consistent rather than per-integrator. And it adds state awareness through birth and death certificates. When a device connects it publishes a birth certificate listing every metric it will report, with types and current values. If it disconnects, the broker publishes a death certificate through the Last Will mechanism.

The result is that a consumer always knows whether data is live, and a newly connected consumer gets the full picture without polling anything. Sparkplug also transmits by exception: after the birth certificate, only changed values are sent. That is the same principle a historian applies when it filters at the interface node, and it is worth understanding its consequences, which I went through in why RAG on historian data fails.

Designing the namespace is the actual work

Choosing protocols takes an afternoon. Designing the namespace is what determines whether this works, and it is where most projects go wrong.

The structure should describe the plant physically, not describe the systems that happen to hold the data. The ISA-95 hierarchy is the conventional basis, and it is conventional because it matches how people already talk about a facility:

enterprise / site / area / line / cell / device / metric
acme / stockholm / packaging / line3 / filler / motor1 / temperature

Anyone who works in that plant can read that path and know exactly what it refers to, which is the test. If understanding a topic requires knowing which historian it came from or which integrator built that cell, the namespace is wrong.

Three rules I would insist on:

Name by physical reality, not by system of origin. The path should not change because you replaced the SCADA package. If it does, every consumer breaks for a reason that has nothing to do with the plant.

One publisher per topic. Two systems writing the same topic produces flapping values that nobody can diagnose, because the payload looks correct in both cases.

Structure is a contract. Once consumers depend on a path, renaming it is a breaking change and needs to be treated like one. Tags get renamed during upgrades and reused years later, and a namespace that drifts silently causes exactly the kind of long-horizon confusion I described in the historian piece.

Where these builds go wrong

These are the failure modes I would check for first, because they are common and they are quiet.

A flat namespace. Topics like line3_filler_temp with the hierarchy encoded in the string. It works until you want to subscribe to everything in one area, and then you discover you cannot, because wildcard subscriptions operate on path segments and you do not have any.

The broker becomes the system of record. A Unified Namespace holds current state. It is not a historian and not a database. When someone starts querying the broker for last month's values, the architecture has been misunderstood, and the fix is to decide deliberately where history lives. That is the choice I worked through in historian vs time-series database vs data lake.

Quality of service chosen by default. Level 2 on every high-rate topic buys a guarantee you rarely need and pays for it in throughput. Level 0 on a critical alarm loses messages silently. Choose per topic, deliberately.

Retained messages used as memory. Retained is for current state. Using it to stash configuration or history produces stale messages that outlive their meaning and reappear months later to confuse a new subscriber.

Timestamps applied at the broker. If the message is stamped when it arrives rather than when the value occurred, you have destroyed the ordering that any later analysis depends on. Timestamp at the source, carry it through, normalise to UTC.

Security deferred. TLS, client certificates, and per-topic access control are not a later phase. A broker reachable on the plant network with anonymous access and no encryption is a control-system exposure, and it is much harder to retrofit once dozens of clients are connected.

No namespace owner. Left ungoverned, the structure fragments within a year, because every integrator adds topics in their own dialect. Someone has to own the tree and review additions, the same way someone owns the tag database.

Why this matters more now than it did

For most of my career this architecture was justified on integration cost, and that argument was always a bit theoretical to a plant manager with a working system.

AI changed the calculation. Every useful thing you might want to do with plant data, whether that is anomaly detection, an assistant that answers questions about the process, or a model that predicts a failure, needs data that is current, structured, and carries its context. A Unified Namespace produces exactly that as a side effect of existing. The semantic layer that industrial RAG depends on is far easier to build when the plant already publishes stockholm/packaging/line3/filler/motor1/temperature than when it publishes FCV100.PV and the meaning lives in a spreadsheet.

This is the honest reason to build one now. Not because point-to-point integration is inelegant, which engineers have known for thirty years, but because the next decade of work on plant data assumes a structured real-time source, and plants that do not have one will spend their AI budget building the plumbing instead.

The bottom line

A Unified Namespace is a single structured real-time hub where systems publish state and subscribers consume it. OPC UA models meaning at the edge. MQTT moves messages above it. Sparkplug B gives MQTT the payload definition and state awareness that OT work requires. Those are the pieces, and the choice between them is a division of labour rather than a competition.

The protocols are the easy part. The namespace design, the governance, and the discipline to keep the structure describing the plant rather than the software are what make it last. Get those right and the next system you add takes one connection instead of six, which is the whole point. Where the data goes after that, and how long you keep it, is a separate decision, and I worked through it in monitoring industrial data without a historian.