Vehicle resource scheduling method and device

Abstract

The invention discloses a vehicle resource scheduling method and device. In the method, a cloud platform collects road and network environment data, vehicle states of resource vehicles around a target vehicle, a vehicle state of the target vehicle and business task information of the target vehicle in real time, and generates a feature snapshot of a unified time window. And the cloud platform determines a stable cooperation time window of the resource vehicles and the target vehicles based on the feature snapshots, and screens adaptive resource vehicles to form a cooperation resource pool. Then, the cloud platform abstracts a target vehicle business task into a hypergraph and divides the hypergraph into transferable sub-tasks, and establishes a mapping relation between the sub-tasks and a target resource vehicle in combination with the computing power demand of the target vehicle and the running state of the target resource vehicle; and finally, the cloud platform issues a subtask execution instruction to the target resource vehicle, receives an execution result of the subtask execution instruction and forwards the execution result to the target vehicle, and the target vehicle completes result combination and service output.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, and in particular to a vehicle resource scheduling method and device. Background Technology

[0002] With the rapid development of intelligent connected vehicle technology, the complexity of services such as advanced driver assistance systems (ADAS), autonomous driving, and in-vehicle entertainment continues to increase, leading to an exponential increase in the demand for real-time computing power from target vehicles. The local computing power of a single vehicle is limited by factors such as hardware cost and power consumption, making it difficult to meet the requirements of high concurrency and low latency business execution. Against this backdrop, the vehicle-cloud integrated architecture has emerged. By integrating the idle computing power of surrounding vehicles with the centralized computing power of the cloud platform, a distributed collaborative computing network is constructed, becoming a key technological direction for solving the bottleneck of local vehicle computing power and is widely used in intelligent transportation, autonomous driving, and other scenarios.

[0003] Each vehicle is equipped with a local Graphics Processing Unit (GPU) for local rendering and real-time computing. However, this model suffers from high hardware costs and uneven utilization. The GPU resources are idle during light-load daily applications, but may be insufficient for heavy-load scenarios. Migrating all vehicle computing tasks to a cloud platform for completion and then pushing the results back to the vehicle offers centralized resource allocation, but limitations in network bandwidth and latency can easily lead to screen stuttering and unresponsive interactions, especially in weak network conditions or cross-regional access scenarios. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a vehicle resource scheduling method and device.

[0005] The embodiments of this application disclose the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a vehicle resource scheduling method, the method comprising:

[0007] Real-time data collection of road and network environment, vehicle status of at least one resource vehicle in the vicinity, vehicle status of the target vehicle, and business task information of the target vehicle are generated to generate a feature snapshot of a unified time window.

[0008] Based on the feature snapshot, a stable collaboration time window between each resource vehicle and the target vehicle is determined, and at least one suitable target resource vehicle is selected to form a collaborative resource pool.

[0009] Based on the business task information, the business tasks of the target vehicle are abstracted into a hypergraph and divided into transferable subtasks. Combining the computing power requirements of the target vehicle with the operating status of at least one of the target resource vehicles, a mapping relationship between the subtasks and at least one of the target resource vehicles is established.

[0010] Based on the mapping relationship, the execution instructions of the corresponding sub-tasks are issued to at least one of the target resource vehicles;

[0011] The system receives subtask execution results uploaded by at least one of the target resource vehicles and forwards the subtask execution results to the target vehicle, so that the target vehicle can complete the merging of execution results and business output of the business task information based on the subtask execution results fed back by at least one of the target resource vehicles.

[0012] In one possible implementation, generating a feature snapshot of a unified time window includes:

[0013] All types of collected data are uniformly aligned and processed to generate feature snapshots with a preset time window duration;

[0014] If the collected data has missing packets or the timestamp drifts for more than a preset time, the abnormal data will be interpolated or discarded. If the data collected in multiple consecutive rounds contains abnormal data, the cloud platform will use its own computing resources to independently complete the business task of the target vehicle and push the execution result to the target vehicle.

[0015] In one possible implementation, determining the stable cooperation time window between each resource vehicle and the target vehicle based on the feature snapshot includes:

[0016] Based on the data in the feature snapshot, the dwell time, co-location time, and connectivity time between each resource vehicle and the target vehicle are calculated; wherein, the dwell time is determined based on the relative speed and heading of the resource vehicle and the target vehicle; the co-location time is determined based on the map, intersection density, and lane-changing intentions; and the connectivity time is determined based on network coverage and signal quality.

[0017] For each resource vehicle, a stable cooperation time window between the resource vehicle and the target vehicle is determined based on the dwell time, co-location time, and connection time between the resource vehicle and the target vehicle.

[0018] In one possible implementation, the selection and adaptation of at least one target resource vehicle to form a collaborative resource pool includes:

[0019] For each of the resource vehicles, based on the vehicle status of the resource vehicle in the feature snapshot and the stable cooperation time window corresponding to the resource vehicle, a comprehensive score is given to the resource vehicle through a scoring function;

[0020] The scoring function is:

[0021] ;

[0022] in, Give a score to the i-th resource vehicle; Score the computing power surplus of the i-th resource vehicle; Score the network quality of the i-th resource vehicle; Let i be the reward and penalty function based on a stable cooperation time window for the i-th resource vehicle; Score the driving risk of the i-th resource vehicle; , , and Adaptive weighting for different scenarios; amplification in high-speed formation scenarios. and Weighting, amplifying weights in urban scenarios , and ;

[0023] The scores of each resource vehicle are sorted from largest to smallest, and the top N resource vehicles in the score ranking are selected as the target resource vehicles to form a collaborative resource pool; N is an integer greater than or equal to 1.

[0024] In one possible implementation, the step of abstracting the target vehicle's business tasks into a hypergraph based on the business task information and dividing it into transferable subtasks includes:

[0025] Based on the business task information, the business task pipeline of the target vehicle is abstracted as a hypergraph G=(V,E); where V is the set of task nodes and E is the set of hyperedges. The weight of the hyperedge is determined by the amount of data between the corresponding tasks, the link latency, and the dependency level penalty value.

[0026] The hypergraph is partitioned with the goal of minimizing cross-vehicle dependencies and minimizing data transmission volume. Subgraphs with weak dependencies and small data volumes are prioritized to obtain multiple transferable subtasks and the dependencies between these multiple transferable subtasks.

[0027] In one possible implementation, establishing a mapping relationship between a subtask and at least one of the target resource vehicles by combining the computing power requirements of the target vehicle with the operating status of at least one of the target resource vehicles includes:

[0028] Based on the latency improvement brought about by the subtask migration, the communication cost between the subtask and the target resource vehicle, and the score of the target resource vehicle, the mapping benefit between the subtask and the target resource vehicle is determined by the edge weight formula;

[0029] The formula for the edge weight is:

[0030] ;

[0031] in, The mapping benefit between the subtask and the i-th resource vehicle. This represents the latency improvement value for subtask migration. The communication cost between the subtask and the i-th resource vehicle. The overall score for the i-th resource vehicle;

[0032] Based on the mapping benefits and constraints, a mapping relationship is established between the subtask and at least one of the target resource vehicles; wherein, the constraints are the maximum concurrency limit for a single vehicle, the completion and return of the subtask within a stable collaboration time window, and the slice bandwidth budget.

[0033] In one possible implementation, after establishing the mapping relationship between the subtask and at least one of the target resource vehicles, the method further includes:

[0034] With the optimization objectives of minimizing tail delay risk, target resource vehicle energy consumption, and slice bandwidth consumption, the mapping relationship is subjected to risk-constrained optimization in the rolling time domain, combined with risk optimization constraints.

[0035] The step of issuing execution instructions for corresponding sub-tasks to at least one of the target resource vehicles based on the mapping relationship includes:

[0036] Based on the optimized mapping relationship, when the subtask is a critical task, a replica offsetting strategy is adopted to simultaneously issue the subtask to the cloud platform and the target resource vehicle corresponding to the subtask.

[0037] Based on the optimized mapping relationship, when the subtask is a batch task, the erasure coding strategy is used to divide the subtask into k valid data fragments and r redundant data fragments. The k valid data fragments and the r redundant data fragments are assigned to multiple target resource vehicles. The results can be merged after any k data fragments are returned. Here, k and r are integers greater than or equal to 1.

[0038] Secondly, embodiments of this application disclose a vehicle resource scheduling device, the device comprising:

