Fine-grained power task cloud edge collaboration optimization scheduling method

Abstract

The application discloses a fine-grained power task cloud edge collaborative optimization scheduling method, and belongs to the technical field of power distribution Internet of Things edge computing.The method comprises the following steps: step a, arranging an edge computing network scene; step b, establishing a task model and determining task information; step c, considering a micro-service processing model of service configuration; step d, calculating micro-service time delay and energy consumption; step e, establishing scheduling constraints and target numbers; step f, designing a task scheduling algorithm based on NSGA-II; step g, calculating weights based on fuzzy logic; and step h, sorting all interfaces of the forefront.In the fine-grained power task cloud edge collaborative optimization scheduling method, micro-service execution constraints, task queuing, service configuration, device resources and task attributes are comprehensively considered, the task execution time and energy consumption are reduced, and the problem that single edge device resources are limited and it is difficult to realize local low-delay and low-energy-consumption processing of all tasks in the prior art is solved.

Description

Technical Field

[0001] A fine-grained cloud-edge collaborative optimization scheduling method for power tasks belongs to the field of edge computing technology for power distribution Internet of Things. Background Technology

[0002] Against the backdrop of new power system construction, emerging application scenarios such as distributed power supply access on the user side, intelligent charging and discharging of electric vehicles, and low-carbon buildings are driving a continuous increase in the types and quantities of services, highlighting the shortcomings of cloud computing in terms of real-time performance and energy consumption. Edge computing technology, an extension of cloud computing, migrates computing power from the centralized cloud to edge devices, enabling rapid and localized processing of power tasks and improving service quality.

[0003] Traditional cloud platforms deploy applications as monolithic units via virtual machines. Each application is a single entity requiring overall scheduling, resulting in poor flexibility and high time and energy costs. To address emerging business growth, edge devices employ microservice architecture and container technology to enable a single physical device to handle different business processes. The business composition at the edge of the power distribution network is complex, with various services having significantly different requirements for edge computing functionality and performance, necessitating reliance on diverse computing capabilities such as real-time computing, control response, and intelligent inference. Individual edge devices have limited resources, allowing only a limited number of services to be configured simultaneously, making it difficult to achieve low-latency and low-energy processing of all tasks locally. Therefore, designing a technical solution that leverages the independent operation of microservices for service configuration and task scheduling, fully utilizing cloud-edge resources, reducing task latency and system energy consumption, and improving task completion rates has become a pressing issue in this field. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to overcome the shortcomings of the prior art and provide a fine-grained cloud-edge collaborative optimization scheduling method for power tasks, which comprehensively considers microservice execution constraints, task queuing, service configuration, equipment resources and task attributes, thereby reducing task execution time and energy consumption.

[0005] The technical solution adopted by this invention to solve its technical problem is: a fine-grained cloud-edge collaborative optimization scheduling method for power tasks, characterized by the following steps:

[0006] Step a: Determine the number of edge devices and the cloud, configure communication between edge devices and the cloud, and create containers and devices;

[0007] Step b: Establish the task model and determine the task information;

[0008] Step c, consider the microservice processing model for service configuration;

[0009] Step d: Calculation of microservice latency and energy consumption;

[0010] Step e: Establishing scheduling constraints and target number;

[0011] Step f, Design of a task scheduling algorithm based on NSGA-II;

[0012] Step g: Weight calculation based on fuzzy logic;

[0013] Step h involves sorting all solutions at the optimal frontier using the approximation-ideal-solution sorting method, calculating the score for each scheme, and selecting the scheduling scheme corresponding to the maximum score as the task scheduling scheme.

[0014] Preferably, step b includes the following steps:

[0015] Step b-1: The fine-grained power task based on microservices is modeled using a directed acyclic graph, denoted as Q. u ={A u B u G u},in: B is a set of nodes in a graph, where each node represents a microservice invoked by a task. u Let G be the set of directed edges in a graph, where directed edges represent dependencies between microservices. Based on the dependencies between two microservices, the microservice that transmits data is called the front-end microservice, and the microservice that receives data is called the back-end microservice. u The collection of data transferred between microservices;

[0016] Step 2-2, Task Topology Modification: The microservice without any preceding microservices is called the entry microservice, and the microservice without any following microservices is called the exit microservice. A virtual entry microservice is added that does not consume any time or resources. With virtual exit microservices It is stipulated that the two virtual microservices will not participate in scheduling, and the graph structure is modified as follows:

[0017]

[0018] Steps 2-3, the set of power tasks is represented as R = {r1, r2, r3, ..., r...} u ,...}, each task r u There are four basic pieces of information, denoted as r. u ={t u ,y u ,v u Q u},

