Power system intelligent dispatching method and system based on cloud edge collaboration

Abstract

This application relates to a cloud-edge collaborative intelligent dispatching method and system for power systems. The method includes: acquiring operational data of the target device for the current dispatching cycle; determining multiple candidate actions corresponding to the device type of the target device based on the operational data, scoring each candidate action, determining the actual action to be executed based on the scoring results, and sending the actual action to the target device for execution; encapsulating the multiple candidate actions, the actual action, and the operational status of the target device before and after the actual action execution into a trajectory package, and sending the trajectory package to a cloud platform to instruct the cloud platform to perform a global risk assessment of the actual action based on the trajectory package and generate a risk constraint parameter table; receiving the risk constraint parameter table and constraining each candidate action in the next cycle according to the risk constraint parameter table. This method can effectively avoid the engineering contradiction between rapid local response at the edge and global security coordination.

Description

Technical Field

[0001] This application relates to the field of power dispatching technology, and in particular to a cloud-edge collaborative intelligent dispatching method and system for power systems. Background Technology

[0002] With the continuous improvement of the proportion of new energy grid connection, the number of energy storage access, the scale of flexible loads and the level of distribution automation, the power system dispatch object has gradually evolved from a relatively stable system mainly controlled by the main grid to a complex collaborative dispatch system involving the main grid, distribution network, distributed power sources, energy storage, adjustable loads and edge control equipment.

[0003] Existing cloud-edge collaborative scheduling solutions typically adopt an architecture of centralized training in the cloud and local inference at the edge. The cloud relies on power flow calculation, state estimation, model training, and high-performance computing capabilities to form scheduling strategies, while the edge relies on local measurement data and lightweight neural networks to quickly generate candidate actions. This approach can reduce the real-time computing pressure of centralized scheduling to a certain extent and is suitable for handling the problems of main and distribution network collaborative optimization and rapid response at the edge.

[0004] However, existing cloud-edge collaborative scheduling schemes do not adequately utilize the correlation between candidate actions, actual executed actions, and local operational changes after the actions, resulting in an engineering contradiction between rapid local response at the edge and global security coordination. Summary of the Invention

[0005] Therefore, it is necessary to provide a cloud-edge collaborative intelligent dispatching method and system for power systems to address the aforementioned technical problems.

[0006] Firstly, this application provides a cloud-edge collaborative intelligent dispatching method for power systems, including:

[0007] Obtain the current scheduling cycle operation data of the target device; the operation data includes at least node voltage, line power, and adjustable device status;

[0008] Based on the operational data, multiple candidate actions corresponding to the device type of the target device are determined, and each candidate action is scored. Based on the scoring results, the actual action to be executed is determined and sent to the target device for execution.

[0009] Multiple candidate actions, actual actions, and the operating status of the target device before and after the actual actions are encapsulated into a trajectory package, and the trajectory package is sent to the cloud platform to instruct the cloud platform to perform a global risk assessment of the actual actions based on the trajectory package and generate a risk constraint parameter table.

[0010] Receive the risk constraint parameter table and apply constraint processing to each candidate action in the next cycle based on the risk constraint parameter table.

[0011] Secondly, this application provides a cloud-edge collaborative intelligent dispatching method for power systems, including:

[0012] The system receives trajectory packets sent by edge devices. The trajectory packets include at least multiple candidate actions, the actual action executed, and the operating status of the target device before and after the actual action is executed. The candidate actions are determined by the edge devices based on the target device's operating data and device type.

[0013] The trajectory packet is parsed, and a risk constraint parameter table is generated based on the parsing results;

[0014] The risk constraint parameter table is sent to the edge device to instruct the edge device to perform constraint processing on each candidate action in the next cycle according to the risk constraint parameter table.

[0015] Thirdly, this application also provides a cloud-edge collaborative intelligent dispatching device for power systems, comprising:

[0016] The acquisition module is used to acquire the current scheduling cycle operation data of the target device; the operation data includes at least node voltage, line power, and adjustable device status;

[0017] The scoring module is used to determine multiple candidate actions corresponding to the device type of the target device based on the running data, score each candidate action, determine the actual action to be executed based on the scoring results, and send the actual action to the target device for execution.

[0018] The encapsulation module is used to encapsulate multiple candidate actions, actual actions, and the operating status of the target device before and after the actual actions into a trajectory package, and send the trajectory package to the cloud platform to instruct the cloud platform to perform a global risk assessment of the actual actions based on the trajectory package and generate a risk constraint parameter table.

[0019] The constraint module is used to receive the risk constraint parameter table and perform constraint processing on each candidate action in the next cycle according to the risk constraint parameter table.

[0020] Fourthly, this application also provides a cloud-edge collaborative intelligent dispatching device for power systems, comprising:

[0021] The receiving module is used to receive trajectory packets sent by edge devices. The trajectory packet includes at least multiple candidate actions, the actual action executed, and the operating status of the target device before and after the actual action is executed. The candidate actions are determined by the edge device based on the operating data of the target device and the device type.

[0022] The parsing module is used to parse the trajectory package and generate a risk constraint parameter table based on the parsing results;

[0023] The distribution module is used to distribute the risk constraint parameter table to the edge devices, so as to instruct the edge devices to perform constraint processing on each candidate action in the next cycle according to the risk constraint parameter table.

[0024] Fifthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method as described in the first aspect.

[0025] In a sixth aspect, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method as described in the second aspect.

[0026] In a seventh aspect, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method as described in the first aspect.

[0027] Eighthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method as described in the second aspect.

[0028] Ninthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method as described in the first aspect.

[0029] In a tenth aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method as described in the second aspect.

[0030] In the eleventh aspect, this application also provides a cloud-edge collaborative intelligent dispatching system for power systems, including edge devices and a cloud platform, wherein the edge devices are used to perform the steps of the method as described in the first aspect; and the cloud platform is used to perform the steps of the method as described in the second aspect.

[0031] The aforementioned cloud-edge collaborative intelligent dispatching method and system for power systems acquires the operational data of the target equipment during the current dispatching cycle. This operational data includes at least node voltage, line power, and the status of adjustable equipment. Based on the operational data, multiple candidate actions corresponding to the equipment type of the target equipment are determined, and each candidate action is scored. The actual action to be executed is determined based on the scoring results and sent to the target equipment for execution. The multiple candidate actions, the actual action, and the operational status of the target equipment before and after the actual action are encapsulated into a trajectory package, which is then sent to the cloud platform. This trajectory package instructs the cloud platform to perform a global risk assessment of the actual action based on the trajectory package and generate a risk constraint parameter table. The system receives the risk constraint parameter table and applies constraints to each candidate action in the next cycle based on the risk constraint parameter table. The above method enables rapid response to actions at the edge, eliminating the need to wait for real-time communication with the cloud. Simultaneously, the complete decision-making process of the edge device is reported to the cloud platform via trajectory packets. This allows the cloud platform to perform accurate global risk assessments based on unified data results, and then convert the assessment results into a directly executable risk constraint parameter table, feeding it back to the edge device. This integrates global safety constraints into the action selection of subsequent scheduling cycles without affecting the real-time decision-making of the edge device in its current scheduling cycle, effectively avoiding the engineering conflict between rapid local response at the edge and global safety coordination. Attached Figure Description

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

[0033] Figure 1 This is an application environment diagram of a cloud-edge collaborative intelligent dispatching method for power systems in one embodiment;

[0034] Figure 2 This is one of the flowcharts illustrating a cloud-edge collaborative intelligent dispatching method for power systems in one embodiment.

[0035] Figure 3 This is the second flowchart of a cloud-edge collaborative intelligent dispatching method for power systems in one embodiment;

[0036] Figure 4 This is the third flowchart of a cloud-edge collaborative intelligent dispatching method for power systems in one embodiment;

[0037] Figure 5This is the fourth flowchart of a cloud-edge collaborative intelligent dispatching method for power systems in one embodiment;

[0038] Figure 6 This is the fifth flowchart of a cloud-edge collaborative intelligent dispatching method for power systems in one embodiment;

[0039] Figure 7 This is the sixth flowchart of a cloud-edge collaborative intelligent dispatching method for power systems in one embodiment;

[0040] Figure 8 This is the seventh flowchart of a cloud-edge collaborative intelligent dispatching method for power systems in one embodiment;

[0041] Figure 9 This is one of the structural block diagrams of a cloud-edge collaborative intelligent dispatching device for power systems in one embodiment;

[0042] Figure 10 This is the second structural block diagram of a cloud-edge collaborative intelligent dispatching device for power systems in one embodiment;

[0043] Figure 11 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0045] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0046] With the continuous improvement of the proportion of new energy grid connection, the number of energy storage access, the scale of flexible loads and the level of distribution automation, the power system dispatch object has gradually evolved from a relatively stable system mainly controlled by the main grid to a complex collaborative dispatch system involving the main grid, distribution network, distributed power sources, energy storage, adjustable loads and edge control equipment.

[0047] Existing cloud-edge collaborative scheduling solutions typically adopt an architecture of centralized training in the cloud and local inference at the edge. The cloud relies on power flow calculation, state estimation, model training, and high-performance computing capabilities to form scheduling strategies, while the edge relies on local measurement data and lightweight neural networks to quickly generate candidate actions. This approach can reduce the real-time computing pressure of centralized scheduling to a certain extent and is suitable for handling the problems of main and distribution network collaborative optimization and rapid response at the edge.

[0048] However, existing cloud-edge collaborative scheduling schemes do not adequately utilize the correlation between candidate actions, actual executed actions, and local operational changes after the actions, resulting in an engineering contradiction between rapid local response at the edge and global security coordination.

