Computing power scheduling method and device of vehicle, vehicle and storage medium

Abstract

This application relates to a vehicle computing power scheduling method, apparatus, vehicle, and storage medium. Based on a vehicle's parking confidence index, the method marks the vehicle as being in a parking schedulable state. In response to this marking, based on multi-dimensional state feature data, the method determines the predicted parking duration and prediction confidence of the vehicle, and based on multi-dimensional computing power evaluation indicators, determines the vehicle's comprehensive confidence. Vehicles with a comprehensive confidence greater than a preset threshold are added to a schedulable resource pool. Based on task feature information, the method labels the tasks to be processed, and based on the labeling results, predicted parking duration, and comprehensive confidence, the method determines the target vehicle for the task from the schedulable resource pool and schedules the target vehicle to execute the task. This solves the problems of related technologies lacking fine-grained differentiation between parking and driving conditions, lacking the ability to predict parking time, and being unable to guarantee continuous task execution, thus achieving efficient utilization of vehicle computing power resources.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a vehicle computing power scheduling method, device, vehicle, and storage medium. Background Technology

[0002] The vehicle not only undertakes core driving functions such as autonomous driving and intelligent cockpit, but its idle computing resources also have great potential to participate in tasks such as distributed computing and cloud-edge collaboration.

[0003] The vehicle computing power scheduling schemes in related technologies mainly allocate resources based on the real-time task requirements during driving, focusing on ensuring driving safety and low-latency response of driving assistance systems.

[0004] However, the relevant technologies have the following problems: on the one hand, they lack a fine distinction between parking and driving conditions, and cannot dynamically identify the computing power redundancy during parking, resulting in resource shortages during driving and wasted computing power during parking; on the other hand, they lack the ability to predict parking time windows, making it difficult to ensure the continuous execution of tasks, and tasks are easily interrupted due to unexpected vehicle starts, which urgently needs to be solved. Summary of the Invention

[0005] This application provides a vehicle computing power scheduling method, device, vehicle, and storage medium to solve the problems of related technologies lacking fine distinction between parking and driving conditions, lacking the ability to predict parking time windows, and making it difficult to ensure the continuous execution of tasks.

[0006] The first aspect of this application provides a method for scheduling computing power for vehicles, comprising the following steps: Based on the vehicle's parking confidence index, the vehicle is marked as having a parking schedulable state. In response to the parking schedulable state marker, the predicted parking duration and prediction confidence of the vehicle are determined based on multi-dimensional state feature data; Based on the multi-dimensional computing power evaluation index and the prediction confidence level, the comprehensive confidence level of the vehicle is determined, and vehicles with a comprehensive confidence level greater than a preset threshold are added to the schedulable resource pool. Based on the task feature information, the task to be processed is labeled to obtain the labeling results. Based on the labeling results of the task, the predicted parking time and the comprehensive confidence level, the target vehicle of the task to be processed is determined from the schedulable resource pool, and the target vehicle is scheduled to execute the task to be processed.

[0007] Optionally, in some embodiments, marking the vehicle as parkable and schedulable based on the vehicle's parking confidence index includes: Acquire the vehicle's status data, charging data, and location data; Based on the status data, the charging data, and the location data, determine whether the vehicle meets the preset scheduling conditions; If the vehicle meets the preset scheduling conditions, the parking confidence score of the vehicle is determined based on the status data, the charging data and the positioning data, and it is determined whether the parking confidence score is higher than the preset score threshold. If the parking confidence score is higher than the preset score threshold, the vehicle is marked as parking available; otherwise, the vehicle is marked as parking pending confirmation.

[0008] Optionally, in some embodiments, determining the predicted parking duration and prediction confidence of the vehicle based on multidimensional state feature data includes: Obtain the historical and current state feature data of the vehicle; The historical state feature data is input into a preset parking duration prediction model to obtain the first parking duration and the first confidence level; The predicted parking duration and the predicted confidence level are obtained by correcting the first parking duration and the first confidence level based on the current state feature data.

[0009] Optionally, in some embodiments, determining the overall confidence level of the vehicle based on the multidimensional computing power evaluation index and the prediction confidence level includes: Obtain the multi-dimensional computing power evaluation index of the vehicle, wherein the multi-dimensional computing power evaluation index includes at least one of the following: available computing power score, power supply stability score and network quality score; The comprehensive confidence level is obtained by weighted fusion calculation of the predicted confidence level and the multidimensional computing power evaluation index.

[0010] Optionally, in some embodiments, the step of annotating the task to be processed based on task feature information to obtain annotation results includes: Obtain the task feature information of the task to be processed, wherein the task feature information includes at least one of the following: type of computing resource consumption, computing timeliness requirements, estimated execution time and task fault tolerance requirements; Based on the type of computing resource consumption, the computing density label of the task to be processed is determined, and the computing density label includes: CPU intensive, GPU intensive, or memory intensive. Based on the aforementioned computational timeliness requirements, the time sensitivity labels of the tasks to be processed are determined, and the time sensitivity labels include real-time, near real-time, or batch processing. Based on the estimated execution time, determine the expected execution duration label for the task to be processed; Based on the aforementioned task fault tolerance requirements, a fault tolerance requirement label is determined for the task to be processed. The fault tolerance requirement label includes: interruptible or non-interruptible. The annotation result is generated by combining the calculated density label, the time sensitivity label, the expected execution time label, and the fault tolerance requirement label.

[0011] Optionally, in some embodiments, determining the target vehicle for the task to be processed from the schedulable resource pool based on the task's annotation results, the predicted parking duration, and the overall confidence level includes: The labeling results of the task to be processed, the predicted parking time of the vehicles in the schedulable resource pool, and the comprehensive confidence level are input into a preset scheduling model to obtain the task-vehicle matching relationship, so as to determine the target vehicle of the task to be processed based on the task-vehicle matching relationship.

