Data Distribution Service
![]() | This article contains promotional content. (July 2020) |
This article may rely excessively on sources too closely associated with the subject, potentially preventing the article from being verifiable and neutral. (July 2014) |
The Data Distribution Service (DDS) for real-time systems is an Object Management Group (OMG) machine-to-machine (sometimes called middleware or connectivity framework) standard that aims to enable dependable, high-performance, interoperable, real-time, scalable data exchanges using a publish–subscribe pattern.
DDS addresses the needs of applications like aerospace and defense, air-traffic control, autonomous vehicles, medical devices, robotics, power generation, simulation and testing, smart grid management, transportation systems, and other applications that require real-time data exchange.
Architecture
Model
DDS is a networking middleware that simplifies complex network programming. It implements a publish–subscribe pattern for sending and receiving data, events, and commands among the nodes. Nodes that produce information (publishers) create "topics" (e.g., temperature, location, pressure) and publish "samples". DDS delivers the samples to subscribers that declare an interest in that topic.
DDS handles transfer chores: message addressing, data marshalling and de-marshalling (so subscribers can be on different platforms from the publisher), delivery, flow control, retries, etc. Any node can be a publisher, subscriber, or both simultaneously.
The DDS publish-subscribe model virtually eliminates complex network programming for distributed applications. [citation needed]
DDS supports mechanisms that go beyond the basic publish-subscribe model. [citation needed] The key benefit is that applications that use DDS for their communications are decoupled. Little design time needs be spent on handling their mutual interactions. In particular, the applications never need information about the other participating applications, including their existence or locations. DDS transparently handles message delivery without requiring intervention from the user applications, including:
- determining who should receive the messages
- where recipients are located
- what happens if messages cannot be delivered
DDS allows the user to specify quality of service (QoS) parameters to configure discovery and behavior mechanisms up-front. By exchanging messages anonymously, DDS simplifies distributed applications and encourages modular, well-structured programs. [citation needed] DDS also automatically handles hot-swapping redundant publishers if the primary fails. [citation needed] Subscribers always get the sample with the highest priority whose data is still valid (that is, whose publisher-specified validity period has not expired). It automatically switches back to the primary when it recovers, too.
Interoperability
Both proprietary and open-source software implementations of DDS are available. These include application programming interfaces (APIs) and libraries of implementations in Ada, C, C++, C#, Java, Python, Scala, Lua, Pharo and Ruby.
DDS vendors participated in interoperability demonstrations at the OMG Spring technical meetings from 2009 to 2013.[1][2][3][4][5][6]
During demos, each vendor published and subscribed to each other's topics using a test suite called the shapes demo. For example, one vendor publishes information about a shape and the other vendors can subscribe to the topic and display the results on their own shapes display. Each vendor takes turns publishing the information and the other subscribe. Two things made the demos possible: the DDS-I or Real-Time Publish-Subscribe (RTPS) protocol,[7] and the agreement to use a common model.

