Data Distribution Service (DDS)

DDS introduces the concept of a Global Data Space (GDS), a virtual shared memory accessible by all participants in a distributed system. Applications do not communicate directly with each other but instead read and write data objects (Topics) to this space. This decouples data producers (Publishers) from data consumers (Subscribers), enabling:

• Dynamic discovery of new participants without configuration changes.
• Location transparency; applications don't need to know the network location of data sources or sinks.
• Scalability as the number of participants grows, as communication is based on data identity, not point-to-point connections.

This is the core communication model of DDS. Unlike message-centric middleware, DCPS is focused on the state and value of data, not transient messages.

• Topics: Define the data structure (type) and a unique name within the Global Data Space (e.g., RobotJointState).
• Publishers: Declare intent to write data for specific Topics.
• Subscribers: Declare intent to read data for specific Topics.
• DataWriters/DataReaders: The objects used by applications to actually write or read data instances for a Topic. The middleware handles matching Publishers and Subscribers and efficiently distributing data updates.

DDS provides fine-grained control over communication behavior through a rich set of QoS Policies. These are contracts between data producers and consumers that the middleware strives to enforce. Key policies include:

• Reliability: BEST_EFFORT (faster) vs. RELIABLE (guaranteed delivery).
• Durability: VOLATILE (late joiners miss data) vs. TRANSIENT_LOCAL (history sent to new subscribers).
• History: How many samples (KEEP_LAST) or all samples (KEEP_ALL) to store.
• Deadline: The maximum expected period between data updates.
• Liveliness: How a participant signals it is still active. Mismatched QoS between a Publisher and Subscriber prevents them from connecting.

RTPS is the wire protocol that implements DDS interoperability. It is standardized separately from the DDS API and is the protocol used by ROS 2. Its features enable deterministic, real-time communication:

• Discovery Protocol: Allows participants to dynamically find each other on the network using multicast or unicast.
• User Datagram Protocol (UDP) based: Minimizes latency and overhead, though TCP is also supported.
• Interoperability: Different DDS vendor implementations can communicate if they both use the standard RTPS protocol.
• Efficiency: Uses a binary format and is designed for minimal serialization/deserialization overhead.

DDS provides a built-in, decentralized discovery mechanism that operates without a central broker. The Simple Discovery Protocol (SDP) and Enhanced Discovery Protocol allow participants to:

• Automatically advertise their existence and the Topics they publish/subscribe to.
• Discover other participants and establish direct peer-to-peer communication channels.
• Dynamically handle participant joins, leaves, and failures. This brokerless architecture eliminates a single point of failure and reduces latency, as data flows directly between matched Publishers and Subscribers after discovery is complete.

Beyond Topic-based subscription, DDS allows for content-based filtering at the subscriber side. A DataReader can attach a QueryCondition or ContentFilteredTopic to receive only data samples that meet specific criteria.

• Example: A navigation subsystem could subscribe to the ObjectDetection Topic but filter to receive only samples where object_class == 'person' and confidence > 0.8.
• This reduces network traffic and application processing load by pushing filtering logic into the middleware layer, which can evaluate filters efficiently as data is received.

DDS is the core communication middleware for ROS 2 (Robot Operating System 2), enabling deterministic data flow between sensors, planning nodes, and actuators. Its Quality of Service (QoS) policies allow developers to guarantee latency, reliability, and bandwidth for critical control loops.

• Real-time control: Ensures sensor data and actuator commands are delivered within strict deadlines.
• Modular architecture: Supports the decoupled, publish-subscribe model essential for complex robotic software stacks.
• Example: An autonomous mobile robot uses DDS to stream LiDAR point clouds to a SLAM node while simultaneously receiving velocity commands from a navigation planner.

DDS is mandated in major defense standards for its deterministic performance and robust security features. It forms the data-centric backbone for C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance) systems and unmanned platforms.

• Interoperability: Enables communication between heterogeneous systems from different vendors (e.g., radar, avionics, ground control).
• DDS Security Specification: Provides authentication, encryption, and access control for classified networks.
• Example: The U.S. Navy's Integrated Combat System uses DDS to share real-time track data between ships, aircraft, and command centers.

In Industry 4.0 and software-defined automation, DDS connects PLCs, robots, HMIs, and analytics engines into a unified, real-time data fabric. It is key to OpcUa over DDS, combining information modeling with high-performance pub/sub.

• Machine-to-Machine (M2M) Communication: Facilitates peer-to-peer data sharing without central brokers, reducing latency and single points of failure.
• Predictive Maintenance: Streams high-frequency vibration and temperature sensor data to analytics models.
• Example: A smart factory uses DDS to synchronize a robotic arm's movements with a conveyor belt's speed, with sub-millisecond coordination.

DDS enables the integration of real-time patient monitoring systems, surgical robots, and diagnostic imaging devices. Its QoS policies ensure vital signs and device status are delivered reliably and on time.

• Deterministic Latency: Critical for closed-loop systems like automated drug delivery or robotic surgery assistance.
• Data-Centric Model: Allows new devices (e.g., a new vital signs monitor) to discover and subscribe to relevant data streams dynamically.
• Example: An integrated operating room uses DDS to share real-time video from surgical scopes, patient vitals from monitors, and instrument telemetry from a robotic surgical system.

DDS is used in advanced driver-assistance systems (ADAS), autonomous driving stacks, and vehicle-to-everything (V2X) communication. It manages the high-volume, low-latency data flow between cameras, radar, fusion engines, and control units.

• Scalable Data Bus: Handles the massive data streams from multiple high-resolution sensors and LiDAR units.
• Fault Tolerance: Built-in redundancy and discovery mechanisms support functional safety requirements.
• Example: An autonomous vehicle uses DDS to distribute object detection results from a perception node to the path planning and vehicle control nodes, with strict deadlines for collision avoidance.

DDS provides the real-time data distribution layer for smart grid control systems, substation automation, and renewable energy integration. It ensures timely delivery of grid sensor data (phasor measurement units) for stability monitoring and automated control.

• Wide-Area Monitoring: Enables real-time synchrophasor data exchange across geographically dispersed substations.
• QoS for Critical Alerts: Allows high-priority fault or alarm messages to preempt regular traffic.
• Example: A utility control center uses DDS to receive real-time power flow and frequency data from hundreds of substations to dynamically balance load and generation.