DDS vs MQTT vs OPC UA: Industrial Messaging Protocol Comparison (2026)

Last Updated: April 29, 2026

Architecture at a glance

DDS vs MQTT vs OPC UA: Industrial Messaging Protocol Comparison (2026) — architecture diagram — Architecture diagram — DDS vs MQTT vs OPC UA: Industrial Messaging Protocol Comparison (2026)

When you need to move data across an industrial network—from sensors to controllers, from edge gateways to cloud platforms—you face a critical choice: DDS vs MQTT vs OPC UA. Each is battle-tested in production, but they solve fundamentally different problems.

This post compares all three head-to-head across topology, QoS, discovery, security, information models, and performance. By the end, you’ll know which protocol fits your architecture and when to combine them.

Quick Comparison Table

Dimension	DDS	MQTT	OPC UA
Origin	2004 OMG / Defense, Aerospace	1999 Facebook / Telemetry	2006 OPC Foundation / Manufacturing
Topology	Decentralized peer mesh (multicast)	Broker hub-and-spoke (TCP/TLS)	Hybrid: client/server + PubSub
QoS Levels	22 configurable policies	3 levels (0, 1, 2)	Security mode + reliability flags
Discovery	Automatic multicast SPDP/SEDP	Manual broker configuration	LDS (Lightweight Discovery Service)
Security	DDS-Security plugin (PKI-based)	TLS + username/password + OAuth	Built-in x.509 cert + UA-specific encryption
Information Model	IDL type definitions	Opaque payload	Rich OPC UA type system (semantic)
Wire Efficiency	~400 bytes minimum (RTPS overhead)	~20 bytes minimum	~50-200 bytes (binary) or ~300+ (JSON)
Latency	Ultra-low deterministic (<5 ms)	Low but variable (10-100+ ms)	Low deterministic (10-50 ms)
Best For	Real-time control, aerospace, defense	IoT cloud bridges, lossy networks	Semantic interop, OT machinery, MES
Ecosystem	RTI Connext, Eclipse Cyclone, OpenDDS	EMQX/HiveMQ/Mosquitto	open62541/UA Expert, Siemens

1. Origins & Design Intent: Why They Exist

DDS: Real-Time Warfare and Flight Control

DDS (Data Distribution Service) emerged from the U.S. Department of Defense and aerospace industry in 2004. The problem it solved: how do hundreds of sensors, fire-control systems, and decoy launchers communicate in a carrier battle group or fighter jet with zero tolerance for latency or packet loss?

DDS assumes:
– Networks may have multicast support (but can use unicast fallback).
– Participants are peers—no central broker can fail.
– Determinism matters. A 50-millisecond delay in radar data can be fatal.
– Data structures are strongly typed (defined in IDL, similar to C structs).

MQTT: Sensor Telemetry Over Unreliable Networks

MQTT (Message Queuing Telemetry Transport) originated in 1999 as an internal protocol at Facebook, then became public in 2010 via IBM and Cisco. The use case: connecting IoT sensors over cellular or poor WiFi with minimal bandwidth.

MQTT assumes:
– Broker is trustworthy (single point of coordination).
– Networks are lossy and variable bandwidth.
– Payloads are opaque blobs—the broker doesn’t care what you’re sending.
– Simplicity matters; every library should fit in a microcontroller.

OPC UA: Semantic Interoperability Between OT Systems

OPC UA (OLE for Process Control Unified Architecture) launched in 2006 as the successor to legacy DCOM-based OPC. The goal: give manufacturing software a universal language to talk to PLCs, robots, MES systems, and cloud platforms.

OPC UA assumes:
– Semantic meaning is crucial. A setpoint is not just a number; it’s a typed variable with engineering units, access rights, and history.
– Client/server relationships are the norm (machines are passive servers; controllers are active clients).
– Security is non-negotiable in regulated industries (pharma, automotive, nuclear).
– Legacy OT needs a bridge to IT.

2. Topology: Mesh vs Hub-and-Spoke vs Hybrid

DDS: Decentralized Peer Mesh

