Cloud edge collaboration-based power grid intelligent fusion terminal optimization scheduling method and system

Abstract

This invention discloses a method and system for optimized scheduling of smart grid converged terminals based on cloud-edge collaboration, relating to the field of smart distribution network technology. The method includes: collecting state datasets of smart grid converged terminals through a cloud-edge collaborative sensing network; constructing an uncertainty quantification model to predict service delays and generate terminal scheduling decision results; constructing a two-layer closed-loop feedback mechanism including short-term and long-term dual feedback loops to generate scheduling effect and scheduling parameter optimization suggestions, respectively; and iteratively updating the terminal scheduling decision results based on these two suggestions to generate an optimized terminal scheduling scheme. This invention solves the technical problems in smart grid converged terminal scheduling scenarios, such as dynamic fluctuations in service execution time, resource allocation imbalances in single-level scheduling modes, and the lack of a continuous correction and control mechanism. It achieves on-demand allocation of terminal resources and dynamic correction of task execution status, improving scheduling accuracy, stability, and resource utilization efficiency.

Description

Technical Field

[0001] This invention relates to the field of smart distribution network technology, and in particular to a method and system for optimizing and scheduling smart distribution network terminals based on cloud-edge collaboration. Background Technology

[0002] Digital information transmission is widely used in power grid cloud-edge collaborative scenarios. As the core node for digital information transmission and scheduling, the optimized scheduling effect of the power grid intelligent converged terminal directly affects the stable operation of the power grid, the quality of digital information transmission, and the reliable operation of equipment. The real-time performance and stability of digital information transmission are crucial foundations for ensuring collaborative scheduling of terminals. Existing technologies mostly employ centralized scheduling or single-node autonomous scheduling, relying on conventional latency estimation and fixed priorities to complete digital information transmission and terminal scheduling, which is applicable in conventional power grid scenarios. However, due to large fluctuations in power grid business load and uncertainties in digital information transmission, existing technologies are prone to causing imbalances in terminal resources, excessive digital information transmission latency, and incomplete and inaccurate scheduling data, making it difficult to meet the needs of efficient scheduling and stable management of digital information transmission for power grid intelligent converged terminals. Summary of the Invention

[0003] This application provides a cloud-edge collaborative method and system for optimizing the scheduling of smart grid converged terminals. It solves the technical problems in the scheduling scenario of smart grid converged terminals, such as the dynamic fluctuation of business execution time, the resource allocation imbalance in single-level scheduling mode, and the lack of a continuous correction and control mechanism.

[0004] The first aspect of this application provides a method for optimized scheduling of smart converged terminals in a power grid based on cloud-edge collaboration. The method includes: collecting data from smart converged terminals in a power grid via a cloud-edge collaborative sensing network to obtain a converged terminal status dataset; constructing an uncertainty quantification model to predict service latency on the converged terminal status dataset to obtain service latency prediction results; performing multi-level joint scheduling based on the service latency prediction results to generate terminal scheduling decision results; constructing a two-layer closed-loop feedback mechanism, which includes a short-term feedback loop and a long-term feedback loop; monitoring the terminal scheduling decision results in real time through the short-term feedback loop to generate scheduling effects; performing data mining on the scheduling effects through the long-term feedback loop to generate scheduling parameter optimization suggestions; and iteratively updating the terminal scheduling decision results based on the scheduling effects and the scheduling parameter optimization suggestions to generate an optimized terminal scheduling scheme.

[0005] A second aspect of this application provides a cloud-edge collaborative smart grid converged terminal optimization scheduling system. The system includes: a converged terminal status dataset acquisition module, used to collect data from smart grid converged terminals via a cloud-edge collaborative sensing network to obtain a converged terminal status dataset; a terminal scheduling decision result generation module, used to construct an uncertainty quantification model to predict service delays on the converged terminal status dataset, obtain service delay prediction results, and perform multi-level joint scheduling based on the service delay prediction results to generate terminal scheduling decision results; a long-term and short-term feedback loop construction module, used to construct a two-layer closed-loop feedback mechanism, the two-layer closed-loop feedback mechanism including a short-term feedback loop and a long-term feedback loop; a scheduling parameter optimization suggestion generation module, used to monitor the terminal scheduling decision results in real time through the short-term feedback loop to generate scheduling effects, and perform data mining on the scheduling effects through the long-term feedback loop to generate scheduling parameter optimization suggestions; and a terminal optimized scheduling scheme generation module, used to iteratively update the terminal scheduling decision results based on the scheduling effects and the scheduling parameter optimization suggestions to generate a terminal optimized scheduling scheme.

[0006] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0007] This application achieves dynamic adaptation of terminal services and efficient allocation of resources by collecting terminal status and service operation data across the entire domain in the scenario of smart grid converged terminal operation. Through uncertainty quantification analysis and multi-level collaborative scheduling processing, service latency and resource status data are obtained, service execution priority and node load matching information are calculated, and iterative adjustments are made in combination with real-time operation feedback and long-term optimization suggestions. This results in the technical effects of on-demand allocation of terminal resources and dynamic correction of task execution status, thereby improving the accuracy, stability and resource utilization efficiency of scheduling. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a flowchart illustrating the optimized scheduling method for a smart grid fusion terminal based on cloud-edge collaboration provided in this application embodiment.

[0010] Figure 2 This is a schematic diagram of the structure of the smart grid fusion terminal optimization scheduling system based on cloud-edge collaboration provided in the embodiments of this application.

[0011] Figure labeling: Module 1 for acquiring fused terminal status dataset, Module 2 for generating terminal scheduling decision results, Module 3 for constructing long-term and short-term feedback loops, Module 4 for generating scheduling parameter optimization suggestions, and Module 5 for generating terminal optimized scheduling schemes. Detailed Implementation

[0012] This application provides a cloud-edge collaborative method and system for optimizing the scheduling of smart grid converged terminals. It solves the technical problems in the scheduling scenario of smart grid converged terminals, such as the dynamic fluctuation of business execution time, the resource allocation imbalance in single-level scheduling mode, and the lack of a continuous correction and control mechanism.

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0014] It should be noted that the terms "first," "second," etc., in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0015] Example 1, as Figure 1 As shown, a smart grid fusion terminal optimization scheduling method based on cloud-edge collaboration is described, wherein the method includes: Data is collected from the smart fusion terminal of the power grid through a cloud-edge collaborative sensing network to obtain the fusion terminal status dataset.

[0016] In this embodiment, the cloud-edge collaborative sensing network is an integrated IoT sensing and transmission network composed of power grid field terminals, edge nodes, and a cloud platform, used for collecting power equipment operation and business data across the entire domain. The power grid intelligent fusion terminal is a core intelligent hardware device on the distribution side deployed in distribution substations and line sites, integrating data acquisition, edge computing, and communication interaction functions.

[0017] Specifically, standardized sensing units are deployed on the smart grid converged terminal, edge node server, and cloud scheduling server to construct a cloud-edge collaborative sensing network with full end-to-end coverage. A combination of periodic polling and event-triggered data collection is used to collect operational status and business load data from the smart grid converged terminal. Periodic polling continuously acquires operational status information such as terminal computing power utilization, memory availability, communication bandwidth, link real-time latency, and node CPU load at fixed time intervals of 100ms to 500ms. Event-triggered data collection is initiated immediately when a new business request is generated by the terminal, acquiring information such as the business request type, data packet length, request deadline, and the pending business load information of the target processing node.

[0018] Next, edge data preprocessing method is adopted to standardize the collected raw data. Abnormal data with values ​​exceeding reasonable threshold range are removed by the 3σ criterion. Data with missing fields are filled with valid values ​​from the previous collection period of the same terminal. The format of heterogeneous data is uniformly converted according to IEC 60870-5-104 power system transmission protocol. Then, data is aligned and classified according to the unique terminal identifier and collection timestamp to form standardized time-series status data corresponding to a single terminal.

[0019] Then, the MQTT-SN transmission protocol, commonly used in the power Internet of Things (IoT), is adopted to complete standardized data transmission between edge nodes and the cloud server. After completing the preprocessing operation of each collection cycle, the edge nodes upload the collected standardized terminal data to the cloud server. After receiving the data, the cloud server identifies data with the same unique terminal identifier and the same collection timestamp as duplicate data, directly removes duplicate entries to complete cross-node data deduplication, verifies the continuity of data timestamps, and replenishes terminal data that is missing for more than 3 consecutive collection cycles by calling historical valid values ​​cached by the edge nodes. Finally, the data is integrated according to the time series to generate a fused terminal status dataset covering all online smart grid fused terminals.

[0020] Through standardized edge-cloud collaborative data collection, preprocessing and integration processes, the complete and standardized collection of full-dimensional operation and business data of the smart grid fusion terminal has been realized, providing a standardized data foundation with time alignment and complete dimensions for subsequent uncertainty quantification prediction and multi-level joint scheduling.

[0021] An uncertainty quantification model is constructed to predict service latency on the converged terminal status dataset, and the service latency prediction results are obtained. Based on the service latency prediction results, multi-level joint scheduling is performed to generate terminal scheduling decision results.

