Data Distribution Service (DDS)

The core abstraction of DDS is a globally addressable data space where applications communicate by reading and writing data-objects, identified by unique keys and topics. This decouples producers (publishers) from consumers (subscribers), as they interact with the data space rather than directly with each other.

• Decoupled Communication: Publishers and subscribers have no direct knowledge of each other's identity, IP address, or existence.
• Data-Centricity: The system is organized around the data itself, not the endpoints, simplifying system design and evolution.
• Automatic Discovery: The middleware automatically discovers compatible data readers and writers on the network.

DDS provides a rich set of configurable Quality of Service (QoS) policies that allow developers to precisely control the behavior of data delivery. These policies are attached to data readers, writers, topics, and publishers/subscribers.

Key QoS policies include:

• Reliability: Choose between BEST_EFFORT (low overhead) and RELIABLE (guaranteed delivery with acknowledgments).
• Durability: Configures data persistence (e.g., VOLATILE, TRANSIENT_LOCAL, TRANSIENT, PERSISTENT).
• Deadline: Specifies the maximum expected period between data updates.
• Latency Budget: Informs the middleware of acceptable end-to-end latency.
• Liveliness: Defines how publishers signal they are alive; readers can detect publisher failures.
• History & Resource Limits: Controls how many samples are kept (e.g., KEEP_LAST, KEEP_ALL) and memory allocation.

The underlying wire protocol for DDS is the Real-Time Publish-Subscribe (RTPS) Protocol, a standardized, interoperable protocol that operates over standard UDP/IP and other transports. RTPS enables the key DDS features.

• Interoperability: Different DDS vendor implementations can communicate seamlessly over the network using RTPS.
• Efficiency: Uses UDP multicast for efficient one-to-many data distribution where supported.
• Discovery: Defines the SPDP (Simple Participant Discovery Protocol) and SEDP (Simple Endpoint Discovery Protocol) for automatic discovery of participants and their data endpoints.
• Modular Transport: Can be adapted to various transports, including shared memory, TCP, or custom deterministic networks.

DDS features a fully dynamic discovery mechanism. Applications (DDS Participants) automatically discover each other on the network and negotiate compatible data types and QoS settings without any central configuration server.

• Zero-Configuration Networking: New nodes can join or leave the system at runtime without disrupting others.
• Type Checking: The middleware validates that the data types (defined via IDL or XML) of matching readers and writers are compatible.
• QoS Negotiation: If a publisher's offered QoS (e.g., Reliability=RELIABLE) is incompatible with a subscriber's requested QoS (e.g., Reliability=BEST_EFFORT), the connection is not established.

Subscribers can use content-based filters to receive only the data that matches specific criteria, reducing network and processing overhead. This is more powerful than traditional topic-based filtering.

• SQL-like Queries: Filters are expressed using a subset of SQL (e.g., "temperature > 100 AND zone = 'A'").
• Efficiency: Filtering can be performed at the publisher side or in the network, preventing unwanted data from being sent to uninterested subscribers.
• Dynamic Changes: Queries can be changed at runtime, allowing subscribers to adapt their data interests based on application state.

DDS is designed for deterministic, dependable systems common in robotics, aerospace, and industrial control. Its architecture provides built-in mechanisms for fault tolerance and predictable behavior.

• Redundancy: Supports active/passive or active/active redundancy for critical data writers.
• Ownership Strength: Allows multiple publishers on the same topic, with the one having the highest "ownership strength" being the active writer—enabling seamless failover.
• Time-Based Data Management: Built-in timestamps and QoS policies like Deadline and Liveliness allow the system to monitor and react to data flow anomalies in real-time.
• Deterministic Latency: When paired with a real-time operating system and network (e.g., TSN), DDS can provide bounded, predictable latencies.

DDS orchestrates communication between hundreds of sensors, compute nodes, and actuators in self-driving cars and drones. It manages the high-volume, low-latency data flow required for perception, planning, and control.

• Key QoS Policies: DEADLINE, LIVELINESS, and RELIABILITY ensure critical messages (e.g., LiDAR point clouds, collision warnings) are delivered on time and in order.
• Example: A drone swarm uses DDS for coordinated flight. Each agent publishes its position and subscribes to the formation's target, with DDS handling the dynamic discovery and reliable multicast of state data.

