Tools & Software Next-generation autonomous system design made easier with DDS
The future of autonomy is based on software that is increasingly based on the DDS standard. This standard is not only used for current applications but also solves the future challenges of autonomous and networked transport.
For industrial applications that require real-time performance, tight interaction between applications and their development teams, and safety-critical reliability, the DDS standard offers advanced connectivity capabilities. It is managed by the Object Management Group (OMG) and is based on a technology called a data bus. DDS (Data Distribution Service) provides all the benefits of a service bus for IT organizations to share data, including communications and network abstraction. Designed specifically for embedded and distributed industrial systems, however, it has proven itself in many complex real-time environments, including unmanned aerial vehicles, surgical robotics, distributed energy resources, and air traffic control. Today, DDS is also used in over 40 different commercial autonomous vehicle development programs that sometimes use DDS as their native framework.
Handling large amounts of data
Essential innovations are necessary for a networked and autonomous future of transport. In highly autonomous vehicles, for example, immense amounts of data are transferred between applications that must be able to recognize their environment in real-time and react accordingly. Functional safety and security are particularly important here.
However, today's designs for autonomous vehicles do not yet meet all these requirements at the same time. Therefore, investments in new technologies are required to meet the functional requirements of autonomous vehicles while maintaining the high standard of non-functional requirements. Of all the technologies integrated into an autonomous vehicle, the software enables decisive progress.
The software is one of the most important competitive advantages for autonomous vehicles due to various disruptive factors in the market such as disruptive technology, innovative start-ups, and new business models. All current innovations such as ride-sharing, autonomous vehicles, electric vehicles, and networked cars are mainly based on advanced software. To design systems for the future, automakers are now beginning to separate software procurement from hardware and view vehicle software as a global component across brands, models and years. This is more difficult than one might think, considering how model-specific vehicle software has become.
Use of standards-based frameworks
Mission-critical systems include not only autonomous vehicles but also aerospace, defense, naval vessels, and unmanned aerial vehicles. They all require high performance, safety, and redundancy with additional requirements such as minimization of size, weight, and power (SWaP). To meet these requirements, standardized software frameworks have been formalized. Another advantage is the higher reusability of the software through modularity and portability as well as the interoperability between different systems and providers.
Suitable software frameworks in the automotive industry are not yet available. AUTOSAR Classic, for example, concentrates on microcontrollers with limited capacity but does not consider the dynamic and modular services that new applications require. When a project uses AUTOSAR today, it requires custom development. Code developed for a vehicle platform cannot simply be used from another platform, causing additional manufacturing time and costs. Reusability is, therefore, an essential feature of a good automotive framework. Besides, the interoperability between components, the decoupling of individual applications, the enabling of an adequate path from development to production and the agnostic nature of the underlying hardware are important points here.
Tools & Software
Are your test cases good enough? What test case quality means for error detection
Frameworks especially for autonomous systems
There are new frameworks that specifically target autonomous vehicles, including the new AUTOSAR Adaptive Platform. This framework has a service-oriented architecture (SOA) based on the idea of AUTOSAR Classic. However, it enables more dynamic functions so that applications (services) can come and go without affecting the entire system. It also leverages common and cross-industry standards, such as execution on POSIX-based operating systems. The open-source Robotic Operating System (ROS) software is more of a robotics framework than a traditional operating system. The latest generation ROS2 is even more scalable, reliable and powerful. Future ideas also exist to provide security-certifiable instantiations for this open-source project.
The DDS data bus solves the most common technical challenges facing automotive manufacturers. The AUTOSAR and ROS2 frameworks, as well as many platforms built internally by Tier-1 suppliers and manufacturers, are also based on the Data Distribution Service (DDS) standard. It is used here as the underlying communication framework to meet the complex applications of highly autonomous and fully autonomous vehicles - especially where Quality of Service (QoS) in real-time, security and performance are crucial.
Reusing software applications on different platforms is not an easy task given the extensive technologies of the different vehicle classes. Different functions and sensor configurations require individual development. Using a software framework, manufacturers can easily reuse applications in multiple environments and configure the technology for each application.
A DDS data bus supports a dynamic environment: the modular architecture removes the dependence of individual software applications on "how" they communicate with other applications or services. The abstraction of the underlying platform and physical communication mechanisms improves application portability. Configurable QoS allows the specific connectivity requirements of each application to be customized without additional software development.
Securing operational processes becomes critical through the improvement of autonomous systems that penetrate further into the areas of society. Consequently, the DDS data bus must be protected from untrusted parties and harmful insider threats. Negative actors should neither capture data during transmission nor create data that affects the behavior of other components.
A secure DDS data bus provides all of the above security while maintaining its data-centric approach and all of the above features, such as a fine-grained configuration of authentication, access control, and data encryption. Protection is provided by data type, enabling flexible and efficient coexistence of data streams with different security requirements in an untrusted network. The security measures do not impair portability, modularity or QoS. Industry-standard algorithms exist for authentication, main exchange, and encryption.
Adaptation to application and data type
With an autonomous vehicle, it must meet the performance requirements of real-time. Unreliable communication harms interoperability because the connected system does not receive the data required by its algorithms. Developers must ensure that the vehicle can perceive, think and act quickly enough to respond to its environment. This poses a challenge because as bandwidth requirements increase, systems have to absorb large amounts of data, such as from HD cameras and LiDAR. Typically, there is an inherent compromise between optimizing for low latency and maximizing bandwidth. However, the QoS parameters of DDS allow latency and bandwidth usage to be adapted to each specific application and data type (see also Figure 1).
When is DDS suitable for software developers?
DDS aims at final data-centric software integration by software teams. When intelligent software becomes important, DDS provides the necessary interface control of data abstraction and data flow. The following questions will help you decide whether DDS is suitable for an application:
- Is it a big problem if my system goes down for a short time?
- Are milliseconds important in my communication?
- Do I employ different software development teams or more than ten software developers?
- Do I send data to many places instead of just one, like a cloud or database?
- Am I implementing a new IIoT architecture?
This article was previously published in German on Elektronikpraxis.
* * Bob Leigh is Senior Director of Automotive at RTI. * Reiner Duwe is Sales Manager EMEA at RTI