A cloud-edge collaborative task scheduling method and system for low-voltage distribution network gray area perception

Abstract

The application belongs to the technical field of power system task scheduling, and discloses a cloud-edge collaborative task scheduling method and system for low-voltage distribution network gray area perception. The method relies on a collaborative system composed of a cloud, a terminal and a computing module. The method comprises the following steps: the terminal receives a data processing task and calculates a task granularity value, and divides the task into a first queue or a second queue based on the comparison result of the task granularity value and a preset threshold value; the task in the first queue is executed locally on the terminal; the task in the second queue is decided by a scheduling model to be executed locally on the terminal or unloaded to the computing module for execution; after the task is executed, a task execution reward is calculated, and an experience sample is constructed based on the task execution result and the task execution reward; the scheduling model parameters are updated through a priority experience replay mechanism; the cloud regularly collects the running states and feedback data of the terminal and the computing module to globally optimize and train the scheduling model, and the updated model parameters are distributed to the terminal through a cloud-edge regulation channel.

Description

Technical Field

[0001] This invention belongs to the field of power system task scheduling technology, specifically relating to a cloud-edge collaborative task scheduling method and system for gray-domain perception of low-voltage distribution networks. Background Technology

[0002] With the continuous advancement of the construction of new power systems, low-voltage distribution networks (transformer areas) are accelerating their transformation towards digitalization and intelligence. Against this backdrop, the edge of the distribution network is aggregating massive amounts of heterogeneous measurement data, such as second-level AC sampling data collected by intelligent fusion terminals and minute-level measurement data reported by IoT devices such as smart circuit breakers and smart meters. This data is characterized by multiple sources, high collection frequency, heterogeneous business types, and strong spatial coupling. Due to the explosive growth in data volume, it is technically impossible to upload the entire amount to the cloud master station for processing. This poses a severe data processing challenge for low-voltage distribution networks in gray-domain sensing scenarios (i.e., on-site sensing and completion of uncertain states in areas due to data gaps, communication blind spots, or heterogeneity).

[0003] Currently, most distribution centers adopt the traditional centralized cloud processing model. However, with the surge in data volume, this model has encountered bottlenecks in terms of communication bandwidth consumption, centralized cloud computing power load, and real-time business response, making it difficult to meet the actual needs of on-site analysis of high-frequency data and second-level rapid response in gray-area perception scenarios. To resolve this core contradiction, a cloud-edge collaborative architecture has been introduced, adopting a distributed processing approach where high-frequency data is processed on-site at the edge and global control is performed by the cloud master station.

[0004] However, existing edge computing and task scheduling solutions still have the following problems when facing the special environment of strong spatiotemporal coupling and computing power fluctuations in low-voltage distribution networks: 1. The task partitioning and distribution mechanism is too simplistic and lacks a refined consideration of edge computing power overhead. Existing technologies mostly use fixed static rules or single business priorities to distribute tasks. Due to the lack of a dynamic granular evaluation mechanism that combines the task's own computational load (floating-point operation load) and communication data volume (input / output byte count), all tasks arriving at the edge side need to be uniformly decided through a complex scheduling model. It is impossible to quickly and proactively separate lightweight tasks, resulting in significant algorithmic redundancy and reducing the real-time response capability of the edge side.

[0005] 2. Traditional reinforcement learning scheduling algorithms suffer from low convergence efficiency and severe policy oscillations in dynamic environments. Existing cloud-edge collaborative scheduling research generally employs a uniform random experience replay mechanism when introducing reinforcement learning algorithms (such as A2C and PPO) for dynamic decision optimization. This mechanism fails to optimize for the high-frequency fluctuations in communication bandwidth and the variable task scale of low-voltage distribution networks, and lacks a priority learning strategy for samples with high temporal difference errors (high value), resulting in slow convergence speed and low training efficiency during both offline and online model updates.

[0006] 3. The scheduling optimization objective is singular, making it difficult to balance latency and the long-term computing power health of the system. Existing low-voltage distribution network task offloading schemes mostly focus on optimizing a single objective (such as only pursuing the minimization of computing latency or reducing node power consumption). Under this mechanism, in order to pursue the ultimate low latency, the model often blindly and excessively offloads massive intensive tasks to edge-side hardware computing modules (such as NPUs), lacking horizontal constraints on the overall computing load balance of all computing nodes in the distribution area (including terminal local general-purpose CPUs and computing modules NPUs). This can easily lead to system crashes or the blocking of core real-time tasks due to local overload of computing modules.

[0007] Therefore, how to achieve lightweight pre-load routing of tasks, efficient multi-objective joint scheduling among heterogeneous computing nodes, and rapid and stable convergence of reinforcement learning models in a highly dynamic environment in the gray-domain perception scenario of low-voltage distribution networks are the technical challenges that urgently need to be solved in the field of power edge computing. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention provides a cloud-edge collaborative task scheduling method and system for gray-domain perception in low-voltage distribution networks. The terminal pre-distributes tasks to a first or second queue based on task granularity. Through a scheduling model, it dynamically decides whether the second queue should remain on the terminal for local execution or be offloaded to a computing module. After task execution, experience samples are built, and a priority experience replay mechanism is used to dynamically update and optimize the network parameters of the scheduling model. Finally, the cloud periodically aggregates operational status and feedback data for global model optimization training and synchronizes it to the terminal. This achieves rapid on-site task distribution and efficient dynamic scheduling of heterogeneous computing power in low-voltage distribution network gray-domain perception scenarios, significantly reducing task execution latency and improving the stability of the scheduling model in highly dynamic operating environments.