[0019] Among them, t u Represents task r u Arrival time, y uRepresents task r u The latency, that is, the task needs to be performed in y u Processing completed within the specified time, v u Represents task r u The type value is used to distinguish between routine tasks, alarm tasks, and fault handling tasks.

[0020] Preferably, step g includes the following steps:

[0021] Step 8-1: Fuzzification, determining the membership degree of each variable using the triangular membership function;

[0022] Step 8-2, Fuzzy Reasoning: Based on the fuzzy rules, derive the corresponding fuzzy variables for defuzzification;

[0023] Step 8-3, Defuzzification: The centroid method is used to calculate the defuzzification of the inferred fuzzy variables. The calculation formula is as follows:

[0024]

[0025] Where x is an input or output variable, f(x) is the membership degree obtained in step 8-1, and the task's time delay weight Y is calculated. u ,1-Y u This represents the energy consumption weight of the task.

[0026] Preferably, in step 8-1, the membership degree of each variable is determined using a triangular membership function, the calculation formula of which is:

[0027]

[0028] Where x is an input or output variable, α, β, γ are given real numbers that depend on the task parameters, and α < β < γ. In the task information, latency, task type value, and input data volume have a significant impact on latency weight. Therefore, these are used as inputs and outputs as the latency weight of the task. Low, medium, and high are used as linguistic variables for latency and input data volume, normal, alarm, and fault are used as linguistic variables for task type value, and very low, low, medium, high, and very high are used as linguistic variables for latency weight.

[0029] Preferably, in step c, a map() function is defined to represent the mapping between microservices and containers, for any a∈A all and c∈C all map(a) = c represents that microservice a is processed by container c, where A all It is the collection of all microservices, C all It is a collection of all business containers. The operation and deployment of containers in the device are also dynamic. Microservice 'a' is assigned to device 'd'. nThere are three possible scenarios during processing:

[0030] Case 1: Equipment d n A container c is configured for the microservice. If this container is processing other microservices of the same type, microservice a needs to enter the container's waiting queue to wait for execution. If the container is idle, microservice a can be executed immediately.

[0031] Scenario 2: The device is not configured with container c and |P n |<N n It is necessary to download the required container image file from the cloud and then put it into operation to process microservice a;

[0032] Scenario 3: Equipment d n No container c is configured and |P n |=N n Then the container list P needs to be... n Replace one of the containers in the list P, and remove the replaced container from the container list P. n Remove and then add a newly configured container to handle microservice a.

[0033] Preferably, in step d, the calculation of microservice latency includes the execution time of the microservice, the data transmission time between microservices, and the waiting time of the microservice; the calculation of microservice energy consumption includes the energy consumption of microservice execution and the energy consumption of data transmission.

[0034] Preferably, the microservice execution time is:

[0035]

[0036] in, For device d n Container c i To meet computing resource constraints, the processing speed... Indicates the execution of microservices Number of CPU cycles required microservices The amount of data to be processed, l represents the number of CPU cycles required to process a unit of data, H n The number of containers running concurrently on the device, any H n The sum of the processing speeds of all containers will not exceed the processing speed of the device, H n ≤|P n |;

[0037] The data transfer time between two dependent microservices is:

[0038]

[0039] In the formula: To implement microservices The device number, For equipment With d n Data transfer rate between For data transfer time between two dependent microservices;

[0040] microservices Assigned to device d n During execution, the microservice's wait time is:

[0041]

[0042] in, For microservices Assigned to device d n The earliest end time, It is device d n Container c i The tail microservice of the waiting queue, by task r k Call, and When container c i During free time, For container c i Image file size, s K,n Centralized cloud and devices n Data transfer rate between W n For device d n The collection of microservices at the tail of all container waiting queues For this set of microservices, task r t Call.

[0043] Preferably, the energy consumption for microservice execution is:

[0044]

[0045] Where, q n For device d n CPU energy efficiency coefficient For device d n Container c i Processing speed Indicates the execution of microservices Required number of CPU cycles;

[0046] Data transfer energy consumption includes the energy consumption of data transfer between dependent microservices:

[0047]

[0048] And the energy consumption of transferring image files:

[0049]

[0050] in, The equipment number is given within a unit of time. The data transmission power of the device; F K The data transmission power of the cloud per unit time. For equipment With d n Data transfer rate between, s K,n Centralized cloud and devices n Data transfer rate between For container c i Image file size, This refers to the data transfer time between two dependent microservices.

[0051] Compared with the prior art, the beneficial effects of this invention are:

[0052] 1. In this fine-grained cloud-edge collaborative optimization scheduling method for power tasks, microservice execution constraints, task queuing, service configuration, equipment resources, and task attributes are comprehensively considered, which reduces task execution time and energy consumption. It overcomes the problem that existing technologies have limited resources for a single edge device, which can only configure a limited number of services at the same time, making it difficult to achieve local low-latency and low-energy processing for all tasks.