[0049] In view of the above-mentioned technical problems, this application provides a cloud-edge collaborative intelligent power system dispatching method. The following embodiments will specifically illustrate the cloud-edge collaborative intelligent power system dispatching method.

[0050] The intelligent power system dispatching method based on cloud-edge collaboration provided in this application can be applied to, for example... Figure 1 The illustrated example is a cloud-edge collaborative intelligent power system dispatching system 1. This system comprises edge devices 101 and a cloud platform 102. Edge devices 101 are deployed in distribution room controllers, transformer edge gateways, energy storage control units, or feeder automation terminals to perform local lightweight intelligent inference and generate trajectory packages. Edge devices 101 read operational data such as node voltage, line power, and adjustable equipment status through the substation industrial bus, local IEC61850 interface, or the control interface of the target device, and perform decision-making operations such as scaling, candidate action scoring, action issuance, and trajectory package encapsulation. The cloud platform 102 is deployed in the main station dispatching platform or distribution network cloud dispatching center, and includes power flow calculation services, main and distribution network topology model services, and a historical operating status caching module. The power flow calculation service is used to calculate the power propagation relationship between nodes; the main and distribution network topology model service is used to maintain the topology connection relationship between the main network, distribution network and edge nodes, and can map the nodes in the trajectory packets reported by edge device 101 to the main and distribution network topology model; the historical operation status cache module is used to save the line power changes and node operation status in the most recent scheduling cycles for subsequent local disturbance propagation analysis.

[0051] Edge device 101 communicates with cloud platform 102 via a standardized cloud-edge interface. Edge device 101 encapsulates the running status before and after the actual action, the set of candidate actions, and the actual action into a trajectory package, and reports it to cloud platform 102 through the standardized cloud-edge interface. Cloud platform 102 then performs a global risk assessment based on the trajectory package, generates a risk constraint parameter table, and distributes it to edge device 101 through the standardized cloud-edge interface, so that edge device 101 can perform constraint processing on candidate actions in subsequent scheduling cycles.

[0052] In one exemplary embodiment, such as Figure 2 As shown, a cloud-edge collaborative intelligent dispatching method for power systems is provided, which is applied to... Figure 1 Taking edge devices in the context of [the context] as an example, the explanation includes:

[0053] S201, Obtain the current scheduling cycle operation data of the target device.

[0054] The operational data includes at least node voltage, line power, and the status of adjustable equipment.

[0055] In this embodiment, edge devices are deployed in locations such as power distribution room controllers, transformer area edge gateways, energy storage control units, or feeder automation terminals. They can collect operational data via the station's industrial bus, local IEC61850 interface, or device control interface. For example, node voltage... Sourced from feeder monitoring and control terminals or smart meters, used to reflect the real-time voltage level of the target node; line power. Data from line measurement units or protection devices reflects changes in the active / reactive power flow of the target line; adjustable equipment status. Sourced from energy storage converters, SVG controllers, or flexible load controllers, this information indicates whether the equipment is currently adjustable, the direction of adjustment, and the remaining adjustment capacity.

[0056] Because the physical meanings and dimensions of various operational data differ, they cannot be directly compared or fused; therefore, scaling processing is necessary. Edge devices store the upper and lower limits of various operational data for the most recent scheduling cycles, converting the current sampled value into a relative change value; for adjustable device states... The relative state value is then formed based on the ratio of the current remaining adjustment capacity to the allowable adjustment range. In this way, edge devices can map different types of operational data to the same numerical scale, enabling the subsequent scoring process to simultaneously consider three dimensions: voltage change, power change, and device adjustment capacity. Parameters such as the number of recent scheduling cycles, scheduling cycle duration, and sampling synchronization error are pre-configured and saved by the edge device during the commissioning or debugging phase. If operational data is missing, timestamps are inconsistent, or the device status display is uncontrollable within a certain cycle, the data for that cycle will not participate in the action scoring and will only be retained as an abnormal sampling record.

[0057] S202: Based on the operating data, determine multiple candidate actions corresponding to the device type of the target device, score each candidate action, determine the actual action to be executed based on the scoring results, and send the actual action to the target device for execution.

[0058] In this embodiment, the edge device inputs the processed operational data into a pre-trained scoring model, i.e., a lightweight neural network model. This model employs a three-layer structure. The first layer is a state embedding layer, primarily used to receive various types of processed operational data and map them into state vectors of uniform length. For example, due to node voltage... Line power and adjustable device status The three types of input data, which come from different data sources and have different physical meanings, can be fused into a fixed-dimensional state vector through a fully connected mapping method by the state embedding layer.

[0059] The second layer is the action association layer, which mainly receives the state vector output by the state embedding layer and generates a corresponding set of candidate actions based on the device type of the target device. Specifically, the action association layer first identifies the type of the target device, and then generates candidate actions corresponding to the target device type according to a preset mapping relationship between devices and actions. For example, when the device type is an energy storage device, it generates three candidate actions: charging, discharging, and holding; when the device type is an SVG device, it generates three candidate actions: reactive power input, reactive power cut-off, and holding; and when the device type is a flexible load device, it generates three candidate actions: load reduction, load restoration, and holding. After generating candidate actions, the action association layer can also adjust the settings based on the adjustable device state. Feasibility constraints are imposed on each candidate action. Adjustable equipment includes three dimensions of information: whether the equipment is currently adjustable, the adjustable direction, and the remaining adjustment capacity. The action association layer can filter and prioritize multiple candidate actions based on this three-dimensional information. For example, when the remaining adjustment capacity of the energy storage equipment (i.e., the remaining rechargeable capacity or the remaining dischargeable capacity) is low, a large discharge action is physically impossible to execute or has limited effect. In this case, the priority of the discharge action is reduced or the action is directly blocked. When the flexible load equipment is in an uninterruptible operating state, the load reduction action is prohibited and the action is directly blocked. When the reactive power compensation capacity of the SVG equipment is close to the upper limit, further reactive power input actions are blocked, and only reactive power cut-off and hold actions are retained. Through the above constraint mechanism, the edge device ensures that all candidate actions entering the scoring stage are physically executable and reasonable under the current operating conditions.

[0060] The third layer is the action scoring layer, which mainly receives the candidate action set output by the action association layer and calculates a comprehensive score for each candidate action. Specifically, the action scoring layer adopts a weighted comprehensive scoring method, which sums the three indicators corresponding to the candidate action: the node voltage change trend, the line power change trend, and the equipment's remaining regulation capacity, to obtain the comprehensive score of the candidate action. The scoring calculation formula can be expressed by the relation (1), which is shown below:

[0061] (1);

[0062] in, The action score for candidate action 'a' is output by the action scoring layer; 'a' represents a candidate action generated by the action association layer. This represents the node voltage change trend corresponding to candidate action 'a', obtained after unified scaling. Its original trend is derived from the node voltage changes over the most recent scheduling cycles. Change estimation; This represents the trend of line power change corresponding to candidate action 'a', obtained after unified scaling. Its original trend is derived from the line power changes over the most recent scheduling cycles. Change estimation; This represents the remaining adjustable capacity of the equipment corresponding to candidate action 'a', obtained after uniform scaling. Its original state comes from the adjustable equipment state. ; , , These represent preset weighting parameters, which are adjusted offline by the cloud based on historical operating conditions and then fixed to the edge. The values ​​of these three parameters reflect the relative importance of voltage stability, line power stability, and equipment sustainable regulation capability in local action selection. For example, in areas with high penetration of renewable energy and frequent voltage fluctuations... A higher configurable value can be made to prioritize voltage improvement when selecting actions at the edge; in areas where feeder power flow frequently exceeds limits, A higher configurable value allows the edge to prioritize actions that mitigate power limit exceedances; this is useful in scenarios with limited device tolerance and high subsequent scheduling requirements. A higher value can be configured to prioritize actions that preserve the device's adjustment capabilities at the edge. Because... , and All have been standardized. The overall score can be calculated by weighting each item together.

[0063] The overall structural parameters of the scoring model are trained offline on the cloud platform and then distributed to the edge device. The edge device only performs inference and action scoring locally, without being involved in model training. When the cloud platform distributes a new version of the model, the edge device retains the version numbers of both the previous and new versions. This ensures that the subsequently packaged trajectory packages can clearly record which model version generated each candidate action, facilitating version tracking and effect attribution by the cloud platform. Based on the scoring results output by the action scoring layer, the edge device determines the candidate action with the highest score as the actual action to be executed and distributes it to the target device for execution. If a valid risk constraint parameter table already exists, the actual action needs to be further modified according to the risk constraint parameter table after determination before being distributed to the target device for execution.

[0064] S203 encapsulates multiple candidate actions, actual actions, and the operating status of the target device before and after the actual actions into a trajectory package, and sends the trajectory package to the cloud platform to instruct the cloud platform to perform a global risk assessment of the actual actions based on the trajectory package and generate a risk constraint parameter table.

[0065] In this embodiment, after the edge device sends the actual action to the target device, it continues to read the node voltage and line power changes within a scheduling cycle to form the operating status after the action is executed. For example, if the actual action is energy storage charging, the node voltage change trend and line power change trend after the charging action is executed are recorded; if the actual action is reactive power input, the node voltage change trend and target line power change trend after reactive power input are recorded.

[0066] Subsequently, the edge device encapsulates the current operating state, candidate action set, actual executed action, and post-action operating state into a trajectory package. The current operating state is determined by the processed node voltage. Line power and adjustable device status The process consists of: the candidate action set is generated by the action association layer; the actual action is selected by the action scoring layer based on the scoring results, or, if a risk constraint parameter table already exists, is written back from the final candidate action after constraint correction; the operating status after the action is executed is formed by the node voltage and line power read again after the action is executed.