[0009] This invention provides the following technical solution: The first objective of this invention is to provide a cloud-edge collaborative task scheduling method for gray-domain perception in low-voltage distribution networks. This method relies on a collaborative system composed of a cloud platform, terminals, and computing modules. It is applied to low-voltage distribution network areas in a gray-domain state where measurement coverage is incomplete and data blind spots exist. The low-voltage distribution network gray-domain perception utilizes the computing power of the terminals and computing modules through a cloud-edge collaborative architecture to monitor and reconstruct the operating status of the low-voltage distribution network areas. The method includes: The terminal receives data processing tasks, calculates task granularity values ​​based on the computational and data volume characteristics of the tasks, and divides the tasks into a first queue or a second queue based on the comparison results between the task granularity values ​​and a preset threshold. Tasks assigned to the first queue are executed locally on the terminal; a state vector is constructed for tasks assigned to the second queue, and the state vector is input into a scheduling model pre-deployed on the terminal side; The scheduling model determines whether the task is executed locally on the terminal or offloaded to the computing module based on the state vector. After the task is completed, the task execution reward is calculated based on the actual execution effect of the task and the overall load balance of the system. Based on the task execution result and the task execution reward, an experience sample is constructed to dynamically update and optimize the network parameters of the scheduling model through a priority experience replay mechanism. The cloud periodically aggregates the operating status and feedback data of the terminal and the computing module to perform global optimization training on the scheduling model, and sends the updated model parameters to the terminal through the cloud-edge control channel.

[0010] A three-tiered collaborative computing system consisting of cloud, terminals, and computing modules is constructed. Through task granularity and a dual-queue distribution mechanism, it enables rapid distribution of massive heterogeneous data streams. Tasks in the first queue are lightweight and processed locally in real-time; computationally intensive tasks in the second queue undergo intelligent offloading decisions through a scheduling model, addressing the communication bandwidth bottlenecks and insufficient real-time response issues faced by traditional centralized cloud processing models. A cloud-edge control closed loop is established, encompassing online terminal decision-making, global offline optimization in the cloud, and periodic parameter distribution and synchronization. This allows the scheduling model deployed in low-voltage distribution network areas to continuously adapt to the frequently fluctuating communication states and service demands under strongly spatiotemporally coupled environments.

[0011] Preferably, the task granularity value calculation includes: normalizing the total computational cost required for task execution to obtain a normalized computational cost, normalizing the sum of the input data and expected output data of the task to obtain a normalized data volume, and the task granularity value is obtained by weighted summation of the normalized computational cost and the normalized data volume.

[0012] This approach abandons traditional task partitioning methods that rely solely on static weights or single features. Instead, it considers both the computational overhead required for task execution and the amount of input and output data. By using normalized weighted summation, it accurately and objectively quantifies the comprehensive overhead of tasks in terms of computational complexity and communication costs, providing a scientific and reliable data basis for subsequent differentiated path routing.

[0013] Preferably, tasks with a granularity value less than the preset threshold are assigned to a first queue, and tasks with a granularity value greater than or equal to the preset threshold are assigned to a second queue; wherein, the preset threshold is set based on the statistical quantile of the historical task granularity value distribution.

[0014] By setting the queue partitioning threshold to the statistical quantile of the historical task distribution (such as the 75th percentile), 75% of lightweight tasks can be executed directly on the terminal without entering a complex scheduling decision process. This reduces the computational power consumption and latency of the scheduling algorithm itself, ensures the rapid response of lightweight services, and meets the needs of rapid task processing in the gray area perception scenario of the distribution center.

[0015] Preferably, the state vector includes the normalized computational cost of the task, the normalized data volume of the task, the current effective transmission bandwidth between the terminal and the computing module, and the task granularity value.

[0016] Preferably, the network parameter update of the scheduling model includes: After the task is completed, an experience sample is constructed, which includes the current state vector, the target action, the task execution reward, and the next state vector. Calculate the priority of the experience samples and store the experience samples with priority tags in the experience replay pool; A priority experience replay mechanism is used to select learning samples from the experience replay pool, and an importance sampling weight is introduced to correct the loss function in order to dynamically update the network parameters of the scheduling model.

[0017] By calculating the priority of empirical samples and introducing importance sampling weights to correct the loss function in real time, this not only solves the pain points of slow convergence and low training efficiency of the traditional Actor-Critic algorithm (i.e., scheduling model) in the highly dynamic environment of low-voltage distribution networks, but also prevents the algorithm from getting trapped in local optima due to excessive focus on high-value samples, and improves the smooth transition capability between offline and online training.

[0018] Preferably, the task execution reward is calculated by weighted average of latency penalty and load imbalance penalty; wherein, the latency penalty is calculated based on the computation latency of the current task and the communication transmission latency caused by task unloading; the load imbalance penalty is the root mean square error of the real-time load rate of the computing node currently participating in the computation relative to the average load rate of each computing node; the computing node includes the local computing power node on the terminal side and the computing power node on the computing module side.

[0019] The reward function innovatively combines computation and communication latency with the load balancing variance among multiple computing nodes in a weighted combination, constraining the offloading boundary of the scheduling model, preventing the computing module from overloading and crashing due to excessive concentration of tasks on the computing module side, and achieving dual optimization of latency minimization and load balancing.

