An emergency processing method for out-of-network device interoperability of a power distribution system and related products

Abstract

The application relates to the technical field of power distribution networks, and provides an emergency processing method for device interoperability of a power distribution system and related products, which comprises the following steps: establishing a device capability card; collecting an interoperability session between an external platform and a network external device, and normalizing the interoperability session into an event sequence; extracting device interoperability behavior features; establishing an interoperability contract based on the device capability card and preset power distribution network operation constraints, obtaining a sandbox verification result by passing a to-be-issued instruction through an interoperability constraint sandbox; outputting a risk level and a risk cause label based on the sandbox verification result and the device interoperability behavior features; selecting an action template from a preset emergency strategy library based on the risk level and the risk cause label, generating an emergency action chain based on the action template; executing the emergency action chain after secondary constraint review, and feeding back and updating the execution result. The application can complete risk prediction and emergency disposal before the execution of the interoperability action.

Description

Technical Field

[0001] This application relates to the field of power distribution network technology, and in particular to an emergency handling method and related products for interoperability of external equipment in power distribution systems. Background Technology

[0002] With the large-scale integration of external devices such as distributed photovoltaic systems, user-side energy storage, electric vehicle charging piles, adjustable load terminals, building energy efficiency control terminals, and low-voltage monitoring terminals into the power distribution system, the traditional operation mode of unidirectional control by grid-side equipment is gradually transforming into an operation mode of collaborative interaction among multiple entities including power sources, grids, loads, and storage. Many of these externally controllable devices are built and maintained by users, operators, or third-party aggregation platforms, and their communication protocols, device firmware, control permissions, execution responses, and operational boundaries vary significantly.

[0003] During actual interoperation between off-grid devices and the distribution network system, off-grid devices may simultaneously receive control commands from the distribution automation master station, load aggregation platform, charging operation platform, energy storage management system, operation and maintenance system, and local controller. When the command source is unauthorized, control parameters are out of bounds, equipment status preconditions are not met, commands from different platforms conflict with each other, protocol interaction sequence is abnormal, or equipment firmware response is abnormal, risks such as local voltage fluctuations, feeder overload, backfeeding failure, overcharging and over-discharging of energy storage, overheating of charging piles, and failure of protection coordination may easily occur.

[0004] In the relevant technologies for risk identification in power distribution systems, most rely on threshold alarms, post-event fault diagnosis, or centralized model analysis. These methods typically only detect risks after anomalies have already affected field equipment, making it difficult to determine whether interoperability actions meet equipment status, electrical boundaries, protocol timing, and permission constraints before actual control commands are issued. Some methods require extensive training with multi-source data such as images, text, and time series, placing high demands on edge deployment conditions and data quality. Implementation costs are high in scenarios with frequent changes in off-network device types, inconsistent protocol versions, and unstable field communication quality. Furthermore, existing interoperability management typically focuses on communication connectivity, single-point authentication, or single threshold violation judgment, lacking a unified benchmark that simultaneously covers protocol behavior, state transitions, electrical responses, and control permissions. It also lacks an emergency response mechanism that allows for virtual replay and secondary verification before command execution. Therefore, existing power distribution system risk identification methods cannot complete risk prediction and emergency response before interoperability actions are executed without relying on large-scale training samples. Summary of the Invention

[0005] This application provides an emergency handling method and related products for interoperability of external equipment in power distribution systems, which can complete risk prediction and emergency response before the interoperation action is performed without relying on a large-scale training sample.

[0006] In one aspect, this application provides an emergency handling method for interoperability of external devices in a power distribution system, applied to an edge gateway or station-side server, the method comprising:

[0007] Establish device capability cards for the external devices connected to the power distribution system;

[0008] Collect interoperability sessions between the external platform and the external device, and normalize the interoperability sessions into an event sequence;

[0009] For each of the aforementioned off-network devices, device interoperability behavior features are extracted from the event sequence of the corresponding device based on a preset sliding time window;

[0010] An interoperability contract is established based on the equipment capability card and preset distribution network operation constraints. The proposed instruction is replayed in a state machine and the constraint is verified through an interoperability constraint sandbox to obtain the sandbox verification result. The interoperability constraint sandbox is constructed based on the interoperability contract.

[0011] Based on the sandbox verification results and the device interoperability behavior characteristics, an interoperability risk score is calculated, and the risk level and risk cause label are output according to a preset threshold.

[0012] Based on the risk level and the risk cause label, select an action template from the preset emergency strategy library, and generate an emergency action chain based on the action template;

[0013] The emergency action chain is executed after secondary constraint verification, and the execution results are updated and fed back.

[0014] Furthermore, establishing device capability cards for the external devices connected to the power distribution system includes:

[0015] Register the external devices connected to the power distribution system, and collect the static attributes, communication protocols, electrical operating boundaries, protection interlocking conditions, and local back-off conditions of the external devices to form a device capability card.

[0016] Furthermore, the external platform includes an external business platform, a distribution automation master station, and an aggregation control platform; the process of collecting interoperability sessions between the external platform and the external network devices, and normalizing the interoperability sessions into an event sequence, includes:

[0017] The interoperability sessions of different protocol messages between the external business platform, the power distribution automation master station, the aggregation control platform and the external equipment are collected, and the interoperability sessions of different protocol messages are uniformly converted into event sequences.

[0018] The interoperability session includes control requests, acknowledgment messages, execution feedback, status transmission, alarm receipts, and heartbeat messages; the event sequence includes device, source, time, instruction, parameter, status, electrical operating quantity, response result, and response delay.

[0019] Furthermore, for each of the external devices, extracting device interoperability behavior features from the event sequence of the corresponding device based on a preset sliding time window includes:

[0020] For each of the aforementioned off-network devices, based on a preset sliding time window, the protocol command sequence, state transition relationship, response delay distribution, parameter boundary envelope, power interaction trajectory, and abnormal receipt set are extracted from the event sequence of the corresponding device to form device interoperability behavior characteristics for risk assessment.

[0021] The method further includes:

[0022] The device interoperability behavior characteristics are stored in layers according to device type, model, firmware version, access topology, and operating season.

[0023] Furthermore, the establishment of an interoperability contract based on the equipment capability card and preset distribution network operation constraints includes:

[0024] Extract the set of executable commands, command source permissions, parameter upper and lower limits, status prerequisites, local rollback conditions, and manual confirmation conditions from the device capability card to form device-level constraints;

[0025] Distribution network operation constraints are extracted from the feeder power flow, transformer capacity, node voltage, branch current, reverse power supply limit, and protection settings contained in the equipment capacity card to form feeder-level constraints;

[0026] Write the business platform control scope, minimum control interval, and multi-source instruction interlock rules for the same device into business-level constraints;

[0027] The intersection of the device-level constraints, the feeder-level constraints, and the service-level constraints forms the interoperability contract for the external device at the current access location.

[0028] Furthermore, the emergency action chain is generated in the order of first handling on the communication side, then handling on the control side, and finally handling on the electrical side; the step of selecting an action template from a preset emergency strategy library based on the risk level and the risk cause label, and generating an emergency action chain based on the action template, includes:

[0029] Based on the risk level and the risk cause label, query the action template mapping table. Prioritize triggering communication-side actions based on permission abnormality, protocol timing abnormality, and data freshness abnormality; prioritize triggering control-side actions based on parameter out-of-bounds, response abnormality, and multi-source instruction conflict; and prioritize triggering electrical-side actions based on feeder out-of-limit, protection coordination failure, reverse power supply abnormality, and equipment overheating to obtain the action template.

[0030] Candidate actions are sorted in the order of communication side, control side, and electrical side, and action combinations are enumerated or greedily selected according to the action template to obtain an emergency action chain.

[0031] Furthermore, the execution of the emergency action chain after secondary constraint verification, and the feedback update of the execution result, includes:

