Unified Namespace (UNS): Understand the Problem First. Then Talk About MQTT.
KNOWLEDGE | INDUSTRIAL DATA
A Unified Namespace makes production data consistently available across machines, lines and sites.
Here I explain what a Unified Namespace actually is, which problem it solves and when it makes sense to use one.
Technology is not an end in itself. And just as important: an MQTT broker alone does not make a UNS.
By Martin Waßmann – IT/OT Experts
What is a Unified Namespace?
Unified Namespace has become one of those topics where people quickly start talking about MQTT, brokers and topics.
But the real problem usually starts much earlier.
A machine provides data for KPIs, often OEE. Then reporting needs the same information. Later, traceability is added, perhaps energy monitoring, analytics or AI. Every application gets connected somehow and, at some point, you have a lot of working solutions – but no scalable data architecture. Maintainability becomes another issue. In the worst case, you have also created an insecure connection between IT and OT.
That is exactly where a Unified Namespace can start to make sense.
Not because MQTT happens to be fashionable. Not because there is suddenly a broker between OT and IT. But because production information is structured once, enriched with context and made available to different applications.
Definition: A Unified Namespace (UNS) is a shared, structured data layer for industrial information.
Machines, equipment and systems provide relevant information in a way that other applications can clearly understand and use. Not only technically, but also in terms of meaning.
It is therefore not simply about moving a value from A to B.
An application should not just know:
DB17.DBX4.2 = 1
but, for example:
Plant → Line → Packaging Machine → Operating State = Production
The difference sounds trivial. In practice, this context determines whether a data architecture can scale later on.
The real value therefore does not come from data being “centralised”. What matters is that different systems understand the same meaning of the same information.
A UNS is therefore less a single product than an architecture and information concept.
Which problem does a UNS solve?
Most companies do not suffer from a lack of data. The problem is usually that:
- it sits in different systems,
- it is named differently on every machine,
- it lacks consistent context,
- it has to be integrated again for every new use case,
- and, eventually, nobody really knows which application gets which information from where.
And somehow, this works surprisingly well – for a while.
One machine, one application – no problem. Ten machines, three use cases – still manageable somehow.
But at some point there are more and more lines, multiple sites and a growing number of applications. And with that, the number of dependencies increases.
A small change on one machine suddenly creates chaos across several applications and the integration work starts all over again.
That is the point where the architecture itself becomes the problem.
A Unified Namespace tries to solve exactly this problem: production information is put into a shared context once and can then be used by multiple applications.
How does a Unified Namespace work?
The basic idea is simple:
Production information is not provided separately for every application.
Instead, relevant information is collected once from machines and systems, put into a shared context and then made available to different applications.
Machine data can, for example, be acquired via OPC UA, Modbus or proprietary vendor interfaces. Relevant information is then transformed into a defined structure and made available through the Unified Namespace.
Such a structure might follow site, production area, line, machine and function – for example based on ISA-95.
Instead of a typical technical tag such as:
DB17.DBX2.1
an application should understand something like:
Plant → Line → Packaging Machine 1 → State
That is how a technical data point becomes information with context.
The question changes from:
How does application X get data from machine Z?
to:
Which information does machine Z provide, and which applications need that information?
For scaling, that is a major difference.
Why does MQTT keep coming up?
MQTT is an open, event-driven publish/subscribe protocol standardised as ISO/IEC 20922.
So much for the theory.
MQTT works very well for this kind of architecture because information does not have to be queried traditionally by every application.
One system publishes information. Other systems that need it subscribe to it.
That reduces direct dependencies between the data source and the applications.
But:
MQTT only solves the transport. By design, it leaves a lot of freedom when it comes to structure.
If I simply publish every PLC tag unchanged to an MQTT broker, I may have introduced MQTT – but I still do not have a Unified Namespace.
In the worst case, I have simply distributed my existing data chaos faster.
Congratulations.
A functioning UNS therefore also needs, among other things:
- a structure that people can understand,
- clear naming,
- context,
- rules for changes,
- and clarity about who is responsible for which information.
→ How MQTT, OPC UA and UNS work together is a separate topic. We cover it here.
Who needs a Unified Namespace? Who benefits from it?
Not every company needs a Unified Namespace.
If one machine needs to provide data to one application, a direct connection may be the best solution.
And if existing systems already provide the required information flow in a clean and scalable way, there is no reason to introduce another architecture just for the sake of it.
A UNS becomes particularly interesting when:
- several applications need the same production data,
- many different machines need to be integrated,
- multiple sites should use a common data structure,
- the same integrations are being built again and again,
- or new use cases would otherwise create more and more point-to-point connections.
At that point, it makes sense to stop thinking only about the next interface and start thinking about the shared data architecture behind it.
And what does a Unified Namespace replace?
Again: less than is sometimes suggested.
A Unified Namespace does not suddenly replace MES, ERP, historians or other production systems.
Those systems have their own jobs.
What a UNS can do is prevent every system from having to build its own connection to the same data sources.
That is the important difference.
I would therefore not treat a UNS as a new central super-platform that replaces everything else.
The better question is:
Which task does each system perform, and which problem is it actually solving?
If I use an MES only to calculate production KPIs, while hardly using the functions it was originally designed for, I should at least ask whether those KPIs could be calculated closer to the source by a service around the UNS instead.
→ Unified Namespace vs MES and Historian: What Actually Replaces What?
Brownfield? Yes, please.
Existing factories rarely look like a Greenfield architecture diagram.
Machines from different manufacturers and generations. Some provide OPC UA, others Modbus.
Data models?
Is that something you can eat?
This is exactly where a UNS becomes interesting.
The idea is not to pass all those machine-specific differences on to every application.
Instead, the dependency is resolved closer to the source.
The information made available in the UNS is standardised and no longer machine-specific.
What goes wrong? Where are the common mistakes?
Many UNS projects start with technology:
Which broker should we use?
That is far too early.
Other questions should come first:
- Which information do we actually need to solve the problem?
- For which use cases?
- Which systems are the source of that information?
- How should a machine or asset be identified consistently?
- Who decides on structure and naming?
- What happens when a second or fifth site is added later?
If these questions remain unanswered, even the best broker cannot turn the result into a clean data architecture.
Or put differently:
UNS projects rarely fail because MQTT does not work. They are more likely to fail because nobody defined what the data is actually supposed to mean.
Frequently Asked Questions
Is MQTT the same as a Unified Namespace?
No. MQTT is a communication protocol. A Unified Namespace also defines how industrial information is structured, contextualised and made available to different systems.
Does a UNS require MQTT?
Not necessarily.
However, MQTT is very well suited to UNS architectures because of its publish/subscribe model and is therefore commonly used.
Does a UNS replace an MES?
No.
An MES supports operational production processes. A UNS makes information available to different systems.
The two can complement each other very well.
Does a UNS also work in Brownfield environments?
Yes.
In fact, a shared information structure can be particularly useful in Brownfield environments because machines and control systems often expose very different interfaces and data models.
Is a UNS only relevant for large corporations?
No.
Company size is not the deciding factor.
What matters is how many data sources, applications and integrations need to work together – and whether that structure needs to scale in future.
Are you currently discussing UNS, MQTT or a new production data platform?
Before choosing technology, you should be clear about which problem the architecture is actually supposed to solve.
That is exactly where we start.
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.