OPC UA PubSub vs MQTT Sparkplug is not a contest between two equivalent brokers. OPC UA PubSub is part of the OPC UA information and communication architecture; it defines publisher and subscriber configuration, dataset metadata, network messages, mappings such as UADP and JSON, and security behavior across several transports. Sparkplug defines an MQTT topic namespace, payload conventions, birth and death sequences, and session-state rules for industrial applications.
Both can carry plant data through an MQTT infrastructure, but the contract a consumer receives is different. The practical decision should start with the semantic authority, state-recovery requirement, installed controls ecosystem, latency domain, and ownership model. Selecting MQTT as a transport does not answer any of those questions. A proof of concept that moves a temperature value can hide the hard work of naming the asset, describing engineering units, reconstructing state, governing changes, and diagnosing stale data.
Separate transport, session state, and industrial semantics
MQTT 5 supplies transport-level behavior including quality of service, retained messages, session expiry, message expiry, reason codes, and shared subscriptions in the OASIS standard. It does not prescribe an asset hierarchy, metric schema, or industrial lifecycle. Sparkplug adds a constrained convention over MQTT: group, edge-node, and device identity in topics; protocol-buffer payloads; metric aliases; and NBIRTH, DBIRTH, NDEATH, DDEATH, and data messages that let a host reconstruct online state.
OPC UA PubSub starts from OPC UA datasets and metadata. Publishers send DataSetMessages inside NetworkMessages; configuration can identify writers and groups, and message mappings can optimize for binary industrial networks or JSON-oriented enterprise integration. The OPC Foundation's Part 14 reference also defines security and multiple transport mappings. PubSub does not require every consumer to call a server for each value, but a complete deployment still needs configuration discovery, metadata management, key distribution, and a model authority.
| Decision area | OPC UA PubSub | MQTT Sparkplug | Architecture implication |
|---|---|---|---|
| Semantic model | Carries OPC UA DataSets and can align with OPC UA types and companion models | Carries typed metrics with names, aliases, properties, and templates inside Sparkplug payloads | Choose who owns canonical asset meaning beyond wire encoding |
| State lifecycle | Key frames, metadata, sequence information, and configured publisher behavior | Birth and death certificates plus MQTT session behavior reconstruct edge and device state | Test reconnect, broker restart, and missed-message recovery |
| Transport choices | UADP or JSON mappings over supported message-oriented middleware and datagram transports | MQTT infrastructure using the Sparkplug namespace and payload | Fit existing network, determinism, and operations skills |
| Discovery/configuration | Rich OPC UA configuration model and discovery options | Topic hierarchy and birth payload expose runtime metrics | Provide an inventory service for enterprise consumers |
| Interoperability proof | Conformance profiles, information models, and exact message settings matter | Specification and TCK-compatible implementations matter | Test products together with the selected feature subset |
Choose OPC UA PubSub when the OPC UA model is the governing contract
OPC UA PubSub is usually the stronger fit when equipment already exposes OPC UA address spaces, companion specifications carry domain meaning, or the organization needs the same information model across client-server access and publish-subscribe distribution. It also fits use cases that need UADP efficiency, multicast or brokerless patterns, or explicit publisher and writer-group engineering. Standardize a narrow interoperable profile: transport, mapping, header layout, encoding, security mode, key service, metadata cadence, time synchronization, and handling of configuration version changes.
The cost is breadth. Optional header combinations and deployment profiles can make two conformant products fail to interoperate. The OPC UA JSON mapping helps web and enterprise software consume messages, but JSON alone does not preserve every operational assumption. Build golden messages and negative tests for field types, status codes, timestamps, sequence gaps, metadata updates, publisher restart, expired keys, and oversized messages. Keep an authoritative registry that maps publisher identity and DataSetWriter identity to an asset record.
Choose MQTT Sparkplug when brokered state is the integration center
Sparkplug is attractive when an MQTT broker is the plant-to-enterprise backbone and teams want a prescribed industrial namespace and state model without deploying the broader OPC UA stack at every integration point. The Eclipse Sparkplug 3.0 specification formalizes normative behavior and has a technology compatibility kit. A primary host can learn an edge node's complete metric set from birth messages, consume incremental data, and mark state invalid after a death certificate or session loss.
That discipline only works when implementations honor it. Use stable group, edge-node, and device identifiers; persist alias mappings correctly; publish births after connection according to the specification; and treat stale values as unavailable rather than silently current. Avoid encoding uncontrolled site structure into topic strings. Put business-friendly names, engineering units, limits, provenance, and template version into a governed model. Broker access control must constrain publishing by topic and identity, while application authorization still decides which commands are permissible for an asset.
| Requirement | Prefer PubSub when | Prefer Sparkplug when | Verify in pilot |
|---|---|---|---|
| Brownfield source | OPC UA servers and companion models are authoritative | Gateways already normalize protocols into MQTT | Semantic loss from the original controller |
| Network pattern | Datagram, multicast, UADP, or OPC UA configuration is needed | Managed broker routing and MQTT operations are standard | Failover, congestion, and reconnect behavior |
| Consumer landscape | Consumers understand OPC UA types and metadata | Consumers need a compact brokered metric/state contract | SDK coverage and schema evolution |
| Operational state | Publisher configuration and dataset sequence are engineered | Birth/death lifecycle is central to host behavior | Broker restart and retained-session edge cases |
| Team capability | Controls and OPC UA expertise owns the system | Messaging platform team operates MQTT reliably | Cross-team incident diagnosis time |
Design the semantic layer before implementing adapters
For either option, create a canonical asset record with stable identity, parent relationships, model and serial numbers, location, signal definition, unit, data type, quality, source timestamp, acquisition timestamp, valid range, command authority, and model version. Distinguish an observation from current state and an event from a counter. Define how null, bad quality, offline, and not-yet-observed differ. A gateway must not convert an OPC UA bad status into a plausible numeric value or turn a missing Sparkplug metric into zero.
Version additively. Add a new metric or dataset field before retiring the old one, preserve aliases within a session, and publish metadata before consumers rely on changed meaning. Maintain contract fixtures for both encodings and an adapter loss ledger: source concept, target representation, transformation, precision, quality mapping, and information that cannot be preserved. If both protocols coexist, name one canonical owner per concept. Bidirectional synchronization without authority rules creates loops and conflicting state.
Secure and operate the contract end to end
Network encryption is necessary but insufficient. Provision unique publisher or edge identities, restrict publish and subscribe scope, rotate credentials, validate payload size and type, and separate telemetry from command authorization. OPC UA PubSub security may protect messages independently of the middleware; MQTT commonly protects connections with TLS and broker authorization. Document where trust terminates and whether intermediaries may inspect, transform, or replay content. A safety controller should not accept a command merely because it arrived on a syntactically valid topic or dataset.
Observe contract outcomes: unknown publisher, unauthorized topic, invalid message, sequence gap, stale age, missing birth, metadata mismatch, alias error, duplicate, consumer lag, key failure, and command rejection. Run broker and publisher failure exercises. Capture raw bounded samples around anomalies, while controlling sensitive operational data. Product selection should include conformance evidence, supported specification versions, security patch commitments, offline behavior, licensing, and the ability to export configuration for independent testing.
Key takeaways
- Compare the complete state and semantic contract, not MQTT with OPC UA as if both were transports.
- Use OPC UA PubSub when OPC UA information models and deployment profiles govern the system.
- Use Sparkplug when a brokered MQTT backbone needs prescribed topic, payload, and birth/death behavior.
- Standardize a constrained feature profile and prove reconnect, metadata, quality, and security behavior between real products.
- Keep one canonical authority for asset identity and meaning when protocols coexist.
FAQ
Does MQTT 5 replace Sparkplug?
No. MQTT 5 adds protocol capabilities, while Sparkplug defines industrial topic, payload, and session-state conventions. A team can use MQTT 5 without Sparkplug, but it must then design and govern its own industrial contract.
Can OPC UA PubSub run over MQTT?
Yes, OPC UA PubSub defines mappings that can use message-oriented middleware, including MQTT. That does not make an OPC UA PubSub payload a Sparkplug payload; consumers, metadata, state rules, and conformance profiles remain different.
Can one architecture use both?
Yes. A gateway may consume OPC UA and publish Sparkplug, or enterprise software may bridge the reverse direction. Make transformations explicit, avoid uncontrolled command paths, and measure semantic loss. One representation must remain authoritative for each writable value.
Before committing, run a two-day interoperability exercise in which one team configures the publisher and another, using only the published contract, builds the consumer. Repeat after a metadata change and broker restart. The time required to recover correct state is often more revealing than a throughput test.
Conclusion
The right industrial data contract is the one whose semantics, state transitions, and failure behavior the organization can govern. OPC UA PubSub offers deep alignment with OPC UA models and flexible deployment profiles; Sparkplug offers a focused MQTT-native state convention. A constrained, tested profile with explicit asset authority matters more than a feature checklist.