Method and apparatus for allocating roadside computing power

Abstract

This application provides a method and apparatus for allocating roadside computing power. The method involves obtaining multiple task parameters for at least one task to be allocated, and obtaining load parameters and dynamic weights of multiple roadside computing nodes. Based on the multiple task parameters and load parameters, at least one candidate node corresponding to at least one task to be allocated is selected from the multiple roadside computing nodes. Based on the load parameters and corresponding dynamic weights, the fit between at least one task to be allocated and at least one candidate node is calculated to determine the final allocation scheme for at least one task to be allocated based on the fit. This application can accurately match the computing power requirements of roadside tasks with the node load status by constructing a multi-dimensional evaluation index system, adopting a hierarchical decision-making and dynamic weight allocation mechanism, and combining a global load balancing objective, thereby generating an optimal computing power allocation scheme with dynamic adjustment capabilities, achieving precise matching between task requirements and node load.

Description

Technical Field

[0001] This application relates to the field of intelligent transportation technology, and in particular to a method and apparatus for allocating roadside computing power. Background Technology

[0002] With the rapid development of intelligent transportation technology, the demand for roadside computing power in application scenarios such as autonomous driving and vehicle-to-infrastructure (V2I) communication is experiencing explosive growth. As the core support for V2I communication, roadside computing systems need to process massive amounts of data uploaded by vehicle terminals and collected data from roadside sensors (cameras, radar, lidar, etc.) in real time, and complete key processes such as task calculation and result feedback.

[0003] In related technologies, roadside computing networks often adopt a three-level allocation architecture of "roadside edge nodes - regional edge nodes - cloud nodes". Roadside edge nodes directly connect to terminal devices and undertake lightweight computing tasks with high real-time requirements. Regional edge nodes undertake medium-complexity collaborative computing tasks. Cloud nodes undertake large-scale data storage and complex model training tasks.

[0004] However, the allocation of roadside computing power in related technologies often uses fixed load thresholds as the basis for allocation, lacking adaptability to the dynamics of roadside tasks and the fluctuations in node load. On the one hand, roadside tasks are characterized by strong real-time, dynamic, and heterogeneous features. Tidal changes in traffic flow and sudden traffic events can cause the amount of roadside tasks to fluctuate dramatically in time and space. When traffic flow suddenly increases, a large number of tasks appear in a concentrated manner. Fixed thresholds can cause most nodes to quickly reach their load limits, and excessively long task cache queues can lead to severe delays or even task dropouts. On the other hand, different types of roadside tasks have significantly different requirements for computing power resources. When traffic flow is sparse, the node load is far below the threshold. If computing power is not allocated properly, some roadside nodes may become overloaded, leading to task delays, lag, or even failures. The waste of resources due to idle computing power on some roadside nodes seriously affects the stability and reliability of intelligent transportation systems and urgently needs to be addressed. Summary of the Invention

[0005] This application provides a method and apparatus for allocating roadside computing power, aiming to improve the problems that roadside computing power allocation methods in related technologies often adopt fixed thresholds or local optimum greedy strategies, which cannot adapt to the dynamic and heterogeneous nature of roadside tasks and the fluctuating characteristics of computing power node loads. This results in uneven overall roadside computing power load, low resource utilization, high-priority tasks being prone to delays in execution, and the inability to guarantee the stability and real-time performance of intelligent transportation system task execution.

[0006] The first aspect of this application provides a method for allocating roadside computing power, comprising the following steps: obtaining multiple task parameters of at least one task to be allocated, and obtaining multiple load parameters and their dynamic weights corresponding to multiple roadside computing power nodes; based on the multiple task parameters and the multiple load parameters, filtering at least one candidate node corresponding to the at least one task to be allocated from the multiple roadside computing power nodes; and based on the multiple load parameters and their corresponding dynamic weights, calculating the fit between the at least one task to be allocated and the at least one candidate node, so as to determine the final allocation scheme of the at least one task to be allocated according to the fit.

[0007] Through the above technical means, the embodiments of this application can establish a complete allocation closed loop from global parameter acquisition and intelligent preliminary screening to accurate adaptation evaluation, and dynamically and multidimensionally match task requirements with the status of roadside computing nodes. This effectively overcomes the blindness of static or random allocation, significantly reduces the average load rate of roadside computing nodes, improves the utilization rate of computing resources, solves the problems of poor adaptability and poor load balancing effect of roadside computing allocation strategies, and ensures the stability and real-time performance of intelligent transportation system task execution.

[0008] Optionally, in one embodiment of this application, the step of obtaining multiple task parameters of at least one task to be assigned and obtaining multiple load parameters and their dynamic weights corresponding to multiple roadside computing nodes includes: obtaining the task type, task computing power requirement, current priority, task deadline, and data transmission volume of the at least one task to be assigned, so as to determine the multiple task parameters based on the task type, task computing power requirement, current priority, task deadline, and data transmission volume; and obtaining the CPU utilization, memory utilization, computing power redundancy, communication latency, and energy consumption of the multiple roadside computing nodes, so as to determine the multiple load parameters based on the CPU utilization, memory utilization, computing power redundancy, communication latency, and energy consumption.

[0009] Through the above technical means, the embodiments of this application can define five major task parameters (task type, computing power requirement, priority, deadline, and data volume) and five major node load parameters (CPU / memory utilization, computing power redundancy, latency, and energy consumption) to provide a comprehensive, specific, and quantifiable data foundation for subsequent screening and adaptation calculation, ensuring the accuracy of the adaptation between the task to be assigned and the roadside computing power node to be finally assigned.

[0010] Optionally, in one embodiment of this application, the step of filtering at least one candidate node corresponding to the at least one task to be assigned from the plurality of roadside computing power nodes based on the plurality of task parameters and the plurality of load parameters includes: matching the filtering conditions corresponding to the at least one task to be assigned according to the current priority of the at least one task to be assigned; and filtering the at least one candidate node according to the filtering conditions and the plurality of load parameters.

[0011] Through the above technical means, the embodiments of this application can achieve "hierarchical decision-making" and "resource guarantee" by setting hardware thresholds (such as CPU utilization and communication latency limits) with decreasing strictness for tasks of different priorities (high, medium and low). This ensures that high-urgent tasks (such as obstacle recognition) can always obtain high-quality node resources with sufficient performance and low latency, thereby reliably meeting the most critical real-time requirements in vehicle-road cooperative scenarios.

[0012] Optionally, in one embodiment of this application, the method further includes: identifying whether there is an associated task set among the at least one task to be assigned; if so, obtaining the data transmission dependency relationship and timing constraint relationship between each subtask in the associated task set; and determining at least one candidate node corresponding to the at least one task to be assigned based on the data transmission dependency relationship, timing constraint relationship, and the communication latency and computing power redundancy of the at least one candidate node.

[0013] Through the above technical means, the embodiments of this application can identify and optimize the processing of a set of related tasks with internal dependencies. By coordinating the allocation of related subtasks to node groups with low communication latency and matching computing power, the data communication overhead between tasks is minimized, ensuring the overall execution efficiency and completion time of complex tasks, and achieving an improvement from single-task optimization to global task chain optimization.

