Roadside device load scheduling method, edge cloud device and storage medium

Abstract

This application relates to the field of vehicle-road cooperative technology, and particularly to a method for load scheduling of roadside equipment, an edge cloud device, and a storage medium. The method includes: acquiring roadside data, vehicle-side data, edge cloud data, and cloud-based data; generating multi-dimensional data based on the roadside data, vehicle-side data, edge cloud data, and cloud-based data; extracting at least one of the following characteristics from the multi-dimensional data: roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics of the roadside equipment; calculating a load assessment score for the roadside equipment based on the at least one of the following characteristics: load assessment score; determining the load level of the roadside equipment based on the load assessment score; and migrating the task load of the roadside equipment to at least one of the edge cloud device and the cloud platform based on the load level. This solves the problems of single load assessment dimensions and poor roadside computing power release effect in related technologies.

Description

Technical Field

[0001] This application relates to the field of vehicle-road cooperative technology, and in particular to a roadside equipment load scheduling method, an edge cloud device, and a storage medium. Background Technology

[0002] With the rapid development of vehicle-road-cloud integrated technology, roadside units, as core nodes for perception, communication, and control, need to undertake multiple tasks such as vehicle positioning, road condition monitoring, data forwarding, and local decision-making.

[0003] In related technologies, a cloud-based computing power scheduling platform is used to collect data on vehicle-side task types, roadside unit computing power load, and communication link quality in real time, and to centralize unidirectional computing power offloading and allocate data in one go. Summary of the Invention

[0004] This application provides a roadside equipment load scheduling method, an edge cloud device, and a storage medium to solve problems such as a single load assessment dimension and poor roadside computing power release effect in related technologies.

[0005] The first aspect of this application provides a roadside equipment load scheduling method, comprising the following steps: acquiring roadside data, vehicle-side data, edge cloud data, and cloud-based data; generating multi-dimensional data based on the roadside data, vehicle-side data, edge cloud data, and cloud-based data, and extracting at least one of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics of the roadside equipment from the multi-dimensional data; calculating a load assessment score for the roadside equipment based on at least one of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics, determining the load level of the roadside equipment based on the load assessment score, and migrating the task load of the roadside equipment to at least one of the edge cloud equipment and the cloud platform based on the load level.

[0006] Optionally, before extracting at least one of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics of roadside equipment from the multi-dimensional data, the method further includes: preprocessing the multi-dimensional data by cleaning, removing outliers, and filling in at least one missing value; converting the preprocessed multi-dimensional data into a target format; and generating a roadside status dataset, a vehicle-side requirement dataset, and a cloud node status dataset based on the multi-dimensional data in the target format.

[0007] Optionally, at least one of the following can be extracted from multi-dimensional data: roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics of roadside equipment: extracting task requirement characteristics from vehicle-side demand datasets; extracting roadside load characteristics and energy consumption cost characteristics from roadside status datasets; and extracting communication quality characteristics between roadside equipment and edge cloud equipment and cloud platform from cloud node status datasets.

[0008] Optionally, the load assessment score of the roadside equipment is calculated based on at least one of roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics, including: assessing a first score of roadside load based on roadside load characteristics; assessing a second score of energy consumption cost based on energy consumption cost characteristics; assessing a third score of task requirement based on task requirement characteristics; assessing a fourth score of task requirement based on communication quality characteristics; and calculating the load assessment score of the roadside equipment by weighting the first, second, third, and fourth scores.

[0009] Optionally, before calculating the load assessment score of the roadside equipment based on the weighted scores of the first, second, third, and fourth scores, the method further includes: obtaining a pre-established mapping table of features and weights; and querying the mapping table using roadside load features, energy consumption cost features, task requirement features, and communication quality features as indexes to obtain the respective weights of the roadside load features, energy consumption cost features, task requirement features, and communication quality features.

[0010] Optionally, migrating the task load of roadside equipment to at least one edge cloud device and cloud platform according to the load level includes: determining a target allocation strategy for roadside equipment according to the load level; and migrating the task load of roadside equipment to at least one edge cloud device and cloud platform according to the target allocation strategy.

[0011] Optionally, a target allocation strategy for roadside equipment is determined based on the load level, including: If the load level is Level 1, the target allocation strategy is the first allocation strategy, which includes: retaining the first and second priority task loads within the roadside equipment, offloading the third priority task loads to edge cloud equipment, offloading the task loads of higher than the third priority to the cloud platform, and retaining preset computing resources within the roadside equipment. If the load level is Level 2, the target allocation strategy is the second allocation strategy, which includes: retaining the first priority and the second priority task loads with computing power requirements greater than the target requirement within the roadside equipment, offloading the second priority and third priority task loads with computing power requirements less than or equal to the target requirement to edge cloud equipment, prohibiting the offloading of task loads to the cloud platform, and the computing resources corresponding to Level 2 are less than those corresponding to Level 1. If the load level is Level 3, the target allocation strategy is the third allocation strategy, which includes: retaining the first priority task loads within the roadside equipment, offloading the task loads of higher than the first priority to edge cloud equipment, offloading the non-real-time task loads of edge devices to the cloud platform, and the computing resources corresponding to Level 3 are less than those corresponding to Level 2.

[0012] Optionally, the task load migration strategy includes: sending migration instructions to roadside devices and target nodes, wherein the target node includes at least one edge cloud device and a cloud platform; the roadside device responds to the migration instructions, suspends the execution of the task to be migrated, and compresses and packages the task context data of the task load; transmitting the packaged task data to the target node; monitoring the transmission progress during the transmission between the roadside device and the target node; and automatically switching to a backup communication link if a transmission interruption occurs; after the target node receives the data, it parses the packaged task data to restore the task context data, and simultaneously sends a successful task start signal to the edge cloud device; and the roadside device deletes the local data of the migrated task.

[0013] A second aspect of this application provides an edge cloud device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the roadside equipment load scheduling method described above.

[0014] A third aspect of this application provides a computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, when the computer program or instructions are executed, they implement the above-described roadside equipment load scheduling method.

[0015] Therefore, this application has the following beneficial effects: The roadside equipment load scheduling method proposed in this application integrates roadside data, vehicle-side data, edge cloud data, and cloud data to extract roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics. Based on these extracted characteristics, a load assessment score is calculated for the roadside equipment, and load levels are assigned. Finally, based on the load level, the task load of the roadside equipment is migrated to edge cloud devices or cloud platforms. The resource advantages of the edge cloud or cloud platform are flexibly matched according to task requirements, ensuring efficient execution of different types of tasks. This achieves accurate assessment of the roadside equipment load status and task migration, reduces equipment energy consumption and maintenance costs, and improves the overall resource utilization and operational stability of the system. Therefore, it solves the problems of single load assessment dimensions and poor roadside computing power release in related technologies.

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

[0017] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a roadside equipment load scheduling method provided according to an embodiment of this application; Figure 2This is a flowchart of a roadside equipment load scheduling implementation method according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an edge cloud device according to an embodiment of this application. Detailed Implementation

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

