Comparing Open Source DDS to RTI Connext DDS: Considerations in Picking the Right DDS Solution to Run Your Distributed System

In 2018, I posted a blog titled “When is Open Source the Right Solution?” This question is still relevant, but as everyone knows, a lot can change in two years. Since then, RTI Connext^® DDS has gained many new features, as have open source versions of DDS. I thought it would be a good idea to update that blog with more recent information for 2020 and share it with you here. 

Why Open Source is Not the Same as Open Standard

The Object Management Group^® (OMG^®) Data Distribution Service™ (DDS) standard is what is called an "open standard." This means that the standard is publicly available and provides a normative reference to help guarantee consistency, portability and interoperability, regardless of the DDS vendor. An open standard is not the same thing as software that is open source. Open source software is computer software made available with its source code. Open source software may be shared, modified and distributed, usually under an open source license. The DDS standard is an open standard and has open source implementations available. There are many commercial distributions that are available as well, of which the most widely-used is RTI Connext DDS.

So, what should you consider when deciding between an open source DDS solution compared to a commercial solution?

It All Comes Down to Features

When deciding between open source DDS and commercial DDS software, it's important to determine the DDS features that you need, then compare them to the features available with the DDS release you want to use. If you aren't certain of what you will need as your project evolves, you should consider software that supports the complete DDS API.

For example, here are some of the standard OMG DDS capabilities that RTI Connext DDS supports that are not commonly found in open source distributions:

• Language support - Connext DDS supports traditional C++, C++03, C++11, Java, Ada, C# and .Net.
• Presentation Quality of Service (QoS) - The ability to control the order in which samples arrive at the subscriber.
• Extensible data types definition - Defines data types in a more flexible way, with the ability to evolve over time without giving up portability, interoperability or the expressiveness of the DDS type system. This is known as extensible types (DDS-XTYPES).
• Request/reply functionality - This is part of the DDS-RPC OMG standard and provides users with an additional messaging paradigm to fit their use case.
• XML Application Language specification support - This provides users with QoS configuration through XML files. This capability complies with the DDS-XML standard.
• Coherent data across multiple Topics - This is implemented with coherent sets with presentation access scope.
• Content Filtered Topics - This gives users the ability to select the data of interest based on the content, not just the Topic name.
• Connext DDS supports UDP, TCP and Shared Memory (including Zero Copy Shared Memory) transports - Other distributions only support a UDP transport.
• Standard Services and Gateways - Includes Persistence Service, DDS-WEB Gateway, DDS-OPCUA Gateway and DDS-XRCE Gateway.
• RTI Web Integration Service – Allows integration of web-based applications and services with RTI Connext DDS.
• RTI Persistence Service – Enables the ability to store data permanently and make it available to applications whenever they join the system.

In addition, here are some of the enhanced (non-standard) capabilities that RTI Connext DDS supports, which are also not commonly found in open source distributions. These capabilities include:

• Writer-Side content filtering to implement the DDS Content filters in the writer side, which enhances scalability and greatly reduces network traffic and CPU utilization.
• Custom content filters, which allow users to “plugin” dedicated filters that take advantage of their specific application data types.
• Guarantee delivery features, such as "application-level" acknowledgments, virtual GUIDs (to support redundant routing services), durable subscriptions, durable writer history and collaborative datawriters.
• Aggregate smaller data-updates into a single one for greater throughput (batching).
• Query historical data from your Topics (Topic Query).
• Dynamically add, remove and change IP connections (IP Mobility).
• Supporting high-speed Flat Data communications.
• Domain Tags that allow the users to define “virtual domains,” so that an unlimited number of DDS domains can co-exist in the same network without interference.

Generally speaking, commercial DDS implementations are more full-featured and more robust than open source versions. This is because they have a larger number of engineers dedicated full-time to development and testing. For instance, Connext DDS Professional has over 50 engineers working full-time on development, in addition to 25 full-time support engineers, plus services and training engineers.

Application Components and Services

When considering which software is best for you, it's important to determine overall interoperability between your system and other data types. Do you need to interface with web pages? Do you want to integrate with a relational database? Some of these key services are not generally available with open source DDS. But Connext DDS does offer these capabilities and more by providing the following Application Components and Services:

• RTI Routing Service - Forward and transform data between networks.
• RTI Recording Service – Record data at high speeds and replay to a live or simulated system.
• RTI Database Integration Service – Store DDS data into relational databases and monitor database changes from anywhere using DDS.
• DDS Connectors scripting language interface - Provides Connext DDS interfaces with Python, Javascript and Lua scripting languages.
• RTI System Designer – Graphically design and configure Connext DDS systems.
• RTI Prototyper – Prototype, exercise and test a DDS system.
• RTI Cloud Discovery Service – Discovery service allowing deployment of DDS applications in the cloud.
  
  

DDS Implementation Tools

You will also want to determine what development tools are available for the DDS implementation you are considering. Quite often, DDS is used in large inter-connected systems that can be quite complex. Having the right tools available to debug these systems is crucial, which is why Connext DDS includes the following DDS implementation tools:

• Admin Console – View running DDS applications and visualize the data, as well as see the participants, topics, writers, and readers including QoS settings and data-types. Connection problems are automatically identified.
• Monitor – Get detailed information on DDS entities, traffic and internal state.
• rtiddsspy (Command Line Utility) - View what is being published and what is being subscribed.
• Excel Spreadsheet Add-in – Read and write DDS from Microsoft Excel.
• Heap Analysis Tool – Take snapshots of DDS heap usage and quickly identify any memory leaks.
  
  

DDS Security

