Methods, systems, equipment and storage media for dynamic switching of multiple systems in vehicles

Abstract

This application provides a method, system, device, and storage medium for dynamic switching of multiple systems in a vehicle, relating to the field of vehicle system technology. The method includes: acquiring a first task request from a first operating system and a second task request from a second operating system; determining a first resource requirement for the first operating system and a second resource requirement for the second operating system; dividing the first operating system into a first resource isolation region and the second operating system into a second resource isolation region; when the first resource occupancy rate in the first resource isolation region exceeds a first preset threshold, or the second resource occupancy rate in the second resource isolation region exceeds a second preset threshold, acquiring vehicle status information and generating a priority list based on the status information; and adjusting the resource allocation ratio of the first or second resource isolation region according to the priority list. The technical effect of this application is: achieving balanced resource allocation across the entire system and improving resource utilization efficiency.

Description

Technical Field

[0001] This application relates to the field of intelligent detection technology, specifically to a method, system, device, and storage medium for dynamic switching of multiple vehicle systems. Background Technology

[0002] As automotive electronics become increasingly sophisticated, in-vehicle systems typically need to run multiple operating systems simultaneously to meet the demands of different functional modules. For example, the Android Operating System (AOS) is used for human-machine interaction and entertainment functions, while the Linux Operating System (LOS) real-time system is used for vehicle control and safety functions. These operating systems need to share limited hardware resources, and how to achieve efficient resource utilization while ensuring system stability has become a pressing technical problem to be solved.

[0003] Existing technologies typically employ static resource allocation schemes, allocating a fixed resource quota to each operating system based on preset configurations at system startup. While this approach is simple to implement and easy to manage, when one operating system has a light workload, most of its pre-allocated resources remain idle; conversely, when another operating system faces intensive computing tasks, even if its performance has reached its bottleneck, it cannot utilize the idle resources of other operating systems, resulting in an unbalanced overall system resource allocation and low utilization efficiency. Summary of the Invention

[0004] This application provides a method, system, device, and storage medium for dynamic switching of multiple systems in a vehicle, which is used to achieve balanced allocation of overall system resources and improve resource utilization efficiency.

[0005] In a first aspect, this application provides a method for dynamic switching of multiple systems in a vehicle. The method includes: acquiring a first task request from a first operating system and a second task request from a second operating system, wherein the first operating system and the second operating system are independently running different operating systems, and the first task request and the second task request are task requests running in parallel; determining a first resource requirement of the first operating system based on the first task request, and determining a second resource requirement of the second operating system based on the second task request; dividing a first resource isolation region for the first operating system based on the first resource requirement, and dividing a second resource isolation region for the second operating system based on the second resource requirement; when the first resource occupancy rate in the first resource isolation region exceeds a first preset threshold, or the second resource occupancy rate in the second resource isolation region exceeds a second preset threshold, acquiring the vehicle's status information; sorting the first task request and the second task request from high to low according to the status information to generate a priority list; and adjusting the resource allocation ratio of the first resource isolation region or the second resource isolation region according to the priority list.

[0006] By adopting the above technical solution, when the resource utilization rate of any operating system exceeds a preset threshold, the system can prioritize tasks based on the vehicle's real-time status information and dynamically adjust the resource allocation ratio accordingly. This ensures the stable operation of critical tasks while improving the system's resource utilization efficiency. Simultaneously, by dividing different operating systems into independent resource isolation areas, resource contention between systems is avoided, enhancing system stability. Furthermore, this solution supports parallel processing of tasks on both the first and second operating systems, achieving balanced overall system resource allocation and improving resource utilization efficiency.

[0007] Optionally, determining the first resource requirement of the first operating system based on the first task request and determining the second resource requirement of the second operating system based on the second task request includes: obtaining the first task type corresponding to the first task request and the second task type corresponding to the second task request; and determining the first resource requirement corresponding to the first task type and the second resource requirement corresponding to the second task type from a pre-stored resource requirement database.

[0008] By adopting the above technical solution, and by pre-establishing a mapping relationship between task types and resource requirements and storing it in a resource requirement database, the system can quickly and accurately obtain the resource quantities required for the first and second task requests. This avoids the system overhead caused by real-time calculation of resource requirements and improves the efficiency and accuracy of resource allocation. Furthermore, this method of determining resource requirements based on task type provides a standardized resource configuration reference for different types of tasks, making resource allocation more standardized and reasonable.

[0009] Optionally, the step of dividing the first resource isolation region for the first operating system based on the first resource requirement and dividing the second resource isolation region for the second operating system based on the second resource requirement includes: obtaining the total resource quantity of the vehicle's in-vehicle system, the first system type of the first operating system, and the second system type of the second operating system; determining the first reserved resource quantity for the first system type and the second reserved resource quantity for the second system type; determining the first resource allocation ratio for the first operating system based on the first ratio of the first resource requirement to the total resource quantity, and dividing the first resource isolation region for the first operating system in combination with the first resource allocation ratio and the first reserved resource quantity; determining the second resource allocation ratio for the second operating system based on the second ratio of the second resource requirement to the total resource quantity, and dividing the second resource isolation region for the second operating system in combination with the second resource allocation ratio and the second reserved resource quantity.

[0010] By adopting the above technical solution, and comprehensively considering the total resources of the vehicle system, the type of operating system, and the corresponding reserved resources, combined with the ratio of task resource requirements to total resources, the resource allocation ratio is determined, thus achieving precise management of resource allocation. This solution ensures the basic operational needs of the system by reserving necessary system resources for different types of operating systems. Simultaneously, dynamic allocation based on the ratio of resource requirements ensures the rationality of resource allocation while avoiding over- or under-allocation, thereby improving the utilization efficiency of system resources.

[0011] Optionally, the status information includes: vehicle speed information, driving status information, and surrounding environment information. The step of sorting the first task request and the second task request according to their importance from highest to lowest based on the status information to generate a priority list includes: combining the vehicle speed information, the driving status information, and the surrounding environment information to determine the first importance of the first task request and the second importance of the second task request; and sorting the first task request and the second task request according to their first and second importance from highest to lowest to generate a priority list.

[0012] By employing the aforementioned technical solution, the importance of tasks is determined through comprehensive analysis of vehicle speed, driving status, and surrounding environmental information, resulting in a more comprehensive and accurate assessment of task priority. This solution can dynamically adjust task importance based on the vehicle's real-time operating environment, ensuring that the system prioritizes the execution of critical tasks in various driving scenarios. For example, in high-speed driving or complex road conditions, the system can increase the importance of safety-related tasks, thereby prioritizing these tasks during resource allocation and improving system safety and reliability.