[0012] Optionally, in some embodiments, after scheduling the target vehicle to perform the task to be processed, the process includes: Determine whether the target vehicle's start-up intention has been received; If the target vehicle's intention to start is received, the pending task is interrupted, and the target vehicle's computing resources are reclaimed.

[0013] A second aspect of this application provides a vehicle computing power scheduling device, comprising: The marking module is used to mark the vehicle as being in a schedulable parking state based on the vehicle's parking confidence index. The prediction module is used to determine the predicted parking duration and prediction confidence of the vehicle based on multi-dimensional state feature data in response to the parking schedulable state marker. The evaluation module is used to determine the comprehensive confidence level of the vehicle based on the multi-dimensional computing power evaluation index and the prediction confidence level, and to add vehicles with a comprehensive confidence level greater than a preset threshold to the schedulable resource pool. The scheduling module is used to label the task to be processed based on task feature information to obtain labeling results, and to determine the target vehicle of the task to be processed from the schedulable resource pool based on the labeling results of the task, the predicted parking time and the comprehensive confidence level, and to schedule the target vehicle to execute the task to be processed.

[0014] Optionally, in some embodiments, the marking module includes: The first acquisition unit is used to acquire the vehicle's status data, charging data, and location data. The first judgment unit is used to determine whether the vehicle meets the preset scheduling conditions based on the status data, the charging data and the positioning data. The second judgment unit is used to determine the parking confidence score of the vehicle based on the status data, the charging data and the positioning data when the vehicle meets the preset scheduling conditions, and to determine whether the parking confidence score is higher than the preset score threshold. The marking unit is used to mark the vehicle as parking dispatchable if the parking confidence score is higher than the preset score threshold, and otherwise mark the vehicle as parking pending confirmation.

[0015] Optionally, in some embodiments, the prediction module includes: The second acquisition unit is used to acquire the historical state feature data and current state feature data of the vehicle. The prediction unit is used to input the historical state feature data into a preset parking duration prediction model to obtain the first parking duration and the first confidence level; The correction unit is used to correct the first parking duration and the first confidence level based on the current state feature data to obtain the predicted parking duration and the predicted confidence level.

[0016] Optionally, in some embodiments, the evaluation module includes: The third acquisition unit is used to acquire the multi-dimensional computing power evaluation index of the vehicle, wherein the multi-dimensional computing power evaluation index includes at least one of the following: available computing power score, power supply stability score and network quality score; The fusion unit is used to perform weighted fusion calculation of the predicted confidence level and the multi-dimensional computing power evaluation index to obtain the comprehensive confidence level.

[0017] Optionally, in some embodiments, the scheduling module includes: The fourth acquisition unit is used to acquire the task feature information of the task to be processed, wherein the task feature information includes at least one of the following: computing resource consumption type, computing timeliness requirements, estimated execution time and task fault tolerance requirements; The first determining unit is configured to determine the computing density label of the task to be processed based on the computing resource consumption type, wherein the computing density label includes: CPU (Central Processing Unit) intensive, GPU (Graphics Processing Unit) intensive, or memory intensive. The second determining unit is used to determine the time sensitivity label of the task to be processed based on the computation timeliness requirements, wherein the time sensitivity label includes real-time, near real-time, or batch processing. The third determining unit is used to determine the estimated execution time label of the task to be processed based on the estimated execution time; The fourth determining unit is used to determine the fault tolerance requirement label of the task to be processed based on the task fault tolerance requirements. The fault tolerance requirement label includes: interruptible or non-interruptible. The combination unit is used to combine the computation density label, the time sensitivity label, the expected execution time label, and the fault tolerance requirement label to generate the annotation result.

[0018] Optionally, in some embodiments, the scheduling module includes: The matching unit is used to input the labeling results of the task to be processed, the predicted parking time of the vehicles in the schedulable resource pool, and the comprehensive confidence level into a preset scheduling model to obtain the task-vehicle matching relationship, so as to determine the target vehicle of the task to be processed based on the task-vehicle matching relationship.

[0019] Optionally, in some embodiments, after scheduling the target vehicle to perform the task to be processed, the scheduling module includes: The third judgment unit is used to determine whether the starting intention of the target vehicle has been received; The recycling unit is used to interrupt the pending task and reclaim the computing resources of the target vehicle upon receiving the start-up intention of the target vehicle.

[0020] A third aspect of this application provides a vehicle, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle computing power scheduling method as described in the above embodiments.

[0021] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the vehicle computing power scheduling method as described in the above embodiments.

[0022] Therefore, by using a parking confidence index, vehicles are marked as being in a schedulable parking state. In response to this marking, based on multi-dimensional state feature data, the predicted parking duration and prediction confidence of the vehicle are determined. Furthermore, based on multi-dimensional computing power evaluation indicators and prediction confidence, the overall confidence of the vehicle is determined. Vehicles with an overall confidence greater than a preset threshold are added to the schedulable resource pool. Based on task feature information, the tasks to be processed are labeled to obtain labeling results. Then, based on the labeling results, predicted parking duration, and overall confidence, the target vehicle for the task is selected from the schedulable resource pool, and the target vehicle is scheduled to execute the task. This solves the problems of related technologies lacking fine-grained differentiation between parking and driving conditions, lacking the ability to predict parking time, and being unable to guarantee continuous task execution, thus achieving efficient utilization of vehicle computing resources.

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

[0024] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a vehicle computing power scheduling method provided according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating the principle of a parking schedulable state marker according to an embodiment of this application; Figure 3 This is a schematic diagram illustrating the principle of parking window prediction according to an embodiment of this application; Figure 4 This is a schematic diagram illustrating the principle of multidimensional computing power evaluation according to an embodiment of this application; Figure 5 This is a schematic diagram illustrating the principle of task matching according to an embodiment of this application; Figure 6 This is a schematic diagram illustrating the principle of a vehicle computing power scheduling method according to an embodiment of this application; Figure 7 This is a block diagram of a vehicle computing power scheduling device provided according to an embodiment of this application; Figure 8 This is a structural schematic diagram of a vehicle provided according to an embodiment of this application. Detailed Implementation

