Calculation task allocation method and control module for vehicle-road cooperation vehicle formation

Abstract

The invention relates to the field of Internet of Vehicles, in particular to a calculation task allocation method and a control module for a vehicle-road cooperation vehicle formation. The method comprises the following steps: firstly, dynamically updating calculation tasks of a vehicle formation, classifying the calculation tasks and adding label information to form a global task pool; and obtaining residual computing power values of computing power nodes such as a head vehicle, a following vehicle, a road test MEC and a cloud server, and detecting node health degrees to form a multi-source computing power pool. Then predicting a potential task of each calculation task and calculating a calculation power dependency degree and a priority degree; performing basic capability scoring on each computing power node, and screening candidate nodes of which the basic capability scores are higher than a preset value; and finally, performing many-to-many matching on each calculation task and candidate node in the double pools by taking the lowest total execution cost of the calculation task and the overall load balance of the calculation power node as optimization targets. According to the method, the problems of relatively large task delay and unbalanced equipment load caused by unreasonable calculation task allocation in the existing vehicle formation can be solved.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking, and in particular to a computational task allocation method for vehicle platooning in vehicle-road cooperative systems, and the corresponding computer program product and vehicle platooning control module. Background Technology

[0002] In recent years, intelligent connected driving technology has made significant progress. Vehicle platooning technology, as an important application, can effectively reduce air resistance, improve road utilization, reduce energy consumption, and enhance traffic safety through close coordination and following between vehicles. During platooning, the lead vehicle, as the control core of the entire platoon, undertakes key tasks such as environmental perception, path planning, and decision-making control, thus placing a particularly high demand on computing resources.

[0003] Although vehicle platooning technology has made some progress, it still faces many challenges in practical applications: (1) Excessive computational burden on the lead vehicle: In existing platooning systems, the lead vehicle needs to handle its own perception, decision-making tasks, and overall platoon control logic simultaneously, resulting in a shortage of computing resources and affecting the real-time performance and reliability of the system. (2) Limited system scalability: Under the traditional architecture, the expansion of the platoon size will lead to an exponential increase in the computational load of the lead vehicle, which limits the operational boundaries and flexibility of platooning applications. (3) Excessive network dependence: Schemes that rely entirely on vehicle-road cooperation are prone to control delays or even failures in areas with unstable network signals (such as tunnels and mountainous areas), affecting the safety of the platoon. (4) Coarse task allocation strategy: Existing technologies mostly adopt fixed task allocation modes, which fail to fully consider the real-time characteristics of tasks, changes in network status, and dynamic fluctuations in computing resources, resulting in low resource utilization. (5) Difficulty in coordinating heterogeneous systems: The lead vehicle and edge computing nodes and cloud servers are heterogeneous in terms of hardware architecture, operating system, and communication protocol, which increases the complexity of collaborative computing.

[0004] The implementation of vehicle platooning, whether it is a single autonomous driving solution or a connected vehicle platooning based on vehicle-road cooperation, requires a large number of vehicle sensors and a certain amount of computing resources. However, the limited computing resources on the vehicle side make it difficult to meet the real-time requirements of related task calculations in platooning scenarios, which has become an obstacle to the implementation of vehicle platooning technology. Summary of the Invention

[0005] To address the issues of excessive task latency and unbalanced equipment load caused by unreasonable allocation of computational tasks in existing vehicle platooning systems, this invention provides a computational task allocation method for vehicle-road cooperative vehicle platooning, along with its corresponding computer program product and vehicle platooning control module.

[0006] The technical solution provided by this invention is as follows: A method for allocating computational tasks for vehicle platooning in vehicle-road cooperative systems includes the following process: The computational tasks of all vehicles in the platoon are dynamically updated, including the core tasks of the lead vehicle and the peripheral tasks of the following vehicles. Each computational task is categorized and labeled with tags containing computing power requirements, latency sensitivity, security risk coefficients, and task source identifiers to form a global task pool.

[0007] The system acquires resource status information reported by each computing node, including the lead vehicle, following vehicles, road test MECs, and cloud servers, and calculates the remaining computing power. It then evaluates the node health and communication latency of each computing node using heartbeat detection and differentiated probe mechanisms; and selects computing nodes with health values ​​higher than preset values ​​to form a multi-source computing power pool.

[0008] Predict potential tasks for each computing task and generate the computing power dependency for each task; combine tag information and computing power dependency to generate the priority of each computing task. Based on health, remaining computing power value, and communication latency, perform basic capability scoring on each computing power node in the multi-source computing power pool, and select computing power nodes with basic capability scores higher than preset values ​​to form candidate nodes.

[0009] Priority, computing power requirement, latency threshold, and security level are used as task-side matching parameters; remaining computing power and communication cost are used as computing power-side matching parameters; constraints on task latency and computing power node load are preset; with the optimization objectives of minimizing the total execution cost of computing tasks and balancing the overall load of computing power nodes, an improved greedy algorithm is used to perform global many-to-many matching between computing tasks in the global task pool and candidate nodes in the multi-source computing power pool.