[0013] Optionally, determining the first importance of the first task request and the second importance of the second task request by combining the vehicle speed information, the driving status information, and the surrounding environment information includes: obtaining a preset mapping relationship between task types and importance; generating a vehicle operating scenario by combining the vehicle speed information, the driving status information, and the surrounding environment information; and determining the first importance of the first task request and the second importance of the second task request in the operating scenario based on the mapping relationship.

[0014] By adopting the above technical solution, and establishing a mapping relationship between task type and importance, and dynamically evaluating task importance in conjunction with real-time vehicle operation scenarios, the standardization and scenario adaptability of task importance determination are achieved. This solution first generates specific operating scenarios based on vehicle speed information, driving status information, and surrounding environment information. Then, it determines the importance of the task in the current scenario according to a preset mapping relationship. This not only improves the accuracy and objectivity of importance assessment but also enables the system to flexibly adjust task priorities according to different scenario characteristics, enhancing the system's adaptability to complex driving environments.

[0015] Optionally, adjusting the resource allocation ratio of the first resource isolation region or the second resource isolation region according to the priority list includes: when the first resource occupancy rate exceeds a first preset threshold, calculating a first excess amount of the first resource occupancy rate exceeding the first preset threshold; determining a first request that needs to be paused in the first task request according to the priority list, and adjusting the first request according to the first excess amount, and determining a second request that needs to be paused in the first task request to reduce the resource occupancy of the first resource isolation region; when the second resource occupancy rate exceeds a second preset threshold, calculating a second excess amount of the second resource occupancy rate exceeding the second preset threshold; determining a third request that needs to be paused in the second task request according to the priority list, and adjusting the third request according to the second excess amount, and determining a third request that needs to be paused in the third task request to reduce the resource occupancy of the second resource isolation region.

[0016] By adopting the above technical solution, precise control of resource usage is achieved by calculating the excess resource utilization and adjusting tasks based on a priority list. This solution can, when resources exceed limits, selectively pause or adjust low-priority tasks according to the specific value of the excess, ensuring the normal operation of high-priority tasks while avoiding excessive resource reclamation. Simultaneously, independent management of resource utilization in the first and second resource isolation zones ensures that resource adjustments in the two operating systems do not interfere with each other, improving the accuracy and stability of system resource regulation.

[0017] Optionally, after adjusting the resource allocation ratio of the first resource isolation region or the second resource isolation region, the method further includes: monitoring the adjusted first resource occupancy rate of the first resource isolation region and the second resource occupancy rate of the second resource isolation region; when the first resource occupancy rate is lower than a third preset threshold, resuming the second request in the order of the priority list; when the second resource occupancy rate is lower than a fourth preset threshold, resuming the fourth request in the order of the priority list, wherein the third preset threshold is less than the first preset threshold, and the fourth preset threshold is less than the second preset threshold.

[0018] By adopting the above technical solution, and by setting a recovery threshold below the resource usage threshold and continuously monitoring resource usage, the smooth recovery of suspended tasks is achieved. This solution gradually restores suspended tasks according to priority when resource usage drops below the preset threshold, avoiding drastic fluctuations in resource usage during task recovery. The difference between the preset thresholds creates a buffer zone for resource regulation, which not only prevents frequent switching of task states but also ensures the stability of system resource usage, improving the continuity of task scheduling and the smoothness of system operation.

[0019] Secondly, this application provides a vehicle-mounted multi-system dynamic switching system, the system comprising: an acquisition module, a first determination module, a second determination module, a generation module, and an adjustment module; wherein,

[0020] The acquisition module is used to acquire a first task request from the vehicle's first operating system and a second task request from the second operating system, wherein the first operating system and the second operating system are independently running different operating systems, and the first task request and the second task request are task requests running in parallel; the first determination module is used to determine a first resource requirement of the first operating system based on the first task request, and determine a second resource requirement of the second operating system based on the second task request; the second determination module is used to divide a first resource isolation region for the first operating system based on the first resource requirement, and divide a second resource isolation region for the second operating system based on the second resource requirement; the generation module is used to acquire the vehicle's status information when the first resource occupancy rate in the first resource isolation region exceeds a first preset threshold, or the second resource occupancy rate in the second resource isolation region exceeds a second preset threshold, and based on the status information, sort the first task request and the second task request from high to low according to task importance to generate a priority list; the adjustment module is used to adjust the resource allocation ratio of the first resource isolation region or the second resource isolation region according to the priority list.

[0021] Thirdly, this application provides an electronic device that adopts the following technical solution: it includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to enable the electronic device to execute a computer program such as any of the above-described vehicle-mounted multi-system dynamic switching methods.

[0022] Fourthly, this application provides a computer-readable storage medium that stores a computer program capable of being loaded by a processor and executing any of the above-mentioned vehicle-mounted multi-system dynamic switching methods.

[0023] In summary, this application includes at least one of the following beneficial technical effects:

[0024] When the resource utilization of any operating system exceeds a preset threshold, the system can prioritize tasks based on the vehicle's real-time status information and dynamically adjust resource allocation accordingly. This ensures the stable operation of critical tasks while improving system resource utilization efficiency. Simultaneously, by allocating independent resource isolation areas for different operating systems, resource contention between systems is avoided, enhancing system stability. Furthermore, this solution supports parallel processing of tasks on both the first and second operating systems, achieving balanced overall system resource allocation and improving resource utilization efficiency. Attached Figure Description

[0025] Figure 1This is a flowchart illustrating a method for dynamic switching of multiple vehicle systems provided in an embodiment of this application;

[0026] Figure 2 This is a schematic diagram of the structure of a vehicle-mounted multi-system dynamic switching system provided in an embodiment of this application;

[0027] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0028] Explanation of reference numerals in the attached figures: 1000, electronic device; 1001, processor; 1002, communication bus; 1003, user interface; 1004, network interface; 1005, memory. Detailed Implementation

[0029] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0030] In the description of the embodiments in this application, words such as "illustrative," "for example," or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "illustrative," "for example," or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of words such as "illustrative," "for example," or "for example" is intended to present the relevant concepts in a specific manner.

[0031] Figure 1 This is a flowchart illustrating a method for dynamic switching of multiple vehicle systems provided in an embodiment of this application. Figure 1 As shown, the method includes S101-S105:

[0032] S101, obtain the first task request of the vehicle's first operating system and the second task request of the second operating system. The first operating system and the second operating system are different operating systems that run independently, and the first task request and the second task request are task requests that run in parallel.

[0033] In this embodiment, to achieve efficient parallel operation of multiple operating systems in the vehicle system, it is first necessary to obtain the task requests of each operating system. Specifically, the vehicle system includes a first operating system and a second operating system. The first operating system can be an Android system, used to handle user interaction tasks such as in-vehicle entertainment and navigation, while the second operating system can be a Linux real-time system, used to handle low-level tasks such as vehicle control and fault diagnosis. These two operating systems run independently through containerization technology, avoiding mutual interference between systems.

[0034] In practical applications, the in-vehicle system's task scheduling module listens for task requests from both operating systems in real time. The first task request might include user-level requests such as multimedia playback, navigation map updates, and voice interaction; these requests are typically initiated by Android applications. The second task request might include real-time-critical requests such as CAN bus data acquisition, vehicle status monitoring, and autonomous driving control; these requests are typically initiated by underlying services of the Linux system. These task requests are designed to run in parallel to fully utilize system resources and improve overall processing efficiency.

[0035] The task scheduling module obtains these task requests through inter-process communication mechanisms (such as Unix domain sockets). Specifically, when the Android system needs to play music, it sends a first task request to the task scheduling module, containing information such as the request type, priority, and estimated resource requirements. Simultaneously, when the Linux system needs to process data from vehicle sensors, it also sends a corresponding second task request. The task scheduling module stores these requests in a task queue, preparing for subsequent resource allocation and priority adjustments.

[0036] S102, determine the first resource requirement of the first operating system according to the first task request, and determine the second resource requirement of the second operating system according to the second task request.

[0037] After receiving a task request, in order to achieve reasonable allocation of vehicle system resources, it is necessary to accurately assess the resource requirements of each operating system. Resource requirements refer to the total computing resources needed to complete a specific task, including specific values ​​for hardware resources such as CPU utilization, memory usage, and I / O bandwidth. By assessing resource requirements in advance, problems such as resource contention or uneven allocation can be avoided during system operation.

[0038] In practice, the in-vehicle system maintains a resource requirement database that stores standard resource consumption data corresponding to different task types. For example, when the first operating system (Android system) initiates the first task request for video playback, the system first identifies the task type of the request. The task type is identified based on identifiers in the request, such as "MEDIA_PLAYBACK" for multimedia playback and "NAV_RENDERING" for navigation rendering. The system then queries the database for historical resource consumption data for this task type, and combines this with parameters such as the current video resolution and encoding format to calculate specific indicators such as the number of CPU cores, memory capacity, and GPU utilization expected to be required to complete the task, thereby determining the initial resource requirement.

[0039] Similarly, when the second operating system (Linux system) initiates a second task request for autonomous driving control, the system will identify task type identifiers such as "AUTO_DRIVE_CTRL" and, in conjunction with real-time parameters such as current vehicle speed and road conditions, extract the corresponding resource consumption baseline value from the database. Considering the real-time requirements of autonomous driving tasks, the system will reserve a certain amount of resource redundancy based on the baseline value to ultimately determine the second resource requirement.

[0040] This database-based resource demand assessment mechanism is dynamic. The system continuously monitors resource usage during actual task execution and updates reference values ​​in the database using machine learning algorithms. For example, if it finds that the actual GPU utilization of a certain type of navigation task is significantly lower than the estimated value during nighttime driving, the system will automatically adjust the resource demand reference value for that scenario. Through this adaptive learning mechanism, the assessment of resource demand becomes increasingly accurate.

[0041] Based on the above embodiments, as an optional implementation, in S102, determining the first resource requirement of the first operating system according to the first task request and determining the second resource requirement of the second operating system according to the second task request specifically includes S21-S22:

[0042] S21, obtain the first task type corresponding to the first task request and the second task type corresponding to the second task request.

[0043] The system first parses the received task requests using a task analyzer to extract task type information. For the first task request from the first operating system (Android system), the system obtains the first task type by parsing the identifier field in the request header. For example, the type identifier for a multimedia playback task is "MEDIA_PLAYBACK", the type identifier for a navigation task is "NAV_RENDERING", and the type identifier for a system settings task is "SYS_SETTINGS", etc. Similarly, for the second task request from the second operating system (Linux system), the system identifies second task types such as "VEHICLE_CTRL" (vehicle control) and "DIAG_SERVICE" (diagnostic service).

[0044] S22, determine the first resource requirement corresponding to the first task type and the second resource requirement corresponding to the second task type from the pre-stored resource requirement database.

[0045] After determining the task type, the system accesses a pre-established resource requirement database to obtain baseline resource requirements. This database employs a hierarchical structure: the top layer is categorized by operating system type, the middle layer is organized by task type, and the bottom layer stores specific resource consumption data. Data records for each task type include multiple dimensions: CPU utilization distribution, memory usage curves, I / O bandwidth requirements, GPU load, etc. This data is obtained through long-term statistical analysis and is periodically updated to reflect the latest resource usage patterns.

[0046] For example, when the system processes the first task request of type "NAV_RENDERING", it retrieves the resource consumption characteristics of this type of task from the database. The data shows that this type of task requires 1 CPU core (25% utilization), 512MB of memory, and 30% of GPU processing power during normal operation. These values ​​will serve as the baseline for the first resource requirement. Simultaneously, the system will dynamically adjust the baseline value based on the specific parameters of the current task (such as map complexity and rendering quality settings) to obtain a more accurate demand prediction.

[0047] For tasks requiring a second operating system, the system uses a similar approach. For example, a task of type "VEHICLE_CTRL" has typical resource requirements recorded in the database as: one real-time CPU core (highest priority), 256MB of dedicated memory, and 10% I / O bandwidth. The system adjusts these baseline values ​​based on operating parameters such as current vehicle speed and road conditions to calculate the second resource requirements.

[0048] S103, a first resource isolation region is allocated for the first operating system based on the first resource requirement, and a second resource isolation region is allocated for the second operating system based on the second resource requirement.

[0049] After determining the resource requirements of each operating system, to avoid resource contention and mutual interference between systems, it is necessary to allocate an independent resource isolation area for each operating system. A resource isolation area refers to an independent resource space allocated to an operating system using containerization technology, including dedicated CPU cores, memory space, I / O bandwidth, and other hardware resources. These resources are logically completely isolated, ensuring that each system can run stably in an independent environment.

