Twin Oaks Feature

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.

CoreDX DDS Architecture

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.