[0019] The following description, with reference to the accompanying drawings, describes a roadside equipment load scheduling method, edge cloud device, and storage medium according to embodiments of this application. Addressing the problems of limited load assessment dimensions and poor roadside computing power release in related technologies mentioned in the background, this application provides a roadside equipment load scheduling method. This method integrates roadside data, vehicle-side data, edge cloud data, and cloud data to extract roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics. Based on the extracted characteristics, a load assessment score for the roadside equipment is calculated, and load levels are assigned. Finally, based on the load level, the task load of the roadside equipment is migrated to the edge cloud device or cloud platform. The resource advantages of the edge cloud or cloud platform are flexibly matched according to task requirements, ensuring efficient execution of different types of tasks. This achieves accurate assessment of the roadside equipment load status and task migration, reducing resource waste or task execution interruptions caused by blind migration. It effectively balances the operating pressure of roadside equipment, reduces equipment energy consumption and maintenance costs, and improves the overall resource utilization and operational stability of the system. Therefore, it solves the problems of limited load assessment dimensions and poor roadside computing power release in related technologies.

[0020] Specifically, Figure 1 This is a flowchart of a roadside equipment load scheduling method provided in an embodiment of this application.

[0021] like Figure 1 As shown, the roadside equipment load scheduling method includes the following steps: In step S101, roadside data, vehicle-side data, edge cloud data, and cloud data are acquired.

[0022] Among them, roadside data is traffic data collected by sensing and communication equipment deployed on the road infrastructure side; vehicle-side data is vehicle operation and environmental perception data collected by sensors, controllers and on-board terminals on the vehicle itself; edge cloud data is data generated by edge cloud platforms deployed at the edge of the traffic scene after real-time preprocessing and fusion calculation of roadside data and vehicle-side data; cloud data is global data formed by in-depth mining of aggregated data uploaded by edge cloud and historical data reported by vehicle / roadside.

[0023] It is understood that the embodiments of this application can build a complete data link by acquiring roadside data, vehicle-side data, edge cloud data and cloud data, breaking the perception blind spot of a single data collection terminal. By complementing roadside data and vehicle-side data, the comprehensiveness and accuracy of traffic environment perception are improved, data transmission latency and cloud computing load are reduced, and the real-time requirements of vehicle-road cooperative applications are guaranteed.

[0024] Specifically, the data collection for roadside units utilizes a monitoring module, an energy consumption monitoring module, and a sensing and communication module. The data collection frequency is set to 100ms / time. The computing power monitoring module collects computing load parameters in real time, including CPU (Central Processing Unit) utilization, GPU utilization, memory usage, and the current task list. The energy consumption monitoring module collects real-time power consumption and hardware temperature of roadside equipment. The sensing and communication module collects traffic flow, V2X (Vehicle to Everything) communication latency, and data transmission rate. The collection frequency is set to 100ms / time to ensure data real-time performance.

[0025] The collection of vehicle-side data is achieved by receiving task requirement data from vehicles within the area via V2X communication. The collection frequency is synchronized with the collection of roadside unit data at 100ms / time. The collected data includes task type, task real-time requirements, and vehicle position and speed. For example, task types include real-time collision avoidance warning and non-real-time navigation path updates. For example, ≤50ms is considered high real-time, 50-500ms is considered medium real-time, and >500ms is considered low real-time.

[0026] Data collection between the edge cloud and the cloud utilizes the edge cloud scheduling center and the cloud platform, with a collection frequency of 500ms / time. The edge cloud scheduling center collects the remaining computing power and communication latency between the roadside and the cloud, while the cloud platform collects the computing power redundancy and historical task execution success rate data.

[0027] This application embodiment can build a complete data link by acquiring roadside data, vehicle-side data, edge cloud data, and cloud data, breaking the perception blind spot of a single data collection terminal. By complementing roadside data and vehicle-side data, it improves the comprehensiveness and accuracy of traffic environment perception, reduces data transmission latency and cloud computing load, and ensures the real-time requirements of vehicle-road cooperative applications.

[0028] In step S102, multi-dimensional data is generated based on roadside data, vehicle-side data, edge cloud data, and cloud data. At least one of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics of the roadside equipment is extracted from the multi-dimensional data.

[0029] Among them, multi-dimensional data is a comprehensive dataset formed by integrating four types of raw data: roadside data, vehicle-side data, edge cloud data, and cloud data; roadside equipment is hardware deployed on the side of road infrastructure, undertaking functions such as traffic environment perception, vehicle-road communication, data forwarding, and edge computing; roadside load characteristics are feature indicators extracted from multi-dimensional data to characterize the computing and storage resource occupancy of roadside equipment; energy consumption cost characteristics are feature indicators extracted from multi-dimensional data to reflect the energy consumption level and operation and maintenance costs of equipment; task requirement characteristics are feature indicators extracted from multi-dimensional data to characterize the business task attributes that roadside equipment needs to process; and communication quality characteristics are feature indicators extracted from multi-dimensional data to reflect the status of communication links between roadside equipment and vehicle-side, edge cloud, and cloud.

[0030] It is understood that the embodiments of this application generate multi-dimensional data from four types of basic data: roadside data, vehicle-side data, edge cloud data, and cloud data, and extract relevant features of roadside equipment. This can break down the information barriers of a single data source, realize the value transformation of basic data, and accurately characterize the operating status, business needs, and resource consumption of roadside equipment. This provides accurate data basis for optimizing the resource scheduling of roadside equipment, effectively improves the operating efficiency of roadside equipment, reduces maintenance costs, and ensures the stable development of vehicle-road cooperative services.

[0031] Specifically, the system correlates and matches regional traffic data perceived by the roadside with individual driving data reported by vehicles to construct a local correlation dimension of vehicles, roads, and environment. Secondly, it accesses real-time decision data from the edge cloud to supplement information on dimensions such as equipment operating load and task execution status. Finally, it employs rule-based or machine learning-based fusion algorithms to integrate global traffic flow and historical operation and maintenance data from the cloud, thereby improving the multi-dimensional data system encompassing time, space, equipment, business, and communication. Ultimately, this results in a structured multi-dimensional dataset covering multiple dimensions, including roadside data, vehicle data, edge cloud data, and cloud data.

[0032] For target fields in multi-dimensional datasets, targeted extraction is performed based on feature type. For example, when extracting roadside load features, indicators such as CPU utilization, memory usage, task concurrency, and number of connected terminals of roadside devices are filtered from the multi-dimensional data; when extracting energy consumption cost features, data such as real-time power consumption, power consumption per unit time, and energy consumption difference between standby and working states are extracted; when extracting task requirement features, information such as task type labels, task execution priority, task triggering frequency, and task response time requirements in the data are identified; when extracting communication quality features, indicators such as communication bandwidth, transmission latency, data packet loss rate, and signal strength between roadside devices and vehicle terminals, edge cloud, and cloud are extracted, and the stability coefficient of the communication link is calculated; after extraction, redundant features are eliminated through correlation analysis, and core features strongly correlated with the operation and management of roadside devices are retained.