Security is a concern in every connected system today. You need to ensure that the DDS software you choose supports the DDS Security standard and also has TLS or DTLS transports readily available. Since 2015, RTI Connext DDS has supported the DDS-Security standard. Connext DDS also has a secure WAN transport that includes TLS and DTLS support. You can read more about RTI Connext DDS Secure here.

Certification

Does your application need some form of certification? It is time consuming and expensive to certify software, and the more code there is, the harder it is to do. RTI Connext DDS Cert provides complete certification evidence for your system. It supports a subset of the DDS standard API and has been certified to DO178C level A certification. You can read more about Connext DDS Cert here.

Robustness

Probably the most important factor in determining whether open source DDS is a good fit is the robustness of the implementation. Arguably, the best way for software to prove itself is in actual customer applications. A good measurement is to assess how many commercial deployments are running the version of DDS software that you are considering. When an implementation has been successfully implemented over and over again, you know that it can do the job. Connext DDS has been field-tested, proven and used in more than 1,500 different projects and in over 1 million devices to date. Some of the complex, mission-critical applications that currently rely on Connext DDS include:

• NASA KSC Launch Control – 300K points, at 400k msgs/sec
• Raytheon Zumwalt destroyer – 1,500 DDS applications, 10m publishable pairs
• Shanghai PVG airport ground control - Used across Southeast China Regional Airports since 2015
• 550' U.S. concrete gravity dam - 24x7 operation, 300K data values

Another consideration is how well the software is tested. What is the quality of the DDS release that you are entrusting your product lifecycle to? RTI testing includes extensive automated testing and rigorous training and reviews, as well as extensive issue tracking and management. In addition, the RTI IIoT Testing Lab is the industry’s largest, most complete lab facility, featuring:

• 240-core scale test; runs 1,000s of concurrent programs, 10k endpoints
• 32 fast Xeon CPU array
• 128-board Micro test array
• Almost 100 different types of computers
  
  

Platform Support

There are a number of vital considerations to take into account for platform support. For example: What is the target architecture, operating system and compiler you are going to use? Does the DDS implementation you are considering support the language(s) you want to use? Also, how often and how quickly do new architectures and OS versions get supported? It’s important to ensure the platform you want to use is supported. If it is not supported, what services are available to create that platform and support it?

If support for a certain platform is not available, open source DDS can be rebuilt to provide the support needed. Open source DDS comes with source code and instructions on how to rebuild the source.

For a faster go-to-market cycle, Connext DDS supports the largest number of platforms in the industry without the need for custom code. Connext DDS also allows customers to build their own libraries, which are primarily used for testing purposes. Whenever you are building your own DDS libraries, it is not always straightforward, and you have to consider what testing has already been done.

Cost

Some open source DDS implementations are available as a free download. In the short term, they cost less than a commercial DDS implementation.

Over time, however, the cost of using open source DDS may increase if you need access to support or specific features. Open source DDS is supported by an open source community, which eliminates any license fees or support fees. However, you must either rely on community support or pay another company for support. As a result, your open source DDS could cost more in the long run, due to missing features that you will need to build, plus additional developer resources, increased development time and additional support costs.

How important is fast, reliable support? It’s a valid comparison to weigh the cost of a commercial DDS license versus the loaded cost of an engineer per year, and to determine your upfront costs vs. costs over the lifetime of the project.

Time to Market

In choosing your DDS software, you need to consider how quickly you can get your system to market with each of the DDS options. If the DDS implementation you want to use does not have the capabilities, support or services you need, or just does not work as expected, can you afford the extra months to get it operational? How would delays affect your ability to deliver on time? In other words, just how important is getting your product out on time?

DDS Support

It is critical to understand what support is available through your DDS vendor in case you run into problems. Open source DDS provides support through online user groups, as well as through third parties for a fee. If you plan on hiring a third-party for support, you need to determine if the support engineers are dedicated to just one implementation or if they support several different products. What is their escalation policy if you run into critical problems?

RTI understands that connectivity software is a mission-critical part of your application, and we treat customer support with the seriousness that it deserves. Our support engineers are exceptionally qualified: They are experts at designing, debugging and implementing distributed real-time and embedded systems. With support centers in the U.S. and Europe, RTI’s DDS support engineers can be reached almost 24/7. In addition, Connext DDS support engineers are co-located with, and have direct access to, development engineering resources should a critical issue arise.

RTI also provides a rich online library for Connext DDS features and tools, as well as a rich list of online resources such as the Connext DDS community, instructional videos, case & code examples, online training and documentation.

Conclusion

Choosing DDS to build and run your distributed system, may be a relatively easy decision. Evaluating and choosing the right DDS solution - open source or commercial software - will depend on your specific requirements. To determine the best option for your project, we invite you to answer the following questions:

• Is the language that you want to use supported?
• Is integration with scripting languages required?
• Do you need integration with the cloud? Or with a relational database?
• Will you need security in the future? Or certification?
• Is the release robust? Does it go through rigorous testing? Has it been successfully used numerous times in fielded applications?
• Is there sufficient support, and a path for escalating problems if they arise?

If you answered with an emphatic “yes” to any of these questions, you are likely working on a complex product with time-to-market objectives that need to be rock solid, well-supported and future-proof. To discuss your unique requirements for your DDS project, please contact your RTI representative.

About the Author

David Seltz is a Field Application Engineer for Real-Time Innovations supporting customers in the New England area.  David has been in the embedded industry for over 32 years working in engineering and sales roles.  Previous to his work at RTI, David was the world-wide FAE manager for Wind River Systems. David holds a Bachelor of Science degree in computer engineering from Lehigh University, and a Master of Science degree in computer engineering from the University of Massachusetts.