Introduction to Unified Namespace (UNS): Accelerate Your Digital Transformation in Metalworking

Guides — 04 dec. 2024 · 13 min read

Digital transformation keeps disappointing because tools get bought before the data architecture exists to connect them. I explain the Unified Namespace in plain words: one live place where all factory data comes together, organized the way the business is organized.

One shared source of truth | via FLUX.2 Pro

Do you remember what the Smart Factory promise sounded like? Everything connected. Dashboards on the wall. AI predicting a breakdown before it happens. Operators with tablets instead of paper.

Maybe you invested in it. A new ERP. A link to the laser. A planning tool. A dashboard. Then another machine came in, and another link went in with it.

And what did you actually get? I have stood in a lot of metal shops over the past ten years, and the answer is usually the same: a plate of spaghetti.

This article is the way out. More and more metal companies replace the spaghetti with a Unified Namespace (UNS): one live place where all factory data comes together, organized the way the business is organized. I will explain what it is, why it is different from a database, what a historian adds, which tools carry one, and how you start with one machine this month. All of it in plain words.

⚠️

Disclaimer: this article comes from my own architecture projects and the lessons of my mentor Walker Reynolds. Tools and platforms change. Always do your own due diligence before you build.

How the spaghetti grows

Every machine and system starts as its own island. One shared structure connecting them all is what replaces the spaghetti. | via FLUX.2 Pro

Nobody chooses the spaghetti. It grows on its own, one sensible decision at a time, until everything is wired to everything. I have watched it happen from the inside, doing this work.

The ERP works, so far so good. Then a planning package arrives, because planning inside the ERP was clumsy. A new machine comes in, another brand, with its own software, so another link gets built. The laser talks to the ERP, but it also talks directly to the planning tool, because the ERP interface was not good enough. From there a line runs to a dashboard. XML here, CSV there, an API in between.

Now count the suppliers: five of them, each with consultants who understand their own system and point at each other when something breaks. Meanwhile your people type the same data into three screens. And still someone stands next to it all with an Excel sheet, because that sheet is the only place where everything comes together.

The math says this never stabilizes. Ten systems can need up to 45 separate connections, each one custom work, each one breakable by the next software update.

This is a big reason digital transformation projects disappoint. McKinsey's research found that fewer than 30 percent of digital transformations succeed, and only 16 percent lead to lasting improvement. A common pattern behind the failures: tools bought before the data architecture existed to connect them.

I wrote about this before:

Meanwhile the demands only climb. Customers who track a pizza on a map expect a live answer to "where is my order". Every AI tool you will try is only as good as the data you can feed it. And the EU's Digital Product Passport will ask for traceability per part. All of it needs data that is current, structured, and in one place. Exactly what the spaghetti cannot deliver.

The eight steps every production company loops through

Step back from the systems for a moment and look at the work itself. Every production company, whatever it makes, loops through the same eight steps, every day:

Sell. A quote goes out, an order comes in. Your CRM and quoting tools.
Plan. The ERP decides what must be made, and when.
Manage production. An MES, or a whiteboard, translates the plan into work for the floor.
Produce. Machines run. Their controls and sensors know exactly what is happening.
Warehouse. Material in, finished product out. The WMS keeps count.
Ship. The product leaves the building, with papers.
Invoice. The bill follows the shipment.
Match. The books confirm that what was sold, made, shipped, and billed all agree.

Every step generates data. Every step needs data from the other steps. And in most shops that data flows point-to-point between systems, or worse: on paper, retyped, with Excel in between. That is the spaghetti, seen from the inside.

Now flip the picture. Same eight steps, but with a hub in the middle. The ERP talks to the hub. The machines talk to the hub. The planning tool talks to the hub. Nothing talks directly to anything else. Every system drops what it knows into one shared place and picks up what it needs from that same place.

That hub, and the naming structure inside it, is the Unified Namespace.

🧭

Want to see your own eight steps on paper? My UNS design guide walks you through modeling your factory before you touch any software, with a fill-in template. Free for members.

What is a Unified Namespace?

A Unified Namespace is an architecture in which every system in your business publishes what it is doing, the moment it happens, to one central place, in one shared structure, and reads what it needs from that same place. It is a design decision, the way "client-server" is a design decision. You then choose tools to implement it.

💡

In one sentence: a UNS is the single, live source of truth for the current state of your factory, organized the way your business is organized.

I learned this architecture from Walker Reynolds, my mentor in industrial digitalization. In his UNS Handbook he pins down what a UNS is in five statements:

The structure of your business and all of its events.
A single source of truth for all data and information of the business.
The place where the current state of the business lives.
The hub through which the smart things in your business communicate with one another.
The architectural foundation of your Industry 4.0 and digital transformation initiative.

Behind those statements sit a handful of characteristics, and each one means something concrete for your shop:

Agnostic. It does not care whose machines you run or which ERP you keep. Any brand can join.
Edge-driven. Data is published where it is born, at the machine, instead of being pulled out by a central system.
Report by exception. Systems speak when something changes and stay quiet otherwise.
Lightweight. The messages are small and simple, so ordinary hardware and networks carry them with ease.
Open architecture. It runs on open standards, so joining never requires one vendor's permission.
Full stack. One structure covers everything from the sensor in the machine to the software in the cloud.
Organized like the business. The data tree mirrors your company, so anyone can find anything.

Agnostic is the load-bearing word. A UNS does not depend on any product or technology, and that is what makes it a foundation instead of another vendor decision. Walker's video explanation is where I send everyone who asks:

Adoption backs the architecture up: Deloitte's 2025 smart manufacturing survey found 54 percent of manufacturers adopting a unified data model standard.

Is it a product? Is it a database?

Two questions come up in every presentation I give, so let me answer them right here.

"So where do I buy one?" You do not. A UNS is something you build to, like a house from an architect's drawing. The drawing decides where the walls and pipes go. Which bricks you use is a separate decision, and you can change brick supplier halfway without moving a wall. In a UNS, the broker, the connectors, and the databases are the bricks. The naming structure and the one-connection rule are the drawing.

"Is it a database, then?" Also no, and this distinction matters. A database is built for asking questions afterwards. "Give me last week's orders." You ask, it answers. A UNS is event-driven: it tells you what happens, at the moment it happens. Machine starts: event. Order comes in: event. Status changes: event. A live stream of the current state of your factory.

You can still look things up. The namespace holds the last known state of everything (a retained message, in MQTT terms), so a system that connects at 09:00 immediately knows the state of the whole factory. And for the full history you attach a historian, which gets its own chapter below, because it changes who owns your data.

Hub and spoke: every system becomes a node

The hub and spoke model in one picture. Every system connects once, to the hub, and nothing talks directly to anything else. | via FLUX.2 Pro

A UNS follows a hub-and-spoke model. One hub in the middle, and every system connected to it as a spoke. Nothing connects to anything else directly.

In practice the hub is a message broker, a small piece of software that receives messages and hands them to whoever subscribed. It usually speaks MQTT, a lightweight publish-subscribe protocol built for exactly this. Every system around the hub is a node: your ERP, your CAM software, your machines, your dashboards, your future AI agents. Each node publishes what it knows and subscribes to what it needs.

It works the way the internet works. Devices from any vendor communicate because they agree on a protocol and an addressing scheme, and no single vendor owns the middle. In your factory, the addressing scheme is the namespace: a tree of topics organized like your business.

"Organized like your business" has a standard behind it: ISA-95, a plain naming convention for the levels of a factory. The common tree runs enterprise / site / area / line / cell.

So a topic like metalworks/utrecht/laser-cutting/line-1/trulaser-5030/status tells anyone, human or software, exactly where in the building that data lives: company, site, area, line, machine.

And one thing about the names: you pick them, in your own language if you want. They outlast every tool you will ever buy.

💡

The core principle: every system has exactly ONE connection, to the UNS. Not dozens of lines between systems. That is the difference between spaghetti and architecture.

Notice what happened to the ERP in this picture: it became one node among many.

UNS platforms and tools: a first look

You do not buy a UNS, you assemble one, and the parts have become good. The short version of who plays where:

UMH Core (open source): the whole UNS in one container, an embedded Kafka-compatible broker plus bridges for more than 50 machine protocols. The docs read like a course.
Ignition: the industrial platform many system integrators build a UNS around.
HighByte: industrial DataOps software, meaning it models your data and moves it between systems with the context attached. At home in data-driven companies.
HiveMQ: an MQTT broker built for enterprise scale, with strong ISA-95 and Sparkplug tooling.
EMQX: another heavyweight MQTT broker, built for serious message volumes.
Mosquitto (open source): a tiny broker that runs on anything. The default choice for a small-shop pilot.
Node-RED: the glue. A visual tool for moving and transforming messages between all of the above.

Each deserves a real evaluation against your shop's size and skills, more than an introduction can carry. Which one fits your shop is exactly what my members tooling comparison answers, with the same namespace built in different tools, side by side.

What AI changes for the Unified Namespace

When I started writing about the UNS, the pitch ended at dashboards: see your factory live. Since 2024 the pitch has moved, because AI moved.

An AI agent, a program that uses a language model to watch, decide, and act, can only act on data it can find and trust. Give it thirty disconnected systems and every AI project starts with a data-wrangling project. Give it one contextualized, real-time namespace and it has what it needs on day one. Walker made this case in his talk on why the UNS is the essential foundation for industrial AI and agentic operations, and Capgemini reached the same conclusion in its own research: the UNS is the scalable foundation for AI.

The plumbing for this is arriving fast. MCP (Model Context Protocol, a standard that lets AI models connect to tools and data sources) has entered the industrial stack: Litmus now runs an MCP server that lets a language model query live plant data directly.

My working model for this is 10-80-10: you set the direction, agents do the running work, you approve what matters. That is a story for another article. Here, the takeaway is simple: the namespace is what makes your factory readable to AI.