[0067] In addition, the trajectory package also stores edge node identifiers, device types, scheduling cycle numbers, action start times, action end times, model version numbers, risk constraint parameter table version numbers, and communication interruption or device refusal flags, enabling the cloud platform to identify the operating conditions and execution sources corresponding to the trajectory package.

[0068] The edge device sends the encapsulated trajectory packet to the cloud platform, instructing the cloud platform to execute the trajectory packet. A global risk assessment is performed on the actual actions taken, and a risk constraint parameter table is generated. This trajectory package... As input for the cloud platform's global risk assessment, it enables the cloud platform to acquire the local state, candidate actions, actual actions, and local operational changes after the actions of edge devices based on a unified data structure, providing data support for disturbance propagation simulation and constraint parameter generation.

[0069] S204, Receive the risk constraint parameter table, and perform constraint processing on each candidate action in the next cycle according to the risk constraint parameter table.

[0070] In this embodiment of the application, after the cloud platform completes the global risk assessment, it generates a risk constraint parameter table. The table is sent to the corresponding edge devices, which receive it and save it locally. This is the risk constraint parameter table. This table is generated and distributed by the cloud platform after performing a global risk assessment on the trajectory packets reported by the edge devices in the previous scheduling cycle. It records information such as device type, candidate actions, applicable operating conditions, constraint strength value, action constraint method (e.g., retention, amplitude limiting, or masking), and allowed action ratio. In addition, the risk constraint parameter table also includes version number, generation time, applicable topology version, and validity period.

[0071] It is worth noting that this risk constraint parameter table does not affect the execution of actions in the current scheduling cycle. That is, the actions in the current scheduling cycle have already been independently decided and issued by the edge device. The table applies to the next scheduling cycle. In other words, starting from the next cycle, before executing any action, the edge device needs to perform constraint processing on each candidate action according to the constraint entries recorded in this risk constraint parameter table.

[0072] After receiving the risk constraint parameter table from the cloud platform, the edge device saves the risk constraint parameter table and its version number. At the beginning of each scheduling cycle, the edge device first checks whether there is an expired risk constraint parameter table locally: if it exists, it uses that risk constraint parameter table as the basis for the action constraints of the current cycle; if it does not exist, a preset boundary strategy is adopted. When the edge device receives a new version of the risk constraint parameter table, it replaces the old table with the new table; if communication is interrupted and the new table is not received, the previous version of the constraint table that has not expired continues to be used; if the previous version has also expired, the preset boundary strategy is adopted to ensure that the edge device has an executable security constraint basis under any circumstances.

[0073] In the aforementioned cloud-edge collaborative intelligent dispatching method for power systems, the following steps are taken: First, the operating data of the target equipment for the current dispatching cycle is acquired. This operating data includes at least node voltage, line power, and adjustable equipment status. Based on the operating data, multiple candidate actions corresponding to the equipment type of the target equipment are determined, and each candidate action is scored. The actual action to be executed is determined based on the scoring results and then sent to the target equipment for execution. The multiple candidate actions, the actual action, and the operating status of the target equipment before and after the actual action are encapsulated into a trajectory package, which is then sent to the cloud platform. This trajectory package instructs the cloud platform to perform a global risk assessment of the actual action based on the trajectory package and generate a risk constraint parameter table. Finally, the risk constraint parameter table is received, and constraint processing is applied to each candidate action in the next cycle based on the risk constraint parameter table. The above method enables rapid response to actions at the edge, eliminating the need to wait for real-time communication with the cloud. Simultaneously, the complete decision-making process of the edge device is reported to the cloud platform via trajectory packets. This allows the cloud platform to perform accurate global risk assessments based on unified data results, and then convert the assessment results into a directly executable risk constraint parameter table, feeding it back to the edge device. This integrates global safety constraints into the action selection of subsequent scheduling cycles without affecting the real-time decision-making of the edge device in its current scheduling cycle, effectively avoiding the engineering conflict between rapid local response at the edge and global safety coordination.

[0074] In an exemplary embodiment, the step S202 above, "determining the actual action to be performed based on the scoring result and sending the actual action to the target device for execution," is as follows: Figure 3 As shown, it includes:

[0075] S301, obtain the score value of each candidate action output by the pre-built scoring model, and determine the candidate action corresponding to the highest score result among the score values ​​as the actual action to be executed.

[0076] In this embodiment of the application, after the action scoring layer of the scoring model completes the scoring calculation for each candidate action, it outputs the comprehensive score value corresponding to each candidate action. A higher score indicates a better overall improvement in voltage stability, power stability, and equipment sustainability under current operating conditions. After obtaining the above scores, the edge device compares the scores of each candidate action and selects the candidate action with the highest score as the actual action to be executed.

[0077] For example, taking the classic scenario of energy storage device parameters and distribution network voltage regulation as an example, the action association layer of the edge device generates three candidate actions for the energy storage device: charging, discharging, and holding. All three actions meet the current device state requirements and enter the scoring stage. The action scoring layer calculates the three scoring index values ​​corresponding to each of the three candidate actions based on the operating data from the most recent scheduling cycles. Among them, the node voltage change trend corresponding to the charging action is... It is 0.70, and the trend of line power change. It is 0.55 and the remaining adjustment capacity of the equipment. The value is 0.80; the three scoring indicators for the discharge action are 0.45, 0.40, and 0.80; the three scoring indicators for the hold action are 0.20, 0.30, and 1.00. If the cloud platform's preset weight parameters are configured as follows... , as well as According to equation (1), the highest score for the charging action is 0.6675. Therefore, the edge device determines the charging action as the actual action to be executed, while retaining the discharging action as the second highest-scoring (0.5025, while the score corresponding to the holding action is 0.395) as an unexecuted candidate action. This is used for global risk assessment and constraint generation by the cloud platform when encapsulating the subsequent trajectory package. This processing allows the edge device to consider both line power changes and the subsequent adjustment capability of the equipment when selecting local voltage regulation actions, which is suitable for scenarios where fluctuations in new energy output cause local voltage and branch power flow to change synchronously.

[0078] S302, determine whether the risk constraint parameter table exists in the current scheduling period.

[0079] In this embodiment, after the edge device determines the candidate action with the highest score as the actual action to be executed, it does not immediately send the actual action to the target device. Instead, it first determines whether a usable risk constraint parameter table exists in the current scheduling period. Specifically, the edge device determines whether a usable risk constraint parameter table exists in the current scheduling period in the following scenarios: Scenario 1: The current scheduling period has successfully received a newly issued risk constraint parameter table from the cloud platform, and the table is within its validity period (i.e., the validity period of the table has not expired at the current time). In this case, the edge device determines that a usable risk constraint parameter table exists. Scenario 2: The current scheduling period has not received a newly issued risk constraint parameter table from the cloud platform, but the edge device locally stores a risk constraint parameter table received in the previous scheduling period that has not yet expired. In this case, the edge device determines that a usable risk constraint parameter table still exists. Scenario 3: The current scheduling period has neither received a newly issued risk constraint parameter table, nor has the risk constraint parameter table stored locally by the edge device in the previous period expired or does not exist at all. In this case, the edge device determines that no usable risk constraint parameter table exists. It is worth noting that the edge device also verifies the version information of the risk constraint parameter table. When an edge device holds both new and old versions of the risk constraint parameter table, the version with the higher number shall prevail. If the newer version of the table has expired while the older version is still valid, the edge device can continue to use the older version of the table to ensure that the constraint mechanism is not interrupted due to version updates or communication delays.

[0080] S303: If a risk constraint parameter table exists in the current scheduling cycle, the actual execution action is limited according to the risk constraint parameter table, and the limited actual execution action is sent to the target device for execution.

[0081] In this embodiment, after determining that a usable risk constraint parameter table exists, the edge device matches the current operating state of the target device with the applicable operating conditions in the risk constraint parameter table. Based on the action markers in the matched target entries, it limits the magnitude of the actual action to be executed and then sends the limited action to the target device for execution. Action markers include retain, limit, and block, with different markers corresponding to different magnitude limiting operations. Specifically, when the action marker is retain, the edge device maintains the initial action magnitude and directly sends the actual action to the target device for execution. When the action marker is limit, the edge device compresses the initial action magnitude according to the allowed action ratio and smooths it by combining it with the action magnitude from the previous scheduling cycle, then sends the final action execution magnitude to the target device for execution. When the action marker is block, the edge device selects the second-highest-scoring candidate action that is not blocked from among the candidate actions as a replacement action, processes it according to the corresponding magnitude limiting method, and then sends it to the target device for execution. If all candidate actions are blocked, a hold action or a zero-adjustment action is executed, and the status is uploaded to the cloud server. If a match fails, a conservative limit is applied according to the preset boundary strategy, and the unmatched information is written to the running log.

[0082] S304: If there is no risk constraint parameter table in the current scheduling cycle, the actual execution action is limited according to the preset boundary policy, and the limited actual execution action is sent to the target device for execution.

[0083] In this embodiment, when the edge device determines that there is no available risk constraint parameter table in the current scheduling period, the edge device cannot obtain global risk constraint guidance from the cloud platform for the current operating conditions. At this time, the preset boundary policy is activated as a security mechanism to ensure safe operation even without global constraints.

