(Did you miss Part 1? Click to read The Problem of Software Interoperability in Automated and Assisted Driving Systems. This is Part 2 of the blog series “Challenge of Software Interoperability.”)

AVCC’s Recommendations for Addressing Software Interoperability 

In our first post, we explored the challenges of software interoperability in automated and assisted driving systems. Now, we turn our attention to the solutions proposed by the Automotive and Autonomous Vehicle Computing Consortium (AVCC). The AVCC has laid out a set of comprehensive recommendations aimed at fostering an ecosystem of interoperable software components, through the adoption of a data-oriented architecture, and the Data Distribution Service (DDS) international open standard for achieving data-oriented communication. 

Adopting Data-Oriented Architecture 

The AVCC advocates the adoption of a data-oriented communication architecture—a best practice for building interoperable software systems, proven across multiple industries. This approach focuses on the data being decoupled from the applications. Applications interact with the data in a shared data space and are not coupled to one another. Applications simply read or write data—when data inputs change, an application acts, and as a result may output new data updates. The data interfaces are crisply defined in terms of the structure and behavior (including timing) of the data exchanged. The data structures and the behaviors together comprise the data model.  

Guidelines for Implementing Data-Oriented Architecture include: 

1. Common Data Models: Establish common data models that define the structure and behavior of the data exchanged between components. This ensures that all components “speak the same language”. 
2. Datatypes: Define datatypes that specify the structure of the data exchanges, such as inheritance, nesting, mutability, and extensibility. This helps ensure that data is transmitted in a manner that meets the structural needs of the applications, while allowing for communication data interface evolution. 
3. Quality-of-Service Profiles: Define quality-of-service (QoS) profiles that specify the behavior of data exchanges, such as reliability, latency, and durability. This helps ensure that data is transmitted in a manner that meets the timing needs of the applications, while allowing for communication data interface evolution. 
4. Data-Centric Communication: Focus on data-centric communication, where the state of the system is represented by the data itself. This contrasts with traditional message-centric communication, where the emphasis is on the messages sent between components. 

Adopting the DDS Standard 

The DDS standard provides a robust framework for data-centric communication. It is an open standard that is designed from “grounds up” for real-time data exchange and is particularly suited for the needs of automated and assisted driving systems. It is proven across industries for autonomy applications, is seeing rapid adoption in automotive, and official DDS bindings have been added to the AUTOSAR Adaptive and Classic platforms. 

Notable aspects of DDS include:  

• The DDS family of specifications include a rich datatype definition language, and a rich set of data QoS policies for declaring behaviors. Thus, DDS provides a rich “standardized” vernacular for defining extensible data models and data-oriented communication interfaces. 
• Decoupled Communication: DDS allows for decoupled communication, meaning that software components do not depend on each other’s location or existence. This abstraction simplifies the development and integration of components. 
• Peer-to-Peer Data Distribution: DDS supports peer-to-peer data distribution, enabling direct data exchanges between components without a central broker. This enhances performance, availability, resilience, scalability, security, and safety. 
• Dynamic Discovery: Components can dynamically discover each other at runtime, making it easier to add, remove, or update components without requiring system-wide reconfiguration. It speeds up the software development cycle, while still allowing for locking down configuration statically in production deployments. 
• Software Databus Abstraction of Physical Connectivity: By abstracting physical connectivity details, the DDS defines a software databus with a standardized programming API and wire protocol. It allows developers to focus on the data and its semantics rather than the intricacies of managing network connections and implementations. This simplifies and speeds up the development process, and drastically reduces the potential for errors introduced by the complexity of simultaneously dealing with multiple physical connectivity technologies and connections. Components simply “plug -n-play” on the software databus and can delegate the responsibility of picking the best communication path (e.g. local shared memory vs. ethernet) to the DDS databus. 

Benefits of Data-Oriented Communication Architecture using DDS 

Adopting a data-oriented communication architecture using the DDS standard provides several key benefits that streamline software development and maintenance processes. 

Improved Software Deployment Flexibility 

A significant advantage of data-oriented communication architecture is the flexibility it offers in software deployment. By adhering to common data models, software components can be updated independently. This means that developers can release updates or new features for individual components without needing to overhaul the entire system. 

For example, consider an automated driving system with separate components for lane-keeping, obstacle detection, and collision avoidance. If the obstacle detection component needs an update to improve its accuracy, developers can implement and deploy that update independently. The components, which only rely on the common data model, continue to function seamlessly with the updated obstacle detection system. 

Flexible Deployment on Different Compute Platforms 

Data-oriented architecture also facilitates flexible deployment across various compute platforms. The DDS software databus abstracts away the physical connectivity details, allowing software components to communicate regardless of the underlying hardware. This means that components can be deployed on different platforms, whether they are in-vehicle embedded systems, cloud-based servers, or edge devices. 

For instance, during the development and testing phases, components can run on high-performance compute platforms on premise or in the cloud to leverage powerful computing resources. Once validated, the components can be redeployed on embedded platforms within the vehicle, facilitating continuous integration and delivery (CI/CD) across different environments. 

Conclusion 

The AVCC’s recommendations for adopting a data-oriented architecture using the DDS standard provide a robust framework for addressing the challenges of software interoperability in automated and assisted driving systems. By streamlining software development and maintenance processes, these best practices pave the way for more flexible, scalable, robust, and reliable driving systems. 

In the final part of this blog series, we will explore real-world case studies and examples that demonstrate the practical benefits of these recommendations in action. Stay tuned! 

• Part 3: Reducing Costs while Increasing Innovation

About the author:

Dr. Rajive Joshi, Chair of the AVCC Software Portability Working Group and Principal Solution Architect at Real-Time Innovations (RTI).