Cross-platform software architecture, vehicle and control method of cross-platform software architecture

Abstract

The embodiment of the invention provides a cross-platform software architecture, a vehicle and a control method of the cross-platform software architecture, and the architecture comprises a first architecture layer which interacts with the vehicle and / or a hardware platform based on a mapping relation list; the second architecture layer is used for providing communication services, scheduling services, diagnosis services and configuration services, the communication services comprise intra-domain communication services and extra-domain communication services, the upper-layer application communicates with the cross-platform software architecture through the intra-domain communication services, standardized data are provided for the upper-layer application, and the upper-layer application communicates with the cross-platform software architecture through the extra-domain communication services. The vehicle and / or the hardware platform communicates with the cross-platform software architecture through an out-of-domain communication service, and provides a scheduling service and / or a diagnosis service for the vehicle of at least one vehicle type based on the standardized data; and the third architecture layer is used for calling a configuration service to provide a configuration write-in function and a configuration read function for the upper-layer application. Therefore, the problems of large workload, long period, high cost and the like of function transplantation caused by platformization only aiming at a single function in related technologies are solved.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a cross-platform software architecture, a vehicle, and a control method for the cross-platform software architecture. Background Technology

[0002] Advanced driver assistance systems (ADAS) software for automobiles has evolved from single electronic control units to domain controllers. The software scale has evolved from single-function to complex multi-function. With the increase in software complexity and the requirement for cross-platform and cross-vehicle applications, technical issues affecting engineering efficiency, such as functional decoupling, standardization, scalability, and platform difference management, have become increasingly important.

[0003] In related technologies, platform architecture only platforms a single function, resulting in a large workload, long cycle and high cost for function porting. In particular, different hardware platforms need to repeatedly develop driver layer code, resulting in high migration costs. The parameter configuration of the same function in different models needs to be maintained independently, resulting in high code redundancy. Traditional architecture cannot dynamically adjust process topology and resource allocation, and low computing power platforms cannot guarantee real-time performance. Summary of the Invention

[0004] This application provides a cross-platform software architecture, a vehicle, and a control method for the cross-platform software architecture, aiming to improve the problem of large workload, long cycle, and high cost of function porting caused by platformization of only a single function.

[0005] A first aspect of this application provides a cross-platform software architecture, comprising: a first architecture layer, which interacts with a vehicle and / or hardware platform based on a mapping relationship list to obtain at least one type of vehicle input data and processes the input data into standardized data of a corresponding format according to the type of the input data; a second architecture layer, which provides communication services, scheduling services, diagnostic services, and configuration services, wherein the communication services include intra-domain communication services and inter-domain communication services, wherein an upper-layer application communicates with the cross-platform software architecture through the intra-domain communication service to provide the standardized data to the upper-layer application, and the vehicle and / or the hardware platform communicates with the cross-platform software architecture through the inter-domain communication service to provide the scheduling service and / or diagnostic service for at least one type of vehicle based on the standardized data; and a third architecture layer, which calls the configuration service to provide configuration writing and configuration reading functions for the upper-layer application, obtains configuration instructions from the upper-layer application or the diagnostic service, and modifies the configuration file of the vehicle and / or hardware platform using the configuration instructions, wherein the configuration file is used to configure the mapping relationship list.

[0006] Based on the above technical means, the cross-platform software architecture in this application embodiment decouples external input differences and vehicle platform differences through the first architecture layer and the third architecture layer to achieve platformization. The second architecture layer integrates internal common logic to build high-level assisted driving dedicated services. The dedicated diagnostic framework design provides functional safety. The flexible scheduling framework provides horizontal extensibility and scalability of the application layer. It is suitable for the development and deployment of intelligent vehicle software systems under complex vehicle models and diverse hardware platforms. It provides a standardized, consistent and efficient secure architecture layer, effectively reducing adaptation costs and testing costs, and minimizing platform migration costs.

[0007] Optionally, the second architecture layer includes: a communication service framework, a scheduling service framework, a diagnostic service framework, and a configuration service framework. The communication service framework provides intra-domain communication services and inter-domain communication services. The diagnostic service framework extracts vehicle identifiers, fault identifiers, and diagnostic events from the standardized data, and performs fault processing on the vehicle identifiers, fault identifiers, and diagnostic events using a pre-configured diagnostic template to obtain fault diagnosis results. The scheduling service framework is used to select corresponding scheduling methods, configuration items, and plugin combinations based on at least one configuration file, scheduling kernel, and application plugins to implement task scheduling for different vehicles and / or hardware platforms according to the scheduling methods, configuration items, and plugin combinations. The configuration service framework is used to configure instructions to modify the configuration files of the vehicles and / or hardware platforms.

[0008] Based on the above technical means, the second architecture layer in this application embodiment constructs a standardized, platform-based, scalable, configurable, and high-performance service support system through the collaboration of four major service frameworks: communication, scheduling, diagnosis, and configuration. This provides powerful underlying service support for intelligent vehicle software systems that are cross-vehicle and cross-hardware platform, significantly improving the system's flexibility, maintainability, real-time performance, and platform adaptability.

[0009] Optionally, the intra-domain communication service includes heterogeneous hardware core intra-core communication service and heterogeneous core inter-core communication service, and the extra-domain communication service includes data transceiver service for external devices. The heterogeneous core inter-core communication service provides data publishing and subscription ports to the upper-layer application through cross-core technology stack; the heterogeneous core intra-core communication service provides process data channels within the heterogeneous core through memory channels; and the extra-domain communication service provides data transceiver service for vehicles and / or hardware platforms through network protocols.