[0084] For example, the preset boundary strategies primarily include at least one of the following: action amplitude limitation, action direction limitation, and action change rate limitation. Regarding action amplitude limitation, the maximum permissible action amplitude is determined locally by the edge device based on the target device's equipment type and rated operating parameters. When the original action amplitude output by the scoring model exceeds this preset upper limit, the edge device reduces the original action amplitude to the preset upper limit. For example, the maximum charging and discharging power of the energy storage device does not exceed a preset percentage of its rated power. Regarding action direction limitation, the edge device can restrict the execution of actions in certain directions based on the target device's current operating state. For example, when the energy storage device's state of charge is close to its lower limit, it is prohibited from continuing to perform discharging actions, only allowing charging or holding actions. Regarding action change rate limitation, the edge device can preset the maximum change in the target device's action amplitude within a unit scheduling cycle, ensuring that the change in action amplitude between adjacent scheduling cycles does not exceed the preset limit. Through the above preset boundary strategies, even when the edge device cannot obtain the risk constraint parameter table from the cloud platform, it can still ensure that the target device's actions do not exceed the basic safety boundaries.

[0085] In an exemplary embodiment, the above-mentioned S303, "limiting the magnitude of the actual execution action according to the risk constraint parameter table, and sending the limited actual execution action to the target device for execution," is as follows: Figure 4 As shown, it includes:

[0086] S401, match the current operating status of the target device with the applicable operating conditions in the risk constraint parameter table to obtain the matching target entry, and obtain the action marker corresponding to the actual action to be executed based on the target entry.

[0087] Action markers include retain, limit, and mask.

[0088] In this embodiment of the application, the edge device determines whether there is an available risk constraint parameter table for the current scheduling period. First, the operating status of the target device in the current scheduling cycle is obtained, including node voltage change values, line power change values, and adjustable equipment status values. Then, the edge device matches the above current operating status with the applicable operating conditions in the risk constraint parameter table. The risk constraint parameter table records the constraint entries for each candidate action under different operating conditions. Each entry includes the applicable operating conditions (node ​​voltage change range, line power change range, adjustable equipment status range), action constraint method (reservation, limiting, or shielding), and the allowed action ratio. When the device type, action type, and current operating status of candidate action a all match the risk constraint parameter table... When a match is found in a specific entry (i.e., the device type in the entry matches the target device type, the action type matches the candidate action, and the node voltage change value falls within the node voltage change range, the line power change value falls within the line power change range, and the adjustable device status value falls within the adjustable device status range), the entry is considered a successful match, and the edge device uses the matched entry as the target entry. After a successful match, the edge device reads the constraint strength value, action constraint method (i.e., action marker, including retention, limiting, or shielding), and action allowable ratio corresponding to the actual action to be executed from the target entry, and sends them to the action constraint execution layer. The action constraint execution layer is deployed between the scoring model and the control interface of the target device, and is used to transform the risk constraint parameter table into final candidate actions that can be directly issued. If no applicable operating conditions for any entry are matched in the current operating state, the risk constraint parameter table is considered unavailable in the current scheduling cycle. Edge devices cannot apply constraint entries from other devices or other operating conditions. Instead, they conservatively restrict the actual execution actions according to the preset boundary strategy and write the unmatched information into the operation record for subsequent trajectory package encapsulation and reporting to the cloud.

[0089] S402 performs different amplitude restriction operations on the actual execution action according to different action markers, and sends the restricted actual execution action to the target device for execution.

[0090] When an action is marked as limited, the allowed action ratio is obtained from the target entry, and the initial action amplitude is compressed according to the allowed action ratio. The compressed actual action is then sent to the target device for execution. Candidate actions are used as replacement actions, and the amplitude of the replacement actions is limited according to the risk constraint parameter table before being sent to the target device for execution.

[0091] In this embodiment, when an action is marked as reserved, it indicates that the cloud platform assesses the action as having a low global risk under current operating conditions, allowing the edge device to execute according to the original decision. The action constraint execution layer maintains the initial action amplitude output by the scoring model. (the initial range of motion) This indicates that the scoring method takes the original adjustment range of a candidate action output (such as the ratio of energy storage charging and discharging power, the ratio of SVG reactive power compensation capacity, or the ratio of flexible load adjustment), without any compression or reduction, and directly sends the actual action to the target device for execution. Simultaneously, the edge device marks the constraint method of this action as "retained" in the operation record.

[0092] When an action is marked as limited, it indicates that the cloud platform assesses that the action poses a certain global risk under the current operating conditions, and the action's amplitude needs to be compressed. The action constraint execution layer reads the allowed proportion of the action from the target entry. In conjunction with the action amplitude of the previous scheduling cycle Continuous correction is performed. Specifically, the edge device calculates the final motion execution amplitude using a method that first employs proportional limiting and then first-order inertial smoothing. Proportional limiting originates from the amplitude constraint method in continuous control and is used to... Limiting the executable range of actions; first-order inertial smoothing originates from a motion continuity processing method commonly used in industrial control, used to reduce abrupt changes in motion amplitude within continuous scheduling cycles. Edge devices first determine the allowable motion ratio. Obtain the amplitude limit target of the candidate action, and then combine it with the action amplitude of the previous scheduling cycle. Smoothing is performed to ensure that the final action amplitude does not exceed the target amplitude limit. Its calculation can be expressed by equation (2), which is shown below:

[0093] (2);

[0094] in, This indicates the final action execution range, which is output by the action constraint execution layer and sent to the control interface of the target device. The percentage of actions allowed is indicated by the risk constraint parameter table. Read the corresponding action entry; This represents the original motion magnitude output by the scoring model in the current scheduling cycle; This indicates the extent of actions performed by the same device in the previous scheduling cycle, which is read by the historical action cache module of the edge device. This represents the motion smoothing weight parameter, configured by the edge device based on the dynamic response speed of the target device. A larger value indicates that the current motion is closer to the motion of the previous cycle. This formula is derived from a first-order inertial adjustment form. The deduction yielded that, among which For the limited target, and Adjustment coefficient Pick At the same time, by taking a smaller value, the final action execution range is kept within a certain limit. . , and Both represent the range of motion of the same device; and As a proportional parameter, the calculation result is consistent with the meaning of the action amplitude required by the equipment control interface. For actions with opposite directions such as charging, discharging, reactive power input, and reactive power cut-off, the edge device first determines the action direction by the candidate action a, and then uses the relation (2) for non-negative amplitude proportional calculation to avoid mixing the action amplitudes of opposite directions in the same relation.

[0095] For example, in a scenario where energy storage participates in distribution network voltage regulation, if the scoring model generates the original charging action amplitude in the current scheduling cycle... The value is 0.9, which corresponds to the permissible action ratio in the risk constraint parameter table. The value is 0.5810, and the historical action cache module in the edge device records the charging action amplitude of the previous scheduling cycle. The motion smoothing weight parameter configured at the edge is 0.60. The value is 0.15. Therefore, the radiation-limiting target... The value is 0.5229; the smoothing result is 0.5345; the final motion execution amplitude is... This result indicates that the edge device adjusts the energy storage charging action to an execution range of approximately 52.29%, and sends this information to the energy storage converter via the energy storage control interface. For SVG devices, this calculation corresponds to the reactive power compensation capacity ratio; for flexible load devices, it corresponds to the load regulation ratio. Therefore, the edge device can maintain its local rapid adjustment capability while implementing the main and distribution network risk constraints generated by the cloud platform into the device's execution range. This final action execution range... The adjustment range will be directly used as the control interface of the target device and written into the trajectory package of the next scheduling cycle after the action is executed, so that the cloud platform can continue to evaluate the actual action effect after the amplitude limit.

[0096] When an action is marked as blocked, it indicates that the cloud platform assesses that the action poses a high global risk under the current operating conditions and prohibits its execution. The action constraint execution layer skips the actual action to be executed and selects the second-highest-scoring candidate action that is not blocked from among the candidate actions under the same device type as a replacement action. After processing the replacement action according to the aforementioned magnitude restriction method, it is sent to the target device for execution. If all candidate actions under the same device type are blocked, the action constraint execution layer executes a hold action or a zero-adjustment action and uploads this state as a high-risk scheduling record to the cloud platform, avoiding the forced execution of risky actions when no actions are available. Through the above processing, the risk constraint parameter table generated by the cloud platform is directly applied to the magnitude of the actual actions of the edge device, rather than merely existing as a prompt message, realizing the implementation of the global risk assessment results at the edge.

[0097] The edge device obtains the final action execution range Then, it is combined with candidate action 'a' to form the final candidate action, which is then sent to the control interface of the corresponding target device. The energy storage device executes the final action according to its magnitude. The SVG device adjusts the charging or discharging power according to the magnitude of the final action. The flexible load controller performs reactive power input or output based on the magnitude of the final action. Perform load reduction or load restoration. After the action is issued, the edge device reads the node voltage after the action is executed. Line power and adjustable device status Candidate action a, final action execution range The execution status of the action is written to the edge execution record. This execution record is used as the encapsulation trajectory package for the next scheduling cycle. The data source. If the target device's control interface returns a refusal to operate, execution failure, or if the node voltage or line power exceeds the limit after execution, the edge device immediately stops expanding the same-direction action and writes the reason for the failure, the actual execution range, and the post-action status into the operation record. The cloud platform will then increase the constraint strength under the corresponding operating conditions or block the action in the next round of risk assessment.

[0098] Through the above processing, the risk constraint parameter table generated by the cloud platform can be directly applied to the actual action range of the edge device, rather than just existing as a prompt message, thus realizing the implementation of the global risk assessment results at the edge.

[0099] In one exemplary embodiment, based on the cloud-edge collaborative intelligent power system dispatching method described in any of the foregoing embodiments, another cloud-edge collaborative intelligent power system dispatching method is also provided, applied to a cloud platform, such as... Figure 5 As shown, it includes:

[0100] S501 receives trajectory packets sent by edge devices.

