Edge-cloud collaborative computing power scheduling architecture and low-power consumption management method

Abstract

The application discloses an edge-cloud collaborative computing power scheduling architecture and a low-power consumption management method, and relates to the technical field of edge computing.The application collects multi-dimensional resource indexes of distributed edge computing nodes, calculates resource availability scores through standardized processing and weighted comprehensive score calculation; extracts static code features and dynamic running features of tasks, adopts a gradient boosting decision tree algorithm to predict execution time, CPU occupancy, memory requirement and network transmission data volume of the tasks, and performs node performance correction; adopts an improved non-dominated sorting genetic algorithm to solve a multi-objective optimization problem, and generates a task offloading decision; the application solves problems such as difficulty in resource quantification under an edge computing environment, lack of accurate prediction in task scheduling, poor single-objective optimization effect, and unintelligent power consumption control, realizes efficient task scheduling and low-power consumption operation, and has good scalability and adaptability.

Description

Technical Field

[0001] This invention relates to the field of edge computing technology, specifically to an edge-cloud collaborative computing power scheduling architecture and a low-power management method. Background Technology

[0002] With the rapid development of IoT, 5G communication, and AI technologies, edge computing has emerged as a new computing paradigm. Edge computing deploys computing, storage, and network resources close to the network edge, effectively reducing network latency, alleviating cloud load, and improving the real-time performance and reliability of data processing. Edge computing is playing an increasingly important role in applications such as smart cities, the industrial internet, autonomous driving, and augmented reality.

[0003] However, edge computing environments are characterized by wide node distribution, strong device heterogeneity, and limited resources, posing numerous challenges in task scheduling and resource management. Existing technologies mainly suffer from the following problems:

[0004] First, monitoring and quantifying the resource status of edge computing nodes is difficult. Existing systems lack real-time monitoring and unified quantification mechanisms for the computing power resources of distributed heterogeneous nodes, making it difficult to accurately assess the task carrying capacity of each node. This results in scheduling decisions lacking reliable data support, easily leading to problems such as load imbalance and low resource utilization.

[0005] Secondly, the computational complexity and resource requirements of tasks are difficult to predict accurately. Traditional task scheduling methods are mainly based on simple heuristic rules and fail to deeply analyze information such as the code characteristics of tasks, the scale of input data, and historical execution patterns. They lack the ability to accurately predict the requirements of task execution time and resource consumption, resulting in poor scheduling performance.

[0006] Finally, existing task offloading decision-making methods have a singular optimization objective. They typically only optimize a single objective such as task completion time or load balancing, failing to seek a balance among multiple conflicting optimization objectives such as task completion time, system energy consumption, and resource utilization, making it difficult to adapt to the differentiated needs of different application scenarios.

[0007] Therefore, there is an urgent need to provide an integrated and intelligent computing power scheduling architecture and a low-power management method to improve the task scheduling efficiency and energy efficiency of edge computing systems.

[0008] To address the aforementioned issues, it is necessary to propose an edge-cloud collaborative computing power scheduling architecture and a low-power management method. Summary of the Invention

[0009] The purpose of this invention is to solve the problems existing in the background technology, and to propose an edge-cloud collaborative computing power scheduling architecture and a low-power management method.

[0010] The objective of this invention can be achieved through the following technical solutions:

[0011] An edge-cloud collaborative computing power scheduling architecture and low-power management method, including the following steps:

[0012] Step S100: Real-time monitoring and status quantification of edge computing node computing resources;

[0013] Real-time monitoring of computing resources of distributed edge computing nodes is performed, collecting multi-dimensional resource indicators such as processor utilization, memory usage, network bandwidth utilization, task queue length and power consumption status of each node, and quantifying these heterogeneous indicators into a unified resource availability score through standardized processing.

[0014] Specifically, a lightweight monitoring agent is deployed on each edge computing node to collect a snapshot of resource metrics every 500 milliseconds, including processor utilization, memory usage, network bandwidth utilization, task queue length, and instantaneous power consumption.

[0015] In a preferred embodiment of the present invention, the collected multi-dimensional resource indicators are standardized by using a maximum-minimum normalization method to map each indicator to a standard range of 0 to 1. For percentage-type indicators, the standardization formula is the original value divided by 100; for count-type indicators such as task queue length, the standardization formula is the current value divided by the reference maximum value; for continuous indicators such as power consumption, the standardization formula is the current value divided by the reference maximum power consumption.

[0016] In a preferred embodiment of this invention, a resource availability score for each edge computing node is calculated using a weighted comprehensive scoring method based on standardized multi-dimensional resource indicators. A weighted summation model is employed, with weight coefficients reflecting the importance of different resource indicators to the node's task carrying capacity. The preset default weight configuration is as follows: processor utilization weight 0.35, memory utilization weight 0.25, network bandwidth utilization weight 0.20, task queue length weight 0.15, and power consumption status weight 0.05, with the sum of the five weight coefficients equal to 1.0. The calculated resource availability score, along with the node identifier, timestamp, and original resource indicator data, is encapsulated into a node state vector.

[0017] Step S200: Task feature extraction and computational complexity prediction;

[0018] By analyzing information such as the task's code characteristics, input data size, and historical execution records, the task's computational resource requirements, execution time, and network transmission overhead are estimated to obtain the task feature vector.

[0019] As a preferred embodiment of the present invention, static features are extracted from the source code, compilation artifacts or container image of the task, including code size features, loop structure features, data structure features and parallel features.

[0020] In a preferred embodiment of the present invention, the runtime characteristics and execution history of the task are collected, including the input data size, input data feature distribution, historical average execution time, and historical resource consumption statistics. Historical execution records of the task or similar tasks are retrieved from the historical execution log database of the task scheduling system, and resource consumption indicators such as average CPU time, peak memory usage, and network data transmission volume are statistically analyzed.

