Systems integration
OPC UA and Sparkplug B solve different problems. Picking on trend is expensive later
Both protocols let a modern AI system read a plant floor. They were built for different jobs, and an integration scoped around the wrong one carries the cost long after the pilot is over.
Executive summary
2019
the year Sparkplug B was contributed to the Eclipse Foundation by Cirrus Link Solutions
Core conclusions
- OPC UA carries a rich, typed information model; Sparkplug B over MQTT is built for high-volume, low-overhead telemetry — different problems, not competing versions of one.
- The expensive mistake isn't picking the worse protocol — it's picking one for the whole estate because it's what the last integrator knew.
- Most estates that get this right run both: OPC UA where a system must understand equipment state, Sparkplug B where it only needs readings at volume.
Any AI system that is meant to act on equipment first has to read it, and on a real plant floor that reading happens through a protocol somebody chose — usually early, usually without much debate, and usually the decision the rest of the integration then has to live inside. Two protocols dominate that choice today, and they were built to solve different problems.
OPC UA, maintained by the OPC Foundation, carries a structured, semantically rich information model: it describes not just a value but what the value means, its relationships to other values, and its type — and the Foundation publishes companion specifications that extend that model into specific domains such as robotics, CNC machining and packaging. Sparkplug B is narrower by design: part of the Eclipse Foundation's Tahu project, contributed by Cirrus Link Solutions in 2019, it standardises how MQTT — a lightweight publish-subscribe messaging protocol — carries topic namespaces, payloads and session state for industrial telemetry.
Where each one actually fits
| OPC UA | Sparkplug B (over MQTT) | |
|---|---|---|
| What it's good at | Rich, typed machine state and relationships — the semantic model an AI system needs to reason about equipment, not just log it | High-volume, high-frequency telemetry from many sensors, with minimal overhead per message |
| Where it struggles | Heavier payloads, more setup per data point — expensive if all you actually need is a stream of readings | A flatter data model — it tells you a value changed, not what the value structurally relates to |
| Typical fit | Machine and process state feeding a system that has to make a structured decision | Sensor fleets feeding a dashboard, a historian, or a model that only needs the numbers |
The expensive mistake
The failure mode is not picking the worse protocol. It is picking one protocol for the whole estate because it was the one the last integrator knew, then discovering eighteen months in that the AI system meant to make decisions has no semantic model to reason over — only a stream of numbers with no stated relationship between them — or that the sensor fleet meant to stream cheaply is instead paying OPC UA's per-point overhead across several hundred tags.
Most estates that get this right end up running both: OPC UA where a system has to understand equipment state, Sparkplug B where it only has to receive readings at volume. That is an architecture decision made once, early, by someone who has read past the marketing page for each — and it is far cheaper to make correctly the first time than to unwind after the AI layer is already built on top of it.