[0010] Based on the aforementioned technical means, the heterogeneous core intra-core communication service of this application embodiment is used for data communication between different processes within the same hardware core. It provides efficient inter-process communication through memory channels, reduces the number of data copies, improves communication efficiency, and has a fast response speed, making it suitable for real-time task interaction. The heterogeneous core inter-core communication service is used for data communication between different hardware cores. It integrates cross-core technology stacks and provides standardized publish and subscribe ports to upper-layer applications. Through a unified publish and subscribe interface, it can shield the differences in underlying cross-core communication, has strong cross-core collaboration capabilities, adapts to different hardware platforms, and has strong scalability. The external communication service is responsible for data transmission and reception with external devices. It implements external communication based on a network protocol stack, has strong openness, and can be flexibly deployed. By unifying intra-domain and external communication into a platform-based service system, it not only ensures efficient collaboration within the heterogeneous hardware platform but also achieves openness and standardization in external communication.

[0011] Optionally, the scheduling service framework is configured with a scheduling mode and a process combination deployment mode. The process combination deployment mode is used to assemble multiple application plugins into at least one process instance. The scheduling mode of the configuration item includes a time scheduling mode and an event scheduling mode. The time scheduling mode is used to trigger tasks according to a predetermined time. The event scheduling mode is used to trigger tasks according to data relationships.

[0012] Based on the above technical means, the scheduling service framework in this application embodiment achieves high real-time performance, low latency, efficient resource utilization, and flexible cross-platform adaptation for task execution through a time / event dual scheduling mode and a plug-in process combination deployment mechanism, which significantly improves the system's performance, reliability, and scalability.

[0013] Optionally, the diagnostic service framework includes a collection layer and an aggregation layer. The collection layer is used to encapsulate diagnostic functions into diagnostic templates and use the diagnostic templates to implement data diagnostic functions. The aggregation layer is used to manage the mapping relationship between fault identifiers and diagnostic events using configuration files, so as to perform corresponding add, modify and delete operations on the configuration files according to diagnostic needs.

[0014] Based on the above technical means, the diagnostic service framework in this application manages the mapping relationship between the diagnostic template encapsulation in the acquisition layer and the fault identifiers and diagnostic events in the configuration file of the aggregation layer, thereby realizing an efficient, flexible and consistent fault detection and management mechanism, which significantly improves the stability, maintainability and adaptability of the system, and is particularly suitable for application scenarios such as intelligent vehicles that have extremely high requirements for real-time performance and reliability.

[0015] Optionally, the input data includes vehicle protocol data, map data, image data, and network data. The first architecture layer includes: a CAN service sublayer, a map service sublayer, an image service sublayer, and a network service sublayer. The CAN service sublayer is used to convert the vehicle protocol data into standardized data that meets CAN service requirements; the map service sublayer is used to convert the map data into standardized data that meets map service requirements; the image service sublayer is used to convert the image data into standardized data that meets image service requirements; and the network service sublayer is used to convert the network data into standardized data that meets network service requirements.

[0016] Based on the above technical means, in this embodiment of the application, the first architecture layer converts raw input data from different sources into a standardized data format through CAN, map, image and network service sub-layers, thereby realizing data abstraction, platform adaptation and interface unification.

[0017] Optionally, each sub-layer of the first architecture layer is built on a communication service framework.

[0018] Based on the above technical means, in the embodiments of this application, each sub-layer of the first architecture layer interacts with data, calls services and shares resources through a unified communication service framework. After processing the original input data and generating standardized data, each sub-layer transmits the data to the upper-layer application efficiently, reliably and in a standardized manner through the unified communication service framework, thereby improving the overall consistency and maintainability of the system and achieving low-latency and high-throughput data transmission.

[0019] Optionally, the third architecture layer includes a configuration mapping plugin, wherein the configuration mapping plugin configures the mapping relationship list based on the configuration file.

[0020] Based on the above technical means, in this embodiment of the application, the configuration mapping plugin is a pluggable configuration processing module, which is used to dynamically generate or update the mapping relationship list used in the first architecture layer according to the configuration file content. By changing the configuration file, it can be adapted to different vehicle models or hardware platforms without modifying the core code, decoupling the data processing logic from platform differences, and realizing the platform's flexible adaptability and efficient maintainability.

[0021] A second aspect of this application provides a vehicle, including the cross-platform software deployment architecture described in the above embodiments.

[0022] A third aspect of this application provides a control method for a cross-platform software deployment architecture. The method is applied to the cross-platform software deployment architecture described in any of the above embodiments. The method includes the following steps: executing a first architecture layer, which interacts with vehicles and / or hardware platforms based on a mapping relationship list to obtain at least one type of vehicle input data, and processes the input data into standardized data of a corresponding format according to the type of the input data; executing a second architecture layer, which provides communication services, scheduling services, diagnostic services, and configuration services. The communication services include intra-domain communication services and inter-domain communication services. Upper-layer applications access the system through... The intra-domain communication service communicates with the cross-platform software architecture to provide the standardized data to the upper-layer application. The vehicle and / or the hardware platform communicate with the cross-platform software architecture through the extra-domain communication service to provide the scheduling service and / or diagnostic service for at least one of the vehicle models based on the standardized data. The third architecture layer is executed, which is used to call the configuration service to provide configuration writing and configuration reading functions for the upper-layer application, obtain the configuration instructions of the upper-layer application or the diagnostic service, and modify the configuration file of the vehicle and / or hardware platform using the configuration instructions. The configuration file is used to configure the mapping relationship list.

[0023] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0024] Figure 1 This is a block diagram illustrating the cross-platform software architecture provided in an embodiment of this application;

