A method and apparatus for integrating third-party algorithm components based on dual-core collaboration

Abstract

This invention relates to the field of computer technology, specifically to a method and apparatus for integrating third-party algorithm components based on dual-core collaboration. This application directly integrates third-party algorithm components into the BCM dual-core MCU, eliminating reliance on ZCU and CAN bus communication. This fundamentally eliminates the latency and security overhead caused by cross-ECU transmission and E2E protection, improving signal real-time performance and communication security. By clearly defining the functions and allocating resources of the BCM dual-core, a dedicated storage area is planned for the third-party algorithm components, and a standardized integration environment is built, achieving efficient and stable component integration. Simultaneously, peripheral access strategies are optimized, unnecessary protections and redundant polling are disabled, releasing idle computing power and hardware resources of the BCM and improving utilization. Without increasing the ZCU hardware cost, the chassis braking algorithm is deployed and executed locally, reducing performance losses caused by cross-domain communication and effectively improving the overall system operating efficiency and resource utilization efficiency.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to a method and apparatus for integrating third-party algorithm components based on dual-core collaboration. Background Technology

[0002] Currently, although vehicle domain controllers utilize dual-core microcontroller designs, the lack of an effective coordination mechanism between the two cores prevents the efficient integration of relevant third-party algorithm components directly into the body controller. These components still rely on the domain controller for overall processing. In particular, algorithm components highly related to chassis braking, such as intelligent driving agent, tire blowout algorithm, indirect tire pressure monitoring, continuous damping control, and anti-American stop-and-go functionality, are typically integrated into the Zone Control Unit (ZCU). These components require frequent communication with the Body Control Module (BCM) via the Controller Area Network (CAN) bus. Furthermore, to meet functional safety requirements, an E2E protection mechanism is necessary. This results in signal links that cannot achieve the same level of security and real-time performance as the interaction between software components within the same Electronic Control Unit (ECU). Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a method and apparatus for integrating third-party algorithm components based on dual-core collaboration, in order to solve the problems of insufficient real-time performance and security of existing chassis braking-related algorithm components that rely on ZCU and communicate with BCM via CAN bus, and the underutilization of BCM resources after E2E protection.

[0004] In a first aspect, embodiments of the present invention provide a method for integrating third-party algorithm components based on dual-core collaboration, the method comprising: The resource allocation of the dual-core microcontroller in the body controller is obtained. The dual-core microcontroller includes a first microcontroller and a second microcontroller. The first microcontroller is equipped with communication and management functions of an open automotive system architecture, and the second microcontroller is equipped with underlying hardware control functions for sensors and actuators. Using the resource allocation information, specify the corresponding storage area for the third-party algorithm components to be integrated, and build an integration preparation environment based on the storage area; In the integrated preparation environment, the third-party algorithm components are standardized and configured to obtain the component integration environment. In the component integration environment, the peripheral access strategy of the body controller is optimized and unnecessary protection and redundant polling of the body controller are turned off to obtain the operating computing power released by the body controller.

[0005] Furthermore, the step of using the resource allocation information to specify corresponding storage areas for the third-party algorithm components to be integrated includes: Based on the resource allocation, determine the storage capacity that can be provided to the third-party algorithm component; The memory resource distribution of the dual-core microcontroller is filtered using the storage capacity to obtain candidate storage areas that can be allocated to third-party algorithm components, and the idle status and access efficiency of the candidate storage areas are obtained. Using the idle state and the access efficiency, a storage region suitable for the component's storage capacity is selected from the candidate storage regions.

[0006] Furthermore, the step of building an integration preparation environment based on the storage area includes: The component resources of the third-party algorithm component are allocated to the storage area for partitioned storage, thereby obtaining the storage environment of the third-party algorithm component; The variables of the third-party algorithm component are configured into a specified memory segment in the storage environment to obtain the integration preparation environment.

[0007] Furthermore, in the integration preparation environment, the third-party algorithm components are standardized and configured to obtain a component integration environment, including: In the integrated preparation environment, a corresponding proxy component is configured for the third-party algorithm component; Establish standardized interaction interfaces between the proxy component and each service layer of the vehicle body controller to obtain an integrated environment for third-party algorithm components with unified interfaces.

[0008] Furthermore, in the component integration environment, optimizing the peripheral access strategy of the body controller and disabling unnecessary protections and redundant polling of the body controller to obtain the operating computing power released by the body controller includes: In the component integration environment, peripheral access control information of the sensor and the actuator is acquired; The triggering conditions of the peripheral access policy are adjusted using peripheral access control information to obtain optimized triggering conditions; Based on the optimized triggering conditions, unnecessary critical section protection and redundant polling operations related to communication in the body controller are turned off to obtain a lightweight operating configuration. The operating load is reduced by the lightweight operating configuration, thereby obtaining the operating computing power released by the vehicle body controller.

[0009] Furthermore, the step of adjusting the triggering conditions of the peripheral access policy using peripheral access control information to obtain optimized triggering conditions includes: Extract the access requirements and trigger thresholds from the peripheral access control information; The necessary and unnecessary access scenarios are filtered out using the access requirements and the trigger thresholds. The triggering conditions for peripheral access are adjusted using the necessary access scenarios and the non-necessary access scenarios respectively, so as to achieve peripheral access only in necessary scenarios.

[0010] Furthermore, after obtaining the computing power released by the vehicle body controller, the method further includes: Obtain the vehicle's real-time driving conditions and the real-time computing power requirements of the third-party algorithm components. The driving scenario of the vehicle is determined by using the real-time driving conditions and the real-time computing power requirements. The system acquires the driving scenario and the computing power, formulates differentiated computing power allocation strategies for the third-party algorithm components, and dynamically schedules the corresponding computing power according to the computing power allocation strategies.

[0011] Furthermore, determining the vehicle's driving scenario using the real-time driving conditions and the real-time computing power requirements includes: The basic driving state of the vehicle is obtained by analyzing the real-time driving conditions. The road condition information of the road segment where the vehicle is located is obtained, and feature fusion is performed based on the road condition information, the basic driving state and the corresponding fusion weights to obtain key scene features; Query the initial driving scenario associated with the key scene features from the scene feature library; Obtain the preset computing power requirement corresponding to the initial driving scenario, and detect whether the real-time computing power requirement matches the preset computing power requirement; If the real-time computing power requirement matches the preset computing power requirement, the initial driving scenario is taken as the driving scenario of the vehicle; or, if the real-time computing power requirement does not match the preset computing power requirement, the fusion weight is reset, feature fusion is performed based on the road condition information and the basic driving state, and the driving scenario of the vehicle is determined based on the key scene features after re-fusion.

[0012] Furthermore, the step of dynamically scheduling the corresponding computing power according to the computing power allocation strategy includes: Obtain the total remaining computing power for the vehicle's operation; Based on the total remaining computing power, the computing power allocation quota for each third-party algorithm component is broken down to obtain the target computing power value for each third-party algorithm component; The actual computing power currently used by each third-party algorithm component is collected, and the actual computing power used is compared with the target computing power value to obtain the computing power scheduling difference. Based on the difference in computing power scheduling, adjust the resource allocation ratio and execute scheduling operations according to the adjusted resource allocation ratio.