[0053] 2. In this fine-grained cloud-edge collaborative optimization scheduling method for power tasks, the limited computing and storage resources of edge devices are considered simultaneously. The limitation of computing resources is reflected in the number of containers that the device can support for concurrent operation, and the limitation of storage resources is reflected in the number of containers that the device can be configured with. These two parameters can effectively simulate the operating status and resource conditions of edge devices in real-world scenarios.

[0054] 3. In this fine-grained cloud-edge collaborative optimization scheduling method for power tasks, service configuration is considered during the task allocation process, three cases of microservice processing are distinguished, and corresponding models are established. The models are highly representative and applicable.

[0055] 4. In this fine-grained cloud-edge collaborative optimization scheduling method for power tasks, the performance of the algorithm in terms of latency and energy consumption is simulated under three scenarios: normal operation, low fault occurrence, and high fault occurrence. The results show that for routine tasks, this invention tends to select scheduling schemes with low execution energy consumption, effectively reducing system energy consumption. For important tasks such as fault handling, this invention can make full use of system resources, ensure timely task processing, and reduce task latency.

[0056] 5. The task set of this fine-grained power task cloud-edge collaborative optimization scheduling method conforms to the parameter range of power tasks in the distribution IoT. Considering the three types of tasks—routine, alarm, and fault—it is highly representative, covers a wide range of task types and scenarios. Attached Figure Description

[0057] Figure 1 Flowchart of a cloud-edge collaborative optimization scheduling method for fine-grained power tasks.

[0058] Figure 2 System architecture diagram for a fine-grained cloud-edge collaborative optimization scheduling method for power tasks.

[0059] Figure 3 This is a real-world scenario illustration of a fine-grained cloud-edge collaborative optimization scheduling method for power tasks.

[0060] Figure 4 The graph shows the performance curves of the fine-grained power task cloud-edge collaborative optimization scheduling method in terms of latency under normal operating scenarios.

[0061] Figure 5 The graph shows the energy consumption performance of the fine-grained cloud-edge collaborative optimization scheduling method for power tasks under normal operating conditions.

[0062] Figure 6 The graph shows the performance of the fine-grained cloud-edge collaborative optimization scheduling method for power tasks in terms of latency in a low-fault scenario.

[0063] Figure 7 The graph shows the energy consumption performance of the fine-grained cloud-edge collaborative optimization scheduling method for power tasks in a low-fault scenario.

[0064] Figure 8 The graph shows the performance of the fine-grained cloud-edge collaborative optimization scheduling method for power tasks in terms of latency under high-fault scenarios.

[0065] Figure 9 The graph shows the energy consumption performance of the fine-grained cloud-edge collaborative optimization scheduling method for power tasks in high-fault scenarios. Detailed Implementation

[0066] Figures 1-9 This is the preferred embodiment of the present invention, which is described below in conjunction with the accompanying drawings. Figures 1-9 The present invention will be further described below.

[0067] like Figure 1 As shown, a fine-grained cloud-edge collaborative optimization scheduling method for power tasks includes the following steps:

[0068] Step 1: Deploy the edge computing network scenario;

[0069] Includes the following steps:

[0070] Step 1-1, Determine the number of edge devices and cloud devices: The set of edge devices and cloud devices in the system can be represented as D = {d1, d2, ..., d...} K}, where K is the total number of edge devices and cloud, and d K The central cloud is represented by one device, and the rest are edge devices.

[0071] Steps 1-2, Communication Settings: s m,n Indicates device d m With d n The data transfer rate between them, and assuming s m,n =s n,m Furthermore, when m = n, it indicates that data is transmitted within the same device. Compared to the communication time between devices, the communication time between containers within a device is negligible. Therefore, let s m,n =+∞. Considering that the communication time between the cloud and the edge will be longer than that between edges, the communication time between the edge device and the cloud is set to 1 / X times the communication time between edge devices, where X is greater than 1.

[0072] Steps 1-3, Container Creation: As the execution carrier of microservices, containers require the following information: a unique ID to distinguish different containers, the running microservice ID, the container image file size, remaining time, and processing speed.

[0073] Steps 1-4, Device Creation: Devices include edge devices and cloud devices. Information includes a unique ID to distinguish different devices and a list of containers. Edge device d n Due to limitations in computing and storage resources, the number of containers that can be configured simultaneously is finite, denoted as N. n Each side device d n Container list P n Used to record container deployment information. When the device d n The business container C needs to be configured. m At that time, the business container c m Add to container list P n |P n | Represents the number of service containers configured on the edge device at a given moment, |P n |≤N n There are ample cloud resources, including images of all containers.