[0039] The acquisition module 401 is used to collect road and network environment data, the vehicle status of at least one resource vehicle in the vicinity, the vehicle status of the target vehicle, and the business task information of the target vehicle in real time, and generate a feature snapshot of a unified time window.

[0040] The filtering module 402 is used to determine the stable collaboration time window between each resource vehicle and the target vehicle based on the feature snapshot, and to filter at least one suitable target resource vehicle to form a collaborative resource pool.

[0041] The segmentation module 403 is used to abstract the business tasks of the target vehicle into a hypergraph based on the business task information and segment them into transferable subtasks. It also establishes a mapping relationship between the subtasks and at least one target resource vehicle by combining the computing power requirements of the target vehicle with the operating status of at least one target resource vehicle.

[0042] The issuing module 404 is used to issue execution instructions for corresponding sub-tasks to at least one of the target resource vehicles based on the mapping relationship;

[0043] The receiving module 405 is used to receive the subtask execution results uploaded by at least one of the target resource vehicles, and forward the subtask execution results to the target vehicle, so that the target vehicle can complete the merging of the execution results of the business task information and the business output based on the subtask execution results fed back by at least one of the target resource vehicles.

[0044] In one possible implementation, the acquisition module 401 is specifically used to perform unified alignment processing on the acquired data and generate a feature snapshot with a preset time window; if the acquired data has missing packets or the timestamp drift is greater than the preset time, interpolation or discard processing is triggered for the abnormal data; if the data acquired in multiple consecutive rounds all contain abnormal data, the cloud platform calls its own computing power resources to independently complete the business task of the target vehicle and push the execution result to the target vehicle.

[0045] In one possible implementation, the filtering module 402 is specifically used to calculate the dwell time, lane co-operation time, and connectivity time between each resource vehicle and the target vehicle based on the data in the feature snapshot; wherein, the dwell time is determined based on the relative speed and heading of the resource vehicle and the target vehicle; the lane co-operation time is determined based on the map, intersection density, and lane-changing intentions; the connectivity time is determined based on network coverage and signal quality; and for each resource vehicle, a stable cooperation time window between the resource vehicle and the target vehicle is determined based on the dwell time, lane co-operation time, and connectivity time between the resource vehicle and the target vehicle.

[0046] In one possible implementation, the filtering module 402 is specifically used to perform a comprehensive score on each resource vehicle based on the vehicle status of the resource vehicle in the feature snapshot and the stable cooperation time window corresponding to the resource vehicle, through a scoring function.

[0047] The scoring function is:

[0048] ;

[0049] in, Give a score to the i-th resource vehicle; Score the computing power surplus of the i-th resource vehicle; Score the network quality of the i-th resource vehicle; Let i be the reward and penalty function based on a stable cooperation time window for the i-th resource vehicle; Score the driving risk of the i-th resource vehicle; , , and Adaptive weighting for different scenarios; amplification in high-speed formation scenarios. and Weighting, amplifying weights in urban scenarios , and ;

[0050] The scores of each resource vehicle are sorted from largest to smallest, and the top N resource vehicles in the score ranking are selected as the target resource vehicles to form a collaborative resource pool; N is an integer greater than or equal to 1.

[0051] In one possible implementation, the segmentation module 403 is specifically used to abstract the business task pipeline of the target vehicle into a hypergraph G=(V,E) based on the business task information; where V is the set of task nodes and E is the set of hyperedges, and the weight of the hyperedge is determined by the data volume, link latency and dependency level penalty value between the corresponding tasks; the hypergraph is divided with the goal of minimizing cross-vehicle dependency and minimizing data transmission volume, and subgraphs with weak dependencies and small data volume are segmented first to obtain multiple transferable subtasks and the dependency relationships between the multiple transferable subtasks.

[0052] In one possible implementation, the segmentation module 403 is specifically used to determine the mapping benefit between the subtask and the target resource vehicle based on the latency improvement value brought about by the subtask migration, the communication cost between the subtask and the target resource vehicle, and the score of the target resource vehicle, through an edge weight formula.

[0053] The formula for the edge weight is:

[0054] ;

[0055] in, The mapping benefit between the subtask and the i-th resource vehicle. This represents the latency improvement value for subtask migration. The communication cost between the subtask and the i-th resource vehicle. The overall score for the i-th resource vehicle;

[0056] Based on the mapping benefits and constraints, a mapping relationship is established between the subtask and at least one of the target resource vehicles; wherein, the constraints are the maximum concurrency limit for a single vehicle, the completion and return of the subtask within a stable collaboration time window, and the slice bandwidth budget.

[0057] In one possible implementation, the apparatus further includes an optimization module; the optimization module is used to perform risk-constrained optimization of the mapping relationship in the rolling time domain with the optimization objectives of minimizing tail delay risk, target resource vehicle energy consumption and slice bandwidth consumption, combined with risk optimization constraints.

[0058] The distribution module 404 is specifically used to, based on the optimized mapping relationship, simultaneously distribute the subtask to the cloud platform and the target resource vehicle corresponding to the subtask using a replica offsetting strategy when the subtask is a critical task; based on the optimized mapping relationship, when the subtask is a batch task, the subtask is divided into k valid data fragments and r redundant data fragments using an erasure coding strategy, and the k valid data fragments and r redundant data fragments are assigned to multiple target resource vehicles, and the results can be merged after any k data fragments are returned; where k and r are integers greater than or equal to 1.

[0059] Thirdly, embodiments of this application disclose a control device, including a processor and a memory, wherein the memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to complete the vehicle resource scheduling method as described in any of the first aspects.

[0060] Fourthly, embodiments of this application disclose a computer-readable storage medium, characterized in that it stores a computer program, which is loaded by a processor to execute the vehicle resource scheduling method as described in any of the first aspects.

[0061] This application provides a vehicle resource scheduling method and device. In this method, a cloud platform collects real-time road and network environment data, the vehicle status of surrounding resource vehicles, the vehicle status of the target vehicle, and the target vehicle's business task information, generating a feature snapshot within a unified time window. Based on this feature snapshot, the cloud platform determines a stable collaboration time window between resource vehicles and the target vehicle, and selects suitable resource vehicles to form a collaborative resource pool. Then, the cloud platform abstracts the target vehicle's business tasks into a hypergraph and divides them into transferable subtasks. Combining the target vehicle's computing power requirements and the target resource vehicle's operating status, a mapping relationship is established between the subtasks and the target resource vehicle. Finally, the cloud platform issues subtask execution instructions to the target resource vehicle, receives its execution results, and forwards them to the target vehicle, which then completes the result merging and business output.

[0062] This technical solution provides precise and synchronized decision-making basis for resource scheduling through feature snapshots within a unified time window. Furthermore, by using stable collaborative time windows to select suitable resource vehicles, the compatibility of resource vehicles and target vehicles in collaboration is improved. By abstracting business tasks into a hypergraph and segmenting them to establish a mapping relationship between subtasks and resource vehicles, fine-grained task allocation is achieved. Finally, by having resource vehicles execute subtasks and return results, the idle computing power of surrounding resource vehicles is effectively utilized, alleviating the local computing power pressure on target vehicles and ensuring the efficient execution of business tasks. Attached Figure Description

[0063] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0064] Figure 1 A flowchart illustrating a vehicle resource scheduling method provided in an embodiment of this application;

[0065] Figure 2 A schematic diagram of the interaction architecture of a vehicle resource scheduling method provided in an embodiment of this application;

[0066] Figure 3 A schematic diagram illustrating the interaction process of a vehicle resource scheduling method provided in an embodiment of this application;

[0067] Figure 4 This is a schematic diagram of the structure of a vehicle resource scheduling device provided in an embodiment of this application. Detailed Implementation

[0068] As described above, existing technologies for vehicle resource scheduling mainly employ three implementation methods: first, the vehicle-side independent computing power mode, where the vehicle is equipped with a local GPU to complete the computation; second, the pure cloud rendering mode, where the entire task is migrated to the cloud for execution and the results are then transmitted back; and third, the vehicle-side fixed collaboration mode, where the vehicle establishes edge collaboration with fixed computing units on the roadside to achieve complementary computing power through static division of labor, but this mode is difficult to flexibly schedule during peak task periods.

