5 Aug 2026 · 5 min read
I built a Unified Namespace myself. A third of the plant was invisible.
uns · open-source
If you have read anything about a Unified Namespace in the last couple of years, you have probably come away with two impressions. That it is mostly a message broker with sensibly named topics. And that the products being sold around it are therefore optional.
I believed roughly that, so I built one from parts to find out what is really involved. The building was easy. What I could not build is the interesting bit.
What one actually consists of
Two agreements, and that is genuinely all.
WHAT A NAMESPACE ACTUALLY IS
The first is the address. Every reading gets published under a name that spells out where in the business it came from: company, site, area, line, cell, tag. Anyone who has laid out a tag database has done this before.
The second is what travels inside. Every reading carries the time it was taken, the value, the unit, and whether the reading is trustworthy. So nobody downstream ever has to guess what a number means.
Neither of these is technology. They are agreements, written down. And a broker will happily carry data that ignores both of them completely.
For the test I built a plant of three sites, two areas each, two lines, two cells and six tags. A hundred and forty-four tags in total. The whole broker, carrying all of it, used under two and a half megabytes of memory. That number is why people look at a commercial product and wonder what exactly they are paying for.
Then I tried to find out what was on it
Here is the thing nobody mentions. A broker does not know what exists. It holds no list, no catalogue, no register of tags. It is a post office, not a phone book. It moves whatever it is handed and keeps no record of who normally writes to whom.
So the only way to discover what is on your namespace is to subscribe to everything and wait to see what turns up.
I did exactly that, for three minutes.
THE PART YOU CANNOT BUILD BY LISTENING
A post office. It delivers whatever it is handed, instantly and faithfully, and keeps no record of who normally writes to whom.
A phone book. Which tags exist, what they mean, what they should be reporting, and whether one has gone quiet. Somebody has to keep this true.
It climbs to ninety-six and stops. It never reaches a hundred and forty-four, and it never will, because the remaining forty-eight tags did not publish anything during the run.
They were not broken. They were correctly configured, correctly named, sitting on exactly the right addresses, doing precisely what they were designed to do. They simply had nothing to say.
WHO ANSWERED WHEN I LISTENED FOR THREE MINUTES
Pressures, flows, temperatures, run hours. Anything reporting on a timer turns up within a minute just by doing its job.
Blocked filter. Emergency stop. Configured, named correctly, working perfectly, and completely invisible until the day they matter.
And look at which ones they are. Real plants do not report everything at the same rate. Pressures and flows come every second. Run-hour counters come every half minute. And then there are the tags that only change when something happens: a blocked filter, an emergency stop.
Those are the tags anyone would most want to know exist, and they are exactly the ones that listening cannot find. A screen built by discovery will show you every pressure in the plant and no emergency stops at all. Not because they are missing, but because nothing has tripped yet.
You also cannot tell, by listening, the difference between a tag that is quiet and a tag that does not exist. Or between a tag that is quiet and a tag that died last Tuesday.
What stops bad data getting in
The other job I had assumed the structure was doing for me.
I mixed faults into about one publish in forty. Not silly ones, the sort that actually happen. A missing unit. A time recorded in seconds where everything else uses milliseconds. The word "OK" where the agreement says "good". A bare number sent with none of the surrounding information. An address typed by hand with a capital letter and a space in it.
WHAT THE BROKER REFUSED
The broker delivered every single one. All of them, faithfully and instantly, to everybody subscribed. It has no opinion about your agreement and it never will.
My checking program caught all of them, but only because I wrote the checking program, and only because the agreement existed as something a computer could read rather than a paragraph in a design document. Delete those forty lines and the bad data flows straight through, looking exactly like good data until something falls over much later.
The timestamp fault is the one worth sitting with. Forty-four readings arrived stamped as though they were taken in 1970. Nothing rejected them. In a historian they would either vanish into some ancient corner or quietly poison every average that touched them, and nobody would find out for months.
So what are you actually buying
Four of the five parts took an afternoon and run in two and a half megabytes. Anyone telling you a product is required for those is overselling.
The fifth cannot be built by listening, at any level of effort, because the information is not there to be found. Something has to hold a register: what tags exist, what they mean, what they are supposed to be reporting, and whether they have gone quiet. That register has to be kept true as the plant changes, and somebody has to do that.
Which is the real buy-or-build question, and it is not "could I run the free broker instead". Obviously you could. It is whether you want to own a register and a checking program and keep them honest for the next ten years, or pay somebody else to.
Plenty of teams should build it themselves. Three sites, a stable tag list, and an engineer who enjoys this sort of thing, and the home-made version is genuinely fine. You will understand your own data better for having built it.
Forty sites with a new one every quarter, and keeping that register true is the whole job, and it is the thing you are really buying.
What nobody should do is build the first four parts, skip the fifth, and call the result a Unified Namespace. That is a broker with tidy names, and a third of your plant will be invisible on it.
The setup, the agreement, the fault injection and every measurement are in the lab write-up. For the bought version of this, see United Manufacturing Hub, explained.
And if the broker at the centre of all this still feels unmotivated, the plain-language case for it is You don't buy a broker for the first consumer.
Keep reading
Newsletter
New essays, by email.
SCADA, cloud, AI, and the plant floor — a short email when something new is published. No noise, unsubscribe anytime.