Internet of Things Communication Protocol – DDS

Overview

DDS (Data Distribution Service) is an IoT communication protocol, belonging to middleware protocols and API standards. It integrates system components, providing low-latency data connectivity, extremely high reliability, and a scalable architecture required for business and mission-critical IoT applications. DDS introduces a virtual global data space. Applications can share information by simply reading from and writing to data objects addressed by application-defined names (Topics) and keys. DDS offers fine-grained and extensive control over QoS parameters, including reliability, bandwidth, delivery deadlines, and resource limits. DDS also supports building local object models on top of the global data space.

Distributed applications using DDS can publish or subscribe to "Topic" information and use a rich set of Quality of Service parameters to configure various aspects of communication (reliability, durability, redundancy, lifespan, transport settings, resources, etc.). The characteristics of DDS include the following:

• Publish/Subscribe Model: Simple and decoupled. It allows for cleaner design of distributed systems.
• Performance: In the publish/subscribe model, latency is lower and throughput is higher compared to the request/reply model. In the request/reply model, the requester must pull data from remote participants, whereas in the publish/subscribe model, the publisher sends data directly to subscribers as soon as it becomes available. The API, object model, and QoS parameters are all meticulously designed for real-time performance, and different implementations are typically highly optimized.
• Automatic Discovery of Remote Participants: This mechanism is one of DDS's key features. Communication is anonymous and decoupled; developers do not need to worry about locating remote participants.
• Rich Set of QoS Parameters allowing fine-tuning of various communication aspects: reliability, durability, redundancy, lifespan, transport settings, resources...
• Interoperability Protocol (RTPS): This protocol can be implemented over virtually any transport, allowing DDS to be used over UDP, TCP, shared memory, and user-defined transports, and enabling true interoperability between different DDS implementations.

History of DDS

The development of the DDS specification began in 2001, led by Real-Time Innovations (RTI) and the French defense company Thales Group. In 2004, the Object Management Group (OMG) released DDS version 1.0, followed by version 1.1 in December 2005, version 1.2 in January 2007, and version 1.4 in April 2015.

Version 2.0 was released in April 2008, version 2.1 in November 2010, version 2.2 in September 2014, and version 2.3 in May 2019. The DDS specification describes two levels of interfaces:

• The lower Data-Centric Publish-Subscribe (DCPS) level, designed to efficiently deliver appropriate information to the appropriate recipients.
• The optional higher Data Local Reconstruction Layer (DLRL), which allows for simple integration of DDS into the application layer.

The Object Management Group (OMG) is a computer industry standards consortium,

founded in 1989 by 11 companies (including Hewlett-Packard, IBM, Sun Microsystems, Apple Computer, American Airlines, iGrafx, and Data General). OMG working groups develop enterprise integration standards for a range of technologies.

DDS Protocol

The DDS factory used to create publishers and subscribers is called a DDS Participant. Typically, an application creates a participant, publishers publish data, and/or subscribers subscribe to data. DDS defines a third level: DataWriter, DataReader, and the act of writing/reading.

Conceptually, DDS envisions a local data store called the "Global Data Space." For the application, the global data space appears as local memory accessed via an API. You write to what seems like local storage. In reality, DDS sends messages to update the corresponding storage on remote nodes. You read from what seems like local storage. Within a DDS domain, the unit of information sharing is a data object within a Topic. The Topic is identified by its name, and the data object is identified by certain "Key" attributes. This is similar to using key attributes to identify records in a database. This is the conceptual diagram. DDS communicates in a peer-to-peer manner and does not require a server or cloud broker for data.

Discovery of remote DDS participants is automatic. In the default behavior, each participant sends multicast announcements (or unicast announcements to a predefined list of peers). DDS maintains a list of remote targets.

1. Space: Due to automatic discovery, the distributed system is independent of network topology. If the network topology changes, no modifications are required in the application.
2. Time: Publishers can publish completely asynchronously without checking the status of subscribers. If the durability QoS parameter is set to persistent, DDS will transfer data to late-joining subscribers.
3. Redundancy: DDS allows for very easy implementation of redundancy. Multiple publishers can publish on the same topic, sharing it, or DDS can be configured to set the topic as exclusive, where the owner of the topic is the publisher with the highest "strength" parameter. If the owner fails, the next strongest publisher becomes the owner. This enables failover and takeover behavior. For subscribers, any number of subscribers can subscribe to the same topic.
4. Platform and Language: DDS is implemented on a wide range of platforms (Windows, Linux, Solaris, AIX, Mac OS, Integrity, LynxOS, QNX, VxWorks, etc.) and languages (C, C++, Java, C#, Ada, etc.). Therefore, a distributed system can be very heterogeneous, but developers do not need to worry about the platform/language of remote nodes.
5. Implementation: The DDS specification set includes a specification for the DDS interoperability protocol, called RTPS (Real-Time Publish-Subscribe Protocol). Different applications within a distributed system can use different DDS implementations and still interoperate.

DDS provides QoS-controlled data sharing. Applications communicate by publishing and subscribing to topics identified by their topic names. Subscriptions can specify time and content filters, receiving only a subset of the data published on a topic. Different DDS domains are completely independent of each other. There is no data sharing between DDS domains.

Brief Comparison of DDS with Other Protocols

IoT applications often consider several specialized messaging/data sharing protocols, including:

• Message Queuing Telemetry Transport (MQTT), a broker-dependent publish/subscribe messaging protocol designed for use with TCP/IP.
• Advanced Message Queuing Protocol (AMQP), which defines an efficient binary peer-to-peer protocol for transferring messages between two network processes, typically a client and a broker.
• Constrained Application Protocol (CoAP), a software protocol intended for use in simple, low-power electronic devices (such as wireless sensors) to connect to internet-based systems.

References