[0033] Furthermore, in the embodiments of this application, before extracting at least one of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics of roadside equipment from multi-dimensional data, the method further includes: preprocessing the multi-dimensional data by cleaning, removing outliers, and filling in at least one missing value; converting the preprocessed multi-dimensional data into a target format, and generating a roadside status dataset, a vehicle-side requirement dataset, and a cloud node status dataset based on the multi-dimensional data in the target format.

[0034] Among these, cleaning involves removing invalid, redundant, and format-conflicting data from the dataset, and eliminating data noise in multi-source data fusion; outlier removal involves identifying and removing abnormal data points that deviate from the normal data distribution range or do not conform to actual business logic; missing value completion involves reasonably filling in empty fields in the dataset; target format is the conversion of preprocessed multi-dimensional data into a unified data format that conforms to subsequent operations; the roadside status dataset is a subset of data related to the full lifecycle operation status of roadside equipment extracted from the multi-dimensional data in the target format; the vehicle-side demand dataset is a subset of data reflecting the vehicle-side business needs for roadside equipment selected from the multi-dimensional data in the target format; and the cloud node status dataset is a subset of data related to the operation status and interaction relationships of edge cloud and cloud nodes extracted from the multi-dimensional data in the target format.

[0035] It is understood that the embodiments of this application perform preprocessing on multi-dimensional data, including cleaning, removing outliers, and filling in missing values, and then convert the preprocessed multi-dimensional data into a unified target format. Based on this target format data, the process of generating roadside status datasets, vehicle demand datasets, and cloud node status datasets can connect multi-dimensional data fusion with roadside equipment feature extraction. Through preprocessing operations, redundancy, noise, and gaps in multi-source heterogeneous data are effectively eliminated, data standardization is achieved, and accurate splitting and focusing of multi-dimensional data is completed, which greatly improves the accuracy and efficiency of roadside equipment feature extraction.

[0036] Specifically, the data receiving module of the edge cloud dispatch center performs preprocessing operations on the collected multi-source data, including cleaning, removing outliers, and filling in missing values. If data cleaning is performed, duplicate data entries are deleted, timestamp formats and field naming rules of different data sources are standardized, and invalid garbled data caused by equipment failure is filtered out. If outlier removal is performed, values ​​exceeding the normal distribution range are selected for core data such as roadside equipment load, energy consumption, and communication, or illogical abnormal data points are removed according to business rules, while recording the reason and location of outlier removal. If missing values ​​are filled, linear interpolation is used to fill short-term data gaps, synchronous data from adjacent roadside equipment in the same road segment is used to fill long-term gaps caused by equipment failure, and machine learning models are used to generate complete data for gaps in complex scenarios. After completion, the matching degree between the data and the actual business scenario is verified.

[0037] Based on the preprocessed clean data, a data format mapping is performed according to the preset target format to unify the heterogeneous data types from different data sources. For example, string timestamps are converted to numeric UTC (Coordinated Universal Time) timestamps, and Boolean device status is converted to 0 / 1 values. Secondly, standardized metadata information is added, including data version number, preprocessing operation record, and data validity identifier. Finally, the preprocessed roadside status dataset, vehicle-side demand dataset, and cloud node status dataset are output.

[0038] Furthermore, in embodiments of this application, extracting at least one of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics of roadside devices from multi-dimensional data includes: extracting task requirement characteristics from vehicle-side demand datasets; extracting roadside load characteristics and energy consumption cost characteristics from roadside status datasets; and extracting communication quality characteristics between roadside devices and edge cloud devices and cloud platforms, respectively, from cloud node status datasets.

[0039] Among them, edge cloud devices are clusters of hardware facilities deployed at the edge of intelligent transportation scenarios; cloud platforms are cloud computing and storage infrastructure deployed in remote centralized data centers.

[0040] It is understood that the targeted feature extraction process based on the precise matching relationship between the vehicle-side demand dataset, roadside status dataset, and cloud node status dataset and the target features in this application embodiment achieves precise focus and efficient screening of feature extraction by binding features of different dimensions with corresponding data sources. This ensures the accuracy of extracting roadside load features, energy consumption cost features, task requirement features, and communication quality features of roadside equipment, effectively improves the operating efficiency and communication stability of roadside equipment, effectively reduces operation and maintenance costs, and improves the operational reliability and efficiency of the entire intelligent transportation system.

[0041] Specifically, task requirement features are extracted from the vehicle-side demand dataset. The first step involves filtering core fields related to roadside equipment tasks from the dataset, including the task type requested by the vehicle, task priority, task execution timeliness requirements, task request frequency per unit time, and target roadside equipment number. The second step involves aggregating and associating the filtered data, grouping it by roadside equipment number and time dimension, and statistically analyzing indicators such as the distribution of task types received by a single roadside equipment at different time periods, the proportion of high-priority tasks, and peak task request periods. The third step uses a clustering algorithm to classify task requirements by level, and combines the real-time requirements and request frequency of the tasks to generate a task requirement feature vector for the roadside equipment. This vector covers dimensions such as task load intensity, task priority distribution, and task time sequence characteristics.

[0042] Extracting roadside load and energy cost features from the roadside status dataset requires filtering fields such as CPU utilization, memory usage, number of concurrent tasks, and data cache capacity utilization from the roadside status dataset for roadside load features. The mean, peak value, and fluctuation coefficient of each indicator are calculated according to a preset time window. At the same time, the duration of roadside equipment in a high-load state is statistically analyzed to comprehensively generate roadside load features that characterize the operating pressure of the equipment. For energy cost features, energy consumption data such as real-time power of equipment, energy consumption difference between standby and working states, and power consumption per unit time are extracted from the dataset. Combined with the operation and maintenance costs of roadside equipment, the unit task energy consumption cost and daily average energy consumption cost of a single device are calculated using a cost conversion formula.

[0043] Extracting communication quality features from the cloud node status dataset requires extracting communication quality features between roadside devices and edge cloud devices, and between roadside devices and the cloud platform. For communication quality features between roadside devices and edge cloud devices, it is necessary to extract communication quality features between the roadside and edge cloud, filter indicators such as roadside-edge cloud communication bandwidth, transmission latency, data packet loss rate, and signal strength in the dataset, and calculate the stability coefficient of the communication link at different time periods. For communication quality features between roadside devices and the cloud platform, it is necessary to extract communication quality features between the roadside and cloud platform, filter indicators such as end-to-end transmission latency, data compression rate, and forwarding success rate between the roadside, edge cloud, and cloud, and combine network jitter data from wide area network transmission to calculate characteristic indicators such as effective bandwidth and transmission efficiency of roadside-cloud communication. Finally, the two sets of data are integrated to generate communication quality features that distinguish the two interactive objects, edge cloud and cloud.

