<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1128054299183456&amp;ev=PageView&amp;noscript=1">
AI in Manufacturing Article 02 of The AI in Manufacturing Playbook

What a Unified Namespace Does (and Doesn't Do)

A unified namespace is often pitched as the foundation for AI on the shop floor. That part holds up. What it does on its own is narrower, and essential to know.

A Scenario From the Floor

A Thursday spent in spreadsheets

Scrap on Line 2 jumped on Tuesday night, and your quality engineer wants to know why. The machine data is in the historian. The job and the operator are in MES. The material lot is in ERP, the last maintenance visit is in the CMMS, and the inspection results are in the quality system. She exports all five, lines up five different timestamp formats in one spreadsheet, but it takes her till the end of Thursday to get a solid answer. Line 2 has run four more shifts by then.

Nobody in that story did anything wrong. Every piece of data she needed existed on Tuesday night. It lived in five systems that were never built to talk to each other, and she was the integration.

The wiring problem it fixes

Most plants connect their systems point to point. MES talks to ERP through one interface. The historian feeds a dashboard through another. Every new application needs its own link to every source it has to monitor, so ten systems that all share data can mean up to 45 separate connections, each with its own owner, format and way of failing. The eleventh system can add ten more (one to each of the systems already there).

A unified namespace changes the shape of that wiring. Instead of connecting systems to each other, each one connects once to a shared hub, usually an MQTT broker. PLCs, machines, MES, ERP and the quality system publish their current state to it. Anything that needs the data subscribes. The historian subscribes, the dashboards subscribe, and a new analytics tool can subscribe on its first day without anyone writing a new interface into MES.

Two design choices make it work on a real floor. Data is organized in a hierarchy that mirrors the plant, typically following the ISA-95 model, from enterprise down through site, area and line to the individual machine. The spindle temperature on Machine 4 lives at an address anyone can read, something like plant-1/machining/line-2/machine-4/spindle-temp. And systems publish when a value changes instead of being polled on a timer, so the namespace always holds the latest reading without flooding the network.

MQTT and OPC UA, the two protocols most namespaces run on, are open standards. The namespace doesn't belong to whichever vendor installed it.

What you get

You get one place to look. The current state of every connected machine and system sits in a single structure, so the question your engineer used to spend a whole day on becomes a simple query.

You get context that survives the trip. Article 01 of this series described how data loses its meaning as it passes up the old layered stack, one system at a time. In a namespace, a reading arrives with its location in the plant attached. A temperature is Machine 4's spindle temperature, on Line 2, during Job 5531.

Adding an application becomes a configuration task instead of an integration project, because it subscribes to the namespace rather than to each source system. That's the practical payoff most teams notice first: the integration backlog stops growing every time someone wants a new dashboard.

What it doesn't do

This is the more useful half if you're about to sign something.

It doesn't keep history

A namespace holds current state. "What is the spindle temperature right now" is its job. "What was it every second last Tuesday" belongs to a historian or database that subscribes to the namespace and records what it sees. Root-cause work always needs history, so plan the historian as part of the project, not as a follow-up.

It doesn't clean your data

If one line reports temperature in Fahrenheit and another in Celsius, the namespace will publish both, faithfully. If operators pick "Other" as the downtime reason because it's first in the dropdown, the namespace will broadcast "Other" in real time to every system that subscribes. Bad data moves faster. It doesn't get better.

It doesn't design itself

The hierarchy, the names, the units and the choice of which tags matter are decisions your people make. Get them wrong and you have a faster version of the mess you had before. This is the step that takes the time, and most of it is conversation with the people who are in charge of the lines, not software.

It doesn't decide anything

A namespace will tell every subscriber that Machine 4 stopped at 9:17. It has no idea that the job on Machine 4 is meant to ship Friday, or that Line 4 has the tooling and the open capacity to take it. That reasoning is the orchestration layer described in Article 01. Orchestration can't work without the namespace underneath it, and the namespace can't do orchestration's job. Your MES and ERP stay where they are, too. They remain the systems of record for work orders, genealogy, costs and compliance. The namespace sits beside them and makes their data visible to everything else.

It doesn't secure itself

Putting plant-floor and business data through one hub makes that hub worth protecting. It needs authentication, permissions set topic by topic, and a considered boundary between the plant network and the business network. Decide who can publish and who can only read before anything connects, because retrofitting permissions onto a live namespace is slow work.

Bad data moves faster. It doesn't get better.

Where to start

Don't wire everything. Pick the problem that costs the most, then connect the handful of data points that describe it. For unplanned downtime that's usually machine state, the reason code, the job running at the time and the part counts. Get one line publishing clean, well-named data and make sure someone actually uses it. Then add the next line.

The naming convention you set on that first line becomes the standard for the whole plant. It's worth an afternoon with the supervisors and engineers who will read it every day.

The first project, not the last

Every AI application on a production floor, whether it predicts a failure, diagnoses a quality drift or reroutes a job, needs to read what is happening across your systems at the moment it happens. The namespace is how it reads. That makes it the natural first project. What the software does with what it reads is the subject of the rest of this series.

Thought Series

The AI in Manufacturing Playbook
  1. 01The Difference Between Monitoring and Orchestration
  2. 02What a Unified Namespace Does (and Doesn't Do)
  3. 03Coming Soon
  4. 04Coming Soon
  5. 05Coming Soon
  6. 06Coming Soon
  7. 07Coming Soon
Close the Gap

Your operation is ready for orchestration.

If you're still relying on monitoring alone, you're running behind on recoverable time, margin, and customer trust. We work with manufacturers to close that gap.

Let's Talk