[0101] The trajectory package is a standardized data structure created by an edge device after completing the action execution of the current scheduling cycle. It encapsulates information such as the operating status before and after action execution, the set of candidate actions, and the actual executed action in a unified format. The trajectory package contains at least the following: multiple candidate actions (i.e., all selectable actions generated by the edge device based on the target device type, such as charging, discharging, and holding actions for energy storage devices), the actual executed action (i.e., the action selected and finally issued by the edge device from the candidate actions), and the operating status of the target device before and after the actual executed action (including node voltage, line power, and adjustable device status before execution, and changes in node voltage and line power reread after execution). Candidate actions are determined by the edge device based on the target device's operating data and device type. In addition, the trajectory package may also carry supplementary information such as edge node identifier, device type, scheduling cycle number, action start time, action end time, model version number of the scoring model, version number of the risk constraint parameter table, and communication interruption or device refusal to operate flags.

[0102] In this embodiment, the cloud platform receives a local scheduling trajectory packet sent by the edge device. Thus, the cloud platform can simultaneously obtain the local state of the edge device under the current operating conditions, the action selection that the edge device could originally execute, and the local change results after the action is executed. This enables the cloud platform to accurately identify the operating conditions and execution source corresponding to the trajectory packet.

[0103] Upon receiving the trajectory package, the cloud platform first performs a completeness check, which includes verifying the edge node identifier, topology version, model version, and scheduling cycle number. If the trajectory package lacks core data such as the actual executed action, candidate action set, or post-action running status, it will not participate in subsequent risk constraint generation and will only be stored as a communication or device anomaly record. After successful verification, the cloud platform begins to execute the subsequent global risk assessment process based on the data in the trajectory package.

[0104] S502 parses the trajectory packet and generates a risk constraint parameter table based on the parsing results.

[0105] In this embodiment, after verifying the trajectory package, the cloud platform parses the data in the trajectory package to obtain the current operating status of the target device (node ​​voltage, line power, and adjustable device status), the set of candidate actions, the actual executed actions, and the operating status after the actions are executed. Subsequently, the cloud platform maps the nodes in the trajectory package to a pre-constructed main distribution network topology model and determines the local risk propagation area centered on the node based on the mapping results. Within the local risk propagation area, the cloud platform performs disturbance propagation simulations for multiple candidate actions, calculating the boundary power change trend, boundary voltage change trend, and regional coupling strength corresponding to the actually executed actions and the non-executed candidate actions, and calculates local deviation terms by combining the line power change trend and node voltage transformation trend of each candidate action at the edge local nodes. Based on this, the cloud platform calculates the global risk propagation value of each candidate action through weighted summation and determines the risk level of each candidate action based on the global risk propagation value.

[0106] The cloud platform further calculates the constraint strength value for each candidate action based on the global risk propagation value, regional coupling strength, local deviation term, and action stability margin term. The action stability margin term is calculated by the cloud platform based on the directional changes of similar actions at the same edge node within the most recent scheduling cycles and the remaining adjustment capacity of the equipment. Then, based on the range to which the constraint strength value belongs, the cloud platform maps each candidate action to one of three action constraint methods: retention, amplitude limiting, or masking.

[0107] Finally, the cloud platform uses edge node identifiers and device types as indexes to organize the applicable operating conditions, constraint strength values, action constraint methods, and allowed proportions of each candidate action into action constraint entries, and summarizes them to generate a risk constraint parameter table. This risk constraint parameter table also includes version number, generation time, applicable topology version, and validity period, and is distributed to the corresponding edge devices through a standardized cloud-edge interface, so that the global risk assessment results can be applied to the action decisions of subsequent scheduling cycles at the edge devices in the form of executable constraints.

[0108] S503 sends the risk constraint parameter table to the edge device to instruct the edge device to perform constraint processing on each candidate action in the next cycle according to the risk constraint parameter table.

[0109] In this embodiment of the application, the cloud platform generates a risk constraint parameter table. Then, the data is organized according to the structure of edge node representation, device type, candidate actions, applicable operating conditions, constraint strength value, action constraint method, and allowed action ratio. The edge node identifier comes from the edge device code registered in the cloud-edge standardized interface; the device type and candidate actions are derived from the global risk assessment results. Applicable operating conditions are determined by the overall risk assessment results. The node voltage variation range, line power variation range, and adjustable equipment state range are generated; constraint strength value. Calculated by the cloud-based risk constraint generation service; the action constraint method is determined by the constraint strength value. The relevant range has been determined; the permitted action ratio has been determined. Write when the action constraint method is limited action.

[0110] The cloud platform transmits the risk constraint parameter table through a standardized cloud-edge interface. The risk constraint parameter table is then distributed to the corresponding edge devices, enabling them to read the table in subsequent scheduling cycles. This data is then used as the constraint basis for generating local candidate actions, thereby transforming the cloud-based global risk assessment results into executable scheduling boundaries for edge devices. If a cloud-edge communication interruption causes the risk constraint parameter table to fail to be delivered, the cloud platform retains the risk constraint parameter table and resends it after communication is restored. Edge devices continue to use the previous version of the risk constraint parameter table until a new version is received; if the previous version has expired, the security boundary policy is reverted, and a table missing marker is written into the next round of trajectory packets.

[0111] In an exemplary embodiment, the above-mentioned S502 step of "parse the trajectory package and generate a risk constraint parameter table based on the parsing results" is as follows: Figure 6 As shown, it includes:

[0112] S601 parses the trajectory packet, maps the nodes in the trajectory packet to the pre-built main distribution network topology model to perform disturbance propagation simulation, and generates global risk assessment results.

[0113] In this embodiment, after verifying the trajectory package, the cloud platform parses the data in the trajectory package to extract the current operating status of the target device (node ​​voltage, line power, and adjustable device status), the set of candidate actions, the actual executed actions, and the operating status after the actions are executed. Based on the edge node identifiers in the trajectory package, the target node is mapped to the main distribution network topology model to determine the local risk propagation area. Subsequently, the cloud platform performs disturbance propagation simulation for each candidate action within the local risk propagation area. For the actual executed actions, the operating status after the actions in the trajectory package can be directly used as the simulation result; for unexecuted candidate actions, disturbance propagation calculation is performed starting from the current operating status. Based on the simulation results, the cloud platform calculates the local deviation term and global risk propagation value for each candidate action. Based on the comparison between the global risk propagation value and a preset risk threshold, each candidate action is divided into three risk levels: priority retention, restricted execution, or high risk. Finally, a global risk assessment result is generated for subsequent generation of a risk constraint parameter table.

[0114] S602, Generate a risk constraint parameter table based on the global risk assessment results.

[0115] In this embodiment of the application, the cloud platform uses the global risk assessment results As direct input, read each candidate action 'a' and the global risk propagation value. Regional coupling strength Local deviation terms The operational conditions and risk level of the action (where the risk level can be determined by the global risk propagation value). The risk assessment results are pre-classified into three categories based on the relationship with preset risk thresholds: priority retention, restricted execution, and high risk. These results are then directly converted into a risk constraint parameter table that can be read and executed by edge devices. Specifically, the cloud platform first determines the risk propagation value of each candidate action. Regional coupling strength Local deviation terms and motion stability margin Determine the constraint strength value corresponding to each candidate action. Constraint strength value It can be represented by relation (3), which is shown below:

[0116] (3);

[0117] in, This represents the constraint strength value corresponding to candidate action 'a'; 'a' represents the constraint strength value from the global risk assessment result. A candidate action was read from the data. This represents the global risk propagation value; Indicates the regional coupling strength; Indicates a local deviation term; The action stability margin term is calculated by the cloud platform based on the directional changes of similar actions of the same edge node in the most recent scheduling cycles and the remaining adjustment capacity of the equipment, and then uniformly scaled. It is used to characterize the degree to which the equipment adjustment margin is continuously consumed. , , as well as The constraint weight parameters, which are preset on the cloud platform, are configured in the risk constraint generation service of the cloud platform after being tuned by historical operating conditions. They are used to determine the proportion of the influence of the global risk propagation value, regional coupling strength, local deviation term, and action stability margin term on the constraint strength value.

[0118] In this process, all input terms are converted to a uniform comparison scale, and the weight parameters are configured non-negatively and summed to 1. The action stability margin term... The introduction of this factor makes the constraint strength value... It can not only mitigate the propagation risks in global risk assessments but also reflect the sustainable adjustment capabilities of edge devices during continuous scheduling. For example, when energy storage devices perform charging operations for multiple consecutive cycles and their remaining adjustment capacity decreases rapidly, the operation stability margin term... Increase; when the energy storage device operates smoothly and has sufficient remaining regulation capacity, the operational stability margin term increases. Reduce. If the historical operation status cache module of the cloud platform lacks sufficient continuous action records, the cloud platform adopts the default stability margin for this device type and adjusts the risk constraint parameter table accordingly. A default flag is written into the entry, enabling edge devices to recognize the entry as a conservative constraint entry.