[0032] Before the emergency action chain is executed, it is reviewed through the interoperability constraint sandbox, and the emergency action chain is executed after the review is passed to obtain the execution result.

[0033] The execution results are fed back to update the preset action feature library, the preset interoperability contract library, and the preset emergency strategy library;

[0034] If the external device recovers to normal and no hard constraints are triggered after the emergency action chain is executed, the response delay distribution, parameter boundary envelope, power interaction trajectory and state transition probability are updated using a sliding window or exponential smoothing method. If the emergency action chain fails to execute, the external device refuses to execute, or is manually confirmed as an abnormal sample, the corresponding sample is frozen and a review mark is generated. The preset action feature library and preset emergency strategy library are updated after the review is passed.

[0035] On the other hand, this application provides an emergency handling device for interoperability of external devices in a power distribution system, applied to an edge gateway or station-side server, the device comprising:

[0036] The device capability card establishment module is used to establish device capability cards for the external devices connected to the power distribution system.

[0037] An event sequence generation module is used to collect interoperability sessions between an external platform and the external device, and normalize the interoperability sessions into an event sequence.

[0038] The behavior feature extraction module is used to extract device interoperability behavior features from the event sequence of each of the external devices based on a preset sliding time window.

[0039] The sandbox verification module is used to establish an interoperability contract based on the device capability card and preset distribution network operation constraints, and to obtain the sandbox verification result by replaying the state machine and verifying the constraints of the instruction to be issued through the interoperability constraint sandbox; the interoperability constraint sandbox is constructed based on the interoperability contract.

[0040] The risk result output module is used to calculate the interoperability risk score based on the sandbox verification results and the device interoperability behavior characteristics, and output the risk level and risk cause label according to a preset threshold.

[0041] An emergency action chain generation module is used to select an action template from a preset emergency strategy library based on the risk level and the risk cause label, and generate an emergency action chain based on the action template.

[0042] The constraint verification module is used to execute the emergency action chain after a second constraint verification and to update the execution results.

[0043] Furthermore, the device capability card establishment module includes:

[0044] The device capability card establishment submodule is used to register the external devices connected to the power distribution system, collect the static attributes, communication protocols, electrical operating boundaries, protection interlocking conditions and local back-off conditions of the external devices, and form a device capability card.

[0045] Furthermore, the external platform includes an external business platform, a distribution automation master station, and an aggregation control platform; the event sequence generation module includes:

[0046] The event sequence conversion submodule is used to collect interoperability sessions of different protocol messages between the external business platform, the distribution automation master station, the aggregation control platform and the external devices, and to convert the interoperability sessions of different protocol messages into event sequences. The interoperability sessions include control requests, acknowledgment messages, execution feedback, status transmission, alarm receipts and heartbeat messages. The event sequences include device, source, time, instruction, parameter, status, electrical operation quantity, response result and response delay.

[0047] Furthermore, the behavioral feature extraction module includes:

[0048] The behavior feature generation submodule is used to extract, based on a preset sliding time window, protocol command sequence, state transition relationship, response delay distribution, parameter boundary envelope, power interaction trajectory and abnormal receipt set from the event sequence of each of the external devices, forming device interoperability behavior features for risk assessment.

[0049] Furthermore, the device also includes:

[0050] The tiered storage module is used to store the device interoperability behavior characteristics in tiers according to device type, model, firmware version, access topology, and operating season.

[0051] Furthermore, the sandbox verification module includes:

[0052] The interoperability contract establishment submodule is used to extract the set of executable commands, command source permissions, parameter upper and lower limits, status preconditions, local rollback conditions, and manual confirmation conditions from the device capability card to form device-level constraints; extract distribution network operation constraints from the feeder power flow, transformer capacity, node voltage, branch current, reverse power transmission limit, and protection settings contained in the device capability card to form feeder-level constraints; write the service platform control range, minimum control interval, and multi-source command interlocking rules for the same device into the service-level constraints; and take the intersection of the device-level constraints, the feeder-level constraints, and the service-level constraints to form the interoperability contract of the external device at the current access location.

[0053] Furthermore, the emergency action chain is generated in the order of first handling on the communication side, then handling on the control side, and finally handling on the electrical side; the emergency action chain generation module includes:

[0054] The action template selection submodule is used to query the action template mapping table based on the risk level and the risk cause label. Based on permission abnormality, protocol timing abnormality and data freshness abnormality, communication side actions are triggered first. Parameter out of bounds, response abnormality and multi-source instruction conflict are triggered first. Feeder out of limit, protection coordination failure, back power supply abnormality and equipment overheating are triggered first. The action template is obtained.

[0055] The emergency action chain generation submodule is used to sort candidate actions in the order of communication side, control side, and electrical side, and to enumerate or greedily select action combinations according to the action template to obtain the emergency action chain.

[0056] Furthermore, the constraint verification module includes:

[0057] The execution feedback update submodule is used to review the emergency action chain through the interoperability constraint sandbox before execution, and execute the emergency action chain after the review is passed to obtain the execution result; the execution result is fed back to update the preset action feature library, preset interoperability contract library, and preset emergency strategy library; wherein, if the external device recovers to normal after the execution of the emergency action chain and no hard constraints are triggered, the response delay distribution, parameter boundary envelope, power interaction trajectory, and state transition probability are updated using a sliding window or exponential smoothing method; if the emergency action chain fails to execute, the external device refuses to execute, or is manually confirmed as an abnormal sample, the corresponding sample is frozen and a review mark is generated, and the preset action feature library and preset emergency strategy library are updated again after the review is passed.

[0058] In another aspect, this application also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements any of the aforementioned emergency handling methods for interoperability between power distribution system external devices.

[0059] In another aspect, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements any of the aforementioned emergency handling methods for interoperability between power distribution system and external equipment.

[0060] In another aspect, this application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the emergency handling methods for interoperability of external devices in the power distribution system described in the above aspects.

[0061] The emergency handling method and related products for interoperability of external devices in power distribution systems provided in this application establish device capability cards for external devices connected to the power distribution system, collect interoperability sessions between external devices and external platforms, normalize the interoperability sessions into event sequences, and extract device interoperability behavior characteristics from the event sequences of corresponding devices based on a preset sliding time window. Before the actual issuance of control commands, the commands to be issued can be input into an interoperability constraint sandbox built based on interoperability contracts for state machine replay and constraint verification. Then, based on the sandbox verification results and device interoperability behavior characteristics, a risk score is calculated and the risk level and risk cause label are output. Finally, an emergency action chain that has undergone secondary verification is generated based on the risk level and risk cause label, realizing a closed loop of risk prevention and handling. It does not rely on large-scale multimodal training data and can be deployed in the edge gateway of the power distribution area and the station server. Before the execution of interoperability actions of external devices, it can identify unauthorized access, out-of-bounds access, abnormal state transitions, abnormal protocol timing, and electrical safety constraint conflicts, thereby improving the risk prevention capability and emergency handling efficiency in the scenario of external device access in new power distribution systems. Attached Figure Description

[0062] Figure 1 This is a flowchart illustrating the steps of an emergency handling method for interoperability between external devices in a power distribution system, as provided in an embodiment of this application.

[0063] Figure 2 This is a schematic diagram illustrating the implementation process of emergency handling for interoperability of external equipment in a power distribution system, as provided in an embodiment of this application.

[0064] Figure 3 This is a schematic diagram illustrating the construction of device interoperability behavior features provided in an embodiment of this application;

[0065] Figure 4 This is a flowchart illustrating the interoperability constraint sandbox and risk assessment process provided in the embodiments of this application;

[0066] Figure 5 This is a flowchart illustrating the emergency strategy orchestration and closed-loop feedback provided in the embodiments of this application;

[0067] Figure 6 This is a structural block diagram of an emergency handling device for interoperability between external equipment in a power distribution system, provided in an embodiment of this application.