[0050] In practice, the first step is to obtain the total resources of the in-vehicle system, including the number of available CPU cores, total memory capacity, GPU computing units, and other hardware resources. Simultaneously, the system determines the required reserved resources for each of the first operating system (Android) and the second operating system (Linux). Reserved resources refer to the minimum resource configuration required to maintain basic system operation. For example, an Android system requires at least two CPU cores and 2GB of memory for system services, while a Linux system requires one real-time CPU core and 1GB of memory for critical task processing.

[0051] During resource allocation, the system first calculates the ratio of the first resource requirement to the total resources, obtaining the first resource allocation ratio. For example, if the first operating system requires 4GB of memory, and the total system memory is 16GB, the initial allocation ratio is 25%. Then, the system considers this ratio in conjunction with reserved resources to ultimately allocate a first resource isolation zone for the first operating system. This allocation is implemented using Linux Container (LXC) technology. The in-vehicle system uses Linux Container (LXC) technology to achieve resource isolation. LXC is an operating system-level virtualization technology that allows multiple isolated Linux systems to run on the same host. Compared to traditional virtual machines, LXC has lower resource overhead and faster startup speed. Then, the cgroups mechanism is used to set CPU quotas, memory limits, and I / O bandwidth control to ensure that resource usage does not exceed the defined boundaries. cgroups (Control Groups) are a resource limiting and isolation mechanism provided by the Linux kernel, used to limit and monitor the resource usage of process groups. With cgroups, the system can precisely control the CPU, memory, I / O, and other resource quotas that each container can use.

[0052] The same process is applied to the second operating system. Based on the second operating system's resource requirements, a second resource allocation ratio is calculated, and combined with the Linux system's reserved resources, a second resource isolation zone is defined. Considering that the second operating system primarily handles real-time tasks, its resource isolation zone will prioritize the allocation of real-time CPU cores, and NUMA affinity settings will ensure low latency for memory access. NUMA (Non-Uniform Memory Access) is a memory design architecture used in multiprocessor systems. In a NUMA architecture, processors access local memory faster than they access remote memory.

[0053] Based on the above embodiments, as an optional implementation, in S103, dividing a first resource isolation region for the first operating system according to a first resource requirement and dividing a second resource isolation region for the second operating system according to a second resource requirement specifically includes S31-S34:

[0054] S31, obtain the total resources of the vehicle's onboard system, the first system type of the first operating system, and the second system type of the second operating system.

[0055] To achieve efficient parallel operation of multiple operating systems, a precise resource isolation mechanism needs to be established. This process first requires understanding the total system resources and considering the characteristics of different operating systems, and then rationally dividing the system into isolation zones based on resource requirements. Total resources refer to the sum of available hardware resources in the vehicle system, including CPU processing power, memory capacity, GPU computing power, etc.; system type reflects the technical characteristics and resource usage patterns of different operating systems.

[0056] Upon system startup, the resource management module first obtains the total resources of the in-vehicle system through hardware detection. For example, it detects that the system is equipped with an 8-core CPU (total computing power 24000 MIPS), 16GB of system memory, and a GPU supporting OpenGL ES 3.2 (with 8 graphics processing cores). Simultaneously, the system identifies the primary operating system (Android) as "GUI_BASED_OS" (graphical interface operating system) and the secondary operating system (Linux) as "RTOS_BASED_OS" (real-time operating system). This system type information is stored in the system configuration file to guide subsequent resource allocation strategies.

[0057] S32, determine the first reserved resource amount for the first system type and the second reserved resource amount for the second system type.

[0058] Based on the system type, the resource management module calculates the amount of reserved resources required by each operating system. These reserved resources represent the minimum resource configuration needed to maintain basic system operation and must be prioritized. For the Android system, due to its graphical user interface characteristics, the first set of reserved resources includes 2 CPU cores (6000 MIPS), 2GB of system memory, and 2 GPU cores to maintain interface rendering and basic system services. For the Linux real-time system, the second set of reserved resources includes 1 dedicated real-time CPU core (3000 MIPS) and 1GB of system memory, primarily to ensure real-time response to critical control tasks. These reserved resources are allocated in a fixed manner through the Linux kernel's CPU affinity and memory binding mechanisms.

[0059] S33. Based on the first ratio of the first resource demand to the total resource quantity, determine the first resource allocation ratio of the first operating system, and combine the first resource allocation ratio and the first reserved resource quantity to divide the first resource isolation area for the first operating system.

[0060] After ensuring reserved resources are available, the system calculates the proportion of dynamically allocable resources. For the first operating system, the system calculates the first ratio of the first resource requirement to the total resources. For example, if the Android system's current task requires 6GB of memory, accounting for 37.5% of the total memory (16GB), this ratio will be used as the benchmark for the first resource allocation ratio. The system then combines this ratio with the first reserved resource amount (2GB) and, through the cgroups mechanism of Linux containers (LXC), divides the Android system into a first resource isolation zone, ultimately allocating 8GB of memory (2GB reserved plus 6GB dynamically allocated).

[0061] S34. Based on the second ratio of the second resource demand to the total resource quantity, determine the second resource allocation ratio of the second operating system, and combine the second resource allocation ratio and the second reserved resource quantity to divide the second resource isolation area for the second operating system.

[0062] The same process is applied to the second operating system. The system calculates the second ratio of the second resource requirement to the total resource requirement and combines this with the second reserved resource amount to determine the final resource allocation. For example, if the Linux system requires 3GB of memory (18.75%), plus the reserved 1GB, the system will allocate a second resource isolation area of ​​4GB of memory for it through cgroups. The remaining 4GB of memory serves as a system buffer to handle sudden loads.

[0063] S104, when the first resource occupancy rate in the first resource isolation area exceeds the first preset threshold, or the second resource occupancy rate in the second resource isolation area exceeds the second preset threshold, obtain the vehicle status information, and sort the first task request and the second task request in descending order of task importance according to the status information to generate a priority list.

[0064] In this embodiment, resource utilization rate refers to the percentage of resources actually used by the system within a specific time period relative to the total allocated resources. The first preset threshold and the second preset threshold are pre-set upper limits for resource utilization rate, typically set between 80% and 90%, used to trigger the resource adjustment mechanism.

[0065] After dividing the resource isolation zones, the system needs to monitor resource usage in real time and adjust task priorities promptly when resource pressure occurs. Resource utilization rate refers to the ratio of the actual amount of resources used by the system within a specific time window (usually 100ms) to the total amount of resources in that isolation zone. The system sets resource utilization rate thresholds for the two operating systems respectively, with the first preset threshold (for Android) set to 85% and the second preset threshold (for Linux) set to 90%. The difference in thresholds takes into account the different systems' tolerance for resource pressure.