[0025] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0026] Before introducing the vehicle computing power scheduling of the embodiments of this application, let's first introduce the problems of vehicle computing power scheduling schemes in related technologies: To address the aforementioned technical problems, this application provides a vehicle computing power scheduling method. In this method, vehicles are marked as schedulable in a parked state based on their parking confidence index. In response to this marking, the predicted parking duration and prediction confidence of the vehicle are determined based on multi-dimensional state feature data. Furthermore, the comprehensive confidence of the vehicle is determined based on multi-dimensional computing power evaluation indicators and the prediction confidence. Vehicles with a comprehensive confidence greater than a preset threshold are added to a schedulable resource pool. Based on task feature information, the tasks to be processed are labeled to obtain labeling results. Based on the labeling results, predicted parking duration, and comprehensive confidence, the target vehicle for the task is determined from the schedulable resource pool, and the target vehicle is scheduled to execute the task. This solves the problems of related technologies lacking fine-grained differentiation between parking and driving conditions, lacking the ability to predict parking time, and being unable to guarantee continuous task execution, thus achieving efficient utilization of vehicle computing power resources.

[0027] Specifically, Figure 1 This is a flowchart illustrating a vehicle computing power scheduling method provided in an embodiment of this application.

[0028] like Figure 1 As shown, the computing power scheduling method for this vehicle includes the following steps: In step S101, the vehicle is marked as parkable based on the vehicle's parking confidence index.

[0029] Furthermore, in some embodiments, the vehicle is marked as parkable and schedulable based on its parking confidence index, including: acquiring the vehicle's status data, charging data, and location data; determining whether the vehicle meets preset scheduling conditions based on the status data, charging data, and location data; if the vehicle meets the preset scheduling conditions, determining the vehicle's parking confidence score based on the status data, charging data, and location data, and determining whether the parking confidence score is higher than a preset score threshold; if the parking confidence score is higher than the preset score threshold, marking the vehicle as parkable and schedulable; otherwise, marking the vehicle as parkable and pending confirmation.

[0030] The vehicle's parking confidence index includes at least one of the following: vehicle status data, charging data, and location data; the preset scheduling conditions can be pre-set by relevant personnel in the art to determine whether the vehicle meets the conditions for entering the computing power scheduling.

[0031] Specifically, in this embodiment, the system first acquires vehicle status data, charging data, and location data. Based on these three types of data, it comprehensively judges whether the vehicle meets preset scheduling conditions. If the vehicle meets the preset scheduling conditions, the system will further calculate the vehicle's parking confidence score based on the above data and compare the score with a preset score threshold. If the parking confidence score is higher than the preset score threshold, it indicates that the vehicle is in a highly stable parking state, and the system marks the vehicle as a parking schedulable state, allowing its idle computing power to be allocated to tasks. Conversely, if the score does not exceed the threshold, the vehicle is marked as a parking pending confirmation state to avoid task interruption due to unstable vehicle status, thereby ensuring the security and reliability of computing power scheduling.

[0032] In actual implementation, such as Figure 2 As shown, the embodiments of this application can integrate multi-source sensor signals and cloud historical data to make a comprehensive judgment on the parking status: (1) Vehicle CAN (Controller Area Network) bus signal fusion: Real-time acquisition of gear position signal (P gear), electronic parking brake EPB (Electronic Parking Brake) status, ignition switch status (IGNOFF), vehicle speed signal (V=0) to build a basic parking confidence level; (2) Charging gun physical connection detection: Through BMS (Battery Management System), the charging gun CC (Connect Confirmation) / CP (Control Pilot) signals are detected to determine whether it is in AC slow charging or DC fast charging state, which serves as a key input for power supply stability assessment. (3) GPS (Global Positioning System) / BeiDou positioning and parking pattern recognition: The vehicle's latitude and longitude are obtained through high-precision positioning. Combined with the residential areas, office areas, commercial parking lots, highway service areas, etc. marked by the cloud map POI (Point of Interest) database, the cloud identifies the vehicle's repeated parking patterns based on historical trajectory clustering. For example, parking in the residential basement from 20:00 to 07:00 the next day provides prior knowledge for parking window prediction. (4) Parking confidence score algorithm: Based on the above signals, the parking confidence score P_conf∈[0,1] is calculated. When P_conf>threshold τ (e.g., 0.9), the vehicle is marked as "parking schedulable state".

[0033] Therefore, this application embodiment integrates four types of information across domains: vehicle CAN bus signal, charging gun physical connection detection, GPS / BeiDou positioning and cloud POI matching, and historical trajectory clustering, to construct a parking confidence scoring algorithm (P_conf). This multi-source fusion scheme solves the pain point that related technologies cannot accurately distinguish between driving and parking states, and is a prerequisite for realizing safe scheduling of parking computing power.

[0034] It should be noted that in some embodiments, the engine speed of a gasoline vehicle or the Ready signal of an electric vehicle can be read through the OBD-II (On-Board Diagnostic) interface to determine whether the vehicle is in a parked state. Additionally, the vehicle owner can manually mark "parking start / end" via a mobile app to inform the cloud of the vehicle's status. Furthermore, geomagnetic sensors or cameras can be deployed in parking lots to indirectly infer the parking status by detecting parking space occupancy. Preferably, the multi-source fusion scheme adopted in this application embodiment utilizes the vehicle's own sensors and cloud-based POI data, requiring no additional hardware investment, covering all parking scenarios (including roadside parking without infrastructure and private parking spaces), and multi-signal cross-verification reduces the false judgment rate.

[0035] In step S102, in response to the parking schedulable state marker, the predicted parking duration and prediction confidence of the vehicle are determined based on multidimensional state feature data.

