Vehicle-based cross-domain computing power dynamic borrowing method and device, vehicle and medium

Abstract

This application provides a method, apparatus, vehicle, and medium for dynamic cross-domain computing power borrowing based on a vehicle. The method includes: obtaining information on the vehicle's driving scenario and the computing power information of the cockpit domain controller and intelligent driving domain controller, which meets preset cross-domain computing power borrowing trigger conditions; then determining the identifier of the borrowing controller, the identifier of the lending controller, the available computing power, and a borrowing duration threshold based on the driving scenario and computing power information. Based on the identifier of the borrowing controller, a securely isolated temporary virtual machine instance is created for the computing power task to be executed by the borrowing controller; based on the identifier of the lending controller, a hardware-isolated cross-domain computing power borrowing channel is established between the temporary virtual machine instance and the lending controller via the MPU / SMMU, so that the borrowing controller can use the idle computing power of the lending controller through the cross-domain computing power borrowing channel within the borrowing duration threshold. This method aims to achieve a balance between improving SoC utilization and ensuring vehicle functional safety.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a method, device, vehicle, and medium for dynamic cross-domain computing power borrowing based on vehicles. Background Technology

[0002] The electronic and electrical architecture of intelligent vehicles is rapidly evolving towards a centralized domain architecture centered around domain controllers (DCs). The Cockpit Domain Controller (CDC) primarily supports high-computing, highly interactive in-vehicle applications such as multimedia entertainment, intelligent voice control, in-vehicle navigation, and edge-side large-scale model inference; while the Intelligent Driving Domain Controller primarily supports core real-time and high-safety driving functions such as environmental perception, target detection, path planning, and vehicle control.

[0003] Currently, to improve the overall computing resource utilization of the vehicle, existing technologies are based on automotive-grade virtualization technology. Independent virtual machine instances are deployed for the cockpit domain and the intelligent driving domain, and computing resource quotas are statically allocated between the two domains. To meet ASIL-level requirements, the high-security intelligent driving domain is secured with minimum computing power, dedicated physical memory, and peripheral access permissions. Idle computing power from both domains is then uniformly incorporated into a global shared resource pool. During vehicle operation, real-time data such as computing load and memory usage in both domains are collected at fixed intervals. Idle computing power in the shared pool is dynamically allocated based on preset functional priority rules, enabling elastic borrowing and collaborative scheduling of cross-domain computing power. Simultaneously, cross-domain access security boundaries are constructed using MMU / SMMU and virtualization layer permission control, prohibiting unauthorized access to core intelligent driving resources from the cockpit domain, thus achieving basic security isolation between the two domains.

[0004] However, existing technologies cannot simultaneously improve SoC utilization and ensure vehicle safety in scenarios involving cross-domain computing power sharing between the cabin and driver. Summary of the Invention

[0005] This application provides a method, apparatus, vehicle, and medium for dynamic cross-domain computing power borrowing based on vehicles, in order to achieve the technical effect of balancing improved computing power SoC utilization and driving function safety assurance.

[0006] In a first aspect, embodiments of this application provide a method for dynamic cross-domain computing power borrowing based on vehicles, including:

[0007] Obtain the vehicle's driving scenario and the computing power information of the cockpit domain controller and intelligent driving domain controller;

[0008] If the driving scenario and the computing power information meet the preset cross-domain computing power borrowing trigger conditions, then the identifier of the borrowing controller, the identifier of the lending controller, the available computing power, and the borrowing duration threshold are determined according to the driving scenario and the computing power information. The borrowing controller is the domain controller in the cockpit domain controller and the intelligent driving domain controller that has a computing power demand gap, and the lending controller is the domain controller in the cockpit domain controller and the intelligent driving domain controller that has idle available computing power.

[0009] Based on the identifier of the borrowing controller, a securely isolated temporary virtual machine instance is created for the computing power task to be executed by the borrowing controller;

[0010] Based on the identifier of the lending controller, a hardware-isolated cross-domain computing power borrowing channel is established between the temporary virtual machine instance and the lending controller via the MPU / SMMU, so that the borrowing controller can use the idle computing power of the lending controller through the cross-domain computing power borrowing channel within the borrowing duration threshold.

[0011] In one possible implementation, establishing a hardware-isolated cross-domain computing power borrowing channel between the temporary virtual machine instance and the lending controller via the MPU / SMMU, based on the identifier of the lending controller, includes:

[0012] Based on the identifier of the lending controller, the memory area corresponding to the available computing power is divided into isolated memory partitions in the lending controller by the MPU / SMMU.

[0013] The isolated memory partition is mapped to the computing resources of the temporary virtual machine instance, and the isolated memory partition is configured to allow the borrowing controller to access memory within the borrowing duration threshold.

[0014] Establish a cross-domain computing power borrowing channel between the temporary virtual machine instance and the lending controller.

[0015] In one possible implementation, the preset cross-domain computing power borrowing trigger condition includes at least one of the following:

[0016] The driving scenario is a parking scenario, and the SoC utilization rate of the cockpit domain controller is lower than the first utilization threshold, the SoC utilization rate of the intelligent driving domain controller is higher than the second utilization threshold, and the chip junction temperature of the cockpit domain controller is lower than the first temperature threshold.

[0017] The driving scenario is an urban driving scenario, and the SoC utilization rate of the intelligent driving domain controller is lower than the third utilization threshold, the SoC utilization rate of the cockpit domain controller is higher than the fourth utilization threshold, and the chip junction temperature of the intelligent driving domain controller is lower than the second temperature threshold.

[0018] Wherein, the first utilization threshold is less than the second utilization threshold, the third utilization threshold is less than the fourth utilization threshold, and the SoC utilization rate and the chip junction temperature belong to the computing power information.

[0019] In one possible implementation, obtaining the vehicle's driving scenario includes:

[0020] Obtain the vehicle's speed, gear, and position;

[0021] If the speed is less than the first preset speed and the gear is a preset gear, then the driving scenario is determined to be the parking scenario, and the preset gear is P or R.

[0022] If the speed is greater than the second preset speed and the location is in an urban area, then the driving scenario is determined to be an urban driving scenario, and the first preset speed is less than the second preset speed.

[0023] In one possible implementation, determining the identifier of the borrowing controller, the identifier of the lending controller, the available computing power, and the borrowing duration threshold based on the driving scenario and the computing power information includes:

[0024] The identification of the borrowing controller, the identification of the lending controller, and the borrowing duration threshold are determined based on the driving scenario.

[0025] The available computing power of the lending controller is calculated based on the total computing power of the lending controller, the preset maximum lending ratio, the SoC utilization rate, and the computing power required by the borrowing controller.

[0026] In one possible implementation, calculating the available computing power of the lending controller based on the total computing power of the lending controller, the preset maximum lending ratio, the SoC utilization rate, and the required computing power of the borrowing controller includes:

[0027] The initial ratio is determined by subtracting the SoC utilization rate from the maximum lendable ratio.

[0028] The maximum value between the initial ratio and 0 is determined as the target ratio;

[0029] The value obtained by multiplying the total computing power by the target ratio is determined as the maximum available computing power.

[0030] The minimum value between the maximum available computing power and the required computing power is determined as the available computing power.

[0031] In one possible implementation, determining the identifier of the borrowing controller, the identifier of the lending controller, and the borrowing duration threshold based on the driving scenario includes:

[0032] If the driving scenario is the parking scenario, then the identifier of the cockpit domain controller is determined as the identifier of the lending controller, the identifier of the intelligent driving domain controller is determined as the identifier of the borrowing controller, and the preset duration threshold corresponding to the parking scenario is determined as the borrowing duration threshold.

[0033] If the driving scenario is the urban driving scenario, then the identifier of the cockpit domain controller is determined as the identifier of the borrowing controller, the identifier of the intelligent driving domain controller is determined as the identifier of the lending controller, and the preset duration threshold corresponding to the urban driving scenario is determined as the borrowing duration threshold.

[0034] In one possible implementation, the cross-domain computing power borrowing channel is a bidirectional PCIe link, and each frame of data transmitted through the cross-domain computing power borrowing channel is accompanied by a cyclic redundancy check code.

[0035] In one possible implementation, the method further includes:

[0036] If the SoC utilization of the lending controller is detected to exceed the fifth utilization threshold, or the chip junction temperature of the lending controller is higher than the third temperature threshold, a hardware interrupt signal is sent to the temporary virtual machine instance.

[0037] In response to the hardware interrupt signal, the temporary virtual machine instance suspends the current task and releases the resources corresponding to the cross-domain computing power borrowing channel.

[0038] In one possible implementation, the method further includes:

[0039] If it is detected that the borrowed time of the cross-domain computing power borrowing channel exceeds the borrowed time threshold, or if the driving scenario changes, a stop signal is sent to the temporary virtual machine instance.

[0040] In response to the stop signal, the temporary virtual machine instance releases the resources corresponding to the cross-domain computing power borrowing channel after completing the current task.

[0041] In one possible implementation, the Automotive Safety Integrity Level (ASIL) of the temporary virtual machine instance is marked as QM.

[0042] In one possible implementation, if the vehicle further includes other domain controllers besides the cockpit domain controller and the intelligent driving domain controller, then the computing resource scheduling priority of the intelligent driving domain controller is higher than the computing resource scheduling priority of the cockpit domain controller and the computing resource scheduling priority of the other domain controllers.