[0066] When the monitoring module detects that the resource utilization of any operating system exceeds the corresponding threshold, the system will collect vehicle status information in real time via the CAN bus. This status information includes three dimensions: vehicle speed information (current speed, acceleration, lateral speed, etc.), driving status information (gear status, steering angle, braking pressure, etc.), and surrounding environment information (distance to adjacent lane vehicles, current road curvature, ambient light intensity, etc.). This information is uniformly encoded using a CAN matrix to ensure the real-time nature and reliability of data collection.

[0067] The system employs a multi-level task evaluation mechanism to calculate the importance of all task requests. First, based on a pre-defined scenario model, the current vehicle state is categorized, such as "high-speed driving" (speed > 100 km / h) and "emergency avoidance" (distance between adjacent vehicles < safe distance). Then, the system performs a matching degree analysis between each task request and the current scenario, calculating the task's importance score. The score calculation involves multiple weighted factors: real-time requirements (weight 0.4), safety impact (weight 0.3), urgency of user interaction (weight 0.2), and system stability (weight 0.1).

[0068] For example, when the system is in a "high-speed driving" scenario, the lane-keeping request in the second operating system receives a higher importance score (e.g., 0.95) due to its high real-time requirement (response latency requirement <10ms) and critical safety attributes; while the background music update request in the first operating system receives a lower score (e.g., 0.3) due to its delayed execution characteristic. The system sorts all task requests from highest to lowest score, generating a priority list to provide a basis for subsequent resource adjustments.

[0069] Based on the above embodiments, as an optional implementation, in S104, the status information includes: vehicle speed information, driving status information, and surrounding environment information. According to the status information, the first task request and the second task request are sorted from highest to lowest importance to generate a priority list, specifically including S41-S42:

[0070] S41, combining vehicle speed information, driving status information and surrounding environment information, determines the first importance of the first task request and the second importance of the second task request.

[0071] S42, sort the first task request and the second task request in descending order of importance to generate a priority list.

[0072] The system first collects status information in real time through the onboard sensor network. Vehicle speed information includes dynamic parameters such as current speed, acceleration, and lateral speed; driving status information records vehicle control parameters such as gear position, steering wheel angle, brake pressure, and ESP status; surrounding environment information includes environmental data such as distance to adjacent lanes, distance to obstacles ahead, road type, and weather visibility. This data is updated via the CAN bus at a period of 100ms to ensure the real-time nature of the status information.

[0073] The specific task analysis engine uses a multi-level evaluation model to calculate the importance of tasks. In the state information standardization processing stage, the system quantifies various types of state information: vehicle speed information standardization: low speed range (0-40km / h) corresponds to a danger level of 0-0.2; medium speed range (40-80km / h) corresponds to a danger level of 0.2-0.4; fast speed range (80-120km / h) corresponds to a danger level of 0.4-0.7; high speed range (>120km / h) corresponds to a danger level of 0.7-1.0.

[0074] Standardized driving conditions: Straight driving (steering wheel angle <5°) corresponds to a hazard level of 0-0.3; slight steering (steering wheel angle 5°-15°) corresponds to a hazard level of 0.3-0.6; sharp steering (steering wheel angle >15°) corresponds to a hazard level of 0.6-0.9; emergency avoidance (with ESP intervention) corresponds to a hazard level of 0.9-1.0.

[0075] Surrounding environment standardization: Sufficient safety distance (>2 times the safety distance) corresponds to danger level 0-0.2; normal driving (1-2 times the safety distance) corresponds to danger level 0.2-0.5; approach warning (0.5-1 times the safety distance) corresponds to danger level 0.5-0.8; dangerous state (<0.5 times the safety distance) corresponds to danger level 0.8-1.0.

[0076] The system calculates the urgency index of the scene through a fusion algorithm: urgency level = vehicle speed weight (0.3) × vehicle speed hazard level + driving state weight (0.4) × driving state hazard level + surrounding environment weight (0.3) × environmental hazard level.

[0077] For all task requests, the system uses a unified evaluation framework to calculate the importance of the task: Basic importance evaluation (total weight is 1.0): Real-time requirements (0.3): Hard real-time tasks (response time <10ms): 0.8-1.0; Soft real-time tasks (response time <100ms): 0.5-0.8; Non-real-time tasks (response time >100ms): 0.1-0.5.

[0078] Safety impact (0.4): Direct safety related (e.g., collision warning): 0.8-1.0; Indirect safety related (e.g., navigation prompts): 0.4-0.8; Non-safety related (e.g., entertainment applications): 0.1-0.4.

[0079] User interaction urgency (0.2): Proactive interaction (requiring immediate user response): 0.7-1.0; Passive prompts (information display): 0.3-0.7; Background tasks (no direct interaction): 0.1-0.3.

[0080] System dependency (0.1): Core system services: 0.8-1.0; Regular application services: 0.4-0.8; Optional function services: 0.1-0.4.

[0081] Final task importance calculation: Task importance = base importance × (1 + scenario urgency adjustment coefficient), where the scenario urgency adjustment coefficient is dynamically calculated according to the task type: Safety critical tasks: adjustment coefficient = scenario urgency × 0.5; User interaction tasks: adjustment coefficient = scenario urgency × 0.3; Backend service tasks: adjustment coefficient = scenario urgency × 0.1.

[0082] Through this standardized evaluation system, the system can objectively assess different types of tasks, ensuring a reasonable ranking of task importance across various scenarios. For example, in high-risk scenarios (urgency level 0.8), the final importance of autonomous driving assistance tasks can reach 0.95 (base importance 0.8 × (1 + 0.8 × 0.5)), while the importance of music playback tasks is only 0.22 (base importance 0.2 × (1 + 0.8 × 0.1)), thus guaranteeing the resource priority of critical tasks.

[0083] Similarly, for the second task request in the second operating system (Linux system), the system assesses its second importance based on the urgency of the scenario. For example, the lane keeping assist task receives the highest importance (0.95) in the high-speed lane change scenario because it is directly related to driving safety; while the background logging task has a lower importance (0.15) and can be appropriately delayed in execution.

[0084] After completing the importance assessment, the system sorts all task requests uniformly, generating a priority list. The sorting algorithm employs an improved quicksort, supporting secondary evaluation of tasks with similar importance (difference < 0.1), taking into account historical execution data and resource utilization efficiency. The final priority list reflects both the task importance ranking and detailed attribute information for each task, providing a basis for subsequent resource adjustments.