[0013] Secondly, embodiments of the present invention provide a third-party algorithm component integration device based on dual-core collaboration, the device comprising: The acquisition module is used to acquire the resource allocation of the dual-core microcontroller in the body controller. The dual-core microcontroller includes a first microcontroller and a second microcontroller. The first microcontroller is equipped with communication and management functions of an open automotive system architecture, and the second microcontroller is equipped with underlying hardware control functions for sensors and actuators. The building module is used to specify the corresponding storage area for the third-party algorithm components to be integrated based on the resource allocation, and to build an integration preparation environment based on the storage area; An optimization module is used to standardize the configuration of the third-party algorithm components in the integration preparation environment to obtain a component integration environment. In the component integration environment, the module optimizes the peripheral access strategy of the body controller and disables unnecessary protection and redundant polling of the body controller to obtain the operating computing power released by the body controller.

[0014] Thirdly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in the first aspect or any corresponding embodiment thereof.

[0015] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions that cause a computer to perform the method described in the first aspect or any of its corresponding embodiments.

[0016] This application directly integrates third-party algorithm components into the BCM dual-core MCU, eliminating reliance on ZCU and CAN bus communication. This fundamentally eliminates the latency and security overhead caused by cross-ECU transmission and E2E protection, significantly improving signal real-time performance and communication security. By clearly defining the functions and allocating resources of the BCM dual-core, a dedicated storage area is planned for the third-party algorithm components, and a standardized integration environment is built, achieving efficient and stable integration of components. Simultaneously, peripheral access strategies are optimized, unnecessary protections and redundant polling are disabled, releasing idle computing power and hardware resources of the BCM and improving utilization. Without increasing the ZCU hardware cost, the chassis braking algorithm is deployed and executed locally, reducing performance losses caused by cross-domain communication and effectively improving the overall system operating efficiency and resource utilization efficiency. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating a method for integrating third-party algorithm components based on dual-core collaboration according to some embodiments of the present invention. Figure 2 This is a schematic diagram of a dual-core microcontroller according to some embodiments of the present invention; Figure 3 This is a flowchart illustrating the AUTOSAR architecture according to some embodiments of the present invention; Figure 4 This is a flowchart illustrating a method for integrating third-party algorithm components based on dual-core collaboration according to some embodiments of the present invention. Figure 5 This is a structural block diagram of a third-party algorithm component integration device based on dual-core collaboration according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] According to embodiments of the present invention, a method and apparatus for integrating third-party algorithm components based on dual-core collaboration are provided. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0021] This embodiment provides a method for integrating third-party algorithm components based on dual-core collaboration. Figure 1 This is a flowchart of a third-party algorithm component integration method based on dual-core collaboration according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: Obtain the resource allocation of the dual-core microcontroller in the body controller. The dual-core microcontroller includes a first microcontroller and a second microcontroller. The first microcontroller is equipped with communication and management functions of an open automotive system architecture, and the second microcontroller is equipped with underlying hardware control functions for sensors and actuators.

[0022] In this embodiment of the application, the overall resources of the dual-core microcontroller in the body controller are comprehensively scanned and analyzed to clarify the core information such as the computing power limit of the first microcontroller and the second microcontroller, the total amount and available space of storage resources (ROM, RAM), interrupt priority allocation, and interface resource support, and to establish a complete resource list.

[0023] The functional deployment boundaries of the two microcontrollers were clarified, and the open automotive system architecture-related functions deployed on the first microcontroller were confirmed, including the triggering mechanism and execution process of the software upgrade module, the adaptation parameters of various communication protocols (CAN, Ethernet, etc.), the response logic of the diagnostic service, the node configuration of network management, and the reserved interfaces for third-party software integration. At the same time, the details of the underlying hardware control functions deployed on the second microcontroller were clarified, covering the data acquisition cycle and signal filtering method of various sensors (such as pressure sensors and temperature sensors), the drive logic of actuators (such as brake solenoid valves and relays), the acquisition and calculation methods of feedback signals, and the computing power consumption of the underlying control functions.

[0024] Based on this, the communication link and coordination mechanism between the dual-core microcontrollers were verified to confirm the specific parameters for real-time data interaction between the two through interrupts and Global RAM, including interrupt triggering conditions, interrupt response priority, shared memory address allocation, data read / write permission settings, and data synchronization mechanism. This ensures that the data transmission latency and data accuracy between the first and second microcontrollers meet the requirements for subsequent integration of third-party algorithm components.

[0025] At the same time, the remaining computing power, idle storage resources, and interface redundancy of the two microcontrollers are statistically analyzed to clarify the upper limit of resources that third-party algorithm components can occupy, providing accurate resource data support for subsequent storage area specification and integration environment construction, and avoiding resource conflicts or waste.

[0026] It should be noted that the role of an open automotive system architecture (such as the AUTOSAR architecture) is to achieve standardized and efficient collaborative communication within the body controller, between the body controller and other electronic control units (ECUs) and peripherals in the vehicle, while also managing various resources of the first microcontroller and adapting to the integration needs of third-party algorithm components. Its communication functions specifically include standardized data transmission, interaction, and forwarding based on bus protocols such as CAN, LIN, and automotive Ethernet, covering command issuance, status feedback, and data synchronization. This ensures stable, low-latency, and compatible communication between the first microcontroller and the second microcontroller, sensors, actuators, and other vehicle systems, adhering to standardized interface specifications of open architectures to achieve hardware and software decoupling and cross-module reuse. Its management functions mainly include real-time monitoring and dynamic allocation of the computing and storage resources of the first microcontroller, status monitoring, fault diagnosis and fault tolerance handling of communication links, and functional collaborative scheduling with the second microcontroller. Simultaneously, it provides standardized communication interfaces and resource management support for third-party algorithm components to be integrated, ensuring seamless adaptation of the integrated components to the existing body controller system and guaranteeing the overall stability, reliability, and scalability of the body controller.

[0027] Step S102: Using the resource allocation information, specify the corresponding storage area for the third-party algorithm component to be integrated, and build the integration preparation environment based on the storage area.

[0028] In this embodiment of the application, the corresponding storage area is specified for the third-party algorithm component to be integrated, taking advantage of the resource allocation situation, including the following steps A1-A3: Step A1: Determine the storage capacity that can be provided to third-party algorithm components based on resource allocation.

[0029] Specifically, the complete resource allocation list of the dual-core microcontroller is retrieved to clarify the total ROM and RAM storage capacity of the first and second microcontrollers, as well as the storage usage of deployed functional modules (such as AUTOSAR system communication management functions and sensor and actuator low-level control functions). This includes the ROM and RAM address range, storage size, and usage ratio of each functional module's library files, global variables, calibration variables, etc. For the first microcontroller, the focus is on calculating the storage resources already occupied by AUTOSAR system software upgrades, communication, diagnostics, network management, and algorithm logic control functions, especially the current occupancy status of the reserved area for third-party software integration. For the second microcontroller, the focus is on calculating the storage usage of low-level functions such as sensor data acquisition and actuator drive control, confirming whether there are reusable or idle storage resources available for allocation to third-party algorithm components.