[0010] As a further improvement of the present invention, the core tasks of the lead vehicle include global path planning and formation control, while the edge tasks of the following vehicles include local obstacle detection assistance, log statistics, and formation status synchronization.

[0011] As a further improvement of this invention, the computational tasks are divided into four categories: perception, decision-making, control, and management. Perception-related computational tasks are further divided into obstacle detection and traffic sign recognition; decision-making-related computational tasks are divided into path planning and behavioral decision-making; control-related computational tasks are divided into trajectory tracking and vehicle control; and management-related computational tasks are divided into formation maintenance and resource coordination.

[0012] As a further improvement of the present invention, the computing power requirements of each computing task include CPU utilization, GPU utilization and memory utilization, and the latency sensitivity information includes maximum tolerable latency and latency sensitivity weight.

[0013] As a further improvement of the present invention, the global task pool adopts a 1-second sliding window to receive new tasks in real time, remove completed tasks, and synchronously update the computing power dependency and priority of tasks.

[0014] As a further improvement of this invention, the method of evaluating the performance of computing nodes through heartbeat detection and differential probe mechanism includes: For core computing nodes including lead vehicles and roadside MECs, a heartbeat packet is sent every 200ms and a virtual test packet is sent every 500ms. Multiple performance indicators, including response latency and packet loss rate, are evaluated, and a health assessment value is generated based on the results of each indicator.

[0015] For edge computing nodes that include vehicle-following and cloud servers, a heartbeat packet is sent every 500ms, a stress test packet is sent randomly, and multiple performance indicators, including corresponding latency, load stability and communication reliability, are evaluated; and a health assessment value is generated based on the results of each indicator.

[0016] As a further improvement of the present invention, the multi-source computing power pool adopts an adaptive sliding window to filter out failed nodes with a health level less than a threshold in real time.

[0017] As a further improvement of the present invention, the computing power requirement value of the computing task and the remaining computing power value of the computing power node are generated based on the index data through a multi-dimensional vector modeling algorithm and converted into a unified representation value.

[0018] As a further improvement of this invention, the potential tasks for each real-time computing task are generated by a potential task prediction model pre-trained based on an LSTM model. The potential task prediction model is used to generate the trigger probability of various tasks based on the multi-dimensional features of the input, including vehicle speed, acceleration, and road curves, and then the tasks with trigger probabilities higher than a preset value are taken as potential tasks for the current computing task.

[0019] As a further improvement of the present invention, the formula for calculating the computing power dependence of the current computing task based on the predicted potential tasks of the current computing task is as follows: The computational power dependency of the current computing task = 0.7 × the computational power requirement of the current computing task + 0.3 × the computational power requirement of the potential tasks of the current task.

[0020] As a further improvement of the present invention, the formula for calculating the priority of any computation task is as follows: Priority = 0.4 × computing power dependence + 0.3 × latency sensitivity weight + 0.2 × security risk coefficient + 0.1 × weight corresponding to task source identifier.

[0021] In the above formula, among the weights corresponding to the task source identifier, the value of the lead vehicle task is 0.6; the value of the following vehicle task is 0.4; the safety risk coefficient is related to the task type, with the value of 0.8 for control type, 0.6 for decision type, 0.5 for perception type, and 0.2 for management type.

[0022] As a further improvement to this invention, the calculation formula for the basic capability score of each computing node is as follows: Basic capability score = 0.5 × health status + 0.3 × remaining computing power + 0.2 × communication latency score Among them, the higher the communication latency of any computing node, the lower the communication latency score.

[0023] As a further improvement of the present invention, the global many-to-many matching process between the computation task and the candidate nodes includes the following steps: (1) Sort each computing task in the global task pool according to priority and use it as the object of each row. Sort each candidate node in the multi-source computing power pool according to basic capability score and use it as the object of each column. Then construct a matching matrix. The elements in the matching matrix are the execution costs of the corresponding computing tasks when they are executed on the candidate nodes.

[0024] (2) Match the top 30% of computing tasks by priority to the candidate nodes that have the lowest execution cost in order of priority; (3) Distribute the remaining computing tasks to each candidate node according to the principle of minimizing the load rate, and each computing task is preferentially matched with candidate nodes with a load rate of less than 60%; (4) Migrate some computing tasks on candidate nodes with a load rate higher than 80% to candidate nodes with a load rate lower than 50% to optimize the overall load balance.

[0025] As a further improvement of the present invention, under the preset constraints, the latency of the core task is less than 50ms, the latency of the other tasks is less than 200ms, and the load of each computing node is less than 85%.

[0026] As a further improvement of the present invention, the formula for calculating the execution cost of any computational task on any candidate node is as follows: Execution cost = 0.4 × computation cost + 0.4 × communication cost + 0.2 × migration cost In the above formula, the computation cost is the ratio of the computational power requirement of the computational task to the remaining computational power of the computational node; the communication cost is calculated based on the network distance and device bandwidth; and the migration cost is characterized by the communication cost between the two migration objects.