[0119] Furthermore, the constraint strength value is obtained on the cloud platform. Subsequently, the cloud platform, combining the risk levels of each candidate action read from the global risk assessment results, maps the candidate actions to corresponding action constraint methods. Specifically, the cloud platform pre-defines low-constraint, medium-constraint, and high-constraint intervals in the risk constraint generation service, and uses the risk level as the interval verification condition. When the constraint strength value... If a candidate action falls within the low-constraint range and its risk level is priority retention, it is marked as a priority retention action, and candidate action 'a' can be written into the risk constraint parameter table. The reserved action field allows edge devices to continue using this candidate action in subsequent scheduling cycles for optimal selection; when the constraint strength value... When an action falls within the medium constraint range or is classified as a restricted action at a risk level, it is marked as a limited action, and candidate action 'a' can be written into the risk constraint parameter table. The limited motion field in the data is used to further calculate the allowed motion ratio. When the constraint strength value When the action falls within a high-constraint range or is classified as high-risk, it is marked as a masked action, and candidate action 'a' can be written into the risk constraint parameter table. The "masking action" field in the code allows edge devices to skip candidate actions when the operating conditions match. However, when the risk level and constraint strength value... When the ranges are inconsistent, the cloud platform adopts a more conservative constraint method, such as a high-risk level but a constraint strength value. When the constraint falls within the medium constraint range, the cloud platform still processes it as a shielded action to ensure that the constraint result is not lower than the risk level requirement. Through the above method, the risk level and constraint strength value are correlated. Both factors contribute to the final determination of the constraint method, and they are mutually verified to ensure that the constraint result reflects both the overall risk level and the multi-dimensional weighted assessment result.

[0120] For limited-amplitude movements, the cloud platform uses a linear reduction approach to calculate the permissible proportion of the movement. This makes the risk constraint parameter table It can directly control the range of motion of edge devices, and the allowable ratio of this motion is... It can be represented by relation (4), which is shown below:

[0121] (4);

[0122] in, This indicates the percentage of actions allowed for candidate action 'a'. This indicates the minimum allowable motion ratio configured on the cloud platform, used to reserve basic adjustment space for limited motion. This indicates the maximum allowed percentage of actions configured on the cloud platform, used to limit the upper limit of action execution under low-constraint conditions; This represents the constraint strength value. The constraint strength values ​​used in the calculation... Minimum allowed proportion of actions and the maximum allowed ratio of actions If all parameters are proportionalized, then the allowable action ratio is... This is also a scaling parameter that can be directly used by edge devices to limit candidate actions. In addition, the cloud platform also verifies the minimum allowed action ratio. Not greater than the maximum permissible motion ratio Both are within the allowed action ratio range of the equipment; if the parameter configuration does not meet this condition, no limit entry will be generated, but a constraint entry to be reviewed will be generated instead.

[0123] Subsequently, the cloud platform uses edge node identifiers and device types as indexes to determine the applicable operating conditions and constraint strength values ​​for each candidate action a (such as energy storage charging, energy storage discharging, reactive power input, reactive power cut-off, load reduction, load restoration, etc.). Action constraint methods and permitted action ratios These are organized into action constraint entries. The applicable operating conditions are generated from the node voltage variation range, line power variation range, and adjustable equipment status range in the global risk assessment results. If the same edge node, the same equipment type, and the same action generate constraint entries under multiple applicable operating conditions, the cloud platform writes them into the risk constraint parameter table according to the operating condition range. This prevents edge devices from misusing the same constraint strength under different voltage or power flow conditions. Therefore, the cloud platform summarizes all action constraint entries to generate a risk constraint parameter table. This risk constraint parameter table It also includes the table version number, generation time, applicable topology version, and validity period. Edge devices can only use this entry if the current operating status meets the applicable operating conditions and the table has not expired.

[0124] For example, in a scenario where energy storage participates in distribution network voltage regulation, the cloud platform obtains the global risk propagation value of a certain energy storage device's charging action. Regional coupling strength and local deviation terms Simultaneously, the cloud-based equipment obtains the operational stability margin term based on the number of consecutive charging cycles and changes in remaining regulation capacity of the energy storage within the most recent scheduling cycles. If risk constraints generate service configuration , , as well as The constraint strength value of this charging action is... If the constraint range configured on the cloud platform is... to Then the constraint strength value of this action If it falls within the medium constraint range, and its risk level is restricted execution, it meets the criteria for a limited action and is therefore marked as a limited action. Furthermore, if... and Then the allowed proportion of this action is Therefore, when edge devices generate candidate energy storage charging actions under similar operating conditions, they can refer to the risk constraint parameter table. Limit the original charging range to approximately Within the allowed range. The constraint strength values ​​and permissible action ratios in the above example are further written into the risk constraint parameter table and read by edge devices for action constraint execution, rather than merely serving as calculation results displayed on the cloud platform.

[0125] In an exemplary embodiment, the above-mentioned S601, "parse the trajectory packet, map the nodes in the trajectory packet to the pre-built main distribution network topology model to perform disturbance propagation simulation, and generate a global risk assessment result," is as follows: Figure 7 As shown, it includes:

[0126] S701 parses the trajectory packet to obtain the parsing results.

[0127] The analysis results include at least node voltage, line power, adjustable device status, edge node identifier, and topology version.

[0128] In this embodiment of the application, after receiving the trajectory packet sent by the edge device and verifying it, the cloud platform processes the trajectory packet... By parsing the data, the node voltage can be obtained. Line power and adjustable device status The system collects operational data and extracts additional information such as edge node identifiers, device types, scheduling cycle numbers, topology versions, model version numbers, and risk constraint parameter table version numbers. Among these, node voltage... This indicates the voltage change of the target node before and after the action is executed; line power. Indicates the power change of the target line before and after the action is executed; adjustable equipment status. This indicates the adjustable direction and remaining adjustment capability of the target device before and after the action is executed; the edge node identifier is used to uniquely identify the edge device that sent the trajectory packet; the topology version indicates the version of the power grid topology to which the trajectory packet applies, so that the cloud platform can perform correct node mapping when the topology changes. After the cloud platform completes the parsing, the parsing results are used as input for subsequent steps, allowing the cloud platform to perform corresponding operations.

[0129] S702 maps the nodes in the trajectory packet to the pre-built main distribution network topology model based on the edge node identifier, and determines the local risk propagation area based on the mapping result.

[0130] In this embodiment, after parsing the trajectory packet, the cloud platform maps the nodes in the trajectory packet to a pre-built main distribution network topology model based on the parsed edge node identifiers and topology versions. During the mapping process, it is necessary not only to associate the target node itself, but also to simultaneously extract the feeder, upstream transformer, adjacent branches, and boundary nodes of the main distribution network to which the target device belongs. Although the actual actions of the edge device only affect a single device, in scenarios with high fluctuations in renewable energy, a single local action may propagate along the feeder to adjacent branches, ultimately affecting the boundary power of the main distribution network. Therefore, the mapping range needs to be extended to the local feeder area where the target node is located and adjacent branches to accurately capture the propagation path and impact range of the action.

[0131] Specifically, the cloud platform first locates the target node in the main distribution network topology model based on the edge node identifier. Then, it extracts the feeder, upstream transformer, adjacent branches, and main distribution network boundary nodes to which the node belongs from the main distribution network topology model, establishing a complete association between the target node and the main distribution network topology. Subsequently, based on this association (i.e., the mapping result), the cloud platform determines the local risk propagation area, centered on the target node and combining its feeder range, adjacent branches, and boundary nodes.

[0132] During the mapping process, the cloud platform also compares the topology version in the trajectory package with the version of the current main and distribution network topology model. If the versions match, the mapping result from the current topology model is directly adopted. If the versions do not match, it indicates a difference between the topology structure used by the edge devices for decision-making and the current topology structure in the cloud, meaning the correspondence of that node in the main and distribution network topology model has changed. In this case, the cloud platform remaps the risk propagation area according to the current topology version and records the topology version change information and the current topology version in the global risk assessment results. This prevents the subsequently generated risk constraint parameter table from being applied to incorrect feeders or boundary nodes. Through this process, the cloud platform can ensure the accuracy of local risk propagation areas and the effectiveness of risk assessment results.

[0133] S703, based on each candidate action, takes the current operating state of the edge device as the starting point, performs disturbance propagation simulation within the local risk propagation area, and obtains the propagation simulation results of each candidate action.

[0134] In this embodiment of the application, after determining the local risk propagation area, the cloud platform reads the actual executed actions and unexecuted candidate actions in the trajectory package, and constructs an independent action propagation branch for each candidate action.

[0135] When the candidate action is the actual action to be executed, the cloud platform directly uses the trajectory package. The operational state after the execution of the action serves as the propagation result of that action and does not require recalculation. This propagation result reflects the actual local impact of the executed action on the local power distribution network.

[0136] When a candidate action is not actually executed (i.e., when the candidate action is not executed), the cloud platform uses the current operating state in the trajectory package as a starting point, treats the candidate action as a disturbance input, and performs disturbance propagation simulation within the local risk propagation area. This simulation process is based on power flow sensitivity analysis methods in power systems, calculating the impact of node injection changes on line power and node voltage to analyze the range of power grid disturbance propagation. Subsequently, based on this, the cloud platform uses edge-end candidate actions as disturbance input and limits the simulation range to the local risk propagation area related to the action node, thus forming a local action risk propagation calculation process suitable for cloud-edge collaborative scenarios.

[0137] To ensure comparability between actual executed actions and unexecuted candidate actions, the cloud platform uses the same current operating state as a benchmark for both, and uses the post-action measurement results of the actually executed actions to correct the local response of that action branch. Furthermore, if the power flow calculation service fails to converge the deduction of a candidate action, the cloud platform marks that candidate action as a high-risk action to be restricted, and does not use invalid power flow results in subsequent constraint generation.

[0138] S704 generates a global risk assessment result based on the results of each propagation simulation.

