Data Distribution Service (DDS)

DDS provides a virtual, decentralized data space where applications read and write data as if to local memory. The middleware handles all networking, addressing, and delivery. This data-centric model decouples applications in time and space—publishers and subscribers do not need to know each other's existence, location, or lifecycle state. A Topic defines the data type and QoS, acting as the rendezvous point in this global space.

DDS operates without brokers, message queues, or central servers. Every node runs the DDS middleware and communicates directly with peers using a Real-Time Publish-Subscribe (RTPS) wire protocol. This eliminates single points of failure, reduces latency by removing intermediary hops, and enables autonomous operation even during network partitions. Discovery is fully distributed—nodes automatically find each other and match Topics without manual configuration.

DDS defines over 20 standard QoS policies that control every aspect of data flow, enabling fine-grained control over non-functional requirements:

• Reliability: Best-effort vs. fully reliable delivery with acknowledgments
• Durability: Transient local, transient, or persistent data for late-joining subscribers
• Deadline: Maximum period between data samples before a violation is flagged
• Liveliness: Heartbeat-based detection of failed publishers or subscribers
• Ownership: Determines which publisher's data takes precedence when multiple sources exist
• Partition: Logical segmentation of the data space within a Topic

DDS is designed for hard real-time systems requiring predictable, bounded latency. The RTPS protocol supports asynchronous and synchronous publication modes, configurable send/receive buffers, and transport priority mapping. Combined with Time-Sensitive Networking (TSN) at the Ethernet layer, DDS can guarantee end-to-end latency in the microsecond range for closed-loop control. The standard is widely used in autonomous vehicles, surgical robotics, and industrial motion control where jitter is unacceptable.

DDS nodes discover each other automatically through a two-phase process: Simple Participant Discovery locates nodes on the network, then Simple Endpoint Discovery matches publishers and subscribers by Topic and compatible QoS. All data is strongly typed using OMG IDL or XML schemas, and the middleware enforces type compatibility at runtime. This prevents silent data corruption from mismatched data structures and enables safe, plug-and-play integration of new devices into a running system.

DDS scales to systems with thousands of nodes through content-based and time-based filtering. Subscribers can specify filter expressions on data fields, and the middleware evaluates these at the publisher side to avoid sending irrelevant data. The DataReader cache maintains a configurable history of samples, enabling subscribers to access past data without re-requesting. Combined with multicast transport and partition-based segmentation, DDS efficiently manages bandwidth in large-scale industrial IoT deployments.

A set of configurable contracts that govern the non-functional behavior of data delivery between DDS entities. These policies allow developers to declare requirements for reliability, durability, latency budget, and liveliness on a per-Topic or per-DataReader/DataWriter basis. Key policies include:

• RELIABILITY: Guarantees delivery (Reliable) or allows best-effort fire-and-forget.
• DURABILITY: Controls whether late-joining subscribers receive historical data.
• DEADLINE: Specifies the maximum interval between data samples; violation triggers an alert.
• LIVELINESS: Determines how the system detects failed publishers or subscribers.

The core conceptual layer of the DDS standard that models the system as a global data space. Applications read and write data objects identified by a Topic name and a structured type, rather than addressing specific nodes or ports. The DCPS model abstracts away the physical location of data, allowing the middleware to handle discovery, marshaling, and delivery. This contrasts sharply with message-centric middleware where the unit of exchange is an opaque blob. In DCPS, the middleware understands the data schema, enabling content-based filtering and type-safe interactions.

The standardized, interoperable wire protocol that underpins DDS communication. RTPS defines the packet format and message exchange rules for automatic discovery, data encapsulation, and reliability over standard UDP/IP transport. It maps DDS entities like DataWriters and DataReaders directly to RTPS endpoints. The protocol supports both unicast and multicast delivery, enabling efficient one-to-many distribution without a broker. RTPS ensures that DDS implementations from different vendors can seamlessly interoperate on the same network.

A set of IEEE 802.1 Ethernet standards that guarantee bounded low-latency and zero congestion loss for time-critical traffic over standard network infrastructure. TSN provides the deterministic transport layer that DDS requires for hard real-time control. Key TSN features include:

• 802.1Qbv: Time-aware scheduling, reserving time slots for critical frames.
• 802.1AS: Precise time synchronization across all network nodes.
• 802.1CB: Frame replication and elimination for seamless redundancy. DDS over TSN combines the flexibility of data-centric middleware with the determinism of scheduled Ethernet, enabling converged networks that carry both best-effort and real-time traffic.