Internet of Things Communication Protocol-DDS

summarize

DDS (Data Distribution Service) is a type ofIoT communication protocolsDDS is a middleware protocol and API standard that integrates the components of a system to provide the low-latency data connectivity, high reliability, and scalable architecture required by business and mission-critical Internet of Things (IoT) applications.DDS introduces a virtual global dataspace where applications can share information by simply reading and writing data objects that are addressed by application-defined names (topics) and keys. DDS introduces a virtual global data space where applications can share information by simply reading and writing data objects addressed by application-defined names (Topics) and keys.DDS has fine-grained and extensive control over QoS parameters including reliability, bandwidth, delivery deadlines, and resource constraints.DDS also supports the construction of 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 set up different aspects of the communication (reliability, persistence, redundancy, lifetime, transport settings, resources, etc.), DDS is characterized by the following:

• Publish/subscribe model: simple and decoupled. It allows for a cleaner design of distributed systems.
• Performance: In publish/subscribe model, latency is lower than request/reply model and throughput is higher than request/reply model. In the request/reply model, the requestor should pull remote participants to get the data, but in the publish/subscribe model, the publisher sends the data directly to the subscriber as soon as this data is available.The API, object model, and QoS parameters have been carefully designed for real-time performance, and often the different implementations are truly optimized.
• Automatic discovery of remote participants: This mechanism is one of the main features of DDS. Communication is anonymous and separated, and developers do not have to worry about the localization of remote participants.
• A rich set of Qos parameters allows tuning all aspects of communication: reliability, persistence, redundancy, lifetime, transport settings, resources...
• Interoperability Protocol (RTPS): This protocol can be implemented on virtually any transport, allowing the use of DDS in UDP, TCP, shared memory and user transport, and enabling true interoperability between different DDS implementations

DDS History

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

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:

• A lower data-centric publish-subscribe (DCPS) level designed to effectively deliver the right information to the right recipients.
• Optional Higher Data Local Reconstruction Layer (DLRL), allowing 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), the OMG Working Group develops enterprise integration standards for a range of technologies.

DDS protocol

The DDS factories used to create publishers and subscribers are called DDS participants. Typically, an application creates a participant where publishers publish data and/or subscribers subscribe to data.DDS defines a third level, data write, data reader, and write/read.

Conceptually, DDS sees a local data store called a "global data space". For applications, the global dataspace looks like local memory accessed through the API. You write to what looks like local storage. In fact, DDS sends a message to update the corresponding store on the remote node. You read from what looks like the local store. In a DDS domain, the unit of information sharing is the data object in a topic. The topic is identified by its name and the data object is identified by some "Key" attribute. This is similar to using the key attribute to identify a record in a database. This is a conceptual diagram; DDS communicates on a peer-to-peer basis and does not require a server or cloud to proxy the data.

The discovery of remote DDS participants is automatic, and in the default behavior, each participant sends multicast notifications (or sends unicast notifications to a predefined list of peers), and the DDS maintains a list of remote targets

1. Space: As auto-discovery, the distributed system is independent of the network topology. If a user changes the network topology, no changes need to be made in the application.
2. Time: Publishers can publish completely asynchronously without testing the state of subscribers. If the persistence of the service parameter is set to persistent, the DDS transmits the data to late joiner subscribers.
3. Redundancy: DDS allows for very easy redundancy. Multiple publishers can publish on the same topic, share the topic, or DDS can be set to make the topic exclusive and the owner of the topic will be the publisher with the highest "strength" parameter. If the owner fails, the following stronger publisher will now become the owner. Failover and takeover behavior is possible. For subscribers, any number of subscribers can subscribe to the same topic.
4. Platforms and languages: DDS is implemented in a large number of platforms (Windows, Linux, Solaris, Aix, Mac Os, Integrity, LynxOS, QNX, VxWorks...etc.) and languages (C, C, Java, C#, Ada, etc.). So distributed systems can be very heterogeneous, but developers don't have to worry about the platform/language of the remote node.
5. Implementation: The DDS specification set includes a specification for a DDS interoperability protocol called RTPS (Real Time Publish Subscribe Protocol). Different applications in a distributed system can use different DDS implementations and they will 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, and fetch only a subset of the data published on the topic. Different DDS domains are completely independent of each other; there is no data sharing between DDS domains.

A brief comparison of DDS with other protocols

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

• Message Queue Telemetry Transport (MQTT)The TCP/IP protocol is a proxy-dependent publish/subscribe messaging protocol designed for use with TCP/IP.
• Advanced Message Queuing Protocol (AMQP)It defines an efficient binary peer-to-peer protocol for transmitting messages between two network processes (usually a client and a proxy)
• Constrained Application Protocol (CoAP) is a software protocol designed to support the connection of simple low-power electronic devices (e.g., wireless sensors) to Internet-based systems

bibliography