Data Distribution Service (DDS):

An Open Standard for Publish-Subscribe Communications

DDS is an Object Management Group (OMG) standard that defines a system, application programming interface (API) and wire protocol for type-safe network communications. DDS was designed specifically to meet the performance and QoS requirements of real-time and embedded systems. It has been adopted in time-critical and mission-critical applications including tactical defense systems; aerospace; railroad and roadway traffic management; industrial control; Supervisory Control and Data Acquisition (SCADA); financial market data distribution; and
automated trading.

The Open Architecture design of DDS can reduce the software lifecycle costs and risks associated with systems that will be maintained over the course of many years.

• DDS provides an Open Standard based communications architecture. By eliminating custom software and providing standard interfaces, DDS reduces development time and eases maintenance.
• DDS decouples applications. By avoiding hardcoded, stovepipe systems, individual subsystems can be added or upgraded without modifying other software.
• DDS applications are interoperable across operating systems, hardware architectures and programming languages.
• DDS provides vendor independence. Applications are portable and interoperable across compliant implementations.

IT decision makers are looking for freedom from vendor lock-in: the concept that once you start using a particular vendor’s product, it will take too many resources to change to a different product, even if it is less expensive or better meets your needs.

Because DDS is an Open Standard, you can be confident about selecting CoreDX DDS. We provide world-class support and a commercial-grade software product. The standard Application Programming Interface (API) and an interoperable wire-protocol make CoreDX DDS a sound investment for the long term.

Data Distribution Service (DDS) Architecture Overview

The DDS standard centers around a straightforward architecture of software entities. These components are arranged in a hierarchy, and each serves a unique purpose in the overall Publish-Subscribe infrastructure. A high-level diagram demonstrates the relationship between the DomainParticipant, Publisher, Subscriber, DataWriter, DataReader, and Topic entities.

This diagram demonstrates the logical structure of the major DDS components.

• DomainParticipants belong to a Domain
• DomainParticipants contain Publisher(s) and Subscriber(s)
• Each Publisher can contain any number of DataWriters
• Each Subscriber can contain any number of DataReaders
• DataReaders and DataWriters are logically connected through a Topic
• A Topic has a name and a data type
• DataWriters produce data samples that are of the data type of their associated Topic
• DataReaders consume data samples that match their associated Topic

These simple concepts are extended through the use of Quality of Service settings and the
more complex Topic types. For example, a Topic may be defined that is an aggregate of several
data types (MultiTopic). Also, a ContentFilteredTopic executes a filter on the data samples,
potentially reducing the number of samples that a DataReader has to process.

This discussion barely scratches the surface of the CoreDX DDS capabilites. For more information
please contact us.