[0027] The present invention also includes a computer program product, which includes a computer program that, when executed by a processor, implements the aforementioned method for allocating computational tasks for vehicle platooning in a vehicle-road cooperative manner, dynamically allocating each computational task generated by the vehicle platooning to each computing node.

[0028] The present invention also includes a vehicle platooning control module, which includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the aforementioned method for allocating computational tasks for vehicle-road cooperative vehicle platooning, dynamically allocating each computational task generated by the vehicle platooning to each computing node.

[0029] The present invention has the following beneficial effects: This invention constructs a global task pool and a multi-source computing power pool on the vehicle side, dynamically updates and standardizes the global task pool, and evaluates and selects leaders for the multi-source computing power pool. Then, with the optimization objectives of minimizing task latency and balancing resource load, a multi-objective optimization greedy algorithm is used to perform many-to-many matching between multiple computing tasks in the task pool and candidate nodes in the computing power pool. This matching scheme maximizes global computing power utilization and optimizes system load balancing while ensuring task real-time performance and security, thereby completely solving the problems of high computational pressure on the lead vehicle and inefficient resource allocation; and improving the reliability and security of vehicle platooning. Attached Figure Description

[0030] Figure 1 This is a flowchart of the steps of the computational task allocation method for vehicle-road cooperative vehicle platooning provided in Embodiment 1 of the present invention.

[0031] Figure 2 This is the classification method for computational tasks in Embodiment 1 of the present invention. Detailed Implementation

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

[0033] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the specification of this invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "or / and" as used herein includes any and all combinations of one or more of the associated listed items.

[0034] Example 1 In existing vehicle platooning systems, each vehicle achieves global unmanned collaborative control through autonomous driving and vehicle-to-infrastructure (V2I) communication, primarily through the lead vehicle. Therefore, the lead vehicle bears a particularly heavy computational burden in this mode. Furthermore, because the system distributes the majority of computational tasks to the lead vehicle without implementing safety redundancy, a failure in the lead vehicle can cause the entire platoon's automatic control to malfunction, resulting in significant system risks. Current research on vehicle platooning mainly focuses on overall vehicle platooning control and intra-platoon communication—essentially single-vehicle platooning solutions. Even when incorporating V2I strategies, roadside MECs and cloud servers are merely used as "perception units providing beyond-line-of-sight services," with the roadside and cloud serving as data providers; the computational tasks are still primarily performed by the lead vehicle in the platoon.

[0035] To address this issue, this embodiment provides a computational task allocation method for vehicle-road cooperative vehicle platooning. This scheme constructs a global task pool and a multi-source computing power pool at the vehicle end (with the lead vehicle acting as the control hub). A multi-objective optimization greedy algorithm is used to achieve dynamic many-to-many matching between multiple tasks in the task pool and multiple computing power nodes in the computing power pool. This scheme maximizes global computing power utilization and optimizes system load balancing while ensuring task real-time performance and security, thereby completely resolving the problems of high computational pressure on the lead vehicle and inefficient resource allocation.

[0036] Specifically, such as Figure 1 As shown, the computational task allocation method for vehicle-road cooperative vehicle platooning provided in this embodiment includes the following steps: I. Construct a global task pool: The computational tasks of all vehicles in the platoon are dynamically updated, including the core tasks of the lead vehicle and the peripheral tasks of the following vehicles. Each computational task is categorized and labeled with tags containing computing power requirements, latency sensitivity, security risk coefficients, and task source identifiers to form a global task pool.

[0037] In this embodiment, the constructed global task pool is used to dynamically aggregate all computational tasks generated throughout the vehicle platoon. Its construction process core includes three parts: task source expansion, task standardization, and a dynamic update mechanism. Specifically, at the task source expansion level, this embodiment aggregates the computational tasks of all vehicles within the platoon through the global task pool. For example, for the lead vehicle, its core tasks include global path planning and platoon control. For the following vehicles, their peripheral tasks include local obstacle detection assistance, log statistics, and platoon status synchronization.

[0038] To achieve scientific management of the collected computing tasks, this embodiment adds uniform tag information to each task to achieve task standardization. Specifically, at the task standardization processing level, such as... Figure 2 As shown, this embodiment categorizes all possible computational tasks generated by vehicle platooning into four types: perception, decision-making, control, and management. Perception tasks are further divided into obstacle detection and traffic sign recognition; decision-making tasks into path planning and behavioral decision-making; control tasks into trajectory tracking and vehicle control; and management tasks into platoon maintenance and resource coordination. For each type of computational task, this embodiment uses its corresponding computing power requirement, latency sensitivity, security risk coefficient, and task source identifier as tag information, which is then encapsulated into the core metadata of the computational task to obtain standardized task entries. Specifically, the computing power requirement information for each computational task includes CPU utilization, GPU utilization, and memory utilization, while the latency sensitivity information includes maximum tolerable latency and latency sensitivity weight. In this embodiment, to facilitate matching between tasks and computing power, the computing power requirement value of the computational task is generated based on indicator data using a multi-dimensional vector modeling algorithm and converted into a unified representation value (such as TFLOPS equivalent, memory bandwidth index, etc.).

