DDS: The Real-Time Data Distribution Service Powering ROS 2 and Autonomous Vehicles

TL;DR:

• DDS (Data Distribution Service) is an OMG open standard for publish-subscribe messaging with automatic peer discovery and configurable Quality of Service
• It’s the default communication middleware in ROS 2 and is used in ADAS, aerospace, defence, and industrial control systems
• Key implementations: Eclipse Cyclone DDS (default in ROS 2), eProsima Fast DDS, RTI Connext DDS (commercial)

If you’ve worked with ROS 2, you’ve used DDS without necessarily knowing it. If you’ve worked on ADAS systems, aerospace avionics, or high-frequency industrial control, you may have worked with it directly. DDS is the kind of infrastructure that sits below the application layer — invisible when it works correctly, painful when you need to understand why something isn’t working.

This guide explains what DDS is, how it works, and when it’s the right choice over simpler messaging systems.

What DDS Is

Data Distribution Service is a publish-subscribe communication standard published by the Object Management Group (OMG). The current version is DDS 1.4. It defines:

• A data-centric pub/sub model where participants publish and subscribe to typed data topics
• Automatic discovery — nodes find each other without a central broker
• Quality of Service (QoS) policies that control reliability, latency, history, and durability behaviour
• A wire protocol called RTPS (Real-Time Publish-Subscribe) that runs over UDP

The “data-centric” framing is important. In a traditional message queue, you send messages. In DDS, you write data to a topic that has a schema. Subscribers receive the current and historical state of that data, not just individual messages. This distinction matters for systems that care about state rather than events.

How DDS Discovery Works

One of DDS’s defining characteristics is its broker-free architecture. Unlike MQTT (which requires a broker like Mosquitto or EMQX) or AMQP (which requires RabbitMQ or a similar server), DDS participants discover each other automatically using a multicast-based protocol.

When a DDS participant starts, it announces itself on well-known multicast addresses. Other participants on the same network respond with their topic information. Once matched — meaning a publisher and subscriber are publishing and subscribing to the same topic with compatible QoS policies — data flows directly between them using UDP unicast.

This means:

• No single point of failure from a central broker
• Sub-millisecond latency is achievable because there’s no broker hop
• Discovery happens automatically when nodes come online — useful in dynamic robotic systems where components start and stop

The downside is that multicast discovery can be problematic in cloud and container environments where multicast traffic is restricted or blocked. For those deployments, DDS implementations support unicast-only discovery with explicit peer lists.

Quality of Service Policies

QoS is where DDS’s expressiveness comes from. Rather than a binary reliable/unreliable choice, DDS defines roughly 20 QoS policies that control different aspects of data exchange behaviour.

The most commonly configured ones:

Reliability: RELIABLE guarantees delivery (with retransmission); BEST_EFFORT drops messages if the network can’t keep up. Sensor telemetry often uses BEST_EFFORT (a slightly stale lidar scan is better than a delayed one); a command channel uses RELIABLE.

Durability: VOLATILE only delivers data to subscribers that are already online; TRANSIENT_LOCAL makes publishers cache their last N samples so late-joining subscribers can receive recent state. Useful for configuration data that new nodes need when they start.

Deadline: The publisher or subscriber declares that data must be published/consumed within a maximum period. If the deadline is missed, an error condition is triggered. This supports watchdog-like behaviour without application code.

Lifespan: Data samples expire after a configurable time and are not delivered to new subscribers after expiry.

History: KEEP_LAST retains the N most recent samples; KEEP_ALL retains everything (subject to resource limits). History interacts with durability to control what late subscribers receive.

QoS policy compatibility determines whether a publisher and subscriber can match. A subscriber requesting RELIABLE will not match a BEST_EFFORT publisher. Getting QoS right is one of the more common debugging tasks in DDS-based systems.

DDS in ROS 2

ROS 2 adopted DDS as its default communication layer, replacing the custom tcpros/udpros protocol from ROS 1. The abstraction layer between ROS 2 and DDS is called the RMW (ROS Middleware Interface), which means you can swap DDS implementations without changing application code.

Available RMW implementations:

• rmw_cyclonedds — Eclipse Cyclone DDS, the default in recent ROS 2 distributions
• rmw_fastrtps — eProsima Fast DDS, widely used and well-documented
• rmw_connextdds — RTI Connext, the commercial option with enterprise support and additional features

ROS 2 maps its concepts onto DDS concepts: ROS Topics are DDS topics, ROS Services map to DDS request/reply patterns, and ROS 2 QoS profiles (like rclcpp::QoS(10)) translate to DDS QoS policies.

Most ROS 2 developers interact with DDS indirectly through rclcpp/rclpy. But understanding the underlying DDS layer becomes important when:

• Debugging discovery failures between nodes on different machines
• Tuning QoS for latency-sensitive or bandwidth-constrained scenarios
• Integrating ROS 2 systems with non-ROS DDS participants
• Configuring DDS for use over Wi-Fi or in containerised deployments

DDS in Automotive ADAS

Outside robotics, DDS is a foundation technology in automotive software architectures. AUTOSAR Adaptive (the software platform for high-performance automotive compute) supports DDS as a service-oriented communication middleware alongside SOME/IP.

In an ADAS system, dozens of compute nodes — processing lidar, camera, radar, and sensor fusion — need to exchange data at low latency with reliability guarantees. DDS’s combination of typed pub/sub, QoS control, and peer discovery maps well onto this architecture.

Several OEMs and Tier 1 suppliers use RTI Connext DDS for ADAS applications, particularly where functional safety requirements (ISO 26262) require validated middleware with certified implementations.

DDS in Aerospace and Defence

DDS has been used in aerospace and defence systems for over a decade. The US Navy’s Generic Open Architecture (GOA) specified DDS as a communication backbone; it’s used in submarine combat systems, unmanned vehicles, and simulation systems.

The robustness of DDS in these domains comes from the absence of a broker (nothing to fail), the QoS deadline and liveliness policies (which enable watchdog monitoring without application code), and the availability of certified implementations with deterministic performance guarantees.

Implementations Compared

For new projects, Cyclone DDS or Fast DDS are the natural choices. RTI Connext makes sense for programmes requiring commercial support or safety-certified middleware.

When to Use DDS vs Alternatives

DDS is well-suited for:

• Systems with multiple distributed nodes that need to find each other dynamically
• Real-time data where QoS control over latency, reliability, and history matters
• Safety-critical or mission-critical systems that need validated middleware
• Interoperability with existing ROS 2 or AUTOSAR Adaptive systems

DDS is overkill for:

• Simple IoT deployments where MQTT is sufficient
• Cloud microservices where Kafka, NATS, or gRPC are more appropriate
• Embedded systems too constrained for DDS’s memory footprint (though micro-DDS implementations like eProsima Micro XRCE-DDS bring DDS to microcontrollers via an agent bridge)

The learning curve is real. DDS’s QoS model is expressive but requires understanding to use correctly. For general-purpose distributed systems in cloud environments, the simpler alternatives are often the right call. For distributed real-time systems in physical environments — robotics, vehicles, manufacturing — DDS earns its complexity.