Executive summary
2019
the year Sparkplug B was contributed to the Eclipse Foundation by Cirrus Link Solutions
Key conclusions
- OPC UA carries a rich, typed information model. Sparkplug B over MQTT is built for high-volume telemetry with low overhead. The two protocols solve different problems.
- The costly mistake is to use one protocol across every site and system because the last integrator knew it.
- Most operations that choose well run both: OPC UA where a system must understand equipment state, and Sparkplug B where it only needs high volumes of readings.
An AI system that is meant to act on equipment must first read data from it. In a real plant, that reading happens through a protocol that someone chose, usually early and with little debate. The rest of the integration then has to work within that decision. Two protocols dominate the choice today, and they were built to solve different problems.
The OPC Foundation maintains OPC UA, which carries a structured information model with rich semantics. The model describes what a value means, how it relates to other values, and its type. The Foundation also publishes companion specifications that extend the model into specific domains, such as robotics, CNC machining and packaging. Sparkplug B is narrower by design. It is part of the Eclipse Foundation's Tahu project, and Cirrus Link Solutions contributed it in 2019. It standardises how MQTT, a lightweight publish-subscribe messaging protocol, carries topic namespaces, payloads and session state for industrial telemetry.
Each protocol fits a different job
| 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 | 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 need is a stream of readings | A flatter data model; it tells you a value changed, and nothing about 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 costly mistake is choosing one protocol for everything
The common failure is to choose one protocol for every site and system because the last integrator knew it. Eighteen months later, the operator finds one of two problems. 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 the sensor fleet meant to stream data cheaply is paying OPC UA's per-point overhead across several hundred tags.
Most operations that choose well run both protocols: OPC UA where a system has to understand equipment state, and Sparkplug B where it only has to receive readings at volume. This is an architecture decision. It should be made once, early, by someone who has looked beyond each protocol's marketing material. Making it correctly the first time costs far less than reversing it after the AI layer is built on top.