[0085] Based on the above embodiments, as an optional implementation, in S41, determining the first importance of the first task request and the second importance of the second task request by combining vehicle speed information, driving status information, and surrounding environment information specifically includes S411-S413:

[0086] S411, obtain the preset mapping relationship between task types and importance.

[0087] The system first loads a pre-defined task type-importance mapping table from the configuration database. This mapping is stored in a multi-dimensional matrix structure, including a task type dimension and a scenario dimension. The task type dimension covers all possible task types, such as:

[0088] Safety control category: "SAFETY_CTRL"; Driving assistance category: "DRIVE_ASSIST"; Information display category: "INFO_DISPLAY"; Entertainment application category: "ENTERTAINMENT"; Each task type has a preset baseline importance value for different scenarios.

[0089] S412 combines vehicle speed information, driving status information, and surrounding environment information to generate the vehicle's operating scenario.

[0090] Next, the system generates the current operating scenario based on the real-time collected status information. Scene generation employs a scene fusion algorithm, which integrates standardized vehicle speed information, driving status information, and surrounding environment information to generate a scene feature vector. For example:

[0091] A vehicle speed of 135 km / h is mapped to "HIGH_SPEED" (high-speed scenario); a steering wheel angle of 20° is mapped to "LANE_CHANGE" (lane change scenario); and a distance from the vehicle in front that is less than the safe distance is mapped to "CLOSE_FOLLOWING" (following scenario). The system combines these features to generate a composite scenario identifier such as "HIGH_SPEED_LANE_CHANGE_CLOSE" (high-speed lane change and following).

[0092] S413, Based on the running scenario, determine the first importance of the first task request and the second importance of the second task request in the running scenario according to the mapping relationship.

[0093] After determining the operating scenario, the system queries the mapping matrix and calculates the task importance based on scenario characteristics. For the first task request in the first operating system, such as a navigation prompt task (type "NAV_GUIDANCE"), the system finds a baseline importance of 0.7 in the "HIGH_SPEED_LANE_CHANGE_CLOSE" scenario. Combining this with a scenario weighting coefficient (e.g., 1.2, representing an increase in importance for high-risk scenarios), the final calculated first importance is 0.84. Similarly, for the lane keeping task in the second operating system (type "LANE_KEEPING"), the system finds a baseline importance of 0.8, and after considering scenario weighting, the second importance is 0.96.

[0094] S105, adjust the resource allocation ratio of the first or second resource isolation zone according to the priority list.

[0095] After generating the task priority list, the system needs to dynamically adjust resource allocation based on the importance of the tasks to ensure that critical tasks can still obtain sufficient execution resources even under resource constraints. Resource allocation ratio refers to the percentage of system resources available in each resource isolation zone, including CPU time slice ratio, memory capacity ratio, and I / O bandwidth allocation ratio.

[0096] The system first calculates the amount of resources that need to be adjusted. When the resource utilization rate of the first resource isolation region exceeds the first preset threshold (85%), the system calculates the excess resource amount, which is called the first excess. For example, if the current memory utilization rate of the first operating system (Android system) reaches 95%, and the first preset threshold is 85%, then the first excess is 10% of memory resources. Similarly, when the resource utilization rate of the second resource isolation region exceeds the second preset threshold (90%), the second excess is calculated.

[0097] When adjusting resources based on the priority list, the system employs a two-stage adjustment strategy. The first stage is resource reclamation, where the system analyzes low-priority tasks one by one, starting from the bottom of the priority list. For non-critical tasks in the primary operating system, such as background application updates and media caching, the system reduces their resource quotas through the Linux cgroups mechanism. Specifically, the system might reduce the CPU quota of a low-priority task from 20% to 5%, or reduce its memory limit from 1GB to 256MB. These reclaimed resources form an available resource pool for reallocation.

[0098] The second phase is resource reallocation, where the system prioritizes the reclaimed resources for tasks at the top of the priority list. For example, when a vehicle is detected to be in an emergency avoidance scenario, the collision warning task in the second operating system (Linux system) may receive additional CPU cores and memory resources, and its CPU time slice quota may increase from the original 30% to 50%. This dynamic adjustment is achieved through the cgroups subsystem of the Linux kernel and can complete resource reallocation in milliseconds.

[0099] To avoid system instability caused by resource adjustments, a smooth transition mechanism is employed during the adjustment process. The system sets a minimum adjustment step size (e.g., CPU quota adjustments do not exceed 5% each time) and introduces a buffer time window (typically 200ms) to ensure gradual changes in resource allocation. Simultaneously, the system maintains a historical record of resource adjustments to detect and prevent potential resource instability.

[0100] When multiple tasks simultaneously request resource upgrades, the system determines the resource allocation order based on the priority difference between the tasks. The larger the priority difference, the greater the resource allocation bias. For example, if a safety-critical task has a priority score of 0.95, while a regular task has a score of 0.3, the system might allocate 90% of the available resources to the safety-critical task and the remaining 10% to the regular task.

[0101] Based on the above embodiments, as an optional implementation, in S105, adjusting the resource allocation ratio of the first resource isolation region or the second resource isolation region according to the priority list specifically includes S51-S54:

[0102] S51, when the first resource utilization rate exceeds the first preset threshold, calculate the first excess amount of the first resource utilization rate exceeding the first preset threshold.

[0103] S52, based on the priority list, determine the first request that needs to be paused in the first task request, and adjust the first request according to the first excess, and determine the second request that needs to be paused in the first task request, so as to reduce the resource occupation of the first resource isolation area.

[0104] When the monitoring module detects that the resource utilization rate of the first operating system (Android system) exceeds the first preset threshold (85%), the system immediately calculates the first excess. For example, if the current CPU utilization reaches 95%, the first excess is 10% (95% - 85%). Similarly, when the resource utilization rate of the second operating system (Linux system) exceeds the second preset threshold (90%), the system calculates the second excess. These excess data directly reflect the degree of resource pressure, providing a quantitative basis for subsequent adjustments.

[0105] The system employs a progressive task adjustment strategy to handle resource overload. For the first operating system, the system first identifies the first adjustable request based on the priority list, starting from the bottom. The identification of adjustable tasks is based on multiple dimensions: task importance (prioritizing tasks with an importance of <0.3); resource consumption (prioritizing tasks with high resource consumption); and task interruptibility (prioritizing tasks that can be smoothly interrupted).