[0043] Secondly, embodiments of this application provide a vehicle-based cross-domain computing power dynamic borrowing device, comprising:

[0044] The acquisition module is used to acquire the vehicle's driving scenario and the computing power information of the cockpit domain controller and the intelligent driving domain controller;

[0045] The determination module is used to determine the identifier of the borrowing controller, the identifier of the lending controller, the available computing power, and the borrowing duration threshold based on the driving scenario and the computing power information if the driving scenario and the computing power information meet the preset cross-domain computing power borrowing trigger conditions. The borrowing controller is the domain controller in the cockpit domain controller and the intelligent driving domain controller that has a computing power demand gap, and the lending controller is the domain controller in the cockpit domain controller and the intelligent driving domain controller that has idle computing power available for lending.

[0046] A creation module is used to create a securely isolated temporary virtual machine instance for the computing power task to be executed by the borrowing controller, based on the identifier of the borrowing controller;

[0047] A module is established to establish a hardware-isolated cross-domain computing power borrowing channel between the temporary virtual machine instance and the lending controller based on the identifier of the lending controller, via the MPU / SMMU, so that the borrowing controller can use the idle computing power of the lending controller through the cross-domain computing power borrowing channel within the borrowing duration threshold.

[0048] In one possible implementation, the establishment module is specifically used for:

[0049] Based on the identifier of the lending controller, the memory area corresponding to the available computing power is divided into isolated memory partitions in the lending controller by the MPU / SMMU.

[0050] The isolated memory partition is mapped to the computing resources of the temporary virtual machine instance, and the isolated memory partition is configured to allow the borrowing controller to access memory within the borrowing duration threshold.

[0051] Establish a cross-domain computing power borrowing channel between the temporary virtual machine instance and the lending controller.

[0052] In one possible implementation, the preset cross-domain computing power borrowing trigger condition includes at least one of the following:

[0053] The driving scenario is a parking scenario, and the SoC utilization rate of the cockpit domain controller is lower than the first utilization threshold, the SoC utilization rate of the intelligent driving domain controller is higher than the second utilization threshold, and the chip junction temperature of the cockpit domain controller is lower than the first temperature threshold.

[0054] The driving scenario is an urban driving scenario, and the SoC utilization rate of the intelligent driving domain controller is lower than the third utilization threshold, the SoC utilization rate of the cockpit domain controller is higher than the fourth utilization threshold, and the chip junction temperature of the intelligent driving domain controller is lower than the second temperature threshold.

[0055] Wherein, the first utilization threshold is less than the second utilization threshold, the third utilization threshold is less than the fourth utilization threshold, and the SoC utilization rate and the chip junction temperature belong to the computing power information.

[0056] In one possible implementation, the acquisition module is specifically used for:

[0057] Obtain the vehicle's speed, gear, and position;

[0058] If the speed is less than the first preset speed and the gear is a preset gear, then the driving scenario is determined to be the parking scenario, and the preset gear is P or R.

[0059] If the speed is greater than the second preset speed and the location is in an urban area, then the driving scenario is determined to be an urban driving scenario, and the first preset speed is less than the second preset speed.

[0060] In one possible implementation, the determining module is specifically used for:

[0061] The identification of the borrowing controller, the identification of the lending controller, and the borrowing duration threshold are determined based on the driving scenario.

[0062] The available computing power of the lending controller is calculated based on the total computing power of the lending controller, the preset maximum lending ratio, the SoC utilization rate, and the computing power required by the borrowing controller.

[0063] In one possible implementation, the determining module is specifically used for:

[0064] The initial ratio is determined by subtracting the SoC utilization rate from the maximum lendable ratio.

[0065] The maximum value between the initial ratio and 0 is determined as the target ratio;

[0066] The value obtained by multiplying the total computing power by the target ratio is determined as the maximum available computing power.

[0067] The minimum value between the maximum available computing power and the required computing power is determined as the available computing power.

[0068] In one possible implementation, the determining module is specifically used for:

[0069] If the driving scenario is the parking scenario, then the identifier of the cockpit domain controller is determined as the identifier of the lending controller, the identifier of the intelligent driving domain controller is determined as the identifier of the borrowing controller, and the preset duration threshold corresponding to the parking scenario is determined as the borrowing duration threshold.

[0070] If the driving scenario is the urban driving scenario, then the identifier of the cockpit domain controller is determined as the identifier of the borrowing controller, the identifier of the intelligent driving domain controller is determined as the identifier of the lending controller, and the preset duration threshold corresponding to the urban driving scenario is determined as the borrowing duration threshold.

[0071] In one possible implementation, the cross-domain computing power borrowing channel is a bidirectional PCIe link, and each frame of data transmitted through the cross-domain computing power borrowing channel is accompanied by a cyclic redundancy check code.

[0072] In one possible implementation, the vehicle-based cross-domain computing power dynamic borrowing device further includes an anomaly recovery module, used for:

[0073] If the SoC utilization of the lending controller is detected to exceed the fifth utilization threshold, or the chip junction temperature of the lending controller is higher than the third temperature threshold, a hardware interrupt signal is sent to the temporary virtual machine instance.

[0074] In response to the hardware interrupt signal, the temporary virtual machine instance suspends the current task and releases the resources corresponding to the cross-domain computing power borrowing channel.

[0075] In one possible implementation, the vehicle-based cross-domain computing power dynamic borrowing device further includes a normal recycling module, used for:

[0076] If it is detected that the borrowed time of the cross-domain computing power borrowing channel exceeds the borrowed time threshold, or if the driving scenario changes, a stop signal is sent to the temporary virtual machine instance.

[0077] In response to the stop signal, the temporary virtual machine instance releases the resources corresponding to the cross-domain computing power borrowing channel after completing the current task.

[0078] In one possible implementation, the Automotive Safety Integrity Level (ASIL) of the temporary virtual machine instance is marked as QM.

[0079] In one possible implementation, if the vehicle further includes other domain controllers besides the cockpit domain controller and the intelligent driving domain controller, then the computing resource scheduling priority of the intelligent driving domain controller is higher than the computing resource scheduling priority of the cockpit domain controller and the computing resource scheduling priority of the other domain controllers.

[0080] Thirdly, embodiments of this application provide a vehicle, including: a vehicle body, a memory, a cockpit domain controller, a smart driving domain controller, and a processor;

[0081] The memory stores computer-executed instructions;

[0082] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0083] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0084] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0085] The vehicle-based cross-domain computing power dynamic borrowing method, device, vehicle, and medium provided in this application acquire the vehicle's driving scenario and the computing power information of the cockpit domain controller and intelligent driving domain controller. When preset cross-domain computing power borrowing trigger conditions are met, the borrowing controller, lending controller, available computing power, and borrowing duration thresholds are accurately determined. A securely isolated temporary virtual machine instance is created for the borrowing controller, and a hardware-isolated cross-domain computing power borrowing channel is established through the MPU / SMMU, enabling bidirectional elastic computing power scheduling between the cockpit domain controller and the intelligent driving domain controller. This solution effectively solves the problem of simultaneous idle computing resources and insufficient computing power demand under the traditional static computing power allocation mode, significantly improving the overall utilization rate of vehicle computing resources. Simultaneously, hardware-level isolation ensures the functional safety of computing power borrowing without increasing additional hardware costs, adapting to the computing power scheduling requirements of in-vehicle multi-domain computing platforms. Attached Figure Description

[0086] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0087] Figure 1 A flowchart illustrating the vehicle-based cross-domain computing power dynamic borrowing method provided in this application. Figure 1 ;

[0088] Figure 2 A flowchart illustrating the vehicle-based cross-domain computing power dynamic borrowing method provided in this application. Figure 2 ;

[0089] Figure 3 A flowchart illustrating the vehicle-based cross-domain computing power dynamic borrowing method provided in this application. Figure 3 ;

[0090] Figure 4 A schematic diagram of the vehicle-mounted cockpit driver fusion computing platform provided in this application;

[0091] Figure 5 A flowchart illustrating the vehicle-based cross-domain computing power dynamic borrowing method provided in this application. Figure 4 ;

[0092] Figure 6 A schematic diagram of the structure of the vehicle-based cross-domain computing power dynamic borrowing device provided in this application;

[0093] Figure 7 This is a structural diagram of the vehicle provided in this application.

[0094] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0095] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0096] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0097] First, the application scenarios involved in this application will be explained:

[0098] The electronic and electrical architecture of intelligent vehicles is rapidly evolving towards a domain-centralized architecture centered around domain controllers. The cockpit domain controller primarily supports high-computing, highly interactive in-vehicle applications such as multimedia entertainment, intelligent voice interaction, in-vehicle navigation, and edge-side large-scale model inference. The intelligent driving domain controller, relying on the core capabilities of the Advanced Driving Assistance System (ADAS), primarily supports core driving functions requiring high real-time performance and high safety levels, such as environmental perception, target detection, path planning, and vehicle control. In traditional discrete domain controller architectures, the two domain controllers typically each carry an independent System-on-Chips (SoC) and achieve cross-domain interconnection via a high-speed Peripheral Component Interconnect Express (PCIe) bus or automotive Ethernet.