[0025] Figure 2 This is a schematic diagram of the scalable cross-platform software deployment architecture provided in the embodiments of this application;

[0026] Figure 3 This is a schematic diagram of the platform adaptation layer provided in the embodiments of this application;

[0027] Figure 4 This is a schematic diagram of the service framework layer provided in the embodiments of this application;

[0028] Figure 5 This is a schematic diagram of the diagnostic framework in the service framework layer provided in the embodiments of this application;

[0029] Figure 6 This is a schematic diagram of the scheduling service framework of the service framework layer provided in the embodiments of this application;

[0030] Figure 7 This is a schematic diagram of the configuration service framework provided in the embodiments of this application;

[0031] Figure 8 This is a flowchart of the control method for the cross-platform software deployment architecture provided in the embodiments of this application. Detailed Implementation

[0032] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0033] With the continuous iteration and development of advanced driver assistance systems (ADAS) technology, its application in the automotive field is becoming increasingly widespread, and more and more car models are equipped with ADAS technology. This growing demand has also spurred the need for platformization, enabling ADAS algorithms to be rapidly migrated across hardware platforms and car models.

[0034] In related technology (1), the platform-based software architecture system adopts a layered approach, extracting and abstracting the common parts of functional logic to form independent functional modules, thereby realizing a unified platform-based control logic. However, this application focuses on the platform-based transformation of in-vehicle AVMs, which is a single-module platform-based transformation and does not involve the platform-based transformation of more complex multi-functional module hybrid systems.

[0035] In related technology (2), the cross-platform airborne integrated software architecture adopts a layered design, consisting of a hardware platform layer, an operating system layer, a capability environment layer, and an application layer. The application layer implements scheduling, the capability environment layer implements communication, the operating system runs the operating system, and the hardware platform layer implements hardware abstraction, thereby achieving cross-platform collaboration and adaptive tailoring. This application mainly focuses on cross-platform compatibility design, failing to address the problems of multi-task collaboration and competition in complex systems with mixed multi-functional modules, and failing to consider security and scalability.

[0036] In related technology (3), the safety redundancy architecture of autonomous vehicles includes a task layer and a safety layer. By decoupling the safety layer, the work and cost of the task layer are simplified, and the safety of the task layer is improved. This application avoids the overhead of redundant frameworks and ensures the safety of the system through the design of the safety layer. However, this patent does not reflect the solution to the problems of multi-task collaboration and competition in complex systems with mixed multi-functional modules, nor does it reflect the consideration of scalability.

[0037] Therefore, this application proposes a scalable cross-platform software deployment architecture applicable to the field of advanced driver assistance systems (ADAS) in automobiles. Following the principle of layered architecture, it decouples external input differences and vehicle platform differences through a platform adaptation layer and a configuration service layer to achieve platformization. It integrates internal common logic through a service framework layer to build dedicated services for advanced driver assistance systems. It provides functional safety through a dedicated diagnostic framework design and provides horizontal extensibility and scalability of the application layer through a flexible scheduling framework.

[0038] The following description, with reference to the accompanying drawings, describes a cross-platform software architecture, a vehicle, and a control method for the cross-platform software architecture according to embodiments of this application.

[0039] Specifically, Figure 1 This is a block diagram illustrating a cross-platform software architecture provided in an embodiment of this application.

[0040] like Figure 1 As shown, the cross-platform software architecture 10 includes: a first architecture layer 100, a second architecture layer 200, and a third architecture layer 300.

[0041] The first architecture layer 100 interacts with the vehicle and / or hardware platform based on the mapping relationship list to obtain at least one type of input data for at least one vehicle model, and processes the input data into standardized data of the corresponding format according to the type of input data. The second architecture layer 200 is used to provide communication services, scheduling services, diagnostic services, and configuration services. The communication services include intra-domain communication services and inter-domain communication services. The upper-layer application communicates with the cross-platform software architecture through the intra-domain communication service to provide standardized data to the upper-layer application. The vehicle and / or hardware platform communicates with the cross-platform software architecture through the inter-domain communication service to provide scheduling services and / or diagnostic services for at least one vehicle model based on the standardized data. The third architecture layer 300 is used to call the configuration service to provide configuration writing and configuration reading functions for the upper-layer application, obtain configuration instructions from the upper-layer application or diagnostic service, and use the configuration instructions to modify the configuration file of the vehicle and / or hardware platform. The configuration file is used to configure the mapping relationship list.

[0042] It is understood that the cross-platform software architecture in this application embodiment achieves platformization by decoupling external input differences and vehicle platform differences through the first architecture layer and the third architecture layer, integrates internal common logic to build high-level assisted driving dedicated services through the second architecture layer, provides functional safety through the design of a dedicated diagnostic framework, and provides horizontal extensibility and scalability of the application layer through a flexible scheduling framework. It is suitable for the development and deployment of intelligent vehicle software systems under complex vehicle models and diverse hardware platforms, provides a standardized, consistent, efficient and secure architecture layer, effectively reduces adaptation costs and testing costs, and minimizes platform migration costs.

[0043] It should be noted that the first architecture layer is used to define the mapping relationship list, which includes the quantity, type, and corresponding communication matrix of the external data for the corresponding vehicle model.

[0044] Specifically, the scalable cross-platform software deployment architecture of this application consists of a three-layer software architecture design, including a first architecture layer, a second architecture layer, and a third architecture layer. It relies on the hardware platform and external interfaces at the bottom, and provides services to the algorithm application software layer at the top. The overall architecture is as follows: Figure 2 As shown, specifically:

[0045] The first architecture layer provides the system with platform-based and cross-platform deployment capabilities; the second architecture layer provides the system with standardized and scalable service frameworks and components; and the third architecture layer provides the system with cross-platform compatibility capabilities. In this application, the first architecture layer can be a platform adaptation layer, the second architecture layer can be a service framework layer, and the third architecture layer can be a configuration service layer, without any specific limitations.

[0046] In this embodiment, the input data includes vehicle protocol data, map data, image data, and network data. The first architecture layer 100 includes: a CAN service sublayer, a map service sublayer, an image service sublayer, and a network service sublayer. The CAN service sublayer is used to convert vehicle protocol data into standardized data that meets the CAN service; the map service sublayer is used to convert map data into standardized data that meets the map service; the image service sublayer is used to convert image data into standardized data that meets the image service; and the network service sublayer is used to convert network data into standardized data that meets the network service.

[0047] It is understood that, in the embodiments of this application, the first architecture layer uses CAN, map, image and network service sublayers to uniformly convert raw input data from different sources into standardized data formats, thereby achieving data abstraction, platform adaptation and interface unification, and maximizing the utilization of platform resources.

[0048] In this embodiment of the application, each sub-layer of the first architecture layer 100 is built based on a communication service framework.

[0049] It is understood that in the embodiments of this application, each sub-layer of the first architecture layer interacts with data, calls services, and shares resources through a unified communication service framework. After processing the original input data and generating standardized data, each sub-layer efficiently, reliably, and in a standardized manner transmits the data to the upper-layer application through the unified communication service framework, thereby improving the overall consistency and maintainability of the system and achieving low-latency, high-throughput data transmission.

[0050] It should be noted that a data adaptation layer is used to isolate external data from internal algorithm applications, while an abstraction layer is used to plan and orchestrate platform resources in a unified manner, so as to maximize the utilization of platform resources.

[0051] Specifically, the first architecture layer (platform adaptation layer) is mainly responsible for the platform-based abstraction of external data from the vehicle's advanced driver assistance controller, and its structure is as follows: Figure 3 As shown.

[0052] The first architecture layer includes a CAN service sublayer, a map service sublayer, an image service sublayer, and a network service sublayer. These sublayers are built on a communication service framework, using loosely coupled components. Different sublayers are independent of each other and support for extended sublayers. If new external inputs are added to different vehicle models, this can be supported through extended components without affecting the architecture of other sublayers. Specifically:

[0053] The CAN service sublayer implements the logical conversion between vehicle / private CAN protocol data and domain-specific algorithm data. It employs a framework-based code design, consisting of a CAN service abstraction framework and configuration file files. The framework code completes the basic process from external CAN protocol abstraction to internal signals, while the configuration file defines the specific mapping relationship from the CAN protocol matrix to the internal signals. By pre-loading the configuration file during initialization, the complete abstraction process from CAN signals to internal CAN information output can be achieved. The CAN service sublayer is suitable for deployment on MCUs or SOCs, allowing for flexible deployment. The configuration file exists in .h file format and can be automatically generated from the vehicle's CAN protocol DBC matrix of the selected vehicle model.

[0054] The map service sublayer abstracts various map source information, including standard precision maps for vehicles, high-precision maps, high-quality maps, vehicle-remembered maps, and crowdsourced maps, into map information used by algorithm software. Relying on the communication service framework, the map service sublayer provides general map services to algorithm application software. Internally, it consists of modules such as map management and updating, map loading, and map data abstraction. Map management and updating manages map source data, performing daily updates to high-precision maps, high-quality maps, crowdsourced maps, and memory maps. Map loading handles the loading of information from various map sources, employing a map processing kernel and plugin architecture that supports the expansion of new map source types and is cross-platform scalable. Map data abstraction is responsible for extracting internally relevant elements from different maps and mapping them onto general map data, publishing them internally through the communication service framework in a standardized data organization format.

[0055] The image service sublayer manages multiple streams of raw image data and abstracts images from different internal algorithms. It employs an architecture of image processing kernel and plugins. By adjusting the access plugins, it can adapt to differences in the number of raw image data streams across different vehicle models. By changing the processing plugins, it can address the varying requirements of different algorithm combinations regarding output image format, size, and resolution. This flexible adaptation framework gives the image service sublayer platform-like capabilities and scalability.

[0056] The network service sublayer implements network-side data access and data abstraction, such as in-vehicle HMI network data access and laser point cloud data access. This sublayer contains multiple network data processing components, each handling different network data services. Each service may use the same or different network protocols and network ports, and they are integrated in a loosely coupled manner, supporting platformization and scalability. The network service sublayer builds its data processing components on top of the communication service framework, isolating the differences in communication protocol support across different platform OSs. Therefore, the network service sublayer only focuses on data differences and scales accordingly, without considering the differences in network protocol technologies provided by the underlying OS.

[0057] In this embodiment, the second architecture layer 200 includes: a communication service framework, a scheduling service framework, a diagnostic service framework, and a configuration service framework. The communication service framework provides intra-domain and inter-domain communication services. The diagnostic service framework extracts vehicle identifiers, fault identifiers, and diagnostic events from standardized data, and uses pre-configured diagnostic templates to perform fault processing on the vehicle identifiers, fault identifiers, and diagnostic events to obtain fault diagnosis results. The scheduling service framework is used to select corresponding scheduling methods, configuration items, and plugin combinations based on at least one configuration file, scheduling kernel, and application plugins to implement task scheduling for different vehicles and / or hardware platforms according to the scheduling methods, configuration items, and plugin combinations. The configuration service framework is used to modify the configuration files of vehicles and / or hardware platforms using configuration instructions.