[0036] Furthermore, in some embodiments, determining the predicted parking duration and prediction confidence of a vehicle based on multidimensional state feature data includes: acquiring historical state feature data and current state feature data of the vehicle; inputting the historical state feature data into a preset parking duration prediction model to obtain a first parking duration and a first confidence; and correcting the first parking duration and the first confidence based on the current state feature data to obtain the predicted parking duration and prediction confidence.

[0037] Among them, historical state feature data is vehicle historical behavior data, and current state feature data is real-time context data.

[0038] Specifically, in response to the parking availability flag, this embodiment of the application acquires the vehicle's historical state feature data and current state feature data. Subsequently, the system inputs the historical state feature data into a preset parking duration prediction model, and by mining the vehicle's past parking patterns, initially outputs a first parking duration and a first confidence level. To further improve the accuracy of the prediction, the system dynamically corrects the first parking duration and the first confidence level based on the current state feature data, thereby ultimately obtaining an accurate predicted parking duration and prediction confidence level.

[0039] In actual implementation, such as Figure 3As shown, the cloud uses an LSTM (Long-Short Term Memory) / Transformer time series model based on historical vehicle trajectory data to learn the periodic patterns of vehicle parking, outputting the predicted parking duration distribution. Based on real-time context information such as the current time, the target charging SOC value, and the vehicle's recent travel plans, the prediction results are corrected using Bayesian methods. The prediction window is divided into three levels according to confidence: high certainty (prediction window > 4 hours, confidence > 0.9), medium certainty (prediction window 1-4 hours, confidence 0.7-0.9), and low certainty (prediction window < 1 hour, confidence < 0.7).

[0040] Therefore, the embodiments of this application use a deep time series model to learn the cross-scale periodic patterns of vehicle parking behavior, such as daily, weekly, and monthly cycles, and combine them with real-time contexts such as charging SOC target value and navigation destination for Bayesian correction. This allows for the prediction of available computing power windows for the next few hours at the beginning of vehicle parking, providing deterministic assurance for refined task scheduling.

[0041] It should be noted that in some embodiments, the average parking time at the same POI location over the past 30 days can be directly used as the prediction value without introducing a deep learning model; alternatively, the vehicle state (driving, short-term parking, long-term parking, etc.) can be modeled as a finite-state Markov chain, and prediction can be made through the state transition probability matrix; in addition, travel plans can be inferred by accessing the vehicle owner's calendar API or weather forecast API. Preferably, the LSTM / Transformer time series model adopted in the embodiments of this application can automatically learn cross-scale periodic patterns, and with real-time Bayesian correction, the prediction error can be reduced and controlled. Moreover, all predictions are based on the vehicle's own anonymized trajectory data, without accessing user privacy data, achieving the best balance between accuracy and compliance.

[0042] In step S103, based on multi-dimensional computing power evaluation indicators and prediction confidence, the comprehensive confidence of the vehicle is determined, and vehicles with a comprehensive confidence greater than a preset threshold are added to the schedulable resource pool.

[0043] Optionally, in some embodiments, determining the overall confidence level of a vehicle based on multidimensional computing power evaluation indicators and prediction confidence levels includes: obtaining multidimensional computing power evaluation indicators for the vehicle, wherein the multidimensional computing power evaluation indicators include at least one of available computing power score, power supply stability score, and network quality score; and performing weighted fusion calculation of prediction confidence level and multidimensional computing power evaluation indicators to obtain the overall confidence level.

[0044] Specifically, this embodiment first obtains multi-dimensional computing power evaluation indicators for vehicles, focusing on collecting at least one of the following data: available computing power score, power supply stability score, and network quality score. The system then performs a weighted fusion calculation with the predicted confidence level obtained in the preceding steps and the aforementioned multi-dimensional computing power evaluation indicators. Based on a preset weighting strategy, the importance of time stability and computing power performance is balanced to obtain a comprehensive confidence level that fully reflects the scheduling value of vehicles. Finally, the system compares the calculated comprehensive confidence level with a preset threshold and only includes vehicles with a comprehensive confidence level greater than the preset threshold in the schedulable resource pool.

[0045] In actual implementation, such as Figure 4 As shown, the embodiments of this application can construct a real-time dynamic evaluation model of the computing power resources of parked vehicles: (1) Evaluation of remaining computing power: Real-time collection of indicators such as CPU idle rate, available computing power (TOPS) of GPU / NPU, idle memory, and idle storage capacity through vehicle-side TMA (Trusted Metering Agent). (2) Evaluation of available time: Take the minimum value between the predicted remaining parking time and the power consumption cutoff time for external computing power set by the user, and match and verify it with the expected execution time of the task. (3) Evaluation of power supply stability: Distinguish between plug-in charging (stable power supply, P_stable>0.95), battery power supply but SOC>60% (substable, P_stable0.8-0.95), and battery power supply and SOC<60% (unstable, P_stable<0.8). (4) Evaluation of network quality: Test the real-time uplink bandwidth, latency, and jitter of 5G / C-V2X / Wi-Fi of the vehicle, and generate a network quality score.

[0046] However, in this application embodiment, a schedulable computing resource pool is constructed: vehicle nodes that meet the requirements of "schedulable parking, stable power supply, and network quality" are aggregated in real time in the cloud to form a unified schedulable computing resource pool, which is continuously updated.

[0047] Therefore, this application establishes a dynamic evaluation model for parking computing power covering six dimensions: remaining CPU computing power, available GPU / NPU TOPS, idle memory, idle storage, network quality, and power supply stability. The cloud aggregates vehicle nodes that meet the criteria in real time based on the six-dimensional comprehensive score, forming a unified pool of schedulable computing resources, thus avoiding the coarse-grained evaluation method that relies solely on a single CPU utilization rate.

[0048] In step S104, the task to be processed is labeled according to the task feature information to obtain the labeling results. Based on the labeling results of the task, the predicted parking time and the comprehensive confidence level, the target vehicle of the task to be processed is determined from the schedulable resource pool, and the target vehicle is scheduled to execute the task to be processed.

