Unified Namespace vs. MES and Historian: What Actually Replaces What?

KNOWLEDGE | Industrial Data

A Unified Namespace is often presented as the new central data platform.
And it usually does not take long before the question comes up:

Do we still need an MES?
What about the historian?
Couldn’t the UNS simply take over everything?

The short answer is: No. And it should not.
A UNS has a different job. It provides production information consistently and reduces dependencies between data sources and applications. An MES supports and controls operational production processes.
A historian stores process data over time.
These are different responsibilities – even if the systems overlap in some areas.
The interesting question is therefore not which system “wins”.
The interesting question is which responsibility should sit where in future.

By Martin Waßmann – IT/OT Experts

The problem usually starts before the technology

In production environments that have grown over time, systems often end up doing far more than they were originally designed for. An MES gets another interface. The historian suddenly becomes the universal data source. A reporting system contains its own business logic. A database gets a few more tables. And eventually nobody really knows which system is actually responsible for which information. That can work for years. Until another use case arrives.

Then the search starts again:

• Where do we get the machine state from?
• Is the current production order authoritative in the MES or ERP?
• Do we read the temperature directly from the PLC or from the historian?
• Why does reporting calculate OEE differently from the MES?

This is exactly where a Unified Namespace can help. But not by replacing all the existing systems.

What does a Unified Namespace actually do?

A UNS makes relevant production information available through a shared structure.
That information can originate from very different sources. The machine state may come from the PLC. The production order from the MES. A quality status from another system.
The UNS does not magically turn all of this into a new source of truth.
Instead, it makes information available in a way that other systems can find and use consistently.
That distinction matters.

An MES has a different job

An MES is not a data broker.
And ideally, it should not become one. An MES supports operational production processes. Depending on the system and implementation, this may include:

• production order management
• production confirmation
• material tracking
• quality processes
• recipes
• operator guidance
• OEE
• traceability

An MES contains its own logic, states and processes.
A Unified Namespace does not replace that logic.
If the MES decides which production order should run next, that responsibility should not suddenly move into an MQTT broker. What can change, however, is this:

The MES does not necessarily have to integrate every machine individually anymore.

It can consume information from a shared production data structure and publish its own information back into that structure. That reduces coupling. And that is where the architectural value lies.

And the historian?

With a historian, the distinction is even clearer. A historian primarily answers one question:

What did a process look like at a particular point in time or over a period of time?

Temperatures, pressures, speeds, states, measurements – often at very high temporal resolution. That is different from a Unified Namespace. An MQTT broker does not automatically retain years of process history. And even if a platform can persist messages, that does not suddenly make it a fully capable historian. A UNS primarily deals with current or event-driven information. Historical analysis still requires suitable storage. That may be a traditional historian.
It may also be something else.
But the requirement does not disappear just because a UNS exists.

So should we just use the historian for everything?

That is another common reaction. And my answer is clearly: No.

If I want to analyse historical process data, a historian can be an excellent source. It becomes problematic when the historian turns into the central integration platform for everything. 
Applications then repeatedly query information that could have been provided as events. Machine structures are recreated inside a historian-specific model. Current states have to be reconstructed from historical records. And eventually every new application depends on the same platform again. Technically, that may work. Architecturally, it is not the same thing.

Is historisation really the same as providing information?

From my perspective: clearly not.

So where does the truth live? Is there a Single Source of Truth?

This is an interesting question, and one that comes up regularly. Take a production order. Where is it authoritative?

ERP?

MES?

UNS?

The answer should not be:
A little bit everywhere.

The UNS should normally not become the owner of the business truth simply because it transports the information.
If the MES is authoritative for the current production order, then the MES remains the source.

It simply publishes that information in a way that other systems can use.

The same principle applies to things such as:

• recipes
• quality approvals
• production planning
• master data
• machine states

The UNS should make responsibilities visible, not blur them.

Frequently Asked Questions

Does a Unified Namespace replace an MES?

No. An MES contains operational production logic and supports or controls production processes.
A UNS makes information available in a structured way to different systems.

Does a UNS replace a historian?

No. Historisation is a separate requirement.
A UNS provides information, but it does not automatically replace long-term storage and analysis of time-series data.

Can an MES publish data into a UNS?

Yes.
An MES can consume information from the UNS and also provide its own information, for example production order or production context.

Does the historian have to connect directly to machines?

Not necessarily.
A historian can also consume information from a shared data structure.
Whether that makes sense depends, among other things, on data rates, required resolution and availability requirements.

Where is the “Single Source of Truth”?

Not necessarily in the UNS.
The system responsible for a particular business or technical fact should remain the authoritative source.
The UNS makes that information available to other systems.

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.
More about Martin Waßmann