OPC UA, MQTT, and Sparkplug B: how they fit together

Ask "should we use OPC UA or MQTT?" in any controls forum and you will get confident, contradictory answers. The question is miscast. These technologies overlap far less than the debate suggests, and most mature architectures use at least two of them at different layers.

What each one is

OPC UA is an industrial interoperability framework: a meta-model for describing assets (objects, variables, methods, references), client/server services for browsing and reading, alarms and historical access, PubSub for many-to-many streaming, and built-in security (X.509 application authentication, signing, encryption). Companion specifications extend the base model into domains — machines, robotics, process automation, energy. Its strength is semantics: a client can connect to a server it has never seen, browse its address space, and understand what it found.

MQTT is a lightweight publish/subscribe transport. Clients publish messages to topic strings on a broker; subscribers receive them. The protocol (an OASIS standard, currently v5) defines retained messages, quality of service levels, session persistence, and Last Will. It defines nothing about topic structure or payload encoding. Its strength is decoupling and efficiency: tiny footprint, store-and-forward friendly, trivial to bridge across network boundaries.

Sparkplug B is a contract that runs on MQTT: a fixed topic namespace, a protobuf payload schema, and birth/death session semantics. It supplies exactly the conventions MQTT omits. Its strength is plug-and-play fleet onboarding with state awareness.

The layer map

Think in terms of who talks to whom:

The common pattern is a gateway that speaks OPC UA (or native protocols) downward and Sparkplug upward. The OPC UA address space models the equipment; the Sparkplug namespace carries its telemetry to every consumer — historian, MES, dashboards, analytics — without each consumer polling the server.

Choosing, concretely

• Pick OPC UA when consumers need to discover structure at runtime, invoke methods, manage alarms, or exchange data with full type information and security between known parties. It is the default for controller-to-SCADA, vendor-to-vendor, and anything with a companion spec in your domain.
• Pick MQTT (+ Sparkplug) when you have many producers and many consumers, intermittent connectivity, a need to buffer at the edge, or a unified-namespace architecture where one broker fans data out to the whole enterprise. Use Sparkplug rather than ad-hoc topics unless you enjoy maintaining topic documentation.
• Use both when the plant floor needs rich modeling and the enterprise needs scalable distribution. This is the modal serious architecture, not a compromise.

What about MQTT without Sparkplug, or Sparkplug without MQTT? Raw MQTT topics are fine for narrow, stable integrations between two teams that can agree on a schema — and a liability the moment a third consumer arrives. Sparkplug without MQTT is a contradiction: the spec assumes a broker. (OPC UA PubSub over MQTT exists as a mapping, but in practice teams pair OPC UA with Sparkplug-as-payload-convention far less often than they run the two side by side.)

The one-paragraph version

OPC UA models the plant so software can understand it. MQTT moves data so software can scale. Sparkplug stops every MQTT project from reinventing topic conventions and liveness tracking. Model with the first, distribute with the second and third, and keep your deterministic traffic on the fieldbus where it belongs.