[0022] In this embodiment of the application, the uncertainty quantification model is a calculation model built on Monte Carlo random sampling and Gaussian statistical rules. It is used to perform random extrapolation calculations on the service delay of the smart grid converged terminal, quantify the degree of service delay fluctuation, and provide quantitative numerical basis for the division of service scheduling priorities.

[0023] Optionally, multi-dimensional feature vectors are extracted based on the converged terminal status dataset. The vectors are then subjected to multiple random forward propagations using an uncertainty quantification model to obtain latency prediction distribution samples. The mean and variance of the samples are calculated and used as service latency estimates and uncertainty quantification indicators, respectively. Service request scheduling priorities are assigned based on these indicators. Finally, multi-level joint scheduling is performed in conjunction with the latency estimates to generate terminal scheduling decision results.

[0024] A two-layer closed-loop feedback mechanism is constructed, which includes a short-term feedback loop and a long-term feedback loop.

[0025] In one embodiment of this application, the two-layer closed-loop feedback mechanism specifically includes a short-term feedback loop and a long-term feedback loop, the construction process of which is described below: For the short-term feedback loop, the real-time monitoring agent module of the edge node server is invoked to collect the execution status of the terminal scheduling decision results at the first time granularity and extract the execution log. Based on the execution log analysis, the actual processing latency data is generated and the terminal resource utilization rate is calculated. The two types of data are integrated to form a short-cycle monitoring data stream. Based on this data stream, a short-term feedback loop is constructed and deployed to the edge node server. The specific implementation process of this step will be described in detail below.

[0026] For the long-term feedback loop, a long-term feedback loop is constructed based on the cloud-side global scheduling layer of the power grid dispatching cloud platform. The input of this loop is defined as the full dispatching effect data collected by each edge node through the short-term feedback loop, which is then uploaded after standardization processing. The data transmission adopts the MQTT-SN transmission protocol, and a fixed data synchronization period of 24 hours is set. The full dispatching effect data of the previous day is synchronized at midnight every day. The InfluxDB time-series database, which is commonly used in the power system, is used as the core data storage carrier of the loop. A complete closed-loop data path is built from edge node data upload, cloud-side time-series data storage, long-term data mining and analysis, to the distribution of dispatching parameter optimization suggestions to the edge-side collaborative scheduling layer and the end-side scheduling layer. The output of the loop is defined as dispatching parameter optimization suggestions that can be directly applied to the adjustment of dispatching strategies. The completed long-term feedback loop is fixedly deployed and run on the cloud-side global scheduling layer, providing a stable closed-loop data path and standardized operating carrier for subsequent long-term mining and analysis of dispatching effect data and optimization of dispatching strategies.

[0027] The terminal scheduling decision results are monitored in real time through the short-term feedback loop to generate scheduling effects. The scheduling effects are then analyzed through data mining through the long-term feedback loop to generate suggestions for optimizing scheduling parameters.

[0028] Specifically, firstly, multiple sampling periods are set according to the real-time monitoring agent module. The execution logs are identified according to business requests and business request identifiers are generated. The business request identifiers are associated and concatenated according to time nodes to obtain execution trajectory data. A sliding monitoring time window containing time length and sliding step size is set. The execution trajectory data is classified in multiple dimensions according to the sliding step size to generate scheduling effect. The specific implementation process of this step will be described in detail below.

[0029] Next, the scheduling effect is stored in the cloud-side time-series database to form a historical dataset of scheduling effect. This dataset is then divided into continuous analysis segments, and the business load is analyzed and the load feature vector is extracted. The performance degradation segments are identified and clustered to obtain candidate degradation business mode clusters. After statistical verification, high-risk business modes are identified. A mapping table between scheduling effect and policy parameters is constructed for high-sensitivity data analysis. After extracting key policy parameters, optimization suggestions for scheduling parameters are formed. The specific implementation process of this step is also described in detail below.

[0030] Based on the scheduling effect and the optimization suggestions for scheduling parameters, the terminal scheduling decision results are iteratively updated to generate an optimized terminal scheduling scheme.

[0031] Specifically, based on the scheduling effect, the delay deviation index is extracted to calculate the short-term adjustment weight. The scheduling parameter optimization suggestions are analyzed to extract the target adjustment value and recommended adjustment step size sequence of the parameters to be adjusted. After long-term analysis, a long-term adjustment baseline is set and its fusion weight is determined according to the short-term adjustment weight. The recommended adjustment compensation sequence and the delay deviation index are combined to perform parameter correction and weighted summation to obtain the incremental parameter update amount. The terminal scheduling decision result is iteratively updated using this update amount to generate the terminal optimized scheduling scheme. The specific implementation process of this step will be described in detail below.

[0032] Furthermore, the method provided in this application embodiment includes: Multidimensional feature analysis is performed on the fused terminal status dataset to extract multidimensional feature vectors. Multiple random forward propagations are then performed on these multidimensional feature vectors using the uncertainty quantification model to generate latency prediction distribution sample data. Based on this latency prediction distribution sample data, the predicted latency is calculated, yielding the mean and variance of the predicted latency. The mean predicted latency is used as the estimated service latency, and the variance of the predicted latency is quantified as an uncertainty quantification index. The estimated service latency and the uncertainty quantification index are added to the service latency prediction result. Based on the uncertainty quantification index, service requests are prioritized, generating multiple priorities. Multi-level joint scheduling is performed according to these multiple priorities and the estimated service latency, generating the terminal scheduling decision result.

[0033] Specifically, firstly, multi-dimensional feature analysis is conducted based on the converged terminal status dataset to extract key features strongly correlated with service latency, including service type, data length, link real-time rate, node CPU load, and node available computing power. The extracted discrete service type features are converted into numerical form using one-hot encoding, and the continuous numerical features are normalized using the min-max normalization method to map all feature values ​​to the range of 0 to 1, completing the feature standardization process. Finally, a fixed-dimensional multi-dimensional feature vector is constructed as the input data for the uncertainty quantification model.

[0034] Then, an uncertainty quantification model combining Monte Carlo random sampling and Gaussian statistics is adopted. This model directly completes the calculation based on the input multidimensional feature vector, and the output of the model is the delay prediction distribution sample data. The number of random samplings is set to 50 to 100 times. Multiple random forward propagations are performed on the constructed multidimensional feature vector. During each propagation, a uniform random perturbation within ±10% is applied to the two time-varying features in the feature vector: the link real-time rate and the node CPU load. The parameters after perturbation do not exceed the reasonable value range of their physical meaning, generating feature parameters for a single propagation. Based on the feature parameters of the single propagation, the delay is calculated according to the single-sample delay calculation formula. The single-sample delay is the sum of the transmission delay and the node processing delay, where the transmission delay is the ratio of the service data length to the link real-time rate after perturbation, and the node processing delay is the ratio of the service data length to the product of the node's available computing power and the remaining load coefficient after perturbation. The remaining load coefficient is the difference between 1 and the node's CPU load after perturbation. Each calculation yields an independent delay prediction value. After a set number of propagation calculations, a complete set of delay prediction distribution sample data is generated.

[0035] Next, calculations are performed on the obtained latency prediction distribution sample data. Specifically: first, the arithmetic mean of all sample data is calculated to obtain the mean of predicted latency; then, the root mean square error between all sample data and the mean of predicted latency is calculated to obtain the variance of predicted latency. The calculated mean of predicted latency is used as the estimated value of business latency, and the variance of predicted latency is directly used as the uncertainty quantification index. The estimated value of business latency and the uncertainty quantification index are added together to the business latency prediction result, completing the entire process of business latency prediction and uncertainty quantification.

[0036] Next, the queue of pending business requests from the smart grid converged terminal is retrieved, each business request in the queue is traversed and its uncertainty quantification index is matched, the index is compared with the range of multi-level uncertainty thresholds, and the business requests are divided into first, second and third priority processing levels according to the high, medium and low uncertainty ranges in which the index falls. This step will be explained in detail in the following content.

[0037] Finally, a three-tiered scheduling hierarchy of terminal, edge, and cloud is constructed. Based on the service scheduling priority and the service latency estimate, a three-tiered progressive collaborative scheduling is implemented. High-priority services are scheduled locally on the terminal side, while medium- and low-priority services are calculated and target edge nodes are selected on the edge side to complete conflict coordination. The terminal and edge scheduling results are aggregated to the cloud to build a global load distribution view, identify idle and overloaded edge nodes and complete resource reallocation. After integrating the resource reconfiguration instructions and the terminal and edge scheduling results, the terminal scheduling decision result is generated. This step will also be explained in detail in the following sections.

[0038] By standardizing feature extraction from the fusion terminal status dataset, and constructing an uncertainty quantification model using Monte Carlo random sampling and Gaussian statistical methods, the random disturbance rules and single-sample delay calculation methods were clarified. This fully realized the accurate prediction and uncertainty quantification of the service delay of the smart fusion terminal of the power grid, providing a reliable and quantifiable basis for service delay prediction for subsequent multi-level joint scheduling.

[0039] Furthermore, the method provided in this application embodiment includes: The system retrieves the pending service request queue from the smart grid convergence terminal, iterates through the queue, and matches it against uncertainty quantification indicators to generate matching results. It then defines a multi-level uncertainty threshold range, including high uncertainty, medium uncertainty, and low uncertainty intervals. Finally, it compares the uncertainty quantification indicators with the multi-level uncertainty threshold ranges and performs matching based on the comparison results and the matching results: S1: Service requests falling into the high uncertainty interval are classified as first priority processing level; S2: Service requests falling into the medium uncertainty interval are classified as second priority processing level; S3: Service requests falling into the low uncertainty interval are classified as third priority processing level.

