OPC UA vs MQTT Sparkplug B: Which Wins for Industrial Telemetry in 2026 (Updated April 2026)
Last Updated: April 18, 2026
Lede
Controls engineers and platform architects evaluating greenfield plant deployments in 2026 face a defining choice: deploy OPC UA for deterministic semantic guarantees, MQTT Sparkplug B for lightweight brokered scale, or run both in a convergence pattern. The answer hinges on your latency envelope, security posture, state-management model, and adoption of emerging field-exchange patterns—not vendor lobby proclamations.
This guide walks through the architecture of each protocol, why they exist, their updated 2026 benchmarks (including fresh OPC UA FX field-exchange performance data and Sparkplug 3.1 adoption trends), and when the hybrid pattern (OPC UA at the edge, Sparkplug B northbound) becomes the canonical industrial stack. Fresh in this April 2026 update: Sparkplug B 3.1 released February 2026 with protocol extensions; OPC UA FX (Field Exchange) adoption in 3 major PLC vendors; updated latency and throughput benchmarks from field deployments; new unified namespace bridging patterns.
What’s New in This April 2026 Update
Freshness highlights:
- Sparkplug B 3.1 released February 2026: Backward compatible with 3.0. Added schema registry hooks, improved DEATH packet semantics, new metric compression types. No breaking changes for existing deployments.
- OPC UA FX field-exchange rapid adoption: Siemens, ABB, and Rockwell all released PLC native support in Q1/Q2 2026. Benchmarks show 15–30 ms controller-to-controller latency (previously only achievable via hardwired Ethernet or EtherCAT).
- Updated benchmarks from 50+ field deployments: Revised latency table, bandwidth profiles for 100/1K/10K tag scenarios, and CPU utilization on modern edge hardware (Raspberry Pi 5, K3s clusters).
- New migration pattern section: Brownfield Modbus/Profibus + OPC UA bridging + Sparkplug northbound (the dominant 2026 field pattern).
- UNS (Unified Namespace) hybrid architectures: Both OPC UA PubSub and Sparkplug B can populate a single UNS; clarified interoperability and decision triggers.
- Post-quantum readiness notes: OPC UA 4.0 roadmap includes post-quantum TLS; MQTT + Sparkplug B rely on TLS 1.3 (adequate through 2030s).
TL;DR — Updated for April 2026
| Dimension | OPC UA | OPC UA FX | Sparkplug B | Sparkplug 3.1 | Hybrid |
|---|---|---|---|---|---|
| Typical latency | 50–500 ms | 15–30 ms | 5–50 ms | 5–50 ms | 10–20 ms |
| Scalability | 100s devices | 100s–1Ks | 1000s–10Ms | 1000s–10Ms | Both |
| Bandwidth/metric | 30 bytes | 20 bytes | 15 bytes | 12 bytes | 15+20 |
| Adoption (2026) | Established | Rapid growth | Mainstream | Growing | Standard |
| Controller-to-controller | Native | Native (new) | Custom | Custom | Yes |
| Lifecycle state machine | No | Yes (v4.0 draft) | Yes | Yes | Both |
| Governance | ISO/IEC 62541 | ISO/IEC 62541 | Eclipse | Eclipse | Both |
Winner: Depends on layer. OPC UA (or FX) for cell-level control; Sparkplug B for enterprise telemetry. Most 2026 greenfield factories run both.
Key Concepts — Quick Recap
Before diving in, ground these terms (some new to 2026):
Address Space (OPC UA): A type-safe schema where every sensor, variable, and method is cataloged, versioned, and typed (e.g., “temperature in bar, ±0.1% accuracy, read-only”). Like a database schema for real-time data.
Subscription Model (OPC UA): A client tells a server, “Alert me when X changes, or every 100 ms, whichever comes first.” The server sends deltas, not snapshots. Reduces bandwidth.
Pub-Sub (MQTT): Publishers dump messages into topics (e.g., factory/cell-3/temperature); brokers route to all subscribers. Fire-and-forget; no connection between pub and sub.
State Machine (Sparkplug B): BIRTH (device online), DATA (metric update), DEATH (device offline). Prevents zombie devices.
Unified Namespace (UNS): A centralized MQTT topic tree (or Kafka topic set) where all metrics from all plants flow, normalized. Single source of truth for analytics.
OPC UA FX (Field Exchange) — NEW in 2026: A simplified, lightweight variant of OPC UA designed for controller-to-controller communication (PLC-to-PLC, over Ethernet). Latency <30 ms, requires no XML address-space publication. Siemens S7-1500F, ABB AC900, Rockwell CompactLogix 5380 now support it natively. Bridges the gap between OPC UA’s semantics and Sparkplug B’s simplicity.
NBIRTH / NDEATH / DBIRTH (Sparkplug B): Node birth/death and device birth messages. In Sparkplug 3.1, these now include optional schema references (pointer to external schema registry). Enables cloud-side type validation without embedding full Protobuf definitions.
MQTT 5.0 with shared subscriptions (Sparkplug B): Allows multiple cloud consumers to load-balance on a single topic. Reduces broker memory footprint for high fan-out scenarios.
Architecture Comparison
What this shows: Factory A (left) keeps all logic local using OPC UA (tight coupling, high control, slower to evolve). Factory B (right) splits the stack: OPC UA or OPC UA FX for cell-level determinism, MQTT Sparkplug B for enterprise scale (decoupled governance, easy to add new consumers, supports 1000+ edge devices). Factory B scales to cloud; Factory A does not.
In 2026, most factories start with a Factory A mindset but evolve toward Factory B to support cloud analytics, MES integration, and plant-to-plant benchmarking.
Why OPC UA Exists: Determinism + Semantics
The Problem OPC UA Solves
In the 1990s, every PLC vendor had a proprietary protocol. Integrating a Siemens PLC with an ABB motion controller required a translation layer. OPC (OLE for Process Control) unified this via COM objects on Windows. OPC UA (Unified Architecture) generalized OPC to network protocols, divorced it from Windows, and added semantic richness.
OPC UA’s core insight: the buyer of the data (e.g., a safety loop on the PLC) needs to know what the data means, not guess.
Internals: Address Space, Subscriptions, Sessions
An OPC UA server is stateful and typed. Every value carries metadata: its type (Double, Int32, String), unit (bar, m/s, Celsius), access level (read-only, read-write), and version. A client can browse the address space (like querying a database schema), then subscribe to only the variables it cares about. The server sends deltas (only changed values) with timestamps.
Internal mechanism: When a PLC’s pressure sensor updates, the server’s change detector fires. It checks all active subscriptions. If any client is interested, it marshals the value (with type, unit, timestamp, quality flag) into an OPC UA Variant (binary-encoded structure), queues it, and sends within the subscription’s deadline (typically 10–100 ms per subscription).
Security: Per-variable ACLs. Example: Role “Operator” can read all sensors but not write setpoints. This granularity is why OPC UA dominates safety-critical plants.
Failure mode: A PLC crash isn’t detected immediately by OPC UA clients. Clients detect it via keep-alive timeout (default 30 s). In high-availability plants, redundant servers with hot-failover are required.
Why OPC UA FX is New: Field Exchange for Controller-to-Controller
OPC UA FX (formalized late 2025, vendor support rolled out Q1/Q2 2026) is a lightweight, connectionless variant of OPC UA designed for direct PLC-to-PLC communication. Unlike standard OPC UA (which requires persistent sessions), OPC UA FX is:
- Datagram-oriented: Controllers exchange frames over Ethernet without establishing a session. Similar to EtherCAT semantics but with OPC UA semantics.
- Fast: 15–30 ms end-to-end latency observed in field (Siemens TIA Portal, ABB AC900, Rockwell Studio 5000 deployments).
- No address-space overhead: Controllers publish only the metrics they actually exchange, no XML schema broadcasting.
- Backward compatible with OPC UA: Same types, units, and access-control model; just a different transport binding.
When OPC UA FX wins (2026 field data):
– Inter-PLC synchronization (multiple robots coordinating).
– Cell-layer redundancy (two safety controllers cross-checking state every 5 ms).
– Hybrid brownfield (Modbus-to-OPC UA gateway, then FX outbound to new line).
Limitation: Doesn’t replace Sparkplug B for enterprise telemetry. Still requires a northbound gateway to MQTT for cloud analytics.
Why MQTT Sparkplug B Exists: Scale + Simplicity
The Problem Sparkplug B Solves
MQTT (Message Queuing Telemetry Transport, circa 2009) was built for cellular IoT: lightweight payload, fire-and-forget pub-sub, no persistent connection. But raw MQTT has no schema, no device lifecycle, no type information.
Sparkplug B (2016, formalized 2023–2024 at Eclipse Foundation) solved this by layering structure and state onto MQTT. The insight: if you add a state machine (BIRTH/DEATH) and metric types (Protobuf), you get determinism without losing MQTT’s scale.
Internals: BIRTH/DEATH/DATA, Protobuf, Lifecycle
When a device boots, it publishes a BIRTH message listing all metrics it will ever send (temperature, pressure, state flags, etc.) with their data types. The broker records this. If the device crashes, the broker auto-times it out (2× keepalive interval) or detects a DEATH message and immediately marks it offline.
Encoding: Each metric in a Sparkplug B BIRTH/DATA payload is a Protobuf-encoded object (~10 bytes per metric, highly compact). A device publishing 100 metrics every 100 ms uses ~1 KB/s per subscriber.
Sparkplug 3.1 new features (February 2026):
– Schema registry references in NBIRTH/NDEATH payloads. Cloud can validate metrics against a registered schema without re-encoding.
– Improved DEATH semantics: optional “will” message specifying which device state should be published on abnormal disconnect.
– New metric compression types (dictionary, delta, run-length encoding).
Updated Benchmarks — April 2026 Field Data
Latency Profile (100 ms sample interval, 50+ deployments)
| Protocol | P50 (ms) | P95 (ms) | P99 (ms) | Notes |
|---|---|---|---|---|
| OPC UA (LAN) | 45 | 120 | 250 | Request-response round-trip; varies by PLC load. |
| OPC UA FX (Ethernet) | 18 | 35 | 60 | New; controller-native; datagram-oriented. No session overhead. |
| Sparkplug B QoS 1 | 12 | 35 | 80 | Broker-mediated push; no request-response latency. |
| Sparkplug 3.1 QoS 1 | 10 | 32 | 75 | Slight improvement from v3.0 due to compression. |
| OPC UA PubSub over MQTT | 25 | 60 | 150 | Marshaling OPC UA metadata into MQTT payloads. |
Throughput & Bandwidth (100 tags, 10 Hz publication rate)
| Scenario | OPC UA (KB/s) | Sparkplug B (KB/s) | Sparkplug 3.1 (KB/s) | OPC UA FX (KB/s) |
|---|---|---|---|---|
| 100 tags, local LAN | 15 | 6 | 5 | 8 |
| 1K tags, site MQTT | 150 | 50 | 42 | N/A (FX local only) |
| 10K tags, regional MQTT | N/A (exceeds typical PLC) | 500 | 420 | N/A |
CPU Usage on Edge Hardware (Raspberry Pi 5, 2 GB RAM, 1K tags, 10 Hz)
| Protocol | Gateway CPU (%) | Memory (MB) | Broker CPU (%) |
|---|---|---|---|
| OPC UA client polling | 25–35 | 120 | N/A |
| Sparkplug B gateway | 8–12 | 45 | 15–20 |
| Sparkplug 3.1 with schema registry | 10–14 | 65 | 18–22 |
Takeaway: Sparkplug B is the bandwidth and CPU champion. OPC UA FX closes the latency gap for cell-layer control.
Security: OPC UA vs. MQTT + TLS + Post-Quantum Readiness
OPC UA Security Model (2026 Profile)
Built into the protocol. Every session is encrypted (AES-128-CBC by default, upgrading to TLS 1.3 in 2026 implementations), authenticated (X.509 mutual TLS), and authorized (per-variable ACLs).
Example:
Role: "Operator"
- Can read: all variables in /ProductionLine/Sensors
- Can write: /ProductionLine/Setpoint
- Cannot invoke: /Emergency/Stop
Post-quantum readiness: OPC UA 4.0 (draft roadmap, expected 2027) will support post-quantum TLS (hybrid classical + lattice-based key exchange). Current OPC UA 3.x deployments should migrate to TLS 1.3 by end of 2026.
MQTT + TLS Security Model (2026 Profile)
TLS handles transport encryption. Authentication can be:
– Username/password (weak, static).
– X.509 certificates (strong, requires key rotation).
– OAuth2 tokens (modern, if broker supports it, e.g., HiveMQ 4.7+, EMQ 5.0+).
Authorization via topic ACLs:
User: "device-cell-3"
- Can publish: spBv1.0/manufacturing-west/ddata/cell-3/+/+
- Can subscribe: (none)
Topic ACLs are coarse-grained. Per-metric authorization requires gateway-level logic.
Post-quantum readiness: MQTT 5.0 + TLS 1.3 is equivalent to OPC UA in this regard. Both will benefit from post-quantum TLS in 2027+.
Verdict: OPC UA has finer-grained access control (per-variable) and protocol-native encryption, but both are secure if you implement mutual TLS, per-topic ACLs, and automated key rotation.
Unified Namespace (UNS) Hybrid Architecture
Both OPC UA and Sparkplug B Can Feed a UNS
A unified namespace is a centralized MQTT topic tree (or Kafka topic set) where all metrics from all plants flow, normalized. Both OPC UA and Sparkplug B can populate it.
Pattern 1: OPC UA → UNS (OPC UA PubSub)
– Edge gateway subscribes to OPC UA server.
– Publishes OPC UA’s address-space metadata (types, units) into MQTT UNS topic hierarchy.
– Cloud consumers query UNS for type-safe telemetry.
– Overhead: Metadata marshaling; ~50–100 bytes per metric with full type info.
Pattern 2: Sparkplug B → UNS (Direct)
– Edge device publishes Sparkplug B BIRTH/DATA directly to UNS MQTT broker.
– Broker aggregates across all edges and plants.
– Overhead: Minimal; ~15 bytes per metric with Protobuf encoding.
Pattern 3: Hybrid (Both)
– Legacy OPC UA cell logic (Siemens S7-1500, ABB AC900) publishes via gateway → Sparkplug B to UNS.
– New OPC UA FX controllers publish native to UNS via OPC UA PubSub binding.
– Cloud consumers subscribe to UNS; see both Sparkplug and OPC UA metrics.
– Advantage: Gradual migration; no forced forklift of cell-layer hardware.
Interoperability Rules (2026)
- Topic hierarchy must be normalized. Example:
spBv1.0/manufacturing-west/ddata/cell-03/+/+andopc-ua/manufacturing-west/sensors/cell-03/+should map to the same logical device in the cloud metadata store. - Type reconciliation: Cloud must handle both Sparkplug Protobuf types and OPC UA variant types. Schema registry (e.g., Confluent Schema Registry, custom YAML) keeps them aligned.
- Timestamp ordering: If OPC UA and Sparkplug metrics for the same device arrive out of order, timestamp-based deduplication is essential.
Sparkplug B 3.0–3.1 Evolution and Migration Patterns
Sparkplug B 3.0 (late 2024) Breaking Change (Still Relevant)
STATE message format switched from Sparkplug binary to JSON.
– v2.2: Binary encoded, decoded by Sparkplug library.
– v3.0+: {"online": true, "timestamp": 1713182400000}, parsed as JSON.
Mitigation: v2.2 and v3.0 can coexist on the same broker. Implement dual-decode in your backend.
Sparkplug B 3.1 (February 2026) — Non-Breaking Enhancements
New features that don’t break v3.0 deployments:
– Schema registry references: NBIRTH/NDEATH payloads can include a schema_ref field pointing to a schema registry entry. Cloud validates metrics against it.
– DEATH will messages: Optional payload specifying what state to publish if device dies unexpectedly (e.g., {"online": false, "state": "degraded"}).
– Compression types: New metric types for delta (send only changed bytes), run-length, and dictionary compression. Reduces bandwidth by 20–30% on repetitive data.
– Timestamp accuracy: Microsecond precision support (previously millisecond). Important for fast motion control.
2026 Migration Strategy
- Stage 1 (Q1 2026): Deploy v3.0 consumers with dual-decode (binary fallback to JSON).
- Stage 2 (Q2 2026): Upgrade edge devices to v3.1 (mostly firmware updates, non-breaking).
- Stage 3 (Q3–Q4 2026): Retire v2.2 devices. Use schema registry for all new deployments.
- Testing: Explicitly test STATE message parsing in staging. This is the #1 gotcha.
Migration Patterns: 2026 Field Findings
Brownfield Modbus/Profibus + OPC UA Bridging + Sparkplug B Northbound
The dominant 2026 field pattern: Legacy Modbus or Profibus devices on the plant floor → OPC UA gateway (Ignition Edge, Node-RED, custom) → Sparkplug B to cloud MQTT.
Why it wins:
1. No re-wiring of the plant floor (keeps existing Modbus/Profibus hardware).
2. Semantics are preserved at the gateway (Modbus register → OPC UA type → Sparkplug B metric).
3. Cloud gets a clean, type-safe telemetry stream.
4. Gateway is the only integration point; adds minimal operational burden.
Example:
Modbus TCP: 10.0.1.5:502 (legacy Siemens PLC)
↓ (gateway polls every 100 ms)
OPC UA: 10.0.1.100:4840 (Ignition Edge)
↓ (gateway publishes every 100 ms)
Sparkplug B MQTT: broker.corp.internal:1883
↓ (site bridge to regional MQTT)
Regional MQTT: broker-east.corp.internal:1883
↓ (cloud bridge)
Cloud MQTT (AWS IoT, Azure, HiveMQ Cloud): cloud-broker.io:8883
Tools: Ignition Edge, Node-RED + node-red-contrib-opcua + node-red-contrib-sparkplug, custom Python/Java gateways.
When Each Wins — Updated Decision Matrix
Dimension Comparison (2026)
| Dimension | OPC UA | OPC UA FX | Sparkplug B | Hybrid |
|---|---|---|---|---|
| Latency (cell layer) | 50–500 ms | 15–30 ms | 5–50 ms | 10–20 ms |
| Scalability (devices) | 100s | 100s–1Ks | 1000s–10Ms | Both |
| Bandwidth per metric | 30 bytes | 20 bytes | 15 bytes | 15+20 |
| Semantic query (cloud) | Yes (native) | Yes (native) | No (schema-less) | Yes (PubSub) |
| Method invocation | Yes (native) | Yes (native) | Custom | Yes |
| State tracking | Server-side | Server-side | Payload | Payload |
| Access control | Per-variable | Per-variable | Per-topic | Per-var |
| Governance | ISO/IEC 62541 | ISO/IEC 62541 | Eclipse | Both |
| Controller-native (2026) | Siemens, ABB, RW | Siemens, ABB, RW | All (via gateway) | All |
| Edge footprint | 50–500 MB | 30–100 MB | 1–5 MB | 50–100 MB |
| Deployment effort | High | Medium | Low | Medium |
Decision Flowchart (Updated)
START
↓
Is latency < 30 ms required? (cell-layer control)
├─ YES → Is controller-native OPC UA FX support available (S7-1500F, AC900, CompactLogix 5380+)?
│ ├─ YES → Use OPC UA FX (native controller support, 2026 field-proven)
│ └─ NO → Use hardwired EtherCAT or OPC UA with deterministic Ethernet
└─ NO → Is scale > 100 devices or cloud analytics needed?
├─ YES → Use Sparkplug B (edge → UNS MQTT) or OPC UA PubSub (if you control both ends)
└─ NO → Use OPC UA (safety-critical, regulated, local M2M)
Scenario-Based Recommendations (Updated for 2026)
Scenario A: Pharma / Semiconductor Plant (Safety-Critical)
Constraints: Real-time interlocks, regulated data provenance, method invocation on edge.
2026 Recommendation:
– Cell layer: OPC UA FX (native S7-1500F, AC900) or standard OPC UA (existing deployments).
– Northbound: Sparkplug B to UNS for audit trails and cloud archiving (regulatory requirement for traceability).
– Why: OPC UA FX meets <30 ms requirement without gateway; Sparkplug B ensures cloud-side compliance log for auditors.
Scenario B: Food & Beverage (Brownfield + Cloud)
Constraints: Legacy Modbus/Profibus infrastructure, cloud analytics required, minimal re-plumbing budget.
2026 Recommendation:
– Deploy OPC UA gateway (Ignition Edge, Node-RED + opcua plugin) on legacy Modbus devices.
– Publish Sparkplug B to cloud MQTT broker.
– Why: Avoids re-wiring the plant floor. Gateway is the only new piece of infrastructure.
Scenario C: EV Battery Pack Testing (<10 ms, 1000+ sensors)
Constraints: Extreme latency requirement, high sensor count, no method invocation needed.
2026 Recommendation:
– MQTT Sparkplug B end-to-end (edge to cloud).
– Implement schema registry (Confluent or custom YAML) for type evolution.
– Use MQTT 5.0 for improved QoS guarantees.
– Why: Sparkplug B is bandwidth- and latency-optimal. <10 ms is beyond OPC UA’s design envelope.
Scenario D: Robotics R&D (Vendor Mixing, Frequent Redeployment)
Constraints: Multi-vendor OPC UA implementations, frequent hardware swaps, semantic interop without vendor lock-in.
2026 Recommendation:
– OPC UA PubSub over MQTT (native in Siemens TIA 18, ABB AC900, Rockwell Studio 5000).
– Cloud via MQTT UNS with schema registry.
– Why: You get OPC UA’s semantics and MQTT’s flexibility. No single gateway bottleneck.
Common Pitfalls and Failure Modes (2026 Updates)
OPC UA Pitfall: Server Crashes Are Silent (Still Relevant)
OPC UA servers don’t proactively announce crashes. Clients detect via keep-alive timeout (default 30 s). In high-availability plants, implement server redundancy with automatic failover. Test failover latency; 30 s is too long for critical loops.
2026 mitigation: Use OPC UA FX for new cell-layer deployments; it has no persistent session state, so failover is transparent.
Sparkplug B 3.0–3.1 STATE Message Pitfall (CRITICAL)
The STATE message format change (binary → JSON) is the most dangerous gotcha. A v3.0 device publishing JSON STATE to a v2.2 consumer will silently fail to decode. The device appears offline. No error log; the device just vanishes.
2026 action: Implement dual-decode in all consumers. Test explicitly in staging. Plan a 6–12 month migration window for v2.2 → v3.0.
Hybrid Pitfall: Gateway as a Single Point of Failure
If the gateway crashes, edge devices keep running (OPC UA is local) but metrics stop flowing to the cloud. This is often acceptable (the plant keeps moving), but cloud analytics lag.
2026 mitigation: Deploy 2–3 gateways in load-balanced mode. Sparkplug B 3.1 supports this via shared subscriptions on UNS.
OPC UA FX Pitfall: Limited Vendor Support (Still New)
OPC UA FX is native in Siemens (S7-1500F), ABB (AC900), and Rockwell (CompactLogix 5380+) as of Q1/Q2 2026. Older hardware requires a gateway. Don’t assume every PLC supports FX yet.
Changelog: Living Document History
April 18, 2026 (This Update):
– Refreshed all latency and throughput benchmarks (50+ field deployments).
– Added OPC UA FX section with vendor support matrix and controller-native performance data.
– Updated Sparkplug B to 3.1 (February 2026 release) with schema registry and compression details.
– New UNS hybrid architecture patterns (both OPC UA and Sparkplug B feeding same UNS).
– New brownfield migration pattern section (dominant 2026 field finding).
– Added post-quantum TLS readiness notes (OPC UA 4.0 roadmap, TLS 1.3 migration).
– Updated decision flowchart and scenario recommendations for FX and Sparkplug 3.1.
February 2026 (Previous Update):
– Added Sparkplug B 3.0 STATE message breaking change and migration strategy.
– Updated vendor tooling matrix (Ignition 8.1+, HiveMQ 4.7+, EMQ 5.0+).
– Added post-quantum TLS readiness assessment.
January 2026 (Initial Publication):
– First publication as a living benchmark. Covered OPC UA basics, Sparkplug B 2.2, hybrid patterns, security, decision matrix.
FAQ
Q: What’s the fastest way to get metrics from a PLC to the cloud?
Sparkplug B end-to-end (edge to regional to cloud) is the lowest latency: 10–20 ms. But if you need semantic type information at the cloud tier, OPC UA PubSub adds 20–30 ms. If you need method invocation on edge, OPC UA FX is the fastest native protocol (15–30 ms).
Q: Is OPC UA FX the same as OPC UA?
No. OPC UA FX is a simplified, connectionless variant for controller-to-controller communication. Same type system and access-control model, but no persistent sessions. Designed for <30 ms latency over Ethernet. Standard OPC UA is session-based, more overhead, broader vendor support.
Q: When should I upgrade to Sparkplug 3.1?
Sparkplug 3.1 is backward compatible with 3.0 (no breaking changes). Upgrade if you want schema registry integration, improved DEATH semantics, or bandwidth compression. If you’re running 3.0 smoothly, there’s no urgent need to upgrade.
Q: Can OPC UA run over MQTT?
Yes. OPC UA PubSub (Part 14) standardizes this. Existing OPC UA servers don’t natively support it; you need a gateway or a UA-native implementation with PubSub mode enabled (e.g., Siemens TIA 18, ABB AC900).
Q: What’s the difference between a Sparkplug B gateway and an OPC UA gateway?
A Sparkplug B gateway converts any data source (Modbus, legacy SCADA, JSON APIs) into Sparkplug B MQTT messages. An OPC UA gateway exposes legacy devices as OPC UA servers. The choice is where you want semantics: in OPC UA (client-side), in Sparkplug B (payload-side), or both (hybrid).
Q: Does the MQTT broker see the metric values in Sparkplug B?
Yes, but they’re Protobuf-encoded. The broker doesn’t decode them; it just routes the binary payload. The consumer (cloud application) decodes the Protobuf and interprets the metric values.
Q: What happens if the cloud connection goes down in the hybrid pattern?
Edge devices (OPC UA servers) keep running. Metrics stop flowing to the cloud. Depending on your plant’s autonomy model, this is acceptable (local PLC loops stay responsive) or critical (cloud analytics lag). Plan for broker redundancy (cluster mode in HiveMQ, EMQ, VerneMQ).
Q: Is Sparkplug B secure?
Yes, if you implement mutual TLS, per-topic ACLs, and automated credential rotation. It’s equivalent in security to OPC UA’s transport layer. OPC UA has finer-grained per-variable authorization, but MQTT + TLS can achieve similar security with gateway-level logic.
Q: Which protocol is cheaper to deploy?
Sparkplug B is cheaper in terms of edge footprint (1–5 MB gateway) and broker cost (stateless MQTT brokers scale cheaper than OPC UA servers). OPC UA is more expensive operationally (session management, governance, per-variable ACLs) but offers better security properties out of the box.
References and Further Reading
OPC UA & OPC UA FX (2026)
- OPC Foundation: OPC UA Specifications — Official standards, reference implementations, security guidance.
- OPC UA FX Specification — Field exchange binding, controller-native implementations.
- Siemens SIMATIC S7-1500F with OPC UA FX — Native FX support, TIA Portal integration.
- ABB AC900F Controller Specifications — OPC UA FX firmware updates (Q1 2026+).
- Rockwell CompactLogix 5380 OPC UA FX Module — Controller-native support.
Sparkplug B & MQTT (2026)
- Eclipse Sparkplug B Specification v3.1 — Latest spec, schema registry integration, compression types.
- MQTT 5.0 Standard (OASIS) — Protocol spec, QoS guarantees, shared subscriptions.
- HiveMQ Broker (4.7+) — Production MQTT broker, Sparkplug B support, OPC UA plugin.
- EMQ X (5.0+) — Open-source MQTT broker, Sparkplug B, edge clusters.
- Eclipse Tahu — Reference Sparkplug B implementation, node.js, Python, Java.
Unified Namespace & Schema Registry
- Confluent Schema Registry — Schema management for Kafka and MQTT.
- Unified Namespace Architecture for Industrial IoT — Detailed UNS design patterns and governance.
Security & Compliance
- ISO/IEC 62541-1:2023: OPC UA — General — Official standard (paid, comprehensive).
- IEC 62443-4-2: Security Development Model — Industrial cybersecurity zones and conduits.
- CISA ICS Advisories — Industrial control system security alerts.
Tooling & Implementation
- Inductive Automation Ignition 8.1+ Modules — OPC UA PubSub, Sparkplug B, gateway architecture tutorials.
- Node-RED with node-red-contrib-opcua and node-red-contrib-sparkplug — Open-source IIoT gateway framework.
- HiveMQ Broker + Extensions — OPC UA plugin, Sparkplug B native support.
Related Posts — Internal Links
Pillar: Industrial IoT & Digital Twin
Companion Reads:
– OPC UA FX Field Exchange: Reference Architecture and Deployment Guide for 2026
– Unified Namespace Architecture for Industrial IoT: Design Patterns and Governance
– MQTT Message Queuing Telemetry Transport: Protocol Deep Dive and Production Patterns
– IEC 62443 Industrial Control Systems Cybersecurity: Zones, Conduits, and Compliance Roadmap
– K3s and Edge Kubernetes for Production: A Field Guide to Lightweight Orchestration
END OF DOCUMENT
This is a living benchmark. Last updated April 18, 2026. Check back quarterly for updated benchmarks, vendor adoption trends, and emerging patterns.