[0021] In a preferred embodiment of this invention, a gradient boosting decision tree (GBDT) algorithm is used to construct a prediction model. This model comprehensively utilizes the static and dynamic features of the task to predict the task's execution time, CPU utilization, memory requirements, and network data transmission volume under a standard computing environment. The training data for the prediction model comes from historical task execution records, and the model is trained offline in batches, retraining the model weekly using the latest historical data.

[0022] In a preferred embodiment of the present invention, considering the differences in execution time of tasks on edge computing nodes with varying performance, node performance correction is applied to the predicted execution time. The performance benchmark score is obtained by running a standard test suite, comprehensively reflecting the node's processor performance, memory performance, and I / O performance. The predicted task complexity features are encapsulated into a task feature vector, including a unique task identifier, submission timestamp, predicted execution time, predicted CPU utilization, predicted memory requirements, predicted network data transfer volume, task priority, and task deadline.

[0023] Step S300: Generation of multi-objective optimization task unloading decision;

[0024] Based on edge computing node status information and task complexity characteristics, a multi-objective optimization algorithm is used to generate the optimal task offloading decision, which determines whether each task should be executed on the local edge computing node, offloaded to a nearby edge computing node, or offloaded to the cloud.

[0025] In a preferred embodiment of the present invention, a feasible solution space for task offloading decisions is constructed, all feasible offloading options for each task are enumerated, and the execution time cost, energy consumption cost, and economic cost of each option are calculated. The execution time cost of the local execution option is equal to the expected execution time of the task on the local node, and the energy consumption cost is equal to the expected energy consumption of the local node during task execution. The execution time cost of offloading to a nearby edge computing node includes data upload time, remote execution time, and result download time. The calculation method for the execution time cost and energy consumption cost of offloading to the cloud is similar to that of offloading to an edge computing node. Cloud offloading also involves economic costs, which are calculated according to the billing standards of the cloud service provider.

[0026] As a preferred embodiment of the present invention, the improved non-dominated sorting genetic algorithm NSGA-II is used to solve the multi-objective optimization problem of task unloading decision-making. The optimization objectives include: minimizing the maximum completion time of all tasks, minimizing the total system energy consumption, and maximizing the resource utilization of edge computing nodes. The NSGA-II algorithm adopts a genetic algorithm framework, with a population size of 100, an evolutionary number of 50 generations, a crossover probability of 0.9, and a mutation probability of 0.1. Chromosome encoding is integer-based, where the j-th gene position of the chromosome represents the unloading target node number of the j-th task. After the algorithm runs, a set of Pareto optimal solutions is obtained, and a weighted summation method is used to select the final execution scheme from these solutions.

[0027] In a preferred embodiment of the present invention, the unloading decision generated by the optimization algorithm is transformed into specific task scheduling instructions and distributed to relevant edge computing nodes and cloud resource pools for execution. For tasks that are selected for local execution or execution on edge computing nodes, a power control request is sent to the power control step to trigger the target node to perform dynamic voltage and frequency adjustment.

[0028] Step S400: Power consumption control of dynamic voltage frequency adjustment;

[0029] Dynamic voltage and frequency adjustment is performed on edge computing nodes. Based on task offloading decisions and task performance requirements, the operating voltage and clock frequency of the processor are dynamically adjusted to minimize node energy consumption while meeting task completion time constraints.

[0030] In a preferred embodiment of the present invention, the available relaxation time for tasks assigned to edge computing nodes is calculated. The relaxation time is defined as the deadline minus the current time and then minus the expected execution time. The existence of relaxation time provides room for reducing processor frequency; the larger the relaxation time, the greater the potential for frequency reduction and the higher the energy-saving potential.

[0031] Based on the calculated relaxation time, a suitable operating point is selected from the discrete frequency-voltage levels supported by the processor. All P-state levels supported by the processor are iterated through; for each level, the expected execution time of the task at that frequency is calculated, and it is determined whether the deadline constraint is met. The lowest frequency level is selected from all preset frequency levels that meet the deadline constraint.

[0032] In a preferred embodiment of the present invention, the selected frequency-voltage level is translated into specific hardware control instructions, and the processor's DVFS mechanism is invoked through the operating system's power management interface to achieve dynamic switching of the processor's operating point. This embodiment adopts a task-granularity frequency adjustment strategy, that is, a suitable frequency level is set before the task starts execution, and the frequency remains unchanged during task execution. For multi-core processors, different processor cores can independently set their frequency-voltage levels. After completing the frequency adjustment, the updated power consumption status data is fed back to the resource monitoring step, forming a closed-loop feedback control.

[0033] Compared with the prior art, the beneficial effects of the present invention are:

[0034] This invention establishes a unified resource quantification mechanism for edge computing nodes by standardizing and weighting multi-dimensional heterogeneous resource indicators such as processor utilization, memory usage, network bandwidth utilization, task queue length, and power consumption status. It comprehensively utilizes the static code and dynamic runtime characteristics of tasks, employing a gradient boosting decision tree algorithm to accurately predict task computational complexity. An improved non-dominated sorting genetic algorithm seeks the Pareto optimal solution among the three objectives of minimizing task completion time, minimizing total system energy consumption, and maximizing resource utilization, achieving multi-objective collaborative optimization of task scheduling. By calculating the available relaxation time of tasks and selecting the lowest frequency level that meets the deadline constraint, dynamic power consumption control based on relaxation time is achieved, reducing the energy consumption of edge computing nodes by 15% to 40%. The invention organically integrates four modules—resource monitoring, task complexity prediction, offload decision generation, and power consumption control—to form a closed-loop feedback control, achieving system-level energy efficiency optimization. This invention supports edge-cloud collaborative scheduling, has good scalability and adaptability, and can meet the differentiated needs of different application scenarios. Attached Figure Description

[0035] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings:

[0036] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

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

[0038] Please see Figure 1 As shown, the edge-cloud collaborative computing power scheduling architecture and low-power management method include the following steps:

[0039] Step S100: Real-time monitoring and status quantification of edge computing node computing resources;

[0040] The computing resources of distributed edge computing nodes are monitored in real time, collecting multi-dimensional resource indicators such as processor utilization, memory usage, network bandwidth utilization, task queue length, and power consumption status of each node. These heterogeneous indicators are then quantified into a unified resource availability score through standardization, providing basic data support for subsequent task offloading decisions. The output data of this step will be transmitted to steps S200 and S300 for task complexity prediction and offloading decision calculation.

[0041] In this embodiment, the real-time monitoring and status quantification steps of edge computing node computing power resources include step S101 resource index collection, step S102 heterogeneous data standardization, and step S103 resource availability quantification.

[0042] Step S101: Resource indicator collection;

[0043] Multi-dimensional resource status data is collected from distributed edge computing nodes through resource metric collection. Edge computing nodes include edge servers, edge gateways, and smart terminal devices. Each node periodically collects local resource metrics through a resource monitoring agent.

[0044] In one implementation of this embodiment, resource status data packets are sent to the edge cluster controller via the network interface of the edge computing node using the UDP protocol, with a transmission period of 500 milliseconds, synchronized with the acquisition period. Compared to the TCP protocol, the UDP protocol has lower transmission overhead and latency, making it suitable for high-frequency status data reporting scenarios. To ensure data reliability, a sequence number mechanism and packet loss detection are implemented at the application layer. The edge cluster controller maintains the latest sequence number for each node, records a packet loss event when a discontinuous sequence number is detected, and estimates the lost data points using interpolation methods.

[0045] As one implementation method of this embodiment, a lightweight monitoring agent is deployed on each edge computing node to obtain the node's resource usage status in real time in a non-intrusive manner. The monitoring agent collects a snapshot of resource metrics every 500 milliseconds, including processor utilization, memory usage, network uplink bandwidth utilization, network downlink bandwidth utilization, current task queue length, and instantaneous power consumption.

[0046] The processor utilization rate is calculated by reading the / proc / stat file of the operating system, and represents the percentage of the total time that the processor is busy, with a value ranging from 0% to 100%.

[0047] The memory usage rate is obtained by reading the / proc / meminfo file, which shows the ratio of used memory to total memory.

[0048] Among them, network bandwidth utilization is calculated by reading the / proc / net / dev file to determine the ratio of data transmission volume per unit time to network interface bandwidth;

[0049] The task queue length represents the number of tasks currently waiting to be executed, which is obtained by querying the task scheduler's ready queue.

[0050] Instantaneous power consumption is obtained by reading from the RAPL interface or the intelligent power management chip, and the unit is watts. The collected raw resource indicator data is appended with a unique node identifier and a timestamp, and encapsulated in JSON format as a resource status data packet.

[0051] Step S102: Heterogeneous data standardization;

[0052] By standardizing heterogeneous data, the collected multi-dimensional resource indicators are standardized to eliminate the differences in the dimensions and numerical ranges of different indicators, so that they can be compared and comprehensively evaluated on a unified scale.

[0053] The maximum-min normalization method is used to map each resource indicator to a standard range of 0 to 1. Standardization not only eliminates differences in units of measurement but also makes different types of resource indicators comparable, laying the foundation for subsequent weighted comprehensive scoring.

[0054] For percentage-based metrics such as processor utilization, memory usage, and network bandwidth utilization, their original values ​​are already within the range of 0% to 100%, and the standardization formula is the original value divided by 100. For count-based metrics such as task queue length, a reference maximum value, Queue_max, needs to be set. The standardization formula is the current queue length divided by the reference maximum value. When the queue length exceeds the reference maximum value, the standardized value is truncated to 1.0. The reference maximum value is set according to the processing capacity of the edge computing node, with a typical value of 50 to 200. For continuous metrics such as instantaneous power consumption, a reference maximum power consumption, Power_max, also needs to be set. The standardization formula is the current power consumption divided by the reference maximum power consumption. The reference maximum power consumption is set to the node's thermal design power (TDP) value.

[0055] As one implementation method of this embodiment, the standardized resource index is referred to as the standardized processor utilization. Standardized memory usage Standardized uplink network bandwidth utilization Standardized downlink network bandwidth utilization Standardized task queue length and standardized instantaneous power consumption The values ​​range from 0 to 1. The larger the value, the higher the load or consumption of the resource and the lower the availability.

[0056] S103. Resource availability quantification;

[0057] Based on standardized multi-dimensional resource indicators, a weighted comprehensive scoring method is used to calculate the resource availability score of each edge computing node. This score comprehensively reflects the node's current overall resource availability and task carrying capacity.

[0058] A weighted summation model is used to comprehensively evaluate the standardized resource indicators, with weight coefficients reflecting the importance of different resource indicators to the node's task carrying capacity. The formula for calculating resource availability score is:

[0059] ;

[0060] In the formula: Availability is the resource availability score of the edge computing node, with a value ranging from 0 to 1. The larger the value, the higher the resource availability. This is a dimensionless parameter representing the weighting coefficient for processor utilization. The standardized processor utilization is a dimensionless parameter with a value range of 0 to 1. This is a dimensionless parameter representing the weighting coefficient for memory usage. This is the standardized memory usage rate, a dimensionless parameter with a value range of 0 to 1. This is a dimensionless parameter representing the weighting coefficient for network bandwidth utilization. and These are the standardized uplink and downlink network bandwidth utilization rates, respectively. They are dimensionless parameters with values ​​ranging from 0 to 1.

[0061] The weighting coefficient for the task queue length is a dimensionless parameter. The standardized task queue length is a dimensionless parameter with a value range of 0 to 1. The weighting coefficient for power consumption state is a dimensionless parameter. The standardized instantaneous power consumption is a dimensionless parameter with a value ranging from 0 to 1.