[0058] It is understood that, in this embodiment of the application, the second architecture layer, through the collaboration of four major service frameworks—communication, scheduling, diagnosis, and configuration—builds a standardized, platform-based, scalable, configurable, and high-performance service support system, providing powerful underlying service support for intelligent vehicle software systems across vehicle models and hardware platforms, and significantly improving the system's flexibility, maintainability, real-time performance, and platform adaptability.

[0059] Specifically, the second architecture layer (service framework layer) provides a series of service frameworks. Its core framework includes communication service frameworks, scheduling service frameworks, diagnostic service frameworks, and configuration service frameworks. In addition, there are some basic general-purpose service frameworks such as log service frameworks and time service frameworks. The service framework layer is arranged as follows: Figure 4 As shown.

[0060] In this embodiment, the intra-domain communication service includes heterogeneous hardware core intra-core communication service and heterogeneous core inter-core communication service, and the extra-domain communication service includes data transmission and reception service for external devices. The heterogeneous core inter-core communication service provides data publishing and subscription ports to upper-layer applications through cross-core technology stacks; the heterogeneous core intra-core communication service provides process data channels within heterogeneous cores through memory channels; and the extra-domain communication service provides data transmission and reception services for vehicles and / or hardware platforms through network protocols.

[0061] It is understood that the heterogeneous core intra-core communication service in this application embodiment is used for data communication between different processes within the same hardware core. It provides efficient inter-process communication through memory channels, reduces the number of data copies, improves communication efficiency, and has a fast response speed, making it suitable for real-time task interaction. The heterogeneous core inter-core communication service is used for data communication between different hardware cores. It integrates cross-core technology stacks and provides standardized publish and subscribe ports to upper-layer applications. Through a unified publish and subscribe interface, it can shield the differences in underlying cross-core communication, has strong cross-core collaboration capabilities, adapts to different hardware platforms, and has strong scalability. The external communication service is responsible for data transmission and reception with external devices. It implements external communication based on network protocol stacks, has strong openness, and can be flexibly deployed. By unifying intra-domain communication and external communication into a platform-based service system, it not only ensures efficient collaboration within the heterogeneous hardware platform but also achieves openness and standardization in external communication.

[0062] It should be noted that the communication service type parameter of the communication service framework is set to an adaptive triggerable service framework that automatically identifies and selects the underlying communication protocol with the lowest overhead and best performance by initiating a service discovery protocol.

[0063] Specifically, the communication service framework of the second architecture layer includes intra-domain communication services and extra-domain communication services. Intra-domain communication services further include heterogeneous core intra-communication services and heterogeneous core inter-communication services. These three sub-service modules are independent of each other and can be independently decomposed and scaled. The extra-domain communication service implements the extra-domain communication underlying services required by the network service sub-layer, such as TCP / IP (Transmission Control Protocol / Internet Protocol) and SOMEIP (Scalable service-oriented middleware over IP), which are relatively common technologies and will not be elaborated here. The heterogeneous core inter-communication service framework adopts a layered architecture design, integrating multiple cross-core technology stacks such as shared memory, network IPC (Inter-Process Communication), and Open AMP (Open Asymmetric Multi-Processing), and provides standardized data publish-subscribe interfaces to achieve the platform requirements of providing openness externally and consistency internally. The heterogeneous intra-core communication service framework and the heterogeneous inter-core communication service framework adopt the same framework design, adding underlying technology stacks such as copy-free and serialization-free memory channels, and supporting an adaptive protocol negotiation mechanism. Algorithm applications can explicitly configure the underlying communication protocol through configuration, or they can configure an adaptive protocol. When configuring the adaptive protocol, the publisher and subscriber of the communication service framework discover each other through service discovery technology and conduct handshake negotiation, adaptively selecting the underlying protocol link with the lowest overhead (optimal latency or optimal load, selectable through configuration).

[0064] In this embodiment of the application, the scheduling service framework is configured with a scheduling mode and a process combination deployment mode. The process combination deployment mode is used to assemble multiple application plugins into at least one process instance. The scheduling modes of the configuration items include a time scheduling mode and an event scheduling mode. The time scheduling mode is used to trigger tasks according to a predetermined time. The event scheduling mode is used to trigger tasks according to data relationships.

[0065] It is understood that the scheduling service framework in this application embodiment achieves high real-time performance, low latency, efficient resource utilization, and flexible cross-platform adaptation for task execution through a time / event dual scheduling mode and a pluggable process combination deployment mechanism, which significantly improves the system's performance, reliability, and scalability.

[0066] It should be noted that the scheduling type parameter of the scheduling service sets nodes with explicit data dependencies to event-based scheduling, and nodes with high time determinism requirements to time-based scheduling. The scheduling deployment configuration parameters, through different combinations of settings, can merge or split multiple upstream and downstream application process nodes.

[0067] Specifically, the scheduling service framework of the second architecture layer is as follows: Figure 6 As shown, the scheduling service framework is organized using a scheduling kernel, application plugins, and configuration files. The scheduling kernel is a framework code with platform-based functionality, while the application plugins can be flexibly deployed according to the resource conditions of different vehicle models and hardware platforms. The configuration files decouple the variable parameters of the scheduling service framework from the framework code through a configuration-based approach.

