For the last couple of years, the pitch for a Unified Namespace has been about plumbing: get every PLC, historian, and MES tag into a consistent MQTT topic tree with Sparkplug B payloads, stop building point-to-point integrations, let anything subscribe to anything. That’s the data bus story, and plenty of plants are still mid-build on it. Now a second conversation is starting, and it’s a different animal: what happens when the thing publishing to a topic isn’t a sensor, but a model?
Sparkplug B 3.0, finalized under the Eclipse Foundation’s Sparkplug working group, cleaned up several long-standing rough edges in the spec — more flexible datatypes, better support for complex/structured metrics, and clearer handling of historical and templated data. None of that sounds like an AI story. But it matters here because model outputs are messier payloads than a temperature reading. A quality prediction might carry a score, a confidence interval, a list of contributing features, and a model version tag, all as one logical unit. Sparkplug B 3.0’s improved support for structured metrics makes it far more natural to publish that as a coherent object under a topic, rather than duct-taping five flat tags together and hoping consumers reassemble them correctly.
The other half of the shift is hardware, not software. NPUs and inference accelerators are now common enough on industrial gateways that running a small trained model — a gradient-boosted tree for quality prediction, a lightweight autoencoder for anomaly scoring — at the edge, next to the PLC connection, is a normal design option rather than a research project. That’s the real change. It used to be that “AI on the plant floor” meant streaming everything to a cloud data lake and waiting for a batch job. Now the scoring can happen a few milliseconds from the sensor, and the only thing that needs to travel over the network is the answer.
From data bus to inference bus
Put those two things together and you get a genuine architectural option: publish model output as a first-class citizen of the Sparkplug namespace, addressed and versioned the same way you’d address any other tag. Instead of Plant1/Line3/Press12/Vibration you also have Plant1/Line3/Press12/Prediction/BearingAnomalyScore, published by an edge inference process instead of a PLC scan.
Architecturally this is coherent. MQTT brokers don’t care whether the publisher is a sensor or a model. Sparkplug’s birth/death certificate mechanism (NBIRTH, DBIRTH, NDEATH) works just as well for an inference service announcing itself and its metric schema as it does for a device announcing its I/O map. Any SCADA, historian, or dashboard already subscribed to the namespace gets the prediction the same way it gets a raw value — no separate integration, no new protocol, no bespoke REST endpoint per model.
That’s the appeal, and it’s real. It’s also where most of the hard problems live, because publishing a number is easy. Publishing a number that people will trust and act on for years is not.
Treat a prediction like a tag — including the metadata a tag doesn’t need
If a prediction is going to live in the UNS next to sensor data, it needs to carry more context than sensor data does, or it will eventually mislead someone. At minimum, a published inference metric should include:
- Model identity and version — which model produced this score, and which trained version. Sparkplug’s DBIRTH metadata is a reasonable place to declare this, but don’t bury it; someone troubleshooting a bad prediction six months from now needs to find it fast.
- Input feature set or window — what data actually fed the model at inference time, at least by reference. If a prediction is wrong, the first question is always “was the model looking at good data?”
- Confidence or a quality flag, not just a bare score. A vibration anomaly score of 0.82 means nothing without knowing what “normal” looks like for that model.
- A staleness signal — is the model still scoring live data, or did the edge device lose its upstream feed and freeze the last output? A frozen prediction that looks like a live one is a classic failure mode, and it’s more dangerous than an obviously broken tag because nothing looks wrong.
None of this is exotic. It’s the same discipline OT teams already apply to sensor health (quality codes, last-known-good timestamps). The difference is that people are inclined to trust a “smart” number more than a raw one, which is exactly backwards — a raw sensor value fails loudly, a model fails quietly.
Namespace placement: don’t bolt predictions onto the device tree
The temptation is to nest the prediction directly under the asset it describes, mirroring ISA-95 structure: Enterprise/Site/Area/Line/Cell/Prediction. That’s fine for consumption, but it conflates two different lifecycles. A device’s tag structure changes when the device changes. A model’s output structure changes when the model changes — which, if you’re doing this seriously, is more often. Several plants experimenting with this have landed on a parallel branch (something like a top-level “Inference” or “Analytics” namespace, mirroring the physical hierarchy but versioned independently) rather than interleaving predictions directly into the equipment tree. That keeps a model redeploy from requiring you to touch the asset namespace at all, and it makes it obvious to any consumer which topics are ground truth and which are an opinion generated by software.
The governance questions nobody wants to own
This is the part that actually stalls these projects, and it’s not technical. Once a prediction is a tag in the UNS, it behaves like a data product — other systems will build on it, dashboards will alarm on it, maybe MES logic will eventually gate a hold decision on it. That raises questions plants haven’t had to answer for sensor data:
- Who owns model drift? A controls engineer owns a sensor’s calibration. Who owns the fact that a quality model trained eighteen months ago no longer reflects current raw material lots or a tooling change? This needs an assigned owner before go-live, not after the first bad batch slips through.
- What triggers retraining, and who approves the new version going live? Silent model updates on a production floor are a bad idea. Treat a new model version the same way you’d treat a PLC logic change — reviewed, versioned, and rolled out deliberately, with the old version’s topic namespace clearly retired or superseded.
- Who’s accountable when a prediction is wrong? If a bearing-failure score misses a real failure, or cries wolf often enough that operators start ignoring it, that’s a different kind of incident than a stuck sensor. Data science, controls, and quality all need to agree in advance who investigates.
These aren’t reasons to avoid the shift — they’re the reason to slow down on scope. Start with one or two low-stakes predictions (a non-critical anomaly score, not a hold/release quality gate), get the namespace pattern, versioning discipline, and ownership model right, and only then expand to predictions that actually drive automated decisions.
What to actually do this year
If your UNS build is stable, this is a reasonable next step, not a distraction from it. If your UNS is still mid-rollout with basic tag coverage incomplete, don’t add inference publishing on top — you’ll be debugging two immature systems at once. For teams ready to move: pick one edge gateway with inference capability, define the metadata schema for a prediction before you write any model code, decide where “Analytics” or “Inference” lives in your topic tree, and assign a named owner for drift and retraining before the first model goes live. The technology is ready enough. The organizational habits around treating a prediction as a governed product, less so — and that’s the gap that will actually determine whether this works.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