[0020] Preferably, the experience replay pool uses a binary tree structure to store each experience sample with priority tags; the step of using a priority experience replay mechanism to select samples to be learned from the experience replay pool includes: During sampling, the probability of each experience sample being sampled is determined based on the proportion of the priority of each experience sample to the total priority of all experience samples in the current experience replay pool. Based on the total number of samples and the probability of each empirical sample being sampled, the importance sampling weight is calculated, and the loss function is corrected by the importance sampling weight to eliminate the scheduling model network parameter update deviation caused by sampling.

[0021] A binary tree structure (SumTree) is used to store each experience sample with priority tags, improving the retrieval efficiency of high-value experience samples and the efficiency of high-frequency sampling. At the same time, the importance sampling weights are used to correct the loss function, eliminating the model parameter update bias caused by non-uniform priority sampling, and ensuring the stability and generalization ability of the scheduling strategy under different task scales and dynamic fluctuations.

[0022] Preferably, the priority of the empirical samples is calculated based on the temporal difference error of the empirical samples; the calculation of the temporal difference error of the empirical samples includes: The scheduling model includes a policy network and a value evaluation network. The value evaluation network is used to calculate the expected value of the current state, and the task execution reward and the expected value of the next state are combined to jointly calculate the temporal difference error of the current state-action pair.

[0023] The temporal difference error (TD-error) calculated by the value evaluation network is used to drive the calculation of the priority of learning experience samples. The action space is implicitly included in the expected value of the immediate reward and the next state, enabling the system to capture experience samples with high temporal difference error more accurately.

[0024] Preferably, when updating the network parameters of the scheduling model, the parameters of the policy network are optimized and updated using the stochastic gradient ascent method based on the temporal difference error and the importance sampling weights; the parameters of the value evaluation network are optimized and updated using the stochastic gradient descent method based on the temporal difference error and the importance sampling weights.

[0025] The second objective of this invention is to provide a cloud-edge collaborative task scheduling system for gray-domain awareness in low-voltage distribution networks, used to implement the above-mentioned method. The system includes: The terminal, deployed on the low-voltage distribution network side, is equipped with a data processing module, a queue partitioning module, a scheduling decision module, a control execution module, and a model update module; among which: The data processing module is used to acquire multi-source data from the distribution area in real time and to preprocess the data. The queue partitioning module is used to acquire data processing tasks, calculate task granularity values ​​based on the computational and data volume characteristics of the tasks, and partition the tasks into a first queue or a second queue based on the comparison results of the task granularity values ​​and preset thresholds. The scheduling decision module is configured with a scheduling model to decide the task execution mode; wherein, tasks assigned to the first queue are executed locally on the terminal; tasks assigned to the second queue are executed locally on the terminal or offloaded to the computing module for execution based on the task's state vector, as decided by the scheduling model. The control execution module is used to execute tasks that are performed locally on the terminal; The model update module is used to build experience samples after the task is completed, and to dynamically update and optimize the network parameters of the scheduling model through a priority experience replay mechanism. A computing module is used to execute tasks offloaded to a second queue for execution by the computing module. The cloud is used to periodically aggregate the operating status and feedback data of the terminal and the computing module to perform global optimization training on the scheduling model, and to send the updated model parameters to the terminal through the cloud-edge control channel.

[0026] Based on the cloud-edge collaborative architecture, a three-layer collaborative computing system is constructed, consisting of a cloud master station, intelligent fusion terminals, and AI computing modules. Combined with computing power prediction and dynamic scheduling mechanisms, it enables on-site data processing and global collaborative optimization in gray-domain perception scenarios.

[0027] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. Construct a three-layer collaborative computing system consisting of cloud, terminal, and computing modules. Through task granularity and a dual-queue distribution mechanism, achieve rapid distribution of massive heterogeneous data streams. Tasks in the first queue are lightweight and processed locally in real-time; computationally intensive tasks in the second queue are intelligently offloaded through a scheduling model. This addresses the communication bandwidth bottlenecks and insufficient real-time response issues faced by traditional centralized cloud processing models. Establish a cloud-edge control closed loop encompassing online terminal decision-making, global offline optimization in the cloud, and periodic parameter distribution and synchronization. This enables the scheduling model deployed in low-voltage distribution network areas to continuously adapt to the frequently fluctuating communication states and business demands under strongly spatiotemporally coupled environments.

[0028] 2. In the scheduling model network parameter update, a priority experience replay mechanism is introduced to prioritize the learning of samples with high time-series differential errors, thereby accelerating the convergence process and improving training efficiency to adapt to the dynamic and frequently changing operating environment of low-voltage distribution networks.

[0029] 3. Based on the cloud-edge collaborative architecture, a three-layer collaborative computing system is constructed, consisting of a cloud master station, intelligent fusion terminals, and AI computing modules. Combined with computing power prediction and dynamic scheduling mechanisms, it enables on-site data processing and global collaborative optimization in gray-domain perception scenarios. Attached Figure Description

[0030] Figure 1 A flowchart of the method provided in Example 1; Figure 2 This is a schematic diagram of the system provided in Example 2. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, 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.

[0032] The present invention will now be described in further detail with reference to the accompanying drawings: To enable those skilled in the art to more clearly understand the present invention, the core technical concept of gray-field perception involved in this invention is explained herein: "Distribution network area gray domain perception" refers to the transparent monitoring and reconstruction of the operating status of distribution areas in a "gray" state where the measurement devices in low-voltage distribution network areas are not fully covered, there are blind spots in the data, or the topology files are inaccurate.

