The Defense and Aerospace Industry Should not Ignore Recent Trends in Protocols

By Angelo Corsaro, PhD, CEO/CTO, ZettaScale Technology

The OMG Data Distribution Service (DDS) has been successfully adopted and deployed in various defense and aerospace applications ranging from Naval Combat Management Sys-tems to Air Traffic Control and Management.  The standard has been around for 20 years, providing this domain with good service and, more importantly, a way to break vertically in-tegrated proprietary systems.

Today’s Challenges

As the defense and aerospace sector moves toward more interconnected and cooperating systems and increasingly requires data to be managed from the microcontroller up to the data center, DDS-based systems or systems that intend to adopt DDS will face a series of challenges.

DDS was designed to address closed sys-tems running in a relatively well-controlled environment.  In other terms, its sweet spot is reliable wired networks and small-scale to medium-scale systems.  Its discovery model limits the applicability of DDS in wireless en-vironments and to larger-scale systems.  This problem is well documented in the robotics community, where it has become a relatively severe issue.  Consequently, the ROS commu-nity has been actively looking for alternative technologies to be adopted as a communica-tion layer.  Vendors have played various con-tortionists to mitigate the issue, but there is an inherent tension between maintaining the DDS semantics, scaling, and remaining stan-dards.  In other words, scaling requires either breaking the semantics, the standard, or both. 

The question now is: why use DDS?  Especial-ly considering that it also comes with a rather steep learning curve for both programmers as well as a  complex deployment tuning.

Another important point to consider is that any DDS system not using DDS Security is ex-posing itself to a series of attacks that are of-ten too easy to initiate.  Attacks such as play-ing with heartbeats or injecting intentionally wrong discovery information. 

Finally, DDS does not easily scale down to constrained environments.  The OMG DDS-XRCE standard is not “DDS” in the sense that it is a client-server protocol that bridges con-strained devices with a DDS domain.  This is a single point of failure and potentially intro-duces additional latency in the distribution path.

Trends in Protocols

DDS was developed at a time when there used to be a more or less clear separation be-tween protocols designed to distribute data–of which Publish/Subscribe protocols like DDS MQTT are an example–and protocols used for Remote Procedure Call, such as RPC, COR-BA, Java RMI, etc., not to mention Databases, which have always lived in their little corner as such, in a distributed system, the data plane would usually be implemented with a Pub/Sub technology, the control plane with an RPC, and the management layer by a combination of the two technologies.  DBMS were everywhere.

In recent years, there has been a trend to-ward unifying the Pub/Sub and the RPC, but the data at rest has always remained a separate world, or at least until recently.  The Eclipse Zenoh Project introduced a new in-novative protocol that unifies data in motion, data at rest, and computations into a protocol that can span from the tiniest microcontroller to the data center. 

The robotics and automotive industry, which had adopted DDS as a consequence of some of the similarities in use cases with defense and aerospace, are now looking with attention at Zenoh. Innovators have been adopting and deploying Zenoh-based solutions for almost two years.  The mainstream industry has rec-ognized its relevance to the point that Zenoh was recently included as a critical project as part of the Eclipse Software Defined Vehicle Working Group. 

On the robotics front, the Open Robotics Software Foundation and Intrinsics recent-ly released a report highlighting how, among most existing protocols, including DDS,  the one that best addresses the communication re-quirements of robotics applications is Zenoh.  As a consequence of this report, the decision was made to implement native support for Ze-noh in the ROS 2 framework.  This is significant as ROS / ROS 2 is globally the most widely used robotics framework.  Its uses span across verti-cals and include aerospace and defense.

The Way Forward

Following the example of the robotics indus-try, defense and aerospace applications should start leveraging the Zenoh protocol today by leveraging its DDS plugin.  This plugin allows DDS applications to communicate transpar-ently through Zenoh.  It is heavily used in the ROS 2 community where DDS communication is constrained to the individual robot, and Ze-noh is used for communicating between ro-bots and across the internet. 

A high-profile example of its use can be found in the Indy Autonomous Challenge.  Zenoh was providential in enabling commu-nications between the autonomous cars and the infrastructure through a CISCO CURB wireless network.  This plugin allows DDS applications to transparently “talk Zenoh” and provides interoperability between native Ze-noh applications and native DDS applications.  Consequently, new applications or functional updates/upgrades to DDS-based systems can leverage Zenoh for performance, scalability, productivity, and reach.  An increasing num-ber of green-field systems in defense and aero-space choose Zenoh as the communication protocol.  This should be the way forward.

About the Author

Angelo Corsaro, Ph., is the Chief Executive Officer (CEO) and Chief Technology Officer (CTO) at ZettaScale Technology.  At ZettaScale, he is working with a world-class team to change the landscape of distributed computing — working hard to bring to every connected human and machine the unconstrained freedom to communicate, compute, and store — anywhere, at any scale, efficiently and securely.