[0030] Based on this, and considering the number, type, and functional requirements of the third-party algorithm components to be integrated, the required ROM and RAM storage capacity for each component is estimated. This includes the size of the compiled and packaged library file, the space occupied by custom global variables and calibration variables, the ROM storage required for variables that need to be initialized during the initialization phase, and the storage requirements for dynamic data during component operation. By comprehensively considering the total storage capacity of the dual-core microcontroller, the occupied storage capacity, the reserved storage space, and the estimated storage requirements of the third-party components, precise calculations determine the total ROM and RAM storage capacity available for the third-party algorithm components. This clarifies the storage quota that each of the two microcontrollers can allocate to the third-party components, while reserving a certain amount of storage redundancy to avoid insufficient storage resources during subsequent component operation, ensuring the rationality and sufficiency of storage capacity allocation.

[0031] Step A2: Filter the memory resource distribution of the dual-core microcontroller using storage capacity to obtain candidate storage areas that can be allocated to third-party algorithm components, and obtain the idle status and access efficiency of the candidate storage areas.

[0032] Specifically, based on the determined storage capacity available for third-party algorithm components, a comprehensive screening of the memory resource distribution of the dual-core microcontroller was conducted. First, the overall ROM and RAM distribution architecture of the two microcontrollers was analyzed, clarifying the partitioning rules of memory resources, the functional positioning of each partition (such as the system core area, application area, and third-party component dedicated area), and the address range. Storage areas that were occupied by the system core functions and low-level control functions and could not be reused were excluded. The focus was on screening out unoccupied and flexibly allocable free storage areas as candidate storage areas that could be allocated to third-party algorithm components.

[0033] For each of the selected candidate storage regions, specific parameters are obtained, with a focus on collecting information related to idle status and access efficiency. Obtaining idle status requires precise statistics on the idle storage size and address contiguousness of each candidate region to confirm the existence of fragmented storage. This ensures that the idle capacity of the candidate regions matches the storage requirements of third-party components, and that address contiguousness facilitates link syntax specification and component loading. Access efficiency testing involves evaluating the read / write speed, data transfer latency, and compatibility with third-party algorithm components for each candidate region. This includes the read efficiency when loading component library files and the response speed when reading and writing variables. Furthermore, the access priority of candidate regions is analyzed in conjunction with the microcontroller's memory architecture to avoid impacting the performance of third-party components due to excessively low access efficiency. Additionally, key information such as access permission settings and whether the ROMCOPY attribute is supported for each candidate storage region must be recorded.

[0034] Step A3: Filter the candidate storage regions to select storage regions that match the component's storage capacity using idle status and access efficiency.

[0035] Specifically, the free storage size of each candidate storage area is compared with the storage capacity of the third-party algorithm component. Candidate areas with free capacity greater than or equal to the estimated storage capacity of the component and with continuous and unfragmented addresses are selected first. Areas with insufficient free capacity, severe address fragmentation, or inability to meet the storage needs of the component are excluded to ensure that the selected storage areas can fully accommodate all storage needs of the third-party component's library files, variables, etc.

[0036] Based on this, the initially selected candidate storage regions are ranked by access efficiency, prioritizing those with high access efficiency, fast read / write speeds, and low data transmission latency. Simultaneously, access permissions and compatibility are considered, ensuring that the region supports the link syntax specification and ROMCOPY attribute settings required by third-party components, and that access permissions meet the read / write requirements of the components, preventing component malfunctions due to insufficient access permissions or compatibility issues. For multiple candidate regions that meet the storage capacity and access efficiency requirements, the computing power allocation of the dual-core microcontroller is further considered. Third-party algorithm components are prioritized for allocation to candidate regions of microcontrollers with relatively sufficient computing power, achieving coordinated matching of storage and computing resources. Furthermore, the storage addresses of the selected storage regions are re-verified to ensure the uniqueness and security of storage region allocation, and the storage region with the best storage capacity, optimal access efficiency, and highest compatibility for the third-party algorithm components is ultimately selected.

[0037] In this embodiment of the application, building an integration preparation environment based on a storage area includes: allocating the component resources of a third-party algorithm component to a storage area for partitioned storage to obtain a storage environment for the third-party algorithm component; configuring the variables of the third-party algorithm component to a specified memory segment in the storage environment to obtain an integration preparation environment.

[0038] Based on the established storage regions, partitioned storage configuration is performed according to the resource types of third-party algorithm components. For compiled and packaged library file resources, they are allocated to dedicated ROM partitions using the link syntax. Different third-party components are stored sequentially in a fixed order to ensure that library file storage addresses do not overlap or conflict. For global variable resources that require initial constant values ​​during the initialization phase, they are allocated to a dedicated ROM region with the ROMCOPY attribute to complete the binding configuration of storage attributes, ensuring that variable initialization and assignment operations can be automatically completed during system startup. For runtime data resources such as global variables and calibration variables, they are allocated to dedicated RAM partitions to achieve physical isolation of data resources of different components. The address mapping and storage binding of various component resources are completed according to statically specified rules throughout the process. The ROM and RAM resource usage of each component is monitored in real time to form an independent, controllable, and monitorable storage environment for third-party algorithm components. This ensures that all component resources are read and written only within the designated areas, preventing out-of-bounds access and resource interference, while providing clear data for subsequent integration debugging and resource optimization.

[0039] During the partitioned storage execution process, the memory architecture of the dual-core microcontroller and the AUTOSAR system storage specifications are strictly followed. The storage address, space size, and access permissions of each type of component resource are finely configured. The storage area verification and locking operations are completed simultaneously to verify the address continuity, space sufficiency, and attribute configuration validity of the ROM partition and RAM partition. This ensures that operations such as library file loading, variable assignment, and data reading and writing can be executed stably. The storage paths of all third-party components are solidified through static partitioning rules to avoid abnormal issues such as address offset and resource overwriting during operation. Finally, a standardized storage environment that adapts to the operation requirements of the BCM system and meets the operation characteristics of third-party components is formed. This environment can support parallel storage and independent operation of multiple components, while meeting the system's core requirements for resource management, fault isolation, and performance monitoring.

[0040] Based on the existing storage environment of third-party algorithm components, the variable sets corresponding to each component are extracted, including all variable types such as global variables, calibration variables, and initialization variables. According to the partitioning rules predefined in the link file, the variables of different third-party algorithm components are precisely configured into the allocated specified RAM and ROM segments. For different components such as i-TPMS, VDSW, and BMXS, a one-to-one mapping between variables and dedicated memory segments is achieved to ensure that the variables of each component are stored independently and do not interfere with each other. During the configuration process, the storage address specification is strictly followed to complete the segment declaration, address binding, and attribute configuration of variables. The segment mapping relationship in the link configuration file is updated synchronously to ensure that the variable access path and storage area are completely matched, meeting the variable calling requirements during system initialization and operation.