[0068] Figure 7 This is a structural block diagram of an electronic device provided in an embodiment of this application;

[0069] Figure 8 This is a structural block diagram of a computer-readable storage medium provided in an embodiment of this application. Detailed Implementation

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

[0071] To address the issues of delayed risk detection in interoperability of external devices, lack of pre-verification of control commands, difficulty in unified management of differences in protocol behavior among different devices, and lack of closed-loop verification for emergency response actions in related technologies, this application establishes a device capability card for each type or each external device and continuously collects interoperability event sequences. This process identifies device interoperability behavior characteristics from multiple dimensions. Before the actual issuance of control commands, the commands to be issued are input into an interoperability constraint sandbox for state replay and constraint verification. Based on the calculated risk score, risk cause labels and risk levels are output. Finally, an emergency action chain that has undergone secondary verification is generated based on the risk level and risk cause labels, achieving a closed-loop system for pre-emptive risk prevention and response. This approach does not rely on large-scale multimodal training data and can be deployed in distribution substation edge gateways and station servers. It identifies unauthorized access, boundary violations, abnormal state transitions, protocol timing anomalies, and electrical safety constraint conflicts before the execution of interoperability actions by external devices, improving risk prevention capabilities and emergency response efficiency in scenarios involving external device access in new power distribution systems.

[0072] Specifically, by characterizing the normal interoperability mode of external devices using device interoperability behavior features, it is possible to detect risks that are difficult to identify in advance by traditional threshold alarms, such as abnormal protocol order, sudden changes in response delay, parameter out-of-bounds, missing state transitions, and clustering of abnormal receipts. The interoperability constraint sandbox completes pre-verification before the actual issuance of control commands, which can prevent unauthorized commands, conflicting commands, and commands that do not meet electrical safety boundaries from directly acting on field devices. The method provided in this application mainly relies on protocol events, device status, and electrical operation constraints, and does not require the construction of a large-scale multimodal training set, making it suitable for deployment on distribution area edge gateways or station servers with limited computing power and unstable communication quality. The emergency action chain includes multiple actions such as interception, throttling, peak shifting, isolation, local rollback, and manual confirmation, and performs secondary constraint verification before execution, which can reduce mishandling and chain reactions. The continuous updating of behavioral features and policy library through the execution result feedback mechanism can keep the interoperability risk identification capability effective after device firmware upgrades, seasonal changes in operation, and changes in access topology.

[0073] Unlike abnormal alarms based solely on operational thresholds, this application embodiment utilizes the device's own protocol behavior, state changes, and electrical responses to form a comparable behavioral benchmark; unlike security protection based solely on authorization authentication, this application embodiment simultaneously verifies the device status, electrical boundaries, feeder constraints, protection coordination, and control timing before issuing instructions; unlike a single alarm strategy, this application embodiment generates a hierarchical action chain on the communication side, control side, and electrical side based on risk cause labels, and performs constraint review again before execution.

[0074] Reference Figure 1 This document illustrates a flowchart of an emergency handling method for interoperability between external devices in a power distribution system, provided by an embodiment of this application. The method may specifically include the following steps:

[0075] Step S101: Establish device capability cards for external devices connected to the power distribution system.

[0076] The emergency handling method for interoperability of external devices in a power distribution system provided in this application embodiment can be deployed in the edge gateway of a power distribution substation, such as an edge gateway or a station-side server. Optionally, one side of the edge gateway is connected to a distribution automation master station, a load aggregation platform, a charging operation platform, or an energy storage management system, and the other side is connected to distributed photovoltaic inverters, user-side energy storage converters, electric vehicle charging piles, and low-voltage smart terminals. The edge gateway does not change the control logic of the original business system, but adds a risk perception and emergency decision-making process before the interoperability command reaches the field equipment.

[0077] In some embodiments of this application, a device capability card can be established for each type or each off-network device connected to the power distribution system. Based on the device capability card, all inherent attributes of a single device / type of device are structurally solidified, enabling the conversion of non-standard device parameters into standardized metadata that can be parsed by the power distribution master station. This achieves unified modeling of heterogeneous device information, which is conducive to classifying and archiving the common capabilities of similar devices, while recording individual differentiated parameters on a single card, thus taking into account both batch control and precise individual control.

[0078] Optionally, the off-network devices mentioned in the embodiments of this application refer to externally controllable devices that are not uniformly constructed or operated by the main body of the power distribution system, but participate in the operation and regulation of the power distribution system through communication interfaces, aggregation platforms, or edge gateways. These include, but are not limited to, at least one of distributed photovoltaic inverters, user-side energy storage devices, electric vehicle charging piles, adjustable load terminals, building energy efficiency control terminals, and low-voltage monitoring terminals. The embodiments of this application do not impose any limitations on this.

[0079] In practical applications, external devices can have their capability cards read by the edge gateway or manually entered when they connect to the network. In specific implementations, for... Figure 2The process of registering external devices and generating device capability cards involves registering the connected external devices and collecting their static attributes, communication protocol type, electrical operating boundaries, executable command set, command source permissions, minimum control interval, protection action conditions, protection interlock conditions, local backoff conditions, and manual confirmation conditions to form the device capability card. The static attributes include the device's unique identifier, device type, manufacturer, model, firmware version, access feeder, access area, rated power, rated capacity, allowable charge / discharge power range, allowable voltage range, allowable current range, allowable temperature range, and state of charge boundaries.

[0080] For example, for charging piles, the constructed equipment capability card includes rated output power, upper limit of nozzle temperature, lower limit of insulation resistance, supported start and stop commands, maximum allowable continuous operating time, and operation platform control permissions; for energy storage equipment, the constructed equipment capability card includes rated charge and discharge power, upper and lower limits of SOC (State of Charge), upper and lower limits of single-unit voltage, grid connection switch status, maximum ramp rate, and local protection action conditions; for distributed photovoltaic equipment, the constructed equipment capability card includes inverter capacity, reactive power regulation range, anti-islanding protection conditions, and reverse power feeding restrictions. This application embodiment does not impose any limitations on these aspects.

[0081] Step S102: Collect interoperability sessions between the external platform and external devices, and normalize the interoperability sessions into event sequences.

[0082] The interoperability mentioned in the embodiments of this application refers to the two-way interactive process between the external business platform, the aggregation control platform, the power distribution automation master station, the edge gateway and the external devices, which revolves around status reading, control command issuance, execution confirmation, alarm transmission and result feedback.

[0083] In some embodiments of this application, such as Figure 2 As shown, it can collect interoperability sessions between external platforms and external devices and normalize them into event sequences.

[0084] Optionally, the external platforms include external business platforms, distribution automation master stations, and aggregation control platforms. Interoperability sessions between different external platforms and external devices use different protocol messages. The normalization of interoperability sessions is manifested by monitoring the interoperability sessions of different protocol messages between external platforms, distribution automation master stations, aggregation control platforms, and external devices through edge gateways, station servers, or cloud-edge collaboration platforms, and uniformly converting the interoperability sessions of different protocol messages into event sequences.

[0085] Interoperability sessions between different protocol messages can include control requests, acknowledgment messages, execution feedback, status reporting, alarm receipts, and heartbeat messages. The generated event sequence can include device, source, time, command, parameter, status, electrical operating quantity, response result, and response delay.

[0086] In practical applications, messages from different protocols can be uniformly abstracted. For example, start, stop, power setting, mode switching, alarm receipt, and heartbeat messages from IEC 104, Modbus, MQTT, or vendor-specific protocols are all converted into sequence events. Through this abstraction, interoperability processes arising from different vendors, different protocols, and different business platforms can be compared within the same risk identification framework.

[0087] For example, such as Figure 3 As shown, the interoperability event sequence of the i-th device can be represented as:

[0088] ;

[0089] A single event can be defined as follows:

[0090] ;

