Overview of DDS - DCPS

Section 7.1.1.2 in the OMG's 1.2 DDS specification (formal/07-01-01) contains a more detailed overview of DDS.

A Simple Conceptual View

Simple DDS model

Publish and Subscribe

DDS is a publish and subscribe service. Data values (Samples) are transferred through the system for conceptual "Data Objects". The "publication" (the association of a Publisher and a DataWriter) send Samples to one or more "subscription" (the association of a DataReader and a Subscriber).

Basic Components of the System

The basic components are Topic, Publisher, Subscriber, DataWriter, and DataReader.

  • Topics are information about a single data type and the distribution and availability of samples.
  • Publishers apply control and restrictions to flow of data from DataWriters.
  • Subscribers apply control and restrictions to flow of data from DataReaders.
  • DataWriters create Samples of a single application data type.
  • DataReaders receive Samples of a single application data type.
  • A Publisher can have many DataWriters.
  • A Subscriber can have many DataReaders.
  • A DataWriter has a single Topic.
  • A DataReader has a single Topic.
  • A Topic can have many DataReaders and DataWriters.
  • A "publication" can have many associated "subscriptions".
  • A "subscription" can have many associated "publications".

Data Flow

The application on the publishing side initiates the flow of data by writing a data value to the DataWriter. The DataWriter's publication publishes the Samples. The publication sends the Samples to the associated subscription(s). Each associated Subscriber gives the recieved Sample to its DataReader(s) that are associated with the sending DataWriter. The flow ends when the application on the subscribing side retrieves the data from the DataReader.

Quality of Service (QoS) Policies control the flow of the data through the system. The Topic, DataReader, DataWriter, Publisher, and Subscriber all have QoS polices. The QoS policies of Publisher, DataWriter, and Topic control the data on the sending side. QoS policies of Subscriber, DataReader, and Topic control the data on the receiving side.

Associating a publication and subscription

The "Data Objects" are identified by Topics. Topics are compatible when they have the same name, the same data type and the QoS polices are not in conflict. When a DataReader's Topic is compatible with a DataWriter's Topic, then the "publication" and "subscription" become associated and data is published between them.

Actual Components in the System

Components of the DDS system

DDS Specification Components

The Domain is the conceptual container of the system. There is no real Domain object. Components in a domain can only communicate with components in the same domain.

The system components are called "Entities" because they all inherit from the Entity class. Each Entity has specialized QoS policies. An Entity may have a Listener, a callback interface for notifications about changes in the Entity's state. The Entity should potentially have a StatusCondition, a wait interface (using WaitSets) for detecting changes in the Entity's state.

System Entites:

  • DomainParticipant: Membership of the domain. All other entity types are attached to it.
  • Topic: Data Object that values will be published/received for
  • Publisher: Manager of the DataWriters
  • Subscriber: Manager of the DataReaders
  • DataWriter: Publishes data for a Topic
  • DataReader: Receives data published for a Topic

OpenDDS Implementation Specific Components

The DCPSInfoRepo is the OpenDDS object that maintains the state of the Domain(s). The DCPSInfoRepo detects when subscriptions and publications in a domain should be associated and notifies them to make the associations.