[0074] Step 2: Establish the task model and determine the task information;

[0075] Includes the following steps:

[0076] Step 2-1, Task Model: Fine-grained power tasks based on microservices are modeled using a directed acyclic graph, denoted as Q. u ={Au B u G u},in: B is a set of nodes in a graph, where each node represents a microservice invoked by a task. u Let be the set of directed edges in the graph, where directed edges represent dependencies between microservices, such as directed edges. microservices The calculation results need to be transmitted to the microservice. Based on the dependency relationship between the two microservices, the microservice that transmits data is called the front-end microservice, and the microservice that receives data is called the back-end microservice. u A collection of data transferred between microservices, for example microservices microservices The amount of data transmitted between them

[0077] Step 2-2, Task Topology Modification: The microservice without any preceding microservices is called the entry microservice, and the microservice without any following microservices is called the exit microservice. To reflect the latency caused by the transmission of task input and result data to task scheduling, and considering the practical situation that both input and result data must reach the initial edge device, a virtual entry microservice is added that does not consume any time or resources. With virtual exit microservices It is stipulated that the two virtual microservices will not participate in scheduling. Therefore, the graph structure is modified as follows:

[0078] Steps 2-3, Task Information: The set of power tasks is represented as R = {r1, r2, r3, ..., r...} u ,...}. Each task r u There are four basic pieces of information, denoted as r. u ={t u ,y u ,v u Q u}, where t u Represents task r u Arrival time, y u Represents task r u The latency, that is, the task needs to be performed in y u Processing completed within the specified time. u Represents task r u The type value is used to distinguish between routine tasks, alarm tasks, and fault handling tasks.

[0079] Step 3, consider the microservice processing model for service configuration;

[0080] Each microservice invoked in the task is processed by its corresponding container. A `map()` function is defined to represent the mapping between microservices and containers. For any a∈A all and c∈C all map(a) = c represents that microservice a is processed by container c, where A all It is the collection of all microservices, C all It is a collection of all business containers.

[0081] The state of a container is changed by tasks. When no tasks are generated or the container has finished processing a task, it is in an idle state. When a task is triggered, the container enters a running state. Because the generation and allocation of tasks in the system are dynamic, the running and deployment of containers on the device are also dynamic. This leads to microservice 'a' being assigned to device 'd'. n There are three possible scenarios during processing:

[0082] Case 1: Equipment d n The container c required by this microservice is configured. If this container is processing other microservices of the same type, microservice a needs to enter the container's waiting queue to wait for execution. If the container is idle, microservice a can be executed immediately.

[0083] Scenario 2: The device is not configured with container c and |P n |<N n Then, it is necessary to download the required container image file from the cloud and then put it into operation to process microservice a.

[0084] Scenario 3: Equipment d n No container c is configured and |P n |=N n Then the container list P needs to be... n Replace one of the containers in the list P, and remove the replaced container from the container list P. n Remove and then add a newly configured container to handle microservice a.

[0085] Step 4, Calculation of microservice latency;

[0086] The calculation of microservice latency includes the following parts:

[0087] (1) Execution time of microservices;

[0088] The processing speed of the same service container generally varies across different devices, resulting in different execution times for the same microservice on different devices. Microservice execution time is:

[0089]

[0090] in, For device d nContainer c i To meet computing resource constraints, the processing speed... Indicates the execution of microservices Number of CPU cycles required microservices The amount of data to be processed, where l represents the number of CPU cycles required to process a unit of data. H n The number of containers running concurrently on the device, any H n The sum of the processing speeds of all containers will not exceed the processing speed of the device, H n ≤|P n |

[0091] (2) Data transfer time between microservices: The data transfer time between two dependent microservices is:

[0092]

[0093] In the formula: To implement microservices The device number, For equipment With d n Data transfer rate between them.

[0094] (3) Microservice wait time: According to the three scenarios described in the microservice processing model, when the microservice... Assigned to device d n During execution, the microservice's wait time is:

[0095]

[0096] in, For microservices Assigned to device d n The earliest end time, It is device d n Container c i The tail microservice of the waiting queue, by task r k Call, and When container c i During free time, For container c i Image file size, s K,n Centralized cloud and devices n The data transfer rate between them. W n For device d n The collection of microservices at the tail of all container waiting queues For this set of microservices, task r tIn order to save time, this invention selects the container that can enter the idle state earliest as the replacement container to provide space for the deployment of the new container.

[0097] Step 5, Calculation of microservice energy consumption;

[0098] The energy consumption of a task during processing includes the energy consumption of microservice execution and the energy consumption of data transmission.

[0099] The energy consumption of microservice execution is:

[0100]

[0101] Where, q n For device d n CPU energy efficiency coefficient For device d n Container c i Processing speed Indicates the execution of microservices The number of CPU cycles required.