[0039] Finally, in order to achieve dynamic updates to the global task pool, this embodiment uses a 1-second sliding window to receive new tasks in real time, remove completed tasks, and synchronously update the computing power dependency and priority of tasks.

[0040] II. Constructing a multi-source computing power pool: The system acquires resource status information reported by each computing node, including the lead vehicle, following vehicles, road test MECs, and cloud servers, and calculates the remaining computing power. It then evaluates the node health and communication latency of each computing node using heartbeat detection and differentiated probe mechanisms; and selects computing nodes with health values ​​higher than preset values ​​to form a multi-source computing power pool.

[0041] In this embodiment, the constructed multi-source computing power pool is used to aggregate all computing power nodes within the vehicle platoon capable of participating in computational tasks. In practical applications, these computing power nodes include the lead vehicle and following vehicles in the platoon, as well as road test MECs and cloud servers. The lead vehicle and following vehicles serve as fixed computing power resources, participating in computational tasks at all times. The road test MECs and cloud servers, on the other hand, are dynamic computing power resources; their ability to participate in computational tasks depends on an evaluation considering factors such as the real-time location of the vehicle platoon.

[0042] To monitor all available computing resources for the vehicle platoon in real time, this embodiment requires each computing node to proactively report its resource status. After evaluation, available computing nodes are included in a multi-source computing pool. Specifically, in the vehicle-to-everything (V2X) system, both the MEC (Multi-access Edge Computing) side and the cloud server deploy computing power sharing interfaces, encapsulating the status of their CPU, GPU, memory, and other computing resources according to standard protocols such as OpenFlow and RESTful. The vehicle-side uses a distributed hash table (DHT) structure to store computing power information.

[0043] In this embodiment, the remaining computing power value of each computing node and the computing power requirement value of the computing task are both generated based on indicator data through a multidimensional vector modeling algorithm and converted into a unified representation value. For example, the roadside MEC updates real-time resource indicators such as CPU load and GPU utilization every 100ms; the cloud server periodically pushes available computing instance parameters. After receiving the computing power data from heterogeneous nodes, the lead vehicle converts the physical resources into standardized computing power representation values ​​through a multidimensional vector modeling algorithm.

[0044] In practical applications of this embodiment, as the vehicle platoon moves, the performance of dynamic computing nodes gradually deteriorates due to factors such as communication quality. To assess the health of each computing node, this embodiment introduces a heartbeat detection and differentiated probe mechanism to evaluate node performance. Specifically, this mechanism includes: for core computing nodes containing the lead vehicle and roadside MEC, a heartbeat packet is sent every 200ms, and a virtual test packet is sent every 500ms, evaluating multiple performance metrics including response latency and packet loss rate; and generating a health assessment value based on the results of these metrics. For edge computing nodes containing following vehicles and cloud servers, a heartbeat packet is sent every 500ms, and a stress test packet is randomly sent, evaluating multiple performance metrics including response latency, load stability, and communication reliability; and generating a health assessment value based on the results of these metrics.

[0045] Finally, this embodiment combines the reported computing power resources and the active evaluation results of each computing power node to construct a multi-source computing power pool consisting of several computing power nodes, including information such as node location, network connectivity, and remaining computing power value. Furthermore, it should be noted that, similar to the global task pool, the multi-source computing power pool in this embodiment also uses an adaptive sliding window to update computing power nodes and filters out failed nodes with health levels below a threshold in real time. After filtering out failed nodes, the topology among the remaining computing power nodes in the multi-source computing power pool is also dynamically updated.

[0046] III. Evaluate the computational task and select computing nodes: Predict potential tasks for each computing task and generate the computing power dependency for each task; combine tag information and computing power dependency to generate the priority of each computing task. Based on health, remaining computing power value, and communication latency, perform basic capability scoring on each computing power node in the multi-source computing power pool, and select computing power nodes with basic capability scores higher than preset values ​​to form candidate nodes.

[0047] To analyze the compatibility between computing tasks and computing nodes, this implementation evaluates computing tasks using computing power dependency and limitation, and evaluates computing nodes using basic capability scoring. Computing power dependency reflects the maximum amount of computing resources a computing task needs to reserve during execution to ensure processing efficiency. To ensure efficient task processing, this embodiment also considers related tasks that may be generated during the execution phase of the current task when evaluating its computing power dependency; these are referred to as "potential tasks." In practical applications, potential tasks for each real-time computing task are generated using a potential task prediction model pre-trained based on an LSTM model. The potential task prediction model generates the trigger probability of various tasks based on multi-dimensional features including vehicle speed, acceleration, and road curves, and then identifies tasks with trigger probabilities higher than a preset value as potential tasks for the current computing task. Specifically, in practical applications, the potential task prediction model trained in this embodiment can predict the trigger probability of 8 types of tasks within 1 second based on 12-dimensional input features.