[0041] After configuring the specified memory segments for all third-party component variables, the integration environment is validated and optimized. This involves verifying the accuracy of variable configuration, the validity of address mapping, and the stability of resource access. It also includes checking whether variable initialization and runtime read / write operations are performed correctly, and verifying memory segment resource usage to ensure there are no issues such as space overflow or address conflicts. Based on the validation results, configuration parameters are fine-tuned to further improve the reliability and compatibility of the storage environment. The result is a standardized preparation environment that can be directly used for the integration of third-party algorithm components. This environment features variable isolation, resource controllability, and interface adaptation, supporting subsequent agent component deployment, communication interaction configuration, and system function integration testing.

[0042] Step S103: Standardize the configuration of third-party algorithm components in the integration preparation environment to obtain the component integration environment. In the component integration environment, optimize the peripheral access strategy of the body controller and disable unnecessary protection and redundant polling of the body controller to obtain the operating computing power released by the body controller.

[0043] In this embodiment of the application, in the integration preparation environment, the third-party algorithm components are standardized and configured to obtain the component integration environment, including: in the integration preparation environment, configuring corresponding proxy components for the third-party algorithm components; establishing standardized interaction interfaces between the proxy components and each service layer of the body controller to obtain an integration environment for third-party algorithm components with unified interfaces.

[0044] Specifically, based on the established integration preparation environment and following the AUTOSAR system architecture specifications, a dedicated proxy component is configured for each third-party algorithm component to be integrated, ensuring a one-to-one correspondence between the proxy component and the third-party algorithm component. For example, an iTPMS_Proxy proxy component is configured for the i-TPMS component, a VDSW_Proxy proxy component for the VDSW component, and a BMXS_Proxy proxy component for the BMXS component. During configuration, the proxy component is bound to the corresponding third-party algorithm component, clarifying the communication protocol and data interaction rules between them. The proxy component acts as an intermediary between the third-party algorithm component and various modules within the BCM system, responsible for receiving interaction requests from the third-party component, forwarding data signals, and handling basic operations such as data format conversion and signal verification during the interaction process. Simultaneously, the runtime resources of the proxy component are allocated to a designated storage area in the integration preparation environment, ensuring that the storage addresses of the proxy component and the third-party algorithm component are independent and do not interfere with each other. The startup priority of the proxy component is configured synchronously to maintain consistency with the startup sequence of the third-party algorithm component, ensuring that the third-party component can immediately interact with the system through the proxy component after startup, avoiding interaction delays or startup anomalies.

[0045] Understandable, such as Figure 2As shown, the AUTOSAR system architecture presents a top-down view of software layering and functional module deployment. The bottom layer is the MCU hardware layer, which drives the MCAL microcontroller abstraction layer upwards. This is then achieved through basic software layers such as SYS, MEM, DIAG, and COM, and the RTE runtime environment, enabling decoupling and communication between software modules. In the functional layer, core chassis braking algorithms such as AEB, AVH, VDC, and ABS, as well as VDSW, iTPMS, BMXS, and their corresponding proxy components, are directly integrated into the upper-layer application modules. They interact with the lower-layer software layer through the RTE and are ultimately executed by the MCU hardware.

[0046] After the proxy component is configured, a comprehensive verification of the binding validity between the proxy component and the third-party algorithm component is performed. Various interaction requests from the third-party component are simulated to test whether the proxy component can accurately receive and forward request signals, verifying the accuracy and real-time performance of data interaction, and identifying potential issues such as signal loss and formatting errors during the binding process. Simultaneously, a dedicated fault monitoring mechanism is configured for the proxy component. When the proxy component experiences operational anomalies or interaction failures, fault information can be promptly reported to facilitate subsequent troubleshooting and repair. Through the above configuration and verification, it is ensured that each third-party algorithm component can effectively interact with the BCM system through the dedicated proxy component, laying the foundation for subsequent standardized interface configuration. This also achieves isolation between the third-party algorithm component and the internal modules of the BCM system, reducing interference from third-party components to the core functions of the system.

[0047] Based on the layered architecture of the AUTOSAR system, the functional boundaries and interaction protocols of each service layer of the body controller (SYS system service layer, DIAG diagnostic service layer, MEM storage service layer, and COM communication layer) are clearly defined. For each type of proxy component, a standardized interaction interface is established between it and each service layer, ensuring that the interface format, parameters, and interaction process are uniformly standardized, thus achieving interface standardization and reusability. For the interface between the proxy component and the COM communication layer, parameters such as signal transmission format, data verification rules, and transmission rate are configured according to the CAN bus communication protocol and E2E processing specifications. This ensures that the signal interaction between third-party algorithm components and other ECUs on the CAN bus through the proxy component, as well as the processing of E2E functions, can all be completed directly through the COM communication layer of the BCM software via this standardized interface, guaranteeing the accuracy and reliability of signal transmission and reception.

[0048] For the interfaces between the proxy component and the SYS system service layer, DIAG diagnostic service layer, and MEM storage service layer, the calling methods, request parameters, and response formats are defined according to the service specifications of each service layer. It is clarified that when a third-party algorithm component needs to schedule services, it initiates a scheduling request through the standardized interface between the proxy component and the SYS system service layer; when fault diagnosis is needed, it submits diagnostic requests and receives diagnostic results through the standardized interface between the proxy component and the DIAG diagnostic service layer; and when fault and log information needs to be stored, it completes data storage and retrieval operations through the standardized interface between the proxy component and the MEM storage service layer. After the interfaces are established, joint debugging tests are performed on all standardized interfaces to verify their compatibility, stability, and interaction efficiency. Potential issues such as response delays, parameter mismatches, and data loss during interface calls are investigated. Interface parameters are optimized based on the test results to ensure smooth and efficient interaction between the proxy component and each service layer.

[0049] Ultimately, a unified, standardized, stable, and reliable third-party algorithm component integration environment is formed. This environment can support standardized interaction between third-party components and various service layers of the BCM system, while also enabling interface reuse and reducing the cost of subsequent third-party component integration and maintenance.

[0050] In this embodiment of the application, in a component integration environment, optimizing the peripheral access strategy of the body controller and disabling unnecessary protections and redundant polling of the body controller to obtain the operating computing power released by the body controller includes the following steps B1-B4: Step B1: In the component integration environment, obtain peripheral access control information for sensors and actuators.

[0051] Specifically, within a unified third-party algorithm component integration environment, comprehensive information related to peripheral access by sensors and actuators is retrieved. The focus is on collecting peripheral access protocol types (SPI / IIC, etc.), access addresses, current access trigger mechanisms, polling cycles, critical section protection configurations, and interaction link parameters between peripherals and the MCU dual-core. Detailed data acquisition trigger conditions, data transmission formats, and feedback signal types for various sensors (such as pressure and temperature sensors), as well as drive control commands, status feedback acquisition methods, and access permission settings for actuators (such as brake solenoid valves and relays), are obtained to clarify the access process and control logic for each peripheral. Simultaneously, key parameters such as CPU utilization, interrupt trigger frequency, and data transmission latency during the current peripheral access process are recorded. The resource consumption relationship between peripheral access and the operation of third-party algorithm components is analyzed, identifying potential issues such as redundant operations, invalid polling, and over-protection in the current peripheral access control. This forms a complete peripheral access control information list, providing precise data support for subsequent access strategy optimization and ensuring that subsequent adjustments accurately match the peripheral operating characteristics and system computing power requirements.