In Industry 4.0 environments, DDS connects robotic arms, AGVs (Automated Guided Vehicles), and programmable logic controllers (PLCs) into a unified, responsive system.

• Data-Centric Design: The global data space allows any authorized node (e.g., a central supervisor) to subscribe to the joint torque of a robot or the location of an AGV without point-to-point configuration.
• Determinism: Coupled with Time-Sensitive Networking (TSN), DDS provides the deterministic latency needed for synchronized multi-robot assembly lines, where a millisecond delay can cause a production fault.

DDS is a standard in modern avionics, notably in the FACE (Future Airborne Capability Environment) and ROSITA (Robust Software Integration Technology for Avionics) standards. It enables modular, upgradeable mission systems.

• Use Case: In a fighter jet, one subsystem publishes fused sensor data (radar, EO/IR) to a Global Data Space. Multiple consumers—like the display, weapon system, and defensive aids—subscribe to this single source of truth, reducing data duplication and latency.
• Dependability: QoS policies like DURABILITY (persisting last-known values for late-joining subscribers) and OWNERSHIP (managing hot-standby redundancy) are critical for safety-critical flight systems.

DDS enables the precise, real-time communication required for robotic-assisted surgery, where haptic feedback and actuator control must be perfectly synchronized.

• Low-Latency Control Loops: The surgeon's input from a haptic controller is published as a high-priority data stream. The robotic arm's control node subscribes to this stream and must receive updates within a strict deadline to provide fluid, immediate response.
• Safety & Redundancy: The OWNERSHIP_STRENGTH QoS allows for primary/backup publisher pairs. If the primary control node fails, the backup automatically takes over publishing control commands without disrupting the data flow to the actuators.

DDS forms the communication backbone for Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) networks, connecting soldiers, vehicles, and command centers.

• Dynamic Discovery: New assets (e.g., a deployed UAV) automatically discover and join the tactical data network, publishing their sensor feeds. Command posts subscribe to these feeds without manual reconfiguration.
• Scalability & Filtering: The Content-Subscription feature allows subscribers to receive only data that matches specific criteria (e.g., "images from sector Alpha-7"), conserving bandwidth in resource-constrained environments.

The power of DDS lies in its configurable Quality of Service (QoS) policies, which define contracts between publishers and subscribers.

• RELIABILITY: Set to RELIABLE for command data (must not be lost) or BEST_EFFORT for high-frequency sensor data where the latest value is most important.
• HISTORY: Keeps a cache of the last N samples. A navigation system might use a KEEP_LAST history of 1 (only current position), while a diagnostics logger might use KEEP_ALL.
• DEADLINE: Specifies the maximum expected period between data updates. A motor controller expecting heartbeat updates every 100ms will be notified if the publisher misses this deadline, triggering a fault response.
• LIVELINESS: Ensures publishers are still "alive." A system can be configured to automatically infer a node failure if its LIVELINESS lease expires, enabling fail-over.

The configurable behavior contracts that define how DDS manages data delivery. Unlike basic messaging, DDS allows fine-grained control over reliability, timeliness, and resource usage. Key policies include:

• Reliability: BEST_EFFORT vs. RELIABLE (guaranteed delivery).
• History: KEEP_LAST (circular buffer) vs. KEEP_ALL.
• Deadline: The maximum expected period between data updates.
• Liveliness: How publishers signal they are still active.
• Time-Based Filter: Allows subscribers to skip updates arriving faster than a specified period.

These policies allow engineers to trade off latency, bandwidth, and reliability for each data stream.

The virtual, distributed data repository conceptual model of DDS. Applications do not communicate directly with each other but instead read and write data into this shared space, accessed via topics. This model provides:

• Data-Centricity: The system is designed around the data and its QoS, not the endpoints.
• Decoupling: Writers and readers can join or leave dynamically without disrupting the system.
• Built-in State Management: Late-joining subscribers can request historical data (if QoS permits) to immediately understand system state.

This is a key differentiator from message-centric middleware like AMQP or MQTT.