[0040] In this embodiment, the pending service request queue is an ordered list of various power service requests that are cached and queued locally by the smart grid fusion terminal according to the request access time and are waiting for scheduling and processing.

[0041] Optionally, firstly, the queue of pending business requests cached locally in the smart grid converged terminal is retrieved, and the queue is processed sequentially by reading the business request information in the queue one by one. Based on the unique business identifier, each business request is associated and bound with the corresponding calculated uncertainty quantification index, so as to achieve a one-to-one correspondence between business requests and quantification indexes and form a complete business index matching result.

[0042] Next, historical data of all uncertainty quantification indicators generated within the past seven consecutive natural days of operation of the smart grid integrated terminal are collected and compiled into an indicator historical dataset. Using a ternary quantification method, all indicator values ​​in this dataset are sorted in ascending order from smallest to largest. The overall numerical distribution is evenly divided into three continuous numerical intervals according to the ternary division rule. The three intervals correspond to the numerical ranges of 0 to 33.3%, 33.3% to 66.6%, and 66.6% to 100%, respectively. Considering the operational characteristics of power terminal business dispatch, the numerical interval of 66.6% to 100% is defined as the high uncertainty interval, the numerical interval of 33.3% to 66.6% is defined as the medium uncertainty interval, and the numerical interval of 0 to 33.3% is defined as the low uncertainty interval. Multi-level uncertainty threshold ranges are defined in the above manner. The defined threshold ranges are automatically updated every 24 hours. During the update, the latest historical indicator dataset of the past seven consecutive natural days is used to re-divide the intervals.

[0043] Next, the uncertainty quantification indicators corresponding to each business request in the business indicator matching results are compared with the predefined multi-level uncertainty threshold range. Based on the interval position of the indicator value and the one-to-one matching relationship between the business and the indicator, the business requests are classified and categorized.

[0044] Finally, business requests with uncertainty quantification index values ​​belonging to the high uncertainty range are uniformly classified as the first priority processing level, business requests with uncertainty quantification index values ​​belonging to the medium uncertainty range are uniformly classified as the second priority processing level, and business requests with uncertainty quantification index values ​​belonging to the low uncertainty range are uniformly classified as the third priority processing level, thereby completing the scheduling priority classification setting for all pending business requests.

[0045] By traversing and matching business requests with uncertainty quantification indicators, and relying on the ternary statistical division method of historical periodic data to determine multi-level uncertainty threshold ranges and clarify update rules, the priority division of business requests is completed according to the range to which the indicators belong. This achieves standardized and reproducible level classification of business requests based on the differences in latency uncertainty, providing a regular and reliable business priority foundation for subsequent multi-level joint scheduling.

[0046] Furthermore, the method provided in this application embodiment includes: Construct an edge-side scheduling layer, an edge-side collaborative scheduling layer, and a cloud-side global scheduling layer; based on the multiple priorities and the estimated service latency, sequentially drive the edge-side scheduling layer, the edge-side collaborative scheduling layer, and the cloud-side global scheduling layer to perform a three-layer progressive collaborative scheduling process: S4: Submit the service requests of the first priority level to the edge-side scheduling layer for local scheduling and generate an edge-side scheduling result; S5: Submit the service requests of the second priority level and the service requests of the third priority level to the edge-side collaborative scheduling layer for edge computing to obtain the expected completion latency parameters of multiple edge nodes; S6: Traverse the expected completion latency parameters of the multiple edge nodes and perform minimization. S7: Extract values, determine target edge nodes for business conflict coordination, and generate edge-side scheduling results; S8: Aggregate and upload the end-side scheduling results and the edge-side scheduling results to the cloud-side global scheduling layer for analysis, and construct a global load distribution view; S9: Based on the global load distribution view, identify and mark nodes to determine multiple resource-idle edge nodes and multiple resource-overloaded edge nodes; S10: Reallocate resources according to the multiple resource-idle edge nodes and the multiple resource-overloaded edge nodes to generate cross-node resource reconfiguration instructions; S11: Merge the cross-node resource reconfiguration instructions with the end-side scheduling results and the edge-side scheduling results to generate the terminal scheduling decision results.

[0047] Specifically, firstly, based on the deployment method of the power Internet of Things edge-cloud collaborative architecture, a terminal-side scheduling layer, an edge-side collaborative scheduling layer, and a cloud-side global scheduling layer are constructed respectively. The terminal-side scheduling layer is deployed locally on each power grid smart converged terminal and is responsible for the local scheduling and execution of the terminal's own business. The edge-side collaborative scheduling layer is deployed according to the administrative division of distribution substations. Each edge-side collaborative scheduling layer corresponds to all power grid smart converged terminals within a distribution substation and is responsible for the collaborative allocation of medium and low priority business of multiple converged terminals within its jurisdiction. The cloud-side global scheduling layer is deployed on the power grid dispatch cloud platform and is responsible for the aggregation of dispatch data of terminals and edge nodes in all distribution substations of the entire network and the optimization and configuration of global resources, thus completing the construction of a three-layer progressive scheduling architecture.

[0048] After the scheduling hierarchy is constructed, based on the multiple priority division results of services and the corresponding service latency estimates, the three scheduling layers are sequentially driven to carry out collaborative scheduling processing. The specific steps are as follows: First, business requests classified as the first priority level are submitted to the terminal-side scheduling layer for local scheduling. The terminal-side scheduling layer uses a local resource real-time detection method to read the terminal's current available computing power, number of idle processing cores, and remaining memory space. Once it is confirmed that the terminal's local available computing power is ≥30% and the remaining memory space is ≥20%, it is determined that the conditions for business execution are met. Then, the business requests of this level are directly allocated to the terminal's local idle processing cores for execution. The execution unit and expected execution cycle of the business allocation are recorded, and the terminal-side scheduling result is generated.

[0049] Then, service requests classified into second and third priority processing levels are uniformly submitted to the edge-side collaborative scheduling layer. The edge-side collaborative scheduling layer first obtains real-time CPU load rate, available computing power, and real-time link bandwidth data for all online edge nodes within its jurisdiction. Combined with the estimated service latency corresponding to the service, and using the latency calculation formula consistent with the uncertainty quantification model in the previous steps, it calculates the expected completion latency parameters for each edge node after undertaking the corresponding service, forming multiple sets of expected completion latency datasets for each service request. A maximum service carrying threshold for edge nodes is pre-set; this threshold is 8 times the number of physical CPU cores of the edge node, corresponding to the maximum service queue length that the node can stably carry within a single cycle.

[0050] Subsequently, a linear traversal extreme value search method is adopted to traverse the expected completion delay parameters of all edge nodes in the dataset, extract the edge node corresponding to the smallest expected completion delay as the initial target edge node, and then perform a business conflict coordination operation. The length of the business queue currently allocated to the initial target edge node is checked. If the queue length does not exceed the node's preset maximum business capacity threshold, the business request is directly allocated to the initial target edge node; if the queue length exceeds the maximum capacity threshold, the edge node with the second smallest expected completion delay is selected as the final target edge node to complete business allocation and conflict avoidance, and finally generate the edge scheduling result.

[0051] Subsequently, the generated end-side scheduling results and edge-side scheduling results are aggregated and uploaded to the cloud-side global scheduling layer via the MQTT-SN transmission protocol. After receiving all scheduling results, the cloud-side global scheduling layer summarizes the service allocation, real-time load data, and resource occupancy status of all smart grid converged terminals and edge nodes across the entire network. Using a gridded data integration method, the data is classified and collected according to distribution area and node type to construct a global load distribution view covering all nodes across the entire network. This view marks the real-time load rate, available resource balance, and number of allocated services for each edge node.

[0052] Next, based on the completed global load distribution view, a node load rate judgment threshold is pre-set. For example, edge nodes with a real-time load rate that is continuously below 30% for more than 3 minutes are identified as resource idle edge nodes, and edge nodes with a real-time load rate that is continuously above 80% for more than 5 minutes are identified as resource overload edge nodes, thus completing the classification and identification of all network nodes.

[0053] Subsequently, based on the identified idle and overloaded edge nodes, a service reallocation operation is performed. All service requests of the third priority level within the overloaded edge node are migrated sequentially to the idle edge node with the lowest real-time load rate in the distribution network topology, according to the expected completion delay from smallest to largest. The physical link distance from the overloaded node is no more than 2 transformer intervals. Corresponding service migration instructions and node resource adjustment instructions are generated and integrated into a cross-node resource reconfiguration instruction.

[0054] Finally, the cloud-side global scheduling layer merges and integrates the generated cross-node resource reconfiguration instructions with the previously summarized end-side scheduling results and edge-side scheduling results to form a complete scheduling instruction set covering end-side local business execution, edge-side cross-terminal business collaborative allocation, and network-wide cross-node resource optimization and adjustment. This generates the final terminal scheduling decision result and sends it to the corresponding smart grid converged terminal and edge node for execution.