[0091] In the formula, For equipment identification, As the source of the instruction, For timestamps, For instruction type, For instruction parameter vectors, For device status, For electrical operating quantity vectors, For the device response results, This is for response time delay. The electrical operating quantity vector may include at least one of voltage, current, active power, reactive power, temperature, state of charge, and feeder load rate.

[0092] In this embodiment, each off-network device maintains a full sequence of events corresponding to its device identifier, and can be divided into multiple sub-sequences of events according to sliding time windows, service sessions, or control batches; subsequent behavioral characteristics can be calculated from the sub-sequences of events within a single window, or obtained by aggregating security samples from multiple historical windows. This embodiment does not impose any limitations on this.

[0093] Step S103: For each external device, extract device interoperability behavior features from the event sequence of the corresponding device based on a preset sliding time window.

[0094] In this embodiment, the normal interoperability mode of external devices can be characterized by the device interoperability behavior characteristics, which can detect risks that are difficult to identify in advance by traditional threshold alarms, such as abnormal protocol order, sudden changes in response delay, parameter out-of-bounds, missing state transitions, and abnormal receipt aggregation.

[0095] Specifically, corresponding device interoperability behavior characteristics can be generated for each external device, such as... Figure 2 As shown, this is specifically manifested in extracting protocol command sequences, state transition relationships, response delay distributions, parameter boundary envelopes, power interaction trajectories, and abnormal feedback sets from event sequences to form device interoperability behavior characteristics for risk assessment.

[0096] In practical applications, such as Figure 3 As shown, the edge gateway statistically analyzes device interoperability behavior characteristics within a sliding window. Specifically, this can be achieved by statistically analyzing the command n-ary sequence frequency table, state transition probability matrix, response delay quantiles, parameter boundary envelopes, power ramp-up rates, and anomaly acknowledgment codes from the event sequences of the corresponding devices based on a preset sliding time window, thus forming device interoperability behavior characteristics. The event sequences are provided by the input layer, the aforementioned extraction operations are completed in the feature extraction layer, and the final device interoperability behavior characteristics are output in the output layer.

[0097] For example, the first The interoperability characteristics of individual devices can be represented as follows:

[0098] ;

[0099] In the formula, This is a frequency table of n-ary sequences of commands. The state transition probability matrix is... For response delay quantiles, For parameter boundary envelope, Power ramp rate, This is a collection of abnormal response reports. The above content describes the behavior patterns of the equipment during interoperation and serves as a benchmark for subsequent risk deviation calculations.

[0100] The command n-ary sequence frequency table can be obtained by counting n consecutive command types and their source combinations after sorting the same device events by timestamp. It is mainly used to characterize the protocol interaction sequence, such as "authentication - startup - power setting - execution confirmation - status receipt". The state transition probability matrix can be obtained by statistically analyzing the device state changes in adjacent events. It is mainly used to describe the normal transition relationships between the device from standby, running, power limiting, fault, and maintenance states. The response delay quantiles can be obtained by statistically analyzing response delay samples under the same device, the same command type, or the same command source. It is mainly used to describe the device under different commands. P50 (median delay), P95 (95th percentile delay), and timeout rate; parameter boundary envelopes can be obtained by fusing command parameter vectors and electrical operation vectors from historical safety samples according to quantiles or safety boundaries, and can mainly be used to describe the normal range of parameters such as power, voltage, current, temperature, and SOC; power ramp-up rate can be formed by active power, reactive power, ramp-up rate, and settling time before and after the power setpoint is issued, and can mainly be used to describe the ramp-up rate and settling time of the actual response of the equipment after the power setpoint changes; the abnormal receipt set is obtained by deduplicating and summarizing the failure codes, rejection codes, timeout codes, and alarm receipt codes in the equipment response results.

[0101] For example, the state transition probability matrix can be calculated using a statistical method with a smoothing term, specifically as follows:

[0102] ;

[0103] In the formula, and These represent the device states before and after the state transition; For the state Transition to state Historical frequency; For smoothing coefficients; For the first A set of states for each device; For the first A set of states of a device The state of any selectable successor device in the table represents all possible transfer target states and is a summation traversal variable; Indicates traversing the specified target state of the device. ; For the state Transition to state The number of historical jumps; the summation operation is represented by traversal. All internal states Summary from The total frequency of transitions from the starting state to all subsequent states. The state set of a device is determined by the enumerable states defined in the device capability card and the valid states appearing in the historical event sequence, such as standby, running, power limited, fault, maintenance, offline, and local control states. After deduplication, it forms a set containing the state of the device. A set of device states This application does not limit the scope of the embodiments.

[0104] In some embodiments of this application, such as Figure 3 As shown, at the output layer, device interoperability behavior characteristics can be stored in a hierarchical manner in the behavior characteristic library according to device type, model, firmware version, access topology, and operating season. That is, the generated characteristics correspond to the device type, model, firmware version, and access location.

[0105] It should be noted that the purpose of tiered storage is to avoid mixing the normal behavioral differences between different device types, firmware versions, access topologies, and seasonal operating conditions, so that subsequent risk assessment can refer to behavioral benchmarks that match the current device type, version, and access scenario. This application's embodiments do not impose any limitations on this.

[0106] Step S104: Establish an interoperability contract based on the equipment capability card and preset distribution network operation constraints, and perform state machine replay and constraint verification of the instructions to be issued through the interoperability constraint sandbox to obtain the sandbox verification result.

[0107] In some embodiments of this application, interoperability contracts can be constructed based on equipment capability cards, feeder operation constraints, protection coordination constraints, control authority constraints, and local interlocking conditions. Before the actual issuance of control commands, state machine replay and constraint verification are performed through an interoperability constraint sandbox to achieve the following: Figure 2 The diagram shows the construction of interoperability contracts and the performance of interoperability constraint sandbox replay verification.

[0108] Optionally, the process of establishing an interoperability contract can be manifested as follows: extracting the set of executable commands, command source permissions, parameter upper and lower limits, status preconditions, local rollback conditions, and manual confirmation conditions from the device capability card to form device-level constraints; extracting distribution network operation constraints from the feeder power flow, transformer capacity, node voltage, branch current, reverse power transmission limit, and protection settings contained in the device capability card to form feeder-level constraints; writing the service platform control range, minimum control interval, and interlocking rules for multi-source commands of the same device into the service-level constraints; and finally, taking the intersection of the device-level constraints, feeder-level constraints, and service-level constraints to form the interoperability contract of the external device at the current access location.

[0109] Optionally, the interoperability contract may include instruction whitelist constraints, instruction source permission constraints, device status precondition constraints, parameter boundary constraints, electrical operation boundary constraints, feeder capacity constraints, protection coordination constraints, control timing interlock constraints, local rollback constraints, and manual confirmation constraints; the control instruction to be issued is only allowed to enter the actual issuance process if the interoperability contract is satisfied.

[0110] For example, the set of interoperability contract constraints can be represented as:

[0111] ;

[0112] in, Source permission constraints, These are precondition constraints for the state. For parameter boundary constraints, For electrical operation constraints, For timing interlock constraints, This includes constraints for local rollback and manual confirmation. It should be noted that the generated interoperability contract can be updated with changes in device firmware, protection settings, or access topology; this application embodiment does not impose such limitations.

[0113] Interoperability constraint sandboxes can be built based on interoperability contracts. Specifically, an interoperability constraint sandbox may include a current state cloning module, an instruction parsing module, an access control module, a state machine replay module, a parameter boundary verification module, an electrical constraint solving module, an interlock checking module, and a risk marking module. In practical applications, the interoperability constraint sandbox can pre-verify the source access, state transitions, parameter ranges, power flow impact, protection coordination relationships, and control timing of the control commands to be issued without changing the actual state of the field equipment.