[0014] Optionally, in one embodiment of this application, obtaining multiple load parameters and their dynamic weights corresponding to multiple roadside computing nodes includes: determining the subjective weights of the multiple load parameters based on typical scores of the multiple load parameters, and determining the objective weights of the multiple load parameters based on the information entropy of the multiple load parameters; determining the weight coefficients corresponding to the subjective weights and the objective weights respectively, taking into account the current traffic environment of the multiple roadside computing nodes; and determining the dynamic weights of the multiple load parameters by combining the subjective weights and their weight coefficients with the objective weights and their weight coefficients.

[0015] Through the above technical means, the embodiments of this application can integrate experience-based judgment scoring (such as high-priority tasks placing more emphasis on delay) and objective differences in real-time node data (reflected by information entropy), and combine them with the dynamic adjustment coefficient of the traffic environment, so that the final weight allocation value used for evaluation has both goal orientation, objectivity and fairness and scenario adaptability, effectively ensuring the scientific and reasonableness of the fit evaluation results.

[0016] Optionally, in one embodiment of this application, after determining the final allocation scheme for the at least one task to be allocated based on the fit evaluation result, the method further includes: obtaining the final computing power node corresponding to the final allocation scheme; based on the status information and load change data of the final computing power node during the execution of the at least one task to be allocated; and adjusting the final allocation scheme according to the status information and the load change data to meet the target requirements.

[0017] Through the above technical means, the embodiments of this application can monitor the actual delay and node load fluctuation during task execution, and perform task migration or resource assistance when a threshold is triggered (such as node overload or task execution timeout risk). This can effectively deal with the deviation between the actual situation and the prediction, ensure that the initial allocation scheme remains effective in a dynamically changing environment, and guarantee the long-term stability and robustness of the system.

[0018] A second aspect of this application provides a roadside computing power allocation device, comprising: a first acquisition module, configured to acquire multiple task parameters of at least one task to be allocated, and acquire multiple load parameters and their dynamic weights corresponding to multiple roadside computing power nodes; a filtering module, configured to filter at least one candidate node corresponding to the at least one task to be allocated from the multiple roadside computing power nodes based on the multiple task parameters and the multiple load parameters; and an allocation module, configured to calculate the fit between the at least one task to be allocated and the at least one candidate node based on the multiple load parameters and their corresponding dynamic weights, so as to determine the final allocation scheme of the at least one task to be allocated according to the fit.

[0019] Through the above technical means, the embodiments of this application can establish a complete allocation closed loop from global parameter acquisition and intelligent preliminary screening to accurate adaptation evaluation, and dynamically and multidimensionally match task requirements with the status of roadside computing nodes. This effectively overcomes the blindness of static or random allocation, significantly reduces the average load rate of roadside computing nodes, improves the utilization rate of computing resources, solves the problems of poor adaptability and poor load balancing effect of roadside computing allocation strategies, and ensures the stability and real-time performance of intelligent transportation system task execution.

[0020] Optionally, in one embodiment of this application, the first acquisition module includes: a first acquisition unit, configured to acquire the task type, task computing power requirement, current priority, task deadline, and data transmission volume of the at least one task to be assigned, so as to determine the plurality of task parameters based on the task type, task computing power requirement, current priority, task deadline, and data transmission volume; and a second acquisition unit, configured to acquire the CPU utilization, memory utilization, computing power redundancy, communication latency, and energy consumption of the plurality of roadside computing power nodes, so as to determine the plurality of load parameters based on the CPU utilization, memory utilization, computing power redundancy, communication latency, and energy consumption.

[0021] Through the above technical means, the embodiments of this application can define five major task parameters (task type, computing power requirement, priority, deadline, and data volume) and five major node load parameters (CPU / memory utilization, computing power redundancy, latency, and energy consumption) to provide a comprehensive, specific, and quantifiable data foundation for subsequent screening and adaptation calculation, ensuring the accuracy of the adaptation between the task to be assigned and the roadside computing power node to be finally assigned.

[0022] Optionally, in one embodiment of this application, the filtering module includes: a matching unit, configured to match the filtering conditions corresponding to the at least one task to be assigned according to the current priority of the at least one task to be assigned; and a filtering unit, configured to filter the at least one candidate node according to the filtering conditions and the plurality of load parameters.

[0023] Through the above technical means, the embodiments of this application can achieve "hierarchical decision-making" and "resource guarantee" by setting hardware thresholds (such as CPU utilization and communication latency limits) with decreasing strictness for tasks of different priorities (high, medium and low). This ensures that high-urgent tasks (such as obstacle recognition) can always obtain high-quality node resources with sufficient performance and low latency, thereby reliably meeting the most critical real-time requirements in vehicle-road cooperative scenarios.

[0024] Optionally, in one embodiment of this application, it further includes: an identification module, configured to identify whether there is an associated task set among the at least one task to be assigned; a second acquisition module, configured to acquire, when the associated task set exists among the at least one task to be assigned, the data transmission dependency relationship and timing constraint relationship between each subtask in the associated task set; and a determination module, configured to determine at least one candidate node corresponding to the at least one task to be assigned based on the data transmission dependency relationship, the timing constraint relationship, and the communication latency and computing power redundancy of the at least one candidate node.

[0025] Through the above technical means, the embodiments of this application can identify and optimize the processing of a set of related tasks with internal dependencies. By coordinating the allocation of related subtasks to node groups with low communication latency and matching computing power, the data communication overhead between tasks is minimized, ensuring the overall execution efficiency and completion time of complex tasks, and achieving an improvement from single-task optimization to global task chain optimization.

[0026] Optionally, in one embodiment of this application, the first acquisition module includes: an identification unit, configured to determine the subjective weights of the plurality of load parameters based on typical scores of the plurality of load parameters, and to determine the objective weights of the plurality of load parameters based on the information entropy of the plurality of load parameters; and a determination unit, configured to determine the weight coefficients corresponding to the subjective weights and the objective weights respectively, in conjunction with the current traffic environment of the plurality of roadside computing nodes; and to determine the dynamic weights of the plurality of load parameters by combining the subjective weights and their weight coefficients with the objective weights and their weight coefficients.

[0027] Through the above technical means, the embodiments of this application can integrate experience-based judgment scoring (such as high-priority tasks placing more emphasis on delay) and objective differences in real-time node data (reflected by information entropy), and combine them with the dynamic adjustment coefficient of the traffic environment, so that the final weight allocation value used for evaluation has both goal orientation, objectivity and fairness and scenario adaptability, effectively ensuring the scientific and reasonableness of the fit evaluation results.

[0028] Optionally, in one embodiment of this application, it further includes: a third acquisition module, configured to acquire the final computing power node corresponding to the final allocation scheme after determining the final allocation scheme of the at least one task to be allocated based on the adaptability evaluation result; a fourth acquisition module, configured to acquire the status information and load change data of the final computing power node during the execution of the at least one task to be allocated; and an adjustment module, configured to adjust the final allocation scheme according to the status information and the load change data to meet the target requirements.

[0029] Through the above technical means, the embodiments of this application can monitor the actual delay and node load fluctuation during task execution, and perform task migration or resource assistance when a threshold is triggered (such as node overload or task execution timeout risk). This can effectively deal with the deviation between the actual situation and the prediction, ensure that the initial allocation scheme remains effective in a dynamically changing environment, and guarantee the long-term stability and robustness of the system. Attached Figure Description