[0055] By constructing a three-layer progressive collaborative scheduling architecture of end-side, edge-side, and cloud-side, clarifying the execution boundaries and judgment rules of each layer, and combining the business priority division results and business latency estimates, the architecture performs local scheduling on the end-side, optimal node selection and conflict coordination on the edge-side, and global load balancing and resource reconfiguration on the cloud-side. This achieves hierarchical and precise scheduling of smart grid converged terminal services, effectively reducing the scheduling risks caused by business processing latency and latency uncertainty, and improving the collaborative utilization efficiency of end-side-cloud resources and the scheduling stability of power grid services.

[0056] Furthermore, the method provided in this application embodiment includes: The system retrieves the real-time monitoring agent module configured on the edge node server, collects terminal scheduling decision results at the first time granularity, and extracts execution logs. Based on the execution logs, it performs short-cycle processing latency analysis to generate actual processing latency data and calculates terminal resource utilization based on the execution logs. The system integrates the actual processing latency data and the terminal resource utilization rate to construct a short-cycle monitoring data stream. Based on the short-cycle monitoring data stream, it constructs a short-term feedback loop and connects it to the edge node server.

[0057] In this embodiment, the edge node server is a dedicated service device deployed locally within the distribution substation, connecting to all smart grid converged terminals within its jurisdiction, and undertaking edge computing, business collaborative scheduling, and local data aggregation and forwarding. The real-time monitoring agent module is a background program component that resides within the edge node server, responsible for automatically collecting terminal scheduling execution logs at a set time granularity, statistically processing latency and resource occupancy status, and organizing and outputting monitoring data.

[0058] Specifically, firstly, the real-time monitoring agent module permanently deployed inside the edge node server is invoked. It operates in a background process mode and periodically collects full data on the actual execution process of the terminal scheduling decision results according to the set first time granularity of 1 to 5 minutes. Using the unique business identifier as the core matching field, the data collection method of capturing logs one by one records key information such as the time of issuance of scheduling instructions, the time of business start-up and operation, the time of business completion, the terminal number to which the business belongs, and resource consumption details. After formatting, standardized business execution logs that are bound one-to-one with the terminal scheduling decision results are extracted.

[0059] Then, based on the collected execution logs, a time-series interpolation method is used, with each service's unique identifier as the unit, to calculate the overall time consumption from the issuance of the scheduling instruction to its completion. This completes short-cycle processing latency analysis, batch-compiles the time consumption information of all services, and generates actual processing latency data corresponding to each service. Simultaneously, the execution logs are read to obtain three core resource data types: terminal CPU utilization, memory usage, and communication link bandwidth usage. A weighted average normalized percentage conversion method is used to calculate the overall resource usage of the terminal, with CPU utilization accounting for 40%, memory usage for 30%, and communication link bandwidth usage for 30%. This weighted calculation yields the real-time updated terminal resource usage rate.

[0060] Next, the generated actual processing latency data and terminal resource utilization rate are time-aligned and matched according to a unified timestamp and a unique business identifier. Data is then merged using the same time sequence and identifier fields, associating and grouping latency and resource utilization values ​​corresponding to the same sampling time and the same business. Next, data frames are encapsulated in JSON format, arranged sequentially by time, with the data update frequency consistent with the first time granularity, constructing a continuous, standardized, short-cycle monitoring data stream. Data stream transmission also adopts the MQTT-SN transmission protocol commonly used in the power IoT.

[0061] Finally, based on the established short-cycle monitoring data stream, a closed-loop data feedback path is built according to the shared memory-based process communication mechanism within the edge node server. The input of the short-cycle feedback loop is defined as the short-cycle monitoring data stream, and the output is a real-time scheduling adjustment trigger signal sent to the edge-side collaborative scheduling layer. The trigger condition for data feedback is set as follows: the actual processing latency exceeds the estimated latency of the corresponding service by 20%, or the terminal resource utilization rate continuously exceeds 80% for two sampling cycles. When the trigger condition is met, the corresponding monitoring data is immediately sent back to the service scheduling processing link of the edge-side collaborative scheduling layer for dynamic adjustment of the service allocation strategy within the current scheduling cycle. This completes the logical construction of the short-cycle feedback loop. Finally, the completed short-cycle feedback loop is fixedly deployed and run in the edge node server to realize the real-time flow and closed-loop feedback of local scheduling execution data.

[0062] By establishing and deploying a short-term feedback loop with clear triggering rules and closed-loop regulation logic, the system has achieved short-cycle real-time acquisition and local closed-loop feedback of dispatch execution data from the smart grid integrated terminal. This provides a stable and continuous data foundation and closed-loop regulation path for subsequent real-time monitoring of dispatch effects and dynamic optimization of dispatch strategies.

[0063] Furthermore, the method provided in this application embodiment includes: The real-time monitoring agent module sets multiple sampling periods, and based on these multiple sampling periods, identifies the execution logs according to multiple service requests based on the terminal scheduling decision results, generating multiple service request identifiers. These service request identifiers are then associated and concatenated according to time nodes to generate execution trajectory data for multiple service requests. A sliding monitoring time window is set, comprising a time length and a sliding step size. Based on the sliding step size, the sliding monitoring time window is activated to perform multi-dimensional classification of the execution trajectory data according to time length, generating the scheduling effect.

[0064] Specifically, based on the real-time monitoring agent module deployed on the edge node server and combined with the monitoring requirements of the short-term feedback loop, multiple consecutive sampling periods of equal length with no overlap are set. The duration of a single sampling period is consistent with the first time granularity of the short-term feedback loop, and the duration of a single period is 1 to 5 minutes. Multiple sampling periods form a continuous and uninterrupted collection sequence. A periodic triggering control method is adopted to allow the real-time monitoring agent module to continuously collect the execution process of the terminal scheduling decision results according to the set sampling period sequence. Meanwhile, a three-segment field consisting of a unique terminal number, a service request access timestamp, and a service priority code is used as the core identifier. A globally unique service request identifier is generated using a decimal number encoding method. The unique terminal number is a fixed and unique code assigned across the entire network. The service request access timestamp is accurate to milliseconds. The service priority code corresponds to three priority levels with values ​​of 1, 2, and 3, respectively, ensuring the global uniqueness of the identifier in multi-terminal and multi-service parallel scenarios. An item-by-item matching method is used to mark each collected execution log and assign a corresponding unique service request identifier to each independent service request, ensuring that each service request corresponds one-to-one with its corresponding execution log. After batch processing, multiple unique service request identifiers are generated.

[0065] Next, a time-series association and splicing method is adopted, using time nodes as the connecting thread, to associate and integrate all execution log entries corresponding to the same business request identifier in ascending order of timestamps, splicing them into complete business execution chain data. Specifically, the scheduling instruction issuance log, business startup and operation log, business execution process log, and business completion log corresponding to the same business request identifier are sequentially linked in chronological order, completely recording the time nodes and status information of the entire process from scheduling issuance to execution completion of the business request, and finally generating unique execution trajectory data for each business request, realizing the traceability of the business execution process. At the same time, the processing rules for execution trajectory data across sliding monitoring time windows are clarified. For business request execution trajectory data whose execution cycle spans multiple sliding monitoring time windows, the principle of business completion time allocation is adopted, and the complete execution trajectory data is completely included in the sliding monitoring time window where the business execution completion time is located, without splitting, to avoid data duplication or omission.

[0066] Next, set the sliding monitoring time window and clarify the two core parameters of the sliding monitoring time window. For example, the time length is set to 30 minutes and the sliding step is set to 10 minutes. Both parameters use fixed values. The time length is used to limit the time range of a single monitoring analysis, and the sliding step is used to determine the time interval for each window movement.

[0067] Based on the set sliding step size, the window is activated by a window cyclic sliding trigger method. The window starts from the starting time node of the execution trajectory data and slides forward in 10-minute steps. After each slide, the window covers the execution trajectory data within 30 minutes. Next, the execution trajectory data within the window is categorized according to three fixed dimensions. The first dimension is the business priority dimension, which is divided into three categories: first priority processing level, second priority processing level, and third priority processing level. The second dimension is the actual processing latency dimension, which is divided into acceptable range, slightly exceeding range, and severely exceeding range. The acceptable range is where the actual processing latency does not exceed 120% of the estimated latency of the corresponding business. The slightly exceeding range is where the actual processing latency is 120% to 200% of the estimated latency of the corresponding business. The severely exceeding range is where the actual processing latency exceeds 200% of the estimated latency of the corresponding business. The third dimension is the terminal resource utilization rate dimension, which is divided into low load range, normal load range, and high load range. The low load range is where the terminal resource utilization rate does not exceed 30%. The normal load range is where the terminal resource utilization rate is 30% to 80%. The high load range is where the terminal resource utilization rate exceeds 80%.

[0068] After classification, key statistical data such as the number of services, proportion, and average value under each dimension are statistically analyzed. First, the resource occupancy rate of each smart grid converged terminal within the sliding monitoring time window is extracted, and the overall average value of the resource occupancy rate of all terminals is calculated. The squared difference between the resource occupancy rate of a single terminal and the overall average value is calculated and the variance is calculated. Then, the variance is normalized and mapped to the interval between 0 and 1 to obtain the resource load balance value. After that, the three core quantitative indicators of service completion rate, latency compliance rate, and resource load balance within the sliding monitoring time window are integrated and calculated. After integrating all the classification statistical results with the core quantitative indicators, a standardized scheduling effect dataset that can intuitively reflect the execution of terminal scheduling decisions is generated.

