A novel AUTOSAR vehicle electrical system based on DDS-TSN

Abstract

This invention relates to a novel AUTOSAR vehicle electronic system based on DDS-TSN, belonging to the field of automotive electronics technology. Addressing the requirements for high-performance deterministic management and scheduling of service traffic in integrated vehicle electronic control systems, this invention adopts a comprehensive system-level approach. Through multi-dimensional collaboration of architecture, platform, middleware, and operating system, it provides a deterministic time-sensitive network middleware based on DDS-TSN, bridging the critical path between hardware TSN deterministic communication and software DDS deterministic bus. This results in a novel AUTOSAR vehicle electronic system based on DDS-TSN, solving the key hardware and software issues related to the overall real-time and deterministic nature of the system.

Description

Technical Field

[0001] This invention belongs to the field of automotive electronics technology, specifically relating to a novel AUTOSAR vehicle electronic system based on DDS-TSN. Background Technology

[0002] With the rapid development of automotive intelligence and connectivity, the performance requirements for vehicle electronic systems are becoming increasingly stringent. Traditional vehicle electronic systems are insufficient in terms of real-time performance, determinism, and scalability of data transmission, making it difficult to meet the demands of modern automobiles for efficient communication and intelligent control. AUTOSAR, as a standardized automotive electronic software architecture, provides a unified platform and specifications for the development of automotive electronic systems. However, existing AUTOSAR vehicle electronic systems still have room for improvement in data communication.

[0003] Because in-vehicle systems are extremely large and complex, heavily reliant on operating systems such as Linux and QNX, ensuring real-time performance is even more challenging. The root cause lies in the inherent uncertainties at every stage, from applications and middleware to the operating system, hardware, and network. These uncertainties accumulate layer by layer, increasing as you move closer to the application layer and decreasing as you approach the hardware layer. Ultimately, the cumulative effect of these uncertainties leads to a decline in both the overall system's uncertainty and real-time performance.

[0004] Therefore, solving the real-time problem of distributed systems is a complex systems engineering project, and we cannot expect to solve it comprehensively by applying a single technology. Relying solely on middleware, operating systems, or network technologies is far from sufficient. A comprehensive approach at the system level is needed, through multi-dimensional collaboration of architecture, platform, middleware, operating systems, and other aspects, in order to meet stringent real-time requirements. Summary of the Invention

[0005] (a) Technical problems to be solved

[0006] The technical problem to be solved by this invention is how to provide a novel AUTOSAR vehicle electrical system based on DDS-TSN to solve the real-time problem of distributed systems.

[0007] (II) Technical Solution

[0008] To address the aforementioned technical problems, this invention proposes a novel AUTOSAR vehicle electronic system based on DDS-TSN, which includes: a peripheral platform layer, a hardware platform layer, a system layer, middleware, and an application layer.

[0009] The outer platform layer is the external vehicle domain;

[0010] The hardware platform layer constructs an in-vehicle electronic system architecture based on the intelligent connected architecture, which includes three parts: data processor, communication controller and handheld phone;

[0011] The system layer deploys the system according to the different requirements of each board;

[0012] The middleware is an AUTOSAR based on DDS-TSN deterministic time-sensitive networks, and has execution management, state management, communication management, platform health management and diagnostic management modules.

[0013] Application layer: This includes common basic service modules for other applications and applications developed based on the vehicle system's power domain and intelligent driving domain. The basic service modules include diagnostic services, health management services, protocol conversion services, data transmission services, storage services, interface display services, and resource collaborative management services. The applications include display management programs, monitoring management programs, and control programs.

[0014] (III) Beneficial Effects

[0015] This invention proposes a novel AUTOSAR vehicle electronic system based on DDS-TSN. Addressing the high-performance deterministic management and scheduling requirements of traffic in integrated vehicle electronic control systems, this invention adopts a comprehensive system-level approach. Through multi-dimensional collaboration of architecture, platform, middleware, and operating system, it provides a deterministic time-sensitive network middleware based on DDS-TSN, bridging the critical path between hardware TSN deterministic communication and software DDS deterministic bus. This results in a novel AUTOSAR vehicle electronic system based on DDS-TSN, solving the key hardware and software issues related to the overall real-time and deterministic nature of the system. Attached Figure Description

[0016] Figure 1 This is a system architecture diagram of the present invention;