[0052] Further verify the accuracy and completeness of peripheral access control information, compare it with the functional deployment boundaries of the dual-core MCU, confirm whether the peripheral access control permissions related to sensors and actuators are all deployed on the second microcontroller, verify the compatibility of peripheral access control information with the dual-core communication mechanism (interrupt plus shared memory), and investigate potential issues such as missing parameters, data errors, and link mismatches during information acquisition. Simultaneously, statistically analyze the access frequency of various peripherals and the CPU usage time for each access, analyze the proportion of system computing power consumed by different peripheral accesses, and identify which peripheral access operations result in wasted computing power and which critical section protections are unnecessary configurations.

[0053] Step B2: Adjust the triggering conditions of the peripheral access policy using peripheral access control information to obtain optimized triggering conditions.

[0054] In this embodiment of the application, the triggering conditions of the peripheral access policy are adjusted using peripheral access control information to obtain optimized triggering conditions. This includes: extracting access requirements and triggering thresholds from the peripheral access control information; using access requirements and triggering thresholds to filter out necessary access scenarios and unnecessary access scenarios; and adjusting the triggering conditions of peripheral access using the necessary access scenarios and unnecessary access scenarios respectively to obtain adjusted triggering conditions, so as to enable peripheral access to be triggered only in necessary scenarios.

[0055] Step B3: Based on the optimized triggering conditions, disable unnecessary critical section protection and redundant polling operations related to communication in the body controller to obtain a lightweight operating configuration.

[0056] Specifically, based on the optimized triggering conditions, a comprehensive review of all communication-related critical section protection configurations and polling operations in the body controller was conducted. This clarified which critical section protections were unnecessary and which polling operations were redundant. The focus was on investigating critical section protections related to CAN communication and SPI / IIC communication, distinguishing the boundaries between necessary and unnecessary critical section protections. Critical section protections involving core system functions, data security, and critical peripheral control were retained. For unnecessary critical section protections that do not require additional protection after integration with third-party algorithm components and do not affect system stability, the shutdown operation was directly performed to reduce the frequency of CPU interrupt suspension and reduce the computational power consumption of interrupt handling.

[0057] The polling operations of sensor and actuator peripherals are optimized synchronously. Based on the optimized trigger conditions, all unnecessary redundant polling operations are shut down, including meaningless polling at fixed intervals and invalid polling that does not meet the trigger conditions. Only necessary polling based on actual needs is retained. That is, peripheral access and polling processing of protocols such as SPI / IIC are only performed when the trigger conditions are met. In unnecessary cases, related communication access and polling operations are completely stopped. In the process of shutting down unnecessary critical section protection and redundant polling operations, the AUTOSAR system architecture specifications and MCU dual-core operation rules are strictly followed to ensure that the shutdown operation will not affect the normal operation of the core system functions and will not cause abnormal problems such as data loss or peripheral malfunction. The system's operating parameters are recorded synchronously after the shutdown operation to verify the effectiveness of the shutdown operation, and finally a lightweight operating configuration is formed.

[0058] Step B4: Reduce the operating load according to the lightweight operation configuration to obtain the operating computing power released by the vehicle body controller.

[0059] Based on the obtained lightweight operating configuration, comprehensive measures were taken to reduce the system's operating load. The focus was on optimizing the computing power allocation of the dual-core MCU. Computing power released after disabling unnecessary critical section protection and eliminating redundant polling operations was prioritized for allocation to third-party algorithm components. Simultaneously, the computing power load distribution between the two cores was rationally adjusted to ensure a balanced computing power load between the first microcontroller (deploying AUTOSAR system communication management and third-party component integration) and the second microcontroller (deploying peripheral low-level control), avoiding overload on any single core. By monitoring the system's operating status in real time and statistically analyzing key parameters such as CPU utilization, interrupt suspension frequency, and computing power consumption ratio before and after the lightweight configuration was implemented, the load reduction effect was compared and analyzed to ensure that each lightweight measure effectively reduced computing power waste.

[0060] Further optimization of the operational process, combined with a dual-core communication mechanism (interrupt plus shared memory), adjusts the timing and frequency of data interaction to reduce unnecessary data interaction between the two cores and lower computational power consumption during data transmission. Simultaneously, based on the computational power requirements of third-party algorithm components, dynamically adjusts the resource allocation of the system service layer, prioritizing the computational power resources required for the operation of third-party components and avoiding excessive redundant computational power consumption by the system's own services. Continuous monitoring of system operational stability and computational power release is conducted to investigate potential anomalies during lightweight configuration execution, such as peripheral access latency and abnormal data interaction, and timely fine-tuning of configuration parameters to ensure that while reducing the operational load, the normal function of the body controller, the stable operation of third-party algorithm components, and the reliable operation of sensors and actuators are not affected. Finally, through a series of load optimization operations, the operational computational power released by the body controller is obtained.

[0061] like Figure 3As shown, the first microcontroller deploys AUTOSAR basic software upgrades, communication management, and application-layer algorithm control functions, responsible for system-level communication and management. The second microcontroller undertakes low-level hardware control functions such as sensor data acquisition, computation, and actuator drive control. The two cores achieve shared data read / write interaction through Global RAM and work collaboratively based on an interrupt notification mechanism. This solution, based on dual-core resource allocation, plans dedicated storage areas for third-party algorithm components and builds a standardized integration environment. Simultaneously, it optimizes peripheral access strategies, disables unnecessary protection and redundant polling, fully releases the computing power of the BCM, and achieves efficient integration and localized operation of third-party algorithm components within the BCM.

[0062] In this embodiment of the application, after obtaining the computing power released by the vehicle body controller, as follows: Figure 4 As shown, the method also includes: Step S201: Obtain the real-time driving conditions of the vehicle and the real-time computing power requirements of the third-party algorithm components.

[0063] In this embodiment, various operating parameters during vehicle operation are collected in real time, including vehicle speed, braking frequency, steering angle, acceleration, road condition information (such as smooth road surface, bumpy road surface, and slope), tire pressure status, and braking system operating status. Real-time transmission and collection of various operating parameters are achieved through communication links such as the sensor interface of the body controller and CAN bus, ensuring the continuity and accuracy of data collection. The sampling period is synchronized with the computing power calculation period of the third-party algorithm component to avoid data delay or loss.

[0064] Simultaneously, the system monitors the operational status of all integrated third-party algorithm components in real time, collects real-time computing power requirement parameters for each component, including the current computing workload, data processing rate, peak computing power usage, computing power requirement fluctuation range, and computing power requirement change trend during component operation. It clarifies the differences in computing power requirements of different components at different times, distinguishes between core and non-core computing power requirements, and records the priority of computing power requirements for each component.

[0065] The collected real-time driving condition data and the real-time computing power requirements of third-party algorithm components undergo preliminary processing to filter invalid and abnormal data, and to appropriately supplement missing data, ensuring data integrity and reliability. Simultaneously, a data correlation analysis mechanism is established to clarify the correspondence between real-time driving conditions and the computing power requirements of third-party algorithm components. For example, when the vehicle brakes frequently, the computing power requirements of braking-related third-party components increase significantly; when the vehicle is traveling at a constant speed, the computing power requirements tend to stabilize. The total operating computing power, allocated computing power, and idle computing power of the current vehicle controller are simultaneously statistically analyzed.