[0048] After predicting the potential tasks for each computing task, this embodiment generates the computing power dependency of the current computing task using the following formula: The computational power dependency of the current computing task = 0.7 × the computational power requirement of the current computing task + 0.3 × the computational power requirement of the potential tasks of the current task.

[0049] Furthermore, the priority of any computational task needs to be dynamically generated by combining label information and the aforementioned computational power dependency, and the calculation formula is as follows: Priority = 0.4 × computing power dependence + 0.3 × latency sensitivity weight + 0.2 × security risk coefficient + 0.1 × weight corresponding to task source identifier.

[0050] In practical applications, the weight corresponding to the task source identifier of the lead vehicle task is 0.6; the weight corresponding to the task source identifier of the following vehicle task is 0.4. The safety risk coefficient is related to the task type. In this embodiment, the safety risk coefficient of control tasks is 0.8, the safety risk coefficient of decision-making tasks is 0.6, the safety risk coefficient of perception tasks is 0.5, and the safety risk coefficient of management tasks is 0.2.

[0051] Finally, the formula for calculating the basic capability score of each computing node is as follows: Basic capability score = 0.5 × health status + 0.3 × remaining computing power + 0.2 × communication latency score In this embodiment, the higher the communication latency of any computing power node, the lower the communication latency score. In practical applications, this embodiment selects computing power nodes with a basic capability score higher than 60 from the multi-source computing power pool to form candidate nodes. In practice, only candidate nodes participate in subsequent task allocation among the computing power nodes in the multi-source computing power pool.

[0052] IV. Many-to-many matching of tasks and computing power Priority, computing power requirement, latency threshold, and security level are used as task-side matching parameters; remaining computing power and communication cost are used as computing power-side matching parameters; constraints on task latency and computing power node load are preset; with the optimization objectives of minimizing the total execution cost of computing tasks and balancing the overall load of computing power nodes, an improved greedy algorithm is used to perform global many-to-many matching between computing tasks in the global task pool and candidate nodes in the multi-source computing power pool.

[0053] In practical applications, the preset constraints in this embodiment are that the latency of the core task is less than 50ms, the latency of other tasks is less than 200ms, and the load of each computing node is less than 85%. The global many-to-many matching process between computing tasks and candidate nodes includes the following steps: (1) Sort each computing task in the global task pool according to priority and use it as the object of each row. Sort each candidate node in the multi-source computing power pool according to basic capability score and use it as the object of each column. Then construct a matching matrix. The elements in the matching matrix are the execution costs of the corresponding computing tasks when they are executed on the candidate nodes.

[0054] The formula for calculating the execution cost of any computational task on any candidate node is as follows: Execution cost = 0.4 × computation cost + 0.4 × communication cost + 0.2 × migration cost In the above formula, the computation cost is the ratio of the computational power requirement of the computational task to the remaining computational power of the computational node; the communication cost is calculated based on the network distance and device bandwidth; and the migration cost is characterized by the communication cost between the two migration objects.

[0055] (2) Match the top 30% of computing tasks by priority to the candidate nodes that have the lowest execution cost in order of priority; (3) Distribute the remaining computing tasks to each candidate node according to the principle of minimizing the load rate, and each computing task is preferentially matched with candidate nodes with a load rate of less than 60%; (4) Migrate some computing tasks on candidate nodes with a load rate higher than 80% to candidate nodes with a load rate lower than 50% to optimize the overall load balance.

[0056] After completing the above matching, this embodiment can output a "task-computing node matching list". From the task side, this list information can clearly identify the main execution computing node for each computing task, several alternative computing nodes (different computing power sources) as safety redundancy, and the execution priority of each computing task. From the node side, this list information can clearly identify the task allocation list for each computing node.

[0057] Furthermore, in practical applications of this embodiment, to ensure the stability of many-to-many allocation, a full lifecycle monitoring and dynamic adjustment mechanism can be constructed to achieve communication link adaptation, real-time monitoring, and anomaly handling. Specifically, core tasks (such as lead vehicle control tasks) use a 5G-Uu interface to directly connect to the main execution node. Edge tasks (such as following vehicle log statistics) use a V2V / V2X+SD-WAN hybrid link, scheduling idle bandwidth; multi-node collaborative tasks use a time synchronization protocol (such as PTP) to ensure consistent task execution timing across multiple computing nodes. In anomaly monitoring, this embodiment collects the execution progress and latency of all tasks at a frequency of 20Hz, and the dynamic load status (CPU / GPU utilization, communication latency) of all computing nodes meets constraints.

[0058] When the execution latency of a computing task exceeds the threshold of 50%, the load of a computing node is greater than 90%, or the communication packet loss rate exceeds 10%, an abnormal alarm is triggered, and the matching matrix is ​​recalculated. The optimal node is selected from the candidate nodes for task migration, or the allocation ratio of multiple tasks is adjusted (such as migrating some tasks from high-load nodes to low-load nodes) to ensure dynamic optimization of many-to-many matching.