[0017] Figure 2 This is a schematic diagram of the DDS-TSN fusion scheme. Detailed Implementation

[0018] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0019] This invention relates to the field of automotive electronics technology, specifically to a novel vehicle electronic system employing a hierarchical architecture (AUTOSAR) that integrates TSN (Time-Sensitive Networking) and DDS (Data Distribution Service) technologies.

[0020] This invention provides a novel AUTOSAR vehicle electronic system based on DDS-TSN. The system adopts a hierarchical architecture, including a peripheral platform layer, a hardware platform layer, a system layer, middleware (AUTOSARAP), and an application layer.

[0021] 1) The peripheral platform layer is the external vehicle domain, such as the power domain, chassis domain, intelligent architecture domain, equipment domain, etc., which is also a special kind of peripheral platform for the system.

[0022] 2) The hardware platform layer constructs a new generation of in-vehicle electronic system architecture based on intelligent connected vehicle architecture, mainly consisting of three parts: a data processor, a communication controller (one in master-slave mode), and a handheld phone. The data processing simulator implements data calculation, storage, and service for the system simulation software. The communication controller is responsible for Ethernet data transmission. The handheld phone is used for remote control and connects to the entire system network to achieve remote communication.

[0023] 3) The system layer deploys the system according to the different requirements of each board. The handheld phone uses the HarmonyOS system, while the power module and communication controller do not have the system deployed. Other boards use the Galaxy V10+RT / Linux / FREERTOS system. The general computing module uses the Galaxy V10+RT system and deploys the vehicle's HarmonyOS system through Docker to implement the interface and services. The ECU module deploys the FREERTOS system.

[0024] 4) The middleware is AUTOSAR based on DDS-TSN deterministic time-sensitive networks and has modules for execution management, state management, communication management, platform health management, and diagnostic management.

[0025] The execution management module is process number one on the AP platform, similar to the systemd service in Linux. Its core function is to maintain the lifecycle of all processes on the AP platform. Applications (processes) on the AP platform are required to be grouped according to functional groups, each with multiple states. Applications must declare which functional group they belong to and register their processes in which state. When a functional group switches to a certain state, processes registered in that state are started, while processes not registered in that state are terminated.

[0026] The platform health management module is responsible for monitoring applications based on AUTOSAR and those created through the IDE. When a monitored entity fails, the platform health management module sends the failure information to the execution management module. The execution management module communicates with the status management module to switch the status of the function group and trigger recovery operations.

[0027] The State Management module is responsible for determining the internal state of applications (including platform applications) based on information received from them. It is the central point for receiving any operational events that may affect its internal state. The State Management module evaluates these events and may request new function group states or machine states from the Execution Management module. The functionality of the State Management module is highly project-specific.

[0028] Function group status change requests can be triggered by several platform applications:

[0029] • Platform health management triggered error recovery.

[0030] • Adaptive diagnostics issues a system reset.

[0031] • Update and configuration management switch the system to a state where software or configuration can be updated and updates can be verified.

[0032] The Diagnostic Management Module is a functional cluster of the AUTOSAR adaptive platform. The Diagnostic Management Module includes Diagnostic Communication Management, Fault Storage Management, Online Diagnostic Monitoring, and Diagnostic Event Management. Among them, Diagnostic Event Management (DEM) mainly provides diagnostic event services, processes diagnostic events, records operation cycle status, maintains DTC status, and stores event data.

[0033] The communication management module primarily provides diagnostic session management, diagnostic request forwarding, and UDS (Unified Diagnostic Services) service processing. Addressing the high-performance deterministic management and scheduling requirements of business traffic in integrated vehicle electronic control systems, it innovatively proposes a deterministic time-sensitive network middleware based on DDS-TSN, bridging the critical path between hardware TSN deterministic communication and software DDS deterministic bus, thus solving the key hardware and software issues related to the overall real-time and deterministic nature of the system.

[0034] We added topic and TSN channel functional modules to the DDS module. We also used QoS configuration for the TSN data transmission function (both the DDS publisher and DDS subscriber need QoS configuration). Developers only need to be familiar with DDS. By configuring TSN parameters in the DDS QoS settings, the DDS and TSN transmission functions can be realized. This simplifies the DDS and TSN configuration and allows developers to easily use TSN network devices without having to understand the functions and mechanisms of TSN.

