DDS (Data Distribution Service)

To facilitate data communication in distributed systems, the Data Distribution Service (DDS) is a data-centric communication standard defined by the Object Management Group (OMG). DDS is specifically designed for real-time systems requiring high security, low latency, and high data volume. Built on a publisher-subscribe model, this architecture enables data to be shared directly between systems without the need for an intermediary server. DDS is used in various fields including industrial automation, air traffic control, financial systems, and military applications—platforms that demand high reliability.

DDS Architecture and Core Components

DDS architecture adopts a data-centric approach, connecting applications based on the identity and content of the data. At the foundation of this structure is the concept of the Global Data Space (GDS), which provides a shared environment where all data is published and applications can read from or update it.

Core Components

• Domain Participant: Represents applications that join the DDS system and enables communication among participants within the same domain.
• Publisher and DataWriter: Components responsible for writing data to the GDS. A Publisher manages one or more DataWriter objects.
• Subscriber and DataReader: Components that read data from the GDS. A Subscriber contains one or more DataReaders.
• Topic: A structure that defines shared data by its name, data type, and Quality of Service (QoS) parameters.

These components are interconnected through compatible QoS settings during the communication process.

Real-Time Publish-Subscribe Model

DDS implements communication using a real-time publish-subscribe model. In this model, publishers emit data on specific topics, while subscribers receive data by subscribing to topics of interest. The system is entirely decoupled, allowing subscribers and publishers to operate independently without knowledge of each other.

Diagram of the DDS architecture. (Drawn with YZ)

RTPS and Network Protocols

DDS uses the Real-Time Publish-Subscribe (RTPS) protocol to transmit data over networks. RTPS operates over UDP, providing connectionless, multicast-capable communication. This protocol enables high-performance data transfer with low latency. The support for multicast significantly improves the efficient use of network resources.

Industrial Applications of DDS

DDS Architecture: Illustrates the relationship between Publisher, Subscriber, and Global Data Space. (Drawn with YZ)

Industrial Automation and the IEC 61499 Standard

The IEC 61499 standard provides a modular, event-driven architecture for distributed control systems. DDS can be employed to meet the communication requirements of this standard. The Service Interface Function Block (SIFB) structures in IEC 61499 can be mapped to DDS Topics, enabling a simplified and scalable publish-subscribe mechanism for data exchange within control systems, replacing complex socket connections.

Use in High-Security Networks

DDS is also used in network systems requiring unidirectional data transfer for enhanced security. In such systems, data diodes physically enforce unidirectional data flow. DDS’s connectionless and data-centric nature is well-suited for integration with additional security measures such as protocol translation and data filtering in unidirectional communication scenarios.

Data Diode Implementations

For example, when transferring data from a secure network to an isolated network, DDS classifies each data unit under its corresponding Topic and delivers it only to authorized data readers. This minimizes the risk of data leakage.

QoS Policies

DDS provides a comprehensive Quality of Service (QoS) configuration to meet the varying requirements of different applications. QoS policies define criteria such as data delivery deadlines, reliability levels, and resource usage.

Main QoS Policies

• Durability: Determines whether data is delivered to subscribers who join after the data was published.
• Reliability: Defines whether data is delivered reliably or on a best-effort basis.
• Latency Budget: Specifies the acceptable delay for data delivery.
• Liveliness: Verifies whether the data producer is still active.

This flexible structure makes DDS applicable across diverse application domains.