[0062] As one implementation method of this embodiment, the weight coefficient is set based on the typical characteristics of edge computing tasks and resource bottleneck analysis, and the preset default weight configuration is as follows: =0.35、 =0.25、 =0.20、 =0.15、 =0.05, the sum of the five weight coefficients equals 1.0, which satisfies the normalization condition.

[0063] It's worth noting that processor utilization is assigned the highest weight of 0.35 because most edge computing tasks are computationally intensive, and processor performance is the primary bottleneck. Memory utilization is weighted at 0.25, reflecting the constraint of memory resources on task concurrency. Network bandwidth utilization is weighted at 0.20, considering that task offloading involves data transmission, and network conditions directly affect offloading efficiency. Task queue length is weighted at 0.15, reflecting the current load queuing status of nodes. Power consumption status is weighted relatively low at 0.05, primarily used to prioritize low-power nodes when resources are sufficient, achieving energy conservation. This weighting configuration strikes a balance between computational performance and energy efficiency, suitable for general edge computing scenarios. For specific application scenarios, the weighting configuration can be adjusted according to actual needs; for example, for network-intensive applications, it can be increased... The value can be increased for energy-sensitive applications. The value of .

[0064] As one implementation method of this embodiment, the calculated resource availability score, along with the node identifier, timestamp, and original resource indicator data, is encapsulated into a node state vector; this state vector is pushed to step S200 through a message queue for task feature extraction and computational complexity prediction; this state vector is then pushed to step S300 through a message queue for multi-objective optimization task unloading decision generation.

[0065] It should be noted that the edge cluster controller maintains a state vector cache for all edge computing nodes. The cache is stored in a time-series database, retaining historical state data for the most recent 30 minutes for trend analysis and prediction. When the resource availability score of a node continues to decline or fluctuates drastically, the system will generate a resource alert to prompt the administrator to pay attention to the health status of that node.

[0066] Step S200: Task feature extraction and computational complexity prediction;

[0067] The node state vector output in step S100 is received, and feature extraction and computational complexity prediction are performed. By analyzing the task's code features, input data scale, historical execution records, and other information, the task's computational resource requirements, execution time, and network transmission overhead are estimated to obtain the task feature vector, providing a quantitative basis for subsequent task unloading decisions.

[0068] In this embodiment, the task feature extraction and computational complexity prediction steps include S201 task static feature extraction, S202 task dynamic feature acquisition, and S203 complexity prediction based on machine learning.

[0069] S201, Task Static Feature Extraction;

[0070] Extract statically analyzable features from the source code, compilation artifacts, or container images of the task. These features include the number of lines of code, the depth of nested loops, the complexity of the function call graph, data dependencies, and the degree of parallelism.

[0071] As one implementation method of this embodiment, static code analysis is used to parse the task program and extract structured features reflecting computational complexity. For tasks submitted in a container format, the system first decompresses the container image and locates the executable file and dependent libraries; for tasks submitted in source code format, the system calls the syntax parser of the corresponding programming language to construct an abstract syntax tree (AST). Based on the AST, the following static features are extracted:

[0072] Code size characteristics, including total lines of code, number of functions, and average function length;

[0073] Loop structure characteristics include the total number of loop statements, the maximum nesting depth of loops, and the average size of the loop body;

[0074] Data structure characteristics, including array dimension, total array size, and data type complexity;

[0075] Parallelism characteristics include the proportion of parallelizable loops and the number of threads.

[0076] It should be noted that these static features characterize the computational complexity of the task from different dimensions, providing input features for subsequent machine learning prediction models.

[0077] S202, Task dynamic feature acquisition;

[0078] The runtime characteristics and execution history of the data acquisition task include the size of the input data, the distribution of input data characteristics, the historical average execution time, and the historical resource consumption statistics.

[0079] As one implementation method of this embodiment, historical execution records of the task or similar tasks are retrieved from the historical execution log database of the task scheduling system, and resource consumption indicators such as average CPU time, peak memory usage, and network data transmission volume are statistically analyzed. For newly submitted tasks, the system matches historical statistical data of similar tasks based on task category tags as a reference. The input data size is obtained by reading the size of the task input file, in MB; the input data feature distribution is obtained by sampling and analyzing the statistical characteristics of the input data, such as analyzing the resolution and color complexity of images for image processing tasks, and analyzing the dimensionality and sparsity of datasets for data analysis tasks. Dynamic features can reflect the resource requirements of the task during actual operation and have higher prediction accuracy than static features, but for new tasks, there may be insufficient historical data, so it is necessary to combine static features for comprehensive prediction.

[0080] S203, Complexity prediction based on machine learning;

[0081] An ensemble learning approach is adopted to comprehensively utilize the static and dynamic features of a task to predict its execution time, CPU utilization, memory requirements, and network transmission overhead in a standard computing environment.

[0082] In this embodiment, step S203 employs the Gradient Boosting Decision Tree (GBDT) algorithm to construct the prediction model. This algorithm, by integrating multiple weak decision tree learners, can effectively capture the nonlinear relationships and interactions between features, exhibiting high prediction accuracy for regression tasks such as computational complexity prediction. The training data for the prediction model comes from historical task execution records. Each training sample contains the task's static feature vector, dynamic feature vector, and target variables such as actual measured execution time and resource consumption. Model training uses an offline batch processing method, retraining the model weekly using the latest historical data to adapt to the evolution of task feature distribution. The trained model is stored in serialized form and loaded for real-time inference on newly submitted tasks during online prediction.

[0083] As one implementation method of this embodiment, the prediction model outputs four key indicators: predicted execution time, predicted CPU utilization, predicted memory requirements, and predicted network data transmission volume.

[0084] The predicted execution time represents the expected execution time of the task on a standard edge computing node (configured with 4 CPU cores and 8GB of memory), in seconds.

[0085] Predicted CPU utilization represents the average CPU utilization during task execution, expressed as a percentage.