[0030] Figure 1 This is a flowchart of a roadside computing power allocation method provided in an embodiment of this application;

[0031] Figure 2This is a flowchart of the computing power allocation on the service roadside according to one embodiment of this application; Figure 3 This is a structural diagram of the roadside computing power distribution device provided in the embodiments of this application; Figure 4 This is a structural diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0032] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0033] This application provides a method for allocating roadside computing power, comprising: obtaining multiple task parameters of at least one task to be allocated, and obtaining multiple load parameters and their dynamic weights corresponding to multiple roadside computing power nodes; based on the multiple task parameters and multiple load parameters, filtering at least one candidate node corresponding to at least one task to be allocated from the multiple roadside computing power nodes; and calculating the fit between at least one task to be allocated and at least one candidate node based on the multiple load parameters and their corresponding dynamic weights, so as to determine the final allocation scheme of at least one task to be allocated according to the fit.

[0034] This application embodiment can construct a multi-dimensional evaluation index system, adopt a hierarchical decision-making and dynamic weight allocation mechanism, and combine the global load balancing target to accurately match the computing power requirements of roadside tasks with the node load status, generate the optimal computing power allocation scheme, and have dynamic adjustment capabilities, so as to achieve accurate matching between task requirements and node load, fundamentally reduce the average load rate of roadside computing power nodes, improve global load balancing, improve the utilization rate of roadside computing power resources, reduce resource waste, ensure the real-time performance of high-priority tasks, improve the safety of intelligent transportation systems, enhance policy adaptability, adapt to complex dynamic roadside scenarios, and reduce the energy consumption of roadside computing power systems.

[0035] Example 1 This application provides a method for allocating roadside computing power. Please refer to the following embodiments. Figure 1 This includes the following steps: S110: Obtain multiple task parameters of at least one task to be assigned, and obtain multiple load parameters and their dynamic weights corresponding to multiple roadside computing nodes. S120: Based on multiple task parameters and multiple load parameters, select at least one candidate node corresponding to at least one task to be assigned from multiple roadside computing power nodes; S130: Based on multiple load parameters and their corresponding dynamic weights, calculate the fit between at least one task to be assigned and at least one candidate node, so as to determine the final allocation scheme of at least one task to be assigned according to the fit.

[0036] It is understandable that the tasks to be assigned here refer to the computing and data processing tasks that need to be undertaken and executed by roadside edge nodes (such as roadside units (RSUs) and edge computing servers), such as computing and data processing tasks related to traffic perception, collaborative decision-making, and service support in the road.

[0037] In some embodiments, the roadside edge node may have one or more tasks to be assigned and executed. In order to assign the most suitable roadside edge node to at least one (one or more) task to be assigned on the roadside, this application can make the assignment based on the actual situation of the task to be assigned and the roadside edge computing nodes.

[0038] For example, this application may, but is not limited to, obtain multiple task parameters of at least one roadside task to be assigned, multiple load parameters corresponding to multiple roadside computing power nodes, and dynamic weights corresponding to multiple load parameters, to provide data support for the allocation of each task to be assigned and its best roadside edge computing power node.

[0039] Furthermore, after obtaining the task parameters of at least one task to be assigned and the load parameters and dynamic weights of each roadside edge computing node, the embodiments of this application can first preliminarily screen at least one candidate node corresponding to at least one task to be assigned based on the task parameters of at least one task to be assigned and the load parameters of each roadside edge computing node, that is, screen out one or more candidate nodes that can meet the current various task requirements of each task to be assigned.

[0040] Similarly, given that there may be one or more candidate nodes selected, the embodiments of this application can then calculate the fit between at least one task to be assigned and at least one candidate node based on the dynamic weights corresponding to the multiple load parameters of the multiple roadside edge computing nodes (including the load parameters of the candidate nodes and their corresponding dynamic weights), thereby determining the roadside computing node to which at least one task to be assigned should be finally assigned based on the candidate node with the highest fit.

[0041] In other words, this application embodiment can calculate the fit between each task to be assigned and its corresponding one or more candidate nodes, and finally select the candidate node with the highest fit as the roadside edge computing node to be assigned for that task.

[0042] This application's embodiments can effectively ensure that computing resources are prioritized for high-priority, high-demand tasks by accurately matching task characteristics with node load and combining priority-based candidate node screening, while fully utilizing the idle computing power of each node. Actual test data shows that the roadside computing power allocation method in this application's embodiments achieves a computing resource utilization rate of 82%-88%, which is 12-23 percentage points higher than methods based on static thresholds (65%-70%) and methods based on greedy algorithms (70%-75%), and 7-18 percentage points higher, respectively, significantly reducing the waste of idle computing resources.

[0043] Step S110 includes obtaining the task type, task computing power requirement, current priority, task deadline, and data transmission volume of at least one task to be assigned, so as to determine multiple task parameters based on the task type, task computing power requirement, current priority, task deadline, and data transmission volume; and obtaining the CPU utilization, memory utilization, computing power redundancy, communication latency, and energy consumption of multiple roadside computing nodes, so as to determine multiple load parameters based on the CPU utilization, memory utilization, computing power redundancy, communication latency, and energy consumption.

[0044] In some embodiments, the multiple task parameters obtained by this application for each task to be assigned include, but are not limited to, the task type of each task to be assigned, the priority of the task to be assigned at the current time, the task deadline, and the amount of data transmitted.

[0045] Furthermore, the multiple load parameters of each roadside computing node obtained in the embodiments of this application include, but are not limited to, the CPU utilization, memory utilization, network bandwidth utilization, computing power redundancy, communication latency, and energy consumption of each roadside computing node.

[0046] The task types to be assigned here can be understood as the core functional classifications of roadside tasks. Common types include multi-source perception data processing, vehicle-road cooperative decision-making, edge service support, traffic incident early warning, and equipment operation and maintenance management. More detailed classifications include obstacle recognition, traffic flow statistics, and vehicle-road communication data forwarding. The task type often determines the core requirements of the task, such as computing power, latency, and bandwidth, directly affecting the task's execution logic. Different task types have significantly different resource requirements; for example, LiDAR point cloud processing is a high-computing-power-requirement type, while device log uploading is a low-computing-power-requirement type.

[0047] The priority at the current moment refers to the execution priority level of each task to be assigned in the current time's scheduling queue (a queue consisting of all tasks to be assigned at the current moment), which is generally determined by the urgency, importance, and business value of the task. In the embodiments of this application, the priority can be divided into three levels according to importance: high (P1), medium (P2), and low (P3): P1 is the highest priority, such as obstacle recognition and emergency braking warning tasks, which need to be executed immediately; P2 is the medium priority, such as traffic flow statistics and traffic signal optimization tasks, which need to be completed within a short time delay; P3 is the general priority, such as data backup and historical data statistics tasks, which have low execution time requirements.

[0048] The task deadline here refers to the latest time threshold from receiving the assigned task to its completion. If the task is completed after the deadline, the output may lose its meaning / effectiveness. For example, the deadline for V2X warning messages is usually required to be <100ms; if this time is exceeded, vehicles will not be able to take timely evasive action. The deadline for daily traffic flow reports, however, can be extended to the early morning of the following day.

