AUTOSAR DDS Integration for Classic-Adaptive Vehicle Communication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The conventional AUTOSAR specification is inadequate for current vehicle electronics development, particularly in intelligent networking and autonomous driving, as it cannot support unified service-oriented communication between classic and adaptive platforms, requiring manual code modifications and complex developer work to implement DDS interfaces.
Innovation Solution
A system architecture is introduced that integrates DDS into the basic software of a classic AUTOSAR architecture, enabling automatic discovery and management of message publishers and subscribers, and using a multi-protocol gateway for interworking between SOME/IP and DDS, thus allowing seamless communication and reducing memory background noise.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If DDS is implemented in CDD of CP software architecture, then DDS basic function is provided, but developer workload increases due to manual code modification
Solution Approach 1:
The patent introduces an intermediary layer (DDS adapter or gateway) between the CP software architecture and DDS protocol. This adapter handles DDS-specific operations (publish, subscribe, QoS management) while presenting a standardized interface to developers. The adapter translates developer-friendly API calls into DDS protocol operations, eliminating the need for manual code modification while maintaining DDS functionality.
Solution Approach 2:
The patent segments the DDS implementation into modular components: a core DDS adapter module that handles protocol complexity, and simplified interface modules that developers interact with. This segmentation isolates the complexity of manual code modification into a manageable adapter layer, while keeping the rest of the development process automated and tool-friendly.
2Adaptability or versatility
If CP device uses only SOME/IP for communication, then communication with SOME/IP applications is enabled, but communication with DDS applications in AP device is impossible
Solution Approach 1:
The patent implements a multi-functional communication gateway that supports both SOME/IP and DDS protocols simultaneously. The gateway can operate in different modes: SOME/IP-only mode for traditional CP devices, and dual-protocol mode for hybrid devices that need to communicate with both SOME/IP applications and DDS applications on AP devices, ensuring broad compatibility and reliable communication across different platform types.
Solution Approach 2:
The patent introduces a protocol translation gateway as an intermediary between SOME/IP and DDS systems. This gateway translates messages between the two protocols, enabling CP devices using SOME/IP to communicate with AP devices using DDS without requiring changes to existing applications, thus maintaining reliability while expanding protocol support.
3Adaptability or versatility
If DDS is integrated into BSW in CP software architecture, then DDS compatibility with CP is achieved, but software component may be affected by underlying modification
Solution Approach 1:
The patent introduces an abstraction layer (DDS adapter or virtualization interface) between software components and the integrated DDS functionality in BSW. This intermediary presents a stable, standardized interface to software components while handling DDS-specific operations in the background. Software components interact with the stable interface without being affected by underlying DDS implementation details or modifications, maintaining both compatibility and stability.
Solution Approach 2:
The patent segments the system into three distinct layers: the stable software component layer that remains unchanged, the intermediary adaptation layer that provides stable interfaces, and the DDS integration layer in BSW that handles protocol-specific operations. This segmentation isolates software components from underlying modifications while maintaining DDS compatibility through the stable intermediary interfaces.
Data Source
Figure 1
Figure 2
Figure 3~4
AI summary
This application discloses a system architecture for implementing DDS communication based on AUTOSAR, a communication method, and a device, which may be applied to an intelligent agent (for example, an intelligent vehicle, an intelligent connected vehicle, or an autonomous vehicle) in intelligent driving. The system architecture includes at least one first integrated module, a data distribution service (DDS) architecture, and an automotive open system architecture (AUTOSAR), the first integrated module is constructed in the DDS architecture, the DDS architecture is deployed in basic software (BSW) in the AUTOSAR, and the AUTOSAR includes a runtime environment (RTE) and a software component (SWC). The first integrated module is configured to manage a message publisher and/or a message subscriber. The RTE is configured to store a mapping relationship between each first integrated module and a corresponding software component (SWC) signal. The SWC signal is a signal sent by the SWC to the RTE and provided for the DDS architecture. In this application, the DDS is integrated into the BSW in a CP software architecture, so that the DDS is compatible with a CP, and the SWC is unaware of modification of underlying software.