[0102] Data transfer energy consumption includes the energy consumption of data transfer between dependent microservices:

[0103]

[0104] And the energy consumption of transferring image files:

[0105]

[0106] In the formula, The equipment number is given within a unit of time. The data transmission power of the device; F K This represents the data transmission power of the cloud per unit time.

[0107] Step 6: Establishing scheduling constraints and target numbers;

[0108] There are three constraints in task scheduling: priority constraint, earliest start time constraint, and execution time constraint. Among them:

[0109] I. Priority Constraints: Microservices have dependencies; a preceding microservice must be executed before a subsequent microservice can run. Furthermore, the execution order of parallel microservices also affects task execution time. Therefore, priority is needed to determine the scheduling order of microservices within the task. Starting from the virtual exit microservice, the priorities are obtained by recursively traversing each node. The priorities of each microservice are as follows:

[0110]

[0111] In the formula: p(i) is scheduling priority, for A collection of backend microservices for The average processing time is given by the formula:

[0112]

[0113] in, K represents the microservice execution time, and K represents the total number of edge devices and the cloud.

[0114] As can be seen from the above, the scheduling priority of all microservices will be lower than that of their predecessor microservices, and the microservices with larger data transmission volumes in parallel will be scheduled first.

[0115] Earliest Start Time Constraint: The earliest start time of a microservice is subject to two constraints:

[0116] 1. A microservice can only execute after all its preceding microservices have completed execution and data transmission.

[0117]

[0118] In the formula: for In device d n The earliest start time; for A collection of front-end microservices This is a microservice within this collection. for In the equipment The earliest end time. For equipment With d n Data transfer rate between them.

[0119] 2. Microservices can only execute when the device is capable of doing so:

[0120]

[0121] Therefore, microservices In device d n The earliest start time in is:

[0122]

[0123] The end time is:

[0124] in, Microservice wait time

[0125] Execution time constraint: The end time of the virtual egress microservice represents the end time of the task, so the task execution time is:

[0126]

[0127] for In device d n The end time in the process.

[0128] The execution time of a task cannot exceed its timeout; otherwise, the task is considered incomplete.

[0129] T u ≤y u

[0130] II. Establishing the objective function:

[0131] The fine-grained power task optimization scheduling problem considering service configuration is a constrained multi-objective optimization problem for task r. u The goal is to minimize task execution time and energy consumption. The objective function is:

[0132] minT u

[0133]

[0134] Step 7, Design of a task scheduling algorithm based on NSGA-II;

[0135] Includes the following steps:

[0136] Step 7-1, Chromosome Encoding;

[0137] To accommodate the NSGA-II algorithm, the scheduling scheme is encoded, with different results representing different scheduling schemes. (Chromosome) This chromosome encoding method avoids the dependencies and priority constraints between microservices, and reduces the difficulty of selection, crossover, and mutation operations.

[0138] Step 7-2, Population initialization;

[0139] Assume the population has M individuals. During population initialization, first generate an initial population Z with M / 2 individuals, and set a probability p. When the random probability ≤ p, randomly select two different chromosomes from Z. When the random probability > p, select the chromosome with the shortest execution time and the chromosome with the shortest energy consumption from Z. Add the two selected individuals to the final population, and repeat the loop M / 2 times to generate the final initialized population.

[0140] Step 7-3, fitness assessment;

[0141] In the NSGA-II algorithm, the fitness of an individual reflects its quality. This invention's task scheduling problem is a multi-objective optimization problem considering minimizing task execution time and energy consumption, using Pareto dominance relationships to filter individuals. The condition for individual h1 to dominate h2 is that at least one outcome, h1, is less than h2 in terms of execution time or energy consumption. In the dominance relationship, the dominance level of the dominating individual is lower than that of the dominated individual. To maintain the distribution and diversity of the solution population, individuals with the same dominance level need to be ranked by crowding. Since the task scheduling problem in this invention involves execution time constraints, there may be situations where the task execution time in the generated scheduling scheme does not meet the execution time constraints. To reflect the degree to which an individual violates the execution time constraints, it is necessary to calculate the individual's constraint violation degree value V:

[0142]

[0143] Therefore, this fine-grained power task cloud-edge collaborative optimization scheduling method evaluates individuals from three aspects: feasibility, advantages and disadvantages, and distribution.

[0144] Step 7-4: Selection, crossover, and mutation operations;

[0145] The selection process employed a binary trophy method, using fitness assessments across three dimensions to select individuals. The rules are as follows:

[0146] According to T u ≤y u Determine the feasibility of individuals h1 and h2. When one is a feasible option and the other is an infeasible option, choose the individual with the feasible option; when both individuals are infeasible options, choose the individual with the smaller V; when both individuals are feasible options or have equal V, if there is mutual domination between individuals, choose the individual with the lower domination level; if there is no mutual domination, choose the individual with the higher crowding level.