[0068] The configuration options for the scheduling service framework primarily include scheduling mode options, supporting both time-based and event-based scheduling. Depending on the characteristics of the algorithm application, tasks requiring on-time processing, such as sensor data processing, positioning, and wire-controlled tasks, can be set to time-based scheduling. The scheduling service framework will then build a timed task scheduler based on the OS system's real-time scheduler to provide on-time scheduling capabilities. Alternatively, two processing tasks with strict data dependencies can be set to event-triggered scheduling. The scheduling service framework will then build a real-time scheduling process based on the successor-successor relationship for sequential scheduling, providing scheduling capabilities with minimal end-to-end latency.

[0069] The configuration options for the scheduling service framework also include plugin combination configuration. This configuration allows you to define which application plugins will be launched in the same process mode during initialization, and which other application plugins will be launched in a different process mode.

[0070] The scheduling service framework provides plug-in services to applications. Applications adapt to the framework by compiling independent functional tasks into separate shared object (.so) libraries, which are then loaded and scheduled for execution during initialization, enabling flexible deployment. For example, if hardware platform A is a multi-chip platform, by modifying the combination of .so plug-ins in the scheduling framework based on the characteristics of each chip (e.g., some chips have strong image processing capabilities, some have strong AI processing capabilities, and some have strong logic processing capabilities) and their computing resources, the platform can quickly adapt to the computing power and chip characteristics distribution of platform A, allowing for customized deployment of algorithm application software without rewriting the algorithm application software code. Similarly, if hardware platform B is a single-chip platform, the scheduling service framework can be configured to combine multiple application plug-ins from upstream and downstream of a business flow into a single process, transforming cross-process communication between upstream and downstream components into intra-process communication, significantly reducing end-to-end latency.

[0071] In this embodiment, the diagnostic service framework includes a collection layer and an aggregation layer. The collection layer encapsulates diagnostic functions into diagnostic templates and uses these templates to implement data diagnostic functions. The aggregation layer manages the mapping relationship between fault identifiers and diagnostic events using configuration files, so as to perform corresponding add, modify, and delete operations on the configuration files according to diagnostic needs.

[0072] It is understood that the diagnostic service framework in this application manages the mapping relationship between the diagnostic template encapsulation in the acquisition layer and the fault identifiers and diagnostic events in the configuration file of the aggregation layer, thereby achieving an efficient, flexible and consistent fault detection and management mechanism. This significantly improves the stability, maintainability and adaptability of the system, and is particularly suitable for application scenarios with extremely high requirements for real-time performance and reliability, such as intelligent vehicles.

[0073] It should be noted that the diagnostic service configuration parameters are configured to map the collected data to the backend processed signals. A three-tiered diagnostic framework is adopted, consisting of templated acquisition, configurable aggregation, and diversified processing, enabling the diagnostic functionality to simultaneously meet platform requirements and be scalable.

[0074] Specifically, the diagnostic service framework at the service framework layer, such as Figure 5 As shown, the service framework layer adopts a layered architecture design, consisting of a collection layer and an aggregation layer, on which various diagnostic applications run. Specifically:

[0075] The acquisition layer of the diagnostic service framework adopts a service framework design, which frameworks standardized general diagnostic functions (such as heartbeat diagnosis, frame rate diagnosis, etc.). Algorithm applications only need to be registered and activated to use them. The diagnostic functions can be flexibly scaled to meet the diagnostic needs of different vehicle models.

[0076] The aggregation layer of the diagnostic service framework consists of a diagnostic aggregation framework and configuration files. The diagnostic aggregation framework implements the framework-based mapping logic from diagnostic fault IDs to diagnostic event IDs, while the configuration files define the mapping relationships between diagnostic fault IDs and diagnostic event IDs. When performing cross-platform migrations or adding new diagnostic fault definitions, only the mapping relationships in the configuration files need to be modified, demonstrating strong scalability.

[0077] In practical applications, for fault diagnosis, it is better to use a unique ID, that is, a unique ID that corresponds to a fault in a single data acquisition entity. The ID number will never change during cross-platform migration, so that all platforms can express faults in a consistent way. The aggregation layer configuration can be added or deleted only based on the number of faults, without the need for redefinition.

[0078] It should be noted that the service framework layer of this application also includes a configuration service framework, which provides code framework support for the configuration service layer. The configuration service framework provides standardized API interfaces to the configuration service layer, integrates hardware or software encryption / decryption plugins based on platform capabilities, receives CRUD (Create, Read, Update, Delete) tasks from the configuration service layer, performs corresponding encryption / decryption operations, and actually performs corresponding CRUD operations on the secure database. By adopting the configuration service framework, common software designs are separated from differences through configuration-based management, thus addressing the need for a single software system to iterate synchronously across platforms and vehicle models.

[0079] In this embodiment of the application, the third architecture layer 300 includes: a configuration mapping plugin, wherein the configuration mapping plugin configures a list of mapping relationships based on a configuration file.

[0080] It is understood that the configuration mapping plugin in this embodiment is a pluggable configuration processing module, which is used to dynamically generate or update the mapping relationship list used in the first architecture layer according to the configuration file content. By changing the configuration file, it can be adapted to different vehicle models or hardware platforms without modifying the core code, decoupling the data processing logic from platform differences, and realizing platform flexibility and efficient maintainability.

[0081] It should be noted that the configuration file and the mapping relationship file are as follows: the configuration file is converted into a database file through integration and stores the application parameter information on the storage board; the mapping relationship file realizes the many-to-one or one-to-many configuration mapping relationship when the configuration is modified.