[0044] This application's embodiments generate multi-dimensional data from four types of basic data: roadside data, vehicle-side data, edge cloud data, and cloud data. It also extracts relevant features of roadside equipment, breaking down information barriers from single data sources and realizing the value transformation of basic data. This allows for the precise characterization of attributes such as the operating status, business needs, and resource consumption of roadside equipment, providing accurate data for optimizing resource scheduling of roadside equipment. This effectively improves the operating efficiency of roadside equipment, reduces maintenance costs, and ensures the stable operation of vehicle-road cooperative services.

[0045] In step S103, a load assessment score for the roadside equipment is calculated based on at least one of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics. The load level of the roadside equipment is determined based on the load assessment score. The task load of the roadside equipment is then migrated to at least one of the edge cloud equipment and the cloud platform based on the load level.

[0046] Among them, the load assessment score is a quantitative assessment value obtained by weighted calculation and normalization of at least one of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics and communication quality characteristics of the roadside equipment; the load level is the category of roadside equipment load assessment score level divided according to the preset score threshold range; the task load is the sum of various calculation, data processing and service response tasks that the roadside equipment currently needs to handle.

[0047] It is understood that the embodiments of this application calculate the load assessment score of roadside equipment by comprehensively considering roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics. Based on the score, the load level of the equipment is determined. Then, in combination with the load level, the task load of the roadside equipment is migrated to at least one of the edge cloud equipment or the cloud platform. This constructs a control process covering load quantification assessment, level determination, and resource scheduling. It can achieve accurate quantification and scientific classification of the load status of roadside equipment, ensure that the task migration strategy is accurately matched with the actual load of the equipment, effectively alleviate the operating pressure of roadside equipment, ensure the efficient execution of various tasks, and improve the resource utilization efficiency of the entire vehicle-road cooperative system.

[0048] Specifically, based on the preprocessed normalized feature values ​​and preset weights, the values ​​of each indicator are first converted into evaluation scores. A weighted summation algorithm is used to calculate the load evaluation score of the roadside equipment, and the calculation results are mapped to a score range of 0-10. The calculation formula is S=Σ(indicator score × indicator weight). The calculation process uses the analytic hierarchy process combined with the fuzzy comprehensive evaluation method to evaluate the preprocessed data, accurately reflecting the actual load capacity of the equipment. After the calculation is completed, the load evaluation score of a single roadside device is generated, and the contribution value of each feature and the basis for correction are recorded.

[0049] The load level classification based on the score threshold combines the rated load capacity of roadside equipment with historical operating data, presets the score threshold range of load level, sets clear judgment rules for different load levels, and marks the corresponding load level for each roadside equipment after the classification is completed and synchronized to the edge cloud dispatch center.

[0050] Further, in embodiments of this application, calculating a load assessment score for a roadside device based on at least one of roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics includes: assessing a first score for the roadside load based on the roadside load characteristics; assessing a second score for the energy consumption cost based on the energy consumption cost characteristics; assessing a third score for the task requirement based on the task requirement characteristics; assessing a fourth score for the task requirement based on the communication quality characteristics; and weighting the first, second, third, and fourth scores to calculate the load assessment score for the roadside device.

[0051] The score consists of four parts: the first score, which is a quantitative assessment of roadside load characteristics and reflects the current hardware operating pressure and resource consumption level of roadside equipment; the second score, which is a quantitative assessment of energy consumption and cost characteristics and is used to correct the load assessment results of roadside equipment from the perspectives of energy consumption and cost; the third score, which is a quantitative assessment of task demand characteristics and reflects the load pressure on roadside equipment caused by vehicle-side business demands; and the fourth score, which is a quantitative assessment of communication quality characteristics and reflects the corrective effect of the communication link status between roadside equipment and edge cloud equipment and cloud platform on the load assessment results.

[0052] It is understood that, based on the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics, the embodiments of this application calculate the corresponding first score, second score, third score, and fourth score, and then integrate the four scores through a weighted summation algorithm to obtain the roadside equipment load assessment score. This constructs a load assessment mechanism that is multi-dimensional and multi-indicator integrated. By assigning differentiated weights to load influencing factors of different dimensions, a comprehensive analysis of the load status of roadside equipment is achieved, thereby improving the credibility of the load assessment score results for roadside equipment.

[0053] Specifically, a first score is calculated based on the preprocessed roadside load characteristic indicators. Weights are assigned according to the degree of influence of the indicators on the equipment load, such as CPU utilization weight of 0.4, memory utilization weight of 0.3, task concurrency weight of 0.2, and cache utilization weight of 0.1. A weighted summation formula is used to calculate the base score, and then a load fluctuation correction coefficient is introduced to finally obtain the first score mapped to the 0-10 score range. The higher the score, the greater the hardware load pressure of the roadside equipment.

[0054] The second score is calculated based on the preprocessed energy consumption cost characteristic indicators. The weights of energy consumption indicators and cost indicators are configured, such as a weight of 0.5 for unit task energy consumption cost, 0.3 for real-time power, and 0.2 for energy consumption difference. The weighted calculation yields the base score. Then, an energy consumption and load correlation correction coefficient is introduced to finally obtain the second score in the range of 0-10. The higher the score, the higher the equipment energy consumption cost and the lower the operating efficiency.

[0055] The third score is calculated based on the preprocessed task demand characteristic indicators. Different types of tasks are assigned different values, such as 10 for safety warning tasks and 5 for traffic condition query tasks. The weights are configured by combining task priority and request frequency. The total task load undertaken by the roadside equipment per unit time is weighted and statistically analyzed, and mapped to the 0-10 score range to obtain the third score. The higher the score, the greater the intensity of the task demand from the vehicle to the roadside equipment.

[0056] The fourth score is calculated based on the preprocessed communication quality characteristic indicators. The base score is calculated by weighting the communication links with the edge cloud and the cloud. Then, a communication and load correlation correction coefficient is introduced to finally obtain the fourth score between 0 and 10. The higher the score, the worse the communication quality and the greater the negative impact on the load.

[0057] Based on the core requirements of roadside equipment load assessment, a weighting scheme for four-dimensional scores is formulated, prioritizing hardware load and task requirements, and using energy consumption and communication as auxiliary weights for correction. For example, the first score has a weight of 0.4, the second score has a weight of 0.15, the third score has a weight of 0.3, and the fourth score has a weight of 0.15. At the same time, an interface for dynamic weight adjustment is reserved, which can optimize parameters according to actual operation and maintenance scenarios.

[0058] The total load assessment score for roadside equipment is calculated using a weighted summation algorithm. The calculation formula is: S=Σ(index score × index weight). The calculation result is mapped to a standard range of 0-10 points to complete the quantitative assessment of the load of a single roadside device.

[0059] Furthermore, in the embodiments of this application, before calculating the load assessment score of the roadside equipment based on the weighted scores of the first score, the second score, the third score, and the fourth score, the method further includes: obtaining a pre-established mapping relationship table of features and weights; using the roadside load features, energy consumption cost features, task requirement features, and communication quality features as indexes, querying the mapping relationship table to obtain the respective weights of the roadside load features, energy consumption cost features, task requirement features, and communication quality features.