[0139] In this embodiment, after obtaining the propagation and deduction results of each candidate action, the cloud platform can acquire the boundary power change trend and boundary voltage change trend corresponding to each candidate action based on the propagation and deduction results. Simultaneously, it acquires the regional coupling strength corresponding to each candidate action based on the main distribution network topology model, where the regional coupling strength is determined by the power correlation between the action node and adjacent nodes. Subsequently, based on the node voltage change trend of each candidate action at the edge nodes and the line power change trend of the local lines at the edge, the cloud platform obtains the local deviation term for each candidate action. Based on this, the cloud platform can calculate the global risk propagation value of each candidate action according to the boundary power change trend, boundary voltage change trend, regional coupling strength, and local deviation term. Then, the cloud platform can classify each candidate action into three risk levels—priority retention, restricted execution, or high risk—based on the relationship between the global risk propagation value and a preset risk threshold. Finally, the cloud platform summarizes the global risk propagation value, regional coupling strength, local deviation term, risk level, and operating conditions of each candidate action to form a global risk assessment result.

[0140] In an exemplary embodiment, the phrase "generate a global risk assessment result based on each propagation simulation result" in S704 above, such as... Figure 8 As shown, it includes:

[0141] S801, calculate the local deviation term of each candidate action based on the line power change trend and node voltage transformation trend of each candidate action.

[0142] Among them, local deviation terms It is mainly used to describe the degree of deviation between the local effect of edge devices and the global propagation result of the cloud platform. It is derived from the deviation evaluation approach in engineering control and improved by combining the characteristics of power grid power flow propagation.

[0143] In this embodiment, for each candidate action, the cloud platform calculates a local deviation term for the candidate action based on the difference between the voltage change trend generated by the candidate action at the edge local node and the node voltage change trend generated at adjacent nodes and boundary nodes, and the difference between the line power change trend generated at the edge local line and the line power change trend caused at the main distribution network boundary. It can be represented by relation (5), which is shown below:

[0144] (5);

[0145] in, This represents the local deviation term of candidate action a; This represents the voltage change trend generated by candidate action 'a' at local nodes on the edge, obtained after uniform scaling. For the actual executed action, this value comes from the trajectory packet. The running status after an action is executed. For candidate actions that have not been executed, this value is inferred by the power flow calculation service near the action node. This indicates the voltage change trend of candidate action a at adjacent nodes and boundary-related nodes; This represents the power change trend of candidate action 'a' generated in the local circuit at the edge, obtained after uniform scaling. Its original value comes from the trajectory packet. The changes in line power or the results of power flow analysis after the execution of the intermediate action; This indicates the trend of line power change caused by candidate action a at the boundary of the main and distribution networks; The configuration weights between local voltage deviation and boundary power deviation are defined by the cloud platform based on the voltage regulation sensitivity and power flow fluctuation sensitivity of the target area.

[0146] Using the above calculation method, if the local measurement results corresponding to the candidate action are opposite to the cloud simulation results (i.e., the local voltage at the edge improves but the global boundary voltage deteriorates, or the local power at the edge is stable but the global boundary power fluctuates more), the cloud platform retains the absolute value of the difference and increases the review priority of the action in the subsequent risk level classification, thereby effectively identifying actions that improve locally but deteriorate globally, and providing a quantitative basis for subsequent constraint strength calculation and risk level classification.

[0147] S802 calculates the global risk propagation value of each candidate action based on local deviation terms, line power change trends, node voltage transformation trends, and regional coupling strength.

[0148] The regional coupling strength is determined by the degree of power correlation between the action node and its neighboring nodes.

[0149] In this embodiment, after calculating the local deviation terms of each candidate action, the cloud platform further combines the line power change trend, node voltage change trend, and regional coupling strength corresponding to each candidate action to calculate the global risk propagation value of each candidate action. This global risk propagation value It can be represented by relation (6), which is shown below:

[0150] (6);

[0151] in, This represents the global risk propagation value corresponding to candidate action 'a'; 'a' represents the risk propagation value from the trajectory package obtained by the cloud platform. A candidate action read from the middle; This represents the trend of line power change caused by candidate action a at the boundary of the main and distribution networks. It is obtained after unified scaling. Its original value is calculated by the power flow calculation service based on the local disturbance propagation results. This represents the voltage change trend of candidate action a in adjacent nodes and boundary related nodes. It is obtained after unified scaling. Its original value is calculated by the main distribution network topology model combined with the power flow propagation results. The region coupling strength of candidate action a is represented by a uniform scaling, and its original value is calculated from the power correlation between the action node and its neighboring nodes. The local deviation term of candidate action a is obtained after uniform scaling; , , , These represent the weighting parameters for cloud-based risk assessment. They are configured on the cloud platform after being tuned offline based on historical operating conditions. These parameters are used to determine the proportion of influence of boundary power surges, regional voltage disturbances, regional coupling strength, and local deviations on the global risk propagation value. It is worth noting that the aforementioned weighting parameters... , , , The risk assessment service on the cloud platform is uniformly configured and managed, and this service has a corresponding version number. When the cloud platform updates the assessment algorithm or weight parameters, the version number is updated accordingly. When generating the global risk assessment result, the cloud platform also records the version number of the risk assessment service currently in use, so as to trace the service version corresponding to the global risk assessment result later.

[0152] because , , as well as All values ​​have been standardized, therefore both sides of equation (6) are dimensionless risk values, and the terms can be directly summed using weighted averages. Global risk propagation value The larger the value, the higher the global risk that the candidate work will generate at the main distribution network level.

[0153] There is also a clear logical relationship between the two relations mentioned above: the local deviation term in relation (5) The calculation is first performed by comparing the deviation between the local operation results and the global propagation results, and then the deviation is used as a local deviation term to input the global risk propagation value in relation (6). During the calculation process, through this cascaded computing method, the cloud platform can identify a typical scenario: the actions of edge devices have improved node voltage within a local range, but their propagation to the main distribution network boundary causes greater power flow fluctuations. Therefore, the local deviation term... It is not an intermediate variable that remains idle after independent output, but rather serves as a global risk propagation value. The components of this table continue to influence the generation of subsequent risk constraint parameter tables.

[0154] S803 determines the risk level of each candidate action based on the global risk propagation value and the preset risk level.

[0155] The risk levels are categorized as priority retention, restricted execution, and high risk.

[0156] In this embodiment of the application, the cloud platform obtains the global risk propagation value of each candidate action. Then, based on the global risk propagation value The relationship between the candidate action and a preset risk threshold categorizes each candidate action into different risk levels. The preset risk thresholds are configured by the cloud platform based on historical limit violation records, boundary power fluctuation records, and scheduling safety rules, and are saved along with the risk assessment service version. Specifically, the cloud platform presets a first threshold and a second threshold (where the first threshold is greater than the second threshold). When the global risk propagation value of a candidate action... When the threshold is exceeded, it indicates that the action may cause a serious power surge or voltage overrun at the main distribution network level, and the candidate action is marked as high risk; when the global risk propagation value of the candidate action... When the value falls between the second and first thresholds, it indicates that the action has a certain degree of global propagation risk and needs to be restricted during execution; therefore, the action is marked as restricted. When the value is below the second threshold, it indicates that the propagation risk of the action at the main distribution network level is low or basically controllable, and the action is marked as priority retention. In addition, if a candidate action corresponds to a high global risk propagation value in multiple consecutive trajectory packets... The cloud platform can increase the constraint priority of the candidate action under the same operating conditions, that is, appropriately reduce the threshold for its risk level classification in the risk assessment of subsequent scheduling cycles, so that it can be more easily marked as restricted execution or high risk.

[0157] For example, in scenarios where energy storage participates in distribution network voltage regulation, edge devices in trajectory packets The system records two candidate actions: charging and discharging, with the actual action recorded as charging. The cloud platform determines the adjacent branches and main / distribution network boundary nodes corresponding to the energy storage node based on the main / distribution network topology model, and then performs disturbance propagation simulations for both candidate actions. For the charging action, the cloud platform obtains... , as well as Meanwhile, based on the trajectory package The local running state after the action is executed is obtained , If configured ,but Further configuration of the cloud platform , , as well as ,but The results show that while the charging action improves the local voltage of edge devices, it also causes more significant power propagation changes at the boundary of the main and distribution networks, thus corresponding to a higher global risk propagation value. The cloud platform then compares candidate action a with the global risk propagation value. Regional coupling strength Local deviation terms The operational conditions under which an action is performed are included as part of the overall risk assessment results and are compiled and organized by the cloud platform.

[0158] S804 summarizes the global risk propagation value, regional coupling strength, local deviation term, and risk level of each candidate action to obtain the global risk assessment result.

[0159] In this embodiment of the application, after the cloud platform completes the risk level classification of each candidate action, it propagates the global risk value of each candidate action. Regional coupling strength Local deviation terms The risk levels and the operating conditions under which the actions are performed are summarized to form a complete overall risk assessment result. The results of this global risk assessment It includes all the runtime condition information for each candidate action and uses it as direct input for generating the risk constraint parameter table, enabling the cloud platform to generate a risk constraint parameter table that can be executed by the edge device based on the result.

[0160] The following examples illustrate all the above embodiments, but these examples do not limit the scope of this technical solution.

[0161] In an exemplary application scenario, such as energy storage participating in distribution network voltage regulation, the edge device generates three candidate actions—charging, discharging, and holding—during the current scheduling cycle. After scoring calculation, the charging action receives the highest score and is determined as the actual action to be executed, then sent to the energy storage converter for execution. After execution, the edge device continues to read the node voltage and line power changes within a scheduling cycle, and encapsulates the operating status before execution, the three candidate actions, the actual charging action executed, and the operating status after execution into a trajectory package. This package includes information such as the edge node identifier, device type, action start and end times, and model version number, before being reported to the cloud platform.