[0086] Predicted memory requirements represent the peak memory needed for task execution, measured in GB; predicted network data transfer volume represents the total amount of data transferred from task input to output, measured in MB.

[0087] As one implementation method of this embodiment, considering the differences in execution time of tasks on edge computing nodes with different performance levels, it is necessary to perform node performance correction on the predicted execution time. The correction formula is:

[0088] ;

[0089] in, Let be the expected execution time of the task on the i-th edge computing node, where i is the unique number of the edge computing node. Predicted execution time on the standard reference node; where The performance benchmark score for the standard reference node. This represents the performance benchmark score of the i-th edge computing node.

[0090] It should be noted that the performance benchmark score is obtained by running a standard test suite and comprehensively reflects the node's processor performance, memory performance, and I / O performance. The higher the score, the stronger the performance.

[0091] It's important to further explain that the introduction of performance benchmark scores allows task execution time prediction to adapt to the performance differences among heterogeneous edge computing nodes. In real-world edge computing environments, the hardware configurations of different nodes can vary significantly, ranging from low-performance embedded devices to high-performance edge servers, with performance differences potentially several times or even tens of times. By performing performance benchmark tests on each node and recording the benchmark scores, the system can dynamically adjust the predicted task execution time based on node performance, improving prediction accuracy. The performance benchmark test is performed once when a node is initially connected to the system and is retested when the node's hardware configuration changes or performance degrades.

[0092] In one implementation of this embodiment, the predicted task complexity features are encapsulated into a task feature vector. This vector includes the following fields: unique task identifier, submission timestamp, predicted execution time, predicted CPU utilization, predicted memory requirements, predicted network data transmission volume, task priority, and task deadline. The task feature vector is passed to step S300 via a message queue to generate a multi-objective optimized task unloading decision, serving as the input parameters for the unloading decision optimization.

[0093] Step S300: Generation of multi-objective optimization task unloading decision;

[0094] Based on the edge computing node status information obtained in step S100 and the task complexity characteristics obtained in step S200, an optimal task offloading decision is generated through a multi-objective optimization algorithm. This decision determines whether each task should be executed on a local edge computing node, offloaded to a nearby edge computing node, or offloaded to the cloud, and selects a specific target node. The optimization objectives include minimizing task completion time, minimizing total system energy consumption, maximizing resource utilization, and meeting task deadline constraints.

[0095] In this embodiment, the multi-objective optimization task unloading decision generation step includes S301 decision space construction, S302 multi-objective optimization solution and S303 decision execution.

[0096] S301, Construction of Decision Space;

[0097] Construct a feasible solution space for task offloading decisions, enumerate all feasible offloading options for each task, including local execution, offloading to a nearby edge computing node, and offloading to the cloud, and calculate the cost metric for each option.

[0098] As one implementation of this embodiment, the currently available computing resource pool is identified, including the local edge computing node submitting the task, neighboring edge computing nodes connected via a low-latency network, and cloud data centers connected via a wide area network. For the j-th task, its feasible offloading option set is denoted as Optionsj={local, edge1, edge2, ..., edgeN, cloud}, where local indicates local execution, edgeN indicates offloading to the Nth neighboring edge computing node for execution, cloud indicates offloading to the cloud for execution, and N is the number of neighboring edge computing nodes. For each offloading option, three key cost metrics are calculated: execution time cost Tcost, energy consumption cost Ecost, and economic cost Ccost.

[0099] As one implementation method of this embodiment, the execution time cost of the local execution option is equal to the expected execution time of the task on the local node, and the energy consumption cost is equal to the expected energy consumption of the local node during task execution, with an economic cost of zero. The execution time cost of offloading to a nearby edge computing node includes three parts: data upload time, remote execution time, and result download time.

[0100] The calculation process for the total execution time cost of offloading to the k-th edge computing node is as follows: divide the predicted network transmission data volume of the task by the uplink bandwidth of the local node to obtain result one; record the expected execution time on the k-th edge computing node as result two; divide the size of the task result data by the downlink bandwidth of the local node to obtain result three; sum result one, result two, and result three to obtain the total execution time cost of offloading to the k-th edge computing node, in seconds;

[0101] As one implementation of this embodiment, the energy consumption cost offloaded to the edge computing node includes the data transmission energy consumption of the local node and the computing energy consumption of the remote node. The calculation process is as follows: add result one to result three to obtain result four; multiply result four by the average power of network transmission of the local node to obtain result five; multiply result two by the average power of computation and execution of the k-th edge computing node to obtain result six; sum result four and result six to obtain the total energy consumption cost offloaded to the k-th edge computing node, in joules.

[0102] As one implementation method of this embodiment, the calculation method for execution time and energy consumption costs of offloading to the cloud is similar to that of offloading to edge computing nodes. The difference lies in the higher network transmission latency and potentially lower bandwidth, but the computing power of the cloud is usually stronger, and the execution time may be shorter. Cloud offloading also involves economic costs, calculated according to the billing standards of cloud service providers, including computing resource costs, storage costs, and network traffic costs.

[0103] As one implementation method in this embodiment, resource availability constraints also need to be considered when constructing the feasible solution space. If the resource availability score of an edge computing node is lower than a preset threshold of 0.2, or the task queue length exceeds the capacity limit, then that node is not considered a feasible offloading target; if the predicted memory requirement of a task exceeds the available memory of the target node, that node is also infeasible; if the task has a deadline constraint, options with expected completion times exceeding the deadline are also infeasible. After feasibility screening, the number of feasible options for each task may be less than the total number of candidate resource pools.

[0104] S302, Multi-objective optimization solution;

[0105] An improved non-dominated sorting genetic algorithm, NSGA-II, is used to solve the multi-objective optimization problem of task unloading decision-making, seeking a Pareto optimal solution among the three objectives of minimizing the total system completion time, minimizing the total system energy consumption, and maximizing resource utilization.

