Key takeaways
- OPC-UA models the data; MQTT moves it. Different jobs, not rivals.
- OPC-UA gives interoperability across PLCs, machines and historians.
- MQTT gives efficient, lightweight transport, typically OT-to-cloud.
- Sparkplug B makes MQTT predictable for industrial use (state, namespace).
- Most plants end up running both, bridged at the edge.
The false choice
“OPC-UA or MQTT?” is the most common false binary in industrial IoT. They operate at different layers. Treating them as alternatives leads to architectures that either can’t interoperate with diverse equipment (MQTT-only) or struggle to move data efficiently at scale (OPC-UA all the way to the cloud).
What each one is for
| OPC-UA | MQTT | |
|---|---|---|
| Type | Information model + interoperability standard | Lightweight pub/sub transport |
| Lives where | Plant floor: PLCs, machines, historians | Edge → cloud |
| Strength | Rich data modeling, machine interoperability | Efficiency, scale, simple fan-out |
| Weakness | Heavier; not ideal as a cloud transport | Raw MQTT has no built-in data model |
| Industrial profile | Companion specifications per industry | Sparkplug B adds state & namespace |
Why Sparkplug B matters
Raw MQTT is just a transport — it doesn’t tell you what a topic means, whether a device is online, or how to handle a disconnect. Sparkplug B adds a defined topic namespace, birth/death certificates (so you know a device’s state) and a payload structure on top of MQTT. It’s what makes MQTT trustworthy for OT, rather than a free-form firehose.
The reference architecture
- Machines and PLCs expose data over OPC-UA on the floor.
- An edge gateway aggregates and normalizes it.
- The gateway bridges to MQTT (Sparkplug B) to publish north.
- The cloud or platform ingests, stores and analyzes — and integrates with existing MES/ERP/historian rather than replacing them.
Where to start on a new project
Start from the machines. If you must interoperate with diverse PLCs and historians, OPC-UA is your floor-level backbone. Add MQTT (Sparkplug B) at the edge when you need to move that data to the cloud efficiently. In practice you’ll run both — and the governed platform on the cloud side is what keeps device identity, access and audit consistent across the whole path.
Where Fundamentum fits
Once OT data is flowing north, it still needs a governed home: device identity, access policies and an audit trail. Fundamentum provides that control plane and can interface with your existing cloud (AWS, Azure) when required, inside a SOC 2 Type II perimeter. See the platform →
Frequently asked questions
Is OPC-UA a replacement for MQTT?
No. OPC-UA is an information-model and interoperability standard for machines, PLCs and historians. MQTT is a lightweight publish/subscribe transport for moving data efficiently, typically to the cloud. They solve different layers and frequently run together.
What is Sparkplug B and why does it matter?
Sparkplug B is a specification that adds structure, state management and a known topic namespace on top of MQTT for industrial use. It makes MQTT predictable for OT — devices announce themselves, report state, and handle disconnects cleanly — which raw MQTT leaves to you.
What’s a typical OT-to-cloud architecture?
A common pattern: machines and PLCs expose data over OPC-UA on the plant floor; an edge gateway aggregates it and bridges to MQTT (often Sparkplug B) to publish north; the cloud or platform ingests, stores and analyzes. OPC-UA for interoperability, MQTT for transport.
Which should I start with on a new project?
Start from the machines. If you need to interoperate with diverse PLCs and historians, OPC-UA is your floor-level backbone. Add MQTT (Sparkplug B) at the edge when you need to move that data to the cloud efficiently. In most plants you’ll end up with both.
Related reading
Talk to an IoT engineer — free
Book a FREE 30-minute consultation with our team. No slides, no obligation — a working session on your connectivity, platform or compliance questions.