[0059] Example 2 The computational task allocation method for vehicle platooning in vehicle-road cooperative mode provided in Example 1 is essentially a data processing method. In order to better apply this scheme, this example further provides a computer program product, a storage medium, and a vehicle platooning control module based on the scheme in Example 1.

[0060] The computer program product provided in this embodiment includes a computer program. When the computer program is executed by the processor, it implements the computational task allocation method for vehicle-road cooperative vehicle platooning as in Embodiment 1, dynamically allocating each computational task generated by the vehicle platooning to each computing node.

[0061] The storage medium provided in this embodiment stores a computer program. When the computer program is executed by the processor, it implements the computational task allocation method for vehicle-road cooperative vehicle formation as in Embodiment 1, dynamically allocating each computational task generated by the vehicle formation to each computing node.

[0062] The vehicle platooning control module provided in this embodiment includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the computational task allocation method for vehicle-road cooperative vehicle platooning as described in Embodiment 1, dynamically allocating each computational task generated by the vehicle platooning to each computing node.

[0063] The vehicle platooning control module provided in this embodiment is essentially a computer device. In practical applications, this computer device can be embedded and deployed within the vehicle to support data processing and interaction. It can also be used as a standalone computer device to support data processing needs in certain scenarios. This non-embedded computer device can be a medium to large-sized computer device such as a laptop, tablet, desktop computer, or rack server, blade server, tower server, or cabinet server (including standalone servers or server clusters composed of multiple servers) capable of executing computer programs.

[0064] Specifically, the computer device in this embodiment includes, but is not limited to, a memory and a processor that can be interconnected via a system bus. In this embodiment, the memory (i.e., the readable storage medium) includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, etc. In some embodiments, the memory can be an internal storage unit of the computer device, such as the hard disk or RAM of the computer device. In other embodiments, the memory can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc. Of course, the memory can also include both internal storage units and external storage devices of the computer device. In this embodiment, the memory is typically used to store the operating system and various application software installed on the computer device. Furthermore, the memory can also be used to temporarily store various types of data that have been output or will be output.

[0065] In some embodiments, the processor may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor is typically used to control the overall operation of a computer device.

[0066] This embodiment also provides an intelligent vehicle, in which an embedded vehicle computational offloading and trajectory joint optimization module is deployed, so that the vehicle can communicate with the surrounding RSUs and BSs during operation, and then execute the steps of the DQN-based vehicle network computational offloading and trajectory joint optimization method as in Embodiment 1, thereby generating an optimal computational offloading and trajectory design strategy for relevant vehicles in a specified scenario.

[0067] To verify the effectiveness of the computational task allocation method for vehicle-road cooperative platooning provided by this invention, engineers developed an experimental plan and conducted simulation tests on the relevant schemes. The simulation experiment was based on a joint architecture of SUMO (Traffic Flow Simulation) and NS-3 (Network Communication Simulation), and implemented the task prediction and allocation algorithm using Python-TensorFlow. The simulation environment was set as a six-lane, two-way highway containing an autonomous driving platoon consisting of one lead vehicle (HV) and four follower vehicles (FV1-FV4), with edge computing nodes (MECs) deployed along the route at 500-meter intervals.

[0068] 1. Parameter configuration of heterogeneous computing power nodes During the multi-source computing power pool construction phase, nodes with different physical characteristics are standardized to TOPS equivalents. The lead vehicle has a computing capacity of 10 TOPS. As the core hub, 60% of its computing power is normally occupied by local control tasks. Each following vehicle has a computing capacity of 8 TOPS. When its CPU load is less than 30%, it reports redundant computing power via V2V. The roadside MEC has a computing capacity of 30 TOPS, covering a radius of 300 meters, and interacts with vehicles via 5G-V2X. The cloud server has a computing capacity greater than 100 TOPS. Although the computing power is large, there is an average end-to-end latency of 100ms.

[0069] 2. Numerical refinement and derivation of the core algorithm The system performs quantitative evaluation on tasks aggregated into the global task pool. Assume there are two typical tasks in the current task pool: Task A is a lead vehicle control task, and Task B is a follower vehicle perception task. Task A has a computational power dependency of 0.9 (high load requirement); latency sensitivity of 1.0 (5ms level, extremely sensitive); risk coefficient of 0.8 (control type); and task source weight of 0.6 (lead vehicle). Therefore, the priority is calculated as: 0.4(0.9) + 0.3(1.0) + 0.2(0.8) + 0.1(0.6) = 0.88. Task B has a computational power dependency of 0.6; latency sensitivity of 0.6 (20ms level); risk coefficient of 0.5 (perception type); and task source weight of 0.4 (follower vehicle). The priority is calculated as 0.4(0.6) + 0.3(0.6) + 0.2(0.5) + 0.1(0.4) = 0.56. Therefore, the system automatically marks task A as a core task and enters the first round of allocation iteration to ensure that it occupies the optimal computing path.

[0070] When dispatching tasks, the system constructs a "task-computing power" matching matrix and calculates the execution cost as follows: Node 1: Head Vehicle Local (HV) Redundancy: 2 TOPS; Latency: 0ms Cost = 0.5X×(4 / 2) + 0.4×0 = 1.0.