Start with one machine

You do not need a steering committee to test any of this, and you certainly do not need a multi-year transformation program that produces a report for the shelf. I call the alternative a lighthouse project: a proof in weeks. Stand up the hub, connect one machine, build one dashboard. Let everyone see it, then decide the next step from what you learned.

Think speedboat, and let the oil tanker follow: the pilot runs next to your existing systems and touches nothing. Step one is finding out how your machine talks, and that is exactly where the members build begins:

Lesson 1: Pick one machine and learn how it talks

Choose a single machine. Find its protocol (OPC UA, MQTT, or its own format). What you are looking for and where to find it.

vanenkhuizen.com

Questions I get about the Unified Namespace

Do I need Sparkplug?

Sparkplug is a specification on top of MQTT that standardizes how devices announce themselves and report their data. It is an ISO standard now (ISO/IEC 20237). The pattern I see in 2026: Sparkplug at the machine edge, then flattened to plain MQTT with your ISA-95 topic tree inside the UNS, because its fixed topic layout fights the business hierarchy you want the namespace to carry. Useful at the edge, never a requirement.

What does a UNS cost to try?

Measure it in effort, mostly. A pilot runs on open-source tools and hardware you already own, so the real investment is attention: a few evenings to stand up a broker, connect one machine, and decide on names. Those naming decisions are the actual work, and they stay yours no matter which tools you use later.

Can my old machines join?

Almost always. Many machines from the last fifteen years speak OPC UA (a standard industrial machines use to expose their data), and gateways translate OPC UA and older signals into MQTT. For machines with no data interface at all, retrofit sensors do the job: a power meter and a part counter tell you when it runs and how much it makes.

How do I keep a UNS secure?

With three habits. Every connection proves who it is before it may publish or subscribe. Every node gets access to exactly the branches it needs and nothing more (role-based access). And nothing is trusted just because it sits inside the building, the zero-trust principle. The broker runs on your local network, so nothing has to leave the building at all. A pilot on one machine, on its own network segment, is a safe place to practice all three.

How do I keep bad data out of the namespace?

Validate at the source: the node that publishes checks its own values before they enter the tree, so one broken sensor cannot poison everything downstream. Agree the naming and unit rules once, when you design the namespace, and write them down. Then watch the streams: because everything flows through one place, a sensor that starts sending nonsense shows up in minutes, on one screen, instead of surfacing in a report a month later.

UNS versus ERP or MES: which do I need?

Different layers. ERP and MES are functions: they hold orders, plan work, and track execution. The UNS is the layer those systems use to exchange data. In a UNS architecture your ERP becomes one node among many and your MES becomes a publisher and subscriber on the namespace. You will still want the functions. You will stop wanting them to be the center.

Keep learning: the UNS resource shelf

Everything above is enough to understand the architecture and start a pilot. When you want to go deeper, this is the shelf I point people to:

Walker Reynolds' UNS Handbook. The written definition from the source, on LinkedIn.
Walker on video. The original What is the Unified Namespace? explainer, the full UNS Masterclass, and Unified Namespace and Historians.
HiveMQ's UNS Essentials. A free, course-style introduction series from the MQTT broker company.
United Manufacturing Hub. Their flagship essay, the UNS basics video series, and the open-source code itself.
The standards. mqtt.org for the protocol, the OPC Foundation for OPC UA, and Corso Systems' plain-language ISA-95 101.
Event-driven thinking. FlowFuse's explainer of event-driven architecture in manufacturing.
My podcast episodes. Event-driven architecture and UNS with Wim Dijkgraaf, making a UNS real with Brian Pribe, and a real-world deployment case study.

The point is

Your factory already produces the data. A Unified Namespace is the choice to organize it, once, in one live structure you own, so every current system and every future one can use it. The architecture is proven, the tools are open, and the smallest useful version fits in a pilot of weeks.

Here is the thought I close my presentations with. ERP became the standard in a time when you could not build software yourself, and back then it was the right answer. Today you can build. So the question changes, from "which package solves my problem" to "which foundation lets me build the rest myself". The UNS is that foundation.

When you are ready to design yours, the full method is in the members library, free to join. The design guide walks you through modeling your factory on paper, then building it one machine at a time, with the fill-in template:

The rest of the build series and the tooling comparison live in the members library. And if you want a second pair of eyes on your architecture before you commit, that is what my services are for.

What would you want to see first on one live screen: order progress, machine status, or actual job cost? Tell me, I read every reply.

Acknowledgments. These insights build on the work of Walker Reynolds, my mentor in industrial digitalization, the team at United Manufacturing Hub, and my Smart Metals Podcast co-host Denis Gontcharov, who all helped make this concept tangible for metalworking.

Luke van Enkhuizen

Ik help metaalbedrijven meer halen uit de machines en de data die ze al hebben. Tien jaar in de industrie, nu schrijf ik over digitale transformatie, de unified namespace en AI-agents die hun werk echt doen.