[0114] Constraint verification includes permission verification, parameter boundary verification, electrical boundary solving, and timing interlock checks. In some embodiments of this application, the instruction to be issued can be input into a sandbox, the current equipment state and feeder operating state can be cloned, and state machine replay, permission verification, electrical constraint solving, and timing interlock checks can be performed.

[0115] In some embodiments of this application, the interoperability constraint sandbox can take the intended instruction, the current equipment status, electrical operating quantities and the corresponding interoperability contract as inputs to generate a status snapshot that does not affect the field equipment; the sandbox simulates instruction parsing, permission judgment, state transition, electrical quantity change and response receipt in sequence according to the instruction whitelist, state preconditions, parameter boundaries, electrical operating boundaries and interlock constraints in the interoperability contract, forming the simulated equipment status, feeder operating status and constraint trigger mark.

[0116] In specific implementations, such as Figure 4As shown, the interoperability constraint sandbox can first clone the current device status and feeder operating status, and then parse the control commands to be issued. If the source of the command is not within the corresponding device's permission range, the sandbox can mark it as permission abnormal; if the command parameters exceed the allowable boundaries in the device's capability card, the sandbox can mark it as parameter out of bounds; if the command will cause feeder capacity, voltage exceeding limits, protection coordination, or reverse power supply constraints to be violated, the sandbox can mark it as electrical constraint violation; if the command lacks the necessary prerequisite states, such as the device receiving a power setting command before completing authentication, the sandbox can mark it as a state transition abnormality.

[0117] The instruction to be executed should satisfy the following: .

[0118] In this embodiment, the interoperability constraint sandbox performs pre-verification before the actual issuance of control commands, which can prevent unauthorized commands, conflicting commands, and commands that do not meet electrical safety boundaries from directly acting on field devices.

[0119] Step S105: Calculate the interoperability risk score based on the sandbox verification results and device interoperability behavior characteristics, and output the risk level and risk cause label according to the preset threshold.

[0120] After obtaining the sandbox validation results, these results can be compared with the device interoperability behavior characteristics to obtain a risk comparison result, and then an emergency action chain can be generated based on the risk comparison result. For example... Figure 2 As shown, the sandbox verification results can be compared with the device interoperability behavior characteristics to calculate the risk score, output the risk level and risk cause label, and realize risk quantification and classification.

[0121] Specifically, the interoperability risk score is obtained by weighting multiple normalized indicators. These can be calculated based on state sequence deviation, parameter boundary deviation, response latency deviation, permission anomalies, electrical constraint violations, and data freshness penalty.

[0122] Among them, the state sequence deviation can reflect the difference between the current protocol interaction sequence and the historical normal sequence; the parameter boundary deviation can reflect whether the control parameters exceed the device capability card or historical behavior envelope; the response delay deviation can reflect whether the device response is significantly slower than the historical distribution; the permission anomaly can reflect whether the source of the instruction is legal; the electrical constraint violation can reflect whether the action to be executed damages the feeder, node voltage, branch current, protection coordination or the device's own boundary; and the data freshness penalty can reflect whether the state and electrical quantities used for judgment have become outdated.

[0123] For example, the deviation of the state sequence can be calculated using the similarity of the longest common subsequence between the current command state sequence and the normal behavior sequence:

[0124] ;

[0125] In the formula, It is a set of normal command state sequences stored in the behavioral characteristics. This is the current sequence to be verified. The length of the longest common subsequence. To prevent extremely small positive numbers with a denominator of zero.

[0126] For example, parameter boundary deviation can be expressed as:

[0127] ;

[0128] In the formula, The first one in the sandbox validation results One control parameter, and These are the lower and upper bounds given by the device capability card or behavioral characteristics, respectively, where m is the number of parameters involved in the verification. The first... Each control parameter originates from the parameter vector of the instruction to be issued, or from derived electrical quantities such as voltage, current, power, temperature, and SOC that need to be verified after sandbox simulation. The lower and upper bounds are not simply the maximum and minimum values ​​of all historical data, but are jointly determined by the allowable boundaries given by the device capability card, the safety boundaries given by scheduling or protection, and the quantiles of historical safety samples, with the stricter boundaries being preferred. For newly connected devices or devices with insufficient samples, the boundaries given by the device capability card and distribution network operation constraints can be used first. This application does not impose any limitations on this.

[0129] For example, the response delay deviation can be expressed as:

[0130] ;

[0131] In the formula, and The instructions are respectively This corresponds to the median and 95th percentile of the historical response delay distribution. The currently pending verification command refers to the control command to be issued that is being replayed in the sandbox. If the first... The response delay for a proposed instruction is denoted as ,but It can be estimated from the historical response delay distribution of devices with the same equipment, the same command type, the same source permissions, and similar device states; after the actual receipt arrives, It can be obtained from the difference between the receipt arrival time and the instruction generation or forwarding time, and used for subsequent distributed updates. This application does not limit this.

[0132] Command permission exceptions characterize the legitimacy of the proposed command in terms of its source, command, scope, and confirmation conditions. For example, command permission exceptions are calculated using the following formula:

[0133] ;

[0134] In the formula, The value is 1 if the instruction source is not in the authorized source set, and 0 otherwise. The value is 1 if the instruction type is not in the device's executable command whitelist, and 0 otherwise. The value is 1 if the device, area, feeder, or power range of the instruction exceeds the authorized range, and 0 otherwise. A value of 1 indicates that manual confirmation is required but has not been obtained; otherwise, a value of 0 indicates that manual confirmation is required. to The corresponding weights can be configured by the operation management strategy or adjusted based on historical handling records.

[0135] For example, a violation of an electrical hard constraint can be represented as:

[0136] ;

[0137] Electrical operating constraints may include at least:

[0138] ;

[0139] In the formula, For node voltage, For branch current, For feeder power, , , and These are the corresponding security boundaries.

[0140] The sources of the aforementioned security boundaries include equipment capability cards, distribution network operation modes, protection settings, dispatch limits, and current feeder capacity estimates. When both equipment capability card boundaries and distribution network operation boundaries exist simultaneously, the more stringent one is taken as the sandbox verification boundary. The historical security envelope in the behavioral characteristics is only used as an auxiliary reference and does not cover the hard security boundaries. This application does not impose any limitations on this.

[0141] For example, the data freshness penalty can be represented as:

[0142] ;

[0143] In the formula, For the current moment, The time of the most recent valid status or electrical quantity update. The maximum allowable data lag time.

[0144] Furthermore, the interoperability risk score includes a base risk score and hard constraint correction terms. The base risk score and the final risk score can be expressed as follows:

[0145] ;

[0146] ;

[0147] In the formula, The deviation of the state sequence. For parameter boundary deviation, In response to latency deviation, This is an exception related to instruction permission. This is an electrical constraint violation. This is a penalty item for data freshness. For hard constraint triggering flag, to These are the weighting coefficients. This is the hard constraint correction coefficient.

[0148] Furthermore, the risk level can be determined jointly by the risk score and the hard constraint label:

[0149] ;

[0150] In the formula, , , and These correspond to alert level, deduction level, blocking level, and isolation level, respectively. Mark as a serious risk requiring isolation and treatment.

[0151] Specifically, when any hard constraint among the instruction source authority constraint, electrical safety constraint, protection coordination constraint, local interlock constraint, or manual confirmation constraint is violated, the risk level will be raised to no less than the blocking level; when a violation of a hard constraint would lead to feeder capacity exceeding limits, protection coordination failure, overcharging or over-discharging of energy storage, overheating of charging piles, backfeeding failure, or abnormal grid connection status, the risk level will be raised to the isolation level.

[0152] Step S106: Select an action template from the preset emergency strategy library based on the risk level and risk cause label, and generate an emergency action chain based on the action template.

[0153] In some embodiments of this application, action templates can be selected from the emergency strategy library based on risk level and risk cause labels to generate emergency action chains on the communication side, control side, and electrical side, thereby realizing emergency strategy orchestration.