[0069] Through the above-mentioned sequential steps, unambiguous real-time monitoring of the execution process of terminal scheduling decision results and standardized quantitative presentation of scheduling effects are achieved, providing accurate and analyzable unified basic data for subsequent data mining and scheduling parameter optimization in the long-term feedback loop.

[0070] Furthermore, the method provided in this application embodiment includes: The scheduling effects are stored in a cloud-based time-series database to generate a historical scheduling effect dataset. This dataset is then divided into multiple continuous analysis segments for business load analysis, extracting load feature vectors. Deterioration is determined based on these segments, and multiple performance degradation segments are clustered using the load feature vectors to generate candidate deterioration business pattern clusters. These clusters are then statistically verified to generate high-risk business patterns. A query is performed based on these high-risk business patterns to construct a scheduling effect-strategy parameter mapping table for high-sensitivity data analysis, extracting multiple key strategy parameters. Finally, these key strategy parameters are added to the scheduling parameter optimization suggestions.

[0071] In one embodiment, firstly, the scheduling effect data synchronously uploaded by each edge node is stored in the cloud-side time-series database one by one according to the rule of ascending timestamp. During the storage process, data cleaning is performed to remove duplicate data and fill in abnormal data with missing timestamps. This ensures that all data is bound to a unique business request identifier, a unique terminal number, a sampling timestamp, and standardized core quantitative indicators. The stored historical data is collected and organized according to natural days to generate a scheduling effect historical dataset that is continuous in time, uniform in format, and free of abnormal data.

[0072] Then, the historical dataset of scheduling effects is divided into multiple continuous and non-overlapping analysis segments according to natural days. The duration of each continuous analysis segment is 24 hours, which is consistent with the data synchronization cycle of the long-term feedback loop. For each completed continuous analysis segment, business load analysis is carried out. Six core load indicators are counted respectively: total daily business request volume, proportion of different priority services, peak daily load period, average terminal resource utilization rate, service latency compliance rate, and resource load balance. The min-max normalization method is used to uniformly map the values ​​of the six core load indicators to the range of 0 to 1. After being arranged in a fixed order, a one-dimensional load feature vector corresponding to each continuous analysis segment is generated.

[0073] Subsequently, based on all the completed continuous analysis segments, performance degradation judgment is carried out: a performance degradation judgment threshold is pre-set, and the selection rule of the benchmark segment is clarified to be synchronously rolled with the judgment node. The judgment benchmark for each analysis segment to be judged is the average value of the corresponding indicators of the previous 7 consecutive non-overlapping analysis segments. When the service latency compliance rate in a single analysis segment drops by more than 15% compared with the benchmark average, or the resource load balance drops by more than 20% compared with the benchmark average, the analysis segment is judged as a performance degradation segment. After determining all segments, extract all performance degradation segments and their corresponding load feature vectors. Use K-means clustering algorithm for clustering. Preset the number of clusters K=5. Use the load feature vectors of all performance degradation segments as input and Euclidean distance as the similarity criterion. Set the algorithm iteration termination condition as a maximum of 100 iterations or a cluster center offset threshold ≤0.001. If either condition is met, the iteration terminates. First, randomly select 5 groups of load feature vectors as initial cluster centers. Calculate the Euclidean distance between each load feature vector and each cluster center. Assign the sample to the category of the nearest cluster center. Then, iterate and update the cluster centers based on all samples in each category. Repeat the classification and center update process until the termination condition is triggered. After the iteration, group all performance degradation segments belonging to the same final cluster center into one group. Finally, generate multiple candidate degradation business mode clusters. Each cluster corresponds to a business operation mode with similar load characteristics and degradation performance.

[0074] Next, all candidate deteriorating business mode clusters are traversed, and the total number of performance degradation segments contained in each cluster and the frequency of recurrence of the corresponding business mode in the historical dataset of scheduling effects are counted one by one. A statistical verification threshold is pre-set. When the number of performance degradation segments in a single candidate deteriorating business mode cluster is ≥3 and the frequency of recurrence of the corresponding business mode in the historical dataset is ≥5, the candidate cluster is determined to have passed the statistical verification. The business operation mode corresponding to the candidate deteriorating business mode cluster that has passed the verification is identified as a high-risk business mode.

[0075] Based on the generated high-risk business models, a backtracking query is performed on the historical scheduling effect dataset to extract all scheduling strategy parameters adopted by the edge-side scheduling layer, the edge-side collaborative scheduling layer, and the cloud-side global scheduling layer within the corresponding time period of all high-risk business models. These parameters include four core categories: resource access thresholds for edge-side local scheduling, maximum service capacity thresholds for nodes in edge-side collaborative scheduling, sliding monitoring time window parameters, and latency judgment thresholds for service priority division. A scheduling effect-strategy parameter mapping table is constructed using a key-value pair mapping method, with a 24-hour analysis segment as the unique matching granularity. Each scheduling effect data point is bound to a scheduling strategy parameter that is fixed in effect throughout the entire cycle of that segment. The row index of this mapping table represents the specific value of the scheduling strategy parameter, and the column index represents the core quantitative indicators of the scheduling effect. Next, a single-factor sensitivity analysis method was used to conduct high-sensitivity data analysis. The parameter adjustment boundary was defined as follows: each parameter was adjusted within ±50% of its original value, with a fixed step size of 10%. Other parameters were fixed at their original values ​​within the segment. The values ​​of individual scheduling strategy parameters were adjusted one by one, and the change range of the corresponding core scheduling performance indicators was statistically analyzed. When the change range of the core scheduling performance indicators exceeded 10% after the adjustment of a single parameter value, the parameter was identified as a key strategy parameter that has a significant impact on scheduling performance. After completing the analysis of all parameters, all key strategy parameters that meet the conditions were extracted.

[0076] Finally, all the extracted key strategy parameters are combined with the corresponding scenarios of high-risk business models to clarify the original value, optimization adjustment direction, and suggested value range of each key strategy parameter. The suggested value range is defined as the parameter value range in the same type of business scenario in historical data where the core indicator compliance rate of scheduling effect is ≥95%. All optimization adjustment content of all parameters is completely added to the scheduling parameter optimization suggestions. The final generated scheduling parameter optimization suggestions are sent to the corresponding edge-side collaborative scheduling layer and end-side scheduling layer through the closed-loop data path of the long-term feedback loop for subsequent iterative optimization and adjustment of scheduling strategies.

[0077] Through the above-mentioned sequential steps, the long-term closed-loop iterative optimization of the power grid intelligent converged terminal scheduling strategy was realized, which effectively reduced the risk of repeated occurrence of business performance degradation and continuously improved the operational stability and resource utilization efficiency of end-edge-cloud collaborative scheduling.

[0078] Furthermore, the method provided in this application embodiment includes: Based on the scheduling effect, a delay deviation index is extracted for short-term analysis to calculate short-term adjustment weights. The scheduling parameter optimization suggestions are analyzed to extract target adjustment values ​​and recommended adjustment step sequence for multiple parameters to be adjusted. Long-term analysis is performed on the target adjustment values ​​of the multiple parameters to be adjusted according to the recommended adjustment step sequence to set a long-term adjustment baseline. The fusion weight of the long-term adjustment baseline is determined based on the short-term adjustment weights. A weighted sum of parameter corrections is performed according to the recommended adjustment compensation sequence and the delay deviation index to generate an incremental parameter update. The incremental parameter update is applied to iteratively update the terminal scheduling decision results to generate the optimized terminal scheduling scheme.

[0079] Optionally, from the standardized scheduling effect dataset obtained in the aforementioned steps, the actual processing latency data of each service within each sliding monitoring time window is extracted, and the ratio is calculated with the preset target processing latency of the service to obtain the latency deviation index corresponding to each service. The latency deviation index is the ratio of the actual processing latency to the target processing latency. The normal latency range is preset to a latency deviation index ≤ 1, and the latency tolerance upper limit is 1.2. The short-term adjustment weight is calculated using linear interpolation. When the latency deviation index exceeds the latency tolerance upper limit of 1.2, the short-term adjustment weight is fixed at 0.8. When the latency deviation index is within the normal latency range, the short-term adjustment weight is fixed at 0.2. When the latency deviation index is in the transition range of 1 to 1.2, the short-term adjustment weight is calculated linearly according to the formula Short-term adjustment weight = 0.2 + 0.6 × (latency deviation index - 1) / 0.2 to ensure that the more severe the latency deviation, the larger the value of the short-term adjustment weight. After the calculation is completed, a unique short-term adjustment weight is matched for each service.

[0080] Next, the optimization suggestions for scheduling parameters issued by the cloud-side global scheduling layer through the long-term feedback loop are analyzed field by field. Four categories of parameters to be adjusted and optimized are extracted: resource admission threshold for local scheduling on the edge side, maximum service capacity threshold for nodes in edge-side collaborative scheduling, sliding monitoring time window parameters, and latency judgment threshold for service priority division. At the same time, the target adjustment value corresponding to each type of parameter is extracted, as well as the recommended adjustment step sequence arranged from smallest to largest. The recommended adjustment step sequence uses 10%, 20%, and 30% of the current value of the parameter as fixed increments to ensure that the step sequence is arranged in ascending order, providing clear progressive adjustment steps for subsequent long-term analysis.