[0049] Optionally, in some embodiments, the annotation of the task to be processed based on task feature information to obtain annotation results includes: obtaining task feature information of the task to be processed, wherein the task feature information includes at least one of: computing resource consumption type, computing timeliness requirement, estimated execution time and task fault tolerance requirement; determining the computing density label of the task to be processed based on the computing resource consumption type, wherein the computing density label includes: CPU intensive, GPU intensive or memory intensive; determining the time sensitivity label of the task to be processed based on the computing timeliness requirement, wherein the time sensitivity label includes real-time, near real-time or batch; determining the expected execution duration label of the task to be processed based on the estimated execution time; determining the fault tolerance requirement label of the task to be processed based on the task fault tolerance requirement, wherein the fault tolerance requirement label includes: interruptible or non-interruptible; and combining the computing density label, time sensitivity label, expected execution duration label and fault tolerance requirement label to generate annotation results.

[0050] Specifically, this application embodiment parses the task attribute information of the task to be processed, and extracts features of the task from four dimensions: type of computing resource consumption, computing timeliness requirements, estimated execution time, and task fault tolerance level. Based on the extracted features, resource type labels representing computing density, timeliness level labels representing time sensitivity, duration labels representing estimated execution time, and fault tolerance labels representing fault tolerance requirements are generated respectively. The resource type labels, timeliness level labels, duration labels, and fault tolerance labels are combined to obtain the annotation results, and the task to be processed is classified according to the annotation results, and long-duration high deterministic tasks, medium-duration medium deterministic tasks, and short-duration low deterministic tasks are identified.

[0051] In actual implementation, such as Figure 5 As shown in the figure, this application embodiment can perform four-dimensional labeling on each task in the cloud task queue based on "computation density (CPU intensive / GPU intensive / memory intensive), time sensitivity (real-time / near real-time / batch), estimated execution time, and fault tolerance requirements (interruptible / non-interruptible)" to classify tasks according to the four-dimensional labeling.

[0052] Optionally, in some embodiments, determining the target vehicle for the task to be processed from the schedulable resource pool based on the task's annotation results, predicted parking duration, and overall confidence level includes: inputting the task's annotation results, the predicted parking duration of vehicles in the schedulable resource pool, and the overall confidence level into a preset scheduling model to obtain the task-vehicle matching relationship, so as to determine the target vehicle for the task to be processed based on the task-vehicle matching relationship.

[0053] It is understandable that, in the task allocation process, this application embodiment can prioritize allocating long-term, high-deterministic tasks, such as large model parameter fine-tuning, batch data preprocessing, and offline map rendering tasks, to vehicles parked at night for charging, i.e., parking windows > 4 hours and confidence levels > 0.9; allocate medium-term, medium-deterministic tasks, such as regional traffic flow analysis and video clip batch processing, to vehicles parked in daytime office / commercial areas, i.e., parking windows between 1 and 4 hours and confidence levels between 0.7 and 0.9; and allocate short-term, low-deterministic tasks, such as lightweight AI inference, data compression, and log processing, to vehicles parked for short periods, i.e., parking windows between 15 and 60 minutes.

[0054] In actual implementation, such as Figure 5 As shown, this embodiment of the application adopts the MAPPO (Multi-Agent Proximal Policy Optimization) algorithm to model task scheduling as Dec-POMDP (Decentralized Partially Observable Markov Decision Process). The cloud scheduling agent dynamically optimizes the scheduling decision based on the real-time resource pool status and task queue status, and performs task-vehicle matching with the overall system throughput, task success rate and energy consumption as joint optimization objectives.

[0055] The following describes the construction process of the preset scheduling model: (1) Task-vehicle bidirectional matching constraint model: Construct a binary feasibility constraint matrix M. Task i can be scheduled to vehicle j only when the matrix value is 1, as shown in the following formula: Mij=1[Wj≥Di] 1[Cj≥Ri] 1[Pj≥Pmin] 1[Nj≥Nmin]; Where: Wj is the predicted remaining parking time of the vehicle, Di is the estimated execution time of the task, Cj is the available computing power of the vehicle, Ri is the minimum computing power requirement of the task, Pj is the power supply stability score, and Nj is the network quality score.

[0056] (2) Level 3 task - window matching rules.

[0057] Task classification: L1 long-duration batch processing tasks (duration > 4h, GPU intensive, breakpoint resumeable), L2 mid-duration near-real-time tasks (1h < duration ≤ 4h, mixed load), L3 short-duration lightweight tasks (duration ≤ 1h, low-latency inference).

[0058] Vehicle window classification: H level (duration > 4h, confidence level > 0.9, plug-in charging), M level (1h < duration ≤ 4h, confidence level > 0.7), L level (15min < duration ≤ 1h, confidence level > 0.5).

[0059] Matching rules: L1 tasks are prioritized for matching H-class vehicles; L2 tasks are prioritized for matching M-class vehicles; L3 tasks are matched for L / M-class vehicles, and H-class premium long window resources are prohibited from being used.

[0060] (3) MAPPO scheduling reward function.