[0035] To utilize the real-time capabilities of DDS-TSN, firstly, by modifying the DDS kernel, QoS configuration is implemented to unify the expiration dates of both the DDS system and the TSN network. This ensures data real-time performance not only at the application layer but also at the transport layer. Secondly, link priority and gating are implemented by binding DDS topic data to TSN channels during transmission. By modifying the DDS kernel to configure QoS and complete the binding between topics and TSN channels, the DDS kernel module directly transmits data according to the QoS-specified TSN channel during data transmission, guaranteeing data real-time performance and validity from the underlying layer.

[0036] Modifying the DDS kernel mainly accomplishes four aspects: First, in terms of data type support, it adds support for bitstream information structure types, that is, it supports structure data types containing key parameters of image bitstreams, such as bitrate, frame rate, and resolution; Second, it expands QoS policies to implement a method of binding DDS topic data with TSN channels for transmission, thereby realizing link priority and gating settings, as well as unifying the expiration dates of DDS itself with those of the TSN network; Third, it supports language extensions, enabling the invocation of multi-language development services; Fourth, it optimizes data transmission efficiency by improving thread management, locking mechanisms, and memory allocation.

[0037] 5) Application Layer: The application layer includes two types of programs: those that provide common basic service modules for other applications and those that are developed based on domains such as the vehicle system power domain and intelligent driving domain. The basic service modules include diagnostic services, health management services, protocol conversion services, data transmission services, storage services, interface display services, and resource collaborative management services. The applications include display management programs, monitoring management programs, and control programs.

[0038] The diagnostic service obtains diagnostic information from the BMC module of each board and sends it to the health management service via the UDS protocol. The diagnostic service is deployed in the general computing module and is the server side of the health management service.

[0039] The protocol conversion service is deployed in the ECU module to realize the mutual conversion between CAN and Ethernet, and between UART and Ethernet in the ECU, providing a foundation for the CAN analog control of the ECU module.

[0040] The data transmission service is a function for data transmission between various boards. It is not a specific application, but is used to achieve time synchronization and data transmission between the boards of the data processing simulator.

[0041] The storage service is deployed in the storage module to realize database storage and file storage of application layer data from the general computing module, AI computing processor, and ECU module.

[0042] Resource collaboration management service is deployed in general computing module, realizing Docker orchestration and management, and HarmonyOS is deployed in Docker to realize interface display service;

[0043] The display management program includes process monitoring and management, and keepalived.

[0044] The monitoring and management program manages the various card processes of the system and enables the switching of redundancy between the general computing module and the storage module.

[0045] The control program can request BMC-based diagnostic services from each board via the network, enabling remote control of each board.

[0046] Example 1:

[0047] A novel vehicle-to-everything (V2X) system based on TSN and DDS adopts a hierarchical architecture, including a peripheral platform layer, a hardware platform layer, a system layer, middleware (AUTOSARAP), and an application layer.

[0048] 1) Peripheral Platform Layer: The peripheral platform layer is the external vehicle domain, such as the power domain, chassis domain, intelligent architecture domain, equipment domain, etc., which is also a special kind of peripheral platform for the system.

[0049] 2) Hardware Platform Layer: The system's hardware platform layer constructs a new generation of in-vehicle electronic system architecture based on an intelligent connected vehicle architecture, mainly consisting of three parts: a data processing simulator, a communication controller (one in master-slave mode), and a handheld phone. The data processing simulator implements data calculation, storage, and service for the system simulation software. The communication controller is responsible for Ethernet data transmission. The handheld phone is used for remote control, connecting to the entire system network to achieve remote communication.

[0050] 3) System layer: The system is deployed according to the different requirements of each board. The handheld phone uses the HarmonyOS system, while the power module and communication controller do not have the system deployed. Other boards use the Galaxy V10+RT / Linux system / FREERTOS system. The general computing module uses the Galaxy V10+RT system and deploys the vehicle's HarmonyOS system through Docker to realize the interface and provide services. The ECU module deploys the FREERTOS system.

[0051] 4) Middleware AUTOSAR: Includes AUTOSAR conforming to the general middleware architecture of vehicles, with modules such as execution management, status management, communication management, platform health management, and diagnostic management.