[0099] During actual vehicle operation, the computing power requirements of the cockpit domain and the intelligent driving domain exhibit time-domain complementary characteristics: In low-speed parking scenarios, most of the front-end interaction and entertainment applications in the cockpit domain are out of active operation, and the SoC utilization rate of the cockpit domain is usually less than 20%, while the SoC utilization rate of the intelligent driving domain can reach more than 80% because it needs to process multiple perception data such as ultrasonic radar and fisheye camera simultaneously; In regular urban driving scenarios, the computing power requirements of the cockpit domain surge significantly due to edge-side large model inference tasks such as intelligent voice interaction and semantic understanding of driving scenarios, while the SoC utilization rate of the intelligent driving domain is often less than 40% under the constant speed driving conditions of urban structured roads.

[0100] The aforementioned temporal complementarity characteristics indicate the potential for computing power sharing and collaborative scheduling between the cockpit and driver domains. To fully leverage the value of computing power collaboration and improve the overall utilization of vehicle computing resources, existing technologies generally use automotive-grade virtualization technology as the basic architecture, deploying independent virtual machine instances for the cockpit and intelligent driving domains respectively, and statically allocating computing resource quotas for both domains. Specifically, for the high-safety intelligent driving domain that meets the Automotive Safety Integrity Level (ASIL) requirements, its basic operating minimum computing power, dedicated physical memory address space, and peripheral access permissions are locked, while unused idle computing power from both domains is uniformly incorporated into a globally shared resource pool.

[0101] During real-time vehicle operation, existing technologies use onboard computing power monitoring modules to collect real-time operational data such as computing load, memory usage, and bus bandwidth utilization in the cockpit and intelligent driving domains at fixed intervals. When either domain experiences a sudden increase in computing load or resource demand, the inter-domain computing power scheduling module dynamically allocates idle computing power from the shared resource pool to the resource demand side based on preset functional priority rules, thereby achieving elastic borrowing and collaborative scheduling of cross-domain computing power. Simultaneously, existing technologies utilize hardware memory management units (MMU) / system memory management units (SMMU) and virtualization layer permission control mechanisms to construct a secure boundary for cross-domain resource access, prohibiting the low-security cockpit domain from directly accessing the core control peripherals, secure island memory, and critical task execution space of the intelligent driving domain, thus achieving basic security isolation and protection between the two domains.

[0102] Due to the fundamental differences in functional safety levels between the cockpit domain and the intelligent driving domain, the cockpit domain's non-safety-related functions such as human-machine interaction and audio-visual entertainment have a low safety level of Quality Management (QM) / Automotive Safety Integrity Level A (ASIL-A), while the intelligent driving domain's core driving functions such as environmental perception, decision-making and planning, and vehicle control need to meet the high safety level requirements of ASIL B-D. Existing technologies, based on software-defined isolation boundaries and computing power scheduling mechanisms, cannot achieve absolute free interference protection under all operating conditions, especially in fault scenarios.

[0103] Specifically, on the one hand, existing computing power quota management technologies are mostly based on soft constraints of the operating system kernel and virtualization layer. When abnormal conditions such as software defects, process dead loops, and memory leaks occur in the cockpit domain, they can easily cause kernel scheduling blockage and scheduling logic failure, thereby breaking through the preset computing power quota limit, seizing the bandwidth and scheduling priority of shared resource pools and even underlying shared hardware resources such as system bus and memory controller, causing uncontrollable interference to the execution sequence of hard real-time tasks in the intelligent driving domain, and causing risks that directly threaten driving safety, such as task execution timeouts and decision delays exceeding the standard. On the other hand, the cross-domain isolation of existing technologies only achieves basic access permission control and does not achieve independent hardware-level isolation boundaries for cross-domain borrowed computing power tasks. Abnormal tasks in the cockpit domain can easily use kernel vulnerabilities and virtualization layer defects to break through the preset access permission boundaries, causing interference to the core operating environment of the intelligent driving domain, and failing to meet the mandatory requirements of ISO 26262 standard for free interference between systems of different security levels.

[0104] In summary, existing technologies cannot simultaneously improve SoC utilization and ensure vehicle safety in scenarios involving cross-domain computing power sharing between the cabin and driver.

[0105] Based on the aforementioned technical problems, the technical concept of this application is as follows: During the research of in-vehicle cross-domain computing power scheduling schemes, the inventors discovered that cockpit domain computing power and intelligent driving domain computing power have significant temporal domain complementarity characteristics. However, directly sharing computing power would bring driving function safety risks, making it difficult to simultaneously achieve SoC utilization improvement and safety assurance. The inventors noted that the core defect of existing software-level scheduling is that isolation boundaries can be breached, while hardware-level isolation mechanisms possess insurmountable security characteristics; simultaneously, an independent temporary operating environment can completely separate borrowed tasks from core tasks. Therefore, the inventors considered first obtaining computing power information from the vehicle driving scenario, cockpit domain, and intelligent driving domain. When it is determined that the preset cross-domain computing power borrowing trigger conditions are met, the borrowing controller, lending controller, available computing power, and borrowing duration threshold are further determined. Then, a securely isolated temporary virtual machine instance is created for the computing power task to be executed by the borrowing controller. A hardware-isolated cross-domain computing power borrowing channel is established between the borrowing controller and the lending controller through the hardware memory protection unit (MPU) / system memory management unit (SMMU), so that the borrowing controller can use the idle computing power of the lending controller within the borrowing duration threshold, thereby balancing SoC utilization and driving safety.

[0106] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0107] Figure 1 A flowchart illustrating the vehicle-based cross-domain computing power dynamic borrowing method provided in this application. Figure 1 ,like Figure 1 As shown, the method includes:

[0108] S11. Obtain the vehicle's driving scenario and the computing power information of the cockpit domain controller and intelligent driving domain controller.

[0109] For example, driving scenarios include urban driving scenarios, parking scenarios, and regular scenarios.

[0110] In one possible implementation, the vehicle's speed, gear, and location can be acquired. The gear includes P, R, D, and N, and the location can be a Global Navigation Satellite System (GNSS) map location, obtained through positioning on a high-precision map using GNSS technology. If the speed is less than a first preset speed and the gear is a preset gear, the driving scenario is determined to be a parking scenario, with the preset gear being P or R. If the speed is greater than a second preset speed and the location is in an urban area, the driving scenario is determined to be an urban driving scenario, with the first preset speed being less than the second preset speed.

[0111] For example, the first preset speed can be 5km / h, 6km / h, 7km / h, etc.; the second preset speed can be 15km / h, 16km / h, 17km / h, etc., which can be preset based on empirical or experimental values. This application embodiment does not impose specific limitations on this.

[0112] It should be understood that other situations are considered standard driving scenarios.

[0113] The above implementation provides an accurate basis for scene judgment for triggering cross-domain computing power borrowing, effectively avoids invalid computing power scheduling caused by scene misidentification, improves the accuracy and reliability of scene judgment, adapts to the computing power scheduling needs of different driving conditions, and ensures the scene adaptability and rationality of cross-domain computing power borrowing.

[0114] Optionally, the computing power information includes the SoC utilization rate and chip junction temperature of the cockpit domain controller and the intelligent driving domain controller. In practical applications, the SoC utilization rate and chip junction temperature of the cockpit domain controller and the intelligent driving domain controller can be collected at certain intervals. This interval can be 100ms, 110ms, or 120ms, etc., and can be preset based on empirical or experimental values. This application embodiment does not impose specific limitations on this.

[0115] S12. If the driving scenario and computing power information meet the preset cross-domain computing power borrowing trigger conditions, then determine the identifier of the borrowing controller, the identifier of the lending controller, the available computing power, and the borrowing duration threshold based on the driving scenario and computing power information.

[0116] Among them, the borrowing controller is the cockpit domain controller and the intelligent driving domain controller that has a computing power demand gap, and the lending controller is the cockpit domain controller and the intelligent driving domain controller that has idle computing power that can be lent out.

[0117] In practical applications, the preset trigger conditions for cross-domain computing power borrowing include at least one of the following:

[0118] 1. The driving scenario is a parking scenario, and the SoC utilization rate of the cockpit domain controller is lower than the first utilization threshold, while the SoC utilization rate of the intelligent driving domain controller is higher than the second utilization threshold, and the chip junction temperature of the cockpit domain controller is lower than the first temperature threshold.

[0119] The first utilization threshold can be 20%, 25%, 30%, etc.; the second utilization threshold can be 70%, 75%, 80%, etc.; the first temperature threshold can be 85°C, 86°C, 87°C, etc., which can be preset based on empirical or experimental values. This application embodiment does not impose specific limitations on this.

[0120] 2. The driving scenario is an urban driving scenario, and the SoC utilization rate of the intelligent driving domain controller is lower than the third utilization threshold, while the SoC utilization rate of the cockpit domain controller is higher than the fourth utilization threshold, and the chip junction temperature of the intelligent driving domain controller is lower than the second temperature threshold.

[0121] Among them, the first utilization threshold is less than the second utilization threshold, the third utilization threshold is less than the fourth utilization threshold, and the SoC utilization rate and chip junction temperature belong to computing power information.

[0122] The third utilization threshold can be 25%, 30%, 35%, etc.; the fourth utilization threshold can be 65%, 70%, 75%, etc.; the second temperature threshold can be 85°C, 86°C, 87°C, etc., which can be preset based on empirical or experimental values. This application embodiment does not impose specific limitations on this.