[0081] For each type of parameter to be adjusted and optimized, the parameters are progressively adjusted from their current values ​​to the target values ​​according to the recommended adjustment step sequence. After each adjustment, historical datasets of scheduling performance for similar business scenarios within the past 30 days are retrieved to evaluate the scheduling performance under that step adjustment. The pre-set acceptable standards for scheduling performance are a business latency compliance rate ≥95% and a resource load balancing degree ≥0.7. The compliance rate of scheduling performance under each adjustment step combination is calculated, and the adjustment path with the highest global compliance rate for multiple parameters is selected. The parameter adjustment baseline value under this path is set as the long-term adjustment baseline to ensure that the baseline value has stable scheduling performance in historical operating scenarios.

[0082] Next, based on the short-term adjustment weight corresponding to each business, the fusion weight of the long-term adjustment baseline is determined. The value of the fusion weight is 1 minus the short-term adjustment weight value of the corresponding business. For example, when the short-term adjustment weight is 0.8, the fusion weight of the long-term adjustment baseline is 1-0.8=0.2. This ensures that the sum of the short-term adjustment weight corresponding to a single business and the fusion weight of the long-term adjustment baseline is always 1, achieving complementary weights between the two and avoiding scheduling deviations caused by a single adjustment logic.

[0083] A pre-defined recommended adjustment compensation sequence is established, corresponding one-to-one with the recommended adjustment step size sequence. The value of this compensation sequence is based on the average delay deviation under historical synchronous long-term adjustments and is positively correlated with the increasing order of the recommended adjustment step size sequence. A compensation value of 0.05 corresponds to a 10% step size, 0.1 to a 20% step size, and 0.15 to a 30% step size. The compensation value range is fixed between 0 and 0.2, used to compensate for the impact of scheduling performance fluctuations under different adjustment step sizes. Subsequently, a weighted summation is performed to calculate the incremental parameter update amount. The specific formula is: Incremental parameter update amount = Short-term adjustment weight × Delay deviation index × Delay deviation correction coefficient + Fusion weight of long-term adjustment baseline × Long-term adjustment baseline correction value + Compensation value corresponding to the recommended adjustment compensation sequence. The delay deviation correction coefficient is fixed at 1% of the target processing delay, and the long-term adjustment baseline correction value is the difference between the target parameter adjustment value and the current value. The calculation is completed using the above formula, generating a unique incremental parameter update amount.

[0084] Finally, the feasibility of incremental parameter updates is verified. After verification, the updates are broken down into multiple sub-step updates and the terminal scheduling decision results are iteratively adjusted step by step according to the preset update steps. The first scheduling effect is collected by using a short-term feedback loop and compared with the original scheduling effect to obtain the verification result. Based on the verification result, three types of subsequent execution strategies are generated, including continuing execution, stopping and rolling back, and accelerating the update. The terminal scheduling decision results are iteratively updated based on the three types of execution strategies to obtain the terminal optimized scheduling scheme. This step will be explained in detail in the following sections.

[0085] By generating incremental parameter updates through weighted summation and applying them to the original scheduling decisions according to explicit rules, the short- and long-term integrated iterative updates of terminal scheduling decision results are realized. The generated terminal optimized scheduling scheme can simultaneously take into account the real-time service delay deviation correction and the long-term operational stability of power grid terminal scheduling.

[0086] Furthermore, the method provided in this application embodiment includes: The incremental parameter update amount is updated for feasibility verification. When the update feasibility verification is passed, the incremental parameter update amount is decomposed into multiple sub-step update amounts. The terminal scheduling decision result is iteratively adjusted step by step according to a preset number of update steps. After the multiple sub-step update amounts are updated, the first scheduling effect is collected through the short-term feedback loop and compared with the scheduling effect to generate a verification result. Based on the verification result, the multiple sub-step update amounts are further analyzed to generate multiple subsequent execution strategies, including a continue execution update strategy, an abort update rollback strategy, and an acceleration completion of the remaining update strategy. Based on the continue execution update strategy, the abort update rollback strategy, and the acceleration completion of the remaining update strategy, the terminal scheduling decision result is iteratively updated to generate a terminal optimized scheduling scheme.

[0087] In one embodiment, firstly, the incremental parameter update amount is checked for update feasibility using an interval threshold comparison method. During the check, it is first verified whether the updated values ​​of each scheduling parameter are within the compliant and safe value range of scheduling parameters specified in the "General Technical Specification for Intelligent Converged Terminals 2025". Then, the variation range of a single parameter and the average variation range of the overall parameters are calculated respectively. The variation range of a single parameter is the ratio of the incremental parameter update amount to the current value of the parameter, and the average variation range of the overall parameters is the average of the variation ranges of all parameters to be adjusted. The upper limit of the variation range of a single parameter is preset to 30%, and the upper limit of the average variation range of the overall parameters is preset to 20%. When all parameters meet the compliant value range requirements and the variation ranges of both single parameters and the overall parameters do not exceed the preset upper limit, the update feasibility check is deemed to have passed. After the check is passed, the overall incremental parameter update amount is divided into 5 equal parts using an average division method, resulting in 5 sub-step update amounts with equal values. The number of sub-step update amounts corresponds one-to-one with the preset number of update steps.

[0088] Next, a fixed execution interval of 10 minutes, consistent with the sliding step size of the sliding monitoring time window of the short-term feedback loop, is set as the preset update step number. According to the order of the sub-step update amounts after the division, at the beginning of each execution interval, the corresponding sub-step update amounts are successively added to the various scheduling parameters to be adjusted corresponding to the terminal scheduling decision results. The parameter iterative adjustment is completed step by step in strict accordance with the predetermined 10-minute time interval, so as to smoothly change the parameter configuration of the scheduling decision and prevent large-scale parameter changes at one time from causing fluctuations in the operation of the power grid.

[0089] After each sub-step update is iteratively adjusted, relying on the established short-term feedback loop, the first scheduling effect data generated by the terminal's current operation is collected in real time. Three core indicators are extracted: business completion rate, latency compliance rate, and resource load balancing. The change range of each indicator is calculated using the following formula: Indicator change range = (Indicator value corresponding to the first scheduling effect - Indicator value corresponding to the original scheduling effect before optimization) / Indicator value corresponding to the original scheduling effect × 100%. The weight percentages of the three core indicators are pre-set. For example, the latency compliance rate has a weight of 50%, the business completion rate has a weight of 30%, and the resource load balancing has a weight of 20%. The change range of each indicator is multiplied by its corresponding weight and then summed to obtain the overall performance change range. Based on the values ​​of the overall performance change range and the change range of individual indicators, an objective and quantitative comparison and verification result is generated.

[0090] Next, a multi-level fixed deviation judgment threshold is pre-set. A positive value for the overall performance change indicates that the scheduling effect after the update is better than before the update, while a negative value indicates that the scheduling effect after the update is worse than before the update. Subsequent analysis is conducted based on the overall performance change and individual indicator change in the comparative verification results. When the overall performance change is ≥0% and the decrease in any individual indicator does not exceed 5%, a strategy to continue executing the update is generated. When the overall performance change is ≤-10%, or the decrease in any individual indicator is ≥15%, a strategy to abort the update and roll back is generated. When the overall performance change is ≥15% and no individual indicator shows a decrease, a strategy to accelerate the completion of the remaining update is generated, forming three types of subsequent execution strategies adapted to different operational performances.

[0091] Finally, according to the standardized operating rules corresponding to different subsequent execution strategies, the terminal scheduling decision results are iteratively updated. When executing the continue execution update strategy, the original 10-minute update interval and sub-step update execution rhythm remain unchanged, and the parameter iteration of all subsequent sub-steps is completed according to the established process. When executing the stop update rollback strategy, all subsequent sub-step update actions are immediately terminated, the update interval is shortened to 5 minutes, and the adjusted scheduling parameters are restored to their initial values ​​before the update in reverse order of the sub-step updates. When executing the accelerate completion of the remaining update strategy, all remaining unexecuted sub-step updates are immediately merged, and all remaining parameter adjustments are completed at once within the current update interval. The overall scheduling decision iteration is completed through the differentiated execution of the three strategies, and finally, a terminal optimized scheduling scheme matching the current power grid operating conditions is generated.

[0092] By triggering three types of execution strategies with fixed thresholds and implementing them according to standardized rules, the step-by-step optimization and update of the power grid smart integrated terminal scheduling decision-making is realized in a stable and controllable manner, taking into account the security of scheduling parameter adjustment, operating condition adaptability and optimization efficiency.

[0093] In summary, the cloud-edge collaborative smart grid integrated terminal optimization scheduling method provided in this application has the following technical effects: This application extracts the delay deviation index from the scheduling effect, sets a long-term adjustment baseline by combining scheduling parameter optimization suggestions, generates incremental update quantities through weighted fusion, and then updates the scheduling decision through step-by-step iterative updates with safety rollback. This achieves the smooth optimization of the terminal scheduling scheme, making the smart grid integrated terminal scheduling more adaptable to operating conditions and safe and reliable. It achieves the technical effects of on-demand allocation of terminal resources and dynamic correction of task execution status, improving the accuracy, stability and resource utilization efficiency of scheduling.