[0106] In one implementation of this embodiment, the task offloading decision problem is modeled as a multi-objective optimization problem. The decision variable is the selection of the offloading target node for each task. The optimization objectives include three aspects: the first objective is to minimize the maximum completion time (makespan) of all tasks, i.e., the total time the system takes to execute all tasks; the second objective is to minimize the total system energy consumption, i.e., the total energy consumed by all nodes in executing tasks and transmitting data; and the third objective is to maximize the resource utilization of edge computing nodes, avoiding resource idleness and waste. These three objectives often conflict. For example, shortening the completion time may require using high-performance but high-power nodes, while reducing energy consumption may require selecting low-power but weaker nodes, leading to a longer completion time. The multi-objective optimization method can find a trade-off balance among these conflicting objectives, generating a set of Pareto optimal solutions for the decision-maker to choose from.

[0107] As one implementation method of this embodiment, the NSGA-II algorithm adopts a genetic algorithm framework, iteratively evolving the population through selection, crossover, and mutation operations, and maintaining solution diversity using non-dominated sorting and crowding distance mechanisms. The population size is set to 100, the number of generations to 50, the crossover probability to 0.9, and the mutation probability to 0.1. Chromosome encoding is integer-based, with chromosome length equal to the number of tasks. The j-th gene position on the chromosome represents the unloading target node number of the j-th task, and the gene value range is the set of feasible options for that task.

[0108] As one implementation of this embodiment, the first objective function of the optimization algorithm, makespan, is calculated as the maximum time for all nodes to complete their assigned tasks; the second objective function, total energy consumption, is calculated as the sum of the energy consumption of all nodes; and the third objective function, resource utilization, is calculated as the average load rate of all edge computing nodes.

[0109] It should be noted that after the NSGA-II algorithm completes, it yields a set of Pareto optimal solutions. These solutions are independent of each other across the three objectives; that is, no single solution is superior to another in all objectives. There are various strategies for selecting the final execution plan from the Pareto solution set. This embodiment uses a weighted summation method, calculating the comprehensive score of each solution based on the objective weights configured by the system administrator, and selecting the solution with the highest score as the final decision. A typical weight configuration is: completion time weight 0.5, energy consumption weight 0.3, and resource utilization weight 0.2. This configuration is suitable for latency-sensitive applications. For energy-sensitive scenarios, the energy consumption weight can be increased to 0.5 or higher.

[0110] S303, Decision Implementation;

[0111] The unloading decisions generated by the optimization algorithm are transformed into specific task scheduling instructions and distributed to relevant edge computing nodes and cloud resource pools for execution.

[0112] As one implementation method of this embodiment, a task scheduling instruction is generated for each task according to the offloading decision scheme. The instruction includes information such as task identifier, target node identifier, task priority, and resource reservation quota. For tasks executed locally, the scheduling instruction is sent to the task scheduler of the local node and added to the local execution queue. For tasks offloaded to nearby edge computing nodes, resource quota is first reserved on the target node, and then the task code and input data are transmitted over the network. After the transmission is completed, the execution instruction is sent to the target node.

[0113] As one implementation method of this embodiment, the task execution status is monitored. If the task execution fails or times out, a rescheduling mechanism is triggered to regenerate the unloading decision and re-execute it.

[0114] As one implementation of this embodiment, for a task that is selected to be executed locally or by an edge computing node, a power consumption control request is sent to the power consumption control step of dynamic voltage and frequency adjustment in step S400. The request includes the performance requirements and energy consumption constraints of the task, triggering the target node to perform dynamic voltage and frequency adjustment to reduce the node power consumption while meeting the task performance requirements.

[0115] Step S400: Power consumption control of dynamic voltage frequency adjustment;

[0116] Dynamic voltage and frequency adjustment is performed on the edge computing nodes. Based on the task offloading decision and task performance requirements generated in step S300, the processor's operating voltage and clock frequency are dynamically adjusted to minimize node power consumption while meeting task completion time constraints, thus achieving low-power operation of the edge computing nodes. This step receives the power control request transmitted in step S300, outputs the processor frequency adjustment instruction to the node hardware layer, and feeds back the actual power consumption status of the node to step S100 for the next round of resource monitoring.

[0117] In this embodiment, the power consumption control steps of dynamic voltage and frequency regulation include S401 task relaxation time calculation, S402 frequency-voltage level selection, and S403 power consumption control instruction execution.

[0118] S401, Calculation of task slack time;

[0119] Calculate the available relaxation time for tasks assigned to edge computing nodes, which is the maximum time margin that task execution can be extended while meeting task deadline constraints;

[0120] In one implementation of this embodiment, a task scheduling instruction transmitted in step S300 is received, which includes the task's deadline and expected execution time. The relaxation time is defined as the deadline minus the current time and then minus the expected execution time, i.e., the time margin between the task completion time and the deadline. The existence of the relaxation time provides room for reducing the processor frequency, because reducing the frequency will prolong the execution time. However, as long as the prolonged execution time still meets the deadline constraint, power consumption can be reduced without affecting the task's timeliness. The larger the relaxation time, the greater the potential for frequency reduction and the higher the energy-saving potential.

[0121] As one implementation method of this embodiment, for background tasks without explicit deadline constraints, the system sets a relatively lenient default deadline, such as twice the expected execution time, in order to make full use of energy-saving opportunities.

[0122] As one implementation method of this embodiment, the relaxation time is calculated by subtracting the current time from the task's deadline, and then subtracting the expected execution time of the task at the current processor frequency.

[0123] S402, Frequency-Voltage Level Selection;

[0124] Based on the calculated relaxation time, a suitable operating point is selected from the discrete frequency-voltage levels supported by the processor so that the execution time of the task still meets the deadline constraint after the frequency is reduced, while minimizing energy consumption.