In March 2009, three vendors demonstrated interoperability between the individual, independent products that implemented the OMG Real-time Publish-Subscribe protocol version 2.1 from January 2009. The demonstration included the discovery of each other's publishers and subscribers on different OS Platforms (Microsoft Windows and Linux) and supported multicast and unicast network communications.[1]
The DDS interoperability demonstration used scenarios such as:
- Basic connectivity to network using Internet Protocol (IP)
- Discovery of publishers and subscribers
- Quality of service (QoS) Compatibility between requester and offerer
- Delay-tolerant networking
- Multiple topics and instances of topics
- Exclusive ownerships of topics
- Content filtering of topic data including time and geographic
History
Development of the DDS specification started in 2001. It was developed by Real-Time Innovations (RTI), a software framework company, and Thales Group, a French defense company. In 2004, the Object Management Group (OMG) published DDS version 1.0.[8] Version 1.1 was published in December 2005,[9] 1.2 in January 2007,[10] and 1.4 in April 2015.[11] DDS is covered by several US patents,[12][13][14][15] among others.
The DDS specification describes two levels of interfaces:
- A lower data-centric publish-subscribe (DCPS) level that is targeted towards the efficient delivery of the proper information to the proper recipients.
- An optional higher data local reconstruction layer (DLRL), which allows for a simple integration of DDS into the application layer.
Other related standards followed the initial core document. The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification ensured that information published on a topic using one vendor's DDS implementation is consumable by one or more subscribers using the same or different vendor's DDS implementations. Although the specification is targeted at the DDS community, its use is not limited. Versions 2.0 was published in April 2008, version 2.1 in November 2010, 2.2 in September 2014, and 2.3 in May 2019.[7]
DDS for Lightweight CCM (dds4ccm) offers an architectural pattern that separates the business logic from the non-functional properties. A 2012 extension added support for streams.[16] A Java 5 Language PSM for DDS defined a Java 5 language binding, referred to as a Platform Specific Model (PSM) for DDS. It specified only the Data-Centric Publish-Subscribe (DCPS) portion of the DDS specification; Additionally, it encompasses the DDS APIs introduced by DDS-XTypes and DDS-CCM. DDS-PSM-Cxx defines the ISO/IEC C++[17] PSM language binding, referred to as a Platform Specific Model (PSM) for DDS. It provides a new C++ API for programming DDS that is more natural to a C++ programmer.[18] The specification provides mappings for the application programming interface (API) specified in DDS-XTypes, and accessing quality of service (QoS) profiles specified in DDS-CCM.
Extensible and Dynamic Topic Types for DDS (DDS-XTypes) provided support for data-centric publish-subscribe communication where topics are defined with specific data structures. To be extensible, DDS topics use data types defined before compile time and used throughout the DDS global data space. This model is desirable when static type checking is useful.[19] A Unified Modeling Language (UML) profile specified DDS domains and topics to be part of analysis and design modeling.[20] This specification also defined how to publish and subscribe objects without first describing the types in another language, such as XML or OMG IDL.[21] An interface definition language (IDL) was specified in 2014 independently from the Common Object Request Broker Architecture (CORBA) specification chapter 3. This IDL 3.5 was compatible with the CORBA 3 specification, but extracted as its own specification allowing it to evolve independently from CORBA.[22]
Other protocols to be mentioned are: DDS-XRCE (DDS for eXtremely Resource Constrained Environments), this specification protocol allows the communication between devices of limited resources, like microcontroller for example and a DDS network. It makes publishing and subscribing to topics via an intermediate service in a DDS domain possible [23] and DDS-RPC (RPC Over DDS) which defines Remote Procedure Calls. These provide a bidirectional request/reply communication and determine distributed services, and are detailed using a service interface. It also supports both synchronous and asynchronous method invocation. [24]
Starting with DDS version 1.4 in 2015, the optional DLRL layer was moved to a separate specification.[25]
What are the different types of Data Distribution Services?
There are three types of Data Distribution Services:
1. Point-to-Point: A point-to-point Data Distribution Service is a direct connection between two devices. This type of service is typically used for small data transfers or for devices that are in close proximity to each other.
2. Multicast: A multicast Data Distribution Service sends data to a group of devices simultaneously. This type of service is often used for streaming video or audio content to multiple devices at the same time.
3. Broadcast: A broadcast Data Distribution Service sends data to all devices on a network simultaneously. This type of service is typically used for distributing systemwide announcements or updates to all devices on a network.
What are the benefits of using a Data Distribution Service?
A Data Distribution Service (DDS) is a service that enables the distribution of data between different devices or locations. It can be used to distribute data between different devices on a network, or between different locations (e.g. between offices).
A Data Distribution Service can provide many benefits, including:
-Improved performance: By distributing data across multiple devices or locations, a Data Distribution Service can help to improve the overall performance of a system. This is because it can reduce the amount of traffic on a single device or connection, and spread the load across multiple devices or connections.
-Increased reliability: A Data Distribution Service can also help to increase the overall reliability of a system. This is because if one device or connection fails, the others can continue to operate.
-Greater flexibility: A Data Distribution Service can also provide greater flexibility when it comes to distributing data. For example, it can allow data to be distributed in real-time, or on a schedule that suits the needs of the system.
How to choose a Data Distribution Service Provider
1. How to choose a Data Distribution Service Provider
When it comes to choosing a data distribution service provider (DDS), there are many factors to consider. Here are a few key factors to help you choose the right DDS for your business:
1. Services offered - When considering a DDS, be sure to inquire about the range of services they offer. Some DDS providers may only offer basic data distribution, while others may offer more comprehensive services such as data warehousing, data mining, and analytics. Choose a provider that offers the level of service that best meets your needs.
2. Scalability - Make sure the DDS you choose can scale to meet your future needs. As your business grows, you'll likely need to increase the amount of data you distribute. Choose a provider that can easily scale up their services to accommodate your future growth.
3. Reliability - Data distribution is critical for many businesses, so reliability is an important factor to consider when choosing a DDS. Be sure to ask potential providers about their uptime guarantee and what steps they take to ensure reliable data distribution.
4. Pricing - Price is always an important consideration when choosing any type of service provider. Be sure to get quotes from several different providers before making your final decision. Read This Data Distribution Service Review Before Choose the right one for you.
See also
- Middleware
- Open architecture computing environment
- Object Management Group (OMG), standards body that developed the specification
References
- ^ a b Angelo Corsaro, Gerardo Pardo-Castellote and Clark Tucker (August 12, 2009). "DDS Interoperability Demo" (PDF). Object Management Group. Archived from the original (PDF) on September 15, 2011. Retrieved November 9, 2016.
- ^ "DDS Interoperability Demo December 2010" (PDF). Real-Time Innovations, Inc. December 11, 2010. Retrieved November 9, 2016.
- ^ 2011, March 2011, https://community.rti.com/content/presentation/omg-dds-interoperability-demo-2011
- ^ 2012, March 2012, https://community.rti.com/content/presentation/omg-dds-interoperability-demo-2012
- ^ 2013, March 2013, http://www.slideshare.net/GerardoPardo/dds-interoperability-demo-2013-washington-dc
- ^ "DDS Interoperability Demonstration". video. Real-Time Innovations. December 14, 2010. Archived from the original on 2014-01-07. Retrieved November 9, 2016.
- ^ a b "The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification (DDSI-RTPS)". May 2019. Retrieved October 28, 2019.
- ^ "Data Distribution Service (DDS), Version 1.0". Object Management Group. December 2, 2004. Retrieved November 9, 2016.
- ^ "Data Distribution Service (DDS), Version 1.1". December 4, 2005. Retrieved November 9, 2016.
- ^ "Data Distribution Service (DDS), Version 1.2". January 1, 2007. Retrieved November 9, 2016.
- ^ "Data Distribution Service (DDS), Version 1.4". April 10, 2015. Retrieved November 9, 2016.
- ^ US Patent US8874686
- ^ US Patent US8671135
- ^ US Patent US8150988
- ^ US Patent US9015672
- ^ DDS for Lightweight CCM (dds4ccm), Version 1.1, formal/2012-02-01, February 2012, http://www.omg.org/spec/dds4ccm/1.1/PDF/
- ^ Programming languages — C++, 15 October 2003, ISO/IEC 14882, http://www.iso.org/iso/catalogue_detail.htm?csnumber=38110
- ^ DDS-PSM-Cxx: ISO/IEC C++ 2003 Language DDS PSM, Version ptc/2011-01-02, January 2011, http://www.omg.org/spec/DDS-PSM-Cxx/1.0/Beta1/PDF
- ^ Extensible and Dynamic Topic Types for DDS (DDS-XTypes), 1.0, formal/2012-11-10, November 2012, http://www.omg.org/spec/DDS-XTypes/1.0/PDF
- ^ UML Profile for Data Distribution, version: 1.0, http://www.omg.org/cgi-bin/doc?ptc/10-05-17.pdf
- ^ DDS-Java: Java 5 Language PSM for DDSVersion 1.0, ptc/2012-12-01, March 2013 http://www.omg.org/spec/DDS-Java/1.0/Beta3/PDF
- ^ "Interface Definition Language (IDL), Version 3.5". OMG. March 1, 2014. Archived from the original on January 21, 2017. Retrieved November 9, 2016.
- ^ "About the DDS For Extremely Resource Constrained Environments Specification Version 1.0". www.omg.org. Retrieved 2021-03-12.
- ^ "About the RPC Over DDS Specification Version 1.0". www.omg.org. Retrieved 2021-03-12.
- ^ "DDS Data Local Reconstruction Layer (DDS-DLRL)". April 2015. Retrieved November 9, 2016.