Simplifying the use of DDS

The specification for DDS provides great capability for applications that want to leverage the distribution of state data in a very customized efficient manner. I say customized here because not only can you specify the unique type of data but you can also specify the behavior of how that data will be delivered, persisted, filtered and stored within the middleware. Actually, the capabilities provided by DDS are not unique to data communications between systems. However, what DDS provides is all of this functionality within the middleware, thus eliminating the need for your applications to provide the same. No coding necessary......to filter data based on satisfying a range specification on one or more of the fields within your data. No coding necessary to provide previously published data to late joining applications. No coding necessary to enable the storage of a historical data publications for live trending analytics to be performed. No coding for these things means application developers can spend their time on more important unique aspects of their application and thus a deliver a better end product with shorter time to market. All of this functionality is enabled and specified through simple code generation and configuration elements known as Quality of Service. As you might guess, this configuration can become difficult to create and manage. If someone is just getting started with understanding DDS, this can become a daunting task to undertake. In order to address this initial view of DDS for developers, there are few things that we have done here at RTI to help with simplifying the use of DDS for some basic applications. Take for example, the process of creating a unique data type, running code generation, setting up a project and including all of the generated files in to the project. For a very simple type, this process seems a little excessive. We have eliminated the need to perform this process for a few simple types. In fact, our latest version of DDS, RTI Connext DDS, includes built-in types for 2 basic types:

• String // Simple ASCII String message
• Octet // Simple byte array message

We also provide keyed versions of these if you want have unique instances of these. The use of these built-in types can be found within our User Manual for DDS and can save a lot of time when creating your applications. Next, we have taken the complexity of having to learn and create Quality of Service profiles for each specific type of data flow in your system and have reduced them down into a set of built-in behavior profiles that can be used directly within your application. These built-in profiles will eliminate the need to of spending hours and hours pouring over our great documentation on each of the various Quality of Service behaviors. Literally this can shorten your time to getting started in creating a DDS publish / subscribe application from several days into an effort that is less than a couple of hours. The great thing about these behavior profiles is that they represent about 75% of the most common use cases we have found projects using out in the field. Here are a few of the built-in profiles:

• Best Effort
• Reliable Keep Last One
• Pattern Streaming
• Pattern Event
• Pattern Status

We have provided some great examples of built-in profiles available for you to download and use up on our Community Portal. You can find the examples here: http://community.rti.com/examples/built-qos-profiles

In addition to these examples, here are some other things up on Community that may be of interest:

• Using QoS Profiles (Examples)
• How can I load a personalized QoS profile in RTI DDS Toolkit for LabVIEW? (Solution)
• Configure Your QoS Through Profiles (Best Practices)

Let us know what you think about these aspects of Simplifying the Use of DDS!

Learn More:

Autonomous Vehicle Production »

Connectivity in Autonomous Systems »

What is DDS? »

Connext DDS Pro »

What is IIoT? »