[0049] The data transmission volume here refers to the total scale of input / output data during the execution of the assigned task, which generally determines the task's network bandwidth requirements for roadside computing nodes. For example, the input data transmission volume of a high-definition camera video stream processing task can reach tens of MB / s; the output data transmission volume of a sensor status message reporting task is only a few KB / time. The larger the data transmission volume, the higher the requirement for the network bandwidth utilization of roadside computing nodes.

[0050] The CPU utilization rate here refers to the real-time occupancy rate of the CPU in the roadside computing node, reflecting the node's computing power load. The calculation formula is (CPU used computing power / total CPU computing power) × 100%. The higher the CPU utilization rate, the more tasks the node is currently running and the less computing power is available. If the utilization rate is too high, such as exceeding 80%, the execution latency of new tasks will increase significantly, and may even cause task lag.

[0051] Memory utilization here refers to the real-time percentage of memory occupied by roadside computing nodes. The calculation formula is generally (used memory / total memory) × 100%, which reflects the level of memory resource scarcity of the nodes. During task execution, memory is required to store intermediate data. If memory utilization is too high, it will trigger the memory swapping mechanism, resulting in a significant decrease in task execution efficiency, especially for large-volume data processing tasks such as LiDAR point clouds.

[0052] The computing power redundancy here refers to the remaining available computing power of the roadside computing power node, that is, the difference between the node's maximum computing power and the currently occupied computing power. It is a core indicator of the roadside computing power node's ability to undertake new tasks. The larger the computing power redundancy, the more high-computing-power tasks (such as multi-sensor data fusion) the node can undertake; conversely, it can only undertake low-computing-power tasks (such as status message statistics).

[0053] Communication latency here refers to the round-trip time of data transmission between the roadside computing nodes and the task initiating terminal, and is a key indicator for measuring the real-time performance of nodes. This parameter is crucial for vehicle-road cooperative decision-making tasks. For example, hazard warning tasks require nodes with a communication latency of <100ms to ensure that warning commands are issued to vehicles in a timely manner.

[0054] Energy consumption here refers to the current operating energy consumption of roadside computing nodes. It is generally based on the total energy consumption of roadside computing nodes per unit time, which can reflect the operating cost and energy sustainability of the nodes.

[0055] Furthermore, after obtaining multiple task parameters for each task to be assigned and load parameters for each roadside computing node, this embodiment of the application can further standardize these parameters. For example, this application may, but is not limited to, use a min-max normalization method to convert parameters of different dimensions to the [0, 1] interval, ensuring uniformity of parameter dimensions and facilitating subsequent evaluation calculations. The standardization formula is: x'=(x-x_min) / (x_max-x_min), Where x is the original parameter value, x_min is the minimum value of the parameter, and x_max is the maximum value of the parameter.

[0056] This application embodiment can define five major task parameters—task type, computing power requirement, priority, deadline, and data volume—and five major node load parameters—CPU / memory utilization, computing power redundancy, latency, and energy consumption—to provide a comprehensive, specific, and quantifiable data foundation for subsequent screening and adaptation calculations, ensuring the accuracy of the matching between the tasks to be assigned and the roadside computing power nodes to be assigned.

[0057] Step S120 includes matching at least one filtering condition corresponding to at least one task to be assigned based on the current priority of at least one task to be assigned; and filtering at least one candidate node based on the filtering condition and multiple load parameters.

[0058] Based on the descriptions of other embodiments, it is understood that this application preliminarily selects at least one candidate node corresponding to at least one task to be assigned based on the task parameters of at least one task to be assigned and the load parameters of each roadside edge computing node, that is, selects one or more candidate nodes that can meet the current various task requirements of each task to be assigned.

[0059] In the screening process, this application embodiment can first match the screening conditions corresponding to each task to be assigned according to the priority of each task at the current time, and then combine the screening conditions corresponding to each task to be assigned with the load parameters of each roadside computing node to screen out at least one candidate node.

[0060] For example, this application can first determine the real-time priority P of each task to be assigned at the current moment, and set candidate node filtering conditions corresponding to different priorities. In practical applications, the corresponding filtering conditions are matched based on the priority of each task to be assigned at the current moment. These filtering conditions correspond to various load parameters of the roadside computing nodes, so as to select a set of candidate nodes that meet the conditions from all roadside computing nodes, achieving preliminary hierarchical decision-making and ensuring the real-time performance of high-priority tasks. Specific filtering conditions can be, but are not limited to, expressed as follows: (1) If the task priority is P1 (highest priority), then the corresponding matching filtering conditions are: CPU utilization C ≤ 50%; Memory utilization M ≤ 45%; Communication delay L ≤ 10ms; The computing power redundancy R is greater than or equal to 1.2 times the computing power requirement S of the task (1.2 times redundancy is reserved to ensure stable execution of the task).

[0061] (2) If the task priority is P2 (medium priority), then the corresponding matching filtering criteria are: CPU utilization C ≤ 65%; Memory utilization M ≤ 60%; Communication delay L ≤ 20ms; The computing power redundancy R is greater than or equal to 1.0 times the task computing power requirement S (to meet the basic computing power requirement).

[0062] (3) If the task priority is P3 (general priority), then the corresponding matching filtering conditions are: CPU utilization C ≤ 80%; Memory utilization M ≤ 75%; Communication delay L ≤ 50ms; The computing power redundancy R is greater than or equal to 0.9 times the computing power requirement S of the task (a small amount of redundancy is allowed, which can be supplemented by subsequent task scheduling).

[0063] Therefore, in practical applications, after obtaining the priority of each task to be assigned at the current time, the embodiments of this application can first match the corresponding filtering conditions according to the priority of each task to be assigned at the current time, and then detect whether the load parameters of multiple roadside computing nodes meet these filtering conditions, so as to filter at least one candidate node (one or more candidate nodes) that meet the conditions from multiple roadside computing nodes.

[0064] It should be noted that if the candidate node set corresponding to a certain task to be assigned is empty, the embodiments of this application can first temporarily store the task to be assigned in the cache queue and send a computing power request to the upper-level regional edge node so that the upper-level node can supplement the allocation of computing power resources.

[0065] This application embodiment can set differentiated candidate node screening conditions for different priority tasks through a hierarchical decision-making mechanism. High-priority tasks (such as obstacle recognition and emergency braking warning) can be preferentially assigned to nodes with low communication latency and sufficient load. At the same time, the dynamic adjustment strategy can respond to node load fluctuations in a timely manner and avoid delays in the execution of high-priority tasks. It can achieve an average execution latency of ≤8ms for P1 level tasks and improve the latency compliance rate (execution latency ≤ deadline) from 85% in related technologies to over 98%, effectively ensuring the safety and reliability of intelligent transportation systems.

[0066] Identify whether there is an associated task set in at least one task to be assigned; if so, obtain the data transmission dependency and timing constraint relationship between each subtask in the associated task set; based on the data transmission dependency, timing constraint relationship and the communication delay and computing power redundancy of at least one candidate node, determine at least one candidate node corresponding to at least one task to be assigned.