[0060] The mapping table is a structured data table that predefines the weight coefficients corresponding to the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics involved in the roadside equipment load assessment.

[0061] It is understood that, in this embodiment of the application, a pre-established feature-weight mapping relationship table is obtained, and then the weight coefficients corresponding to various features are accurately retrieved from the table using roadside load features, energy consumption cost features, task requirement features, and communication quality features as indexes, providing a quantitative basis for subsequent weighted calculations. By assigning weights to different features through a pre-defined mapping table, the weighted calculation of roadside equipment load assessment can be clearly defined, making the load assessment results more objective and credible. This ensures that the importance of each feature can be reasonably reflected in the load assessment score through quantified weight coefficients, guaranteeing that the final load assessment score can truly reflect the operating status of the roadside equipment.

[0062] Specifically, as shown in Table 1, the mapping relationship between features and weights is based on the load assessment of roadside equipment. The assessment dimensions are divided into four categories: roadside load status, task requirement characteristics, communication quality, and energy consumption cost. Each category is further subdivided into specific indicators, and the units, weight percentages, and descriptions of each indicator are clearly defined, thereby quantifying the degree of influence of different features on equipment load assessment.

[0063] The roadside load status includes three indicators: CPU utilization, memory usage, and hardware temperature. CPU utilization has a weight of 15%, reflecting the device's computing load; memory usage has a weight of 10%, reflecting the device's storage resource load; and hardware temperature has a weight of 8%, reflecting the risk of hardware wear and tear. Task requirement characteristics cover task real-time level, task priority, and task computing power requirements. Task real-time level has a weight of 20%, task priority has a weight of 12%, and task computing power requirements have a weight of 10%, which are respectively associated with the task's latency requirements, importance, and computing power consumption. Communication quality includes communication latency, data packet loss rate, and roadside real-time power consumption. Communication latency has a weight of 10%, corresponding to the transmission latency between the roadside and the edge cloud / cloud; data packet loss rate has a weight of 5%, corresponding to the proportion of packet loss during data transmission; and roadside real-time power consumption has a weight of 10%, reflecting the energy consumption cost of roadside operation.

[0064] The table clearly presents the specific meaning, quantification unit, and weight percentage of various evaluation indicators, providing a basis for the weighted calculation of roadside equipment load evaluation scores based on the correspondence between characteristics and weights.

[0065] Table 1. Mapping Relationship between Features and Weights

[0066] Furthermore, in embodiments of this application, migrating the task load of roadside equipment to at least one edge cloud device and cloud platform according to the load level includes: determining a target allocation strategy for roadside equipment according to the load level; and migrating the task load of roadside equipment to at least one edge cloud device and cloud platform according to the target allocation strategy.

[0067] The target allocation strategy is a specific plan that is pre-formulated based on the load level of roadside equipment to guide the migration of task load.

[0068] It is understood that the embodiments of this application determine the corresponding task target allocation strategy based on the load level of the roadside equipment, and then migrate the task load of the roadside equipment to the task scheduling process of at least one of the edge cloud equipment and the cloud platform as needed according to the strategy. By fully leveraging the low latency advantage of the edge cloud equipment and the computing power and storage resource advantages of the cloud platform through the migration strategy, the load coordination and balance of the roadside equipment, edge cloud equipment and cloud platform are achieved, effectively alleviating the operating pressure of the roadside equipment, avoiding problems such as response delay, data packet loss or equipment failure due to excessive load, and ensuring the efficient execution of different types of tasks.

[0069] Specifically, the roadside load status is divided into three levels based on the load assessment score: Level 1, Level 2, and Level 3. Level 1 is a load assessment score greater than 7 points, Level 2 is a load assessment score greater than 4 points and less than or equal to 7 points, and Level 3 is a load assessment score less than or equal to 4 points.

[0070] Based on the target allocation strategies corresponding to the first, second, and third levels, all tasks on the roadside equipment are classified according to their attributes such as real-time performance, priority, and computing power consumption, distinguishing between local retention tasks, edge cloud migration tasks, and cloud platform migration tasks.

[0071] Further, in embodiments of this application, determining the target allocation strategy for roadside equipment based on load level includes: if the load level is first level, the target allocation strategy is a first allocation strategy, which includes: retaining first-priority and second-priority task loads within the roadside equipment, offloading third-priority task loads to edge cloud devices, offloading task loads of third-priority and above to the cloud platform, and retaining preset computing power resources within the roadside equipment; if the load level is second level, the target allocation strategy is a second allocation strategy, which includes: retaining first-priority and second-priority task loads with computing power requirements greater than the target requirement within the roadside equipment. Prioritized task loads will be offloaded to edge cloud devices for second-priority and third-priority task loads whose computing power requirements are less than or equal to the target requirements. Offloading task loads to the cloud platform is prohibited. The computing power resources corresponding to the second-priority level are less than those corresponding to the first-priority level. If the load level is the third level, the target allocation strategy is the third allocation strategy, which includes: retaining the first-priority task loads in the roadside equipment, offloading the task loads above the first priority level to edge cloud devices, and offloading the non-real-time task loads of the edge meta-devices to the cloud platform. The computing power resources corresponding to the third level are less than those corresponding to the second-priority level.

[0072] The first level represents the low-load state of roadside equipment, where the equipment has sufficient resource reserves and the load pressure is minimal. The first allocation strategy is the task allocation rule corresponding to the first level. The first priority is the highest priority level for tasks, ensuring execution locally or on low-latency nodes. The second priority is for tasks with a lower priority than the first priority, serving as important auxiliary tasks for roadside equipment. The third priority is for tasks with a lower priority, which are prioritized for offloading during load diversion. The preset computing power resources are the fixed computing power quota that roadside equipment needs to reserve under the first level. The second level represents the load state of roadside equipment with a higher load pressure than the first level. The second allocation strategy is the task allocation rule corresponding to the second level. The target requirement is the computing power threshold used in the second allocation strategy to classify tasks with the second priority. The third level represents the high-load state of roadside equipment with the highest load pressure. The third allocation strategy is the task allocation rule corresponding to the third level.

[0073] It is understood that the embodiments of this application match corresponding task allocation strategies according to different load levels of roadside equipment, and carry out hierarchical collaborative load scheduling of roadside equipment, edge cloud equipment and cloud platform, which ensures the stable execution of high-priority core tasks, alleviates the operating pressure of roadside equipment step by step, realizes the optimized configuration and efficient utilization of multi-level resources, and improves the flexibility and stability of the entire roadside equipment task scheduling system.