[0033] Specifically, the "gray area" is a specific operating scenario that lies between the "black area" and the "white area".

[0034] Black area: refers to a blind area where measurement data is completely lacking and the topological relationship is unknown.

[0035] White area: refers to a transparent state where the measurement device is fully covered, data is uploaded in real time, and the topological relationship is completely accurate.

[0036] Gray area: refers to the current transitional state of the transformer area. Although the transformer area has deployed some existing measurement devices (such as smart meters, distribution transformer terminals, etc.), it is unable to achieve high-frequency data acquisition of all nodes due to construction costs or communication bottlenecks. This results in data breakpoints, unclear phase attribution, or missing branch topology within the transformer area, making it impossible to obtain a complete operational overview by directly reading the data.

[0037] The essence of "gray area perception" technology is "computation to supplement measurement". That is, by using a cloud-edge collaborative architecture, high-computing algorithms such as topology identification, state estimation and power flow calculation are deployed on the edge side. Based on existing incomplete measurement data, combined with power physics constraints and data-driven models, missing blind spot data is extrapolated and reconstructed, thereby achieving a panoramic perception effect of transformer area comparable to full measurement coverage with low hardware investment costs.

[0038] This invention provides a cloud-edge collaborative task scheduling method and system for gray-domain perception in low-voltage distribution networks. It is specifically designed to resolve the contradiction between the high difficulty of perception and the limited resources on the edge side under the aforementioned "gray-domain" state. The specific technical connections and supporting relationships between the two are as follows: 1. The mismatch between algorithm computing power requirements and edge heterogeneous computing power: The core of achieving "gray area perception" lies in "computation-assisted measurement," which relies on complex algorithms such as topology identification and state estimation. These algorithms typically involve high-dimensional matrix operations and iterative solutions, demanding extremely high computing power. However, edge terminals (such as intelligent converged terminals) are usually limited by cost and power consumption, resulting in limited general-purpose CPU computing power, making it difficult to independently and in real-time support all gray area perception algorithms. This invention introduces a computing module (AI computing module) as a computing power enhancement unit and designs a cloud-edge collaborative task scheduling method. This method intelligently decides whether computationally intensive gray area perception tasks should be executed locally on the terminal or offloaded to the computing module, effectively utilizing the heterogeneous acceleration capabilities of the computing module (especially its NPU). This solves the high computing power requirement of gray area perception algorithms within limited edge-side resources.

[0039] 2. Coordinated optimization of data flow and sensing accuracy: In the gray-domain sensing process, the terminal is responsible for collecting incomplete raw measurement data (input) and acts as the scheduling decision center. The computing module, as the execution unit, is responsible for handling the computationally intensive tasks offloaded from the terminal. The scheduling system of this invention can intelligently allocate computing tasks based on the current communication bandwidth status (such as the effective transmission bandwidth between the terminal and the computing module) and task priorities. This dynamic scheduling mechanism ensures that the gray-domain sensing algorithm can obtain the necessary computing power support, while avoiding processing delays caused by all tasks piling up on the terminal CPU, thus guaranteeing the real-time performance and accuracy of sensing.

[0040] 3. Achieve the transition from "gray area" to "white area": This invention, through efficient edge-side task scheduling, enables distribution network areas to achieve near-full measurement coverage (i.e., logically reaching the "white zone") by enhancing computing power at the logical level (terminals + computing modules), without increasing the number of physical measurement devices (i.e., still physically in the "gray zone"). The collaborative system provided by this invention, consisting of cloud, terminal, and computing module, is a key supporting architecture for achieving low-cost, high-efficiency gray zone perception.

[0041] Example 1: like Figure 1 As shown, this embodiment provides a cloud-edge collaborative task scheduling method for low-voltage distribution network gray-domain perception. The method relies on a collaborative system composed of a cloud, a terminal, and a computing module. It is applied to low-voltage distribution network areas in a gray-domain state where measurement coverage is incomplete and data blind spots exist. The low-voltage distribution network gray-domain perception utilizes the computing power of the terminal and the computing module through a cloud-edge collaborative architecture to monitor and reconstruct the operating status of the low-voltage distribution network area. The method includes: The terminal receives data processing tasks, calculates task granularity values ​​based on the computational and data volume characteristics of the tasks, and divides the tasks into a first queue or a second queue based on the comparison results between the task granularity values ​​and a preset threshold. Tasks assigned to the first queue are executed locally on the terminal; a state vector is constructed for tasks assigned to the second queue, and the state vector is input into a scheduling model pre-deployed on the terminal side; The scheduling model determines whether the task is executed locally on the terminal or offloaded to the computing module based on the state vector. After the task is completed, the task execution reward is calculated based on the actual execution effect of the task and the overall load balance of the system. Based on the task execution result and the task execution reward, an experience sample is constructed to dynamically update and optimize the network parameters of the scheduling model through a priority experience replay mechanism. The cloud periodically aggregates the operating status and feedback data of the terminal and the computing module to perform global optimization training on the scheduling model, and sends the updated model parameters to the terminal through the cloud-edge control channel.

[0042] The following describes the specific method and process: S1. Task arrival and task granularity value calculation: After the task arrives at the smart terminal, the task granularity value is first calculated. Task granularity value Task-based normalized computational complexity With normalized data volume The weighted calculation is as follows:

[0043]

[0044]