[0052] The execution management process is process number 1 on the AP platform, similar to the systemd service in Linux. Its core function is to maintain the lifecycle of all processes on the AP platform. Applications (processes) on the AP platform are required to be grouped according to functional groups, each with multiple states. Applications must declare which functional group they belong to and register their processes in which state. When a functional group switches to a certain state, processes registered in that state are started, while processes not registered in that state are terminated.

[0053] The platform health management is responsible for monitoring applications based on AUTOSAR and those created through the IDE. When a monitored entity fails, the platform health management sends the failure information to the execution management module. The execution management module communicates with the status management module to switch the status of the functional group and trigger recovery operations.

[0054] State management is responsible for determining the internal state of an application (including platform applications) based on information received from it. It is the central point for receiving any operational events that may affect its internal state. State management evaluates these events and may request new functional group states or machine states from execution management. The functions of state management are highly project-specific.

[0055] Function group status change requests can be triggered by several platform applications:

[0056] • Platform health management triggered error recovery.

[0057] • Adaptive diagnostics issues a system reset.

[0058] • Update and configuration management switch the system to a state where software or configuration can be updated and updates can be verified.

[0059] Diagnostic management is a functional cluster of the AUTOSAR adaptive platform. Among them, diagnostic event management (DEM) mainly provides diagnostic event services, processes diagnostic events, records operation cycle status, maintains DTC status, and stores event data.

[0060] Communication management primarily provides diagnostic session management, diagnostic request forwarding, and UDS service processing. Addressing the high-performance deterministic management and scheduling requirements of service traffic in integrated vehicle electronic control systems, an innovative deterministic time-sensitive network middleware based on DDS-TSN is proposed. This middleware bridges the critical path between hardware TSN deterministic communication and software DDS deterministic bus, resolving key hardware and software issues related to overall real-time and deterministic system performance.

[0061] 5) Application Layer: The application layer includes two types of programs: those that provide common basic service modules for other applications and those that are developed based on domains such as the vehicle system's power domain and intelligent driving domain. The basic service modules include diagnostic services, protocol conversion services, data transmission services, storage services, interface display services, and resource collaborative management services. The applications include display management, monitoring management, and control programs.

[0062] The diagnostic service obtains diagnostic information from the BMC module of each board and sends it to the health management system via the UDS protocol. The diagnostic service is deployed in the general computing module and serves as the server side of the health management service.

[0063] The protocol conversion service is deployed in the ECU module to realize the mutual conversion between CAN and Ethernet, and between UART and Ethernet in the ECU, providing a foundation for the CAN analog control of the ECU module.

[0064] The data transmission service is a function for data transmission between various boards. It is not a specific application, but is used to achieve time synchronization and data transmission between the boards of the data processing simulator.

[0065] The storage service is deployed in the storage module to realize database storage and file storage of application layer data from the general computing module, AI computing processor, and ECU module.

[0066] Resource collaboration management service is deployed in general computing module, realizing Docker orchestration and management, and HarmonyOS is deployed in Docker to realize interface display service;

[0067] Display management includes process monitoring and management, and keepalived.

[0068] The monitoring and management system manages the various card processes of the system and enables the switching of redundancy between general computing modules and storage modules.

[0069] The control program can request BMC-based diagnostic services from each board via the network, enabling remote control of each board.

[0070] This invention addresses the high-performance deterministic management and scheduling requirements of business traffic in integrated vehicle electronic control systems. It adopts a comprehensive system-level approach, employing multi-dimensional collaboration across architecture, platform, middleware, and operating system to provide a deterministic time-sensitive network middleware based on DDS-TSN. This middleware bridges the critical path between hardware TSN deterministic communication and software DDS deterministic bus, and designs a novel AUTOSAR vehicle electronic system based on DDS-TSN, solving the key hardware and software issues related to the overall real-time and deterministic nature of the system.