[0082] Specifically, the third architecture layer (configuration service layer) is as follows: Figure 7 As shown, by invoking the third architecture layer, the algorithm application is provided with the ability to write and read configurations. The third architecture layer supports reading the integrated deployment configuration file and generating an encrypted database during the initial initialization phase. It also accepts configuration instructions from the algorithm application or diagnostic service during the process, allowing for additions and modifications to the data in the encrypted database. The third architecture layer also includes one-to-many and many-to-one configuration mapping plugins. These plugins adopt a configuration-based and framework code architecture design, allowing customization of the mapping relationship between an external configuration item and multiple database configuration parameters, or configuration of the mapping relationship between multiple external configuration items and one database configuration parameter, thereby achieving advanced scalable configuration. A flexible deployment framework is adopted, using highly flexible component assembly to address the need for rapid software deployment across different hardware platforms and computing power levels.

[0083] According to the cross-platform software architecture proposed in this application, the cross-platform software architecture decouples external input differences and vehicle platform differences through the first architecture layer and the third architecture layer to achieve platformization. The second architecture layer integrates internal common logic to build high-level assisted driving dedicated services. The dedicated diagnostic framework design provides functional safety. The flexible scheduling framework provides horizontal extensibility and scalability of the application layer. It is suitable for the development and deployment of intelligent vehicle software systems under complex vehicle models and diverse hardware platforms. It provides a standardized, consistent and efficient secure architecture layer, effectively reducing adaptation costs and testing costs, and minimizing platform migration costs.

[0084] This application also includes a vehicle that incorporates the cross-platform software architecture described in the above embodiments.

[0085] Next, with reference to the accompanying drawings, a control method for a cross-platform software architecture proposed according to an embodiment of this application is described.

[0086] Figure 8 This is a flowchart of a cross-platform software architecture control method according to an embodiment of this application.

[0087] like Figure 8 As shown, the control method for this cross-platform software architecture, applied to the cross-platform software architecture of the above embodiment, includes the following steps:

[0088] In step S101, the first architecture layer is executed. The first architecture layer interacts with the vehicle and / or hardware platform based on the mapping relationship list to obtain at least one type of vehicle input data and processes the input data into standardized data in the corresponding format according to the type of input data.

[0089] It is understood that the embodiments of this application can execute the first architecture layer, interact with vehicles and / or hardware platforms based on the mapping relationship list, obtain input data and process it into standardized data, realize efficient abstraction and adaptation from input data of multiple vehicle models and multiple platforms to unified format output, and provide data consistency, platform flexibility and scalability for the entire system.

[0090] In step S102, the second architecture layer is executed. The second architecture layer is used to provide communication services, scheduling services, diagnostic services, and configuration services. The communication services include intra-domain communication services and extra-domain communication services. The upper-layer application communicates with the cross-platform software architecture through the intra-domain communication service and provides standardized data to the upper-layer application. The vehicle and / or hardware platform communicates with the cross-platform software architecture through the extra-domain communication service and provides scheduling services and / or diagnostic services for at least one vehicle model based on the standardized data.

[0091] It is understood that the embodiments of this application can execute the second architecture layer, and through a unified service framework such as communication, scheduling, diagnosis, and configuration, it realizes the efficient flow of standardized data and the unified control of task scheduling, fault diagnosis, and configuration management, providing stable, efficient, and scalable service support for upper-layer applications.

[0092] In step S103, the third architecture layer is executed. The third architecture layer is used to call the configuration service to provide configuration writing and configuration reading functions for the upper layer application, obtain the configuration instructions of the upper layer application or diagnostic service, and modify the configuration file of the vehicle and / or hardware platform using the configuration instructions. The configuration file is used to configure the mapping relationship list.

[0093] It is understood that the embodiments of this application can execute a third architecture layer, implement configuration writing and reading functions by calling configuration services, and dynamically modify configuration files based on instructions from upper-layer applications or diagnostic services. This achieves unified configuration management of key system behaviors such as mapping relationship lists, scheduling strategies, communication parameters, and diagnostic rules, providing a standardized, consistent, efficient, and secure architecture layer.

[0094] It should be noted that this application establishes a mapping table for internal and external data mapping relationships in the platform adaptation layer by setting up a platform adaptation layer, service framework layer, configuration service layer, flexibly configuring application deployment, and setting up a functional safety diagnostic framework; establishes the business successor relationship and data dependency relationship of algorithm application components; determines the mapping relationship between vehicle configuration and algorithm configuration; determines the platform resource threshold and the actual resource overhead of application components; and determines the mapping relationship between diagnostic signals and processing signals. Thus, in a hardware platform with centralized computing power, the scheduling service framework completely combines components with the same functions into a large process, achieving better end-to-end latency and lower communication overhead. It uses a unique diagnostic acquisition ID across platforms and vehicle models for cross-platform adaptation, achieving one code for one fault and one code for one measure.

[0095] The cross-platform software architecture control method proposed in this application decouples external input differences and vehicle platform differences through the first and third architecture layers to achieve platformization. It integrates internal common logic through the second architecture layer to build high-level assisted driving dedicated services. It provides functional safety through a dedicated diagnostic framework design and provides horizontal extensibility and scalability of the application layer through a flexible scheduling framework. It is suitable for the development and deployment of intelligent vehicle software systems under complex vehicle models and diverse hardware platforms. It provides a standardized, consistent, efficient and secure architecture layer, effectively reducing adaptation and testing costs and minimizing platform migration costs.

[0096] In this application, "multiple" refers to two or more.

[0097] In this application, unless otherwise expressly defined, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0098] The terms “first,” “second,” “third,” “fourth,” etc., in this application (if present) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0099] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0100] Unless otherwise specified, all steps in this application may be performed sequentially or randomly. For example, if the method includes steps A and B, it means that the method may include steps A and B performed sequentially, or it may include steps B and A performed sequentially. For example, if the method may also include step C, it means that step C may be added to the method in any order. For example, the method may include steps A, B, and C, or it may include steps A, C, and B, or it may include steps C, A, and B, etc.