[0094] Example 2, as Figure 2 As shown, based on the same inventive concept as in Embodiment 1 above, this application provides a smart grid integrated terminal optimization scheduling system based on cloud-edge collaboration, the system comprising: The fusion terminal status dataset acquisition module 1 is used to collect data from the smart fusion terminal of the power grid through the cloud-edge collaborative sensing network to obtain the fusion terminal status dataset.

[0095] Terminal scheduling decision result generation module 2 is used to construct an uncertainty quantification model to predict service latency of the converged terminal status dataset, obtain service latency prediction results, perform multi-level joint scheduling based on the service latency prediction results, and generate terminal scheduling decision results.

[0096] The long-short feedback loop construction module 3 is used to construct a two-layer closed-loop feedback mechanism, which includes a short-term feedback loop and a long-term feedback loop.

[0097] The scheduling parameter optimization suggestion generation module 4 is used to monitor the terminal scheduling decision results in real time through the short-term feedback loop, generate scheduling effects, and perform data mining on the scheduling effects through the long-term feedback loop to generate scheduling parameter optimization suggestions.

[0098] Terminal optimization scheduling scheme generation module 5, which iteratively updates the terminal scheduling decision results based on the scheduling effect and the scheduling parameter optimization suggestions, and generates a terminal optimization scheduling scheme.

[0099] Furthermore, the terminal scheduling decision result generation module 2 is used to perform the following steps: Multidimensional feature analysis is performed on the fused terminal status dataset to extract multidimensional feature vectors. Multiple random forward propagations are then performed on these multidimensional feature vectors using the uncertainty quantification model to generate latency prediction distribution sample data. Based on this latency prediction distribution sample data, the predicted latency is calculated, yielding the mean and variance of the predicted latency. The mean predicted latency is used as the estimated service latency, and the variance of the predicted latency is quantified as an uncertainty quantification index. The estimated service latency and the uncertainty quantification index are added to the service latency prediction result. Based on the uncertainty quantification index, service requests are prioritized, generating multiple priorities. Multi-level joint scheduling is performed according to these multiple priorities and the estimated service latency, generating the terminal scheduling decision result.

[0100] Furthermore, the terminal scheduling decision result generation module 2 is used to perform the following steps: The system retrieves the pending service request queue from the smart grid convergence terminal, iterates through the queue, and matches it against uncertainty quantification indicators to generate matching results. It then defines a multi-level uncertainty threshold range, including high uncertainty, medium uncertainty, and low uncertainty intervals. Finally, it compares the uncertainty quantification indicators with the multi-level uncertainty threshold ranges and performs matching based on the comparison results and the matching results: S1: Service requests falling into the high uncertainty interval are classified as first priority processing level; S2: Service requests falling into the medium uncertainty interval are classified as second priority processing level; S3: Service requests falling into the low uncertainty interval are classified as third priority processing level.

[0101] Furthermore, the terminal scheduling decision result generation module 2 is used to perform the following steps: Construct an edge-side scheduling layer, an edge-side collaborative scheduling layer, and a cloud-side global scheduling layer; based on the multiple priorities and the estimated service latency, sequentially drive the edge-side scheduling layer, the edge-side collaborative scheduling layer, and the cloud-side global scheduling layer to perform a three-layer progressive collaborative scheduling process: S4: Submit the service requests of the first priority level to the edge-side scheduling layer for local scheduling and generate an edge-side scheduling result; S5: Submit the service requests of the second priority level and the service requests of the third priority level to the edge-side collaborative scheduling layer for edge computing to obtain the expected completion latency parameters of multiple edge nodes; S6: Traverse the expected completion latency parameters of the multiple edge nodes and perform minimization. S7: Extract values, determine target edge nodes for business conflict coordination, and generate edge-side scheduling results; S8: Aggregate and upload the end-side scheduling results and the edge-side scheduling results to the cloud-side global scheduling layer for analysis, and construct a global load distribution view; S9: Based on the global load distribution view, identify and mark nodes to determine multiple resource-idle edge nodes and multiple resource-overloaded edge nodes; S10: Reallocate resources according to the multiple resource-idle edge nodes and the multiple resource-overloaded edge nodes to generate cross-node resource reconfiguration instructions; S11: Merge the cross-node resource reconfiguration instructions with the end-side scheduling results and the edge-side scheduling results to generate the terminal scheduling decision results.

[0102] Furthermore, the long-short feedback loop construction module 3 is used to perform the following steps: The system retrieves the real-time monitoring agent module configured on the edge node server, collects terminal scheduling decision results at the first time granularity, and extracts execution logs. Based on the execution logs, it performs short-cycle processing latency analysis to generate actual processing latency data and calculates terminal resource utilization based on the execution logs. The system integrates the actual processing latency data and the terminal resource utilization rate to construct a short-cycle monitoring data stream. Based on the short-cycle monitoring data stream, it constructs a short-term feedback loop and connects it to the edge node server.

[0103] Furthermore, the scheduling parameter optimization suggestion generation module 4 is used to perform the following steps: The real-time monitoring agent module sets multiple sampling periods, and based on these multiple sampling periods, identifies the execution logs according to multiple service requests based on the terminal scheduling decision results, generating multiple service request identifiers. These service request identifiers are then associated and concatenated according to time nodes to generate execution trajectory data for multiple service requests. A sliding monitoring time window is set, comprising a time length and a sliding step size. Based on the sliding step size, the sliding monitoring time window is activated to perform multi-dimensional classification of the execution trajectory data according to time length, generating the scheduling effect.

[0104] Furthermore, the scheduling parameter optimization suggestion generation module 4 is used to perform the following steps: The scheduling effects are stored in a cloud-based time-series database to generate a historical scheduling effect dataset. This dataset is then divided into multiple continuous analysis segments for business load analysis, extracting load feature vectors. Deterioration is determined based on these segments, and multiple performance degradation segments are clustered using the load feature vectors to generate candidate deterioration business pattern clusters. These clusters are then statistically verified to generate high-risk business patterns. A query is performed based on these high-risk business patterns to construct a scheduling effect-strategy parameter mapping table for high-sensitivity data analysis, extracting multiple key strategy parameters. Finally, these key strategy parameters are added to the scheduling parameter optimization suggestions.

[0105] Furthermore, the terminal optimization scheduling scheme generation module 5 is used to perform the following steps: Based on the scheduling effect, a delay deviation index is extracted for short-term analysis to calculate short-term adjustment weights. The scheduling parameter optimization suggestions are analyzed to extract target adjustment values ​​and recommended adjustment step sequence for multiple parameters to be adjusted. Long-term analysis is performed on the target adjustment values ​​of the multiple parameters to be adjusted according to the recommended adjustment step sequence to set a long-term adjustment baseline. The fusion weight of the long-term adjustment baseline is determined based on the short-term adjustment weights. A weighted sum of parameter corrections is performed according to the recommended adjustment compensation sequence and the delay deviation index to generate an incremental parameter update. The incremental parameter update is applied to iteratively update the terminal scheduling decision results to generate the optimized terminal scheduling scheme.

[0106] Furthermore, the terminal optimization scheduling scheme generation module 5 is used to perform the following steps: The incremental parameter update amount is updated for feasibility verification. When the update feasibility verification is passed, the incremental parameter update amount is decomposed into multiple sub-step update amounts. The terminal scheduling decision result is iteratively adjusted step by step according to a preset number of update steps. After the multiple sub-step update amounts are updated, the first scheduling effect is collected through the short-term feedback loop and compared with the scheduling effect to generate a verification result. Based on the verification result, the multiple sub-step update amounts are further analyzed to generate multiple subsequent execution strategies, including a continue execution update strategy, an abort update rollback strategy, and an acceleration completion of the remaining update strategy. Based on the continue execution update strategy, the abort update rollback strategy, and the acceleration completion of the remaining update strategy, the terminal scheduling decision result is iteratively updated to generate a terminal optimized scheduling scheme.