[0125] It's important to note that modern processors typically support multiple discrete frequency-voltage levels, known as P-states, ranging from the highest-performance P0 state to the lowest-power Pn state. Each P-state corresponds to a specific set of clock frequencies f and supply voltages V; higher frequencies result in higher voltages, stronger performance, but also higher power consumption.

[0126] It should be further explained that, according to the power consumption model of CMOS circuits, power consumption is directly proportional to the square of the voltage and the frequency. Therefore, reducing both voltage and frequency can significantly reduce power consumption. At the same time, task execution time is inversely proportional to processor frequency; lowering the frequency will lead to longer execution time. Therefore, the selection of frequency-voltage levels requires finding the optimal operating point within this performance-power consumption tradeoff.

[0127] As one implementation method of this embodiment, all P-state levels supported by the processor are traversed, and for each level, the expected execution time of the task at that frequency is calculated. The calculation process is as follows: multiply the expected execution time of the task at each preset frequency level by the clock frequency of the highest frequency level, and divide by the clock frequency of that preset frequency level to obtain the expected execution time of the task at that preset frequency level.

[0128] As one implementation of this embodiment, it is further determined whether the preset frequency level meets the deadline constraint. If it is identified that the sum of the expected execution time of the task at the preset frequency level and the current time is less than the task's deadline, then the preset frequency level is determined to meet the deadline constraint. The lowest frequency level is selected from all preset frequency levels that meet the deadline constraint. If none of the frequency levels meet the deadline constraint, the highest frequency level P0 is selected, and a task timeout risk warning is generated.

[0129] S403, Power consumption control instruction execution;

[0130] The selected frequency-voltage level is translated into specific hardware control instructions, and the processor's DVFS mechanism is invoked through the operating system's power management interface to achieve dynamic switching of the processor's operating point.

[0131] In one implementation of this embodiment, the CPUFreq subsystem interface of the Linux operating system is invoked to send a frequency adjustment request to the processor's power management unit (PMU). Modern x86 processors support setting the target frequency and voltage by writing to specific model-specific registers (MSRs), while ARM processors control this through the device tree and runtime power management interface. Frequency switching typically occurs in microseconds, during which the processor briefly pauses execution; therefore, frequent switching incurs performance overhead. This embodiment employs a task-granular frequency adjustment strategy: setting an appropriate frequency level before a task begins execution, maintaining that frequency during task execution, and readjusting the frequency based on the needs of the next task after completion. This strategy strikes a balance between energy saving and switching overhead.

[0132] As one implementation method in this embodiment, for multi-core processors, different processor cores can be independently configured with frequency-voltage levels to achieve finer-grained power consumption control. If multiple tasks run in parallel on different cores, the system calculates the optimal frequency level for each core, ensuring that each core operates at the lowest possible frequency while meeting the performance requirements of its running task. This per-core DVFS strategy has higher energy-saving potential compared to traditional overall adjustment strategies, but it requires processor hardware support and operating system cooperation.

[0133] As one implementation of this embodiment, after frequency adjustment is completed, the actual power consumption change of the monitoring node is monitored, and the updated power consumption status data is fed back to the resource monitoring step in step S100 to update the power consumption normalization value and resource availability score of the node, forming a closed-loop feedback control.

[0134] It should be further explained that the dynamic voltage and frequency adjustment mechanism implemented in this step is a key technical means for low-power operation of edge computing nodes. Experimental data shows that compared with fixed operation at the highest frequency, adopting an adaptive frequency adjustment strategy based on relaxation time can reduce the energy consumption of edge computing nodes by 15% to 40%, with the specific energy saving depending on the tightness of the task's time constraints and load characteristics. For background tasks with looser time constraints, the energy saving effect is more significant; for tasks with strict real-time requirements, the energy saving potential is limited. By working in conjunction with the intelligent task scheduling in step S30O, the system can prioritize scheduling tasks with looser time constraints to low-power nodes and tasks with stricter time constraints to high-performance nodes, achieving system-level energy efficiency optimization.

[0135] It should be understood that the terms “comprising” and “including” used in this disclosure and claims indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0136] It should also be understood that the terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used in this disclosure and claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this disclosure and claims means any combination and all possible combinations of one or more of the associated listed items, and includes such combinations;

[0137] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to specific implementations. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. An edge-cloud collaborative computing power scheduling architecture and low-power management method, characterized in that, Includes the following steps: Step S100: Real-time monitoring and status quantification of edge computing node computing resources; Real-time monitoring of computing resources of distributed edge computing nodes is performed, and heterogeneous indicators are collected; these heterogeneous indicators are then quantified into a unified resource availability score through standardized processing. Step S200: Task feature extraction and computational complexity prediction; By analyzing information such as the task's code characteristics, input data size, and historical execution records, the task's computing resource requirements, execution time, and network transmission overhead are estimated to obtain the task feature vector. Step S300: Generation of multi-objective optimization task unloading decision; Based on edge computing node status information and task complexity characteristics, a multi-objective optimization algorithm is used to generate the optimal task offloading decision, which determines whether each task is executed on a local edge computing node, offloaded to a nearby edge computing node, or offloaded to the cloud for execution. Step S400: Power consumption control of dynamic voltage frequency adjustment; Dynamic voltage and frequency adjustment is performed on edge computing nodes. Based on task offloading decisions and task performance requirements, the operating voltage and clock frequency of the processor are dynamically adjusted to minimize node energy consumption while meeting task completion time constraints.

2. The edge-cloud collaborative computing power scheduling architecture and low-power management method according to claim 1, characterized in that, The specific process for collecting heterogeneous metrics is as follows: Deploy a lightweight monitoring agent on each edge computing node to collect a snapshot of resource metrics every 500 milliseconds, including processor utilization, memory usage, network bandwidth utilization, task queue length, and instantaneous power consumption. The collected multi-dimensional resource indicators are standardized, and the maximum-minimum normalization method is used to map each indicator to a standard range of 0 to 1. For percentage-based metrics, the standardization formula is the original value divided by 100; for count-based metrics such as task queue length, the standardization formula is the current value divided by the reference maximum value; for continuous metrics such as power consumption, the standardization formula is the current value divided by the reference maximum power consumption. Based on standardized multi-dimensional resource metrics, a weighted comprehensive scoring method is used to calculate the resource availability score of each edge computing node.

