MQTT, OPC UA and Unified Namespace: Three Things That Are Constantly Mixed Up

KNOWLEDGE | Industrial Data

OPC UA, MQTT and Unified Namespace are often thrown into the same bucket. That is a problem because they solve different tasks.
OPC UA helps provide industrial data in a structured way. MQTT distributes information. The Unified Namespace defines how that information is organised and used consistently.
Sounds simple. Yet in projects, these things are constantly mixed up. And suddenly an MQTT broker is called a “UNS” – even though all that really happened was that data was moved from one place to another.

By Martin Waßmann – IT/OT Experts

Few topics mix up terminology as quickly as Unified Namespace

An MQTT broker gets installed and suddenly there is a UNS. A machine supports OPC UA and is therefore considered “integrated”. Or MQTT and OPC UA are treated as competing technologies, as if you had to choose one or the other.

That quickly sends projects in the wrong direction. Because OPC UA, MQTT and Unified Namespace solve different problems.
They can work extremely well together. But only if it is clear what each of them is actually there for.

The short version:

• OPC UA helps me provide and understand industrial data.
• MQTT helps me distribute information.
• The Unified Namespace defines how that information becomes structured and reusable across the organisation.
• And yes: this is deliberately simplified. But for architecture decisions, this distinction is far more important than the next discussion about broker features.

In short

OPC UA is an industrial communication standard that can transport not only values, but also describe structures, data types and semantic information.

MQTT is a lightweight publish/subscribe protocol. A publisher sends messages to topics, a broker distributes them, and subscribers consume the information relevant to them.

A Unified Namespace, on the other hand, is not a protocol. It describes a shared information and architecture structure through which industrial information can be provided and used consistently.

So the three terms are not interchangeable.

OPC UA just gets data out of the PLC, right?

No. That simplification misses quite a lot.

One of the strengths of OPC UA is that data does not have to be exposed merely as anonymous addresses.
A PLC or OPC UA server can provide structures, objects, variables, data types and relationships.

Instead of just:

DB17.DBD24

an application may receive something much closer to the actual machine:

FillingMachine

• State
• Speed
• GoodCount
• RejectCount

That is a significant difference.

Especially when you are no longer integrating one machine, but eventually hundreds of them.
But the same rule applies here:

Just because a machine speaks OPC UA does not mean its data structure is automatically good.

I have seen enough OPC UA servers that ultimately expose little more than PLC variables in a slightly nicer interface.
The technical access is there. A useful information model often is not.

MQTT: distribute information without connecting everyone directly to everyone else

MQTT solves a different problem.
Traditional integrations often look like this:

Machine → OEE
Machine → Reporting
Machine → MES
Machine → Analytics

Every new application creates another connection to the data source.
A publish/subscribe model can reduce this direct coupling.

A data source might publish:

site1/line2/machine5/state

and different applications can subscribe to exactly that information.
The machine does not need to know whether OEE, reporting or an AI model is consuming it.
That is powerful.

Especially as the number of data sources and applications grows.
But MQTT initially answers only one question:

How do I distribute messages?

MQTT does not automatically answer:

• How do we name assets?
• Which information belongs to a machine?
• What does state = 2 actually mean?
• Which structure applies across all sites?
• Who is allowed to change topics?
• Which information is authoritative?

And that is why this sentence matters:

MQTT is a very good transport mechanism. But a transport mechanism does not define a data architecture.

The broker is not the Unified Namespace

This is probably the most common misconception. And it is worth repeating.
Typical scenario:

1. An MQTT broker is installed.
2. Machines or gateways publish data.
3. Applications subscribe to topics.
4. The whole thing gets labelled “Unified Namespace”.

Technically, that setup may work perfectly well.
It still does not necessarily make it a useful UNS.

A real-world example:

machine01/db17/tag27
machine02/plc/status_1
line3/maschine4/var_127
site-b/packaging/m5/state

Everything is on the same broker.
Everything is reachable.
And yet nothing has actually been unified.
The transport architecture has been centralised, while the semantic complexity has simply been moved onto the broker.

A shared broker is not automatically a shared information model.

This is where many UNS discussions become far too technical, far too early.

So where does the Unified Namespace come in?

A Unified Namespace tries to establish a consistent structure for relevant industrial information.

For example:

Enterprise

└─ Site

└─ Area

└─ Line

└─ Asset

├─ State

├─ Production

├─ Quality

└─Energy

Whether this exact hierarchy is right depends on the company.

The important point is something else:

An application should not have to reverse-engineer information from vendor-specific structures.

It should know where information can be found, what it is called and what it means.

Conceptually, this creates something like:

As-Is Machines

different, technical, vendor-specific

↓

Integration / Mapping / Context

↓

Unified Namespace

consistent, understandable, reusable

↓

OEE | MES | Reporting | Analytics | AI

That middle layer is often underestimated.
Because someone has to decide how technical machine data becomes information that can be used across the organisation.