[0071] Node 2: Roadside MEC Redundancy: 20 TOPS; Latency: 12ms Cost = 0.5×(4 / 20) + 0.4×(12 / 10) = 0.1 + 0.48 = 0.58.

[0072] Node 3: Following the vehicle (FV2) Redundancy: 8 TOPS; Latency: 5ms Cost = 0.5×(4 / 8) + 0.4×(5 / 10) = 0.25 + 0.2 = 0.45.

[0073] Based on the above data analysis, it can be seen that although the roadside MEC has stronger computing power, due to the communication advantages of V2V, the system ultimately determines that the following vehicle FV2 is the optimal allocation node for task B.

[0074] 3. Demonstration of typical application scenarios Scenario 1: Global load balancing under extreme load Background: As the convoy entered a complex construction area, the obstacle data sensed by the lead vehicle surged, and the local CPU usage instantly reached 95%.

[0075] Execution logic: The dual-pool architecture detects that the health of the lead vehicle has dropped to 40, but the roadside MEC and following vehicles FV1 and FV2 are in a low-load state. Based on the above cost calculation, the system reserves 5% of the computing power of the lead vehicle to process "hard real-time" control commands, and dispatches 80% of the perception computing tasks in parallel to the roadside MEC and FV1.

[0076] Results: The load on the lead vehicle returned to the safe range (around 45%) within 200ms, the convoy traveled smoothly, and no control lag was observed.

[0077] Scenario 2: Adaptive Migration in Complex Network Environments Background: The task is being performed on the roadside MEC when a vehicle passes by at high speed, causing a momentary blockage in the 5G link with a packet loss rate of 15%.

[0078] Dynamic adjustment logic: The monitoring module detects that the health score of the roadside MEC has dropped to 55 (below the critical threshold of 60). The system immediately extracts the second alternative node (such as FV3) from the "matching list", encapsulates the task context, and performs state transition through a stable V2V link.

[0079] Result: The computation task was continued to be executed on the alternative node, and the overall task completion time only increased by 8ms.

[0080] 4. Simulation analysis comparing the advancement of different schemes This experiment compares the proposed solution (MPG: Multi-Pool Greedy Algorithm) with traditional single-vehicle independent processing solutions and traditional vehicle-cloud static allocation solutions, resulting in the following performance evaluation table: Table 1: Performance Comparison of the Invention and Existing Solutions The data shows that the present invention outperforms existing solutions in all aspects, demonstrating outstanding performance.

[0081] Furthermore, the many-to-many matching mechanism of this invention successfully distributes the computational burden of the lead vehicle across the entire platoon and roadside, reducing the load by 52%. Through the execution cost matrix, the system can accurately identify the optimal node, improving computing resource utilization by 3.5 times. The dynamic adjustment mechanism and alternative node strategy ensure that the system's robustness in complex network environments reaches over 99.9%.

[0082] The above-described embodiments are merely one implementation of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the inventive concept, and these all fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the appended claims.

Claims

1. A method for allocating computational tasks for vehicle platooning in vehicle-road cooperative systems, characterized in that, It includes: The calculation task of dynamically updating all vehicles in the vehicle platoon; They are categorized and labeled with information including computing power requirements, latency sensitivity, security risk coefficient, and task source identifier to form a global task pool; The system acquires resource status information reported by each computing power node, including the lead vehicle, following vehicles, road test MEC, and cloud server, and calculates the remaining computing power value; it evaluates the node health and communication latency through heartbeat detection and differential probe mechanism; and selects computing power nodes with node health values ​​higher than preset values ​​to form a multi-source computing power pool. Predict potential tasks for each computing task and generate the computing power dependency for each computing task; combine the computing power dependency and tag information to generate the priority of each computing task; perform basic capability scoring on each computing power node, and select computing power nodes with basic capability scores higher than preset values ​​to form candidate nodes; Priority, computing power requirement, latency threshold, and security level are used as task-side matching parameters; remaining computing power and communication cost are used as computing power-side matching parameters; constraints on task latency and computing power node load are preset; with the optimization objectives of minimizing the total execution cost of computing tasks and balancing the overall load of computing power nodes, an improved greedy algorithm is used to perform global many-to-many matching between computing tasks in the global task pool and candidate nodes in the multi-source computing power pool.

2. The computational task allocation method for vehicle platooning in vehicle-road cooperative systems according to claim 1, characterized in that: The core tasks of the lead vehicle include global path planning and formation control, while the peripheral tasks of the following vehicles include local obstacle detection assistance, log statistics, and formation status synchronization. Furthermore / or, computational tasks are divided into four categories: perception, decision-making, control, and management. Among them, perception-based computational tasks are further divided into obstacle detection and traffic sign recognition; decision-making-based computational tasks are divided into path planning and behavioral decision-making; control-based computational tasks are divided into trajectory tracking and vehicle control; and management-based computational tasks are divided into formation maintenance and resource coordination. And / or, the computing power requirements of each computing task include CPU utilization, GPU utilization and memory utilization, and the latency sensitivity information includes maximum tolerable latency and latency sensitivity weights; And / or, the global task pool adopts a 1-second sliding window to receive new tasks in real time, remove completed tasks, and synchronously update the computing power dependency and priority of tasks.