[0067] Those skilled in the art will understand that, in real-world scenarios, a roadside task to be assigned may be an indivisible "atomic task." That is, when the system allocates and schedules resources, the task to be assigned is regarded as an indivisible, independently managed minimum task unit. It is a logical black box, and the system only cares about its input, output, and overall resource requirements, without caring about its internal structure. Therefore, it can be allocated and evaluated as a whole.

[0068] Meanwhile, the tasks to be assigned encountered on the roadside can also be "composite tasks" composed of multiple "subtasks". When a task to be assigned is a "composite task", it may consist of one or more logically related "subtasks". In this case, the "subtask" is an internal component that constitutes the task to be assigned. For example, a task to be assigned called "real-time decision-making for autonomous driving" may contain multiple subtasks such as "perception data fusion", "obstacle trajectory prediction", and "local path planning". When assigning tasks, it is necessary to identify and handle the relationships between these subtasks.

[0069] Based on this, as a possible implementation, embodiments of this application can also obtain whether there is a set of related tasks with dependencies in at least one task to be assigned. In the case that there is a set of related tasks with dependencies in a certain task to be assigned, the data transmission relationship (referring to the order in which data must be exchanged between subtasks) and the timing constraint relationship (referring to the execution order and time limit requirements between subtasks) between each subtask in the set of related tasks can be obtained. In order to determine at least one candidate node corresponding to the set of related tasks based on its data transmission dependency relationship, timing constraint relationship and the communication delay and computing power redundancy of at least one candidate node.

[0070] In this context, a set of related tasks can be understood as a group of logically interconnected independent task units that are subject to constraints on data transfer or execution order. For example, a complete "vehicle environment perception and path planning" task can be broken down into three sub-tasks: "sensor data fusion," "target recognition and tracking," and "local path planning." These three sub-tasks constitute a set of related tasks.

[0071] The associated task set is a subset identified from composite tasks to be assigned. That is, a task to be assigned is a composite task that contains multiple subtasks, and the associated task set contains one or more of these subtasks. Furthermore, there are data transmission dependencies or timing constraints or other dependencies between the tasks (i.e., subtasks) in this subset of the associated task set.

[0072] The set of related tasks can be either an internal expansion of a single, complex task to be assigned: for example, a "real-time update of high-precision maps" task is decomposed into multiple subtasks, which automatically form a set of related tasks. Alternatively, it can be an external association of multiple atomic tasks to be assigned: for example, a "traffic flow statistics" task and a "traffic light timing optimization" task, the latter requiring the former's result as input. Once the system identifies this cross-task dependency, it temporarily combines these two independent tasks into a set of related tasks for processing.

[0073] Therefore, when a set of related tasks with dependencies is identified in a task to be assigned, the embodiments of this application can obtain the data transmission relationship and timing constraint relationship between each subtask in the set of related tasks. Then, based on the data transmission dependency relationship, timing constraint relationship, and the communication latency and computing power redundancy of at least one candidate node, the related task set is screened for collaborative allocation nodes. This allows at least one task to be assigned corresponding to the set of related tasks to be assigned to one or more candidate nodes that meet the collaborative computing conditions, so as to minimize the communication overhead between tasks and meet the overall task deadline.

[0074] The embodiments of this application can identify and optimize the processing of a set of related tasks with internal dependencies. By coordinating the allocation of related subtasks to node groups with low communication latency and matching computing power, the data communication overhead between tasks is minimized, ensuring the overall execution efficiency and completion time of complex tasks, and achieving an improvement from single-task optimization to global task chain optimization.

[0075] Step S110 includes determining the subjective weight of the load parameters based on typical scores of multiple load parameters, and determining the objective weight of the load parameters based on the information entropy of the load parameters; determining the weight coefficients corresponding to the subjective weight and objective weight respectively by combining the current traffic environment of multiple roadside computing nodes; and determining the dynamic weight of the load parameters by combining the subjective weight and its weight coefficient as well as the objective weight and its weight coefficient.

[0076] Based on the descriptions of other embodiments, it is understood that when obtaining the dynamic weights of the load parameters of roadside computing nodes, this application can first determine the subjective weights corresponding to multiple load parameters based on the typical scores corresponding to multiple load parameters, and then determine the objective weights corresponding to multiple load parameters based on the information entropy corresponding to multiple load parameters. That is, the subjective weight of each load parameter is determined based on the typical score of each load parameter, and the objective weight of each load parameter is determined based on the information entropy of each load parameter.

[0077] Here, the typical score can be understood as the score given by professionals in this technical field based on their experience regarding the importance of load parameters. For example, in high-priority tasks, professionals in this technical field will give higher scores to communication latency and relatively lower scores to energy consumption, thereby reflecting the differences in the subjective importance of the indicators.

[0078] Subjective weight here refers to the weight of load parameters calculated based on typical scores from professionals in this technical field. It reflects the importance ranking of indicators at the level of human experience. For example, in high-priority tasks of vehicle-road cooperation, the subjective weight of communication delay is higher than that of energy consumption, in order to reflect the subjective goal of ensuring the real-time performance of the task.

[0079] Information entropy can be understood here as an indicator calculated using the entropy weighting method to measure the distinguishing ability of load parameter data. The magnitude of information entropy is negatively correlated with the distinguishing ability of the indicator: the smaller the entropy value, the greater the numerical difference of the load parameter among different nodes, and the more effectively it can distinguish the quality of nodes; conversely, the distinguishing ability is weak.

[0080] Objective weight here refers to the weight calculated based on the information entropy of load parameters. It is determined by the actual data distribution of load parameters of each roadside computing node, without incorporating human experience, and reflects the distinguishing value of the indicator at an objective level. For example, if the energy consumption values ​​of all nodes in a certain road segment are almost identical, its information entropy is high, and its objective weight is low.

[0081] Furthermore, based on the traffic environment of the roadside computing nodes, this embodiment can determine the weight coefficients corresponding to subjective weights and objective weights, thereby ultimately combining the subjective weights and their weight coefficients, as well as the objective weights and their weight coefficients, to determine the dynamic weight of each load parameter. The weight coefficients of the subjective weights and objective weights respectively represent the proportions of the subjective and objective weights in the final dynamic weight, and can be dynamically adjusted according to the traffic scenario of the roadside computing nodes.

[0082] In short, this application can, but is not limited to, assign dynamic weights to key evaluation indicators for task-node matching with the goals of "global load balancing, reducing overall load, and ensuring task real-time performance." These key evaluation indicators include various load parameters: node CPU utilization (C), memory utilization (M), computing power redundancy (R), communication latency (L), and energy consumption (E). The dynamic weight calculation employs an entropy weighting method combined with the Analytic Hierarchy Process (AHP) to integrate subjective and objective weights. The specific process is as follows: For example, the dynamic weight calculation in this application can, but is not limited to, use the entropy weight method combined with the analytic hierarchy process (AHP) to achieve the fusion of subjective and objective weights. The specific process can, but is not limited to, be represented as follows: Subjective weight determination: The Analytic Hierarchy Process (AHP) is used to construct a hierarchical structure model of target layer (global load balancing) - criterion layer (each evaluation index) - scheme layer (candidate node). The judgment matrix is ​​constructed by experts (professionals and technicians in this technical field) scoring, and the subjective weight ω_sub of each evaluation index (each load parameter) is calculated (e.g., in high priority tasks, the subjective weight of communication delay L is higher than that of energy consumption E).