[0154] Specifically, such as Figure 5 As shown, the emergency strategy library organizes action templates according to risk level and risk cause labels. For example, risk levels can include alert level, depreciation level, blocking level, and isolation level; wherein, the alert level outputs an alarm and continues monitoring, the depreciation level outputs a limit, depreciation, delay, or off-peak execution strategy, the blocking level intercepts the current control command and switches the local control fallback strategy, and the isolation level freezes the interoperability session and triggers an electrical isolation or manual on-site confirmation process.

[0155] In practical applications, when the risk level is at the warning level, the system records the event and prompts for manual review; when the risk level is at the de-rating level, the system can reduce the charging power or energy storage charging and discharging power to a safe range, or group multiple devices for staggered peak operation; when the risk level is at the blocking level, the system intercepts the current control command, sends the blocking reason back to the upper-level platform, and switches the device's local control mode; when the risk level is at the isolation level, the system freezes the interoperability session, and if necessary, performs grid connection switch tripping or notifies on-site personnel for manual confirmation.

[0156] Optionally, the emergency action chain is generated in the order of communication side handling, control side handling, and electrical side handling. The emergency action chain includes at least two actions from the following: command interception, command rewriting, power setpoint derating, equipment grouping and peak shifting, communication session freezing, local control mode switching, grid-connected switch tripping, maintenance work order generation, manual confirmation request, and result receipt.

[0157] Step S107: The emergency action chain is executed after secondary constraint review, and the execution results are updated and fed back.

[0158] The emergency action chain actually executed is the emergency action chain after secondary constraint review. The object of secondary constraint review is the emergency action chain to be executed, not the completed on-site actions. Only when the remaining risk of the action chain after simulation in the sandbox is lower than the current risk and no hard constraints are triggered, it is allowed to enter the actual execution process. If the review fails, the action template is reselected or it is transferred to manual confirmation.

[0159] In practical applications, the interoperability constraint sandbox can be re-entered for review before the action chain is executed. In the specific implementation, the generation of emergency action chains adopts the logic of "tag triggering, hierarchical sorting, combined evaluation, and sandbox review".

[0160] First, the action template mapping table can be queried based on risk level and risk cause tags. Actions on the communication side are triggered first based on permission anomalies, protocol timing anomalies, and data freshness anomalies; actions on the control side are triggered first based on parameter out-of-bounds, response anomalies, and multi-source command conflicts; and actions on the electrical side are triggered first based on feeder out-of-limit, protection coordination failure, backfeeding anomalies, and equipment overheating. This yields the action templates. Then, candidate actions are sorted in the order of communication side, control side, and electrical side, and action combinations are enumerated or greedily selected according to the action templates to obtain the emergency action chain. The current emergency action chain is the candidate action chain. This candidate action chain can then be input into the interoperability constraint sandbox. If the simulation results satisfy the interoperability contract and the remaining risk is minimized, the output is the actual action chain to be executed.

[0161] For example, an emergency action chain can be determined by the following optimization objective:

[0162] ,satisfy ;

[0163] In the formula, Based on risk level and risk reason label The set of candidate actions to be triggered The remaining risk after the action chain is executed. For the cost of execution, To handle the delay, To mitigate the effects of power supply continuity or risk reduction, This is the set of interoperability contract constraints for the corresponding devices. to These are the weighting coefficients.

[0164] In its implementation, the edge gateway first generates communication-side actions based on risk cause tags, such as session freezing, command interception, command rewriting, or upper-level platform acknowledgments. If the communication-side actions are insufficient to reduce the risk, control-side actions are then generated, such as power limiting, derating, delay, peak shifting, or switching local control modes. If hard constraint violations or isolation-level risks still exist, electrical-side actions are generated, such as grid-connected switch tripping, protection interlocking, or manual on-site confirmation. After each layer of actions is generated, the remaining risk after the action is calculated in a sandbox. Only actions that pass secondary constraint review can enter the actual execution queue.

[0165] Among them, the remaining risk is obtained by the risk score after the candidate action chain is simulated and executed in the sandbox; the execution cost is obtained by configuring the action's impact range, user impact level, number of equipment start-ups and shutdowns, and operation and maintenance costs; the handling delay is obtained by statistically analyzing the historical action execution duration or communication timeout threshold; the power supply continuity or risk mitigation effect is calculated by the changes in feeder capacity margin, voltage over-limit degree, equipment safety margin, and risk level before and after the action; the weighting coefficient is pre-configured by the transformer area operation strategy, power supply priority, and emergency handling rules, and can be adjusted according to the historical handling effect.

[0166] Taking the simultaneous receipt of power boost commands from an external aggregation platform by energy storage devices and charging piles within a certain distribution area as an example, the edge gateway first reads the current feeder load rate, voltage level, energy storage SOC, and charging pile nozzle temperature. Then, it replays the intended actions in the interoperability constraint sandbox. If the sandbox determines that simultaneous power boosting of both types of devices would lead to feeder capacity exceeding limits, and the temperature of a charging pile is already close to the upper limit in the device's capacity card, the system marks the interoperability event as a derating or blocking risk. Subsequently, an emergency action chain of "charging pile power derating—energy storage delayed discharge—continuous high-temperature nozzle monitoring—result receipt" is generated and executed after secondary verification to ensure there are no constraint conflicts. This application embodiment does not impose any limitations on this.

[0167] In this embodiment, the emergency action chain includes multiple actions such as interception, reduction of threshold, staggered peak, isolation, local rollback, and manual confirmation. A secondary constraint review is performed before execution, which can reduce mishandling and chain reactions.

[0168] In some embodiments of this application, the emergency action chain is reviewed through an interoperability constraint sandbox before execution. After the review is passed, the emergency action chain can be executed to obtain the execution result, and then... Figure 2 As shown, the execution results will be updated to the preset action feature library, preset interoperability contract library, and preset emergency strategy library.

[0169] After an emergency action is executed, the edge gateway can determine the effectiveness of the response based on device feedback and changes in electrical quantities. In one scenario, if the external device recovers normally after the emergency action chain is executed and no hard constraints are triggered, the response delay distribution, parameter boundary envelope, power interaction trajectory, and state transition probability are updated using a sliding window or exponential smoothing method. This means that the response delay, power ramp-up rate, and state transition results are written into the device interoperability behavior characteristics with low weight, marked as safe samples, and the preset action feature library and preset emergency strategy library are updated. In another scenario, if the emergency action chain fails, the external device refuses to execute, or it is manually identified as an abnormal sample, the corresponding sample is frozen and a verification mark is generated to prevent abnormal data from contaminating normal behavior feature samples. The preset action feature library and preset emergency strategy library are updated only after the verification is passed.

[0170] For example, when the equipment returns to normal after an emergency action is performed and no hard constraints are triggered, the behavioral characteristic parameters are updated using an exponential smoothing method:

[0171] ;

[0172] In the formula, For the updated behavioral feature parameters, These are the behavioral feature parameters before the update. This represents the current statistical value of the safe sample. To update the step size; The equipment response result refers to the operational outcome of the equipment after the emergency action is executed. For the set of safe execution results, The trigger condition for parameter updates represents the equipment's operational result after the emergency action is executed. The result set of the secure execution is used to perform the current exponential smoothing parameter update. Through the above mechanism, the embodiments of this application can adapt to device firmware upgrades, seasonal load changes, and access topology changes.

[0173] In this embodiment of the application, by continuously updating the behavioral characteristics and policy library through the execution result feedback mechanism, the interoperability risk identification capability after device firmware upgrades, seasonal changes in operation, and changes in access topology can remain effective.