[0147] Crossover operations employ the widely used two-point crossover method. Based on the crossover probability, crossover is performed on genes at two locations other than the first and last genes on the chromosome. Based on the mutation probability, mutation is performed on genes at one of those locations other than the first and last genes on the chromosome.

[0148] Step 7-5, population update;

[0149] The algorithm performs selection, crossover, and mutation operations on the parent population to obtain the offspring population, then merges the parent and offspring populations into a new population. First, it assesses the feasibility of individuals, then categorizes all individuals into feasible and infeasible solutions, with any feasible solution being preferred over any infeasible one. Next, among all feasible solutions, they are sorted sequentially based on dominance level and crowding. Among infeasible solutions, they are sorted sequentially based on constraint violation value, dominance level, and crowding. Finally, M individuals are selected sequentially and the process repeats. The algorithm iterates continuously, outputting the optimal frontier when the maximum number of iterations is reached.

[0150] Step 8: Weight calculation based on fuzzy logic;

[0151] Since exceeding the latency threshold signifies task failure, latency is a more critical metric. This invention proposes a task latency weighting method based on fuzzy logic, with the following steps:

[0152] Step 8-1, blurring.

[0153] The membership degree of each variable is determined using the triangular membership function, and the calculation formula is as follows:

[0154]

[0155] Where x is an input or output variable, α, β, and γ are given real numbers that depend on the task parameters, and α < β < γ. In the task information, latency, task type value, and input data volume have a significant impact on latency weights, and are therefore used as inputs. The output is the task's latency weight. Low, medium, and high are used as linguistic variables for latency and input data volume; normal, alarm, and fault are used as linguistic variables for task type values; and very low, low, medium, high, and very high are used as linguistic variables for latency weights.

[0156] Depending on the range of task parameters set in the simulation, the values ​​of α, β, and γ are shown in Table 1:

[0157] Table 1 Membership Function Parameters

[0158]

[0159] Step 8-2, Fuzzy Inference. The corresponding fuzzy variables are inferred based on the fuzzy rules for defuzzification. A fuzzy rule table is established based on the functions and characteristics of tasks in the power distribution IoT, as shown in Table 2:

[0160] Table 2 Fuzzy Rule Table

[0161]

[0162] Step 8-3, Defuzzification. The centroid method is used to calculate the defuzzification of the inferred fuzzy variables. The calculation formula is as follows:

[0163]

[0164] The time delay weight Y of the task is obtained through calculation. u ,1-Y u This represents the energy consumption weight of the task.

[0165] Using the above method, critical tasks such as fault handling will receive a higher latency weight, and the final scheduling scheme will be selected from the Pareto solution set with a preference for schemes with shorter execution times. Non-critical tasks will have a lower latency weight, and the scheme with lower energy consumption will be selected while still meeting the latency requirements for task completion.

[0166] Step 9: Sort all solutions of the optimal frontier using the approximation-ideal-solution sorting method, including the following parts:

[0167] This fine-grained cloud-edge collaborative optimization scheduling method for power tasks uses an approximation-ideal-solution sorting method to rank all solutions in the optimal frontier. The minimum execution time and minimum energy consumption in the optimal frontier are taken as the optimal ideal value, and the maximum execution time and maximum energy consumption are taken as the worst ideal value. After data normalization and standardization, the weighted Euclidean distance between each feasible solution and the optimal and worst ideal values ​​is calculated based on the task's latency and energy consumption weights. and Calculate the score S for each scheme according to the following formula. i :

[0168]

[0169] Therefore, 0 ≤ S i ≤1, S i The larger the value, the closer the solution is to the optimal ideal value. Therefore, we choose S. i The scheduling scheme corresponding to the maximum value is used as the task scheduling scheme.

[0170] The following specific example further illustrates the fine-grained cloud-edge collaborative optimization scheduling method for power tasks:

[0171] A fine-grained cloud-edge collaborative optimization scheduling method for power tasks is applied to a real distribution transformer area. Each edge device can be responsible for processing tasks within one or several transformer areas, while the central cloud manages all devices. Distribution IoT terminals are responsible for generating tasks and providing data. During task processing, the task data information from the underlying terminals is uploaded to the edge devices in the corresponding area (the edge device where the task first arrives is called the initial edge device for this task). The edge devices will offload microservices according to the system's task scheduling strategy. Since the tasks within the management area of ​​the edge devices are diverse and the edge device resources are limited, only a limited number of services can be configured. Therefore, it is necessary to adjust the service configuration in the edge devices according to different task allocation results. When the task is completed, the result data is sent to the initial edge device.