[0061] Rsched=w1 Total number of tasks completed + w2 (1 Task interruption rate + w3 Theoretical upper limit computing power utilization w4 Eenergy; Where Rsched is the overall scheduling benefit value, w1=0.4, w2=0.35, w3=0.15, w4=0.10, which supports dynamic calibration in the cloud and takes into account task completion rate, stability, resource utilization and energy consumption.

[0062] (4) Parameter definition of Dec-POMDP model. Global status: task queue length, number of tasks at each level, total number of vehicles in the resource pool, average parking window duration; Local observations: single vehicle parking confidence, remaining window, available computing power, power supply / network score; Action space: task allocation, checkpoint migration, rejection of low-quality tasks; Reward and punishment mechanism: positive reward for task completion, negative penalty for interruption without backup, slight penalty for idle computing power.

[0063] Therefore, the embodiments of this application label tasks according to four dimensions: computational density, time sensitivity, expected execution time, and fault tolerance requirements. Parked vehicles are divided into three levels (high / medium / low certainty) according to window duration and confidence level. This enables precise matching of long-term batch processing tasks to vehicles charging at night, medium-term analysis tasks to vehicles in daytime office areas, and short-term inference tasks to vehicles temporarily parked. Furthermore, MAPPO deep reinforcement learning is introduced to optimize Dec-POMDP modeling.

[0064] It should be noted that in other embodiments, static scheduling based on heuristic rules can be used, without introducing machine learning, and greedy matching can be performed only based on the expected execution time of the task and the available time of the vehicle; or, reinforcement learning scheduling based on single-agent DQN / DDPG can be used, with a single global agent making scheduling decisions; in addition, the scheduling problem can be modeled as an ILP / MILP mathematical programming problem, and the global optimal solution can be found using CPLEX or Gurobi solvers. Preferably, the MAPPO algorithm adopted in the embodiments of this application, through a centralized training and distributed execution architecture, allows each vehicle to make decisions based on local observations as an independent agent, which takes into account both global optimization effect and distributed execution efficiency, and can still maintain millisecond-level decision latency in large-scale scenarios.

[0065] Optionally, in some embodiments, after scheduling the target vehicle to perform the task to be processed, the process includes: determining whether a start intention of the target vehicle has been received; if a start intention of the target vehicle has been received, then interrupting the task to be processed and reclaiming the computing resources of the target vehicle.

[0066] Specifically, in combination Figure 6 As shown, the embodiments of this application can realize seamless switching of computing power when the vehicle state changes: (1) Vehicle start-up pre-sensing: The vehicle end monitors gear changes in real time, such as switching from P gear to D / R gear, handbrake release, accelerator pedal signal, and predicts the start intention 3-5 seconds before the vehicle officially leaves, and enters the computing power recovery process in advance. (2) Quick checkpoint saving: During the task execution process, the vehicle end periodically saves the intermediate state of the task as a checkpoint to ensure that the task can be recovered from the interruption point after interruption. (3) Priority recovery of computing power: When the vehicle start intention is detected, the external playback task is immediately paused, the checkpoint is saved, GPU / CPU / memory resources are recovered and switched to the core driving business, such as autonomous driving perception, planning control and vehicle interaction. (4) Cross-node task migration: After receiving the vehicle end recovery signal, the cloud scheduling engine immediately migrates the checkpoint of the unfinished task to other available parking nodes or edge servers to continue execution, realizing seamless task connection.

[0067] Therefore, in this embodiment of the application, a pre-start sensing module is deployed on the vehicle side. By monitoring gear changes, handbrake release, and accelerator pedal signals in real time, the starting intention is predicted before the vehicle officially leaves. This triggers an immediate pause of the task, saving of checkpoints, recovery of GPU / CPU / memory, and switching of the computing power recovery process for core driving services, ensuring that driving safety is not affected by external tasks.

[0068] It should be noted that in other embodiments, startup pre-awareness can be omitted, and only task execution timeouts can be set. For example, if there is no heartbeat for 5 minutes, the node is considered offline, and the cloud passively detects and reschedules it. Alternatively, a geofence can be set at the parking lot exit, and computing power reclamation is triggered when a vehicle crosses the fence. In addition, when the vehicle system starts, GPU / CPU resources are statically partitioned into a driving-only area and an externally schedulable area. Externally scheduled tasks are only allowed to use the externally schedulable area, and even if they are not reclaimed, it will not affect the core driving business. Preferably, the startup pre-awareness, computing power reclamation, and checkpoint mechanism of this application embodiment can achieve efficient external utilization of computing power during parking while ensuring the absolute priority of driving safety, thus balancing safety and utilization rate, and is the optimal solution in the vehicle scenario.

[0069] In summary, this application has the following beneficial effects: (1) Advantages of scene adaptability: The embodiments of this application use the vehicle parking status as an independent scheduling dimension for vehicle computing power scheduling, which solves the technical problems of tight computing power in the vehicle driving state and waste of computing power in the parking state, and fills the gap in parking computing power scheduling technology in the field of vehicle edge computing.

[0070] (2) Advantage of deterministic guarantee driven by prediction: By introducing deep learning time-series prediction and Bayesian real-time correction, the embodiments of this application can predict the computing power available window for the next few hours at the beginning of vehicle parking, providing deterministic guarantee for long-term batch computing tasks, breaking through the limitation of related technologies that can only handle short-term instantaneous tasks.

[0071] (3) The refined advantages of multi-dimensional evaluation: The six-dimensional computing power evaluation model covers the unique dimensions of power supply stability and network quality in the vehicle scenario, and its accuracy far exceeds that of single-dimensional CPU load rate evaluation.

[0072] (4) Absolute advantage in safety protection: The triple protection scheme of pre-sensing, computing power recovery and checkpoint migration ensures that the external computing power will not affect the vehicle driving safety at any time.

[0073] (5) Advantages of system architecture completeness: The five-layer closed-loop scheduling architecture forms a complete closed loop of perception, prediction, evaluation, scheduling and recovery. The data flow and control flow between each layer are closely connected, and the application value is high.

[0074] The vehicle computing power scheduling method proposed in this application identifies vehicles as being in a schedulable parking state based on their parking confidence index. In response to this labeling, the predicted parking duration and prediction confidence are determined based on multi-dimensional state feature data. Furthermore, the comprehensive confidence of the vehicle is determined based on multi-dimensional computing power evaluation indicators and the prediction confidence. Vehicles with a comprehensive confidence greater than a preset threshold are added to a schedulable resource pool. The task to be processed is labeled based on task feature information to obtain labeling results. Based on the labeling results, predicted parking duration, and comprehensive confidence, the target vehicle for the task is determined from the schedulable resource pool, and the target vehicle is scheduled to execute the task. This solves the problems of related technologies lacking fine-grained differentiation between parking and driving conditions, lacking the ability to predict parking time, and being unable to guarantee continuous task execution, thus achieving efficient utilization of vehicle computing power resources.

[0075] Next, the computing power scheduling device for vehicles according to the embodiments of this application is described with reference to the accompanying drawings.

[0076] Figure 7 This is a block diagram of a vehicle computing power scheduling device according to an embodiment of this application.

[0077] like Figure 7 As shown, the computing power scheduling device 10 of the vehicle includes: a marking module 100, a prediction module 200, an evaluation module 300, and a scheduling module 400.

[0078] The marking module 100 is used to mark the vehicle as being in a schedulable parking state based on the vehicle's parking confidence index.

[0079] The prediction module 200 is used to determine the predicted parking duration and prediction confidence of the vehicle based on multi-dimensional state feature data in response to the parking schedulable state marker.

[0080] The evaluation module 300 is used to determine the comprehensive confidence level of a vehicle based on multi-dimensional computing power evaluation indicators and prediction confidence level, and to add vehicles with a comprehensive confidence level greater than a preset threshold to the schedulable resource pool.

[0081] The scheduling module 400 is used to label the task to be processed based on the task feature information to obtain the labeling results, and to determine the target vehicle of the task to be processed from the schedulable resource pool based on the task labeling results, predicted parking time and comprehensive confidence level, and to schedule the target vehicle to execute the task to be processed.

[0082] Optionally, in some embodiments, the marking module 100 includes: a first acquisition unit, a first judgment unit, a second judgment unit, and a marking unit.

[0083] The first acquisition unit is used to acquire vehicle status data, charging data, and location data.

[0084] The first judgment unit is used to determine whether the vehicle meets the preset scheduling conditions based on status data, charging data, and location data.

[0085] The second judgment unit is used to determine the vehicle's parking confidence score based on status data, charging data, and positioning data when the vehicle meets the preset scheduling conditions, and to determine whether the parking confidence score is higher than the preset score threshold.

[0086] The marking unit is used to mark a vehicle as parkable and schedulable if the parking confidence score is higher than a preset score threshold, otherwise, mark the vehicle as parked and pending confirmation.

[0087] Optionally, in some embodiments, the prediction module 200 includes: a second acquisition unit, a prediction unit, and a correction unit.

[0088] The second acquisition unit is used to acquire historical state feature data and current state feature data of the vehicle.

[0089] The prediction unit is used to input historical state feature data into a preset parking duration prediction model to obtain the first parking duration and the first confidence level.

[0090] The correction unit is used to correct the first parking duration and the first confidence level based on the current state feature data to obtain the predicted parking duration and the predicted confidence level.

[0091] Optionally, in some embodiments, the evaluation module 300 includes a third acquisition unit and a fusion unit.

[0092] The third acquisition unit is used to acquire the vehicle's multi-dimensional computing power evaluation index, which includes at least one of the following: available computing power score, power supply stability score, and network quality score.

[0093] The fusion unit is used to perform weighted fusion calculations of the prediction confidence level and multi-dimensional computing power evaluation indicators to obtain the comprehensive confidence level.

[0094] Optionally, in some embodiments, the scheduling module 400 includes: a fourth acquisition unit, a first determination unit to a fourth determination unit, and a combination unit.

[0095] The fourth acquisition unit is used to acquire task feature information of the task to be processed, wherein the task feature information includes at least one of the following: type of computing resource consumption, computing timeliness requirements, estimated execution time and task fault tolerance requirements.

[0096] The first determining unit is used to determine the computation density label of the task to be processed based on the type of computational resource consumption. The computation density label includes: CPU intensive, GPU intensive, or memory intensive.

[0097] The second determining unit is used to determine the time-sensitive labels of the tasks to be processed based on the computational timeliness requirements. The time-sensitive labels include real-time, near real-time, or batch processing.

[0098] The third determining unit is used to determine the estimated execution time label of the task to be processed based on the estimated execution time.

[0099] The fourth determining unit is used to determine the fault tolerance requirement label of the task to be processed based on the task fault tolerance requirements. The fault tolerance requirement label includes: interruptible or non-interruptible.

[0100] The combination unit is used to combine the calculated density label, time-sensitive label, expected execution time label, and fault tolerance requirement label to generate the annotation result.

[0101] Optionally, in some embodiments, the scheduling module 400 includes a matching unit.

[0102] The matching unit is used to input the labeled results of the task to be processed, the predicted parking time of vehicles in the schedulable resource pool, and the comprehensive confidence level into a preset scheduling model to obtain the task-vehicle matching relationship, so as to determine the target vehicle of the task to be processed based on the task-vehicle matching relationship.

[0103] Optionally, in some embodiments, after scheduling the target vehicle to perform the task to be processed, the scheduling module includes: a third judgment unit and a recycling unit.

[0104] The third judgment unit is used to determine whether the starting intention of the target vehicle has been received.

[0105] The recycling unit is used to interrupt pending tasks and reclaim the computing resources of the target vehicle upon receiving the target vehicle's intention to start.

[0106] It should be noted that the foregoing explanation of the vehicle computing power scheduling method embodiment also applies to the vehicle computing power scheduling device of this embodiment, and will not be repeated here.

[0107] The vehicle computing power scheduling device proposed in this application identifies vehicles as being in a schedulable parking state based on their parking confidence index. In response to this labeling, the device determines the predicted parking duration and prediction confidence based on multi-dimensional state feature data. It then determines the vehicle's overall confidence based on multi-dimensional computing power evaluation indicators and the prediction confidence. Vehicles with an overall confidence greater than a preset threshold are added to a schedulable resource pool. Based on task feature information, the device labels the tasks to be processed, obtaining labeling results. Finally, based on the labeling results, predicted parking duration, and overall confidence, the device identifies the target vehicle for the task from the schedulable resource pool and schedules the target vehicle to execute the task. This solves the problems of related technologies lacking fine-grained differentiation between parking and driving conditions, lacking the ability to predict parking time, and failing to guarantee continuous task execution, thus achieving efficient utilization of vehicle computing power resources.

[0108] Figure 8 A schematic diagram of the structure of a vehicle provided in an embodiment of this application. The vehicle may include: The memory 801, the processor 802, and the computer program stored on the memory 801 and capable of running on the processor 802.

[0109] When the processor 802 executes the program, it implements the vehicle computing power scheduling method provided in the above embodiments.

[0110] Furthermore, the vehicle also includes: Communication interface 803 is used for communication between memory 801 and processor 802.

[0111] The memory 801 is used to store computer programs that can run on the processor 802.

[0112] The memory 801 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0113] If the memory 801, processor 802, and communication interface 803 are implemented independently, then the communication interface 803, memory 801, and processor 802 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0114] Optionally, in a specific implementation, if the memory 801, processor 802, and communication interface 803 are integrated on a single chip, then the memory 801, processor 802, and communication interface 803 can communicate with each other through an internal interface.

