Unified Namespace explained:what it is, when you need it, when you don't

In the project I am working on, the plant is new, and almost every quarter one or two machines arrive to be integrated. None is like the previous one. One speaks OPC UA, one FINS, one is a Siemens SIMATIC PLC. One writes a CSV for every part it machines, another a text file. One exposes a TCP/IP socket, the last one a REST API. Every time there is something new.

If every new machine forced us to touch all the systems that use its data, we would redo half the project every quarter. What keeps it standing is simple to say: for each machine there is an adapter that speaks its language, and a mapper that brings everything back to one standard object. From there on, for the rest of the system, one machine is as good as another.

That is the idea behind the Unified Namespace, and when I design industrial middleware I think about it from the start, even when there is only one machine. Much of what is written about it comes from broker and platform vendors. Here is how I actually use it.

01What it is

A Unified Namespace (UNS) is a shared communication recipe. Different machines and software exchange information following the same rules, for both reading and writing.

In practice there is a central point, usually an MQTT broker. Each system publishes there what it knows and subscribes to what it needs. Information has an address that says where it comes from and what it is about. For example:

plant-a/assembly/line-2/screwdriver-01/state
plant-a/assembly/line-2/screwdriver-01/alarms
plant-a/assembly/line-2/order/request

The advantage is not the broker. It is that whoever acquires the data does not need to know every system that will use it, and whoever consumes it does not need to know the quirks of every machine. Coupling between components drops, and adding a machine or a system becomes local work instead of a chain of changes.

02What it isn't

03ISA-95 yes, but not mechanically

The address structure usually follows the ISA-95 hierarchy: site, area, line, machine. It is an excellent starting point, and the standard was updated recently: Part 1 was revised in April 2025.

The mistake is applying it mechanically. First I look at the context: the systems involved, the information to exchange, the logic to implement. Then I adapt the convention to the project. What matters is that it is clear and shared: anyone must understand where a piece of information is and how to read it, without a hierarchy deeper than needed.

04Same rules, not the same place

{
  "type": "telemetry",
  "workcenter": "line-2/screwdriver-01",
  "timestamp": "2026-11-03T08:15:02Z",
  "data": {
    "torque_nm": 12.4,
    "result": "ok"
  }
}

This does not mean storing everything in the same place, or giving everything the same lifecycle. Orders, recipes, alarms and telemetry follow the same communication model, each with its own handling.

05MQTT or Sparkplug B

I have studied Sparkplug B out of interest, but never implemented it in a project. It is not wrong: when I control the architecture and the parties involved, I simply don't add constraints without a concrete benefit.

06How much to build

I introduce a common structure even with a single machine. Today it is one, tomorrow it could be ten, and with good foundations you grow without redoing everything.

07When the broker is gone

Acquisition must depend as little as possible on the broker and downstream systems. If the broker does not answer, I keep collecting data from the machines, within the available resources, and handle locally whatever needs no external answer. For events I cannot lose there is a persistent buffer, recovered when the connection returns.

Not everything can go on, though. I cannot confirm an order change or a rescheduling if the system that must answer is unreachable. The failure has to be handled without losing information and without pretending an operation succeeded. I wrote about this in The network goes down, the line doesn't.

08The most common mistake

Thinking a UNS is simple and immediate. First you gather the requirements: who the parties are, what information they exchange, what logic must be supported. Only then do you define structure and rules.

Otherwise you get a formally tidy structure that solves nothing. Systems stay dependent, data keeps different meanings, exceptions pile up in the middleware.

From the outside everything looks in order: one single point, clean cables. Just lift the lid.

The tangle hasn't gone away: it has been moved into one place.