[0123] The aforementioned preset cross-domain computing power borrowing trigger conditions ensure that cross-domain computing power borrowing is only triggered when the lending controller has sufficient idle computing power, the borrowing controller has a computing power demand gap, and the junction temperature of the lending controller chip meets safety requirements. This effectively avoids invalid computing power borrowing and excessive borrowing, ensures the stable operation of the lending controller's main task, and accurately adapts to the computing power demand characteristics of different driving scenarios. It also improves the rationality and security of cross-domain computing power scheduling, providing reliable triggering logic support for the efficient utilization of the vehicle's computing power resources.

[0124] Among them, the available computing power refers to the maximum computing power that the lending controller can lend to the borrowing controller during this computing power borrowing process; the borrowing duration threshold refers to the maximum duration for which the borrowing controller can borrow the computing power of the lending controller during this computing power borrowing process.

[0125] It should be understood that the specific determination of the borrower controller's identifier, lender controller's identifier, available computing power, and borrowing duration threshold based on the driving scenario and computing power information will be achieved through... Figure 2 The embodiments shown are explained and illustrated, and will not be repeated here.

[0126] S13. Based on the identifier of the borrowing controller, create a securely isolated temporary virtual machine instance for the computing power task to be executed by the borrowing controller.

[0127] The ASIL of the temporary virtual machine instance is marked as QM, which is strictly isolated from the ASIL of the borrowed controller's main virtual machine and does not affect each other. This meets the requirements of the ISO 26262 functional safety standard for multi-domain computing power scheduling, avoids confusion of safety levels and functional safety risks, and improves the functional safety of the vehicle-mounted multi-domain computing platform.

[0128] S14. Based on the identifier of the lending controller, a hardware-isolated cross-domain computing power borrowing channel is established between the temporary virtual machine instance and the lending controller through the MPU / SMMU, so that the borrowing controller can use the idle computing power of the lending controller through the cross-domain computing power borrowing channel within the borrowing duration threshold.

[0129] In one possible implementation, based on the identifier of the lending controller, the memory region corresponding to the available computing power is divided into isolated memory partitions within the lending controller via the MPU / SMMU. These isolated memory partitions are configured to allow only Direct Memory Access (DMA) by the borrowing controller, with a cross-domain computing power borrowing channel establishment latency of ≤10ms. Further, the isolated memory partitions are mapped to the computing resources of temporary virtual machine instances, and the isolated memory partitions are configured to allow memory access by the borrowing controller within a borrowing duration threshold. Finally, a cross-domain computing power borrowing channel is established between the temporary virtual machine instance and the lending controller.

[0130] Optionally, a cross-domain computing power borrowing channel can be directly established between a temporary virtual machine instance and the lending controller. Alternatively, the initial cross-domain computing power borrowing channel can be configured to obtain a configured cross-domain computing power borrowing channel. This initial cross-domain computing power borrowing channel is pre-established based on historical driving trajectories and high-precision maps. Specifically, based on historical driving trajectories and high-precision maps, the driving scenario the vehicle is about to enter is predicted 5-10 minutes in advance. If the driving scenario is a parking scenario or an urban driving scenario, an initial cross-domain computing power borrowing channel is established between the cockpit domain controller and the intelligent driving domain controller. This initial cross-domain computing power borrowing channel only completes the basic PCIe link handshake and initialization, is in an idle state awaiting activation, has not been partitioned into isolated memory partitions, and is not associated with any temporary virtual machine instances. It cannot perform data transmission, does not occupy any available computing power, and poses no security risks.

[0131] This approach achieves hardware-level memory isolation and access control, accurately matches the allocation of available computing power resources, ensures that the borrowing controller can only access the computing power resources of the lending controller within the authorized scope, avoids interference with the lending controller's main tasks, and meets the isolation requirements of vehicle functional safety for multi-domain computing power scheduling, thereby improving the security and reliability of cross-domain computing power borrowing.

[0132] The cross-domain computing power borrowing channel is a bidirectional link based on PCIe. In practical applications, the PCIe channel bandwidth is 16GT / s, the typical data transfer volume for a single inference task is 50-200MB, and the transmission latency is ≤5ms.

[0133] Each frame of data transmitted via the cross-domain computing power borrowing channel is appended with a Cyclic Redundancy Check (CRC) code. This CRC code can be a 32-bit Cyclic Redundancy Check (CRC32) code with a frame error rate of <10⁻ 9 .

[0134] The PCIe-based bidirectional link ensures high-speed, bidirectional data transmission between the cockpit domain controller and the intelligent driving domain controller, meeting the high bandwidth and low latency requirements of cross-domain computing power scheduling in vehicles. At the same time, the cyclic redundancy check code is used to verify data integrity, effectively avoiding data transmission errors and packet loss, improving the communication reliability and stability of cross-domain computing power borrowing, and providing reliable communication link support for dynamic cross-domain computing power borrowing.

[0135] The vehicle-based cross-domain computing power dynamic borrowing method provided in this application obtains the vehicle's driving scenario and the computing power information of the cockpit domain controller and the intelligent driving domain controller. If the driving scenario and computing power information meet preset cross-domain computing power borrowing trigger conditions, the identifier of the borrowing controller, the identifier of the lending controller, the available computing power, and the borrowing duration threshold are determined based on the driving scenario and computing power information. Then, based on the identifier of the borrowing controller, a securely isolated temporary virtual machine instance is created for the computing power task to be executed by the borrowing controller. Finally, based on the identifier of the lending controller, a hardware-isolated cross-domain computing power borrowing channel is established between the temporary virtual machine instance and the lending controller via the MPU / SMMU, so that the borrowing controller can use the idle computing power of the lending controller through the cross-domain computing power borrowing channel within the borrowing duration threshold. Here, the borrowing controller is a domain controller among the cockpit domain controller and the intelligent driving domain controller that has a computing power demand gap, and the lending controller is a domain controller among the cockpit domain controller and the intelligent driving domain controller that has idle available computing power to borrow. This technical solution effectively solves the problem of both idle computing resources and insufficient computing demand under the traditional static computing power allocation mode, significantly improves the utilization rate of global computing power resources of the whole vehicle, and ensures the functional safety of computing power borrowing through hardware-level isolation without adding extra hardware costs, and adapts to the computing power scheduling needs of the vehicle multi-domain computing platform.

[0136] Optionally, in one embodiment, three computing power demand levels can be pre-set: large (30%-40%), medium (15%-30%), and small (less than 15%). For each computing power demand level, a predefined isolation memory partition size, resource quota for temporary virtual machine instances, and cross-domain computing power borrowing channel configuration template are provided.

[0137] For low computing power requirements, temporary virtual machine instances and isolated memory partitions left over from the previous computing power borrowing in the same driving scenario can be reused. Channel activation can be completed by only updating memory access permissions and borrowing duration thresholds, without having to re-execute the complete channel establishment process, which significantly reduces resource consumption.

[0138] For medium to high computing power requirements, the upper limit of the corresponding level should be selected for resource allocation to ensure the performance of the borrowed controller.

[0139] Figure 2 A flowchart illustrating the vehicle-based cross-domain computing power dynamic borrowing method provided in this application. Figure 2 ,like Figure 2 As shown, the step S12, "determining the identifier of the borrowing controller, the identifier of the lending controller, the available computing power, and the borrowing duration threshold based on the driving scenario and computing power information," can be achieved through the following steps:

[0140] S21. Determine the identifier of the borrowed controller, the identifier of the lent controller, and the borrowing duration threshold based on the driving scenario.

[0141] In one possible implementation, if the driving scenario is a parking scenario, then the identifier of the cockpit domain controller is determined as the identifier of the lending controller, the identifier of the intelligent driving domain controller is determined as the identifier of the borrowing controller, and the preset duration threshold corresponding to the parking scenario is determined as the borrowing duration threshold.

[0142] If the driving scenario is an urban driving scenario, then the identifier of the cockpit domain controller will be determined as the identifier of the borrowed controller, the identifier of the intelligent driving domain controller will be determined as the identifier of the lent controller, and the preset duration threshold corresponding to the urban driving scenario will be determined as the borrowing duration threshold.

[0143] The preset time thresholds for parking scenarios and urban driving scenarios are both preset values ​​based on experience or experiments. In practical applications, the preset time thresholds for parking scenarios can be 120s, 130s, 140s, etc.; the preset time thresholds for urban driving scenarios can be 300s, 310s, 320s, etc. This application embodiment does not impose specific limitations on these.

[0144] The above approach enables scenario-based bidirectional computing power scheduling, accurately adapting to the computing power requirements of different driving scenarios. In parking scenarios, it ensures the perception computing power requirements of the intelligent driving domain controller, and in urban driving scenarios, it ensures the computing power requirements of the large model of the cockpit domain controller, significantly improving the overall utilization rate of vehicle computing power resources and adapting to the computing power scheduling requirements of the in-vehicle multi-domain computing platform.

[0145] S22. Calculate the available computing power of the lending controller based on the total computing power of the lending controller, the preset maximum lending ratio, the SoC utilization rate, and the required computing power of the borrowing controller.

[0146] In one possible implementation, the initial ratio is determined by subtracting the SoC utilization rate from the maximum available ratio, and the target ratio is determined by the maximum value between the initial ratio and 0. Then, the maximum available computing power is determined by multiplying the total computing power by the target ratio. Finally, the minimum value between the maximum available computing power and the required computing power is determined as the available computing power.

[0147] The above implementation method not only ensures that the lending controller will not affect the stable operation of its main task due to excessive lending of computing power, but also accurately matches the actual computing power requirements of the borrowing controller, avoids the waste and over-allocation of computing power resources, improves the rationality and security of cross-domain computing power scheduling, and provides reliable computing logic support for dynamic cross-domain computing power borrowing.