[0107] The cloud-edge collaborative smart grid integrated terminal optimization scheduling system provided in this embodiment of the invention can execute the cloud-edge collaborative smart grid integrated terminal optimization scheduling method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0108] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0109] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application. In some cases, the actions or steps described in this application can be performed in a different order than that shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A method for optimal scheduling of a power grid intelligent fusion terminal based on cloud-edge collaboration, characterized in that, The method includes: Data is collected from the smart fusion terminal of the power grid through a cloud-edge collaborative sensing network to obtain the fusion terminal status dataset; An uncertainty quantification model is constructed to predict service latency using the converged terminal status dataset, and the service latency prediction results are obtained. Based on the service latency prediction results, multi-level joint scheduling is performed to generate terminal scheduling decision results. A two-layer closed-loop feedback mechanism is constructed, which includes a short-term feedback loop and a long-term feedback loop; The terminal scheduling decision results are monitored in real time through the short-term feedback loop to generate scheduling effect, and the scheduling effect is mined through the long-term feedback loop to generate scheduling parameter optimization suggestions. Based on the scheduling effect and the optimization suggestions for scheduling parameters, the terminal scheduling decision results are iteratively updated to generate an optimized terminal scheduling scheme. 2.The cloud-edge collaboration based power grid intelligent fusion terminal optimal scheduling method of claim 1, wherein, An uncertainty quantification model is constructed to predict service latency using the fused terminal state dataset, obtaining service latency prediction results. Based on the service latency prediction results, multi-level joint scheduling is performed to generate terminal scheduling decision results. The method includes: Multidimensional feature analysis is performed on the fused terminal status dataset to extract multidimensional feature vectors. The uncertainty quantification model is used to perform multiple random forward propagations on the multidimensional feature vector to generate time delay prediction distribution sample data. Based on the predicted delay distribution sample data, the predicted delay is calculated, and the predicted delay mean and predicted delay variance are calculated. The predicted delay mean is used as the service delay estimate, and the predicted delay variance is quantified as an uncertainty quantification index. Add the estimated service latency and the uncertainty quantification index to the service latency prediction result; Based on the aforementioned uncertainty quantification indicators, requests are prioritized and multiple priorities are generated. Multi-level joint scheduling is performed based on the multiple priorities and the estimated service latency to generate the terminal scheduling decision result. 3.The cloud-edge collaboration based power grid intelligent fusion terminal optimal scheduling method of claim 2, wherein, Based on the aforementioned uncertainty quantification index, requests are prioritized and multiple priorities are generated. The method includes: The pending service request queue of the smart grid convergence terminal is retrieved, and the pending service request queue is traversed and matched with the uncertainty quantification index to generate a matching result; Define a multi-level uncertainty threshold range, which includes a high uncertainty range, a medium uncertainty range, and a low uncertainty range; The uncertainty quantification index is compared with the multi-level uncertainty threshold range, and matching is performed based on the comparison result and the matching result: S1: Classify service requests falling into the high uncertainty range into the first priority processing level; S2: Classify service requests falling into the medium uncertainty range into the second priority processing level; S3: Classify service requests that fall into the low uncertainty range into the third priority processing level. 4.The cloud-edge collaboration based power grid intelligent fusion terminal optimal scheduling method of claim 3, wherein, The terminal scheduling decision result is generated by performing multi-level joint scheduling based on the multiple priorities and the estimated service latency, and the method includes: Construct an edge-side scheduling layer, an edge-side collaborative scheduling layer, and a cloud-side global scheduling layer; Based on the multiple priorities and the estimated service latency, the terminal-side scheduling layer, the edge-side collaborative scheduling layer, and the cloud-side global scheduling layer are sequentially driven to perform a three-layer progressive collaborative scheduling process: S4: Submit the service request of the first priority level to the terminal-side scheduling layer for local scheduling and generate the terminal-side scheduling result; S5: Submit the service requests of the second priority level and the service requests of the third priority level to the edge-side collaborative scheduling layer for edge computing to obtain the expected completion delay parameters of multiple edge nodes; S6: Traverse the expected completion delay parameters of the multiple edge nodes to extract the minimum value, determine the target edge node for business conflict coordination, and generate the edge scheduling result; S7: The endpoint scheduling results and the edge scheduling results are aggregated and uploaded to the cloud-side global scheduling layer for analysis to construct a global load distribution view; S8: Based on the global load distribution view, identify and mark nodes to determine multiple resource idle edge nodes and multiple resource overload edge nodes; S9: Based on the multiple idle resource edge nodes and the multiple overloaded resource edge nodes, a cross-node resource reconfiguration instruction is generated; S10: The cross-node resource reconfiguration instruction is merged with the terminal-side scheduling result and the edge-side scheduling result to generate the terminal scheduling decision result.

5. The method for optimized scheduling of smart grid converged terminals based on cloud-edge collaboration as described in claim 1, characterized in that, The construction process of short-term feedback loops includes the following methods: The edge node server configuration real-time monitoring agent module is invoked, and the terminal scheduling decision results are collected by the real-time monitoring agent module at the first time granularity, and the execution log is extracted. Short-cycle processing latency analysis is performed based on the execution log to generate actual processing latency data. Resource usage is calculated based on the execution log to generate terminal resource usage rate. The actual processing latency data is integrated with the terminal resource utilization rate to construct a short-cycle monitoring data stream; A short-term feedback loop is constructed based on the short-cycle monitoring data stream, and the short-term feedback loop is built to the edge node server.

6. The method for optimized scheduling of smart grid converged terminals based on cloud-edge collaboration as described in claim 5, characterized in that, The method for real-time monitoring of the terminal scheduling decision results through the short-term feedback loop to generate scheduling effects includes: The real-time monitoring agent module sets multiple sampling periods, and based on the multiple sampling periods, identifies the execution log according to multiple business requests based on the terminal scheduling decision results, generating multiple business request identifiers; The execution trajectory data of multiple business requests are generated by associating and concatenating them according to time nodes based on the multiple business request identifiers. Set a sliding monitoring time window, which includes a time length and a sliding step size; Based on the sliding step size, the sliding monitoring time window is activated to perform multi-dimensional classification of the execution trajectory data according to the time length, thereby generating the scheduling effect.

7. The method for optimized scheduling of smart grid converged terminals based on cloud-edge collaboration as described in claim 1, characterized in that, The method involves performing data mining on the scheduling effect through the long-term feedback loop to generate scheduling parameter optimization suggestions, including: The scheduling effects are stored in a cloud-based time-series database according to the time series to generate a historical dataset of scheduling effects. The historical dataset of scheduling effects is divided into multiple continuous analysis segments for business load analysis, and load feature vectors are extracted. Degradation is determined based on the multiple continuous analysis segments, and multiple performance degradation segments are extracted and clustered together with the load feature vector to generate candidate degradation business mode clusters. The candidate deteriorating business model cluster is traversed for statistical verification to generate high-risk business models. Based on the high-risk business model, a scheduling effect-strategy parameter mapping table is constructed for highly sensitive data analysis, and multiple key strategy parameters are extracted. Add the aforementioned key strategy parameters to the scheduling parameter optimization suggestions.

8. The method for optimized scheduling of smart grid converged terminals based on cloud-edge collaboration as described in claim 1, characterized in that, Based on the scheduling effect and the optimization suggestions for scheduling parameters, the terminal scheduling decision result is iteratively updated to generate an optimized terminal scheduling scheme. The method includes: Based on the scheduling effect, the delay deviation index is extracted for short-term analysis, and the short-term adjustment weight is calculated. Based on the optimization suggestions for the scheduling parameters, the target adjustment values ​​and recommended adjustment step sequence of multiple parameters to be adjusted and optimized are extracted. According to the recommended adjustment step size sequence, the target adjustment values ​​of the multiple parameters to be adjusted and optimized are analyzed over a long period, and a long period adjustment baseline is set. The fusion weight of the long-term adjusted baseline is determined based on the short-term adjustment weight; The parameter update quantity is generated by weighted summation of the recommended adjustment compensation sequence and time delay deviation index to generate incremental parameter update quantity. The terminal scheduling decision result is iteratively updated using the incremental parameter update amount to generate the terminal optimized scheduling scheme.

9. The method for optimized scheduling of smart grid converged terminals based on cloud-edge collaboration as described in claim 8, characterized in that, The terminal scheduling decision result is iteratively updated using the incremental parameter update amount to generate the optimized terminal scheduling scheme. The method includes: The incremental parameter update amount is checked for update feasibility. When the update feasibility is verified as passed, the incremental parameter update amount is decomposed into multiple sub-step update amounts. The terminal scheduling decision results are iteratively adjusted step by step according to a preset number of update steps; After the multiple sub-step update amounts are updated, the first scheduling effect is collected through the short-term feedback loop and compared with the scheduling effect to generate a verification result. Based on the verification results, the update volume of the multiple sub-steps is further analyzed to generate multiple subsequent execution strategies, including a strategy to continue executing the update, a strategy to stop the update and roll back, and a strategy to accelerate the completion of the remaining update. Based on the continued update strategy, the aborted update rollback strategy, and the accelerated completion of the remaining update strategy, the terminal scheduling decision result is iteratively updated to generate an optimized terminal scheduling scheme.

10. A smart grid integrated terminal optimization scheduling system based on cloud-edge collaboration, characterized in that, The system is used to implement the cloud-edge collaborative smart grid integrated terminal optimization scheduling method according to any one of claims 1-9, the system comprising: The fusion terminal status dataset acquisition module is used to collect data from the smart fusion terminal of the power grid through the cloud-edge collaborative sensing network and obtain the fusion terminal status dataset. The terminal scheduling decision result generation module is used to construct an uncertainty quantification model to predict service latency of the converged terminal status dataset, obtain service latency prediction results, perform multi-level joint scheduling based on the service latency prediction results, and generate terminal scheduling decision results. The long-short feedback loop construction module is used to construct a two-layer closed-loop feedback mechanism, which includes a short-term feedback loop and a long-term feedback loop. The scheduling parameter optimization suggestion generation module is used to monitor the terminal scheduling decision results in real time through the short-term feedback loop, generate scheduling effect, and perform data mining on the scheduling effect through the long-term feedback loop to generate scheduling parameter optimization suggestions. The terminal optimization scheduling scheme generation module iteratively updates the terminal scheduling decision results based on the scheduling effect and the scheduling parameter optimization suggestions to generate a terminal optimization scheduling scheme.

Images