[0045] in, For the task i The normalization computational cost has a value range of [0,1]. To carry out the mission i The total number of computation cycles or floating-point operations (FLOPs) required; This represents the maximum computational load in historical tasks. For the task i The normalized data volume, with a value range of [0,1]; This is the sum of the input data volume and the expected output data volume based on historical statistics, in bytes. The input data volume can be accurately obtained when the task arrives, while the output data volume is estimated using the historical average due to the uncertainty of the task execution result. This represents the maximum amount of data in a historical task. , These are weighting coefficients used to balance the impact of computational complexity and communication overhead, satisfying... In this embodiment , .

[0046] S2, Dual-queue task division: Based on task granularity and preset threshold Divide the task queue. Threshold. The setting method is as follows: collect the distribution data of historical task granularity values, perform statistical analysis, and take the 75th percentile as the division threshold to ensure that 75% of lightweight tasks (divided into the first queue) are executed quickly on the spot, and 25% of medium-weight tasks (divided into the second queue) enter the intelligent scheduling process.

[0047] The division rules are as follows: like The task is classified as lightweight and added to the LP queue (i.e., the first queue), and executed directly on the local smart terminal. like The tasks are divided into medium-sized tasks and added to the HP queue (i.e., the second queue), and then enter the reinforcement learning scheduling decision process of the scheduling model.

[0048] S3. State space construction: For HP queue tasks, construct a state vector. :

[0049] in, This represents the current effective transmission bandwidth between the terminal and the computing module.

[0050] S4, Actor Network (Policy Network) Action Output: The Actor network is based on the state vector. Output action probability distribution, the action space is defined as:

[0051] In the formula, =0 indicates local processing on the terminal. =1 indicates that the code is unloaded to the AI ​​computing module.

[0052] S5, Critic Network (Value Assessment Network): Value Assessment: The Critic network evaluates the value of the current state-action pair. Calculate the timing difference error (TD-error). :

[0053] In the formula, The immediate reward following the execution of the current scheduling decision; As a discount factor, in this embodiment =0.95; The value assessment network's expected value assessment of the current state; This represents the expected value assessment value of the value assessment network for the next state.

[0054] S6. Task Execution and Task Reward Calculation: After the task is completed, calculate the reward function. The reward function is based on the task execution delay T and the system load balancing variance. The construction and calculation formula is as follows:

[0055]

[0056] Where T is the execution latency of the current task, which includes computation latency and communication latency, in seconds; computation latency is the execution time of the task on the target node, and communication latency is the data transmission time of the task (only generated when the task is unloaded). The system load balancing variance is specifically the variance of the computing nodes currently participating in the computation. j Real-time load rate Relative to the average load rate of each computing node The mean squared error; To calculate the total number of nodes; , For the weighting coefficients, satisfying This embodiment emphasizes the importance of balancing latency optimization and load balancing. .

[0057] S7. Experience storage and priority calculation: Construct experience samples containing the current state vector, target action, task execution reward, and next state vector; calculate the priority of each experience sample; and store the experience samples with priority tags in the experience replay pool. The formula for calculating the priority P of an experience sample is:

[0058] In the formula, It is a constant greater than 0, ensuring that all empirical priorities are non-zero.

[0059] S8, Prioritize Experience Replay Sampling: The SumTree binary tree structure is used to store each experience sample with priority tags. Sampling is performed according to the priority of each experience sample. Sampling probability of an empirical sample for:

[0060] In the formula, The intensity used to control the priority of playback is within the range of [0,1]. In this embodiment... =0.6; k This represents the total number of experience samples in the current experience replay pool; This represents the sum of priorities of all experience samples in the current experience replay pool.

[0061] S9. Importance sampling weight correction: Introducing importance sampling weights The loss function is modified to avoid bias in scheduling model network parameter updates caused by priority sampling. Importance sampling weights. The calculation formula is:

[0062] In the formula, N is the total number of empirical samples; The importance sampling compensation parameter, with a value range of [0,1], is used to adjust the degree of compensation. In this embodiment... =0.4.

[0063] S10, Network Parameter Update: The Actor network updates its parameters using stochastic gradient ascent (SGA), while the Critic network updates its parameters using stochastic gradient descent (SGD), as follows:

[0064]

[0065] In the formula, and These are the parameters for the Actor network and the Critic network, respectively. In this embodiment, the learning rate is... =0.001.

[0066] In this embodiment, the scheduling model adopts an Actor-Critic architecture. Both the Actor network (policy network) and the Critic network (value evaluation network) use multi-layer fully connected neural networks, and the specific design is as follows: (1) The structural design of the Actor network (policy network) is as follows: Input layer: 4-dimensional, corresponding to the 4 components of the state vector, namely normalized computational cost, normalized data volume, current effective transmission bandwidth (all normalized to the [0,1] interval) and task granularity label (value 0 or 1). The first hidden layer has 128 neurons, with the activation function being ReLU (Rectified Linear Unit). Dropout regularization (dropout ratio of 0.2) is introduced to prevent overfitting. The second hidden layer has 64 neurons with ReLU activation function and Dropout regularization (dropout ratio of 0.1). Output layer: A 2D Softmax output layer, corresponding to the probability distributions of actions A=0 (executed locally on the terminal) and A=1 (unloaded to the computing module), respectively. ,satisfy .

[0067] The total number of parameters in the Actor network is approximately 4×128+128+128×64+64+64×2+2≈16,834 trainable parameters, which meets the lightweight requirements for real-time inference on the edge side.