[0071] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A novel AUTOSAR vehicle electronic system based on DDS-TSN, characterized in that, The system comprises: a peripheral platform layer, a hardware platform layer, a system layer, middleware, and an application layer; The outer platform layer is the external vehicle domain; The hardware platform layer constructs an in-vehicle electronic system architecture based on the intelligent connected architecture, which includes three parts: data processor, communication controller and handheld phone; The system layer deploys the system according to the different requirements of each board; The middleware is an AUTOSAR based on DDS-TSN deterministic time-sensitive networks, and has execution management, state management, communication management, platform health management and diagnostic management modules. Application layer: This includes common basic service modules for other applications and applications developed based on the vehicle system's power domain and intelligent driving domain. The basic service modules include diagnostic services, health management services, protocol conversion services, data transmission services, storage services, interface display services, and resource collaborative management services. The applications include display management programs, monitoring management programs, and control programs. in, The execution management module is the number 1 process of the AP platform, responsible for maintaining the lifecycle of the entire AP platform process. Applications under the AP platform are required to be grouped according to functional groups, and each functional group has multiple states. Applications must declare which functional group they belong to and register their processes to which state. When a functional group switches to a certain state, processes registered in that state will be started, and processes not registered in that state will be terminated. The platform health management module is responsible for monitoring applications based on AUTOSAR and those created through the IDE. When a monitored entity fails, the platform health management module sends the failure information to the execution management module. The execution management module communicates with the status management module to switch the status of the functional group and trigger recovery operations. The State Management module is responsible for determining its internal state based on the information received from the application. It is the central point for receiving any operational events that may affect its internal state. The State Management module evaluates these events and may request new functional group states or machine states from the Execution Management module. The Diagnostic Management Module is a functional cluster of the AUTOSAR adaptive platform. It includes diagnostic communication management, fault storage management, online diagnostic monitoring, and diagnostic event management. Among them, the Diagnostic Event Management (DEM) provides diagnostic event services, processes diagnostic events, records operation cycle status, maintains DTC status, and stores event data. The communication management module provides diagnostic session management, diagnostic request forwarding, and UDS service processing. This module is based on the DDS-TSN deterministic time-sensitive network middleware. It adds functional modules for topics and TSN channels to the DDS module, and also uses QoS configuration for the TSN data transmission function. Both the DDS publisher and the DDS subscriber need QoS configuration. Developers only need to be familiar with DDS. By configuring TSN parameters in the DDS QoS configuration, the DDS and TSN transmission functions can be implemented. To utilize the real-time functionality of DDS-TSN, firstly, by modifying the DDS kernel, QoS configuration is implemented to unify the deadlines of both the DDS itself and the TSN network. This ensures data real-time performance not only at the application layer but also at the transport layer. Secondly, link priority and gating settings are implemented by binding DDS topic data to TSN channels during transmission. By modifying the DDS kernel to configure QoS and complete the binding of topics to TSN channels, the DDS kernel module directly transmits data according to the QoS-specified TSN channel during data transmission, ensuring data real-time performance and validity from the underlying layer.

2. The novel AUTOSAR vehicle electronic system based on DDS-TSN as described in claim 1, characterized in that, The data processing simulator implements data calculation, storage, and service in the system simulation software; The communication controller is responsible for Ethernet data transmission; the handheld phone is used for remote control and connects to the entire system network to achieve remote communication.

3. The novel AUTOSAR vehicle electronic system based on DDS-TSN as described in claim 2, characterized in that, The handheld phone runs on HarmonyOS. The power module and communication controller do not have the system deployed. Other boards use Galaxy V10+RT / Linux / FREERTOS. The general computing module uses Galaxy V10+RT and deploys the vehicle's HarmonyOS system via Docker to provide the interface and services. The ECU module deploys the FREERTOS system.

4. The novel AUTOSAR vehicle electronic system based on DDS-TSN as described in claim 1, characterized in that, In the application layer, The diagnostic service obtains the BMC module diagnostic information of each board and sends it to the health management service via the UDS protocol; The diagnostic service is deployed in the general computing module and serves as the server-side component of the health management service. The protocol conversion service is deployed in the ECU module to realize the mutual conversion between CAN and Ethernet, and between UART and Ethernet in the ECU, providing a foundation for the CAN analog control of the ECU module; Data transmission service is the function of data transmission between various boards, realizing time synchronization and data transmission between various boards of the data processing simulator; The storage service is deployed in the storage module to realize database storage and file storage of application layer data of the general computing module, AI computing processor, and ECU module; Resource collaboration management service is deployed in general computing module, realizing Docker orchestration and management, and HarmonyOS is deployed in Docker to realize interface display service; The display management program includes process monitoring and management, and keepalived; The monitoring and management program manages the various card processes of the system and enables the switching of redundancy between the general computing module and the storage module; The control program requests BMC-based diagnostic services from each board via the network to remotely control each board.

Images