[0148] For example, the maximum lendable ratio can be in the range of [30%, 50%], such as 40%, to ensure that the lending controller retains sufficient self-use backup computing power.

[0149] The above embodiments realize scenario-based computing power allocation and precise computing power calculation, which not only ensures that the lending controller retains sufficient self-use computing power, but also accurately matches the computing power demand gap of the borrowing controller, effectively improving the overall computing power resource utilization of the vehicle, avoiding the waste of computing power resources, and adapting to the computing power scheduling needs of different driving scenarios.

[0150] Optionally, in some embodiments, if the SoC utilization of the borrowed controller is detected to exceed a fifth utilization threshold, or the chip junction temperature of the borrowed controller is detected to be higher than a third temperature threshold, a hardware interrupt signal is sent to the temporary virtual machine instance. Subsequently, in response to the hardware interrupt signal, the temporary virtual machine instance suspends its current task and releases the resources corresponding to the cross-domain computing power borrowing channel.

[0151] For example, the fifth utilization threshold can be 80%, 85%, 90%, etc.; the third temperature threshold can be 90°C, 91°C, 92°C, etc., which can be preset based on empirical or experimental values. This application embodiment does not impose specific limitations on this.

[0152] In practical applications, during the computing power borrowing process, the SoC utilization rate and chip junction temperature of the borrowing controller can be continuously monitored at certain intervals. For example, this interval can be 100ms, 110ms, or 120ms, etc., which can be preset based on empirical or experimental values. This application embodiment does not impose specific limitations on this.

[0153] It should be understood that this recovery is an emergency recovery. In practical applications, the timeout for the entire emergency recovery process is guaranteed to be ≤50ms.

[0154] This implementation method provides emergency security for computing power borrowing. When the lending controller experiences insufficient computing power or overheating risks, the borrowed computing power resources can be quickly recovered, ensuring the stable operation of the lending controller's main tasks, avoiding system failures and security risks, meeting the requirements of vehicle functional safety, and improving the security and reliability of cross-domain computing power borrowing.

[0155] Optionally, in some embodiments, if it is detected that the borrowed time of the cross-domain computing power borrowing channel exceeds the borrowed time threshold, or if the driving scenario changes, a stop signal is sent to the temporary virtual machine instance; in response to the stop signal, the temporary virtual machine instance releases the resources corresponding to the cross-domain computing power borrowing channel after completing the current task.

[0156] It should be understood that this recovery is a normal recovery, and the timeout for a normal recovery is guaranteed to be ≤500ms.

[0157] Among them, the driving scenario does not meet the cross-domain computing power borrowing trigger condition when the driving scenario switches from the current scenario to another scenario. For example, if the driving scenario switches from the parking scenario to the urban driving scenario, then the driving scenario is considered not to meet the cross-domain computing power borrowing trigger condition.

[0158] In the above embodiments, releasing the resources corresponding to the cross-domain computing power borrowing channel includes closing the cross-domain computing power borrowing channel, clearing the MPU / SMMU isolation configuration, and releasing the temporary virtual machine instance. After releasing the resources corresponding to the cross-domain computing power borrowing channel, the recovery completion can also be reported and written to the borrowing log. The borrowing log includes the start and end time of this computing power borrowing, the borrowed computing power, and the recovery type, which includes emergency recovery and normal recovery.

[0159] The above embodiments realize the standardized and orderly recycling of computing power borrowing, avoid the leakage and invalid occupation of computing power resources, ensure the reasonable reuse of computing power resources, adapt to the dynamic needs of driving scenario switching, improve the orderliness and reliability of cross-domain computing power scheduling, and provide a complete borrowing and returning process support for cross-domain dynamic computing power borrowing.

[0160] In the above embodiments, the first utilization threshold, the second utilization threshold, the third utilization threshold, the fourth utilization threshold, the fifth utilization threshold, the first temperature threshold, the second temperature threshold, the third temperature threshold, etc., can be updated via OTA. After the update, it will take effect when the preset cross-domain computing power borrowing trigger condition is met next time, without affecting the ongoing computing power borrowing task.

[0161] Optionally, in some embodiments, if the vehicle also includes other domain controllers besides the cockpit domain controller and the intelligent driving domain controller, the computing resource scheduling priority of the intelligent driving domain controller is higher than the computing resource scheduling priority of the cockpit domain controller and the computing resource scheduling priority of other domain controllers.

[0162] For example, other domain controllers include the body domain controller, powertrain domain controller, chassis domain controller, and thermal management domain controller. Among them, the body domain controller is mainly responsible for controlling vehicle body accessories such as doors and windows, lights, and wipers; the powertrain domain controller is mainly responsible for managing the vehicle's motor, battery, and electronic control system; and the chassis domain controller is mainly responsible for controlling the vehicle's braking, steering, suspension, and other chassis systems.

[0163] Computing resource scheduling priority refers to the order in which global computing resources are allocated and scheduled when multiple domain controllers simultaneously have cross-domain computing power borrowing needs. The computing power needs of domain controllers with higher priority will be met first, thereby ensuring the stable operation of core functions.

[0164] In one possible implementation, the computing resource scheduling priority of all domain controllers is pre-configured during the initialization phase. The computing resource scheduling priority of the intelligent driving domain controller is set to the highest globally, followed by the cockpit domain controller, and then other domain controllers. When multiple domain controllers simultaneously request cross-domain computing resource borrowing, idle computing resources are allocated to the domain controller with the higher priority according to the pre-configured priority list, preventing them from being preempted by the cockpit domain controller or other domain controllers.

[0165] In practical applications, this embodiment is suitable for central computing platforms with gateway domains.

[0166] The above embodiments ensure the priority supply of computing resources for autonomous driving tasks, prevent the computing power of the intelligent driving domain controller from being preempted by the cockpit domain controller or other domain controllers, ensure the real-time performance and reliability of autonomous driving tasks, meet the core requirements of vehicle functional safety, improve the safety of the entire vehicle, and adapt to the computing power scheduling requirements of multi-domain fusion computing platforms.

[0167] To more clearly explain the solutions shown in the above embodiments, a specific embodiment will be used for illustration below.

[0168] Figure 3 A flowchart illustrating the vehicle-based cross-domain computing power dynamic borrowing method provided in this application. Figure 3 ,like Figure 3 As shown, the method includes:

[0169] S301. Determine the driving scenario based on the vehicle's speed, gear, and position.

[0170] S302. Determine whether the driving scenario is a parking scenario or an urban driving scenario.

[0171] If yes, then execute S303; otherwise, execute S301.

[0172] S303, Collect computing power information.

[0173] S304. Determine whether the computing power information meets the triggering conditions for cross-domain computing power borrowing.

[0174] If yes, then execute S305; otherwise, execute S301.

[0175] S305. Determine the identifier of the borrowing controller, the identifier of the lending controller, the available computing power, and the borrowing duration threshold.

[0176] S306. Establish a hardware-isolated cross-domain computing power borrowing channel between the borrowing controller and the lending controller.

[0177] S307. Monitor the status of the lending controller.

[0178] In one possible implementation, the SoC utilization, chip junction temperature, and borrowing duration of the borrowed controller are monitored.

[0179] S308, Whether to trigger emergency recovery.

[0180] If yes, then execute S309; ​​otherwise, execute S310.

[0181] S309. Pause the current task and release the resources corresponding to the cross-domain computing power borrowing channel.

[0182] S310, whether to trigger normal recycling.

[0183] If yes, then execute S311; otherwise, execute S307.

[0184] S311. After completing the current task, release the resources corresponding to the cross-domain computing power borrowing channel.

[0185] Next, we will take the example of an intelligent car equipped with a dual SoC platform for cockpit and intelligent driving automatically parking in a city parking lot to illustrate the above-mentioned method of dynamic borrowing of cross-domain computing power.

[0186] In this embodiment, the vehicle includes a cockpit SoC (i.e., a cockpit domain controller, which includes a central processing unit (CPU), a graphics processing unit (GPU), and a neural processing unit (NPU)) and an intelligent driving SoC (i.e., an intelligent driving domain controller, which includes a CPU and an NPU). The two SoCs are interconnected via a high-speed PCIe Gen4 bus and support DMA. Both domains run operating systems that support a hypervisor and are configured with a hardware memory protection unit (MPU or SMMU) for memory access control.

[0187] In practical application, the vehicle speed drops to 3 km / h, the gear is shifted to reverse, and the driving scenario is determined to be a parking scenario. Subsequently, the NPU utilization rate of the cockpit SoC was collected to be 18%, the chip junction temperature was 72°C, and the NPU utilization rate of the intelligent driving SoC was 84%. Since 18% < 30% (first utilization threshold) and 84% > 70% (second utilization threshold), and 72°C < 85°C (first temperature threshold), the cross-domain computing power borrowing trigger conditions are met, triggering the borrowing of computing power from the cockpit to the intelligent driving system. That is, the lending controller is the cockpit SoC, and the borrowing controller is the intelligent driving SoC. Then, based on the total computing power of the lending controller, the preset maximum borrowable ratio, the NPU utilization rate, and the required computing power of the borrowing controller, the borrowable computing power of the lending controller is calculated to be 22% of the NPU computing power, with a borrowing duration threshold of 120 seconds.