[0066] Step S202: Determine the vehicle's driving scenario by utilizing real-time driving conditions and real-time computing power requirements.

[0067] In this embodiment of the application, the vehicle's driving scenario is determined by utilizing real-time driving conditions and real-time computing power requirements, including the following steps A1-A5: Step A1: Analyze real-time driving conditions to obtain the vehicle's basic driving status.

[0068] Specifically, the system first collects core operating parameters during vehicle operation in real time through onboard sensors, the OBD interface, and the vehicle control system. These parameters include, but are not limited to, real-time vehicle speed, steering angle, brake trigger frequency, throttle opening, engine speed, driving duration, and gear changes. The collection frequency is set to 10Hz to ensure the real-time nature and continuity of the data. After collection, the raw data is preprocessed using a Kalman filter algorithm to remove abnormal and redundant data caused by sensor errors, road surface disturbances, and other factors, retaining only the valid operating parameters.

[0069] Subsequently, based on the preset driving state determination threshold, the preprocessed operating condition parameters are subjected to feature extraction and classification recognition. For example, when the vehicle speed is stable within ±5km / h and lasts for more than 3 seconds, it is determined to be constant speed driving; when the throttle opening is greater than 60% and the vehicle speed increase rate exceeds 10km / h / s, it is determined to be accelerating driving; when the braking trigger frequency is greater than 2 times / minute and the vehicle speed decrease rate exceeds 8km / h / s, it is determined to be decelerating driving. Finally, the basic driving state of the vehicle is output.

[0070] Step A2: Obtain road condition information of the road segment where the vehicle is located, and perform feature fusion based on road condition information, basic driving status and corresponding fusion weights to obtain key scene features.

[0071] Specifically, through the vehicle navigation system, roadside units (RSUs), and real-time traffic data interfaces, detailed road condition information of the current road segment of the vehicle is obtained synchronously, including road type (expressway, urban expressway, urban ordinary road, rural road), traffic congestion level (smooth, slow, congested), road environment (sunny day, rainy day, snowy day, night, inside tunnel), road curvature, and intersection density, etc., to ensure the comprehensiveness and timeliness of road condition information.

[0072] Simultaneously, the vehicle's basic driving status is retrieved, and combined with preset fusion weights (where road condition information is weighted at 0.6 and basic driving status at 0.4, these weights are trained based on historical scene recognition data to ensure the accuracy of feature fusion), a weighted fusion algorithm is used to fuse road condition information and basic driving status features. During the fusion process, various features are standardized, transforming parameters of different dimensions into a unified standard, and then a comprehensive feature value is calculated based on the fusion weights. Finally, a four-dimensional key scene feature containing "road type - congestion level - basic driving status - road environment" is output.

[0073] Step A3: Query the initial driving scenario associated with key scene features from the scene feature library.

[0074] Specifically, firstly, the scene feature library pre-stores various standard driving scenarios and their corresponding standard feature thresholds. The standard scenarios include high-speed uniform and smooth traffic scenarios, urban road congestion and deceleration scenarios, and rural road turning and driving scenarios. Each standard scenario corresponds to a unique set of scene feature thresholds, which are calibrated based on a large amount of historical driving data and algorithm training results, and can cover the vast majority of vehicle driving scenarios.

[0075] During the query process, the output key scene features are input into the scene matching model. The K-Nearest Neighbors (KNN) algorithm is used to compare the key scene features with the feature thresholds of all standard scenes in the scene feature library, calculating the Euclidean distance between them. The smaller the distance, the higher the similarity. A similarity threshold of 85% is set, and standard scenes with similarity no lower than this threshold are selected as candidate initial driving scenes. If multiple candidate scenes exist, the scene with the smallest Euclidean distance and the highest matching degree with the key scene features is selected as the initial driving scene. If no scene meets the similarity standard, a scene query anomaly message is output.

[0076] Step A4: Obtain the preset computing power requirements corresponding to the initial driving scenario, and check whether the real-time computing power requirements match the preset computing power requirements.

[0077] Specifically, firstly, the preset computing power requirement corresponding to the initial driving scenario is retrieved. This preset computing power requirement is not a fixed value, but rather a range that includes an upper limit, a lower limit, and a baseline value. The baseline value is the typical computing power consumption value of the third-party algorithm component in this scenario, while the upper and lower limits are the allowable reasonable fluctuation range. The preset computing power requirement is based on the computing power consumption data of the third-party algorithm component in similar historical scenarios, and is obtained through statistical analysis and machine learning model training, which can adapt to changes in computing power requirements under different scenarios.

[0078] Subsequently, the real-time computing power requirements of the third-party algorithm component are obtained. This requirement is collected in real time through the computing power monitoring module of the algorithm component, and the collection frequency is consistent with the operating data collection frequency to ensure data synchronization. Finally, the real-time computing power requirements are compared with the preset computing power requirement range, and the deviation rate between the real-time computing power requirements and the benchmark value is calculated. If the deviation rate is ≤15% and the real-time computing power requirements are within the preset range, the two are considered to match; if the deviation rate is >15% or the real-time computing power requirements exceed the preset range, the two are considered to be mismatched.

[0079] Step A5: If the real-time computing power requirement matches the preset computing power requirement, the initial driving scenario is taken as the vehicle's driving scenario; or, if the real-time computing power requirement does not match the preset computing power requirement, the fusion weights are reset, feature fusion is performed based on road condition information and basic driving status, and the vehicle's driving scenario is determined based on the key scenario features after re-fusion.

[0080] Specifically, if the real-time computing power requirement is detected to match the preset computing power requirement, i.e., the deviation rate is ≤15% and the real-time computing power requirement is within the preset range, it means that the initial driving scenario can accurately reflect the current actual driving state of the vehicle. At this time, the initial driving scenario is directly used as the final driving scenario of the vehicle, and the scenario information is synchronized to the computing power allocation module to provide a scenario basis for subsequent computing power scheduling.

[0081] If a mismatch is detected, i.e., the deviation rate is greater than 15% or the real-time computing power requirement exceeds the preset range, it indicates a deviation between the initial driving scenario and the vehicle's actual driving state. The main reason for this deviation is unreasonable feature fusion weights leading to key scenario feature bias. In this case, the feature fusion weights are reset. Based on the vehicle's current real-time driving conditions and road conditions, the original fusion weights are adjusted using a gradient descent algorithm. After adjustment, feature fusion is performed again based on road conditions and the basic driving state to obtain re-fused key scenario features. Subsequently, the re-fused key scenario features are input into the scene feature library for querying to determine a new initial driving scenario. The matching and detection process is repeated until the real-time computing power requirement matches the preset computing power requirement of the new initial scenario, ultimately determining the vehicle's driving scenario.

[0082] Step S203: Obtain the driving scenario and computing power, formulate differentiated computing power allocation strategies for third-party algorithm components, and dynamically schedule the corresponding computing power according to the computing power allocation strategies.

