The architecture question for a greenfield IIoT build: broker in the middle, or client-server to each asset?
| MQTT / Sparkplug B | OPC UA | |
|---|---|---|
| Specification | OASIS MQTT 3.1.1 / 5.0, Eclipse Sparkplug B | IEC 62541 |
| First published | 1999 (MQTT), 2016 (Sparkplug B) | 2008 |
| Transport | TCP 1883, TLS 8883, via a broker | TCP binary on 4840, or HTTPS |
| Data model | MQTT itself carries opaque bytes on a topic. Sparkplug B adds a protobuf payload, a topic namespace, and birth/death certificates so state is knowable. | A full information model: typed nodes, references, objects, methods and historical access. The richest model in industrial automation. |
| Discovery | Sparkplug B birth certificates announce metrics on connect. Plain MQTT: none. | Built in. Browse the address space, read the type definitions. |
| Security | TLS plus broker-level authentication and topic ACLs. | Built in and mandatory to configure: X.509 certificates, signing, encryption, user authentication. |
| Polling or subscription | Publish/subscribe, report-by-exception. The device pushes when a value changes. | Both. Polled reads and subscriptions with monitored items and dead-banding. |
| Implementation complexity | Low to implement, moderate to operate: the broker becomes infrastructure you own. | High. The stack is large, certificate handling is a real operational task, and server implementations vary. |
| Typical industries | IIoT gateways, distributed and remote assets, energy, anything behind a cellular link. | Modern machine tools, robotics, packaging, anything specified after ~2015. |
| Forge support | Adapter shipped. 19 verticals mapped. | Adapter shipped. 19 verticals mapped. |
Strength. Report-by-exception over an expensive or unreliable link. One broker fans out to many consumers.
What it costs you. Plain MQTT has no schema at all: the payload is whatever the publisher decided that day.
MQTT / Sparkplug B adapter →Strength. Self-describing. You can walk a server you have never seen and learn what it holds.
What it costs you. Self-describing is not the same as standardised, two vendors model the same machine differently, so the names still need mapping.
OPC UA adapter →OPC UA models the asset; MQTT moves the message. They compose better than they compete: OPC UA PubSub over MQTT exists precisely because the industry stopped treating this as an either/or. If you are choosing under pressure: OPC UA when you need to *interrogate* equipment, MQTT when you need to *ship* readings cheaply.
Forge is not an argument for a protocol. It is the layer that makes the choice stop mattering downstream: 2,086 curated mappings across 13 protocol adapters, resolving to 985 canonical fields defined with enforced units and physics bounds.
Two devices, two protocols, two vendors, two entirely different tag names, and one canonical field out. Both of these are real mappings from the corpus, not illustrations.
Same field: amr.battery.charge. Same unit contract, same physics
bounds, same shape. Your query does not need to know which protocol the reading
arrived on.