[0188] Furthermore, the MPU allocates 22% of the NPU computing power on the cockpit SoC as an isolated memory partition. This isolated memory partition only allows DMA from the intelligent driving SoC. The hypervisor creates a temporary virtual machine instance on the intelligent driving SoC and maps it to the aforementioned isolated memory partition, establishing a PCIe data link, i.e., a cross-domain computing power borrowing channel, which takes 8ms to establish. Finally, the intelligent driving SoC distributes the parking bird's eye view (BEV) perception computing task to the temporary virtual machine instance for execution. The NPU utilization of the intelligent driving SoC drops to 62%, the perception frame rate increases from 15fps to 22fps, and the parking trajectory planning accuracy improves by approximately 15%. After 105 seconds, the vehicle completes parking, the scene perception determines that the current scene switches to a regular scene, triggering normal recycling. After completing the current inference batch, the temporary virtual machine instance releases resources within 380ms, reports recycling completion, and writes it to the borrowing log.

[0189] Based on simulation tests, the cross-domain computing power dynamic borrowing method of this application improves the utilization rate of the vehicle global domain controller SoC by 15%-30% in parking scenarios without increasing hardware costs, increases the intelligent driving perception frame rate from 15fps to 22fps in typical parking scenarios (an improvement of approximately 47%), and reduces the response latency of the large cockpit model by approximately 20% in urban driving scenarios. The ASIL isolation mechanism, through dual protection of MPU and Hypervisor, ensures that the security level downgrade of borrowed computing power is limited to the scope of temporary virtual machine instances, and the ASIL of the main virtual machine of the borrowed controller is not affected. It has passed the ISO26262 functional safety risk analysis verification. The emergency recovery hard interrupt mechanism ensures that the entire resource recovery process has a latency of ≤50ms, and the cross-domain computing power borrowing and returning reliability rate is ≥99.99%.

[0190] In summary, the technical effects of the embodiments of this application are as follows:

[0191] (1) Improved SoC utilization: Cross-scenario computing power sharing between the cockpit domain controller and the intelligent driving domain controller improves the overall utilization rate of vehicle computing resources by 15%-30%. Taking a domain controller with a scale of 100 TOPS as an example, the computing power for autonomous driving perception increases by about 22% in the parking scenario, and the perception accuracy and frame rate are significantly improved.

[0192] (2) No additional hardware cost: The computing power is borrowed from the existing idle computing power resources on the same platform. There is no need to increase the number of chips or expand the area of ​​the printed circuit board (PCB). The overall inference capability of the system is improved under the condition of zero hardware increment.

[0193] (3) Functional safety compliance: The ASIL isolation mechanism (MPU hardware partitioning + Hypervisor software isolation) ensures that the security level of the borrowed computing power is marked as QM, which is strictly isolated from the ASIL of the main virtual machine of the lending controller and the borrowing controller, thus meeting the independence requirements of ISO26262 for systems with multiple ASIL levels.

[0194] (4) High reliability of recycling: The triple protection mechanism (normal recycling after timeout, emergency recycling of SoC utilization rate, and emergency recycling of chip junction temperature) ensures that the computing power is reliably recycled within 50ms, and the reliability of cross-domain computing power borrowing system is ≥99.99%.

[0195] (5) High configurability: All threshold parameters support OTA dynamic updates, adapting to different vehicle models, different driving habits and different regulatory requirements for computing power allocation strategies.

[0196] For example, the vehicle-in-cabin driver fusion computing method can be applied to the vehicle-in-cabin driver fusion computing platform. Figure 4 This is a schematic diagram of the structure of the vehicle-mounted cockpit driver fusion computing platform provided in this application, as shown below. Figure 4 As shown, the cross-domain computing power dynamic borrowing system adopts a four-layer architecture, which consists of the application layer, computing power management layer, isolation communication layer, and hardware layer from top to bottom.

[0197] The application layer includes a cockpit application module, a large-scale model inference module, a perception task module, and a planning and control module. The cockpit application module is primarily responsible for implementing basic cockpit functions such as in-vehicle entertainment and navigation; the large-scale model inference module is mainly responsible for inference calculations related to large-scale AI models, such as voice interaction and scene understanding; the perception task module is mainly responsible for calculating autonomous driving perception tasks such as BEV perception and object detection; and the planning and control module is mainly responsible for calculating autonomous driving decision-making and control tasks such as vehicle trajectory planning and vehicle motion control.

[0198] The computing power management layer includes a scene awareness module, a computing power monitoring module, a borrowing decision engine, and a borrowing / returning status manager. Specifically:

[0199] The scene perception module receives input from the vehicle speed sensor, gear sensor, GNSS module and high-precision map, identifies the current driving scene of the vehicle, and outputs scene labels, including four categories: parking scene, urban driving scene, highway driving scene and normal scene.

[0200] The computing power monitoring module is used to collect the SoC utilization and chip junction temperature of the CPU, GPU, and NPU of the cockpit domain controller and intelligent driving domain controller at a period of 100ms, form a snapshot, and report it to the borrowing decision engine.

[0201] The decision engine is used to determine whether the cross-domain computing power borrowing trigger conditions are met based on the driving scenario and snapshot. When the cross-domain computing power borrowing trigger conditions are met, the available computing power and the maximum borrowing duration threshold are calculated, and corresponding control instructions are sent to the isolation communication layer and the borrowing and returning status manager. For example, an establishment instruction is sent to the isolation communication layer to instruct the isolation communication layer to establish a cross-domain computing power borrowing channel.

[0202] The borrowing and returning state manager maintains a five-state machine (idle, borrowed, borrowing in, recycling, and emergency recycling) and performs timeout-based normal recycling and emergency recycling operations. After performing these operations, the state machine returns to the idle state. The five-state machine uses redundant encoding for storage to prevent state chaos caused by software failures. State transitions are only allowed under preset legal conditions; illegal state transitions trigger system errors and prohibit all subsequent cross-domain computing power borrowing operations until a reset is performed.

[0203] The isolated communication layer includes an MPU / SMMU, a Hypervisor virtualization module, and a PCIe bus channel module. The MPU / SMMU is used to partition hardware-isolated memory partitions on the lending controller, implementing access control for memory regions with different security levels. The Hypervisor virtualization module creates temporary virtual machine instances on the borrowing controller, encapsulating the borrowed computing resources within these temporary virtual machine instances and marking their security level as QM to achieve secure isolation from the main virtual machine. The PCIe bus channel module establishes a cross-domain data transmission link between the cockpit domain controller and the intelligent driving domain controller, and enables CRC32 code verification for data integrity, ensuring reliable data transmission. It should be understood that CRC32 verification is performed at the DMA hardware layer and does not consume CPU computing power.

[0204] The hardware layer includes a cockpit domain controller, an intelligent driving domain controller, and a high-speed interconnect bus module. The cockpit domain controller integrates a CPU, GPU, and NPU to provide computing power support for cockpit-related functions; the intelligent driving domain controller integrates a CPU and NPU to provide computing power support for autonomous driving-related functions; the high-speed interconnect bus module adopts PCIeGen4 to realize high-speed data interaction between the cockpit domain controller and the intelligent driving domain controller.

[0205] In the vehicle-mounted cockpit-driving fusion computing platform, the scene perception module identifies the vehicle driving scene, drives the borrowing decision engine to calculate cross-domain available computing power, and uses MPU / SMMU and Hypervisor virtualization technology to establish an ASIL-secure and isolated cross-domain computing power borrowing channel. Under the dual protection of timeout monitoring and emergency recovery of the borrowing and returning status manager, bidirectional elastic computing power scheduling between the cockpit domain controller and the intelligent driving domain controller is realized.

[0206] based on Figure 4 The in-vehicle cockpit driver fusion computing platform shown, taking a parking scenario as an example, uses... Figure 5 The interaction process between the above modules will be explained. Figure 5 A flowchart illustrating the vehicle-based cross-domain computing power dynamic borrowing method provided in this application. Figure 4 ,like Figure 5 As shown, in this embodiment, the cockpit domain controller is a lending controller, and the intelligent driving domain controller is a borrowing controller. The method includes:

[0207] S501, The scene perception module sends a scene type identifier to the borrowing decision engine to confirm that the current driving scene is a parking scene.

[0208] S502 uses the decision engine to send a query command to the cockpit domain controller to obtain the NPU utilization and chip junction temperature of the cockpit domain controller.

[0209] S503, the cockpit domain controller returns the NPU utilization and chip junction temperature to the borrowed decision engine, specifically the NPU utilization is 18% and the chip junction temperature is 72°C.

[0210] S504: Use the decision engine to send a query command to the intelligent driving domain controller to obtain the NPU utilization of the intelligent driving domain controller.

[0211] The S505 intelligent driving domain controller returns the NPU utilization rate to the borrowed decision engine, specifically showing an NPU utilization rate of 84%.

[0212] S506: Based on the current scenario type, computing power utilization rate, and chip junction temperature, the decision engine determines that the cross-domain computing power borrowing trigger conditions are met, and issues a cross-domain computing power borrowing instruction to the intelligent driving domain controller, specifying that the computing power that can be borrowed this time is 22% of the NPU computing power, and the borrowing time threshold is 120s.

[0213] S507: Using the decision engine, issue an isolated partition creation command to the cockpit domain controller, instructing the cockpit domain controller to establish an isolated memory partition corresponding to 22% of the NPU computing power through the MPU.