[0074] Specifically, the first level represents the low-load state of roadside equipment, where the corresponding first allocation strategy has sufficient roadside computing power and low energy consumption, aiming at moderate load reduction and resource reservation; the second level represents the load state of roadside equipment with load pressure higher than the first level, where the corresponding second allocation strategy has roadside computing power at a critical state, aiming at precise load reduction and load balancing; the third level represents the high-load state of roadside equipment with the greatest load pressure, where the corresponding third allocation strategy has limited roadside computing power, aiming at maximizing load reduction and ensuring core services.

[0075] The first allocation strategy corresponding to the first level includes reserving the first and second priority task loads on the roadside, where the first priority is high real-time tasks and the second priority is high-priority tasks; the edge cloud will offload all third-priority tasks that it cannot handle with its own computing power to edge cloud devices, where the third priority includes medium-low real-time tasks and medium-low priority tasks; for monitoring sudden accidents, 20% of computing power is reserved to deal with sudden tasks. Only when the communication delay between the edge cloud and the roadside is ≤100ms and the packet loss rate is ≤1%, the remaining computing power of the edge cloud must be ≥1.2 times the total computing power requirement of the offloaded tasks to avoid overloading the edge cloud.

[0076] The second allocation strategy corresponding to the second level includes retaining the first priority and part of the second priority task load on the roadside. The computing power requirement of the second priority part needs to be greater than the target requirement, which can be 50 GFLOPS, that is, 50 billion floating-point operations per second. Tasks with computing power requirements of the second priority part that are less than or equal to the target requirement of 50 GFLOPS and the third priority tasks are offloaded to the edge cloud. The third priority tasks are shared between the roadside and the edge cloud at a ratio of 7:3. After the roadside tasks are offloaded, it is prohibited to offload tasks to the cloud.

[0077] The third allocation strategy corresponding to the third level includes retaining the first priority task load to ensure that high real-time and high-priority core tasks are performed first; offloading all second priority, third priority and other tasks above the first priority to edge cloud devices; and the edge cloud starting a computing power expansion mechanism to call on the redundant computing power of adjacent edge clouds in the region.

[0078] Furthermore, in the embodiments of this application, the task load migration strategy includes: sending migration instructions to the roadside device and the target node, wherein the target node includes at least one edge cloud device and a cloud platform; the roadside device responds to the migration instructions, suspends the execution of the task to be migrated, and compresses and packages the task context data of the task load; transmits the packaged task data to the target node, monitors the transmission progress during the transmission between the roadside device and the target node, and automatically switches to a backup communication link if a transmission interruption occurs; after the target node receives the data, it parses the packaged task data to restore the task context data, and simultaneously sends a successful task start signal to the edge cloud device; the roadside device deletes the local data of the migrated task.

[0079] The target node is the terminal or platform that receives the roadside equipment migration task, undertakes it, and continues to execute the roadside equipment transfer task. The migration instruction is the task migration control instruction sent by the task scheduler to the roadside equipment. The transmission progress is the proportion of the amount of data transmitted to the total amount of data to be transmitted during the process of the roadside equipment transmitting the packaged task data to the target node. The communication link is the transmission channel that serves as an alternative channel to ensure the continuous transmission of task data when the main link is interrupted. Parsing and packaging is the data decompression and format restoration operation performed by the target node after receiving the packaged task data transmitted by the roadside equipment. The success signal is the status confirmation signal fed back to the roadside equipment by the target node after completing the parsing and unpacking of the task data, restoring the task context data, and successfully starting the migration task. The migration task is the task to be completed in the roadside equipment that needs to be transferred to the target node for continued execution.

[0080] It is understood that the task load migration strategy in this application sends migration instructions to the roadside equipment and the target node, including edge cloud equipment and cloud platform. The roadside equipment suspends the task to be migrated and compresses and packages the task context data. It monitors the progress when transmitting data. If interrupted, it switches to the backup communication link. After the target node unpacks and restores the data, it sends back a successful start signal. The roadside equipment deletes the local migration task data. The task load migration strategy proposed in this application can effectively balance the task load of roadside equipment, edge cloud equipment and cloud platform. According to the task requirements, it can flexibly select the nearest edge cloud equipment or the cloud platform with stronger computing power as the target node, adapting to the latency and computing power requirements of different tasks in the vehicle-road cooperative scenario. At the same time, by deleting the local data after the task migration, the storage and computing power resources of the roadside equipment are released. By using the switching mechanism of the backup communication link, the complete retention and reliable transmission of task context data are achieved, ensuring the seamless execution of the task to be migrated at the target node and improving the anti-interference capability and stability of data transmission.

[0081] Specifically, migration instructions are sent to target nodes such as roadside units and edge / cloud. These instructions include information such as task identifier, data format, and transmission protocol. The roadside unit suspends the execution of the task to be migrated, compresses and packages the task context data using the LZ4 compression algorithm, establishes an encrypted transmission channel through the 5G private network, and transmits the packaged task data to the target node. During transmission, the transmission progress is monitored in real time. If a transmission interruption occurs, the system automatically switches to a backup communication link. After receiving the data, the target node unpacks the data, restores the task context, and starts task execution. Simultaneously, it sends a successful task start signal to the edge cloud scheduling center. The roadside unit deletes the local data of the migrated task, releasing computing resources.

[0082] This application's embodiments calculate a roadside equipment load assessment score by comprehensively considering roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics. Based on this score, the equipment load level is determined. Then, combined with the load level, the task load of the roadside equipment is directionally migrated to at least one of the edge cloud equipment or the cloud platform. This constructs a control process covering load quantification assessment, level determination, and resource scheduling. It can achieve accurate quantification and scientific classification of the roadside equipment load status, ensure that the task migration strategy is accurately matched with the actual load of the equipment, effectively alleviate the operating pressure of the roadside equipment, ensure the efficient execution of various tasks, and improve the resource utilization efficiency of the entire vehicle-road cooperative system.

[0083] To better understand the solution of this application, the roadside equipment load scheduling method or execution flow of this application is described below through a specific embodiment, as follows: Figure 2 What is below: Step 1: Data acquisition and preprocessing.

[0084] This step is fundamental to the entire system's operation, providing data support for subsequent evaluation and scheduling. It must be performed, and the accuracy of the data must be guaranteed. The specific process is as follows: 1.1 Roadside Unit Data Acquisition: Real-time computing load parameters of the roadside units are collected through the computing power monitoring module, including CPU utilization, GPU utilization, memory usage, and the list of currently executing tasks; real-time power consumption and hardware temperature of roadside equipment are collected through the energy consumption monitoring module; and traffic flow, V2X communication latency, and data transmission rate are collected through the sensing and communication module. The acquisition frequency is set to 100ms / time to ensure data real-time performance.

[0085] 1.2 Vehicle-side data acquisition: Receive task requirement data from vehicles within the area via V2X communication, including task type, real-time requirements, vehicle location, and speed. The acquisition frequency is synchronized with the roadside data collection at 100ms / time.

[0086] 1.3 Edge Cloud and Cloud Data Acquisition: The edge cloud scheduling center collects its own remaining computing power and communication latency with the roadside / cloud; the cloud platform collects its own computing power redundancy and historical task execution success rate data. The acquisition frequency is 500ms / time, balancing real-time performance and resource consumption.