[0068] (2) The structural design of the Critic network (value assessment network) is as follows: Input layer: Same as the Actor network, with a dimension of 4, inputting the current state vector; First hidden layer: 128 neurons, activation function is ReLU, dropout ratio is 0.2; Second hidden layer: 64 neurons, activation function is ReLU, dropout ratio is 0.1; Output layer: 1-dimensional linear output layer (no activation function), outputting the value evaluation of the current state. It is used to evaluate the expected cumulative return of the current strategy in a given state.

[0069] The total number of parameters in the Critic network is the same as that in the Actor network, approximately 16,834 trainable parameters.

[0070] (3) Loss function and optimization method: The loss function of the Critic network is: ,in This refers to the timing difference error (TD-error). For instant rewards, Discount factor (in this embodiment) =0.95). Introduce importance sampling weights. Then, the actual loss function is corrected to: This is to eliminate sampling bias introduced by prioritizing experience playback.

[0071] The policy gradient of the Actor network is: After introducing importance sampling weights, it is corrected to: .

[0072] Both networks use the Adam optimizer for parameter updates, with a learning rate λ=0.001, an experience replay pool capacity N=10000, and a mini-batch size of 32.

[0073] In summary, this embodiment constructs a three-layer collaborative computing system consisting of cloud, terminal, and computing module. Through task granularity and a dual-queue distribution mechanism, it achieves rapid distribution of massive heterogeneous data streams, assigning lightweight tasks to the first queue for on-site, real-time processing; and assigning computationally intensive tasks to the second queue, with intelligent offloading decisions made through a scheduling model. This effectively solves the communication bandwidth bottlenecks and insufficient real-time response issues faced by traditional centralized cloud processing models. Simultaneously, a cloud-edge control closed loop is established, encompassing online terminal decision-making, global offline optimization in the cloud, and periodic parameter distribution and synchronization. This enables the scheduling model deployed in the low-voltage distribution network area to continuously adapt to the frequently fluctuating communication states and service demands under a strongly spatiotemporally coupled environment.

[0074] Example 2: like Figure 2 As shown, this embodiment provides a cloud-edge collaborative task scheduling system for gray-domain awareness in low-voltage distribution networks, used to implement the method described in Embodiment 1. The system includes: The terminal, deployed on the low-voltage distribution network side, is equipped with a data processing module, a queue partitioning module, a scheduling decision module, a control execution module, and a model update module; among which: The data processing module is used to acquire multi-source data from the distribution area in real time and to preprocess the data. The queue partitioning module is used to acquire data processing tasks, calculate task granularity values ​​based on the computational and data volume characteristics of the tasks, and partition the tasks into a first queue or a second queue based on the comparison results of the task granularity values ​​and preset thresholds. The scheduling decision module is configured with a scheduling model to decide the task execution mode; wherein, tasks assigned to the first queue are executed locally on the terminal; tasks assigned to the second queue are executed locally on the terminal or offloaded to the computing module for execution based on the task's state vector, as decided by the scheduling model. The control execution module is used to execute tasks that are performed locally on the terminal; The model update module is used to build experience samples after the task is completed, and to dynamically update and optimize the network parameters of the scheduling model through a priority experience replay mechanism. A computing module is used to execute tasks offloaded to a second queue for execution by the computing module. The cloud is used to periodically aggregate the operating status and feedback data of the terminal and the computing module. The feedback data includes the local execution results of the terminal execution module and the execution results of the computing module, so as to perform global optimization training on the scheduling model and send the updated model parameters to the terminal through the cloud-edge control channel.

[0075] Furthermore, the computing module is an AI computing module, including an inference acceleration module, a feature extraction module, and a real-time analysis module; wherein: The inference acceleration module adopts a heterogeneous hardware architecture consisting of a general-purpose central processing unit (CPU) and a neural network processor (NPU). The CPU serves as the heterogeneous control core, used to carry out heterogeneous communication, task container management, and conventional control logic for non-matrix calculations. The NPU serves as the computing power acceleration core, specifically used to execute large-dimensional matrix calculations and forward inference tasks of AI models, leveraging its hardware advantages of large-scale parallel computing and high efficiency and low power consumption. The feature extraction module is used to extract deep feature matrices from multi-source data sent by the terminal and transform the extracted feature data into a standardized data matrix with a unified feature dimension. This provides a standardized input interface for various subsequent power grid analysis algorithms, avoids redundant data cleaning and feature transformation processing of the same type of original data by multiple independent algorithms, and reduces computing power consumption. The real-time analysis module is used to carry out and execute the tasks (computation-intensive tasks) of the second queue, and return the execution results to the terminal after completion to support the rapid response decision of the scheduling model. When the real-time analysis module is executed, it is able to efficiently run the forward inference process of time series prediction algorithms, including the Long Short-Term Memory (LSTM) algorithm and the TimeNet algorithm, based on the underlying computing power support of the inference acceleration module.

[0076] Data flow description between modules: Data flow encompasses two dimensions: first, the data flow between the cloud main station, the intelligent fusion terminal, and the AI ​​computing module; and second, the data flow between the various modules within the AI ​​computing module. The following sections will explain these two dimensions of data flow: Dimension 1: Data flow between cloud and edge modules (1) Cloud Main Station → Intelligent Converged Terminal: The cloud main station serves as the global model training and version management center. It gathers the running status data and task execution feedback reported by terminals in various regions to build a training set. Based on historical data and feedback, it incrementally trains and optimizes the scheduling model to generate updated model parameters. The data is distributed to various intelligent converged terminals via a lightweight cloud-edge channel. i Local update scheduling model parameters , This is a mapping function.

