Connext DDS and the Industrial IoT: The Top 5 Things to Know

**Please note that with the April 2024 release of Connext Professional 7.3 LTS, the functionalities formerly comprising Connext Secure are now available as an optional component to Connext Professional, named Security Extensions. 

The Data Distribution Service (DDS) standard has been a trusted connectivity standard in the Aerospace and Defense market since its launch in 2004, earning credibility in large, mission-critical systems. Today, its high-performance capabilities have caused it to emerge as a standout technology for the Industrial Internet of Things (IIoT). However, while the technology is proven, the IIoT market is still new and thus results in some misconceptions regarding DDS.

I’d like to set the record straight and tell you the top 5 things you need to know about the DDS standard and RTI’s Connext DDS implementation in IIoT.

1. DDS is not the same as the other IoT connectivity solutions

DDS tends to get mixed into the growing number of distributed connectivity solutions for IIoT, such as MQTT, AMQP and CoAP. Each can move data between distributed applications, but in actuality, there are many limitations and requirements that exist in real-time control applications that are not addressed by these solutions. These include: platform resource constraints, small data delivery latency, high throughput reliable delivery to many destinations, dynamic application startup and restarts, no single points of failure and many more.

DDS is the only framework that was designed from the ground up to not only solve these problems, but also provide its capabilities in a data-centric platform. Data-centric solutions have been around for a long time. For example, just take a look at any database application. Those applications are based on the data defined in tables and the interaction of writing data to the database and reading data from the database. In the world of IIoT, however, it’s about the data that is produced and consumed by applications in real time. In other words, it’s about data in motion, not data at rest. This concept then enables DDS to be more than just a framework for building distributed applications, but rather a platform upon which distributed application can grow and evolve through its data and capabilities over time. 

^{Figure 1: DDS works through a data-centric framework for efficient data sharing} 

Data-centricity enables applications to discover and share precise data, providing for efficient filtering based on data ranges or thresholds. Other IIoT protocols require this filtering to be done within the application code. In addition, DDS provides for a rich set of Quality of Service (QoS) behavioral settings, making it ideal for applications that require real-time data delivery with high reliably, even when a reliable transport is not available. Since DDS works in a peer-to-peer fashion, DDS-based systems are inherently massively parallel, with no single point of failure or attack. This makes DDS-based systems extremely well suited for edge-autonomy applications where low latency, high reliability and massive scalability are paramount. 

2. DDS is widely used in critical infrastructure

Fifteen years ago, DDS was quickly adopted by the aerospace and defense industry. During this time, implementations of DDS became fully featured and battle-tested. With the advent of the IIoT, DDS has now taken off in the commercial industrial world, too. Here’s a sampling of the types of applications using DDS:

• Healthcare patient monitoring
• Surgical robots
• Autonomous vehicles
• Hyperloop Transportation
• Wind-power generation systems
• Air traffic control
• Mass transit systems
• Medical imaging
• Space launch systems
• Power-plant energy generation
• Mining operations
• Oil & gas drilling
• Robotics
• Smart-grid power distribution

So, what makes DDS so applicable across all of these types of applications? Well, not only does the data-centricity provide a platform for growth and evolution, but also it provides a rich set of QoS that enables each of these application spaces to address the problems that are unique to their requirements. 

3. Connext DDS is highly secure

Two years ago, the OMG released the DDS Security specification, which provides a framework for securing systems at the data/topic level. It works through a wire-level protocol called RTPS that runs over any transport. The RTI Connext databus is the first connectivity software designed for architecting and securing IIoT systems. For years, applications have secured their systems with physical perimeter security, host platform user level security, or network encryption based security. Now, DDS offers developer the ability for fine-grain security that is unique to each individual data flow, or DDS Topic. This capability offers flexibility of protecting different topics of data while providing authentication, authorization, confidentiality and integrity. This helps to protect discovery information, metadata and data while defending against unauthorized access, tampering and replay.

RTI’s implementation of security completely removes the need to have any source code included in the application related to security. All of the security is configured via external configuration files, thus enabling your software programmers to not have to be security experts and your security experts to not have to be software programmers. In addition, DDS Secure standard is architected to be future proof against unknown security breaches. This is accomplished with the solution relying on two parts: First, a framework that connects the concepts of authentication, access control and encryption to DDS entities such as participants, readers, writers and discovery. 

^{Figure 2: The DDS security framework}

Then, through the use of a plugin architecture, the functions of authentication, access control, encryption/decryption, data tagging and logging can be provided with the latest and greatest solutions. Please see this link for more information on DDS Secure. 

4. Connext DDS is sophisticated and supports many IoT communication patterns

There is a rich set of functionality to develop a new system through Connext DDS. Developers may look at its QoS policies and get overwhelmed. There are approximately 23 high level QoS policies, each of which can have a number of individual settings. Yet one particular use case, such as alarm/event data or streaming video data, would only use a few of these QoS policies. RTI simplifies development through the ability to break down the behavioral requirements of each application or use case and then applying the correct QoS policies to achieve the desired behavior. 

Every application is unique and uses a subset of the QoS policies, typically 5-6 per application. As the market leader of DDS, RTI’s Connext DDS also provides many other QoS capabilities that enhance its ability to solve their individual problems. For example, take this block of distributed application problems that exist:

^{Figure 3: Common Distributed System problems} 

RTI’s Connext DDS provides QoS behaviors that address each of these issues: 

^{Figure 4: Connext DDS QoS Policies} 

While most of these are defined in the DDS standard, there are a few of these, such as Batching, Transports, Multi-Channel and Flow Control, that are unique to RTI Connext DDS.

There are publicly-available resources and examples available for use cases, such as RTI’s Case + Code examples, so developers can simply apply minor changes to different parameters, and achieve the desired operation based on the deployed environment. For more information, please visit the Getting Started page.

5. Connext DDS applications are evolvable

Connext DDS is future-proof through its data centricity design. To illustrate how it works for integration with past - and future - designs, let’s look at how a system evolves over time. The standard workflow within Connext DDS is to define the data topics that will be used to communicate between applications. These topics are strongly typed to provide several key attributes, such as application communication integrity, bandwidth usage efficiency, data availability discovery, and filtering efficiency. However, by strongly defining your data type for a given topic, these definitions become static in nature. In order to evolve their datatype in future releases, the OMG added a standard called Extensible and Dynamic Topic Types (X-Types) for DDS. This standard not only enables a developer to add/change/delete individual data fields within a datatype, it also provides a mechanism to define some fields as optional fields that don’t require inclusion with each data publication. Connext DDS supports Type Extensibility to interoperate older applications with newer ones that use the updated data type.

As interest has grown in DDS, so too have questions, myths and confusion. I invite you to contact me to get the real facts about Connext DDS and how it can help you solve your real-time communications problems. Contact me or visit www.rti.com for more information.