[0087] 1.4 Data Preprocessing: The data receiving module of the edge cloud dispatch center cleans the collected multi-source data, removes outliers, fills in missing values, and standardizes the data into a unified format, outputting the preprocessed roadside status dataset, vehicle demand dataset, and cloud node status dataset.

[0088] Step 2: Multi-dimensional load assessment.

[0089] This step is the core of generating a scientific scheduling strategy, directly determining the balance between roadside computing power reduction and service quality. It must be executed, and the accuracy of the evaluation model must be guaranteed. Specific process: 2.1 Establish an evaluation index system: Twelve evaluation indicators were constructed from four dimensions: roadside load status, task requirements, characteristics, communication quality, energy consumption, and cost. The indicators and their weights are shown in Table 1. 2.2 Load Assessment Calculation: The Analytic Hierarchy Process (AHP) combined with fuzzy comprehensive evaluation method was used to evaluate the preprocessed data. First, the values ​​of each indicator were converted into evaluation scores (0-10 points), such as 10 points for CPU utilization ≤ 30%, 6 points for 30%-60%, 3 points for 60%-80%, and 0 points for > 80%. Then, the comprehensive evaluation score S (0-10 points) was calculated based on the weights, using the formula: S = Σ (indicator score × indicator weight). Based on the S value, the roadside load status was divided into three levels: high load (S ≤ 4 points), medium load (4 < S ≤ 7 points), and low load (S > 7 points).

[0090] Step 3: Generate computing power allocation strategy.

[0091] This step is crucial for reducing roadside computing power. Differentiated strategies are developed based on load assessment results, and their execution must be ensured while maintaining their feasibility. The strategy generation module of the edge cloud scheduling center generates the following three core strategies based on roadside load levels, task characteristics, and cloud node status: 3.1 Low-load strategy (S>7 points): With sufficient roadside computing power and low energy consumption, the goal is to moderately reduce load and reserve resources.

[0092] The low-load strategy details are as follows: 1) Retain roadside high real-time tasks and high-priority tasks; 2) Offload all low-to-medium real-time tasks and low-to-medium priority tasks to the edge cloud; 3) Edge cloud offloads low-real-time, low-priority tasks that its own computing power cannot handle to the cloud; 4) Reserve 20% of computing power on the roadside to cope with sudden tasks. Control conditions and parameters: Task offloading is only performed when the communication delay between the edge cloud and the roadside is ≤100ms and the packet loss rate is ≤1%; the remaining computing power of the edge cloud must be ≥1.2 times the total computing power requirement of the offloading task to avoid overloading the edge cloud.

[0093] 3.2 Medium load strategy (4 < S ≤ 7 points): The roadside computing power is in a critical state, with the goal of precise load reduction and load balancing.

[0094] The medium load policy content is as follows: 1) Retain roadside high real-time tasks and some medium real-time tasks (level 2 tasks with medium computing power requirements > 50 GFLOPS); 2) Offload tasks with a computing power requirement of ≤50GFLOPS and low real-time tasks to the edge cloud; 3) Roadside and edge clouds will share medium-priority tasks in a 7:3 ratio; 4) Do not uninstall tasks to the cloud to avoid communication delays affecting service quality.

[0095] Control conditions and parameters: After the roadside task is unloaded, the CPU utilization rate should be controlled at ≤60%; the communication latency between the edge cloud and the roadside should be ≤150ms and the packet loss rate should be ≤2%; after the task is unloaded, the real-time power consumption of the roadside should be reduced by ≥15%.

[0096] 3.3 High-load strategy (S≤4 points): Roadside computing power is tight, with the goal of maximizing load reduction and ensuring core services.

[0097] The high-load strategy details are as follows: 1) Only retain high real-time, high-priority core tasks on the roadside, such as real-time collision avoidance warning and traffic light control; 2) Offload all other tasks, including those with level 2-3 real-time requirements and level 2-5 priority requirements, to the edge cloud; 3) The edge cloud initiates a computing power expansion mechanism, utilizing the redundant computing power of adjacent edge clouds within the region; 4) The cloud temporarily takes over non-real-time tasks that the edge cloud cannot handle, ensuring task execution.

[0098] Control conditions and parameters: The response latency of the core roadside task must be ≤50ms to ensure service quality; the communication latency between the edge cloud and the roadside must be ≤200ms and the packet loss rate must be ≤3%; after the roadside is offloaded, the CPU utilization rate must be reduced to ≤40% and the hardware temperature must be reduced to ≤60℃.

[0099] Step 4: Dynamically migrate and execute the task.

[0100] This step is the core of strategy implementation, directly reducing roadside computing power. It must be executed, and the smoothness of the migration process must be guaranteed. It is performed by the task migration module of the edge cloud scheduling center. The specific process is as follows: 4.1 Migration Preparation: Send migration instructions to the roadside unit and the target node, including information such as task identifier, data format, and transmission protocol; the roadside unit suspends the execution of the task to be migrated and compresses and packages the task context data.

[0101] 4.2 Data transmission: An encrypted transmission channel (using AES-256 encryption algorithm) is established through a 5G private network to transmit the packaged task data to the target node; the transmission progress is monitored in real time during the transmission process, and if the transmission is interrupted, it automatically switches to the backup communication link to ensure data integrity.

[0102] 4.3 Task Restart: After receiving the data, the target node unpacks and restores the task context, and starts task execution; at the same time, it sends a successful task start signal to the edge cloud scheduling center; the roadside unit deletes the local data of the migrated task and releases computing resources.

[0103] 4.4 Migration Time Control: The total migration time for a single task must meet the following requirements: high real-time tasks ≤ 100ms, medium real-time tasks ≤ 500ms, and low real-time tasks ≤ 1000ms, to avoid affecting service quality during the migration process.

[0104] Step 5: Feedback evaluation and strategy optimization.

[0105] This step is crucial for achieving continuous load reduction. It is the preferred step because it improves the adaptability of the strategy through closed-loop optimization. It is executed by the feedback optimization module of the edge cloud scheduling center, and the specific process is as follows: 5.1 Effectiveness Evaluation: After the task is completed, three core evaluation indicators will be collected: 1) Service quality indicators to determine whether the task response latency meets the requirements; 2) Roadside load reduction effect, such as the percentage reduction in roadside computing load and the percentage reduction in power consumption; 3) Task execution success rate: Determine whether the task failure was caused by migration. The evaluation cycle is 10 seconds / time, and an evaluation report is generated.

[0106] 5.2 Strategy Adjustment: Dynamically optimize strategy parameters based on the evaluation report. 1) If the service quality does not meet the standards, reduce the offloading ratio of the corresponding tasks and migrate some tasks back to the roadside or edge cloud. 2) If the roadside load reduction effect does not meet expectations, increase the unloading volume of low-priority tasks while ensuring service quality; 3) If the task execution success rate is less than 99.5%, optimize the communication encryption transmission protocol to reduce the packet loss rate.