[0069] Existing implementation methods have several shortcomings. The vehicle-side independent computing power mode has high hardware costs and uneven resource utilization, the pure cloud rendering mode is easily affected by network limitations, resulting in interactive lag, and the vehicle-side fixed collaboration mode is difficult to adapt to flexible scheduling during instantaneous peak tasks. Overall, there are also problems such as insufficient elastic resource sharing, coarse scheduling granularity, and lack of instantaneous collaboration mechanisms, making it difficult to guarantee the user experience of cloud desktops in weak network or sudden high load scenarios.

[0070] To address this technical problem, this application provides a vehicle resource scheduling method and device. In this method, a cloud platform collects real-time road and network environment data, the vehicle status of surrounding resource vehicles, the vehicle status of the target vehicle, and the target vehicle's business task information, generating a feature snapshot of a unified time window. Based on this feature snapshot, the cloud platform determines a stable collaboration time window between resource vehicles and the target vehicle, and selects suitable resource vehicles to form a collaborative resource pool. Then, the cloud platform abstracts the target vehicle's business tasks into a hypergraph and divides them into transferable subtasks. Combining the target vehicle's computing power requirements and the target resource vehicle's operating status, a mapping relationship is established between the subtasks and the target resource vehicle. Finally, the cloud platform issues subtask execution instructions to the target resource vehicle, receives its execution results, and forwards them to the target vehicle, which then completes the result merging and business output.

[0071] This technical solution provides precise and synchronized decision-making basis for resource scheduling through feature snapshots within a unified time window. Furthermore, by using stable collaborative time windows to select suitable resource vehicles, the compatibility of resource vehicles and target vehicles in collaboration is improved. By abstracting business tasks into a hypergraph and segmenting them to establish a mapping relationship between subtasks and resource vehicles, fine-grained task allocation is achieved. Finally, by having resource vehicles execute subtasks and return results, the idle computing power of surrounding resource vehicles is effectively utilized, alleviating the local computing power pressure on target vehicles and ensuring the efficient execution of business tasks.

[0072] The vehicle resource scheduling method provided in this application can be widely applied to high-computing-power-demand scenarios in intelligent transportation and autonomous driving. For example, in an autonomous driving scenario on urban roads, when a target vehicle needs to complete heavy-load tasks such as high-definition environmental perception or 3D map rendering in real time, the cloud platform can collect the GPU status, vehicle driving data, and road network environment information of resource vehicles (such as lightly loaded private cars and logistics vehicles) within a 1-kilometer radius of the target vehicle in real time. It can then select resource vehicles with a stable collaboration time window of more than 3 seconds to form a collaborative resource pool, and allocate transferable sub-tasks such as 3D rendering to these resource vehicles for execution. After completing the calculations, the resource vehicles return the results to the target vehicle, helping the target vehicle to smoothly complete high-concurrency autonomous driving tasks without increasing local hardware costs.

[0073] In high-speed platooning scenarios, if a target vehicle in the platoon needs to run highly interactive services such as multi-terminal video conferencing, the cloud can quickly detect the idle computing power of other lightly loaded vehicles in the platoon. Through hypergraph segmentation, sub-tasks such as video encoding are distributed to adjacent resource vehicles. The resource vehicles process the data in parallel and then send back the results. This not only avoids the network latency problem of pure cloud mode, but also improves the resource utilization rate in the platoon through vehicle-to-vehicle collaboration, ensuring the smoothness of cloud desktop interaction for users in mobile scenarios.

[0074] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0075] See Figure 1 , Figure 1 This is a flowchart illustrating a vehicle resource scheduling method provided in an embodiment of this application. The executing entity of this method can be a server, desktop computer, or other electronic device capable of computation. The following description uses a server running a cloud platform as the executing entity, and the method includes:

[0076] S101: The server collects real-time road and network environment data, the vehicle status of at least one resource vehicle in the vicinity, the vehicle status of the target vehicle, and the business task information of the target vehicle, and generates a feature snapshot of a unified time window.

[0077] Among the data collected by the server, road and network environment data are used to assess the external environmental feasibility of resource vehicle and target vehicle collaboration. This includes data such as road topology, intersection density, real-time traffic conditions, network coverage, signal strength, round-trip latency, bandwidth, and packet loss rate. Vehicle status is used to determine the computing power supply capability and collaborative driving stability of resource vehicles. This includes data such as vehicle speed, heading angle, lane change intention, GPU utilization, and video memory usage. Business task information is used to clarify the computing power requirements and task execution constraints of the target vehicle. This includes data such as business type, task size, computing power requirement threshold, latency requirement upper limit, task dependencies, and service quality level.

[0078] Resource vehicles refer to surrounding vehicles within a predefined geographical area of ​​the target vehicle that possess idle computing resources and can participate in collaborative computing. The target vehicle is a vehicle experiencing computing load pressure that requires migrating some business tasks to external devices for execution.

[0079] The server can construct a comprehensive data acquisition network using multi-source sensing devices such as Vehicle-to-Everything (V2X), Roadside Units (RSUs), or edge computing nodes. During the data acquisition phase, the server can synchronously trigger the parallel acquisition of multiple types of data according to a preset unified time window period. For road and network environment data, the server can acquire real-time road conditions through roadside cameras and millimeter-wave radar, and collect network performance indicators for each area through network probes. For the vehicle status of resource vehicles and target vehicles, the server can collect vehicle driving parameters through onboard units (OBUs) and obtain computing load data through hardware monitoring modules. For the business task information of target vehicles, the onboard system of the target vehicle actively reports detailed parameters of the tasks to be executed to the server.

[0080] After data collection is complete, the server can perform preprocessing operations on the multi-source data. Specifically, the server aligns the timestamps of all collected data to a base time within a unified time window, removing invalid data that is outside the time window range. Then, the server uses algorithms such as hash verification and outlier detection to filter out erroneous and redundant data. Finally, the server converts the raw data of different formats and volumes into feature data of a unified specification, and ultimately integrates them to generate a complete feature snapshot, which is stored in a cloud database to provide data support for subsequent scheduling decisions.

[0081] Based on multi-source data collection, in order to further ensure the temporal consistency and data reliability of feature snapshots, the embodiments of this application can ensure that feature snapshots can provide stable data support for subsequent scheduling decisions through time alignment, anomaly handling and emergency fallback mechanisms.

[0082] In one possible implementation, feature snapshots can be generated as follows: The server performs unified alignment processing on the collected data and generates feature snapshots with a preset time window. If the collected data has missing packets or timestamp drifts greater than the preset time, the server triggers interpolation or discarding of the abnormal data. If abnormal data is found in multiple consecutive rounds of data collection, the server independently completes the target vehicle's business tasks by utilizing the cloud platform's own computing resources and pushes the execution results to the target vehicle.

[0083] After completing a round of multi-source data collection, the server extracts the timestamps of each type of raw data by using a pre-set time window duration and a reference time. It then uniformly calibrates the timestamps of all data to the reference time, ensuring that road and network environment data, vehicle status data, and business task information all fall within the same time window. Finally, it integrates and generates an initial feature snapshot, thereby avoiding the problem of time sequence misalignment of multi-source data from the root.

[0084] To address potential anomalies such as missing packets and timestamp drift during data acquisition, this application embodiment can implement a hierarchical anomaly handling strategy. The server verifies each data point in the initial feature snapshot. If missing packets are detected, or if the timestamp drift exceeds a preset time, the appropriate processing method is selected based on the data type. For continuous data such as road conditions and network bandwidth, the server can use linear interpolation algorithms to supplement missing data. For discrete data such as vehicle lane-changing intentions and task types, the server can directly discard abnormal data and retain the valid parts, ensuring the integrity and accuracy of the feature snapshot.

[0085] To address data acquisition failures in extreme scenarios, this application embodiment also includes an emergency fallback mechanism. The server tracks data anomalies across consecutive acquisition rounds. If severe anomalies are detected in multiple consecutive acquisition rounds and cannot be corrected through interpolation or other methods, it indicates that the current external data acquisition network can no longer provide effective support for scheduling decisions. In this case, the cloud platform immediately triggers an emergency response, utilizing its idle computing resources to directly take over the target vehicle's business tasks and independently complete the calculations. After completion, the execution results are pushed to the target vehicle, ensuring continuous execution of the target vehicle's business tasks and preventing business interruptions due to data anomalies.

[0086] S102: The server determines the stable collaboration time window between each resource vehicle and the target vehicle based on feature snapshots, and selects at least one suitable target resource vehicle to form a collaborative resource pool.