[0083] For example: Step 1: Construct an AHP (the core of AHP is to rank the importance of criteria-level indicators to serve the goal-level; the solution-level is the final object to be evaluated. This application's embodiment focuses on calculating the subjective weights of the criteria-level indicators) three-layer hierarchical structure model: Target layer: Global load balancing (core objective: to make the overall load of roadside computing nodes more balanced and ensure task execution efficiency). Criteria Layer: 5 load assessment metrics: CPU utilization, memory utilization, computing power redundancy, communication latency, and energy consumption; Solution layer: 3 candidate roadside computing nodes: node 1, node 2, node 3.

[0084] Step 2: Expert scoring to construct a judgment matrix: Using the AHP standard's 1-9 scale (1 = equally important, 9 = extremely important, and the reciprocal indicates the opposite importance), combined with high-priority task scenarios (communication latency L is more important than energy consumption E, and real-time performance takes priority), domain experts scored the relative importance of the five indicators in the criterion layer, resulting in a 5×5 judgment matrix A.

[0085] For example, Table 1 is a scoring table of one embodiment of this application, which can be represented as follows, but is not limited to: Table 1

[0086] The corresponding judgment matrix can be, but is not limited to, represented as:

[0087] The scoring logic (high-priority task-oriented) in this application embodiment can be, but is not limited to, represented as follows: Communication latency (L) > Computing redundancy (R) > CPU utilization (C) > Memory utilization (M) = Energy consumption (E); For example, a value of 3 in column C of row L indicates that communication latency L is 3 times more important than CPU utilization C. The value of E in row and L in column 1 / 4 indicates that the importance of energy consumption E is only 1 / 4 of that of communication delay L, which meets the requirement that "L has a higher weight than E" in the task requirements.

[0088] Step 3: Calculate the eigenvalues ​​and eigenvectors of the judgment matrix: (1) Calculate the sum of each column of the judgment matrix: , , , , ; (2) Normalize the judgment matrix (divide each row element by the sum of the corresponding columns) to obtain the normalized matrix. Taking the first row (indicator C) as an example: , , , , ; (3) Calculate the average value of each row of the normalized matrix to obtain the eigenvectors. : , , , , .

[0089] Step 4: Consistency check (a crucial step to avoid inconsistencies in scoring logic): (1) Calculate the largest eigenvalue

[0090]

[0091] First calculate :

[0092]

[0093]

[0094]

[0095]

[0096] calculate : .

[0097] (2) Calculate the consistency ratio

[0098] Consistency Indicators ; Random Consistency Index (When n=5, look up the table to get...) =1.12). Consistency ratio ; The consistency check passed, the scoring logic is consistent, and the feature vector is valid.

[0099] Step 5: Obtain the subjective weights of the criteria-level indicators

[0100] eigenvectors Normalization (summing to 1) yields the subjective weights of the five evaluation indicators: , , , , , In high-priority task scenarios, the subjective weight of communication latency (L) (0.4363) is much higher than the subjective weight of energy consumption (E) (0.0939), which fully meets the requirements; meanwhile, the weight of computing power redundancy (R) is second, reflecting the goal of "ensuring real-time performance and balancing the load".

[0101] Objective weight determination: The entropy weight method is adopted. Based on the standardized multi-dimensional load parameters of each roadside computing node, the information entropy of each evaluation index is calculated, and the objective weight of each evaluation index is determined according to the magnitude of the information entropy. The lower the information entropy, the higher the indicator differentiation and the greater the weight.

[0102] Dynamic composite weight determination: A linear weighting method is used to integrate subjective and objective weights to obtain the dynamic composite weights of each evaluation indicator. , in, These are the weighting coefficients. It can be dynamically adjusted according to roadside traffic scenarios, such as during busy traffic periods. To increase the proportion of real-time related indicators in the subjective weighting, a value of 0.6 is used; in sparse traffic scenarios. We set the value to 0.4 to increase the proportion of resource utilization-related indicators in the objective weighting.

[0103] A dynamic comprehensive weighting system, combined with standardized multi-dimensional node load parameters, is used to construct a candidate node suitability evaluation function. This function calculates the suitability score for each candidate node with the current task to be assigned. A higher suitability score indicates that the node is more suitable for assigning the task. The suitability evaluation function is as follows:

[0104] in, , , , , These are dynamic comprehensive weights for CPU utilization, memory utilization, computing power redundancy, communication latency, and energy consumption, respectively. , , These represent the remaining capacity of the node's CPU, memory, and energy consumption, respectively (the larger the value, the stronger the capacity). This indicates the sufficiency of node computing power redundancy relative to the task's computing power requirements (the larger the value, the more sufficient the computing power). Indicates the degree of advantage of node communication latency ( This represents the maximum allowable communication delay for the corresponding priority task; the larger the value, the more significant the delay advantage.

[0105] After calculating the fitness scores of all candidate nodes, this embodiment of the application can select the node with the highest score as the optimal computing power allocation node for the current task; if multiple nodes have the same fitness score, the computing power redundancy R of the computing power nodes can be further compared, and the node with the largest R can be selected to complete the allocation.

[0106] After matching the optimal nodes for all tasks to be assigned, the allocation results for each task are integrated to generate a computing power allocation scheme that includes "task ID, task type, computing power requirement, allocation node ID, node load status, and estimated execution time." This scheme is then synchronously output to the "task dynamic migration and execution" stage to guide roadside computing power nodes in receiving and executing tasks. Simultaneously, the allocation scheme is backed up to the roadside computing power scheduling center for subsequent feedback and evaluation.

[0107] This application embodiment comprehensively considers multiple dimensions of roadside computing nodes, such as CPU utilization, memory utilization, and computing power redundancy, through a dynamic weight allocation model. It selects the optimal node based on the global load balancing objective, avoiding the load imbalance problems caused by "local optima" or "static thresholds" in existing technologies. Field tests have verified that, in urban main road morning and evening rush hour scenarios, after adopting the roadside computing power allocation strategy of this application embodiment, the average load rate of roadside computing nodes can be reduced from 68%-75% in related technologies to 45%-55%, and the load standard deviation can be reduced from 0.21 to 0.12, effectively achieving a balanced global load distribution and avoiding the overload problem of a single node.

[0108] After determining the final allocation scheme for at least one task to be assigned based on the suitability assessment results, the method further includes: obtaining the final computing power node corresponding to the final allocation scheme; and adjusting the final allocation scheme to meet the target requirements based on the status information and load change data of the final computing power node during the execution of at least one task to be assigned.

[0109] In some embodiments, to improve the adaptability of the allocation scheme, after obtaining the final allocation scheme for each task to be allocated, this application may also embed a dynamic adjustment strategy.

[0110] For example, this application can obtain the final computing power node of the final allocation scheme for each task to be assigned, and then adjust and optimize each final allocation scheme according to the status information and load change data of each final computing power node in the process of executing at least one task to be assigned, until the final allocation scheme meets the target requirements.

[0111] Here, the target requirements refer to the core constraints and performance standards that the final allocation scheme needs to achieve after adjustment and optimization. Examples include reasonable thresholds for load regression of roadside computing nodes, timely fulfillment of task execution latency constraints, achievement of global load balancing standards, and compliance with task execution stability requirements. Specific target requirements can be adjusted by those skilled in the art based on actual circumstances and needs. This embodiment is provided as an example only and does not impose specific requirements.

[0112] For example, this application can collect in real time the task execution status (such as task completion progress, actual execution delay, etc.) and load change data (such as real-time fluctuations in CPU utilization and memory utilization) of each computing power node during the execution of at least one task to be assigned, and set certain dynamic adjustment and optimization trigger conditions: Dynamic adjustment is triggered when the CPU utilization of a certain roadside computing node exceeds the maximum allowable load threshold of the corresponding priority task for a continuous target time (the target time can be understood as a pre-set time period, such as 500ms) (50% for P1 level tasks, 65% for P2 level tasks, and 80% for P3 level tasks), or when the actual execution delay of a task to be assigned exceeds 80% of its deadline.

[0113] In this application embodiment, the adjustment method may be, but is not limited to, migrating some low-priority tasks (such as P3 tasks) on the roadside computing power node to the roadside computing power node with the second highest adaptability and sufficient load, or diverting some tasks to the upper-level regional edge node to ensure that the load of the roadside computing power node returns to a reasonable range.

[0114] Table 2 shows the core control conditions and parameters in the adjustment process of one embodiment of this application, which can be represented as follows, but are not limited to: Table 2

[0115] All parameters in Table 1 can be dynamically adjusted by those skilled in the art according to specific roadside traffic scenarios (such as urban arterial roads, highways, and suburban roads). This application embodiment is only for illustrative purposes and does not impose any specific limitations.

[0116] This application embodiment can avoid the surge in energy consumption caused by node overload by optimizing computing power allocation. At the same time, it reduces unnecessary task migration and data transmission energy consumption by accurately matching tasks, so that the average energy consumption of the roadside computing power system can be reduced by 15%-20%, and the average daily energy consumption of each roadside edge node is reduced from 2.8kWh to below 2.3kWh, effectively realizing the green and efficient operation of the computing power system.

[0117] Example 2 Figure 2 This is a flowchart illustrating the computing power allocation process on the service roadside according to one embodiment of this application. Figure 2 As shown, the specific computing power allocation process on the service roadside can be represented, but is not limited to, as follows: Step 1: Receive the set of roadside tasks to be assigned from the "Data Acquisition and Preprocessing" stage, perform feature analysis on each task to be assigned, extract core parameters, and perform standardization processing.

[0118] The core parameters include: task type, computing power requirement S (unit: GFLOPS), real-time priority P, deadline T (unit: ms), data transfer volume D (unit: MB), etc.

[0119] Standardization: Parameters with different dimensions are converted to the [0,1] interval for easier subsequent evaluation and calculation. The standardization formula is as follows: x'=(x-x_min) / (x_max-x_min), Where x is the original parameter value, x_min is the minimum value of the parameter, and x_max is the maximum value of the parameter.

[0120] Step 2: Import the load assessment data of each computing node on the roadside output from the "Multi-dimensional Load Assessment" step, including the node's CPU utilization C, memory utilization M, and network bandwidth utilization B; at the same time, supplement the data by collecting the computing power redundancy R (unit: GFLOPS, i.e., the difference between the node's maximum computing power and the currently occupied computing power), communication latency L (unit: ms, i.e., the communication latency between the node and the task initiating terminal), and energy consumption E (unit: W, i.e., the node's current operating energy consumption), forming a complete set of multi-dimensional load parameters for the nodes.

[0121] The parameters collected in addition to the above are also standardized using the min-max normalization method in step 1 to ensure that the parameters are of uniform dimension.

[0122] Step 3, priority-based candidate node selection: Based on the task real-time priority P extracted in Step 1, set the candidate node selection conditions corresponding to different priorities, select the candidate node set that meets the conditions from all roadside computing power nodes, realize the initial hierarchical decision-making, and ensure the real-time performance of high-priority tasks.

[0123] If the set of candidate nodes corresponding to a certain task is empty, the task is temporarily stored in the cache queue and a computing power request is sent to the upper-level regional edge node, which will then supplement and allocate computing power resources.

[0124] Step 4, Dynamic Weight Allocation Model Construction and Parameter Weight Calculation: A dynamic weight allocation model is constructed with the goals of "global load balancing, reducing overall load, and ensuring task real-time performance." Dynamic weights are assigned to key evaluation indicators for task-node matching. Key evaluation indicators include: node CPU utilization C, memory utilization M, computing power redundancy R, communication latency L, and energy consumption E.

[0125] A linear weighting method is used to integrate subjective and objective weights to obtain the dynamic comprehensive weight of each evaluation indicator: ω = α·ω_sub + (1-α)·ω_obj, Wherein, α is the weighting coefficient (α∈[0.4,0.6]), which can be dynamically adjusted according to the roadside traffic scenario.

[0126] Step 5, Candidate Node Fit Calculation and Optimal Node Selection: Based on the dynamic comprehensive weight obtained in Step 4, and combined with the standardized multi-dimensional load parameters of the nodes, a candidate node fit evaluation function is constructed. The fit score of each candidate node with the current task to be assigned is calculated. The higher the fit score, the more suitable the node is for assigning the task.

[0127] After calculating the fitness scores of all candidate nodes, the node with the highest score is selected as the optimal computing power allocation node for the current task; if multiple nodes have the same fitness score, the computing power redundancy R of the nodes is further compared, and the node with the largest R is selected to complete the allocation.

[0128] Step 6: After matching the optimal nodes for all tasks to be assigned, integrate the allocation results of each task to generate a computing power allocation scheme containing "task ID, task type, computing power requirement, allocation node ID, node load status, and estimated execution time". This scheme is then synchronously output to the "task dynamic migration and execution" stage to guide roadside computing power nodes in receiving and executing tasks. Simultaneously, the allocation scheme is backed up to the roadside computing power scheduling center for subsequent feedback and evaluation.

[0129] Real-time data collection of task execution status (e.g., task completion progress, actual execution latency) and load change data (e.g., real-time fluctuations in CPU utilization and memory utilization) is implemented on each computing node. Dynamic adjustment trigger conditions are set: dynamic adjustment is triggered when the CPU utilization of a node exceeds the maximum allowable load threshold for the corresponding priority task for 500ms consecutively (50% for P1 tasks, 65% for P2 tasks, and 80% for P3 tasks), or when the actual execution latency of a task exceeds 80% of its deadline. The adjustment method involves migrating some low-priority tasks (e.g., P3 tasks) on that node to nodes with the next highest adaptability and sufficient load, or offloading some tasks to edge nodes in the upper-level region, ensuring that the node load returns to a reasonable range.

[0130] This application embodiment also provides a roadside computing power distribution device 30, please refer to... Figure 3 The system includes: a first acquisition module 310, used to acquire multiple task parameters of at least one task to be assigned, and to acquire multiple load parameters and their dynamic weights corresponding to multiple roadside computing nodes; a filtering module 320, used to filter at least one candidate node corresponding to at least one task to be assigned from multiple roadside computing nodes based on multiple task parameters and multiple load parameters; and an allocation module 330, used to calculate the fit between at least one task to be assigned and at least one candidate node based on multiple load parameters and their corresponding dynamic weights, so as to determine the final allocation scheme of at least one task to be assigned according to the fit.

[0131] Optionally, in one embodiment of this application, the first acquisition module 310 includes: a first acquisition unit, configured to acquire at least one task to be assigned, including task type, task computing power requirement, current priority, task deadline, and data transmission volume, so as to determine multiple task parameters based on the task type, task computing power requirement, current priority, task deadline, and data transmission volume; and a second acquisition unit, configured to acquire the CPU utilization, memory utilization, computing power redundancy, communication latency, and energy consumption of multiple roadside computing power nodes, so as to determine multiple load parameters based on the CPU utilization, memory utilization, computing power redundancy, communication latency, and energy consumption.

[0132] Optionally, in one embodiment of this application, the filtering module 320 includes: a matching unit, configured to match at least one filtering condition corresponding to at least one task to be assigned based on the current priority of at least one task to be assigned; and a filtering unit, configured to filter at least one candidate node based on the filtering condition and multiple load parameters.

[0133] Optionally, in one embodiment of this application, the roadside computing power allocation device 30 further includes: an identification module, used to identify whether there is an associated task set in at least one task to be allocated; a second acquisition module, used to acquire the data transmission dependency and timing constraint relationship between each subtask in the associated task set when there is an associated task set in at least one task to be allocated; and a determination module, used to determine at least one candidate node corresponding to at least one task to be allocated based on the data transmission dependency, timing constraint relationship, and the communication delay and computing power redundancy of at least one candidate node.

[0134] Optionally, in one embodiment of this application, the first acquisition module 310 includes: an identification unit, configured to determine the subjective weights of multiple load parameters based on typical scores of multiple load parameters, and to determine the objective weights of multiple load parameters based on the information entropy of multiple load parameters; and a determination unit, configured to determine the weight coefficients corresponding to the subjective weights and objective weights respectively by combining the current traffic environment of multiple roadside computing nodes; and to determine the dynamic weights of multiple load parameters by combining the subjective weights and their weight coefficients with the objective weights and their weight coefficients.

[0135] Optionally, in one embodiment of this application, the roadside computing power allocation device 30 further includes: a third acquisition module, used to acquire the final computing power node corresponding to the final allocation scheme after determining the final allocation scheme of at least one task to be allocated based on the suitability evaluation result; a fourth acquisition module, used to acquire the status information and load change data of the final computing power node during the execution of at least one task to be allocated; and an adjustment module, used to adjust the final allocation scheme according to the status information and load change data to meet the target requirements.

[0136] This application also provides an electronic device 40, please refer to... Figure 4 It includes a processor 410 and a memory 420, wherein the memory 410 is used to store computer programs; the processor 420 is used to execute the programs stored in the memory 410 to implement the roadside computing power allocation method described in any embodiment of this application.

[0137] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the roadside computing power allocation method described in any embodiment of this application.

[0138] In this application, "multiple" refers to two or more.

[0139] In this application, unless otherwise expressly defined, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0140] The terms “first,” “second,” “third,” “fourth,” etc., in this application (if present) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0141] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0142] Unless otherwise specified, all steps in this application may be performed sequentially or randomly. For example, if the method includes steps A and B, it means that the method may include steps A and B performed sequentially, or it may include steps B and A performed sequentially. For example, if the method may also include step C, it means that step C may be added to the method in any order. For example, the method may include steps A, B, and C, or it may include steps A, C, and B, or it may include steps C, A, and B, etc.

