What is DDS?
The "Data Distribution Service for Real-Time Systems" (DDS) is an open standard from the Object Management Group (OMG) released in 2003 and revised in 2007. This standard is the specification of the API of a Publish-Subscribe Communication Middleware for distributed systems.
Distributed applications using DDS can publish or subscribe to "topics" of information and use a rich set of Quality of Service parameters to set up the different aspects of the communication (reliability, persistence, redundancy, lifespan, transport settings, resources...).
DDS Model:
The abstract model is very easy to understand: A topic is the definition of the structure of Data we want to share in our distributed system and a name to refer to that piece of information. For example, we could define a topic called "Vehicle Position" and its structure could be a couple of floats for x and y, and perhaps an integer for the id of the vehicle.
The topics exist in and abstract space that DDS calls "Global Data Space". Actually this abstract concept is near to the real implementation, because in the most used DDS implementations there are no intermediate brokers such as in JMS, ZeroC ICE Storm, or other Publish/Subscribe technologies.
DDS Model: The Global Data Space
The DDS Factory to create publishers and subscribers is called DDS participant. Usually an application creates one participant, publishers to publish data and/or subscribers to subscribe to data. Actually DDS defines a third level, the Datawriters and the Datareaders, and those entities are really in charge of writing/reading from the global data space, but for the sake of simplicity in this introduction, we will just talk about publishers and subscribers.
The discovery of the remote DDS participants is automatic, in the default behavior each participant sends a multicast announcement (or an unicast one to a pre-defined list of peers), and DDS maintains a list of the remote destinations.
This model is decoupled in several dimensions:
- Space: Being the discovery automatic, the distributed system is independent of the network topology. If the user changes the network topology, no changes are necessary in your applications.
- Time: The Publisher can publish completely asynchronously, without testing the subscriber(s) presence. DDS will transmit the data to the late-joiner subscribers if the persistence quality of service parameters were set to persistent.
- Redundancy: DDS allows implementing redundancy very easily. Several publishers can publish over the same topic, sharing the topic, or DDS can be setup to set the topic to exclusive, and the owner of the topic will be the publisher with highest "strength" parameter. If the owner fails, the following stronger publisher will be now the owner. Both failover and takeover behaviors can be implemented. For the subscriber side, any number of subscribers can subscribe to the same topic.
- Platform & Language: DDS is implemented in a high number of platforms (Windows, Linux, Solaris, Aix, Mac Os, Integrity, LynxOS, QNX, VxWorks... ) and languages (C,C++,Java,C#, Ada...). Your distributed system can be very heterogeneous, and a developer does not have to worry about the platform/language of the remote nodes.
- Implementation: DDS set of specifications include one for the DDS interoperability protocol, called RTPS (Real Time Publish Subscribe Protocol). Different applications in your distributed system can use different DDS implementations, and they will interoperate.
DDS Architecture:
DDS exposes a simple modular design. In the most used implementations the DDS infrastructure is just a lib (static or dynamic) you link to your application. It is not necessary to install any service or daemon.
The interoperability protocol is on top of transport layer in the OSI model thus it can be implemented over any underlying transport. Several DDS implementations expose a pluggable transport mechanism and offer typical transport options like UDP, TCP and Shared Memory, and allow adding user transports.
DDS Architecture
DDS Advantages:
- Publish/Subscribe Model: Simple and decoupled. It allows a cleaner design of your distributed system.
- Performance: In the publish/subscribe pattern, the latency is lower and the throughput higher than in request/reply patterns. In a request/reply model a requester should pull the remote participant to get the data, but in the publish/subscribe model, the publisher directly sends the data to the subscriber as soon as this data is available. The API, the object model and the QoS parameters have been planned to enable real-time performance, and usually the different implementations are really optimized.
- Automatic Discovery of remote participants: This mechanism is one of the key features of DDS. The communications are anonymous and decoupled, and the developer does not have to worry about the localization of the remote participants.
- Rich set of Qos parameters, allowing tuning every aspect of the communications: reliability, persistence, redundancy, lifespan, transport settings, resources...
- Interoperability Protocol (RTPS): This protocol can be implemented over virtually any transport, allowing the use of DDS in UDP, TCP, Shared Memory and user transports, and enabling real interoperability between the different DDS implementations.
Available Implementations:
Both commercial and open-source implementations of DDS are available. The best-known are eProsima Fast DDS (formerly known as Fast RTPS), RTI DDS, OpenSplice DDS, CoreDx, and OpenDDS.
For More information About DDS:
For more information, please contact