[0087] A stable collaboration time window refers to the continuous time interval within which the resource vehicle and the target vehicle can maintain a stable communication connection and effective computing power collaboration under the current driving state and external environmental constraints. The stable collaboration time window determines the feasibility of subtask execution and result feedback.

[0088] In this embodiment, the server constructs a collaborative feasibility assessment model based on road and network environment data, resource vehicle status, and target vehicle status from feature snapshots, thereby calculating the stable collaboration time window for each resource vehicle and target vehicle. Specifically, the server can combine road topology, real-time traffic conditions, and data such as vehicle speed and heading angle to predict the relative position changes of resource vehicles and target vehicles within a preset time period, and determine whether there are driving scenarios that may lead to collaboration interruption, such as frequent lane changes or intersection intersections. Simultaneously, the server assesses the stability of the communication connection between resource vehicles and target vehicles based on data such as network coverage, signal strength, and round-trip latency, determining the duration for which the communication link can maintain effective transmission. The server integrates the driving stability and communication stability assessment results, taking the shortest duration of the two as the stable collaboration time window duration for the resource vehicle and target vehicle, and sets a stable collaboration time window threshold.

[0089] After calculating the stable collaboration time window, the server initiates the target resource vehicle screening process. During the screening process, the server can combine the stable collaboration time window with the resource vehicle's computing power status. For example, if a resource vehicle's stable collaboration time window meets the threshold requirement, and its current idle computing power can match the basic computing power requirements of the target vehicle's business tasks, then the resource vehicle is determined to be a suitable target resource vehicle; if the resource vehicle's stable collaboration time window is less than the threshold, or its computing power cannot meet the basic requirements, it is directly eliminated.

[0090] The server integrates all selected target resource vehicles, generates a collaborative resource pool, and records core information such as the computing power parameters and stable collaboration time window duration of each target resource vehicle. This information is then stored in the cloud scheduling database to provide resource list support for subsequent subtask allocation.

[0091] In one possible implementation, if no suitable target resource vehicle is found after screening, the server will expand the search range of resource vehicles and re-execute the stable collaboration time window calculation and screening process; if no suitable resource vehicle is found after expanding the range, the server will report the information that a collaborative resource pool cannot be formed at present to the target vehicle and trigger the cloud backup computing power undertaking mechanism to ensure that business tasks are not interrupted.

[0092] In calculating the stable collaboration time window, this application embodiment can achieve an accurate assessment of the collaborative stability between resource vehicles and target vehicles by splitting and calculating multiple core time indicators.

[0093] In one possible implementation, the server determines the stable collaboration time window between each resource vehicle and the target vehicle based on feature snapshots, including:

[0094] Based on data from the feature snapshot, the server calculates the dwell time, lane co-location time, and connectivity time between each resource vehicle and the target vehicle. Dwell time is determined based on the relative speed and heading of the resource vehicle and the target vehicle; lane co-location time is determined based on the map, intersection density, and lane-changing intentions; and connectivity time is determined based on network coverage and signal quality.

[0095] For each resource vehicle, the server determines a stable collaboration time window between the resource vehicle and the target vehicle based on the dwell time, co-location time, and connection time between the resource vehicle and the target vehicle.

[0096] The server calculates dwell time, co-channel time, and connectivity time based on multi-dimensional data in the feature snapshot.

[0097] The server extracts real-time vehicle status data such as the driving speed and heading angle of the resource vehicle and the target vehicle. Combined with the current relative positions of the two vehicles, the kinematic model is used to predict the duration for which the two vehicles can remain within the preset cooperative distance range, thus determining the dwell time. If the relative speed of the two vehicles is small and their headings are basically the same, the dwell time will be longer; otherwise, the dwell time will be shorter.

[0098] The server retrieves road environment data such as road topology and intersection distribution density from the feature snapshot. At the same time, it combines the lane-changing intention information of the two vehicles to determine whether the two vehicles will leave the same lane or driving path due to factors such as intersection diversion and lane changing during future driving, and thus determine the duration for which the two vehicles can maintain driving in the same lane.

[0099] Based on network environment data such as network coverage, signal strength, and round-trip latency in the feature snapshot, the server uses a communication link quality assessment model to predict the duration for which the communication link between the two vehicles can maintain a stable connection and meet the requirements for task data transmission. If the current network signal is strong and the packet loss rate is low, the connection time will be longer.

[0100] After obtaining the three parameters—dwell time, co-location time, and connectivity time—the server determines the stable collaboration time window for each resource vehicle with the target vehicle, using the minimum value. Dwell time, co-location time, and connectivity time determine the feasibility of collaboration from three dimensions: spatial distance, travel path, and communication link, respectively. Collaboration can only proceed smoothly when all three dimensions meet stability requirements; a shortening of any dimension will directly lead to collaboration interruption. For example, if a resource vehicle's dwell time with the target vehicle is 5 seconds, its co-location time is 4 seconds, and its connectivity time is 6 seconds, then the minimum value of 4 seconds is taken as the stable collaboration time window for that resource vehicle, thus ensuring the reliability of the stable collaboration time window evaluation results.

[0101] This application's embodiment addresses the issues of ambiguity and strong subjectivity in traditional collaborative stability assessments by breaking down the stable collaboration time window into three quantifiable indicators: dwell time, shared route time, and connectivity time. This makes the calculation results of the time window more objective and accurate. Furthermore, by adopting the principle of minimizing the minimum value to determine the final stable collaboration time window, it fully considers constraints such as driving, road conditions, and communication. This maximizes the stable collaboration between resource vehicles and target vehicles within the window duration, avoiding task interruptions due to shortcomings in a single dimension, and providing a more reliable decision-making basis for subsequent selection of target resource vehicles.

[0102] After calculating the stable collaboration time window, in order to further accurately select suitable target resource vehicles, this application embodiment quantitatively evaluates the computing power, network, collaboration stability and other multi-dimensional indicators of the resource vehicles to ensure that the resource quality of the collaborative resource pool is highly matched with the needs of the target vehicles.

[0103] In one possible implementation, at least one suitable target resource vehicle is selected to form a collaborative resource pool, including:

[0104] For each resource vehicle, the server performs a comprehensive score based on the vehicle status in the feature snapshot and the corresponding stable collaboration time window of the resource vehicle through a scoring function.

[0105] The scoring function is:

[0106] ;

[0107] in, Give a score to the i-th resource vehicle; Score the computing power surplus of the i-th resource vehicle; Score the network quality of the i-th resource vehicle; Let i be the reward and penalty function based on a stable cooperation time window for the i-th resource vehicle; Score the driving risk of the i-th resource vehicle; , , and Adaptive weighting for different scenarios; amplification in high-speed formation scenarios. and Weighting, amplifying weights in urban scenarios , and ;

[0108] Sort the scores of each resource vehicle from largest to smallest, and select the top N resource vehicles as target resource vehicles to form a collaborative resource pool; N is an integer greater than or equal to 1.

[0109] In this embodiment, the computing power surplus score is a score that assesses the level of idle computing power that the resource vehicle can provide, based on its hardware status such as GPU utilization and remaining video memory; the network quality score is a score that assesses the quality of the communication link based on data such as signal strength, bandwidth, and latency between the resource vehicle and the target vehicle; the reward and penalty function is a scoring item set according to the stable cooperation time window of the resource vehicle, with a higher reward score for a longer window; the driving risk score is a score that assesses the driving risk during the cooperation process based on the resource vehicle's driving speed, lane change frequency, and other status; and the scene adaptive weight is a weight ratio that adjusts the weight of each scoring item according to different driving scenarios to adapt to the characteristics of the scenario.

[0110] For each resource vehicle, the server extracts the corresponding vehicle status data and the calculated stable collaboration time window from the feature snapshot, and calculates each sub-score in the scoring function. Finally, the sub-scores and their corresponding weights are substituted into the scoring function to calculate the comprehensive score for each resource vehicle. The server sorts all resource vehicles from highest to lowest comprehensive score and selects the top N resource vehicles as target resource vehicles to form a collaborative resource pool.

[0111] This application's embodiments overcome the limitations of traditional resource screening that relies solely on a single indicator by employing a multi-dimensional comprehensive scoring function. It comprehensively evaluates the computing power, network, collaborative stability, and driving risks of resource vehicles, making the screening results more aligned with the actual needs of the target vehicles. Simultaneously, it introduces scenario-adaptive weights, enabling resource screening to adapt to the core requirements of different scenarios such as highways and urban areas, enhancing the flexibility and targeting of the screening process. Finally, by using a scoring-ranking selection method, it ensures that the collaborative resource pool gathers the currently optimal resource vehicles, providing high-quality resource support for the efficient allocation and execution of subsequent sub-tasks.