[0174] It should be noted that those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of this application. For example, the interoperability constraint sandbox can be deployed on an edge gateway, a station-side server, or a cloud-edge collaboration platform; the risk score weight can be configured according to the type of distribution area, device type, and management strategy; the emergency action chain can also be extended to actions such as manual confirmation, work order dispatch, scheduling interlocking, and synchronous notification from a third-party platform. As long as these modifications and variations fall within the scope of the claims of this application and their equivalents, they should be included within the protection scope of this application.

[0175] In this embodiment, device capability cards are established for external devices connected to the power distribution system, and interoperability sessions between these devices and external platforms are collected. These interoperability sessions are normalized into event sequences, and device interoperability behavior features are extracted from the event sequences of the corresponding devices based on a preset sliding time window. Before the actual issuance of control commands, the commands to be issued can be input into an interoperability constraint sandbox built based on interoperability contracts for state machine replay and constraint verification. Then, risk scores are calculated based on the sandbox verification results and device interoperability behavior features, and risk levels and risk cause labels are output. Finally, an emergency action chain that has undergone secondary verification is generated based on the risk level and risk cause labels, realizing a closed loop of risk prevention and handling. This approach does not rely on large-scale multimodal training data and can be deployed in the edge gateway of the power distribution area and the station server. Before the execution of interoperability actions of external devices, it can identify unauthorized access, out-of-bounds access, abnormal state transitions, abnormal protocol timing, and electrical safety constraint conflicts, thereby improving the risk prevention capabilities and emergency response efficiency in the scenario of external device access in the new power distribution system.

[0176] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0177] Reference Figure 6 This document illustrates a structural block diagram of an emergency handling device for interoperability between external devices in a power distribution system, provided by an embodiment of this application. Applied to an edge gateway or station-side server, it may specifically include the following modules:

[0178] The device capability card establishment module 601 is used to establish device capability cards for external devices connected to the power distribution system.

[0179] The event sequence generation module 602 is used to collect interoperability sessions between an external platform and external devices, and normalize the interoperability sessions into an event sequence.

[0180] The behavior feature extraction module 603 is used to extract device interoperability behavior features from the event sequence of each external device based on a preset sliding time window.

[0181] The sandbox verification module 604 is used to establish interoperability contracts based on equipment capability cards and preset distribution network operation constraints. The intended instructions are replayed through the interoperability constraint sandbox to obtain the sandbox verification results. The interoperability constraint sandbox is constructed based on the interoperability contracts.

[0182] The risk result output module 605 is used to calculate the interoperability risk score based on the sandbox verification results and device interoperability behavior characteristics, and output the risk level and risk cause label according to the preset threshold.

[0183] The emergency action chain generation module 606 is used to select an action template from a preset emergency strategy library based on the risk level and risk cause label, and generate an emergency action chain based on the action template.

[0184] The constraint verification module 607 is used to execute the emergency action chain after a second constraint verification and to update the execution results.

[0185] In some embodiments of this application, the device capability card establishment module 601 may include the following sub-modules:

[0186] The Equipment Capability Card Establishment Submodule is used to register external devices connected to the power distribution system, collect the static attributes, communication protocols, electrical operating boundaries, protection interlocking conditions, and local back-off conditions of the external devices, and form the Equipment Capability Card.

[0187] In some embodiments of this application, the external platform includes an external business platform, a power distribution automation master station, and an aggregation control platform; the event sequence generation module 602 may include the following sub-modules:

[0188] The event sequence conversion submodule is used to collect interoperability sessions of different protocol messages between external business platforms, distribution automation master stations, aggregation control platforms and external devices, and convert the interoperability sessions of different protocol messages into event sequences. The interoperability sessions include control requests, acknowledgment messages, execution feedback, status transmission, alarm receipts and heartbeat messages. The event sequence includes device, source, time, command, parameter, status, electrical operation quantity, response result and response delay.

[0189] In some embodiments of this application, the behavior feature extraction module 603 may include the following sub-modules:

[0190] The behavior feature generation submodule is used to extract protocol command sequences, state transition relationships, response delay distributions, parameter boundary envelopes, power interaction trajectories, and abnormal receipt sets from the event sequences of each external device based on a preset sliding time window, forming device interoperability behavior features for risk assessment.

[0191] In some embodiments of this application, the apparatus provided in this application may further include the following modules:

[0192] The tiered storage module is used to store device interoperability characteristics in tiers according to device type, model, firmware version, access topology, and operating season.

[0193] In some embodiments of this application, the sandbox verification module 604 may include the following sub-modules:

[0194] The interoperability contract establishment submodule is used to extract the set of executable commands, command source permissions, parameter upper and lower limits, status preconditions, local rollback conditions, and manual confirmation conditions from the device capability card to form device-level constraints; extract distribution network operation constraints from the feeder power flow, transformer capacity, node voltage, branch current, reverse power transmission limit, and protection settings contained in the device capability card to form feeder-level constraints; write the service platform control range, minimum control interval, and interlock rules for multi-source commands of the same device into the service-level constraints; and take the intersection of the device-level constraints, feeder-level constraints, and service-level constraints to form the interoperability contract of the external device at the current access location.

[0195] In some embodiments of this application, the emergency action chain is generated in the order of communication-side response, control-side response, and electrical-side response; the emergency action chain generation module 606 may include the following sub-modules:

[0196] The action template selection submodule is used to query the action template mapping table based on risk level and risk cause label. Based on permission abnormality, protocol timing abnormality and data freshness abnormality, communication side actions are triggered first. Parameter out of bounds, response abnormality and multi-source command conflict are triggered first. Feeder out of limit, protection coordination failure, back power supply abnormality and equipment overheating are triggered first. The action template is obtained.

[0197] The emergency action chain generation submodule is used to sort candidate actions in the order of communication side, control side, and electrical side, and to enumerate or greedily select action combinations according to action templates to obtain emergency action chains.

[0198] In some embodiments of this application, the constraint review module 607 may include the following sub-modules:

[0199] The execution feedback update submodule is used to review the emergency action chain through an interoperability constraint sandbox before execution, and execute the emergency action chain after the review is passed to obtain the execution result. The execution result is then fed back to update the preset action feature library, preset interoperability contract library, and preset emergency strategy library. Specifically, if the external device recovers to normal after the execution of the emergency action chain and no hard constraints are triggered, the response delay distribution, parameter boundary envelope, power interaction trajectory, and state transition probability are updated using a sliding window or exponential smoothing method. If the emergency action chain fails to execute, the external device refuses to execute, or it is manually confirmed as an abnormal sample, the corresponding sample is frozen and a review mark is generated. The preset action feature library and preset emergency strategy library are then updated after the review is passed.

[0200] In this embodiment, device capability cards are established for external devices connected to the power distribution system, and interoperability sessions between these devices and external platforms are collected. These interoperability sessions are normalized into event sequences, and device interoperability behavior features are extracted from the event sequences of the corresponding devices based on a preset sliding time window. Before the actual issuance of control commands, the commands to be issued can be input into an interoperability constraint sandbox built based on interoperability contracts for state machine replay and constraint verification. Then, risk scores are calculated based on the sandbox verification results and device interoperability behavior features, and risk levels and risk cause labels are output. Finally, an emergency action chain that has undergone secondary verification is generated based on the risk level and risk cause labels, realizing a closed loop of risk prevention and handling. This approach does not rely on large-scale multimodal training data and can be deployed in the edge gateway of the power distribution area and the station server. Before the execution of interoperability actions of external devices, it can identify unauthorized access, out-of-bounds access, abnormal state transitions, abnormal protocol timing, and electrical safety constraint conflicts, thereby improving the risk prevention capabilities and emergency response efficiency in the scenario of external device access in the new power distribution system.

