I’ve noticed something funny about “manufacturing AI.” The AI part gets all the attention. The real success or failure usually happens much earlier, in the boring part. How you name data. Where you publish it. Whether anyone can trust it.
If your plant data is messy, inconsistent, or trapped in ten different systems, AI will not save you. It will just produce confident answers faster.
After working on multiple manufacturing data programs, this pattern repeats itself. The biggest blocker is rarely the algorithm. The real challenge is the data foundation.
That is why many teams that eventually succeed with AI start with two things first. A Unified Namespace (UNS). And Sparkplug B.
Not because they are trendy. Because they reduce chaos.
Why AI Struggles in Plants (and It’s Not the Model)
In most plants, the problem is not a lack of sensors. There are usually thousands of signals already available. The issue is that those signals are not organized in a way machines can understand.
Across multiple site rollouts, the same problems keep showing up:
- The same equipment has different tag names across lines or sites
- Some values are live, some are stale, some are simulated. Nobody knows which is which
- Context is missing, like batch, product, operating mode, or unit of measure
- Data is scattered across PLCs, SCADA screens, historians, spreadsheets, and a few “do not touch” servers
AI needs patterns. Manufacturing systems often provide exceptions.
Another common issue is cryptic tag naming. It is not unusual to see tags like FIC_101 or TEMP_2 dumped into a data lake. Without context, those numbers mean nothing. What does it measure. What unit is it in. Which line does it belong to. Which batch was running.
When AI models receive data like this, most of the effort goes into cleaning and interpreting the signals, not solving real operational problems.
That is why many AI initiatives stall after the first pilot. The data foundation simply is not ready.
UNS Is Not a Data Lake. It’s a Shared Map
A Unified Namespace is often misunderstood. It is not another storage platform. It is not a historian. It is not a data lake.
A UNS is essentially a shared map of operational data.
The idea is simple. Publish operational data in one place, using a consistent structure, so every consumer sees the same version of reality.
The most important word here is structure.
When we implemented UNS in real manufacturing environments, we used a hierarchy that matched how people already think about a plant:
Enterprise / Site / Area / Line / Cell / Equipment
Under each equipment node, we separated two types of information.
First. What the equipment is.
Second. What the equipment is doing.
That distinction matters more than people expect.
“What it is” represents metadata:
- equipment name
- equipment type
- model number
- engineering units
- limits and configuration
“What it’s doing” represents telemetry:
- machine state
- operating mode
- speed or throughput
- temperatures or pressures
- counts, alarms, or events
Separating these concepts helps prevent a common problem. In many systems, tags change meaning over time. A controls engineer edits a screen, renames a variable, or repurposes a signal. Suddenly the same tag represents something slightly different.
When that happens, AI models end up learning from shifting definitions. UNS structures reduce that risk.
Another advantage is decoupling.
Machines and systems publish their data once into the UNS. Consumers subscribe to what they need. Dashboards, analytics pipelines, AI models, and business systems can all read from the same source without creating dozens of point-to-point integrations.
Sparkplug B Is the Behavior That Makes UNS Reliable
Many teams try to build a UNS using raw MQTT topics and JSON payloads. That approach works at first. Then problems appear.
Everyone invents their own topic structures. Payloads look different across vendors. Some devices quietly stop publishing and nobody notices.
Sparkplug B fixes this.
It is an open specification built on top of MQTT that adds the operational behavior industrial systems require.
In practice, it introduces a few mechanisms that become critical on real shop floors:
- Birth certificates: When a device comes online, it announces its full set of metrics. Consumers immediately know what data is available.
- Death certificates: If a device disconnects, the system knows it is offline. Not “maybe the value stopped changing.” Actually offline.
- Standard payload structure: Data follows a consistent format, typically encoded using Protocol Buffers. That removes guesswork when integrating systems.
- State management: Sparkplug B tracks device and metric health. It becomes much easier to detect stale or invalid data.
In simple terms. Sparkplug B turns MQTT into something that behaves like an industrial data infrastructure.
Without it, every integration tends to reinvent the same conventions. With it, systems speak a predictable language.
A Simple Example From the Floor
Here is a typical situation we encountered on a packaging line.
Leadership wanted AI to predict downtime. The plant already had years of data. But the signals were scattered across multiple systems:
- PLC tags representing machine states
- SCADA tags that had been renamed multiple times
- A historian with decent history but inconsistent naming
- Manual logs used during changeovers
Before touching any AI model, we focused on standardizing the operational signals.
We defined a clear UNS structure for the line:
- Enterprise/Site/Packaging/Line1/Filler/Status/State
- Enterprise/Site/Packaging/Line1/Filler/Status/Mode
- Enterprise/Site/Packaging/Line1/Filler/Performance/Speed
- Enterprise/Site/Packaging/Line1/Filler/Status/StopReason
- Enterprise/Site/Packaging/Line1/Filler/Condition/Health
These signals were published through Sparkplug B so their status was always known.
Something interesting happened.
We did not need AI immediately.
Just having consistent states and reliable “is this signal alive” information created value:
- downtime dashboards that operators trusted
- cleaner KPIs
- fewer arguments in daily production meetings about whose numbers were correct
Only after the data stabilized did predictive models start to make sense.
The foundation came first. The AI came later.
How UNS and Sparkplug B Create AI-Ready Data
AI-ready data is not just about volume. It is about quality and structure.
When a Unified Namespace is combined with Sparkplug B, several important things happen.
- Consistent semantics: The same concept has the same name everywhere. Location in the hierarchy carries meaning.
- Better context: AI models need more than numbers. They need operating mode, state, product, timing, units, and limits.
- Clear data quality signals: Systems can see whether data is online, stale, or invalid. Sparkplug B helps expose that information.
- Decoupled architecture: Data producers publish once. Consumers subscribe. New applications can be added without breaking existing ones.
- Scalable governance: When a second site comes online, the structure already exists. Teams are not reinventing naming conventions every time.
In practice, this dramatically reduces the amount of custom data wrangling required for analytics and AI.
Where This Foundation Leads
Once the UNS structure is stable and Sparkplug B behavior is enforced, more advanced use cases become realistic.
Examples we have seen include:
- anomaly detection on machine behavior
- early warning for temperature, vibration, or cycle time drift
- predictive maintenance models
- smarter batch monitoring
- automated root cause suggestions
These solutions are not magic. They still require engineering and domain knowledge.
But at least the models are learning from consistent signals instead of constantly shifting data.
My Not-So-Popular Opinion
Most manufacturing AI initiatives should begin with naming conventions and state models, not with model selection.
It is not exciting. It is not a flashy demo. But it determines whether your organization ends up building:
- one custom AI solution per line forever
or
- one scalable data foundation that supports many use cases
You can still build AI without UNS and Sparkplug B.
You will simply spend the majority of your budget repeatedly cleaning and interpreting data. That cost quietly becomes your real AI investment.
Getting the foundation right changes that equation.
Leave a Comment