[0106] The adjustment process employs a tiered handling mechanism:

[0107] Minor adjustments (exceeding the limit by less than 5%): Reduce the task's resource quota (e.g., reduce the CPU quota by 50%); extend the task's execution cycle; reduce the task's refresh frequency;

[0108] Moderate adjustments (5% ≤ Excess < 10%): Suspend unnecessary background services; reduce interface rendering quality; disable some functional modules;

[0109] Heavy adjustment (exceeding the limit by ≥10%): Suspend all non-critical tasks; forcibly reclaim resources; terminate low-priority processes.

[0110] For example, when the first excess is 8%, the system first identifies the media playback task at the bottom of the priority list as the first request, reduces its CPU quota by 75% and lowers its audio sampling rate, which is expected to reduce resource usage by 3%. Then, the background synchronization task is identified as the second request, and its execution is paused to reclaim the remaining 5% of resource usage. The entire adjustment process is implemented through the cgroups mechanism to ensure the accuracy of resource reclamation.

[0111] S53, when the second resource utilization rate exceeds the second preset threshold, calculate the second excess amount of the second resource utilization rate exceeding the second preset threshold.

[0112] S54, based on the priority list, determine the third request that needs to be paused in the second task request, and adjust the third request according to the second excess, to determine the third request that needs to be paused in the third task request, so as to reduce the resource occupation of the second resource isolation area.

[0113] For the second operating system, a similar but more stringent adjustment strategy is employed. When a second excess is detected, the system prioritizes protecting real-time tasks and identifies non-real-time tasks as third-party requests for adjustment. Adjustment methods include: reducing the sampling frequency of non-critical sensors; extending the execution interval of diagnostic services; and merging similar data processing tasks.

[0114] After adjusting the resource allocation ratio of the first or second resource isolation zone, the specific details also include:

[0115] The system monitors the resource utilization rate of the first resource isolation zone and the resource utilization rate of the second resource isolation zone after the adjustment. When the resource utilization rate of the first resource isolation zone is lower than the third preset threshold, the second requests are restored to operation in the order of the priority list. When the resource utilization rate of the second resource isolation zone is lower than the fourth preset threshold, the fourth requests are restored to operation in the order of the priority list. The third preset threshold is lower than the first preset threshold, and the fourth preset threshold is lower than the second preset threshold.

[0116] To achieve efficient utilization of system resources and ensure a smooth transition in service quality, the system needs to continuously monitor resource usage and resume suspended tasks as needed after resource adjustments are completed. The settings of the third preset threshold (75%) and the fourth preset threshold (80%) create a buffer space for resource adjustments, avoiding frequent fluctuations in resource usage near critical values.

[0117] The system continuously collects the resource occupancy rates of the first and second resource isolation zones through a resource monitoring module, with a sampling period of 100ms, to ensure timely capture of changes in resource usage trends. When the first resource occupancy rate is detected to drop below a third preset threshold, it indicates that the resource pressure on the first operating system (Android system) has been alleviated, and the system initiates the task recovery process.

[0118] The recovery process employs a gradual strategy. First, it retrieves the list of paused second requests from the priority list, then resumes tasks one by one in descending order of importance. For example, when resource utilization drops to 70%, the system first resumes the navigation prompt task (importance 0.8), observes for 5 seconds to confirm stable resource utilization, and then resumes the background data synchronization task (importance 0.6). Task recovery uses a smooth ramp-up mechanism, initially starting tasks with the minimum resource quota and then gradually increasing them to the normal quota over multiple monitoring periods. This approach avoids sudden changes in resource usage during task recovery.

[0119] Similarly, when the second resource utilization rate drops below the fourth preset threshold, the system performs a similar recovery process for the fourth request in the second operating system (Linux system). However, considering real-time requirements, the recovery process is more aggressive, with the recovery time for a single task controlled within 50ms. During the task recovery process, the system continuously monitors the changing trend of resource utilization rate. If an abnormal increase in resource usage is detected (an increase of more than 5% in a single monitoring cycle), the current recovery process is immediately paused, waiting for the resource utilization rate to stabilize again.

[0120] Based on the above method, this application also discloses an in-vehicle multi-system dynamic switching system, such as... Figure 2 As shown, Figure 2This is a schematic diagram of the structure of a vehicle-mounted multi-system dynamic switching system provided in an embodiment of this application. The system includes: an acquisition module, a first determination module, a second determination module, a generation module, and an adjustment module; wherein,

[0121] The system comprises the following modules: an acquisition module for acquiring a first task request from the vehicle's first operating system and a second task request from the second operating system, wherein the first and second operating systems are independent operating systems and the first and second task requests are task requests running in parallel; a first determination module for determining a first resource requirement of the first operating system based on the first task request and a second resource requirement of the second operating system based on the second task request; a second determination module for dividing the first operating system into a first resource isolation region based on the first resource requirement and a second resource isolation region based on the second resource requirement; a generation module for acquiring vehicle status information when the first resource occupancy rate in the first resource isolation region exceeds a first preset threshold, or the second resource occupancy rate in the second resource isolation region exceeds a second preset threshold, and sorting the first and second task requests according to their task importance from high to low based on the status information to generate a priority list; and an adjustment module for adjusting the resource allocation ratio of the first or second resource isolation region based on the priority list.

[0122] It should be noted that the system provided in the above embodiments is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0123] Please see Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device 1000 may include: at least one processor 1001, at least one network interface 1004, a user interface 1003, a memory 1005, and at least one communication bus 1002.

[0124] The communication bus 1002 is used to realize the connection and communication between these components.

[0125] The user interface 1003 may include a display screen and a camera. Optionally, the user interface 1003 may also include a standard wired interface and a wireless interface.

[0126] The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0127] The processor 1001 may include one or more processing cores. The processor 1001 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1005, and by calling data stored in the memory 1005. Optionally, the processor 1001 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 1001 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 1001 and may be implemented as a separate chip.

[0128] The memory 1005 may include random access memory (RAM) or read-only memory. Optionally, the memory 1005 may include a non-transitory computer-readable storage medium. The memory 1005 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 1005 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 1005 may also be at least one storage device located remotely from the aforementioned processor 1001. Figure 3 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for a vehicle-mounted multi-system dynamic switching method.

[0129] exist Figure 3 In the electronic device 1000 shown, the user interface 1003 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 1001 can be used to call an application program stored in the memory 1005 for a vehicle multi-system dynamic switching method. When executed by one or more processors, the electronic device performs one or more of the methods described in the above embodiments.