[0112] S103: The server abstracts the target vehicle's business tasks into a hypergraph based on the business task information and divides it into transferable subtasks.

[0113] A hypergraph is a topological graph centered on the logical structure of business tasks, breaking down tasks into functional modules and dependent edges. The hypergraph describes the execution logic and dependencies of each module within a task. A portable subtask is a task unit extracted from a business task, possessing independent execution capabilities and capable of operating independently of the target vehicle's local computing power.

[0114] Based on the target vehicle's business task information, the server abstracts and models the business tasks. The server extracts the core functional modules of the task as task nodes in the hypergraph, and at the same time sorts out the execution dependencies between the modules as dependency edges in the hypergraph, finally constructing a complete business task hypergraph that clearly presents the execution logic of the task and the module relationships.

[0115] Subsequently, the server performs subtask partitioning on the hypergraph. Based on the task nodes and dependent edges of the hypergraph, the server identifies task nodes with independent computing power requirements and no strong local dependencies, marking these nodes as migrateable units. At the same time, combined with the computing power requirements of the target vehicle, the server splits all migrateable units in the hypergraph into independent migrateable subtasks, and labels each subtask with its core parameters such as computing power requirements, execution time, and data volume to ensure that the subtasks have the conditions for independent execution.

[0116] In one possible implementation, if there are task nodes in the hypergraph that strongly depend on the local resources of the target vehicle, such as modules that need to call real-time data from the target vehicle's camera, these nodes are retained as task units executed locally on the target vehicle. Only nodes without local dependencies are migrated and split into subtasks to avoid resource call failures during subtask execution.

[0117] This application's embodiments utilize hypergraph abstraction modeling to transform complex business tasks into a structured topology graph, clearly outlining the module division and dependencies of tasks, thus resolving the issues of vague logic and chaotic dependencies in traditional task decomposition. Furthermore, by precisely segmenting transferable subtasks, fine-grained task decomposition is achieved, satisfying both the target vehicle's computational burden reduction requirements and ensuring the independent execution capability of subtasks. Simultaneously, by distinguishing between local and transferred task units, execution failures caused by subtasks relying on local resources are avoided, improving the feasibility and stability of subtask migration.

[0118] Based on business task abstraction and subtask segmentation, this application further provides a refined segmentation method based on hypergraph topology and optimization objectives. By quantifying hyperedge weights and setting segmentation objectives, a more reasonable transferable subtask splitting is achieved.

[0119] In one possible implementation, the server abstracts the target vehicle's business tasks into a hypergraph based on business task information and divides it into transferable subtasks, including:

[0120] Based on business task information, the server abstracts the business task pipeline of the target vehicle into a hypergraph G=(V,E). Here, V is the set of task nodes and E is the set of hyperedges. The weight of the hyperedge is determined by the amount of data between the corresponding tasks, the link latency, and the dependency level penalty value.

[0121] The server partitions the hypergraph with the goal of minimizing cross-vehicle dependencies and minimizing data transfer volume, prioritizing the splitting of weakly dependent subgraphs with small data volumes to obtain multiple transferable subtasks and the dependencies between these transferable subtasks.

[0122] The server treats the functional modules of business tasks as a set of task nodes V in a hypergraph. Simultaneously, it constructs a set of hyperedges E based on the dependencies between nodes and calculates the weight of each hyperedge. The weight value is positively correlated with the amount of data transmitted between nodes and the latency of the communication link; the larger the data volume and the higher the latency, the higher the weight. A dependency level penalty value is also added; the deeper the dependency level, the higher the penalty value. Finally, the quantified weight of the hyperedge is obtained through a weighted summation. A higher weight indicates a stronger dependency between nodes.

[0123] Subsequently, the server partitions the hypergraph with the optimization objectives of minimizing cross-vehicle dependencies and minimizing data transmission volume. Based on hyperedge weights, the server prioritizes hyperedges with lower weights for partitioning, splitting the hypergraph into multiple independent subgraphs. Each subgraph corresponds to a transferable subtask, and the dependencies between subtasks are recorded. For example, for a video encoding task, if the hyperedge weight between frame acquisition and frame compression is low, they are preferentially split into independent subtasks, and the execution result of frame compression depends on the execution result of frame acquisition.

[0124] This implementation method transforms the dependencies between task nodes into calculable numerical indicators by quantifying hyperedge weights, thus solving the problem of difficulty in measuring dependency strength in traditional task partitioning. Hypergraph partitioning is performed with the goals of minimizing cross-vehicle dependencies and data transmission volume. This reduces the dependency complexity of subtasks executing across resource vehicles and lowers data transmission overhead, thereby improving the efficiency of subtask execution. Simultaneously, prioritizing the partitioning of subgraphs with weak dependencies and small data volumes ensures the independence and migration feasibility of subtasks, laying a solid foundation for subsequent mapping and allocation of subtasks and resource vehicles.

[0125] S104: The server combines the computing power requirements of the target vehicle with the operating status of at least one target resource vehicle to establish a mapping relationship between the subtask and at least one target resource vehicle.

[0126] The server performs preprocessing to match portable subtasks with target resource vehicles. By organizing the computing power requirements of each portable subtask and extracting the running status of each target resource vehicle in the collaborative resource pool, the server establishes a mapping list between subtask requirements and resource vehicle capabilities.

[0127] Based on a matching list of needs and capabilities, the server constructs mapping relationships. Adhering to the core principles of matching subtask requirements with resource vehicle capabilities and ensuring subtask dependencies do not span multiple resources, subtasks are assigned to their corresponding target resource vehicles. For example, if a subtask's computing power requirement perfectly matches the idle computing power of resource vehicle A, and its dependent subtasks are already assigned to resource vehicle A, then it is directly mapped to resource vehicle A. If a subtask has no dependencies, it is preferentially assigned to a resource vehicle with a longer stable collaboration time window to ensure the subtask has sufficient time to complete execution and return results.

[0128] In one possible implementation, if the computing power requirement of a single subtask exceeds the independent carrying capacity of a certain resource vehicle, the server will further split the subtask into smaller sub-units, map them to multiple resource vehicles for parallel execution, and then merge the results after all sub-units are completed, thereby improving the execution efficiency of the subtasks.

[0129] This application's embodiments, by precisely matching subtask requirements with resource vehicle capabilities, avoid subtask execution failures due to insufficient computing power in resource vehicles, while fully utilizing the idle computing power of resource vehicles. By prioritizing the mapping of dependencies within the same vehicle, cross-vehicle data transmission and dependency waiting between subtasks are reduced, improving subtask execution efficiency. Furthermore, the implementation method of subtask splitting and mapping further expands the solution's adaptability to subtasks with high computing power requirements, enhancing the flexibility and applicability of the scheduling scheme.

[0130] Based on the matching of subtasks and resource vehicles, this application embodiment can achieve a more accurate mapping relationship by quantifying mapping benefits and combining constraints, thereby ensuring the efficiency and stability of subtask execution.

[0131] In one possible implementation, the server combines the computing power requirements of the target vehicle with the operating status of at least one target resource vehicle to establish a mapping relationship between subtasks and at least one target resource vehicle, including:

[0132] The server determines the mapping benefit between the subtask and the target resource vehicle based on the latency improvement brought by the subtask migration, the communication cost between the subtask and the target resource vehicle, and the score of the target resource vehicle, using an edge weight formula.

[0133] The formula for edge weight is:

[0134] ;

[0135] in, The mapping benefit between the subtask and the i-th resource vehicle. This represents the latency improvement value for subtask migration. The communication cost between the subtask and the i-th resource vehicle. The overall score for the i-th resource vehicle;

[0136] Based on the mapping benefits and constraints, the server establishes a mapping relationship between subtasks and at least one target resource vehicle; among which, the constraints are the maximum concurrency of a single vehicle, the completion and return of the subtask within a stable collaboration time window, and the slice bandwidth budget.