[0083] In this embodiment of the application, the corresponding computing power is dynamically scheduled according to the computing power allocation strategy, including steps B1-B4: Step B1: Obtain the total remaining computing power for the vehicle's operation.

[0084] Specifically, the vehicle's onboard computing power management module collects the total supply of vehicle computing power resources in real time. This total supply is determined by the rated computing power of the vehicle's computing power chip. At the same time, combined with parameters such as the chip's current operating temperature and load rate, the actual available total computing power of the computing power chip is calculated.

[0085] Subsequently, the total computing power consumption of all built-in systems and deployed third-party algorithm components in the vehicle is collected in real time. This includes the computing power consumption of core systems such as the in-vehicle entertainment system, the autonomous driving assistance system, and the body control system, as well as the real-time computing power usage of each third-party algorithm component. The collection frequency is set to 5Hz to ensure data real-time performance. Finally, the total remaining computing power of the vehicle is calculated by subtracting the current total computing power consumption from the total computing power supply. The calculation results are verified to remove outliers caused by data collection errors, and the accurate total remaining computing power is output.

[0086] Step B2: Based on the total remaining computing power, break down the computing power allocation quota of each third-party algorithm component to obtain the target computing power value of each third-party algorithm component.

[0087] Specifically, the system obtains the total remaining computing power for vehicle operation and retrieves the established differentiated computing power allocation strategy. This strategy is based on the current driving scenario of the vehicle, the priority of each third-party algorithm component (e.g., autonomous driving algorithms have a higher priority than entertainment algorithms), and the urgency of computing power requirements. It clarifies the computing power allocation ratio and minimum guaranteed computing power for each algorithm component.

[0088] Subsequently, based on the allocation ratio in the computing power allocation strategy and combined with the total remaining computing power, the total remaining power is broken down to prioritize the computing power needs of high-priority algorithm components. For example, the allocation ratio for autonomous driving algorithm components is set at 40%, and the allocation ratio for entertainment algorithm components is set at 20%. During the breakdown process, if the allocation amount for a certain algorithm component is lower than its minimum guaranteed computing power, the allocation ratio is adjusted to ensure the basic computing power needs of that component. After the breakdown is completed, the target computing power value for each third-party algorithm component is calculated, and the target computing power value that should be allocated to each third-party algorithm component is determined.

[0089] Step B3: Collect the current actual computing power occupied by each third-party algorithm component, and compare the actual computing power occupied with the target computing power value to obtain the computing power scheduling difference.

[0090] Specifically, the actual computing power used by each third-party algorithm component is collected in real time through its built-in computing power monitoring unit. The collected data includes the component's instantaneous computing power usage, average computing power usage, and computing power fluctuations. The collection frequency is consistent with the total computing power reserve collection frequency to ensure data synchronization. After collection, the actual computing power usage data is preprocessed to remove instantaneous outliers caused by component operation fluctuations, retaining valid data.

[0091] Subsequently, the target computing power values ​​of each third-party algorithm component are retrieved. The actual computing power used by each component is compared with the corresponding target computing power value, and the difference between the two is calculated, which is the computing power scheduling difference. If the actual computing power used is lower than the target computing power value, the scheduling difference is positive, indicating that the computing power supply of the component is insufficient; if the actual computing power used is higher than the target computing power value, the scheduling difference is negative, indicating that the computing power supply of the component is excessive. Finally, the computing power scheduling difference value of each third-party algorithm component is output.

[0092] Step B4: Adjust the resource allocation ratio according to the computing power scheduling difference, and execute the scheduling operation according to the adjusted resource allocation ratio.

[0093] Specifically, the computational power scheduling difference of each third-party algorithm component is obtained. The scheduling differences of all components are then summarized and analyzed to determine the overall supply and demand of computational resources. If the summarized difference is positive, it indicates an overall insufficient supply of computational power, requiring priority to be given to ensuring the computational power needs of high-priority components. If the summarized difference is negative, it indicates an overall surplus of computational power, allowing for an appropriate reduction in the computational power allocation to some low-priority components. Subsequently, based on the magnitude of the scheduling difference and component priority, the computational power resource allocation ratio of each third-party algorithm component is adjusted. For components with insufficient computational power, corresponding computational power is allocated from components with surplus computational power or from the total remaining computational power to ensure they reach their target computational power value. For components with surplus computational power, their computational power allocation ratio is reduced, releasing excess computational power to the total remaining computational power.

[0094] After the adjustment is completed, the adjusted resource allocation ratio is sent to the vehicle computing power scheduling module, which then performs computing power scheduling operations to adjust the computing power occupancy of each algorithm component in real time. After the scheduling is completed, the actual computing power occupied by each component is collected again to verify whether the target computing power value has been reached. If it has not been reached, the above adjustment process is repeated until the actual computing power occupied by all components is consistent with the target computing power value, thus completing the dynamic scheduling of the running computing power.

[0095] This embodiment also provides a third-party algorithm component integration device based on dual-core collaboration. This device is used to implement the above embodiments and preferred embodiments, and details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0096] This embodiment provides a third-party algorithm component integration device based on dual-core collaboration, such as... Figure 5 As shown, it includes: The acquisition module 501 is used to acquire the resource allocation of the dual-core microcontroller in the body controller. The dual-core microcontroller includes a first microcontroller and a second microcontroller. The first microcontroller is deployed with communication and management functions of an open automotive system architecture, and the second microcontroller is deployed with underlying hardware control functions of sensors and actuators. Module 502 is used to specify the corresponding storage area for the third-party algorithm components to be integrated based on the resource allocation, and to build the integration preparation environment based on the storage area; The optimization module 503 is used to standardize the configuration of third-party algorithm components in the integration preparation environment to obtain the component integration environment. In the component integration environment, the peripheral access strategy of the body controller is optimized and unnecessary protection and redundant polling of the body controller are turned off to obtain the operating computing power released by the body controller.

[0097] In this embodiment of the application, the construction module 502 is specifically used to determine the storage capacity that can be provided to the third-party algorithm component based on the resource allocation; to filter the memory resource distribution of the dual-core microcontroller using the storage capacity to obtain candidate storage areas that can be allocated to the third-party algorithm component, and to obtain the idle status and access efficiency of the candidate storage areas; and to filter out the storage area that matches the storage capacity of the component from the candidate storage areas using the idle status and access efficiency.

[0098] In this embodiment of the application, the construction module 502 is specifically used to allocate the component resources of the third-party algorithm component to the storage area for partitioned storage, thereby obtaining the storage environment of the third-party algorithm component; and to configure the variables of the third-party algorithm component to a specified memory segment in the storage environment, thereby obtaining the integration preparation environment.

[0099] In this embodiment of the application, the optimization module 503 is specifically used to configure corresponding proxy components for third-party algorithm components in the integration preparation environment; establish standardized interaction interfaces between the proxy components and each service layer of the body controller, and obtain an integration environment for third-party algorithm components with unified interfaces.