[0107] 5.3 Model Update: The edge cloud regularly uploads evaluation data to the cloud. The cloud uses machine learning to train and optimize the indicator weights of the load evaluation model. The updated model is then distributed to the edge cloud to improve the accuracy of subsequent evaluation and scheduling.

[0108] In summary, the roadside equipment load scheduling method proposed in this application integrates roadside data, vehicle-side data, edge cloud data, and cloud data to extract roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics. Based on these extracted characteristics, a load assessment score for the roadside equipment is calculated, and load levels are assigned. Finally, based on the load level, the task load of the roadside equipment is migrated to edge cloud equipment or a cloud platform. The resource advantages of the edge cloud or cloud platform are flexibly matched according to task requirements, ensuring efficient execution of different types of tasks. This achieves accurate assessment of the roadside equipment load status and task migration, reducing resource waste or task execution interruptions caused by blind migration. It effectively balances the operating pressure of roadside equipment, reduces equipment energy consumption and maintenance costs, and improves the overall resource utilization and operational stability of the system.

[0109] Figure 3 This is a schematic diagram of the structure of an edge cloud device provided in an embodiment of this application. The edge cloud device may include: The memory 301, the processor 302, and the computer program stored on the memory 301 and capable of running on the processor 302.

[0110] When the processor 302 executes the program, it implements the roadside equipment load scheduling method provided in the above embodiments.

[0111] Furthermore, edge cloud devices also include: Communication interface 303 is used for communication between memory 301 and processor 302.

[0112] The memory 301 is used to store computer programs that can run on the processor 302.

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

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

[0115] Optionally, in a specific implementation, if the memory 301, processor 302, and communication interface 303 are integrated on a single chip, then the memory 301, processor 302, and communication interface 303 can communicate with each other through an internal interface.

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

[0117] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the roadside equipment load scheduling method described above.

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

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

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

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

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

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

Claims

1. A roadside device load scheduling method, characterized by, The method is applied to an edge cloud device, which communicates with the roadside equipment, the vehicle, and the cloud platform, respectively. The method includes the following steps: Acquire roadside data, vehicle-side data, edge cloud data, and cloud data; Multi-dimensional data is generated based on the roadside data, vehicle-side data, edge cloud data, and cloud data. At least one of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics of the roadside equipment is extracted from the multi-dimensional data. Based on at least one of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics, a load assessment score is calculated for the roadside device. The load level of the roadside device is determined based on the load assessment score. Based on the load level, the task load of the roadside device is migrated to at least one of the edge cloud device and the cloud platform.

2. The roadside equipment load scheduling method according to claim 1, characterized in that, Before extracting at least one of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics of the roadside equipment from the multi-dimensional data, the method further includes: Preprocessing of multi-dimensional data includes cleaning, removing outliers, and filling in at least one missing value. The preprocessed multi-dimensional data is transformed into the target format, and roadside status dataset, vehicle demand dataset, and cloud node status dataset are generated based on the multi-dimensional data in the target format.

3. The roadside equipment load scheduling method according to claim 2, characterized in that, Extracting at least one of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics of the roadside equipment from the multi-dimensional data includes: Extract the task requirement features from the vehicle-side requirement dataset; Extract the roadside load features and energy consumption cost features from the roadside status dataset; The communication quality characteristics of the roadside device with the edge cloud device and the cloud platform are extracted from the cloud node status dataset.

4. The roadside equipment load scheduling method according to claim 1, characterized in that, The step of calculating the load assessment score of the roadside equipment based on at least one of the roadside load characteristics, the energy consumption cost characteristics, the task requirement characteristics, and the communication quality characteristics includes: A first score of the roadside load is evaluated based on the roadside load characteristics; A second score for energy consumption cost is assessed based on the aforementioned energy consumption cost characteristics; A third score for the task requirements is assessed based on the aforementioned task requirement characteristics; The fourth score for task requirements is evaluated based on the aforementioned communication quality characteristics; The load assessment score of the roadside equipment is calculated by weighting the first score, the second score, the third score, and the fourth score.

5. The roadside equipment load scheduling method according to claim 4, characterized in that, Before calculating the load assessment score of the roadside equipment based on the weighted scores of the first score, the second score, the third score, and the fourth score, the method further includes: Obtain the pre-established mapping table between features and weights; Using the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics as indexes, the mapping relationship table is queried to obtain the weights of the roadside load characteristics, energy consumption cost characteristics, task requirement characteristics, and communication quality characteristics, respectively.

6. The roadside equipment load scheduling method according to claim 1, characterized in that, The step of migrating the task load of the roadside equipment to at least one of the edge cloud equipment and the cloud platform according to the load level includes: The target allocation strategy for the roadside equipment is determined based on the load level. According to the target allocation strategy, the task load of the roadside equipment is migrated to at least one of the edge cloud equipment and the cloud platform.

7. The roadside equipment load scheduling method according to claim 6, characterized in that, The step of determining the target allocation strategy for the roadside equipment based on the load level includes: If the load level is the first level, then the target allocation strategy is the first allocation strategy, which includes: retaining the first priority and second priority task loads in the roadside equipment, offloading the third priority task loads to the edge cloud equipment, offloading the task loads above the third priority to the cloud platform, and retaining preset computing power resources in the roadside equipment. If the load level is the second level, then the target allocation strategy is the second allocation strategy. The second allocation strategy includes: retaining the first priority and the second priority task load with computing power demand greater than the target demand in the roadside equipment; offloading the second priority task load with computing power demand less than or equal to the target demand and the third priority task load to the edge cloud equipment; prohibiting the offloading of the task load to the cloud platform; and the computing power resources corresponding to the second level are less than the computing power resources corresponding to the first level. If the load level is the third level, then the target allocation strategy is the third allocation strategy, which includes: retaining the first priority task load in the roadside equipment, offloading the task load above the first priority to the edge cloud equipment, and offloading the non-real-time task load of the edge meta-equipment to the cloud platform. The computing power resources corresponding to the third level are less than the computing power resources corresponding to the second level.

8. The roadside equipment load scheduling method according to claim 1, 6, or 7, characterized in that, The task load migration strategy includes: A migration command is sent to the roadside device and the target node, wherein the target node includes at least one of the edge cloud device and the cloud platform. In response to the migration command, the roadside device suspends the execution of the task to be migrated and compresses and packages the task context data of the task load. The packaged task data is transmitted to the target node. During the transmission between the roadside device and the target node, the transmission progress is monitored. If a transmission interruption occurs, the system automatically switches to a backup communication link. After the target node receives the data, it parses the packaged task data to restore the task context data, and sends a successful task start signal to the edge cloud device. The roadside device then deletes the local data of the migrated task.

9. An edge cloud device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the roadside equipment load scheduling method according to any one of claims 1-8.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed, they implement the roadside equipment load scheduling method according to any one of claims 1-8.

Images