[0101] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A cross-platform software architecture, characterized in that, include: The first architecture layer interacts with the vehicle and / or hardware platform based on a mapping relationship list to obtain at least one type of vehicle input data and processes the input data into standardized data in a corresponding format according to the type of the input data. The second architecture layer is used to provide communication services, scheduling services, diagnostic services, and configuration services. The communication services include intra-domain communication services and inter-domain communication services. Upper-layer applications communicate with the cross-platform software architecture through the intra-domain communication services to provide the standardized data to the upper-layer applications. The vehicles and / or the hardware platform communicate with the cross-platform software architecture through the inter-domain communication services to provide the scheduling services and / or diagnostic services for at least one of the vehicle models based on the standardized data. The third architecture layer is used to call the configuration service to provide configuration writing and configuration reading functions for the upper-layer application, obtain the configuration instructions of the upper-layer application or the diagnostic service, and use the configuration instructions to modify the configuration file of the vehicle and / or hardware platform. The configuration file is used to configure the mapping relationship list.

2. The cross-platform software architecture according to claim 1, characterized in that, The second architecture layer includes: a communication service framework, a scheduling service framework, a diagnostic service framework, and a configuration service framework, wherein, The communication service framework provides intra-domain communication services and inter-domain communication services; The diagnostic service framework extracts vehicle identifiers, fault identifiers, and diagnostic events from the standardized data, and uses a pre-configured diagnostic template to process the vehicle identifiers, fault identifiers, and diagnostic events to obtain fault diagnosis results. The scheduling service framework is used to select the corresponding scheduling method, configuration item and plugin combination according to at least one of the configuration file, scheduling kernel and application plugin, so as to realize task scheduling of different vehicles and / or hardware platforms according to the scheduling method, configuration item and plugin combination. The configuration service framework is used to configure instructions to modify the configuration files of the vehicle and / or hardware platform.

3. The cross-platform software architecture according to claim 2, characterized in that, The intra-domain communication service includes communication services within heterogeneous hardware cores and communication services between heterogeneous cores; the extra-domain communication service includes data transceiver services for external devices. The heterogeneous inter-core communication service provides data publishing and subscription ports to the upper-layer application through cross-core technology stack; The heterogeneous kernel communication service provides a process data channel within the heterogeneous kernel through a memory channel. The extraterritorial communication service provides data transmission and reception services for vehicles and / or hardware platforms through network protocols.

4. The cross-platform software architecture according to claim 2, characterized in that, The scheduling service framework is configured with scheduling modes and process combination deployment modes. The process combination deployment mode is used to assemble multiple application plugins into at least one process instance. The scheduling modes of the configuration items include: time-based scheduling mode and event-based scheduling mode. The time scheduling mode is used to trigger tasks according to a predetermined time. The event scheduling mode is used to trigger tasks based on data relationships.

5. The cross-platform software architecture according to claim 2, characterized in that, The diagnostic service framework includes a data acquisition layer and a data aggregation layer, wherein... The acquisition layer is used to encapsulate diagnostic functions into diagnostic templates, and to implement data diagnostic functions using the diagnostic templates. The aggregation layer is used to manage the mapping relationship between fault identifiers and diagnostic events using configuration files, so as to perform corresponding add, modify and delete operations on the configuration files according to diagnostic needs.

6. The cross-platform software architecture according to claim 1, characterized in that, The input data includes vehicle protocol data, map data, image data, and network data. The first architecture layer includes: a CAN service sublayer, a map service sublayer, an image service sublayer, and a network service sublayer. The CAN service sublayer is used to convert the vehicle protocol data into standardized data that meets the CAN service requirements. The map service sublayer is used to convert the map data into standardized data that meets the map service requirements. The image service sublayer is used to convert the image data into standardized data that meets the requirements of the image service. The network service sublayer is used to convert the network data into standardized data that meets the requirements of network services.

7. The cross-platform software architecture according to claim 6, characterized in that, Each sub-layer of the first architecture layer is built on a communication service framework.

8. The cross-platform software architecture according to claim 1, characterized in that, The third architecture layer includes a configuration mapping plugin, wherein the configuration mapping plugin configures the mapping relationship list based on the configuration file.

9. A vehicle, characterized in that, Including the cross-platform software architecture as described in any one of claims 1-8.

10. A control method for a cross-platform software architecture, characterized in that, The method is applied to the cross-platform software architecture according to any one of claims 1-8, wherein the method includes the following steps: The first architecture layer is executed. The first architecture layer interacts with the vehicle and / or hardware platform based on the mapping relationship list to obtain at least one type of vehicle input data and processes the input data into standardized data in the corresponding format according to the type of the input data. A second architecture layer is executed, which provides communication services, scheduling services, diagnostic services, and configuration services. The communication services include intra-domain communication services and inter-domain communication services. Upper-layer applications communicate with the cross-platform software architecture through the intra-domain communication services to provide the standardized data to the upper-layer applications. The vehicles and / or the hardware platform communicate with the cross-platform software architecture through the inter-domain communication services to provide the scheduling services and / or diagnostic services for at least one of the vehicle models based on the standardized data. The third architecture layer is executed, which is used to call the configuration service to provide configuration writing and configuration reading functions for the upper layer application, obtain the configuration instructions of the upper layer application or the diagnostic service, and use the configuration instructions to modify the configuration file of the vehicle and / or hardware platform, the configuration file being used to configure the mapping relationship list.

Images