[0130] An electronic device readable storage medium stores instructions that, when executed by one or more processors, cause the electronic device to perform one or more of the methods described in the above embodiments.

[0131] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0132] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0133] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and 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 displayed or discussed mutual couplings, direct couplings, or communication connections may be through some service interfaces; indirect couplings or communication connections between devices or units may be electrical or other forms.

[0134] 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.

[0135] Furthermore, 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0136] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 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 described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0137] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will be readily apparent to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described herein. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for dynamic switching of multiple systems on a vehicle, the method comprising: The method comprises: obtaining a first task request of a first operating system of a vehicle and a second task request of a second operating system, the first operating system and the second operating system being different operating systems running independently, the first task request and the second task request being task requests running in parallel; determining a first resource requirement of the first operating system according to the first task request, and determining a second resource requirement of the second operating system according to the second task request; dividing a first resource isolation area for the first operating system according to the first resource requirement, and dividing a second resource isolation area for the second operating system according to the second resource requirement; when a first resource occupancy rate in the first resource isolation area exceeds a first preset threshold or a second resource occupancy rate in the second resource isolation area exceeds a second preset threshold, obtaining state information of the vehicle, sorting the first task request and the second task request according to task importance from high to low according to the state information, and generating a priority list; adjusting a resource allocation ratio of the first resource isolation area or the second resource isolation area according to the priority list.

2. The vehicle-mounted multi-system dynamic switching method according to claim 1, wherein, The determining of the first resource requirement of the first operating system according to the first task request and the determining of the second resource requirement of the second operating system according to the second task request comprise: obtaining a first task type corresponding to the first task request and a second task type corresponding to the second task request; determining the first resource requirement corresponding to the first task type and the second resource requirement corresponding to the second task type from a pre-stored resource requirement database.

3. The vehicle-mounted multi-system dynamic switching method of claim 1, wherein, The dividing of the first resource isolation area for the first operating system according to the first resource requirement and the dividing of the second resource isolation area for the second operating system according to the second resource requirement comprise: obtaining a total resource amount of a vehicle-mounted system of the vehicle, a first system type of the first operating system, and a second system type of the second operating system; determining a first reserved resource amount of the first system type and a second reserved resource amount of the second system type; determining a first resource allocation ratio of the first operating system according to a first ratio of the first resource requirement to the total resource amount, and dividing the first resource isolation area for the first operating system in combination with the first resource allocation ratio and the first reserved resource amount; determining a second resource allocation ratio of the second operating system according to a second ratio of the second resource requirement to the total resource amount, and dividing the second resource isolation area for the second operating system in combination with the second resource allocation ratio and the second reserved resource amount.

4. The vehicle-mounted multi-system dynamic switching method of claim 1, wherein, The state information comprises vehicle speed information, driving state information, and surrounding environment information, and the sorting of the first task request and the second task request according to task importance from high to low according to the state information to generate a priority list comprises: Determine a first importance degree of the first task request and a second importance degree of the second task request in combination with the vehicle speed information, the driving state information and the surrounding environment information; Sort the first task request and the second task request according to the first importance degree and the second importance degree from high to low to generate a priority list.

5. The vehicle-mounted multi-system dynamic switching method of claim 4, wherein, The determination of the first importance degree of the first task request and the second importance degree of the second task request in combination with the vehicle speed information, the driving state information and the surrounding environment information comprises: Obtain a preset mapping relationship between task types and importance degrees; Generate an operation scene of the vehicle in combination with the vehicle speed information, the driving state information and the surrounding environment information; Determine the first importance degree of the first task request and the second importance degree of the second task request in the operation scene according to the mapping relationship on the basis of the operation scene.

6. The vehicle-mounted multi-system dynamic switching method of claim 1, wherein, The adjustment of the resource allocation proportion of the first resource isolation region or the second resource isolation region according to the priority list comprises: When the first resource occupancy rate exceeds a first preset threshold, calculate a first excess amount by which the first resource occupancy rate exceeds the first preset threshold; Determine a first request that needs to be suspended in the first task request according to the priority list, and adjust the first request according to the first excess amount to determine a second request that needs to be suspended in the first task request; When the second resource occupancy rate exceeds a second preset threshold, calculate a second excess amount by which the second resource occupancy rate exceeds the second preset threshold; Determine a third request that needs to be suspended in the second task request according to the priority list, and adjust the third request according to the second excess amount to determine a fourth request that needs to be suspended in the second task request.

7. The vehicle-mounted multi-system dynamic switching method of claim 6, wherein, After the adjustment of the resource allocation proportion of the first resource isolation region or the second resource isolation region, further comprising: Monitor the first resource occupancy rate of the adjusted first resource isolation region and the second resource occupancy rate of the second resource isolation region; When the first resource occupancy rate is lower than a third preset threshold, sequentially restore the second request to run according to the order of the priority list; When the second resource occupancy rate is lower than a fourth preset threshold, sequentially restore the fourth request to run according to the order of the priority list, wherein the third preset threshold is smaller than the first preset threshold, and the fourth preset threshold is smaller than the second preset threshold.

8. An in-vehicle multi-system dynamic switching system, characterized by, The system comprises an acquisition module, a first determination module, a second determination module, a generation module and an adjustment module, wherein: The acquisition module is configured to acquire a first task request of a first operating system of a vehicle and a second task request of a second operating system, the first operating system and the second operating system are different operating systems running independently, and the first task request and the second task request are task requests running in parallel; The first determining module is configured to determine a first resource requirement of the first operating system according to the first task request, and determine a second resource requirement of the second operating system according to the second task request; The second determining module is configured to divide a first resource isolation area for the first operating system according to the first resource requirement, and divide a second resource isolation area for the second operating system according to the second resource requirement; The generating module is configured to, when a first resource occupancy rate in the first resource isolation area exceeds a first preset threshold or a second resource occupancy rate in the second resource isolation area exceeds a second preset threshold, acquire state information of the vehicle, sort the first task request and the second task request according to task importance from high to low according to the state information, and generate a priority list; The adjusting module is configured to adjust a resource allocation proportion of the first resource isolation area or the second resource isolation area according to the priority list.

9. An electronic device, comprising: An electronic device includes a processor, a memory, a user interface, and a network interface. The memory is configured to store instructions. The user interface and the network interface are configured to communicate with other devices. The processor is configured to execute the instructions stored in the memory to cause the electronic device to perform the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, A computer program is stored in a memory and can be loaded and executed by a processor to perform the method of any one of claims 1-7.

Images