[0143] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for allocating roadside computing power, characterized in that, Includes the following steps: Obtain multiple task parameters for at least one task to be assigned, and obtain multiple load parameters and their dynamic weights corresponding to multiple roadside computing nodes; Based on the multiple task parameters and the multiple load parameters, at least one candidate node corresponding to the at least one task to be assigned is selected from the multiple roadside computing power nodes; Based on the multiple load parameters and their corresponding dynamic weights, the fit between the at least one task to be assigned and at least one candidate node is calculated, so as to determine the final allocation scheme of the at least one task to be assigned according to the fit.

2. The method according to claim 1, characterized in that, The step of obtaining multiple task parameters for at least one task to be assigned, and obtaining multiple load parameters and their dynamic weights corresponding to multiple roadside computing nodes, includes: The task type, computing power requirement, current priority, deadline, and data transmission volume of the at least one task to be assigned are obtained, so as to determine the multiple task parameters based on the task type, computing power requirement, current priority, deadline, and data transmission volume. The CPU utilization, memory utilization, computing power redundancy, communication latency, and energy consumption of the multiple roadside computing nodes are obtained, so as to determine the multiple load parameters based on the CPU utilization, memory utilization, computing power redundancy, communication latency, and energy consumption.

3. The method according to claim 2, characterized in that, The step of selecting at least one candidate node corresponding to the at least one task to be assigned from the multiple roadside computing nodes based on the multiple task parameters and the multiple load parameters includes: Match the filtering conditions corresponding to the at least one task to be assigned based on the current priority of the task at the current time. Based on the filtering criteria and the multiple load parameters, at least one candidate node is filtered.

4. The method according to claim 1, characterized in that, Also includes: Identify whether there is a set of associated tasks among the at least one task to be assigned; If they exist, then obtain the data transmission dependencies and timing constraints between the subtasks in the associated task set; Based on the data transmission dependencies, timing constraints, and the communication latency and computing power redundancy of the at least one candidate node, at least one candidate node corresponding to the at least one task to be assigned is determined.

5. The method according to claim 1, characterized in that, The process of obtaining multiple load parameters and their dynamic weights corresponding to multiple roadside computing nodes includes: The subjective weights of the multiple load parameters are determined based on the typical scores of the multiple load parameters, and the objective weights of the multiple load parameters are determined based on the information entropy of the multiple load parameters. Based on the current traffic environment of the multiple roadside computing nodes, the weight coefficients corresponding to the subjective weight and the objective weight are determined respectively. The dynamic weights of the multiple load parameters are determined by combining the subjective weights and their weight coefficients with the objective weights and their weight coefficients.

6. The method according to claim 1, characterized in that, After determining the final allocation scheme for the at least one task to be assigned based on the fit evaluation result, the method further includes: Obtain the final computing power node corresponding to the final allocation scheme; Obtain the status information and load change data of the final computing node during the execution of the at least one task to be assigned; The final allocation scheme is adjusted based on the status information and the load change data to meet the target requirements.

7. A roadside computing power distribution device, characterized in that, include: The acquisition module is used to acquire multiple task parameters of at least one task to be assigned, and to acquire multiple load parameters and their dynamic weights corresponding to multiple roadside computing nodes. The filtering module is used to filter at least one candidate node corresponding to the at least one task to be assigned from the multiple roadside computing power nodes based on the multiple task parameters and the multiple load parameters. The allocation module is used to calculate the fit between the at least one task to be allocated and at least one candidate node based on the multiple load parameters and their corresponding dynamic weights, so as to determine the final allocation scheme of the at least one task to be allocated according to the fit.

8. An electronic device, characterized in that, Including processor and memory, among which Memory, used to store computer programs; A processor for executing a program stored in memory to implement the method described in any one of claims 1-6.

9. A vehicle, characterized in that, It includes the electronic device as described in claim 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images