[0115] The processor 802 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0116] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described vehicle computing power scheduling method.

[0117] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0118] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0119] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0120] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0121] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0122] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for scheduling vehicle computing power, characterized in that, Includes the following steps: Based on the vehicle's parking confidence index, the vehicle is marked as having a parking schedulable state. In response to the parking schedulable state marker, the predicted parking duration and prediction confidence of the vehicle are determined based on multi-dimensional state feature data; Based on the multi-dimensional computing power evaluation index and the prediction confidence level, the comprehensive confidence level of the vehicle is determined, and vehicles with a comprehensive confidence level greater than a preset threshold are added to the schedulable resource pool. Based on the task feature information, the task to be processed is labeled to obtain the labeling results. Based on the labeling results of the task, the predicted parking time and the comprehensive confidence level, the target vehicle of the task to be processed is determined from the schedulable resource pool, and the target vehicle is scheduled to execute the task to be processed.

2. The method according to claim 1, characterized in that, The vehicle-based parking confidence index is used to mark the vehicle as being in a schedulable parking state, including: Acquire the vehicle's status data, charging data, and location data; Based on the status data, the charging data, and the location data, determine whether the vehicle meets the preset scheduling conditions; If the vehicle meets the preset scheduling conditions, the parking confidence score of the vehicle is determined based on the status data, the charging data and the positioning data, and it is determined whether the parking confidence score is higher than the preset score threshold. If the parking confidence score is higher than the preset score threshold, the vehicle is marked as parking available; otherwise, the vehicle is marked as parking pending confirmation.