[0162] After receiving and verifying the trajectory packet, the cloud platform maps the target node to the main distribution network topology model, determines the local risk propagation area, and performs disturbance propagation simulations for the three candidate actions. For the actually executed charging action, the post-execution running state in the trajectory packet is directly used as the simulation result; for the unexecuted discharging and holding actions, disturbance propagation calculations are performed within the local risk propagation area starting from the current running state. Subsequently, based on the simulation results, the cloud platform calculates the global risk propagation value for each candidate action, where the global risk propagation value for the charging action is 0.6164, the regional coupling strength is 0.80, the local deviation term is 0.356, and the risk level is classified as restricted execution. Then, the cloud platform calculates the constraint strength value to be 0.5986, thus determining that the action is a limited action, and calculates the action allowable ratio to be 0.5810. Finally, the above information is summarized to generate a risk constraint parameter table, which is then distributed to the edge devices.

[0163] The edge device receives and saves the risk constraint parameter table. In the next scheduling cycle, it generates candidate actions again, completes the scoring, matches the constraint entries corresponding to the charging actions, compresses the original charging amplitude to approximately 58.10% based on the allowed proportion of the actions, and then smooths it by combining it with the action amplitude of the previous scheduling cycle before issuing it for execution. If the edge device does not receive a new risk constraint parameter table, it continues to use the old risk constraint parameter table that has not expired; if the old risk constraint parameter table has expired, a safety boundary strategy is adopted for conservative restrictions.

[0164] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0165] Based on the same inventive concept, this application also provides a cloud-edge collaborative power system intelligent dispatching device for implementing the cloud-edge collaborative power system intelligent dispatching method described above. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of one or more cloud-edge collaborative power system intelligent dispatching device embodiments provided below can be found in the limitations of the cloud-edge collaborative power system intelligent dispatching method described above, and will not be repeated here.

[0166] In one exemplary embodiment, such as Figure 9 As shown, a cloud-edge collaborative intelligent dispatching device for power systems is provided, comprising:

[0167] The acquisition module 11 is used to acquire the current scheduling cycle operation data of the target device; the operation data includes at least node voltage, line power and adjustable device status;

[0168] The scoring module 12 is used to determine multiple candidate actions corresponding to the device type of the target device based on the running data, score each candidate action, determine the actual action to be executed based on the scoring results, and send the actual action to the target device for execution.

[0169] The encapsulation module 13 is used to encapsulate multiple candidate actions, actual actions, and the operating status of the target device before and after the actual actions into a trajectory package, and send the trajectory package to the cloud platform to instruct the cloud platform to perform a global risk assessment of the actual actions based on the trajectory package and generate a risk constraint parameter table.

[0170] The constraint module 14 is used to receive the risk constraint parameter table and perform constraint processing on each candidate action in the next cycle according to the risk constraint parameter table.

[0171] In one exemplary embodiment, such as Figure 10 As shown, a cloud-edge collaborative intelligent dispatching device for power systems is also provided, comprising:

[0172] The receiving module 21 is used to receive the trajectory packet sent by the edge device. The trajectory packet includes at least multiple candidate actions, the actual executed action, and the operating status of the target device before and after the actual executed action. The candidate actions are determined by the edge device based on the operating data of the target device and the device type.

[0173] Parsing module 22 is used to parse the trajectory package and generate a risk constraint parameter table based on the parsing results;

[0174] The distribution module 23 is used to distribute the risk constraint parameter table to the edge device, so as to instruct the edge device to perform constraint processing on each candidate action in the next cycle according to the risk constraint parameter table.

[0175] The modules in the two cloud-edge collaborative intelligent dispatching devices for power systems described above can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0176] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 11 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores operational data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network. When the computer program is executed by the processor, it implements a cloud-edge collaborative intelligent power system dispatching method.

[0177] Those skilled in the art will understand that Figure 11The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0178] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps described in the above method embodiments.

[0179] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps described in the above method embodiments.

[0180] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps described in the above method embodiments.

[0181] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps described in the above method embodiments.

[0182] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0183] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0184] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A smart dispatching method for power systems based on cloud-edge collaboration, characterized in that, Applied to edge devices, the method includes: Obtain the current scheduling cycle operation data of the target device; the operation data includes at least node voltage, line power, and adjustable device status; Based on the operational data, multiple candidate actions corresponding to the device type of the target device are determined, and each candidate action is scored. Based on the scoring results, the actual action to be executed is determined and the actual action to be executed is sent to the target device. The candidate actions, the actual actions, and the operating status of the target device before and after the actual actions are encapsulated into a trajectory package, and the trajectory package is sent to the cloud platform to instruct the cloud platform to perform a global risk assessment of the actual actions based on the trajectory package and generate a risk constraint parameter table. Receive the risk constraint parameter table and perform constraint processing on each candidate action in the next cycle according to the risk constraint parameter table.

2. The method according to claim 1, characterized in that, The step of determining the actual action to be performed based on the scoring result and sending the actual action to the target device for execution includes: Obtain the score value of each candidate action output by the pre-built scoring model, and determine the candidate action corresponding to the highest score result among the score values ​​as the actual action to be executed; Determine whether the risk constraint parameter table exists in the current scheduling period; If the risk constraint parameter table exists in the current scheduling period, the actual execution action is limited according to the risk constraint parameter table, and the limited actual execution action is sent to the target device for execution. If the risk constraint parameter table does not exist in the current scheduling period, the magnitude of the actual execution action is limited according to the preset boundary strategy, and the limited actual execution action is sent to the target device for execution.

3. The method according to claim 2, characterized in that, The step of limiting the magnitude of the actual execution action according to the risk constraint parameter table, and then sending the limited actual execution action to the target device for execution, includes: The current operating status of the target device is matched with the applicable operating conditions in the risk constraint parameter table to obtain the matching target entries, and the action marker corresponding to the actual action is obtained according to the target entries; the action marker includes retention, amplitude limiting, and shielding; Different amplitude restrictions are applied to the actual execution action based on different action markers, and the restricted actual execution action is then sent to the target device for execution.

4. The method according to claim 3, characterized in that, The step of applying different amplitude limits to the actual execution action based on different action markers, and then sending the limited actual execution action to the target device for execution, includes: If the action is marked as reserved, the initial action amplitude of the actual action is maintained, and the actual action is sent to the target device for execution. When the action is marked as limited, the action allowable ratio is obtained from the target entry, and the initial action amplitude is compressed according to the action allowable ratio. The compressed actual action is then sent to the target device for execution. When the action is marked as blocked, the candidate action with the second highest score that is not blocked is selected from each of the candidate actions as the replacement action. After the replacement action is subject to a range limit according to the risk constraint parameter table, it is sent to the target device for execution.

5. A smart dispatching method for power systems based on cloud-edge collaboration, characterized in that, Applied to a cloud platform, the method includes: The system receives a trajectory packet sent by an edge device. The trajectory packet includes at least multiple candidate actions, the actual executed action, and the operating status of the target device before and after the actual executed action. The candidate actions are determined by the edge device based on the operating data and device type of the target device. The trajectory package is parsed, and a risk constraint parameter table is generated based on the parsing results; The risk constraint parameter table is sent to the edge device to instruct the edge device to perform constraint processing on each candidate action in the next cycle according to the risk constraint parameter table.

6. The method according to claim 5, characterized in that, The step of parsing the trajectory packet and generating a risk constraint parameter table based on the parsing results includes: The trajectory packet is parsed, and the nodes in the trajectory packet are mapped to a pre-built main distribution network topology model to perform disturbance propagation simulation and generate a global risk assessment result. The risk constraint parameter table is generated based on the global risk assessment results.

7. The method according to claim 6, characterized in that, The process of parsing the trajectory packet, mapping the nodes in the trajectory packet to a pre-constructed main distribution network topology model for disturbance propagation simulation, and generating a global risk assessment result includes: The trajectory packet is parsed to obtain the parsing result; the parsing result includes at least node voltage, line power, adjustable device status, edge node identifier, and topology version; Based on the edge node identifier, the nodes in the trajectory packet are mapped to the pre-constructed main distribution network topology model, and the local risk propagation area is determined based on the mapping result; Based on each of the candidate actions, starting from the current operating state of the edge device, the disturbance propagation is simulated within the local risk propagation area to obtain the propagation simulation results of each of the candidate actions; Based on the propagation simulation results described above, a global risk assessment result is generated.

8. The method according to claim 7, characterized in that, Based on each of the candidate actions, starting from the current operating state, the disturbance propagation simulation is performed within the local risk propagation area to obtain the propagation simulation results of each of the candidate actions, including: When the candidate action is the actual action, the operating state of the target device after the actual action is executed is taken as the propagation and deduction result of the actual action. If the candidate action is not the actual action to be executed, starting from the current operating state, calculate the line power change trend and node voltage transformation trend of each candidate action within the local risk propagation area, and use the line power change trend and node voltage transformation trend as the propagation deduction result of each candidate action.

9. The method according to claim 7, characterized in that, The step of generating a global risk assessment result based on the propagation simulation results includes: Based on the line power change trend and node voltage transformation trend of each candidate action, calculate the local deviation term of each candidate action; Based on the local deviation term, the line power change trend, the node voltage transformation trend, and the regional coupling strength, the global risk propagation value of each candidate action is calculated; the regional coupling strength is determined by the degree of power correlation between the action node and its adjacent nodes. Based on the global risk propagation value and the preset risk level, the risk level of each candidate action is determined; the risk level includes priority retention, restricted execution, and high risk. The global risk propagation value, regional coupling strength, local deviation term, and risk level of each candidate action are summarized to obtain the global risk assessment result.

10. A cloud-edge collaborative intelligent dispatching system for power systems, comprising edge devices and a cloud platform, characterized in that, The edge device is used to perform the steps of the method as described in any one of claims 1-4; the cloud platform is used to perform the steps of the method as described in any one of claims 5-9.

Images