3. The edge-cloud collaborative computing power scheduling architecture and low-power management method according to claim 2, characterized in that, The specific process for calculating the resource availability score of each edge computing node using the weighted comprehensive scoring method is as follows: A weighted summation model is adopted, with weight coefficients reflecting the importance of different resource indicators to the node's task carrying capacity. The preset default weight configuration is as follows: processor utilization weight 0.35, memory utilization weight 0.25, network bandwidth utilization weight 0.20, task queue length weight 0.15, and power consumption status weight 0.

05. The sum of the five weight coefficients equals 1.

0. The calculated resource availability score, together with the node identifier, timestamp, and original resource indicator data, is encapsulated into a node state vector.

4. The edge-cloud collaborative computing power scheduling architecture and low-power management method according to claim 1, characterized in that, The specific process for estimating the computational resource requirements, execution time, and network transmission overhead of a task is as follows: Extract static features from the source code, compilation artifacts, or container image of the task, including code size features, loop structure features, data structure features, and parallelism features. The system collects runtime characteristics and execution history of tasks, including input data size, input data feature distribution, historical average execution time, and historical resource consumption statistics; it retrieves historical execution records of the task or similar tasks from the historical execution log database of the task scheduling system, and statistically analyzes the historical average CPU time, peak memory usage, and network data transmission volume. A prediction model is constructed using the Gradient Boosting Decision Tree (GBDT) algorithm, which comprehensively utilizes the static and dynamic features of the task to predict the execution time, CPU utilization, memory requirements, and network data transmission volume of the task in a standard computing environment; the training data for the prediction model comes from historical task execution records. Perform node performance correction on the predicted execution time; The performance benchmark score is obtained by running a standard test suite, which comprehensively reflects the node's processor performance, memory performance, and I / O performance. The predicted task complexity features are encapsulated into a task feature vector, which includes a unique task identifier, submission timestamp, predicted execution time, predicted CPU utilization, predicted memory requirements, predicted network data transfer volume, task priority, and task deadline.

5. The edge-cloud collaborative computing power scheduling architecture and low-power management method according to claim 1, characterized in that, The specific process of generating the optimal task unloading decision using a multi-objective optimization algorithm is as follows: Construct a feasible solution space for task offloading decisions, enumerate all feasible offloading options for each task, and calculate the execution time cost, energy cost, and economic cost for each option. The execution time cost of the local execution option is equal to the expected execution time of the task on the local node, and the energy cost is equal to the expected energy consumption of the local node during task execution. The execution time cost of offloading to a nearby edge computing node includes data upload time, remote execution time, and result download time. The calculation method for the execution time cost and energy cost of offloading to the cloud is similar to that of offloading to an edge computing node. Cloud offloading also involves economic costs, which are calculated according to the billing standards of the cloud service provider. Solving multi-objective optimization problems based on machine learning algorithms.

6. The edge-cloud collaborative computing power scheduling architecture and low-power management method according to claim 1, characterized in that, The specific process of solving multi-objective optimization problems based on machine learning algorithms is as follows: An improved non-dominated sorting genetic algorithm, NSGA-II, is used to solve the multi-objective optimization problem of task unloading decision-making. The optimization objectives include: minimizing the maximum completion time of all tasks, minimizing the total system energy consumption, and maximizing the resource utilization of edge computing nodes. The NSGA-II algorithm adopts a genetic algorithm framework with a population size of 100, an evolutionary number of 50 generations, a crossover probability of 0.9, and a mutation probability of 0.

1. Chromosome encoding is performed using integer encoding, where the j-th gene position of the chromosome represents the unloading target node number of the j-th task. After the algorithm runs, a set of Pareto optimal solutions is obtained, and a weighted summation method is used to select the final execution scheme from them.

7. The edge-cloud collaborative computing power scheduling architecture and low-power management method according to claim 6, characterized in that: The offloading decision generated by the optimization algorithm is transformed into specific task scheduling instructions and distributed to relevant edge computing nodes and cloud resource pools for execution. For tasks that choose to be executed locally or on edge computing nodes, a power control request is sent to the power control step to trigger the target node to perform dynamic voltage and frequency adjustment.

8. The edge-cloud collaborative computing power scheduling architecture and low-power management method according to claim 1, characterized in that, The specific process of dynamically adjusting the processor's operating voltage and clock frequency based on task offloading decisions and task performance requirements is as follows: Calculate the available relaxation time for tasks assigned to edge computing nodes. The relaxation time is defined as the deadline minus the current time and then minus the expected execution time. Based on the calculated relaxation time, a suitable operating point is selected from the discrete frequency-voltage levels supported by the processor; all P-state levels supported by the processor are traversed, and for each level, the expected execution time of the task at that frequency is calculated to determine whether the deadline constraint is met; the lowest frequency level is selected from all preset frequency levels that meet the deadline constraint.

9. The edge-cloud collaborative computing power scheduling architecture and low-power management method according to claim 1, characterized in that, The specific process of dynamically adjusting the processor's operating voltage and clock frequency is as follows: The selected frequency-voltage level is translated into specific hardware control instructions, and the processor's DVFS mechanism is invoked through the operating system's power management interface to achieve dynamic switching of the processor's operating point. This embodiment adopts a task-granular frequency adjustment strategy, that is, a suitable frequency level is set before the task starts execution and the frequency remains unchanged during the task execution. For multi-core processors, different processor cores can independently set the frequency-voltage level. After the frequency adjustment is completed, the updated power consumption status data is fed back to the resource monitoring step to form a closed-loop feedback control.

Images