[0077] (2) Intelligent converged terminal → AI computing module: Intelligent converged terminal i As a node for on-site task scheduling and collaborative decision-making, it aggregates multi-source data from the transformer area in real time to construct a state vector. The PRIME-AC scheduling model dynamically determines the execution position of tasks in each HP queue. When the decision is to offload, the terminal sends the task and its parameters to the AI ​​computing module via the USB RNDIS high-speed channel to achieve task scheduling. (Intelligent Converged Terminal) i For the task j The scheduling decision is represented as .

[0078] (3) AI computing module → intelligent fusion terminal: As an edge-side complex inference and computing power enhancement unit, the AI ​​computing module receives and parses the tasks offloaded by the terminal and calls the parameters of the deployed AI model. Perform reasoning calculations , Represents inference operators; encapsulates inference results. The results are then returned to the intelligent fusion terminal via the USB RNDIS channel, allowing the terminal to generate the final decision based on the fusion inference results.

[0079] Dimension Two: Data Flow Between Modules Within the AI ​​Computing Module (1) Intelligent Fusion Terminal → Feature Extraction Module: The intelligent fusion terminal transmits the raw multi-source data to the feature extraction module of the AI ​​computing module through the USB RNDIS channel. The feature extraction module performs deep feature matrix extraction on the received multi-source data, transforms the raw data into a standardized data matrix with a unified feature dimension, and stores it in the shared memory area on the module side, avoiding repeated data cleaning and feature transformation processing of the same type of raw data by multiple independent algorithms.

[0080] (2) Feature extraction module → Inference acceleration module: The CPU control core of the inference acceleration module reads the standardized data matrix from the shared memory area, allocates the matrix calculation part (large-dimensional matrix operation and AI model forward inference) to the NPU for execution according to the task scheduling instructions, and keeps the non-matrix calculation control logic part in the CPU processing, so as to realize the heterogeneous collaborative computing of CPU and NPU.

[0081] (3) Task scheduling → Real-time analysis module: The terminal scheduling decision module sends the tasks that are decided to be unloaded in the HP queue to the real-time analysis module of the computing module. The real-time analysis module obtains the corresponding standardized data matrix from the shared memory area, loads the corresponding AI inference model (such as LSTM, TIMENET time series prediction model), and calls the NPU inference acceleration module to perform forward inference.

[0082] (4) Real-time analysis module → intelligent fusion terminal: The real-time analysis module encapsulates the inference results into JSON format and returns them to the terminal via the USB RNDIS channel. The terminal's local control execution module integrates the inference results to generate local decision instructions, enabling rapid response at the edge; the model update module calculates the reward function based on the inference results and actual execution feedback, and constructs experience samples for subsequent dynamic updates of the scheduling model parameters.

[0083] Furthermore, to achieve adaptive dynamic scheduling in the variable environment of low-voltage distribution networks, the terminal performs adaptive computing power prediction during operation. The computing power prediction is entirely implemented at the edge, and the specific prediction method is as follows: (1) Prediction Principle: Various computing tasks carried on the edge side (such as time series prediction, anomaly detection, feature extraction, etc.) are executed at preset intervals, and different tasks have different execution frequencies (such as second-level, minute-level, etc.). At any given time, the actual CPU load on the edge side depends on the number and computing intensity of each task being executed at that time. At the same time, due to differences in individual factors such as topology, scale of access devices, and number of measurement points, different distribution areas have different sets of computing tasks deployed, resulting in significant differences in the load fluctuation patterns of each distribution area. Based on the above regularity, by statistically analyzing historical CPU usage time and combining it with the execution frequency of each task, it is possible to effectively predict the future computing power occupancy.

[0084] (2) Prediction Method: The intelligent fusion terminal records CPU utilization at a fixed time granularity (1 second) and maintains a scheduling cycle table for each computing task (recording the execution cycle and estimated execution time of each task). At each scheduling time t, the terminal determines the tasks to be executed at the current time based on the scheduling cycle table, queries historical CPU utilization records for the same time within several past scheduling cycles, and calculates the predicted CPU utilization for the current time using a weighted moving average: ,in The least common multiple of the scheduling period. The weight is decayed (the more recent the historical record, the greater the weight).

[0085] (3) Application of prediction results: Based on the predicted CPU utilization rate, calculate the future available computing power on the edge side: ,in This represents the total computing power at the edge. When the predicted available computing power is below a safety threshold, the scheduling model increases the tendency to offload tasks to the computing module when outputting actions, allocating more HP queue tasks to the NPU of the AI ​​computing module for execution, thereby reducing the CPU load on the terminal. When the predicted available computing power is sufficient, more tasks can remain on the terminal for execution, reducing the dependence on the module.

[0086] (4) Personalized Adaptation: Since the prediction is based entirely on the historical CPU utilization data of this area, it naturally includes personalized factors such as the unique topology, equipment scale, and task configuration of this area, without the need for additional modeling. After running for a period of time, the newly deployed area can accumulate enough historical data to form an effective predictive capability, achieving immediate adaptation upon deployment.

[0087] This embodiment is based on a cloud-edge collaborative architecture, which constructs a three-layer collaborative computing system consisting of a cloud master station, an intelligent fusion terminal, and an AI computing module. Combined with computing power prediction and dynamic scheduling mechanisms, it enables on-site data processing and global collaborative optimization in gray-domain perception scenarios.