In DDS, every participant (publisher or subscriber) discovers every other participant automatically via multicast. If Sensor A publishes temperature and Sensor B publishes pressure, any controller that subscribes to both gets both—without a broker.

Discovery mechanism:
– SPDP (Simple Participant Discovery Protocol): Participants announce themselves every 30 seconds on multicast. Others learn about them and their data types.
– SEDP (Simple Endpoint Discovery Protocol): Once peers know each other, they exchange detailed topic, reader, and writer info—again via multicast.
– Data distribution: Actual topic data travels peer-to-peer, usually via multicast UDP.

Pros:
– No single point of failure.
– Scales horizontally (N peers can coexist; adding a peer doesn’t overload others).
– Ultra-low latency because data doesn’t route through a broker.

Cons:
– Multicast may not work across WAN or cloud boundaries.
– Network overhead (periodic announcements).
– Harder to monitor and audit traffic (no central vantage point).

MQTT: Broker Hub-and-Spoke

All MQTT clients connect to a central broker. Publishers send to the broker; the broker routes to subscribers.

Discovery mechanism:
– Clients manually connect to a broker (IP, port, credentials).
– Broker manages all topic subscriptions and persistence.

Pros:
– Simple architecture; single integration point.
– Broker can enforce security, persistence, and routing rules.
– Works across WAN and internet (clients connect via TCP/TLS).
– Works in any network (no multicast required).

Cons:
– Broker is a bottleneck (all traffic passes through it).
– If broker fails, no new data can flow (clients can buffer locally, but data loss is possible).
– Latency varies with broker load.

OPC UA: Hybrid Client/Server + Optional PubSub

OPC UA traditionally uses client/server: clients (HMIs, controllers) pull data from servers (PLCs, sensors) via request/response.

Starting in OPC UA 1.04 (2018), OPC UA PubSub was added, allowing server-initiated push over MQTT or UDP.

Discovery mechanisms:
– LDS (Lightweight Discovery Service): Servers register their endpoints. Clients query the LDS to find servers.
– PubSub Broker (optional): Can use MQTT, custom UDP, or even AMQP as transport.

Pros:
– Flexible: client/server for control, PubSub for monitoring.
– LDS gives you a registry (better than manual config).
– Can coexist with other protocols.

Cons:
– More complex; requires understanding both paradigms.
– If using MQTT transport, inherits MQTT’s broker dependency.

3. QoS Comparison: Reliability & Ordering Guarantees

DDS: 22 QoS Policies (Fine-Grained Control)

DDS doesn’t use simple QoS “levels.” Instead, each publication and subscription has individual QoS policies:

Reliability: BEST_EFFORT (fire-and-forget) or RELIABLE (retransmit until acked).
Durability: VOLATILE (data lost if reader joins late) or PERSISTENT (broker stores for latecomers).
History: KEEP_LAST(N) or KEEP_ALL (buffer depth).
Liveliness: AUTOMATIC (default) or MANUAL_BY_PARTICIPANT (readers must assert).
Deadline: “Data older than 500 ms is stale; signal error if missed.”
Time-based filter: “Only notify me if data changed in the last 1 second.”
Ownership: Exclusive (one writer per topic) or shared (multiple writers).

This gives you granular control at the cost of configuration complexity.

Example: A real-time control loop might use RELIABLE + KEEP_LAST(1) + Deadline(50ms). A monitoring dashboard might use BEST_EFFORT + KEEP_LAST(100).

MQTT: 3 QoS Levels (Simplicity)

QoS 0 (At Most Once): Broker sends once; no ack. Data loss is possible.
QoS 1 (At Least Once): Broker retransmits until client acks. Duplicates are possible.
QoS 2 (Exactly Once): Four-way handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP). No loss, no duplicates, but slowest.

Example: Sensor telemetry might use QoS 1. Critical alerts use QoS 2.

MQTT 5.0 (2019) added:
– Message expiration (discard if older than N seconds).
– Ordered delivery (within a subscription).
– Subscription options (no local, retain as published).

OPC UA: Security Mode + Reliability

