The Data Distribution Service (DDS) is a middleware standard that is ideal for production quality data communication. It is currently widely used in the fields of aerospace and defense, autonomous vehicles, as well as up-and-coming in robotics, medical devices, and power generation. DDS uses a publish-subscribe communication pattern to create a decentralized, architecture-independent, scalable, asynchronous network. To learn more about how the DDS middleware platform works, read through the DDS Conceptual Tutorial.
This tutorial covers the following aspects of DDS:
In DDS, the DDS network is referred to as the Global Data Space.
Within the Global Data Space, you can create a portion of the network referred to as a Domain. Domains are identified by a Domain name and a numeric Domain ID. There can be one or many Domains within the Global Data Space.
Within Domains there are Topics. Topics are categories that describe the type of data communicated on the network. For example, if you have an application that you would like to use DDS to receive information about the weather, a Topic could be Temperature. Domains can have one or many Topics. If you have the same Topic in different Domains they are considered distinct Topics.
Applications that use DDS are referred to a Domain Participants because they participate in a Domain. Applications that send data are referred to as Publishers and applications that receive data are referred to as Subscribers. Domain Participants can be Publishers, Subscribers, or both.
Data is sent and received on a DDS network as a Data Sample, specified by a DDS data type. A Topic registers a DDS data type, then referred to as the Registered Type, to specify the data type that must be used to communicate about that Topic. A Publisher uses a DataWriter to send data on the DDS network. A Publisher can have one or many DataWriters that publish to one or many Topics. A Subscriber uses a DataReader to receive data from the DDS network. A Subscriber can have one or many DataReaders, that subscribe to one or many Topics.
In addition to being able to send and receive data, Quality of Service (QoS), which describes the quality of the data transport, can be specified for a Topic, a Publisher or Subscriber, or specific DataReaders or DataWriters. DDS is known to have several QoS policies to help ensure exact control over data transport. You can assign individual QoS policies to these entities, or you can assign a set of QoS policies referred to as a QoS profile.
DDS is specified by the Object Management Group (OMG) standard. The standard provides specifications that explain how the DDS network must be configured and how applications should use the DDS network. The DDS standard is implemented by several different DDS vendors. Each vendor can implement the DDS standard by using a programming language of its choice. Despite varied low-level implementations, DDS vendors are interoperable (an application that uses one vendor can communicate with an application on a different vendor) because its vendors implement to the DDS standard. DDS applications, composed of the definitions previously described (for example, Domains, Topics, Data Samples, Publishers, Subscribers) can be defined in a programming language agnostic way by using XML or IDL specifications. These XML and IDL specifications provide the ability to port DDS applications between different vendors with different programming language implementations.