[0172] In such Figure 2 The system architecture diagram shows three edge devices and a central cloud. Each edge device can only be configured with two services. When a task arrives, considering the current service configurations of each edge device, the system assigns microservices 1 and 4 to d1, 2 to d2, and 3 to d3. Under this allocation scheme, d1 needs to download and configure service 4 from the cloud, and then the devices collaborate to execute the task. (Reference) Figure 3 The image shows a real-world scenario, illustrating an improved IEEE 33-node system. The distribution area comprises four edge devices and one central cloud.

[0173] To verify the performance of the proposed algorithm for fine-grained power task cloud-edge collaborative optimization scheduling, the algorithm was implemented and tested using Python. The task class includes ID, graph structure, arrival time, deadline, task type value, latency weight, and the submitted edge device number. The container class includes ID, running microservice, remaining time, image file size, and processing speed. The server class includes ID and container list. The system settings class includes the number of edge devices, cloud-edge communication time multiplier, number of containers supported for concurrent operation on each device, CPU energy efficiency coefficient, and device data transmission power. The algorithm settings class includes population size, maximum number of iterations, crossover probability, mutation probability, and probabilities set during population initialization.

[0174] To evaluate the performance of the algorithm, our fine-grained cloud-edge collaborative optimization scheduling method for power tasks is compared with the following three benchmark algorithms:

[0175] Method 1: Edge Process (EP): For all tasks, this algorithm assigns them to the initial edge device for processing, and the microservices called are not unloaded.

[0176] Method 2: Cloud Process (CP): For all tasks, this algorithm offloads microservices, except for virtual entry and exit microservices, to cloud processing.

[0177] Method 3: Random Process (RP): For all tasks, this algorithm randomly assigns microservices, except for the virtual entry and exit microservices, to various devices for execution.

[0178] Regarding system parameter settings, the number of edge devices is 4, and the number of cloud devices is 1. Each edge device can be configured with 4 containers simultaneously, and the cloud supports 9 concurrent containers. The data transfer rate between edges is 20 times that of the cloud edge. Considering that the computing power of the cloud is stronger than that of the edge devices, the average processing speed of the cloud is set to 1.25 times that of the edge devices. The CPU energy efficiency coefficient is 5×10. -27 The data transmission power of the edge device is 3W, and the data transmission power of the cloud is 5W. Regarding task configuration, each task calls 5-9 microservices. The amount of data processed by each microservice is in the range of (0.1, 1.2) MB; the amount of data transmitted from the virtual entry microservice to another entry microservice is in the range of (0.5, 1) MB; the amount of data transmitted between other microservices is in the range of (0.1, 0.5) MB; the container image file size is in the range of (0.5, 1) MB; and the task latency is in the range of (2, 20) s. Regarding algorithm parameter settings, the population size is 50, the maximum number of iterations is 100, the crossover probability is 0.3, the mutation probability is 0.3, and p = 0.5.

[0179] To fully verify the effectiveness of the task scheduling strategy proposed in this invention in the actual operation environment of the power grid, three typical scenarios were simulated:

[0180] (1) Normal operation scenario: all tasks are routine tasks, with no alarms or fault handling tasks. The experimental results comparison chart is shown below. Figures 4-5 As shown.

[0181] (2) In low-fault scenarios, the ratio of routine tasks, alarm tasks, and fault handling tasks is 7:2:1. The experimental results comparison chart is shown below. Figures 6-7 As shown.

[0182] (3) In high-fault scenarios, the ratio of routine tasks, alarm tasks, and fault handling tasks is 5:3:2. The experimental results comparison chart is shown below. Figures 8-9 As shown.

[0183] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A fine-grained cloud-edge collaborative optimization scheduling method for power tasks, characterized in that: Includes the following steps: Step a: Determine the number of edge devices and the cloud, configure communication between edge devices and the cloud, and create containers and devices; Step b: Establish the task model and determine the task information; Step c, consider the microservice processing model for service configuration; Step d: Calculation of microservice latency and energy consumption; Step e: Establishing scheduling constraints and target number; Step f, Design of a task scheduling algorithm based on NSGA-II; Step g: Weight calculation based on fuzzy logic; Step h: Sort all solutions of the optimal frontier using the approximation ideal solution sorting method, calculate the score of each scheme, and select the scheduling scheme corresponding to the maximum score as the task scheduling scheme. In step c, the map() function is defined to represent the mapping between microservices and containers. For any and , Represents microservices By container Processing, among which It is a collection of all microservices. It is a collection of all business containers, and the operation and deployment of containers in the device are also dynamically changing; microservices Assigned to equipment There are three possible scenarios during processing: Scenario 1: Equipment Containers required for microservices have been configured. If this container is handling other microservices of the same type, the microservices It needs to enter the container's waiting queue to wait for execution. If the container is idle, the microservice will proceed. It can be executed immediately; Scenario 2: The device is not equipped with a container. and It requires downloading the necessary container image files from the cloud and then running them to handle microservices. ; Scenario 3: Equipment No container configured and Then the container list needs to be... Replace one of the containers in the list, and remove the replaced container from the container list. Remove and then add a newly configured container to handle microservices. ; In step d, the calculation of microservice latency includes the execution time of the microservice, the data transmission time between microservices, and the waiting time of the microservice; The calculation of microservice energy consumption includes the energy consumption of microservice execution and the energy consumption of data transmission.