3. The method according to claim 1, characterized in that, The determination of the predicted parking duration and prediction confidence of the vehicle based on multidimensional state feature data includes: Obtain the historical and current state feature data of the vehicle; The historical state feature data is input into a preset parking duration prediction model to obtain the first parking duration and the first confidence level; The predicted parking duration and the predicted confidence level are obtained by correcting the first parking duration and the first confidence level based on the current state feature data.

4. The method according to claim 1, characterized in that, The determination of the vehicle's overall confidence level based on the multi-dimensional computing power evaluation index and the prediction confidence level includes: Obtain the multi-dimensional computing power evaluation index of the vehicle, wherein the multi-dimensional computing power evaluation index includes at least one of the following: available computing power score, power supply stability score and network quality score; The comprehensive confidence level is obtained by weighted fusion calculation of the predicted confidence level and the multidimensional computing power evaluation index.

5. The method according to claim 1, characterized in that, The step of labeling the task to be processed based on task feature information to obtain labeling results includes: Obtain the task feature information of the task to be processed, wherein the task feature information includes at least one of the following: type of computing resource consumption, computing timeliness requirements, estimated execution time and task fault tolerance requirements; Based on the type of computing resource consumption, the computing density label of the task to be processed is determined, and the computing density label includes: CPU intensive, GPU intensive, or memory intensive. Based on the aforementioned computational timeliness requirements, the time sensitivity labels of the tasks to be processed are determined, and the time sensitivity labels include real-time, near real-time, or batch processing. Based on the estimated execution time, determine the expected execution duration label for the task to be processed; Based on the aforementioned task fault tolerance requirements, a fault tolerance requirement label is determined for the task to be processed. The fault tolerance requirement label includes: interruptible or non-interruptible. The annotation result is generated by combining the calculated density label, the time sensitivity label, the expected execution time label, and the fault tolerance requirement label.

6. The method according to claim 1, characterized in that, The step of determining the target vehicle for the task to be processed from the schedulable resource pool based on the task's labeling results, the predicted parking time, and the overall confidence level includes: The labeling results of the task to be processed, the predicted parking time of the vehicles in the schedulable resource pool, and the comprehensive confidence level are input into a preset scheduling model to obtain the task-vehicle matching relationship, so as to determine the target vehicle of the task to be processed based on the task-vehicle matching relationship.

7. The method according to claim 1, characterized in that, After scheduling the target vehicle to perform the task to be processed, the process includes: Determine whether the target vehicle's start-up intention has been received; If the target vehicle's intention to start is received, the pending task is interrupted, and the target vehicle's computing resources are reclaimed.

8. A vehicle computing power scheduling device, characterized in that, include: The marking module is used to mark the vehicle as being in a schedulable parking state based on the vehicle's parking confidence index. The prediction module is used to determine the predicted parking duration and prediction confidence of the vehicle based on multi-dimensional state feature data in response to the parking schedulable state marker. The evaluation module is used to determine the comprehensive confidence level of the vehicle based on the multi-dimensional computing power evaluation index and the prediction confidence level, and to add vehicles with a comprehensive confidence level greater than a preset threshold to the schedulable resource pool. The scheduling module is used to label the task to be processed based on task feature information to obtain labeling results, and to determine the target vehicle of the task to be processed from the schedulable resource pool based on the labeling results of the task, the predicted parking time and the comprehensive confidence level, and to schedule the target vehicle to execute the task to be processed.

9. A vehicle, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the computing power scheduling method for a vehicle as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the computing power scheduling method for vehicles as described in any one of claims 1-7.

Images