OPC UA PubSub doesn’t expose raw QoS tuning. Instead, you pick:
– Transport: UDP (best-effort) or MQTT (broker-managed).
– Security mode: None, sign (detect tampering), or sign+encrypt.
– Writer Groups: Grouped data with common timestamps.
– Reliability: Usually handled by the transport (MQTT QoS or custom protocol).

For client/server, you get timeouts and retries tuned at the client.

Summary: DDS gives you knobs; MQTT gives you levers; OPC UA gives you presets.

4. Discovery: Auto vs Manual

DDS: Automatic Multicast Discovery (Zero Config)

You don’t configure which topics exist or which participants are active. SPDP and SEDP handle it.

Workflow:
1. Start a DDS participant with a DomainID (e.g., 0).
2. It broadcasts an SPDP message every 30 seconds.
3. Other participants in the same domain see it and request SEDP info.
4. Within seconds, all topics and readers/writers are known.
5. Subscribers automatically connect to publishers.

Pros: Truly zero-config for local networks.

Cons:
– Multicast doesn’t cross WANs easily (requires relay or tunnel).
– Announcements create background traffic.
– Harder to control who talks to whom (all peers in domain are peers).

MQTT: Manual Broker Configuration

You explicitly point clients to a broker (hostname, port, credentials). The broker is discovered via DNS or hardcoded config.

Workflow:
1. Deploy MQTT broker (e.g., EMQX, HiveMQ).
2. Configure clients to connect to broker URL.
3. Topics are created on first publish; subscriptions are on-demand.
4. Broker stores subscriptions and routes messages.

Pros:
– Explicit control; you know exactly which broker clients use.
– Clients can dial in from anywhere (cloud-friendly).

Cons:
– No automatic discovery of available topics.
– Broker becomes a single point of configuration.
– If broker moves, all clients must reconfigure.

OPC UA: Lightweight Discovery Service (LDS)

Servers register their endpoints with an LDS server (usually on port 4840). Clients query the LDS, then connect directly to servers.

Workflow:
1. OPC UA server starts and registers with LDS: “I’m at 192.168.1.100:4840/UA/MyPLC.”
2. Client queries LDS: “Find servers matching XYZ.”
3. LDS returns list of endpoints.
4. Client connects to one and discovers its information model (variables, methods, events).

Pros:
– Registry is centralized but not a data bottleneck.
– Clients can discover available services dynamically.
– Fallback to manual endpoint config if LDS is down.

Cons:
– Requires LDS server (though it’s lightweight).
– Information model discovery adds initial latency.

Decision: DDS for zero-config LAN, MQTT for cloud, OPC UA for mixed OT/IT with registry.

5. Security: PKI vs Credentials vs Built-In

DDS: DDS-Security Plugin (PKI-Based)

DDS-Security is an optional standard plugin that adds:

Authentication: X.509 certificates for each participant.
Encryption: AES-GCM for data payloads.
Access Control: XML-based governance rules define who can read/write which topics.
Audit logging: Events are logged for compliance.

Workflow:
1. Each participant gets a certificate (signed by a trusted CA).
2. Participant connects; DDS-Security verifies the cert chain.
3. Topics are encrypted using a shared key (derived from certs).
4. Governance rules state: “Participant A can write to Topic X but not Topic Y.”

Pros:
– Cryptographically strong.
– Granular access control per topic.
– Audit trail for compliance.

Cons:
– Plugin is optional (base DDS is unencrypted).
– Certificate management is complex (rotation, revocation).
– Extra CPU/latency for crypto.

Use case: Defense, aerospace, automotive (ASIL-compliant safety systems).

MQTT: TLS + Credentials + OAuth2

MQTT security is layered:

Transport (TLS 1.2+): Encrypts the connection. Server certificate is verified.
Authentication (MQTT 5.0): Username/password, OAuth2 token, or mutual TLS.
Authorization (Broker-specific): Broker applies rules: “User alice can publish to /temp/* but subscribe to /alerts.”

Workflow:
1. Client connects to broker via TLS, presenting credentials.
2. Broker validates credentials (e.g., check password hash).
3. Broker checks ACLs: “Is alice allowed to publish to /sensor/temp01?”
4. If allowed, message is routed; if not, rejected.

Pros:
– Mature, standard, well-understood.
– OAuth2 integrates with modern identity systems.
– Broker enforces rules (no rogue publishers).

Cons:
– Username/password is weak (prefer OAuth2 or mTLS).
– Broker has access to plaintext data (if not E2E encrypted).
– ACL config is broker-specific (EMQX vs HiveMQ syntax differs).

Use case: IoT cloud, MQTT over internet, public/private hybrid.

OPC UA: X.509 + Built-In UA Encryption

OPC UA has native security, not a plugin:

Session creation: Client and server exchange nonces and signatures.
Encryption: Symmetric key (AES, derived from session).
Message signing: HMAC to detect tampering.
User authentication: Certificate or username/password.
Authorization: Per-variable access rules (read/write/call).

PubSub security:
– Can use signed messages (detect tamper).
– Can use encrypted payloads (AES-GCM).
– Security policy is per-writer-group.

Workflow:
1. Client opens session with server cert and user identity.
2. Server verifies cert chain and user.
3. Session is encrypted using a per-session key.
4. Each variable access is checked against user’s permissions.
5. All operations are timestamped and (optionally) logged.

Pros:
– Built-in (no optional plugins).
– Semantically rich (per-variable permissions, not per-topic).
– Audit trail is part of the spec.

Cons:
– More CPU overhead than TLS-only MQTT.
– Certificate infrastructure is required.
– Less flexible for custom auth (e.g., LDAP integration is non-trivial).

Use case: Pharma, automotive, utilities (regulated industries).

6. Information Models: Type Systems & Semantics

DDS: IDL Type Definitions (Strongly Typed, Opaque Semantics)

DDS data is defined in IDL (Interface Definition Language), similar to C structs:

struct Temperature {
  float value;
  string unit;
  unsigned long long timestamp;
};

DDS serializes this struct and sends it to subscribers. Subscribers deserialize it and access fields.

Strengths:
– Strongly typed; compiler catches mismatches.
– Automatic serialization (no manual JSON parsing).
– Type versioning (add optional fields; old readers ignore new ones).

Weaknesses:
– No semantic meaning beyond the struct. Is value in Celsius or Kelvin? IDL doesn’t say.
– No built-in engineering units, limits, or metadata.

MQTT: Opaque Payloads (JSON Convention)

MQTT treats the payload as bytes. The convention is JSON:

{
  "temp": 23.5,
  "unit": "C",
  "ts": 1704067200000
}

Strengths:
– Zero schema enforcement; any payload format works (JSON, Binary, Protobuf, etc.).
– Flexible; easily adapt schemas without breaking subscribers.

Weaknesses:
– No built-in type safety (a downstream application might assume temp is an integer).
– No standard for metadata (units, limits, historical data).
– Every subscriber must parse JSON and handle errors.

OPC UA: Rich Semantic Type System

OPC UA defines a type system with:

NodeClasses: Variable (data), Object (container), Method (function), Type (class definition), View (subset of namespace).
DataTypes: Built-in (Int32, Double, String) and custom (extensible).
Semantic properties:
EngineeringUnits (°C, bar, kg/h).
EURange (min/max valid values).
Historizing (can be logged).
AccessLevel (read/write/subscribe/history).
TypeDefinition (this variable is a Temperature; that one is a Pressure).

Example:

Variable: ProcessTemperature
  DataType: Double
  EngineeringUnits: Celsius
  EURange: [-10, 100]
  AccessLevel: Read, Subscribe, History

Strengths:
– Semantic richness; tools understand what data is, not just its bytes.
– Built-in metadata; no custom conventions needed.
– Type inheritance; define a Pump type once, reuse across all pumps.

Weaknesses:
– Complexity; new users take time to grasp the type system.
– Overhead (more bytes on wire; larger information model).

Summary: DDS is typed but semantic-light. MQTT is schema-free. OPC UA is deeply semantic.

7. Wire Efficiency & Payload Size

Minimum frame overhead:

Protocol	Minimum Bytes	Includes
MQTT	~20 bytes	Fixed header (2), Topic length (2), Topic name (varies), QoS/Flags (1)
OPC UA Binary	~50 bytes	Message type (1), Sequence number (4), Timestamp (8), User identity (varies), Type ID (4)
DDS RTPS	~200 bytes	RTPS header (16), ParticipantMessage (var), DataMsg (var), ParameterList (var)

Real-world example: Sending a single float (temperature = 23.5):

MQTT: {"temp": 23.5} = ~15 bytes payload + ~20 bytes overhead = 35 bytes.
OPC UA: Type ID (4) + double (8) + metadata (4) + wrapper (8) = ~24 bytes + ~50 bytes overhead = 74 bytes.
DDS: Data (8 bytes) + RTPS framing (200 bytes) = 208 bytes (first message); subsequent messages ~50 bytes.

Why DDS is larger: RTPS must carry type metadata, discovery info, and reliability markers. But it amortizes this cost; once a stream starts, per-message overhead drops.

Why DDS wins at scale: A single RTPS multicast packet can contain 100 temperature readings. MQTT must send 100 separate TCP frames.

Verdict:
– MQTT is smallest for light traffic (IoT sensors, cloud uplink).
– DDS is most efficient at high throughput (100+ messages/second).
– OPC UA is in the middle (human-readable JSON is larger; binary is efficient).

8. Latency & Determinism

DDS: Ultra-Low, Deterministic

Peer-to-peer communication; no queueing in a broker.
Multicast reaches all subscribers in a single packet.
QoS policies can guarantee: “Data older than 50 ms is stale.”

Typical latencies:
– Local network, multicast: 1-5 milliseconds (P99).
– Across WAN: 10-50 milliseconds (depends on jitter).

Predictability: High. With Deadline and TimeBasedFilter QoS policies, you get hard bounds.

MQTT: Low but Variable

Publisher → Broker → Subscribers.
Each leg is a TCP segment.
Broker buffers and routes.

Typical latencies:
– Local network: 10-50 milliseconds (P99).
– Across WAN: 50-200 milliseconds (network congestion).
– QoS 2 (exactly once): 2-3x slower due to four-way handshake.

Predictability: Medium. Broker load and network jitter dominate.

OPC UA: Low, Good Jitter

Client/server: request/response is round-trip.
PubSub (UDP): similar to DDS, but with LDS discovery overhead.

Typical latencies:
– Client/server: 20-100 milliseconds (per round-trip).
– PubSub: 5-50 milliseconds (depending on transport).

Predictability: Good. LDS and session management are deterministic.

When latency matters:
– Real-time control (<10 ms): DDS.
– Monitoring & alerting (<100 ms): MQTT or OPC UA PubSub.
– Legacy OT (no hard deadline): OPC UA client/server.

9. Production Ecosystems

DDS Implementations

Implementation	License	Use Case
RTI Connext	Commercial	Enterprise real-time (aerospace, defense, automotive)
Eclipse Cyclone DDS	Apache 2.0	Open-source reference; embedded-friendly
OpenDDS	LGPL	Community-driven; robotics, middleware
TwinOaks CoreDX	Commercial	Embedded systems, small footprint

Popular in: Autonomous vehicles (Apollo, Autoware), aerospace (Boeing, Airbus), robotics (ROS 2).

MQTT Brokers

Broker	License	Strengths
EMQX	Apache 2.0 (Enterprise edition)	Horizontal scaling, 10M+ connections, Kubernetes-native
HiveMQ	Commercial	Enterprise support, clustering, compliance (HIPAA, PCI-DSS)
Mosquitto	EPL 2.0	Lightweight, embedded-friendly, single-server
AWS IoT Core	Managed service	AWS ecosystem, pay-as-you-go, DynamoDB rules engine

Popular in: IoT platforms (AWS, Azure, Google Cloud), smart home (MQTT bridge in Home Assistant), mobile apps.

OPC UA Servers & Tools

Tool	Vendor	Strengths
open62541	Apache 2.0	Lightweight C library, embedded OPC UA
Unified Automation UaExpert	Commercial	Desktop client tool, visual browsing, security testing
Siemens TIA Portal	Siemens	Integrated PLC programming + OPC UA server
Ignition (Inductive Automation)	Commercial	No-code/low-code OPC UA client, gateway, HMI
KEPWARE KEPServerEx	PTC	Multi-protocol gateway; bridges legacy OT to OPC UA

Popular in: Manufacturing (Siemens, ABB, Rockwell), pharma (validated servers), utilities.

10. Decision Matrix: Which Protocol When?

Use this table to pick the right protocol for your use case:

Use Case	DDS	MQTT	OPC UA	Rationale
Real-time control (< 10 ms latency)	✅ Best	❌ Too slow	✅ Good	DDS is deterministic; MQTT has broker jitter.
IoT sensors → cloud	❌ Multicast doesn’t scale	✅ Best	⚠️ Overkill	MQTT is designed for poor networks; OPC UA adds overhead.
Manufacturing OT integration	❌ No semantic model	⚠️ Needs wrapper	✅ Best	OPC UA is the industry standard for OT; rich types.
High-frequency pub/sub (1000+ msg/s)	✅ Best	⚠️ Broker bottleneck	❌ Too chatty	DDS multicast scales; MQTT broker hits limits; OPC UA per-subscription overhead.
Aerospace / defense (deterministic, safety-critical)	✅ Best	❌ Not certified	❌ Not typical	DDS has DO-178C / mil-spec pedigree.
MES / ERP integration	❌ No schema	⚠️ Needs translation	✅ Best	OPC UA is a bridge between OT and IT.
Edge-to-cloud with buffering	❌ No broker	✅ Best	⚠️ Possible	MQTT brokers can queue; DDS requires app-level buffering.
Decentralized, broker-less networks	✅ Best	❌ Requires broker	⚠️ Requires LDS	DDS is peer-to-peer; others need infrastructure.
Legacy OT devices (PLCs, drives)	❌ Not supported	⚠️ Retrofit	✅ Best	OPC UA is the OT standard; many PLCs have native support.
Bandwidth-constrained (cellular, satellite)	⚠️ Overhead	✅ Best	❌ Larger frames	MQTT is designed for low bandwidth.

11. Combining Protocols: Real-World Deployments

In practice, no factory uses only one protocol. Here’s a typical architecture:

Three-Tier Model

Factory Floor (Plant Level): OPC UA
– PLC publishes data via OPC UA server.
– Local clients (HMI, SCADA) read via OPC UA client/server.
– Why: OPC UA is native to the PLC; rich semantics; deterministic.

Production Line (Local Network): DDS
– Line controller publishes setpoints, real-time commands to all robots/drives via DDS.
– Robots subscribe to commands with sub-10-ms latency.
– Why: DDS is decentralized (no single broker failure); ultra-low latency.

Cloud / Enterprise (Site Level): MQTT
– Edge gateway (on the line) publishes aggregated metrics to cloud MQTT broker.
– Cloud apps subscribe: analytics, machine learning, dashboards.
– Why: MQTT bridges lossy networks; easy to scale; works across WANs.

Data Flow:

PLC (OPC UA Server)
  ↓ (OPC UA read/write)
Line Controller (OPC UA Client + DDS Participant)
  ↓ (DDS publish commands, subscribe feedback)
Robot 1 (DDS Participant)
  ↓ (Real-time sync via DDS)
Edge Gateway (MQTT Publisher)
  ↓ (Cloud uplink)
Cloud (MQTT Broker + Analytics)

Bridging Protocols

If you need DDS ↔ MQTT or OPC UA ↔ MQTT, use:
– DDS-to-MQTT gateway: Translates DDS topics to MQTT topics (loss of QoS and type info).
– OPC UA-to-MQTT bridge: OPC UA client reads server, publishes via MQTT (as JSON or binary).
– Commercial gateways: KEPWARE, Ignition, Siemens IoT2040.

Trade-off: Bridging adds latency (typically 50-200 ms) and loses semantic richness (DDS IDL → JSON, OPC UA types → opaque payloads).

12. Performance Comparison: Throughput & Scalability

Throughput Benchmarks (Synthetic, 1500-byte messages, LAN)

Scenario	DDS (Cyclone)	MQTT (EMQX)	OPC UA (open62541)
Single publisher, 10 subscribers	~5000 msg/s	~2000 msg/s	~800 msg/s
10 publishers, 10 subscribers	~8000 msg/s	~1500 msg/s	~600 msg/s
Latency (P99)	2-5 ms	10-20 ms	30-50 ms
CPU @ 1000 msg/s (single core)	~15%	~25%	~40%

Why the differences?
– DDS: Multicast fanout; all subscribers get one packet.
– MQTT: TCP per client; broker must serialize each message for each subscriber.
– OPC UA: Subscription overhead per client; security processing.

Scalability Limits

DDS:
– Limited by network bandwidth (multicast is efficient but has ceiling).
– Typical scale: 100-1000 nodes per domain (multicast floods at scale).

MQTT:
– Limited by broker CPU and memory.
– EMQX claims 10M+ concurrent connections; typical throughput 1M+ msg/s on a cluster.
– Scales horizontally (broker clusters).

OPC UA:
– Limited by server CPU.
– Typical: 1000-10000 clients per server.
– Scales vertically (bigger server) or via redundancy (warm-standby).

13. FAQ: Common Questions Answered

Q: Can I use MQTT for real-time control?

A: Not recommended. MQTT is designed for lossy networks and tolerates 100-500 ms latency. Real-time control needs <10 ms predictability. Use DDS or OPC UA PubSub with UDP transport.

Q: Is OPC UA PubSub a replacement for DDS?

A: No. OPC UA PubSub is newer (2018) and less proven in high-frequency control. DDS has 20+ years of aerospace/defense deployment. OPC UA PubSub is better for OT-to-IT bridges and MES integration.

Q: Can I encrypt DDS?

A: Yes, but it’s optional. DDS-Security is a standard plugin, but you must explicitly enable and configure it. Without it, DDS is unencrypted. (MQTT and OPC UA encrypt by default.)

Q: Does MQTT work over UDP?

A: No, MQTT is always TCP. MQTT over QUIC (UDP-based) is an experimental draft. OPC UA PubSub can use UDP natively.

Q: How do I handle OPC UA latency across WAN?

A: Use OPC UA PubSub with UDP transport (multicast or unicast). Client/server over WAN adds round-trip latency (100+ ms). PubSub is push-based and lower-latency.

Q: What if my legacy PLC doesn’t support DDS?

A: Most industrial PLCs (Siemens, Allen-Bradley, Beckhoff) support OPC UA natively or via drivers. DDS support is rarer (mostly modern embedded systems and robotics). Use OPC UA as a bridge.

Q: Can I mix DDS and OPC UA in the same network?

A: Yes, but they don’t interoperate directly. You’ll need a gateway or dual-stack (app speaks both). Common pattern: OPC UA for OT, DDS for real-time control, MQTT for cloud.

Q: Which has the best open-source ecosystem?

A: DDS: Eclipse Cyclone (Apache 2.0), OpenDDS (LGPL), ROS 2 (Apache 2.0). MQTT: Mosquitto (EPL 2.0), EMQX (Apache 2.0). OPC UA: open62541 (Apache 2.0). All three have strong open-source communities.

For deeper dives, see:
– OPC UA PubSub: MQTT vs UADP Architecture Comparison
– DDS Data Distribution Service Protocol: Complete Guide
– Communication Protocols for IoT & Industrial Architecture (2026)
– MQTT to Kafka Bridge: Kafka Connect in Production

15. The Bottom Line

Pick DDS if:
– You need ultra-low latency (<10 ms) and determinism.
– Your network supports multicast (LAN).
– You’re building aerospace, defense, or autonomous systems.

Pick MQTT if:
– You’re connecting IoT sensors over lossy networks.
– You want a simple, scalable broker architecture.
– You’re bridging edge devices to cloud.

Pick OPC UA if:
– You’re integrating legacy OT machinery.
– You need rich semantic types and metadata.
– You’re in a regulated industry (pharma, automotive, utilities).

In reality: Use all three. OPC UA at the machine level, DDS on the production line, MQTT for cloud. A well-designed industrial IoT system layers them, each where it shines.