So OPC UA at the bottom and MQTT at the top?

That would be a nice simplification.

Unfortunately, reality is usually messier.

One machine may support OPC UA. Another may use Modbus TCP. An older system may have to be integrated via S7. Another application offers a REST API. And perhaps a modern edge controller already publishes MQTT directly – but does not allow you to change the data structure.

That is Brownfield.

So I would not design an architecture backwards from the protocol I would like to use.

A machine should be integrated using the most sensible interface available.

That may be OPC UA. It does not have to be.

What matters afterwards is that the information provided fits into the shared structure.

Or, put more simply:

The integration towards the machine may be heterogeneous. The information structure above it should ideally no longer be.

That matters far more to me than “OPC UA or MQTT?”.

MQTT or OPC UA? The question itself is part of the problem.

This question comes up regularly:
Should we use OPC UA or MQTT?

In many cases, the answer is:
Both. For different jobs.

For example:

PLC / Machine

↓

OPC UA

↓

Edge / Integration

↓

MQTT

↓

Unified Namespace

↓

Applications

This is only one possible architecture, but it is easy to understand.

OPC UA can provide structured access to machine information.

The integration layer decides which information is actually needed and how it should be mapped into the target structure.

MQTT then distributes that information event-driven to other systems.

And the UNS defines how that information is organised in the larger context.

There is no competition between OPC UA and MQTT. It is simply a very practical division of labour.

But OPC UA supports Pub/Sub too, doesn’t it?

Yes. It does. Great.

And turning that into a technology religion is unnecessary.
OPC UA can do more than traditional client/server communication and also supports publish/subscribe mechanisms.
MQTT, in turn, can transport far more than simple numerical values.

So the technologies overlap in some areas.
That does not change the actual architecture question:

Which problem should be solved at which point?

If an existing architecture cleanly meets the requirements using OPC UA PubSub, nobody needs to introduce MQTT merely because everyone at a conference is suddenly talking about UNS.
Conversely, MQTT should not be rejected simply because OPC UA can theoretically provide publish/subscribe as well.

Architecture should come from requirements – not loyalty to a particular technology.

A Brownfield example

Imagine a production line with machines from different generations.
Machine A provides a well-structured OPC UA server.
Machine B also provides OPC UA, but effectively exposes little more than a list of technical PLC tags.
Machine C has no OPC UA server at all and has to be integrated through another protocol.

For the applications above them, those differences should ideally no longer matter.
All three machines could ultimately provide the same information:

• State
• CurrentOrder
• GoodCount
• RejectCount
• Speed

This is where the actual value emerges.

Not because every machine speaks the same protocol.
But because different machines ultimately speak the same language towards the applications.
For Brownfield environments, that is a far more realistic objective than trying to technically standardise every machine first.

Data model. Data model. Data model. Topic structure?

Another typical discussion:

What should our MQTT topic structure look like?

Again, people often start talking about syntax far too early.

enterprise / site / area / line / asset

Looks great.
It can still carry terrible information.

The more important questions are:

• What is actually an asset in our organisation?
• How do we represent lines and sub-assets?
• Where does a production order belong?
• Who owns the machine state?
• How are quality information and events modelled?
• How do we handle versions?
• Which information belongs permanently in the UNS – and which does not?

A good topic structure can make an information model visible.
It cannot replace the information model.

The whole thing in one sentence

If I had to reduce the three terms to practical questions:

OPC UA:
How do I access and understand industrial data?

MQTT:
How do I distribute information in a decoupled, event-driven way?

Unified Namespace:
How do I organise that information so it becomes reusable across the organisation?

This is not technically complete.
But it prevents about 80 percent of the wrong architecture discussions.

Frequently Asked Questions

Is MQTT required for a Unified Namespace?

No. MQTT is commonly used in UNS architectures because publish/subscribe and the decoupling of data sources and applications fit the concept very well. But the Unified Namespace itself is not an MQTT standard.

Is OPC UA better than MQTT?

That question is too simplistic. The two technologies address different requirements and can be used together.

Can a machine publish directly to MQTT?

Yes.
Whether that is sensible depends, among other things, on whether the machine can reliably provide the required data structure, context, security and operational capabilities.

Do I have to copy OPC UA data one-to-one into MQTT?

No.
In fact, that is often exactly what you should not do.
The integration layer can select relevant information, normalise it and map it into the shared information model.

Is the MQTT broker the central database of a UNS?

No.
An MQTT broker distributes messages.
Persistence and historisation are separate requirements and should be addressed deliberately in the architecture.

Does all machine data belong in the UNS?

No.
Which data should be published depends on requirements, reusability and ownership – not on the principle of “let’s collect everything first”.

About the Author

Martin Waßmann is the founder of IT/OT Experts and supports manufacturing companies with digital strategy, IT/OT integration and scalable production data architectures.

His focus includes Brownfield integration, Unified Namespace, MQTT and OPC UA.

More about Martin Waßmann