[0137] Mapping benefits refer to the quantified gains from allocating a subtask to a resource vehicle, considering latency improvement, communication costs, and resource vehicle quality. Latency improvement is the reduction in latency when the subtask is migrated to a resource vehicle for execution compared to its local execution on the target vehicle. Communication costs refer to the data transmission costs between the subtask and its corresponding resource vehicle, which are positively correlated with the amount of data transmitted and link latency. Constraints include at least the maximum number of subtasks that can be executed simultaneously on a single resource vehicle, the requirement that subtasks complete execution and data return within a stable collaboration time window, and the requirement that the data transmission bandwidth of the subtasks does not exceed a preset budget.

[0138] Based on the computing power requirements of the subtask, the server evaluates the latency of its execution on the target vehicle and the latency of its execution on the resource vehicle, respectively. The difference between the two is the latency improvement value. Furthermore, the server quantifies the data transmission cost between the subtask and the resource vehicle by combining the data volume of the subtask and the network quality of the resource vehicle.

[0139] After determining the latency improvement value and communication cost, the server uses the overall score, latency improvement value, and communication cost into the edge weight formula to calculate the mapping benefit of the target resource vehicle. The higher the mapping benefit, the better the overall effect of assigning the subtask to the target resource vehicle.

[0140] The server prioritizes allocating subtasks to resource vehicles with high return values, aiming to maximize mapping benefits. Furthermore, the allocation must simultaneously meet three constraints: the number of subtasks handled by a single resource vehicle cannot exceed its concurrency limit; the total execution and return time of subtasks cannot exceed the stable collaboration time window between the resource vehicle and the target vehicle; and the data transmission bandwidth of the subtasks cannot exceed the preset slice bandwidth budget.

[0141] This application's embodiments quantify mapping benefits, transforming the efficiency, cost, and quality of subtask allocation into calculable metrics, thus resolving the subjectivity issue of traditional allocation methods that rely on experience. Furthermore, by incorporating multi-dimensional constraints, it avoids resource overload, ensures subtasks complete execution within the collaboration window, controls bandwidth consumption, and improves the rationality and feasibility of the mapping relationship. Ultimately, it achieves optimal subtask allocation, maximizing the value of resource collaboration.

[0142] After completing the initial mapping between subtasks and target resource vehicles, this application embodiment introduces a risk optimization mechanism and a differentiated instruction issuance strategy to further improve the reliability of subtask execution and resource utilization efficiency.

[0143] In one possible implementation, after establishing the mapping relationship between the subtask and at least one target resource vehicle, the server also includes:

[0144] The server aims to minimize tail latency risk, target resource vehicle energy consumption, and slice bandwidth consumption. Combined with risk optimization constraints, the mapping relationship is optimized within the rolling time domain under risk-constrained conditions.

[0145] Based on the mapping relationship, the server issues execution instructions for corresponding subtasks to at least one target resource vehicle, including:

[0146] Based on the optimized mapping relationship, when the subtask is a critical task, the server adopts a replica offsetting strategy to simultaneously send the subtask to the cloud platform and the target resource vehicle corresponding to the subtask.

[0147] Based on the optimized mapping relationship, when the subtask is a batch task, the server uses an erasure coding strategy to divide the subtask into k valid data fragments and r redundant data fragments. The k valid data fragments and r redundant data fragments are then distributed to multiple target resource vehicles. The results can be merged after any k data fragments are returned. Here, k and r are integers greater than or equal to 1.

[0148] The server performs risk-constrained optimization on the established mapping relationship within the rolling time domain. The server's core objectives are to minimize tail latency risk, target resource vehicle energy consumption, and slice bandwidth consumption, while also incorporating risk optimization constraints, such as resource vehicle hardware load thresholds and subtask latency limits.

[0149] The server continuously monitors the operational status of target resource vehicles, the progress of subtasks, and network transmission within a specified time window. If a resource vehicle's load is nearing its limit, some of its subtasks are migrated to idle resource vehicles. If a subtask poses a risk of tail latency delays, it is prioritized for allocation of more computing resources. Simultaneously, the server optimizes data transmission paths, reduces cross-regional bandwidth consumption, and dynamically adjusts mapping relationships to balance multiple objectives while ensuring execution stability.

[0150] Subsequently, based on the optimized mapping relationship, the server adopts corresponding instruction delivery strategies for different task types. For critical tasks, such as autonomous driving environmental perception, a copy offsetting strategy is used. The same critical task is simultaneously delivered to the target resource vehicle and the cloud platform. If the resource vehicle completes on time and returns the result, it is directly forwarded to the target vehicle; if the resource vehicle times out or malfunctions, the execution result from the cloud platform is immediately used to avoid interruption of critical business operations.

[0151] For batch tasks, such as high-definition video encoding, an erasure coding strategy is adopted. The server divides the task into k valid data fragments and r redundant data fragments (the specific values ​​of k and r are adapted according to the scenario), and assigns all fragments to multiple target resource vehicles. After any k fragments (which can include valid data fragments and redundant data fragments) have completed execution and returned, the complete task result can be restored through the redundant fragments without waiting for all resource vehicles to complete. This improves parallel processing efficiency and enhances fault tolerance to resource vehicle failures.

[0152] This application's embodiments, through a combination of dynamic optimization and differentiated strategies, not only solve the problem that static mapping relationships are difficult to adapt to dynamic environments, but also provide precise execution guarantees for the core requirements of different tasks, effectively improving the reliability and efficiency of resource collaboration.

[0153] S105: The server issues the corresponding subtask execution instruction to at least one target resource vehicle based on the mapping relationship.

[0154] The server first uses the optimized mapping relationship to compile a list of subtasks that each target resource vehicle needs to undertake, and generates corresponding execution instructions for each subtask. The execution instructions clearly define the computational logic of the subtask, the input data segment, the GPU computing power allocation standard, the upper limit of video memory usage, and the time node and data format for result return, ensuring that the target resource vehicle can accurately adapt to the task execution requirements.

[0155] The server can use the low-latency communication channel of the vehicle network to send execution instructions for corresponding sub-tasks to each target resource vehicle. During the sending process, the server can adopt a one-to-one precise push mode, that is, according to the mapping relationship, the sub-task instructions are sent only to the corresponding target resource vehicle to avoid missent or cross-vehicle interference. At the same time, the server starts an instruction transmission monitoring mechanism to receive instruction reception feedback from the target resource vehicles in real time. If no feedback is received within a preset time, the instruction retransmission process is immediately triggered to ensure that the instructions are successfully delivered.

[0156] This application embodiment achieves precise matching between subtasks and target resource vehicles by issuing targeted execution instructions, based on mapping relationships, thus avoiding resource waste and instruction transmission redundancy. Standardized execution instructions provide clear and unified execution guidelines for target resource vehicles, reducing the risk of subtask execution deviations. The monitoring and retransmission mechanism for instruction transmission ensures the reliability of instruction issuance, guaranteeing that subtasks can start execution on time, effectively connecting task allocation and task execution, and laying the foundation for the efficient advancement of overall business tasks.

[0157] S106: The server receives the subtask execution results uploaded by at least one target resource vehicle, and forwards the subtask execution results to the target vehicle so that the target vehicle can complete the merging of business task information execution results and business output based on the subtask execution results fed back by at least one target resource vehicle.

[0158] After sending subtasks to each target resource vehicle, the server continuously monitors the execution progress of these subtasks. Once the target resource vehicles have completed their calculations, the server can receive the subtask execution results uploaded by each vehicle through the vehicle-to-everything (V2X) high-reliability transmission channel. During the reception process, the server can verify the result data. On one hand, it checks whether the data format conforms to the preset specifications; on the other hand, it verifies the data integrity through a checksum. If a format error or missing data is found, the server immediately sends a retransmission request to the corresponding resource vehicle to ensure the accuracy of the received results.

[0159] Based on the dependencies between subtasks, the server sorts and organizes all valid execution results, then forwards the results in batches to the target vehicle via a low-latency communication link. If there are critical tasks employing a replica offsetting strategy, the server will prioritize forwarding the results of tasks completed earlier, while discarding redundant results to reduce transmission overhead. After receiving the results, the target vehicle initiates a result merging process, integrating the scattered subtask results into a complete business task output, which is ultimately applied to the actual business scenario.

[0160] In one possible implementation, if some resource vehicles fail to return results on time due to malfunctions, the server will enable redundant backups to supplement the missing data, ensuring that the target vehicle can obtain the complete result set and avoiding interruptions in the merging process.