[0214] S508: Using the decision engine, issue a temporary virtual machine instance creation command to the intelligent driving domain controller, instructing the intelligent driving domain controller to create a temporary virtual machine instance with a security level of QM through the Hypervisor.

[0215] The S509 intelligent driving domain controller transmits BEV perception computing tasks to the cockpit domain controller via the PCIe channel, and the idle NPU computing power of the cockpit domain controller executes the BEV perception computing tasks.

[0216] The S510 borrowing and returning status manager monitors the duration of the current computing power borrowing in real time. When it detects that the borrowed duration has exceeded the preset borrowing duration threshold, it sends an overtime normal recovery trigger signal to the borrowing decision engine.

[0217] S511: Use the decision engine to send a normal recycling command to the intelligent driving domain controller, triggering the normal recycling process of the cross-domain computing power borrowing channel.

[0218] S512 After completing the current BEV perception computing task, the intelligent driving domain controller releases the temporary virtual machine instance and sends a resource release completion notification to the cockpit domain controller.

[0219] S513, the cockpit domain controller releases the isolated memory partition and reports the completion of the isolated partition release to the borrowing decision engine, thus ending this cross-domain computing power dynamic borrowing process.

[0220] Existing in-vehicle multi-domain computing platforms generally suffer from the following core technical problems:

[0221] Firstly, the computing resources of the cockpit domain controller and the intelligent driving domain controller adopt a static independent allocation mode. During operation, they cannot dynamically borrow the idle computing power of each other across domains. This results in a large amount of idle computing power of the cockpit domain controller in parking scenarios, while the autonomous driving perception computing power of the intelligent driving domain controller is severely insufficient, and the overall computing power resource utilization rate is extremely low.

[0222] Secondly, existing cross-domain resource scheduling solutions mostly originate from the information technology (IT) cloud computing field. They are not specifically designed for vehicle functional safety requirements, lack functional safety constraints that comply with the ISO26262 standard, and cannot achieve hardware-level isolation between borrowed computing power and main domain security tasks, thus posing serious functional safety risks.

[0223] Third, the lack of a precise borrowing trigger mechanism based on driving scenario perception and a complete state management of the entire computing power borrowing and returning process makes it impossible to reliably control the delay of emergency recovery and borrowing timeout, which can easily lead to resource leakage, system lag, or even functional failure.

[0224] To address the aforementioned technical issues, this application provides a cross-domain dynamic computing power borrowing method that enables bidirectional elastic computing power scheduling between the cockpit domain controller and the intelligent driving domain controller without increasing any hardware costs. The specific solution is as follows:

[0225] 1. Solving the problem of low utilization rate of static computing power allocation: This application proposes a cross-domain computing power dynamic borrowing mechanism based on driving scenario perception. By identifying typical scenarios such as parking and urban driving through the scenario perception module, the corresponding computing power borrowing is automatically triggered, realizing bidirectional computing power borrowing between the cockpit domain controller and the intelligent driving domain controller, thereby improving the overall utilization rate of the vehicle's global computing power resources by 15%-30%.

[0226] 2. Addressing the issue of insufficient functional safety isolation: This application adopts a dual isolation mechanism of MPU / SMMU hardware partitioning + Hypervisor software isolation, which encapsulates the borrowed computing power in an independent temporary virtual machine instance, marks its security level as QM, and strictly isolates it from the ASIL of the respective main virtual machines of the lending controller and the borrowing controller, fully meeting the independence requirements of ISO26262 for systems with multiple ASIL levels.

[0227] 3. Solving the problem of unreliable computing power borrowing and repayment: This application designs a five-state machine (idle state, lending state, borrowing state, recycling in progress, emergency recycling) for full-process state management, and constructs a triple guarantee mechanism of normal recycling after timeout, emergency recycling based on computing power utilization, and emergency recycling based on chip junction temperature, ensuring that the entire emergency recycling process has a latency of ≤50ms and a cross-domain computing power borrowing and repayment reliability rate of ≥99.99%.

[0228] Figure 6 A schematic diagram of the vehicle-based cross-domain computing power dynamic borrowing device provided in this application is shown below. Figure 6 As shown, the vehicle-based cross-domain computing power dynamic borrowing device 60 provided in this embodiment includes:

[0229] The acquisition module 601 is used to acquire the vehicle's driving scenario and the computing power information of the cockpit domain controller and the intelligent driving domain controller;

[0230] The determination module 602 is used to determine the identifier of the borrowing controller, the identifier of the lending controller, the available computing power, and the borrowing duration threshold based on the driving scenario and computing power information if the driving scenario and computing power information meet the preset cross-domain computing power borrowing trigger conditions. The borrowing controller is the domain controller with a computing power demand gap among the cockpit domain controller and the intelligent driving domain controller, and the lending controller is the domain controller with idle available computing power among the cockpit domain controller and the intelligent driving domain controller.

[0231] Create module 603 to create securely isolated temporary virtual machine instances for the computing power tasks to be executed by the borrowing controller based on the identifier of the borrowing controller;

[0232] Module 604 is established to create a hardware-isolated cross-domain computing power borrowing channel between a temporary virtual machine instance and the lending controller based on the identifier of the lending controller, via the MPU / SMMU, so that the borrowing controller can use the idle computing power of the lending controller through the cross-domain computing power borrowing channel within the borrowing duration threshold.

[0233] In one possible implementation, module 604 is specifically used for:

[0234] Based on the identifier of the lending controller, the memory area corresponding to the available computing power is divided into isolated memory partitions in the lending controller through the MPU / SMMU;

[0235] Map the isolated memory partition to the computing resources of the temporary virtual machine instance, and configure the isolated memory partition to allow the controller to access memory within the borrowing duration threshold;

[0236] Establish a cross-domain computing power borrowing channel between a temporary virtual machine instance and the lending controller.

[0237] In one possible implementation, the preset cross-domain computing power borrowing trigger condition includes at least one of the following:

[0238] The driving scenario is a parking scenario, and the SoC utilization rate of the cockpit domain controller is lower than the first utilization threshold, while the SoC utilization rate of the intelligent driving domain controller is higher than the second utilization threshold, and the chip junction temperature of the cockpit domain controller is lower than the first temperature threshold.

[0239] The driving scenario is an urban driving scenario, and the SoC utilization rate of the intelligent driving domain controller is lower than the third utilization threshold, while the SoC utilization rate of the cockpit domain controller is higher than the fourth utilization threshold, and the chip junction temperature of the intelligent driving domain controller is lower than the second temperature threshold.

[0240] Among them, the first utilization threshold is less than the second utilization threshold, the third utilization threshold is less than the fourth utilization threshold, and the SoC utilization rate and chip junction temperature belong to computing power information.

[0241] In one possible implementation, the acquisition module 601 is specifically used for:

[0242] Obtain the vehicle's speed, gear, and position;

[0243] If the speed is less than the first preset speed and the gear is the preset gear, then the driving scenario is determined to be a parking scenario, and the preset gear is P or R.

[0244] If the speed is greater than the second preset speed and the location is in an urban area, then the driving scenario is determined to be an urban driving scenario, and the first preset speed is less than the second preset speed.

[0245] In one possible implementation, the determining module 602 is specifically used for:

[0246] The identification of the borrowed controller, the identification of the lent controller, and the borrowing duration threshold are determined based on the driving scenario.

[0247] The available computing power of the borrowed controller is calculated based on the total computing power of the borrowed controller, the preset maximum borrowable ratio, the SoC utilization rate, and the computing power required by the borrowed controller.

[0248] In one possible implementation, the determining module 602 is specifically used for:

[0249] The initial ratio is determined by subtracting the SoC utilization rate from the maximum available ratio.

[0250] The maximum value between the initial ratio and 0 is determined as the target ratio;

[0251] The value obtained by multiplying the total computing power by the target ratio is determined as the maximum available computing power.

[0252] The minimum of the maximum available computing power and the required computing power is determined as the available computing power.

[0253] In one possible implementation, the determining module 602 is specifically used for:

[0254] If the driving scenario is a parking scenario, then the identifier of the cockpit domain controller is determined as the identifier of the lending controller, the identifier of the intelligent driving domain controller is determined as the identifier of the borrowing controller, and the preset duration threshold corresponding to the parking scenario is determined as the borrowing duration threshold.

[0255] If the driving scenario is an urban driving scenario, then the identifier of the cockpit domain controller will be determined as the identifier of the borrowed controller, the identifier of the intelligent driving domain controller will be determined as the identifier of the lent controller, and the preset duration threshold corresponding to the urban driving scenario will be determined as the borrowing duration threshold.

[0256] In one possible implementation, the cross-domain computing power borrowing channel is a bidirectional PCIe link, and each frame of data transmitted through the cross-domain computing power borrowing channel is accompanied by a cyclic redundancy check code.

[0257] In one possible implementation, the vehicle-based cross-domain computing power dynamic borrowing device 60 further includes an anomaly recovery module, used for:

[0258] If the SoC utilization of the loaned controller exceeds the fifth utilization threshold, or the chip junction temperature of the loaned controller is higher than the third temperature threshold, a hardware interrupt signal is sent to the temporary virtual machine instance.

[0259] In response to a hardware interrupt signal, the temporary virtual machine instance suspends the current task and releases the resources corresponding to the cross-domain computing power borrowing channel.

[0260] In one possible implementation, the vehicle-based cross-domain computing power dynamic borrowing device 60 further includes a normal recycling module for:

[0261] If it is detected that the borrowed time of the cross-domain computing power borrowing channel exceeds the borrowed time threshold, or if the driving scenario changes, a stop signal is sent to the temporary virtual machine instance.

[0262] In response to a stop signal, a temporary virtual machine instance releases the resources corresponding to the cross-domain computing power borrowing channel after completing the current task.

[0263] In one possible implementation, the Automotive Safety Integrity Level (ASIL) of the temporary virtual machine instance is marked as QM.

[0264] In one possible implementation, if the vehicle also includes other domain controllers besides the cockpit domain controller and the intelligent driving domain controller, then the computing resource scheduling priority of the intelligent driving domain controller is higher than the computing resource scheduling priority of the cockpit domain controller and the computing resource scheduling priority of the other domain controllers.

[0265] The vehicle-based cross-domain computing power dynamic borrowing device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0266] Figure 7 This is a structural diagram of the vehicle provided in this application. Figure 7 As shown, the vehicle 70 provided in this embodiment includes: a processor 701, a memory 702, a cockpit domain controller 703, an intelligent driving domain controller 704, and a vehicle body 705. Optionally, the vehicle 70 also includes a communication component 706. The processor 701, memory 702, cockpit domain controller 703, intelligent driving domain controller 704, and communication component 706 are connected via a bus 707.

[0267] In the specific implementation process, the processor 701 executes the computer execution instructions stored in the memory 702, causing at least one processor 701 to execute the above-described method.

[0268] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0269] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0270] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0271] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0272] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0273] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0274] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0275] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0276] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0277] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0278] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0279] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0280] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0281] Finally, it should be noted that other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and alterations may be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for dynamic cross-domain computing power borrowing based on vehicles, characterized in that, include: Obtain the vehicle's driving scenario and the computing power information of the cockpit domain controller and intelligent driving domain controller; If the driving scenario and the computing power information meet the preset cross-domain computing power borrowing trigger conditions, then the identifier of the borrowing controller, the identifier of the lending controller, the available computing power, and the borrowing duration threshold are determined according to the driving scenario and the computing power information. The borrowing controller is the domain controller in the cockpit domain controller and the intelligent driving domain controller that has a computing power demand gap, and the lending controller is the domain controller in the cockpit domain controller and the intelligent driving domain controller that has idle available computing power. Based on the identifier of the borrowing controller, a securely isolated temporary virtual machine instance is created for the computing power task to be executed by the borrowing controller; Based on the identifier of the lending controller, a hardware-isolated cross-domain computing power borrowing channel is established between the temporary virtual machine instance and the lending controller through the hardware memory protection unit (MPU) / system memory management unit (SMMU), so that the borrowing controller can use the idle computing power of the lending controller through the cross-domain computing power borrowing channel within the borrowing duration threshold.

2. The method according to claim 1, characterized in that, The establishment of a hardware-isolated cross-domain computing power borrowing channel between the temporary virtual machine instance and the lending controller, based on the identifier of the lending controller and via the MPU / SMMU, includes: Based on the identifier of the lending controller, the memory area corresponding to the available computing power is divided into isolated memory partitions in the lending controller by the MPU / SMMU. The isolated memory partition is mapped to the computing resources of the temporary virtual machine instance, and the isolated memory partition is configured to allow the borrowing controller to access memory within the borrowing duration threshold. Establish a cross-domain computing power borrowing channel between the temporary virtual machine instance and the lending controller.

3. The method according to claim 1, characterized in that, The preset cross-domain computing power borrowing trigger conditions include at least one of the following: The driving scenario is a parking scenario, and the system-on-a-chip (SoC) utilization rate of the cockpit domain controller is lower than the first utilization threshold, the SoC utilization rate of the intelligent driving domain controller is higher than the second utilization threshold, and the chip junction temperature of the cockpit domain controller is lower than the first temperature threshold. The driving scenario is an urban driving scenario, and the SoC utilization rate of the intelligent driving domain controller is lower than the third utilization threshold, the SoC utilization rate of the cockpit domain controller is higher than the fourth utilization threshold, and the chip junction temperature of the intelligent driving domain controller is lower than the second temperature threshold. Wherein, the first utilization threshold is less than the second utilization threshold, the third utilization threshold is less than the fourth utilization threshold, and the SoC utilization rate and the chip junction temperature belong to the computing power information.

4. The method according to claim 3, characterized in that, The process of obtaining the vehicle's driving scenario includes: Obtain the vehicle's speed, gear, and position; If the speed is less than the first preset speed and the gear is a preset gear, then the driving scenario is determined to be the parking scenario, and the preset gear is P or R. If the speed is greater than the second preset speed and the location is in an urban area, then the driving scenario is determined to be an urban driving scenario, and the first preset speed is less than the second preset speed.

5. The method according to claim 3, characterized in that, The step of determining the identifier of the borrowing controller, the identifier of the lending controller, the available computing power, and the borrowing duration threshold based on the driving scenario and the computing power information includes: The identification of the borrowing controller, the identification of the lending controller, and the borrowing duration threshold are determined based on the driving scenario. The available computing power of the lending controller is calculated based on the total computing power of the lending controller, the preset maximum lending ratio, the SoC utilization rate, and the computing power required by the borrowing controller.

6. The method according to claim 5, characterized in that, The step of calculating the available computing power of the lending controller based on the total computing power of the lending controller, the preset maximum lending ratio, the SoC utilization rate, and the required computing power of the borrowing controller includes: The initial ratio is determined by subtracting the SoC utilization rate from the maximum lendable ratio. The maximum value between the initial ratio and 0 is determined as the target ratio; The value obtained by multiplying the total computing power by the target ratio is determined as the maximum available computing power. The minimum value between the maximum available computing power and the required computing power is determined as the available computing power.

7. The method according to claim 5, characterized in that, The step of determining the identifier of the borrowing controller, the identifier of the lending controller, and the borrowing duration threshold based on the driving scenario includes: If the driving scenario is the parking scenario, then the identifier of the cockpit domain controller is determined as the identifier of the lending controller, the identifier of the intelligent driving domain controller is determined as the identifier of the borrowing controller, and the preset duration threshold corresponding to the parking scenario is determined as the borrowing duration threshold. If the driving scenario is the urban driving scenario, then the identifier of the cockpit domain controller is determined as the identifier of the borrowing controller, the identifier of the intelligent driving domain controller is determined as the identifier of the lending controller, and the preset duration threshold corresponding to the urban driving scenario is determined as the borrowing duration threshold.

8. The method according to any one of claims 1-7, characterized in that, The cross-domain computing power borrowing channel is a bidirectional link based on the high-speed peripheral component interconnect bus PCIe, and each frame of data transmitted through the cross-domain computing power borrowing channel is accompanied by a cyclic redundancy check code.

9. The method according to any one of claims 1-7, characterized in that, The method further includes: If the SoC utilization of the lending controller is detected to exceed the fifth utilization threshold, or the chip junction temperature of the lending controller is higher than the third temperature threshold, a hardware interrupt signal is sent to the temporary virtual machine instance. In response to the hardware interrupt signal, the temporary virtual machine instance suspends the current task and releases the resources corresponding to the cross-domain computing power borrowing channel.

10. The method according to any one of claims 1-7, characterized in that, The method further includes: If it is detected that the borrowed time of the cross-domain computing power borrowing channel exceeds the borrowed time threshold, or if the driving scenario changes, a stop signal is sent to the temporary virtual machine instance. In response to the stop signal, the temporary virtual machine instance releases the resources corresponding to the cross-domain computing power borrowing channel after completing the current task.

11. The method according to any one of claims 1-7, characterized in that, The Automotive Safety Integrity Level (ASIL) of the temporary virtual machine instance is marked as Quality Management Level (QM).

12. The method according to any one of claims 1-7, characterized in that, If the vehicle also includes other domain controllers besides the cockpit domain controller and the intelligent driving domain controller, then the computing resource scheduling priority of the intelligent driving domain controller is higher than the computing resource scheduling priority of the cockpit domain controller and the computing resource scheduling priority of the other domain controllers.

13. A vehicle-based cross-domain computing power dynamic borrowing device, characterized in that, include: The acquisition module is used to acquire the vehicle's driving scenario and the computing power information of the cockpit domain controller and the intelligent driving domain controller; The determination module is used to determine the identifier of the borrowing controller, the identifier of the lending controller, the available computing power, and the borrowing duration threshold based on the driving scenario and the computing power information if the driving scenario and the computing power information meet the preset cross-domain computing power borrowing trigger conditions. The borrowing controller is the domain controller in the cockpit domain controller and the intelligent driving domain controller that has a computing power demand gap, and the lending controller is the domain controller in the cockpit domain controller and the intelligent driving domain controller that has idle computing power available for lending. A creation module is used to create a securely isolated temporary virtual machine instance for the computing power task to be executed by the borrowing controller, based on the identifier of the borrowing controller; A module is established to establish a hardware-isolated cross-domain computing power borrowing channel between the temporary virtual machine instance and the lending controller based on the identifier of the lending controller, through the hardware memory protection unit (MPU) / system memory management unit (SMMU), so that the borrowing controller can use the idle computing power of the lending controller through the cross-domain computing power borrowing channel within the borrowing duration threshold.

14. A vehicle, characterized in that, include: Vehicle body, memory, cockpit domain controller, intelligent driving domain controller, and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-12.

16. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-12.

Images