3. The computational task allocation method for vehicle platooning in vehicle-road cooperative systems according to claim 1, characterized in that, Methods for evaluating the performance of computing nodes through heartbeat detection and differential probe mechanisms include: For core computing nodes including lead vehicles and roadside MECs, a heartbeat packet is sent every 200ms and a virtual test packet is sent every 500ms. Multiple performance indicators, including response latency and packet loss rate, are evaluated, and a health assessment value is generated based on the results of each indicator. For edge computing nodes that include vehicle-following and cloud servers, a heartbeat packet is sent every 500ms, a stress test packet is sent randomly, and multiple performance indicators, including corresponding latency, load stability and communication reliability, are evaluated; and a health assessment value is generated based on the results of each indicator. And / or, the multi-source computing power pool uses an adaptive sliding window to filter out failed nodes with a health level less than a threshold in real time.

4. The computational task allocation method for vehicle platooning in vehicle-road cooperative systems according to claim 1, characterized in that: The computing power requirement of the computing task and the remaining computing power of the computing nodes are generated based on the index data through a multidimensional vector modeling algorithm and converted into a unified representation value. And / or, the potential tasks for each real-time computing task are generated by a potential task prediction model pre-trained based on an LSTM model; the potential task prediction model is used to generate the trigger probability of various tasks based on the multi-dimensional features of the input, including vehicle speed, acceleration and road curves, and then the tasks with trigger probabilities higher than a preset value are taken as the potential tasks of the current computing task. And / or, the formula for calculating the computational power dependency of the current computing task based on the predicted potential tasks of the current computing task is as follows: The computational power dependency of the current computing task = 0.7 × the computational power requirement of the current computing task + 0.3 × the computational power requirement of the potential tasks of the current task.

5. The computational task allocation method for vehicle-road cooperative vehicle platooning according to claim 4, characterized in that: The formula for calculating the priority of any computation task is as follows: Priority = 0.4 × computing power dependence + 0.3 × latency sensitivity weight + 0.2 × security risk coefficient + 0.1 × weight corresponding to task source identifier; In the above formula, among the weights corresponding to the task source identifier, the value of the lead vehicle task is 0.6; the value of the following vehicle task is 0.4; the safety risk coefficient is related to the task type, with the value of 0.8 for control type, 0.6 for decision type, 0.5 for perception type, and 0.2 for management type.

6. The computational task allocation method for vehicle platooning in vehicle-road cooperative systems according to claim 5, characterized in that: The formula for calculating the basic capability score of each computing node is as follows: Basic capability score = 0.5 × health status + 0.3 × remaining computing power + 0.2 × communication latency score Among them, the higher the communication latency of any computing node, the lower the communication latency score.

7. The computational task allocation method for vehicle platooning in vehicle-road cooperative systems according to claim 6, characterized in that: The global many-to-many matching process between the computation task and candidate nodes includes the following steps: (1) Sort each computing task in the global task pool according to priority and use it as the object of each row. Sort each candidate node in the multi-source computing power pool according to basic capability score and use it as the object of each column. Then construct a matching matrix. The elements in the matching matrix are the execution costs of the corresponding computing tasks when they are executed on the candidate nodes. (2) Match the top 30% of computing tasks by priority to the candidate nodes that have the lowest execution cost in order of priority; (3) Distribute the remaining computing tasks to each candidate node according to the principle of minimizing the load rate, and prioritize matching each computing task with candidate nodes with a load rate of less than 60%; (4) Migrate some computing tasks on candidate nodes with a load rate higher than 80% to candidate nodes with a load rate lower than 50% to optimize the overall load balance.

8. The computational task allocation method for vehicle-road cooperative vehicle platooning according to claim 7, characterized in that... ； Under the preset constraints, the latency of core tasks is less than 50ms, the latency of other tasks is less than 200ms, and the load of each computing node is less than 85%. And / or, the formula for calculating the execution cost of any computational task on any candidate node is as follows: Execution cost = 0.4 × computation cost + 0.4 × communication cost + 0.2 × migration cost In the above formula, the computation cost is the ratio of the computational power requirement of the computational task to the remaining computational power of the computational node; the communication cost is calculated based on the network distance and device bandwidth; and the migration cost is characterized by the communication cost between the two migration objects.

9. A computer program product comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the computational task allocation method for vehicle-road cooperative vehicle platooning as described in any one of claims 1-8, dynamically allocating each computational task generated by the vehicle platooning to each computing node.

10. A vehicle platooning control module, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, it implements the computational task allocation method for vehicle-road cooperative vehicle platooning as described in any one of claims 1-8, and dynamically allocates each computational task generated by the vehicle platooning to each computing node.

Images