[0161] This application's embodiments ensure the accuracy and completeness of subtask execution results through a result reception verification mechanism, preventing erroneous data from affecting the final business output. Furthermore, forwarding results in a dependency-based order provides a clear logical basis for merging results from the target vehicle, improving merging efficiency. The redundant backup and supplementation mechanism effectively addresses the issue of missing results due to resource vehicle failures, ensuring the continuity of business tasks.

[0162] The above embodiments describe the method with the server as the main component. The following will combine... Figure 2 The architecture shown and Figure 3 The interactive flow shown describes the interaction process between the server, resource vehicle, and target vehicle. This method's interactive flow centers on the server running the cloud-based scheduling center, achieving multi-terminal collaboration through edge proxies on the target vehicle and resource vehicle. The specific interactive process is as follows:

[0163] During the data collection and status reporting phase, when a user triggers a highly interactive service, the load prediction and task description module in the edge agent of the target vehicle collects its own vehicle status, information on the business tasks to be executed, and road and network environment data in real time, and reports the data to the status aggregation module of the server through communication links (such as RSU, 5G or V2X).

[0164] After receiving data uploaded by the edge agent of the target vehicle, the server sends a data collection request to the edge agent of the resource vehicle. Similarly, the edge agent of the resource vehicle synchronously collects its own vehicle status and reports the data to the server's status aggregation module through the same link.

[0165] During the collaborative resource selection phase, after receiving data from multiple sources, the server integrates and generates a feature snapshot within a unified time window. The server's collaborative resource selection module calculates a stable collaboration time window based on the feature snapshot and uses a scoring function to filter target resource vehicles.

[0166] During the task segmentation phase, the server abstracts business tasks into a hypergraph through the task segmentation and allocation module, segments them into migrateable subtasks, and establishes a mapping relationship between subtasks and resource vehicles.

[0167] During the task allocation phase, the server sends subtask execution instructions to the edge agent of the corresponding resource vehicle via Temporary Message Passing (TMP) link. If the subtask is a critical task, a replica instruction is simultaneously sent to its own computing power node in the cloud; if the subtask is a batch task, the sharding instruction is distributed to multiple resource vehicles.

[0168] During the subtask execution and result feedback phase, the edge agent of the resource vehicle completes the subtask calculation through the GPU execution and feedback module, and after the execution guardian module verifies the result, it sends the execution result back to the server through the TMP link.

[0169] After receiving and verifying the result, the server forwards it to the edge agent of the target vehicle. If duplicate fragments or redundant fragments exist, valid results are forwarded first.

[0170] The edge agent of the target vehicle integrates the results of subtasks through the result merging and rollback modules to complete the output of business tasks.

[0171] The server's steady-state and fallback module monitors the execution status of subtasks in the rolling time domain. If a risk is detected, such as resource vehicle overload, the mapping relationship is dynamically adjusted and instructions are reissued. If the resource vehicle fails to execute, the cloud-based fallback computing power is triggered to execute the task.

[0172] The server's security and settlement module uses Key Management Service (KMS) to encrypt data transmission, record resource usage at each end, and complete collaborative settlement.

[0173] The above interaction process utilizes the computing power of resource vehicles efficiently through the central scheduling of the server and the collaboration of edge agents on multiple terminals, ensuring the stable execution of the target vehicle's business tasks.

[0174] This application also provides a vehicle resource scheduling device, such as... Figure 4 As shown, the device includes:

[0175] The acquisition module 401 is used to collect road and network environment data, the vehicle status of at least one resource vehicle in the vicinity, the vehicle status of the target vehicle, and the business task information of the target vehicle in real time, and generate a feature snapshot of a unified time window.

[0176] The filtering module 402 is used to determine the stable collaboration time window between each resource vehicle and the target vehicle based on the feature snapshot, and to filter at least one suitable target resource vehicle to form a collaborative resource pool.

[0177] The segmentation module 403 is used to abstract the business tasks of the target vehicle into a hypergraph based on the business task information and segment them into transferable subtasks. It also establishes a mapping relationship between the subtasks and at least one target resource vehicle by combining the computing power requirements of the target vehicle with the operating status of at least one target resource vehicle.

[0178] The issuing module 404 is used to issue execution instructions for corresponding sub-tasks to at least one of the target resource vehicles based on the mapping relationship;

[0179] The receiving module 405 is used to receive the subtask execution results uploaded by at least one of the target resource vehicles, and forward the subtask execution results to the target vehicle, so that the target vehicle can complete the merging of the execution results of the business task information and the business output based on the subtask execution results fed back by at least one of the target resource vehicles.

[0180] In one possible implementation, the acquisition module 401 is specifically used to perform unified alignment processing on the acquired data and generate a feature snapshot with a preset time window; if the acquired data has missing packets or the timestamp drift is greater than the preset time, interpolation or discard processing is triggered for the abnormal data; if the data acquired in multiple consecutive rounds all contain abnormal data, the cloud platform calls its own computing power resources to independently complete the business task of the target vehicle and push the execution result to the target vehicle.

[0181] In one possible implementation, the filtering module 402 is specifically used to calculate the dwell time, lane co-operation time, and connectivity time between each resource vehicle and the target vehicle based on the data in the feature snapshot; wherein, the dwell time is determined based on the relative speed and heading of the resource vehicle and the target vehicle; the lane co-operation time is determined based on the map, intersection density, and lane-changing intentions; the connectivity time is determined based on network coverage and signal quality; and for each resource vehicle, a stable cooperation time window between the resource vehicle and the target vehicle is determined based on the dwell time, lane co-operation time, and connectivity time between the resource vehicle and the target vehicle.

[0182] In one possible implementation, the filtering module 402 is specifically used to perform a comprehensive score on each resource vehicle based on the vehicle status of the resource vehicle in the feature snapshot and the stable cooperation time window corresponding to the resource vehicle, through a scoring function.

[0183] The scoring function is:

[0184] ;

[0185] in, Give a score to the i-th resource vehicle; Score the computing power surplus of the i-th resource vehicle; Score the network quality of the i-th resource vehicle; Let i be the reward and penalty function based on a stable cooperation time window for the i-th resource vehicle; Score the driving risk of the i-th resource vehicle; , , and Adaptive weighting for different scenarios; amplification in high-speed formation scenarios. and Weighting, amplifying weights in urban scenarios , and ;

[0186] The scores of each resource vehicle are sorted from largest to smallest, and the top N resource vehicles in the score ranking are selected as the target resource vehicles to form a collaborative resource pool; N is an integer greater than or equal to 1.

[0187] In one possible implementation, the segmentation module 403 is specifically used to abstract the business task pipeline of the target vehicle into a hypergraph G=(V,E) based on the business task information; where V is the set of task nodes and E is the set of hyperedges, and the weight of the hyperedge is determined by the data volume, link latency and dependency level penalty value between the corresponding tasks; the hypergraph is divided with the goal of minimizing cross-vehicle dependency and minimizing data transmission volume, and subgraphs with weak dependencies and small data volume are segmented first to obtain multiple transferable subtasks and the dependency relationships between the multiple transferable subtasks.

[0188] In one possible implementation, the segmentation module 403 is specifically used to determine the mapping benefit between the subtask and the target resource vehicle based on the latency improvement value brought about by the subtask migration, the communication cost between the subtask and the target resource vehicle, and the score of the target resource vehicle, through an edge weight formula.

[0189] The formula for the edge weight is:

[0190] ;

[0191] in, The mapping benefit between the subtask and the i-th resource vehicle. This represents the latency improvement value for subtask migration. The communication cost between the subtask and the i-th resource vehicle. The overall score for the i-th resource vehicle;

[0192] Based on the mapping benefits and constraints, a mapping relationship is established between the subtask and at least one of the target resource vehicles; wherein, the constraints are the maximum concurrency limit for a single vehicle, the completion and return of the subtask within a stable collaboration time window, and the slice bandwidth budget.

[0193] In one possible implementation, the apparatus further includes an optimization module; the optimization module is used to perform risk-constrained optimization of the mapping relationship in the rolling time domain with the optimization objectives of minimizing tail delay risk, target resource vehicle energy consumption and slice bandwidth consumption, combined with risk optimization constraints.

[0194] The distribution module 404 is specifically used to, based on the optimized mapping relationship, simultaneously distribute the subtask to the cloud platform and the target resource vehicle corresponding to the subtask using a replica offsetting strategy when the subtask is a critical task; based on the optimized mapping relationship, when the subtask is a batch task, the subtask is divided into k valid data fragments and r redundant data fragments using an erasure coding strategy, and the k valid data fragments and r redundant data fragments are assigned to multiple target resource vehicles, and the results can be merged after any k data fragments are returned; where k and r are integers greater than or equal to 1.