[0201] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0202] This application also provides an electronic device, see embodiments thereof. Figure 7 The provided electronic device 700 includes a memory 710, a processor 720, and a computer program 711 stored in the memory 710 and capable of running on the processor 720. When the computer program 711 is executed by the processor, it implements the various processes of the above-described emergency handling method embodiment for interoperability of external devices in the power distribution system and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0203] This application also provides a computer-readable storage medium, see embodiments thereof. Figure 8 The computer-readable storage medium 800 provided stores a computer program 711. When the computer program 711 is executed by the processor, it implements the various processes of the above-described emergency handling method embodiment for interoperability of external devices in the power distribution system and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0204] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0205] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of the embodiments of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to these processes, methods, products, or devices. The division of modules in the embodiments of this application is merely a logical division; in actual applications, there may be other division methods. For example, multiple modules may be combined into or integrated into another system, or some features may be ignored or not performed. Additionally, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interface, and the indirect coupling or communication connection between modules may be electrical or other similar forms, none of which are limited in the embodiments of this application. Furthermore, the modules or sub-modules described as separate components may or may not be physically separated, may or may not be physical modules, or may be distributed among multiple circuit modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the embodiments of this application.

[0206] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0207] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0208] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or modules through some interfaces, and may be electrical, mechanical, or other forms.

[0209] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0210] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium.

[0211] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0212] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0213] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0214] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes; these computer program instructions may also be loaded onto a computer or other programmable data processing terminal equipment to cause a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0215] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0216] Finally, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0217] The technical solutions provided in the embodiments of this application have been described in detail above. Specific examples have been used in the embodiments of this application to illustrate the principles and implementation methods of the embodiments of this application. The description of the above embodiments is only for the purpose of helping to understand the methods and core ideas of the embodiments of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the embodiments of this application. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this application.

Claims

1. An emergency handling method for interoperability of external equipment in a power distribution system, characterized in that, Applied to edge gateways or station servers, the method includes: Establish device capability cards for the external devices connected to the power distribution system; Collect interoperability sessions between the external platform and the external device, and normalize the interoperability sessions into an event sequence; For each of the aforementioned off-network devices, device interoperability behavior features are extracted from the event sequence of the corresponding device based on a preset sliding time window; An interoperability contract is established based on the equipment capability card and preset distribution network operation constraints. The proposed instruction is replayed in a state machine and the constraint is verified through an interoperability constraint sandbox to obtain the sandbox verification result. The interoperability constraint sandbox is constructed based on the interoperability contract. Based on the sandbox verification results and the device interoperability behavior characteristics, an interoperability risk score is calculated, and the risk level and risk cause label are output according to a preset threshold. Based on the risk level and the risk cause label, select an action template from the preset emergency strategy library, and generate an emergency action chain based on the action template; The emergency action chain is executed after secondary constraint verification, and the execution result is updated and fed back.

2. The method according to claim 1, characterized in that, The step of establishing device capability cards for the external devices connected to the power distribution system includes: Register the external devices connected to the power distribution system, and collect the static attributes, communication protocols, electrical operating boundaries, protection interlocking conditions, and local back-off conditions of the external devices to form a device capability card.

3. The method according to claim 1, characterized in that, The external platform includes an external business platform, a power distribution automation master station, and an aggregation control platform; the acquisition of interoperability sessions between the external platform and the external devices, and the normalization of the interoperability sessions into an event sequence, includes: The interoperability sessions of different protocol messages between the external business platform, the power distribution automation master station, the aggregation control platform and the external equipment are collected, and the interoperability sessions of different protocol messages are uniformly converted into event sequences. The interoperability session includes control requests, acknowledgment messages, execution feedback, status transmission, alarm receipts, and heartbeat messages; the event sequence includes device, source, time, instruction, parameter, status, electrical operating quantity, response result, and response delay.

4. The method according to claim 1, characterized in that, For each of the external devices, the process of extracting device interoperability behavior features from the event sequence of the corresponding device based on a preset sliding time window includes: For each of the aforementioned off-network devices, based on a preset sliding time window, the protocol command sequence, state transition relationship, response delay distribution, parameter boundary envelope, power interaction trajectory, and abnormal receipt set are extracted from the event sequence of the corresponding device to form device interoperability behavior characteristics for risk assessment. The method further includes: The device interoperability behavior characteristics are stored in layers according to device type, model, firmware version, access topology, and operating season.

5. The method according to claim 1, characterized in that, The establishment of an interoperability contract based on the equipment capability card and preset distribution network operation constraints includes: Extract the set of executable commands, command source permissions, parameter upper and lower limits, status prerequisites, local rollback conditions, and manual confirmation conditions from the device capability card to form device-level constraints; Distribution network operation constraints are extracted from the feeder power flow, transformer capacity, node voltage, branch current, reverse power supply limit, and protection settings contained in the equipment capacity card to form feeder-level constraints; Write the business platform control scope, minimum control interval, and multi-source instruction interlock rules for the same device into business-level constraints; The intersection of the device-level constraints, the feeder-level constraints, and the service-level constraints forms the interoperability contract for the external device at the current access location.

6. The method according to claim 1, characterized in that, The emergency action chain is generated in the order of communication-side response, control-side response, and electrical-side response; the step of selecting an action template from a preset emergency strategy library based on the risk level and the risk cause label, and generating an emergency action chain based on the action template, includes: Based on the risk level and the risk cause label, query the action template mapping table. Prioritize triggering communication-side actions based on permission abnormality, protocol timing abnormality, and data freshness abnormality; prioritize triggering control-side actions based on parameter out-of-bounds, response abnormality, and multi-source instruction conflict; and prioritize triggering electrical-side actions based on feeder out-of-limit, protection coordination failure, reverse power supply abnormality, and equipment overheating to obtain the action template. Candidate actions are sorted in the order of communication side, control side, and electrical side, and action combinations are enumerated or greedily selected according to the action template to obtain an emergency action chain.

7. The method according to claim 1, characterized in that, The execution of the emergency action chain after secondary constraint verification, and the feedback and updating of the execution results, includes: Before the emergency action chain is executed, it is reviewed through the interoperability constraint sandbox, and the emergency action chain is executed after the review is passed to obtain the execution result. The execution results are fed back to update the preset action feature library, the preset interoperability contract library, and the preset emergency strategy library; If the external device recovers to normal and no hard constraints are triggered after the emergency action chain is executed, the response delay distribution, parameter boundary envelope, power interaction trajectory and state transition probability are updated using a sliding window or exponential smoothing method. If the emergency action chain fails to execute, the external device refuses to execute, or is manually confirmed as an abnormal sample, the corresponding sample is frozen and a review mark is generated. The preset action feature library and preset emergency strategy library are updated after the review is passed.

8. An emergency handling device for interoperability of external equipment in a power distribution system, characterized in that, The device, applied to an edge gateway or station server, includes: The device capability card establishment module is used to establish device capability cards for the external devices connected to the power distribution system. An event sequence generation module is used to collect interoperability sessions between an external platform and the external device, and normalize the interoperability sessions into an event sequence. The behavior feature extraction module is used to extract device interoperability behavior features from the event sequence of each of the external devices based on a preset sliding time window. The sandbox verification module is used to establish an interoperability contract based on the device capability card and preset distribution network operation constraints, and to obtain the sandbox verification result by replaying the state machine and verifying the constraints of the instruction to be issued through the interoperability constraint sandbox; the interoperability constraint sandbox is constructed based on the interoperability contract. The risk result output module is used to calculate the interoperability risk score based on the sandbox verification results and the device interoperability behavior characteristics, and output the risk level and risk cause label according to a preset threshold. An emergency action chain generation module is used to select an action template from a preset emergency strategy library based on the risk level and the risk cause label, and generate an emergency action chain based on the action template. The constraint verification module is used to execute the emergency action chain after a second constraint verification and to update the execution results.

9. An electronic device, characterized in that, include: A processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the emergency handling method for interoperability of external equipment in a power distribution system as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the emergency handling method for interoperability of external devices in a power distribution system as described in any one of claims 1 to 7.

Images