2. The fine-grained cloud-edge collaborative optimization scheduling method for power tasks according to claim 1, characterized in that: Step b includes the following steps: Step b-1, the fine-grained power tasks based on microservices are modeled using a directed acyclic graph, represented as... ,in: Let be a set of nodes in a graph, where each node represents a microservice invoked by a task. Let be the set of directed edges in the graph, where directed edges represent dependencies between microservices. Based on the dependencies between two microservices, the microservice that transmits data is called the front-end microservice, and the microservice that receives data is called the back-end microservice. The collection of data transferred between microservices; Step 2-2, Task Topology Modification: The microservice without any preceding microservices is called the entry microservice, and the microservice without any following microservices is called the exit microservice. A virtual entry microservice is added that does not consume any time or resources. With virtual exit microservices It is stipulated that the two virtual microservices will not participate in scheduling, and the graph structure is modified as follows: ； Steps 2-3, the set of power tasks is represented as follows Each task There are four basic pieces of information, represented as follows , in, Indicates task Arrival time, Indicates task The latency, that is, the task needs to Processing completed within the specified time. Indicates task The type value is used to distinguish between routine tasks, alarm tasks, and fault handling tasks.

3. The fine-grained cloud-edge collaborative optimization scheduling method for power tasks according to claim 1, characterized in that: Step g includes the following steps: Step 8-1: Fuzzification, determining the membership degree of each variable using the triangular membership function; Step 8-2, Fuzzy Reasoning: Based on the fuzzy rules, derive the corresponding fuzzy variables for defuzzification; Step 8-3, Defuzzification: The centroid method is used to calculate the defuzzification of the inferred fuzzy variables. The calculation formula is as follows: in, For input or output variables, The time delay weight of the task is calculated using the membership degree obtained in step 8-1. , This represents the energy consumption weight of the task.

4. The fine-grained cloud-edge collaborative optimization scheduling method for power tasks according to claim 3, characterized in that: In step 8-1, the membership degree of each variable is determined using the triangular membership function, and the calculation formula is as follows: in, For input or output variables, , , Given a real number, depending on the task parameters, and In the task information, latency, task type value, and input data volume have a significant impact on latency weight. Therefore, as input, the output is the latency weight of the task. Low, medium, and high are used as linguistic variables for latency and input data volume, normal, alarm, and fault are used as linguistic variables for task type value, and very low, low, medium, high, and very high are used as linguistic variables for latency weight.

5. The fine-grained cloud-edge collaborative optimization scheduling method for power tasks according to claim 1, characterized in that: The execution time of a microservice is: in, For equipment medium container To meet computing resource constraints, the processing speed... Indicates the execution of microservices Number of CPU cycles required , microservices The amount of data to be processed, where l represents the number of CPU cycles required to process a unit of data. The number of containers running concurrently on the device, arbitrary. The sum of the processing speeds of each container will not exceed the processing speed of the device. ; The data transfer time between two dependent microservices is: In the formula: To implement microservices The device number, , For equipment and Data transfer rate between For data transfer time between two dependent microservices; microservices Assigned to equipment During execution, the microservice's wait time is: in, For microservices Assigned to equipment The earliest end time, It is equipment medium container The tail microservice of the waiting queue, consisting of tasks Call, and When the container During free time, , For containers Image file size, Centralized cloud and devices Data transfer rate between For equipment The collection of microservices at the tail of all container waiting queues For this set of microservices, the task Call.

6. The fine-grained cloud-edge collaborative optimization scheduling method for power tasks according to claim 1, characterized in that: The energy consumption of microservice execution is: in, For equipment CPU energy efficiency coefficient For equipment medium container Processing speed Indicates the execution of microservices Required number of CPU cycles; Data transfer energy consumption includes the energy consumption of data transfer between dependent microservices: And the energy consumption of transferring image files: in, The equipment number is given within a unit of time. The data transmission power of the device; This refers to the data transmission power of the cloud per unit time. For equipment and Data transfer rate between Centralized cloud and devices Data transfer rate between For containers Image file size, This refers to the data transfer time between two dependent microservices.

Images