[0195] This application also provides a control device. The control device may include a memory and a processor. The processor is used to execute the vehicle resource scheduling method described in any of the above embodiments. The memory may be random access memory (RAM), flash memory, read-only memory (ROM), non-volatile read-only memory (EPROM), registers, hard disk, removable disk, etc.

[0196] Memory can store computer instructions, which, when executed by a processor, can be used to implement vehicle resource scheduling methods. Memory can also store data.

[0197] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape) or a semiconductor medium (e.g., solid-state disk (SSD)).

[0198] This application also provides a readable storage medium for storing the methods provided in the above embodiments. For example, RAM, flash memory, ROM, EPROM, registers, hard disk, removable disk, or any other form of storage medium in the art.

[0199] In the embodiments of this application, the terms "first" and "second" (if they exist) are used only as name identifiers and do not represent the order of first and second.

[0200] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Regarding the methods disclosed in the embodiments, since they correspond to the product embodiments disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the description of the product embodiments.

[0201] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A vehicle resource scheduling method, characterized in that, Applied to a cloud platform, the method includes: Real-time data collection of road and network environment, vehicle status of at least one resource vehicle in the vicinity, vehicle status of the target vehicle, and business task information of the target vehicle are generated to generate a feature snapshot of a unified time window. Based on the feature snapshot, a stable collaboration time window between each resource vehicle and the target vehicle is determined, and at least one suitable target resource vehicle is selected to form a collaborative resource pool. Based on the business task information, the business tasks of the target vehicle are abstracted into a hypergraph and divided into transferable subtasks. Combining the computing power requirements of the target vehicle with the operating status of at least one of the target resource vehicles, a mapping relationship between the subtasks and at least one of the target resource vehicles is established. Based on the mapping relationship, the execution instructions of the corresponding sub-tasks are issued to at least one of the target resource vehicles; The system receives subtask execution results uploaded by at least one of the target resource vehicles and forwards the subtask execution results to the target vehicle, so that the target vehicle can complete the merging of execution results and business output of the business task information based on the subtask execution results fed back by at least one of the target resource vehicles.

2. The method according to claim 1, characterized in that, The generation of a unified time window feature snapshot includes: All types of collected data are uniformly aligned and processed to generate feature snapshots with a preset time window duration; If the collected data has missing packets or the timestamp drifts for more than a preset time, the abnormal data will be interpolated or discarded. If the data collected in multiple consecutive rounds contains abnormal data, the cloud platform will use its own computing resources to independently complete the business task of the target vehicle and push the execution result to the target vehicle.

3. The method according to claim 1, characterized in that, The step of determining the stable cooperation time window between each resource vehicle and the target vehicle based on the feature snapshot includes: Based on the data in the feature snapshot, the dwell time, co-location time, and connectivity time between each resource vehicle and the target vehicle are calculated; wherein, the dwell time is determined based on the relative speed and heading of the resource vehicle and the target vehicle; the co-location time is determined based on the map, intersection density, and lane-changing intentions; and the connectivity time is determined based on network coverage and signal quality. For each resource vehicle, a stable cooperation time window between the resource vehicle and the target vehicle is determined based on the dwell time, co-location time, and connection time between the resource vehicle and the target vehicle.

4. The method according to claim 1, characterized in that, The selected and matched target resource vehicle forms a collaborative resource pool, including: For each of the resource vehicles, based on the vehicle status of the resource vehicle in the feature snapshot and the stable cooperation time window corresponding to the resource vehicle, a comprehensive score is given to the resource vehicle through a scoring function; The scoring function is: ； in, Give a score to the i-th resource vehicle; Score the computing power surplus of the i-th resource vehicle; Score the network quality of the i-th resource vehicle; Let i be the reward and penalty function based on a stable cooperation time window for the i-th resource vehicle; Score the driving risk of the i-th resource vehicle; , , and Adaptive weighting for different scenarios; amplification in high-speed formation scenarios. and Weighting, amplifying weights in urban scenarios , and ; The scores of each resource vehicle are sorted from largest to smallest, and the top N resource vehicles in the score ranking are selected as the target resource vehicles to form a collaborative resource pool; N is an integer greater than or equal to 1.

5. The method according to claim 1, characterized in that, The process of abstracting the target vehicle's business tasks into a hypergraph based on the business task information and dividing it into transferable subtasks includes: Based on the business task information, the business task pipeline of the target vehicle is abstracted as a hypergraph G=(V,E); where V is the set of task nodes and E is the set of hyperedges. The weight of the hyperedge is determined by the amount of data between the corresponding tasks, the link latency, and the dependency level penalty value. The hypergraph is partitioned with the goal of minimizing cross-vehicle dependencies and minimizing data transmission volume. Subgraphs with weak dependencies and small data volumes are prioritized to obtain multiple transferable subtasks and the dependencies between these multiple transferable subtasks.

6. The method according to claim 1, characterized in that, The step of establishing a mapping relationship between subtasks and at least one of the target resource vehicles by combining the computing power requirements of the target vehicle with the operating status of at least one of the target resource vehicles includes: Based on the latency improvement brought about by the subtask migration, the communication cost between the subtask and the target resource vehicle, and the score of the target resource vehicle, the mapping benefit between the subtask and the target resource vehicle is determined by the edge weight formula; The formula for the edge weight is: ； in, The mapping benefit between the subtask and the i-th resource vehicle. This represents the latency improvement value for subtask migration. The communication cost between the subtask and the i-th resource vehicle. The overall score for the i-th resource vehicle; Based on the mapping benefits and constraints, a mapping relationship is established between the subtask and at least one of the target resource vehicles; wherein, the constraints are the maximum concurrency limit for a single vehicle, the completion and return of the subtask within a stable collaboration time window, and the slice bandwidth budget.

7. The method according to claim 1, characterized in that, After establishing the mapping relationship between the subtask and at least one of the target resource vehicles, the process also includes: With the optimization objectives of minimizing tail delay risk, target resource vehicle energy consumption, and slice bandwidth consumption, the mapping relationship is subjected to risk-constrained optimization in the rolling time domain, combined with risk optimization constraints. The step of issuing execution instructions for corresponding sub-tasks to at least one of the target resource vehicles based on the mapping relationship includes: Based on the optimized mapping relationship, when the subtask is a critical task, a replica offsetting strategy is adopted to simultaneously issue the subtask to the cloud platform and the target resource vehicle corresponding to the subtask. Based on the optimized mapping relationship, when the subtask is a batch task, the erasure coding strategy is used to divide the subtask into k valid data fragments and r redundant data fragments. The k valid data fragments and the r redundant data fragments are assigned to multiple target resource vehicles. The results can be merged after any k data fragments are returned. Here, k and r are integers greater than or equal to 1.

8. A vehicle resource scheduling device, characterized in that, The device, applied to a cloud platform, includes: The data acquisition module is used to collect real-time road and network environment data, the vehicle status of at least one resource vehicle in the vicinity, the vehicle status of the target vehicle, and the business task information of the target vehicle, and generate a feature snapshot of a unified time window. The filtering module is used to determine the stable collaboration time window between each resource vehicle and the target vehicle based on the feature snapshot, and to filter at least one suitable target resource vehicle to form a collaborative resource pool. The segmentation module is used to abstract the business tasks of the target vehicle into a hypergraph based on the business task information and segment them into transferable subtasks. Combining the computing power requirements of the target vehicle with the operating status of at least one of the target resource vehicles, a mapping relationship is established between the subtasks and at least one of the target resource vehicles. The distribution module is used to distribute execution instructions for corresponding sub-tasks to at least one of the target resource vehicles based on the mapping relationship; The receiving module is used to receive the subtask execution results uploaded by at least one of the target resource vehicles, and forward the subtask execution results to the target vehicle, so that the target vehicle can complete the merging of the execution results of the business task information and the business output based on the subtask execution results fed back by at least one of the target resource vehicles.

9. A control device, characterized in that, It includes a processor and a memory, the memory being used to store programs, instructions, or code, and the processor being used to execute the programs, instructions, or code in the memory to perform the vehicle resource scheduling method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The system contains a computer program that is loaded by a processor to execute the vehicle resource scheduling method as described in any one of claims 1-7.

Images