[0088] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A cloud-edge collaborative task scheduling method for gray-domain perception in low-voltage distribution networks, characterized in that, The method relies on a collaborative system composed of cloud, terminal, and computing module. It is applied to low-voltage distribution network areas in a gray-domain state where measurement coverage is incomplete and data blind spots exist. The low-voltage distribution network gray-domain perception utilizes the computing power of the terminal and computing module through a cloud-edge collaborative architecture to monitor and reconstruct the operating status of the low-voltage distribution network area. The method includes: The terminal receives data processing tasks, calculates task granularity values ​​based on the computational and data volume characteristics of the tasks, and divides the tasks into a first queue or a second queue based on the comparison results between the task granularity values ​​and a preset threshold. Tasks assigned to the first queue are executed locally on the terminal; a state vector is constructed for tasks assigned to the second queue, and the state vector is input into a scheduling model pre-deployed on the terminal side; The scheduling model determines whether the task is executed locally on the terminal or offloaded to the computing module based on the state vector. After the task is completed, an experience sample containing the current state vector, target action, task execution reward, and next state vector is constructed; the priority of the experience sample is calculated, and the experience sample with priority label is stored in the experience replay pool; a priority experience replay mechanism is used to select samples to be learned from the experience replay pool, and importance sampling weights are introduced to correct the loss function in order to dynamically update the network parameters of the scheduling model. The task execution reward is calculated by weighting latency penalty and load imbalance penalty; wherein, the latency penalty is calculated based on the current task's computation latency and the communication transmission latency caused by task unloading; the load imbalance penalty is the root mean square error of the real-time load rate of the computing node currently participating in the computation relative to the average load rate of each computing node; the computing node includes the local computing power node on the terminal side and the computing power node on the computing module side. The cloud periodically aggregates the operating status and feedback data of the terminal and the computing module to perform global optimization training on the scheduling model, and sends the updated model parameters to the terminal through the cloud-edge control channel.

2. The method according to claim 1, characterized in that, The task granularity value calculation includes: normalizing the total computational cost required for task execution to obtain a normalized computational cost, normalizing the sum of the input data and expected output data of the task to obtain a normalized data volume, and the task granularity value is obtained by weighted summation of the normalized computational cost and the normalized data volume.

3. The method according to claim 1, characterized in that, Tasks with a granularity value less than the preset threshold are assigned to the first queue, and tasks with a granularity value greater than or equal to the preset threshold are assigned to the second queue; wherein, the preset threshold is set based on the statistical quantile of the historical task granularity value distribution.

4. The method according to claim 1, characterized in that, The state vector includes the normalized computational cost of the task, the normalized data volume of the task, the current effective transmission bandwidth between the terminal and the computing module, and the task granularity value.

5. The method according to claim 1, characterized in that, The experience replay pool uses a binary tree structure to store each experience sample with a priority label; the selection of samples to be learned from the experience replay pool using a priority experience replay mechanism includes: During sampling, the probability of each experience sample being sampled is determined based on the proportion of the priority of each experience sample to the total priority of all experience samples in the current experience replay pool. Based on the total number of samples and the probability of each empirical sample being sampled, the importance sampling weight is calculated, and the loss function is corrected by the importance sampling weight to eliminate the scheduling model network parameter update deviation caused by sampling.

6. The method according to claim 5, characterized in that, The priority of the empirical samples is calculated based on the temporal difference error of the empirical samples; The calculation of the temporal difference error of the empirical sample includes: The scheduling model includes a policy network and a value evaluation network. The value evaluation network is used to calculate the expected value of the current state, and the task execution reward and the expected value of the next state are combined to jointly calculate the temporal difference error of the current state-action pair.

7. The method according to claim 6, characterized in that, When updating the network parameters of the scheduling model, the parameters of the policy network are optimized and updated using the stochastic gradient ascent method based on the temporal difference error and the importance sampling weights; the parameters of the value evaluation network are optimized and updated using the stochastic gradient descent method based on the temporal difference error and the importance sampling weights.

8. A cloud-edge collaborative task scheduling system for gray-domain perception in low-voltage distribution networks, used to implement the method described in any one of claims 1 to 7, characterized in that, The system includes: The terminal, deployed on the low-voltage distribution network side, is equipped with a data processing module, a queue partitioning module, a scheduling decision module, a control execution module, and a model update module; among which: The data processing module is used to acquire multi-source data from the distribution area in real time and to preprocess the data. The queue partitioning module is used to acquire data processing tasks, calculate task granularity values ​​based on the computational and data volume characteristics of the tasks, and partition the tasks into a first queue or a second queue based on the comparison results of the task granularity values ​​and preset thresholds. The scheduling decision module is configured with a scheduling model to decide the task execution mode; wherein, tasks assigned to the first queue are executed locally on the terminal; tasks assigned to the second queue are executed locally on the terminal or offloaded to the computing module for execution based on the task's state vector, as decided by the scheduling model. The control execution module is used to execute tasks that are performed locally on the terminal; The model update module is used to build experience samples after the task is executed, and to dynamically update and optimize the network parameters of the scheduling model through a priority experience replay mechanism. A computing module is used to execute tasks offloaded to a second queue for execution by the computing module. The cloud is used to periodically aggregate the operating status and feedback data of the terminal and the computing module to perform global optimization training on the scheduling model, and to send the updated model parameters to the terminal through the cloud-edge control channel.

Images