[0100] In this embodiment, the optimization module 503 is specifically used to acquire peripheral access control information of sensors and actuators in a component integration environment; adjust the triggering conditions of peripheral access strategy using the peripheral access control information to obtain optimized triggering conditions; disable unnecessary critical section protection and redundant polling operations related to communication in the body controller according to the optimized triggering conditions to obtain a lightweight operation configuration; reduce the operating load according to the lightweight operation configuration to obtain the operating computing power released by the body controller.

[0101] In this embodiment, the optimization module 503 is specifically used to extract the access requirements and trigger thresholds from the peripheral access control information; use the access requirements and trigger thresholds to filter out necessary access scenarios and unnecessary access scenarios; and adjust the triggering conditions for peripheral access using the necessary access scenarios and unnecessary access scenarios respectively to obtain the adjusted triggering conditions, so as to achieve peripheral access only in necessary scenarios.

[0102] In this embodiment of the application, the construction module is specifically used to obtain the real-time driving conditions of the vehicle and the real-time computing power requirements of the third-party algorithm components; determine the driving scenario of the vehicle using the real-time driving conditions and real-time computing power requirements; obtain the driving scenario and the operating computing power, formulate differentiated computing power allocation strategies for the third-party algorithm components, and dynamically schedule the corresponding operating computing power according to the computing power allocation strategies.

[0103] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 6 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0104] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0105] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0106] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0107] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include combinations of the above types of memory. The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0108] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0109] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A third-party algorithm component integration method based on dual-core collaboration, characterized in that, The method includes: The resource allocation of the dual-core microcontroller in the body controller is obtained. The dual-core microcontroller includes a first microcontroller and a second microcontroller. The first microcontroller is equipped with communication and management functions of an open automotive system architecture, and the second microcontroller is equipped with underlying hardware control functions for sensors and actuators. Using the resource allocation information, specify the corresponding storage area for the third-party algorithm components to be integrated, and build an integration preparation environment based on the storage area; In the integrated preparation environment, the third-party algorithm components are standardized and configured to obtain the component integration environment. In the component integration environment, the peripheral access strategy of the body controller is optimized and unnecessary protection and redundant polling of the body controller are turned off to obtain the operating computing power released by the body controller.

2. The method of claim 1, wherein, The step of using the resource allocation information to specify corresponding storage areas for the third-party algorithm components to be integrated includes: Based on the resource allocation, determine the storage capacity that can be provided to the third-party algorithm component; The memory resource distribution of the dual-core microcontroller is filtered using the storage capacity to obtain candidate storage areas that can be allocated to third-party algorithm components, and the idle status and access efficiency of the candidate storage areas are obtained. Using the idle state and the access efficiency, a storage region suitable for the component's storage capacity is selected from the candidate storage regions.

3. The method of claim 1, wherein, The construction of the integrated preparation environment based on the storage area includes: The component resources of the third-party algorithm component are allocated to the storage area for partitioned storage, thereby obtaining the storage environment of the third-party algorithm component; The variables of the third-party algorithm component are configured into a specified memory segment in the storage environment to obtain the integration preparation environment.

4. The method of claim 1, wherein, In the integration preparation environment, the third-party algorithm component is standardized and configured to obtain a component integration environment, including: In the integrated preparation environment, a corresponding proxy component is configured for the third-party algorithm component; Establish standardized interaction interfaces between the proxy component and each service layer of the vehicle body controller to obtain an integrated environment for third-party algorithm components with unified interfaces.

5. The method of claim 1, wherein, In the component integration environment, optimizing the peripheral access strategy of the body controller and disabling unnecessary protections and redundant polling of the body controller yields the freed-up computing power of the body controller, including: In the component integration environment, peripheral access control information of the sensor and the actuator is acquired; The triggering conditions of the peripheral access policy are adjusted using peripheral access control information to obtain optimized triggering conditions; Based on the optimized triggering conditions, unnecessary critical section protection and redundant polling operations related to communication in the body controller are turned off to obtain a lightweight operating configuration. The operating load is reduced by optimizing the lightweight operating configuration, thereby increasing the operating computing power released by the vehicle body controller.

6. The method of claim 5, wherein, The step of adjusting the triggering conditions of the peripheral access policy using peripheral access control information to obtain optimized triggering conditions includes: Extract the access requirements and trigger thresholds from the peripheral access control information; The necessary and unnecessary access scenarios are filtered out using the access requirements and the trigger thresholds. The triggering conditions for peripheral access are adjusted using the necessary access scenarios and the non-necessary access scenarios respectively, so as to achieve peripheral access only in necessary scenarios.

7. The method of claim 1, wherein, After obtaining the computing power released by the vehicle body controller, the method further includes: Obtain the vehicle's real-time driving conditions and the real-time computing power requirements of the third-party algorithm components. The driving scenario of the vehicle is determined by using the real-time driving conditions and the real-time computing power requirements. The system acquires the driving scenario and the computing power, formulates differentiated computing power allocation strategies for the third-party algorithm components, and dynamically schedules the corresponding computing power according to the computing power allocation strategies.

8. The method of claim 7, wherein, Determining the vehicle's driving scenario using the real-time driving conditions and the real-time computing power requirements includes: The basic driving state of the vehicle is obtained by analyzing the real-time driving conditions. The road condition information of the road segment where the vehicle is located is obtained, and feature fusion is performed based on the road condition information, the basic driving state and the corresponding fusion weights to obtain key scene features; Query the initial driving scenario associated with the key scene features from the scene feature library; Obtain the preset computing power requirement corresponding to the initial driving scenario, and detect whether the real-time computing power requirement matches the preset computing power requirement; If the real-time computing power requirement matches the preset computing power requirement, the initial driving scenario is taken as the driving scenario of the vehicle; or, if the real-time computing power requirement does not match the preset computing power requirement, the fusion weight is reset, feature fusion is performed based on the road condition information and the basic driving state, and the driving scenario of the vehicle is determined based on the key scene features after re-fusion.

9. The method of claim 7, wherein, The dynamic scheduling of corresponding computing power according to the computing power allocation strategy includes: Obtain the total remaining computing power for the vehicle's operation; Based on the total remaining computing power, the computing power allocation quota for each third-party algorithm component is broken down to obtain the target computing power value for each third-party algorithm component; The actual computing power currently used by each third-party algorithm component is collected, and the actual computing power used is compared with the target computing power value to obtain the computing power scheduling difference. Based on the difference in computing power scheduling, adjust the resource allocation ratio and execute scheduling operations according to the adjusted resource allocation ratio.

10. A dual-core collaboration based third-party algorithm component integration apparatus, comprising: The device includes: The acquisition module is used to acquire the resource allocation of the dual-core microcontroller in the body controller. The dual-core microcontroller includes a first microcontroller and a second microcontroller. The first microcontroller is equipped with communication and management functions of an open automotive system architecture, and the second microcontroller is equipped with underlying hardware control functions for sensors and actuators. The building module is used to specify the corresponding storage area for the third-party algorithm components to be integrated based on the resource allocation, and to build an integration preparation environment based on the storage area; An optimization module is used to standardize the configuration of the third-party algorithm components in the integration preparation environment to obtain a component integration environment. In the component integration environment, the module optimizes the peripheral access strategy of the body controller and disables unnecessary protection and redundant polling of the body controller to obtain the operating computing power released by the body controller.

Images