A Power Grid Transfer Verification Method Based on Digital Twins

Abstract

This invention discloses a power grid transfer verification method based on digital twins, relating to the field of power grid dispatching technology. The method includes the following steps: First, a dual-track isolation architecture of associated and asynchronous coexisting modes is constructed. Data sections are captured and extracted from the associated mode. Then, unstructured dispatching operation text is processed through Chinese word segmentation, stop word removal, normalized object standardization, and action vector extraction to generate a structured underlying operation script matrix. Subsequently, in the asynchronous coexisting mode, single-step dispatching operations are executed line by line according to the script matrix, and topology analysis, electromechanical transients, and dynamic power flow cross-verification are performed after each micro-state switching action. When overload or hidden risks are identified, safety blocking, full-network load rebalancing, rewriting of the original dispatching command control script, and re-verification are executed. This invention can improve the accuracy and closed-loop handling of transfer verification and enhance the consistency of on-site execution without interfering with the monitoring of the physical power grid operation.

Description

Technical Field

[0001] This invention relates to the field of power grid dispatching technology, specifically a power grid transfer verification method based on digital twins. Background Technology

[0002] For tasks such as power grid fault repair, planned maintenance, operation mode adjustment, and load transfer handling: dispatchers draft switching operations based on the current operating segment, determine the opening and closing sequence of tie switches, check that the transfer path meets operational constraints, and prepare operation tickets or emergency response plans. The current mainstream technical process typically involves obtaining the current time segment from dispatching or substation monitoring, constructing a local simulation or candidate transfer scheme, and verifying the executability of the operation sequence by combining error prevention rules, five-prevention logic, or power flow verification.

[0003] Chinese patent document CN113177081A discloses a method for one-click sequential control operation ticket verification without power outages using visual verification. This document is mainly applied to systems at the plant level, involving a monitoring host, an intelligent anti-misoperation device, and a measurement and control device. Its main principle is as follows: The operating status data of primary and secondary equipment at the current time segment are obtained from the monitoring host and stored in a local database as analog data. The real-time screen reads the real-time database, and the analog screen reads the local database, thus isolating the data and screen between the operating and analog states. Next, the monitoring host sends the sequential control operation ticket and corresponding analog simulation data to the intelligent anti-misoperation device. The anti-misoperation logic of the intelligent anti-misoperation device and an independent intelligent anti-misoperation device complete a single-step anti-misoperation verification. After the single-step simulation passes, the monitoring host sends remote control selection and cancellation commands to the measurement and control device and verifies the remote control link channel. After all verifications are completed, the CrC checksum of the operation ticket is updated, and a verification record file is generated. Therefore, this technology mainly verifies sequential control operation tickets under power outage conditions through local analog state verification, dual-set anti-misoperation verification, and visual simulation.

[0004] While the aforementioned existing technologies demonstrate clear applicability in power plant-level sequential control ticket verification scenarios, they still have limitations in power grid transfer verification scenarios. Firstly, the input objects remain existing operation tickets and the status of equipment within the station. Dispatch command texts written in natural language by dispatchers cannot be imported into the simulation chain. The connection between the text content and the executable model still requires manual equipment location, status matching, and step organization, resulting in a separation between semantic expression and simulation verification. Secondly, the verification focus of this scheme is on single-step anti-misoperation interlocking, equipment status verification, and remote control link verification, which still falls under the category of operability judgment before power plant-level sequential control execution. The analysis of common transfer scenarios such as temporary paralleling, asynchronous loop closure, transient disturbance-triggered protection actions, and intermediate transitional states caused by multi-path load transfer during power flow redistribution remains insufficient. Thirdly, when candidate transfer paths encounter limitations or operational obstacles during verification, the existing process requires dispatchers to re-modify tickets, recalculate, and reorganize the sequence, easily leading to a disconnect between ticket preparation and contingency plan development.

[0005] Based on the above, the current objective technical problem is how to perform full-process and consistent verification of the transfer operation content written by the dispatcher without affecting the existing network monitoring, and reduce the burden of manual trial and error in complex intermediate states and multi-path load transfer scenarios. Summary of the Invention

[0006] (a) Technical problems to be solved To address the shortcomings of existing technologies, this invention provides a power grid transfer verification method based on digital twins. It performs Chinese word segmentation, stop word removal, object normalization, and action vector extraction on unstructured dispatch operation text to generate a structured underlying operation script matrix. Subsequently, in asynchronous symbiotic mode, single-step dispatch operations are executed line by line according to the script matrix, and topology analysis, electromechanical transients, and dynamic power flow cross-verification are performed after each micro-state switching action. When overload or hidden risks are identified, safety blocking, network-wide load rebalancing, rewriting of the original dispatch control script, and reverification are executed. This method improves the accuracy and closed-loop management of transfer verification and enhances the consistency of on-site execution without interfering with the monitoring of the physical power grid operation; it solves the technical problems described in the background art.

[0007] (II) Technical Solution To achieve the above objectives, the present invention provides the following technical solution: The power grid transfer verification method based on digital twins includes: establishing a twin power grid with associated mode based on the real-time state of the power grid; capturing and stripping data sections from the associated mode during transfer rehearsals or operation ticket verification, and starting the asynchronous coexistence mode; importing unstructured scheduling operation text, and generating a structured underlying operation script matrix through Chinese word segmentation, stop word removal, normalized object normalization, and action vector extraction. In asynchronous symbiotic mode, single-step scheduling operations are executed line by line according to the structured underlying operation script matrix, and topology analysis, electromechanical transient and dynamic power flow cross-verification are performed after each micro-state switching action. When an overload or hidden risk is identified, a safety shutdown, a full-network load rebalancing, and a rewriting and re-verification of the original dispatch control script are performed. After verification, the instruction sequence that has passed the safety check is backfilled into the production management system and a dispatch instruction ticket and a power grid accident handling plan are generated.

[0008] Furthermore, when establishing a twin power grid in the companion mode, the CIME model and real-time cross-section of EMS, the equipment ledger of PMS, and the real-time data of the information protection system are collected. Based on the data, a physical model of the primary system and a mechanism model of the secondary system are established, and the companion mode is made to run synchronously with the real-time state of the power grid. An asynchronous symbiotic mode is started in the container cluster.

[0009] Furthermore, when extracting and separating data sections from the coexisting mode, the current switch status, disconnector status, bus energization relationship, main transformer operation status, line power flow information, and secondary protection activation / deactivation status are synchronously solidified, and the synchronous solidification results are used as the initial sections for power transfer pre-rehearsal and operation ticket verification in the asynchronous coexisting mode.

[0010] Furthermore, the parsing of unstructured scheduling operation text is performed in the following order: Chinese word segmentation, stop word removal, normalized object normalization, and action vector extraction. Chinese word segmentation is based on power entities and action terms in the power proprietary knowledge graph. Stop word removal is used to remove redundant function words that do not represent control meaning and retain operation sequence information.

[0011] Furthermore, the normalization of objects includes a unified mapping of heterogeneous colloquial descriptions of the same device, binding the device name filled in by the operator to the standard CIME node identification code in the twin physical model; the action vector extraction includes parsing the specific action intent and combining the specific action intents into a structured underlying operation script matrix according to the execution order.

[0012] Furthermore, in the asynchronous symbiotic mode, single-step scheduling operations are executed one by one according to the structured underlying operation script matrix. After each micro-state switching action is completed, the current pre-run process is immediately suspended. The topology relationship, electromechanical transient process and dynamic power flow state corresponding to the micro-state are cross-validated before deciding whether to continue executing the next single-step scheduling operation.

[0013] Furthermore, cross-validation includes: performing risk interception of the combined loop for the states at both ends of the switch break, performing protection maloperation interception for transient electrical fluctuations caused by micro-state operations, performing heavy overload interception for the target path after single-step load transfer, and establishing a correlation between each interception result and the micro-state switching action that triggered the interception result and its corresponding physical operation steps.

[0014] Furthermore, when cross-validation identifies overload or hidden risks, it first performs a security block on the current pre-process and highlights the specific physical operation steps that intercept the error. Then, it triggers a full-network load rebalancing by eliminating the single-step over-limit as a constraint, and keeps the remaining unexecuted steps in the asynchronous coexistence mode in a state of waiting to be rewritten.

[0015] Furthermore, the network-wide load rebalancing includes re-searching for interconnection relationships across the entire network, calculating alternative power sources, adjusting the output of virtual generators, and determining the load transfer ratio allocation; the rewriting of the original dispatch control script includes replacing the corresponding steps in the original script based on the alternative power sources and the load transfer ratio allocation, and then re-entering cross-validation.

[0016] Furthermore, when the cross-validation is successful, the instruction sequence that has passed the security check will be backfilled into the production management system via the browser plugin WebAPI or reserved interface. Standardized dispatch instruction tickets will be generated according to the execution order of the structured underlying operation script matrix, and power grid accident handling plans corresponding to the dispatch instruction tickets will be generated simultaneously.

[0017] (III) Beneficial Effects This invention provides a power grid transfer verification method based on digital twins, which has the following beneficial effects: By isolating the accompanying mode and the asynchronous symbiotic mode, the power transfer rehearsal and operation ticket verification are completed in a separate environment, protecting the operation monitoring link of the physical power grid from disturbance. The verification starting point is consistent with the production section, so as not to affect the on-site operation judgment and to provide a section basis for subsequent script execution. By performing Chinese word segmentation, stop word removal, object normalization and action vector extraction on the unstructured dispatch operation text, the colloquial equipment names and action descriptions are converted into a structured underlying operation script matrix, emphasizing the consistency of dispatch objects, actions and execution order, and avoiding script deviations caused by human misreading.

[0018] The asynchronous symbiotic mode performs single-step scheduling operations line by line according to the structured underlying operation script matrix. After each micro-state switching, topology analysis, electromechanical transients, and dynamic power flow cross-verification are performed immediately. Risk identification is moved from the final state to the intermediate state. It can detect anomalies in the combined loop, protection trigger boundaries, and path limits caused by single-step operations. After overload or hidden risks are discovered, the specific physical operation steps that caused the error are found through safety blocking, network-wide load rebalancing, rewriting and reverification of the original dispatch control script. The alternative transfer strategy is regenerated around the steps, forming a closed-loop processing chain that connects verification, correction, and review, reducing manual ticket modification.

[0019] By backfilling the safety-verified instruction sequence into the production management system after all verifications are completed, dispatch instruction tickets and power grid accident handling plans are generated. This ensures that the front-end dispatch order parsing results, intermediate simulation results, and back-end business tickets are from the same source, reducing errors and execution deviations caused by manual transcription and repetitive processing, and making the dispatch and handling process seamless. Attached Figure Description

[0020] Figure 1 This is a diagram of the overall business architecture for power grid transfer verification in this invention; Figure 2 This is a schematic diagram illustrating the freezing of the associated cross-section and the peeling of the symbiotic sandbox in this invention. Figure 3 This is a flowchart of the semantic parsing of command text and generation of action scripts in this invention; Figure 4 This is a flowchart of the micro-state step-by-step verification process based on single-step scheduling in this invention; Figure 5This is a flowchart of the rebalancing process after the security block of the present invention. Figure 6 This is a schematic diagram illustrating the unified release object generation and dual document backfilling of the present invention. Detailed Implementation

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

[0022] Please see Figures 1-6 This invention provides a power grid transfer verification method based on digital twins, comprising: Step 1: First, compress the current operating section, equipment ledger, secondary device relationships, and operational procedures of the physical power grid into a replicable, separable, and independently analyzable symbiotic section base. Then, place this base in a container sandbox physically separated from the production monitoring link, providing a unique state starting point for subsequent natural language dispatch command parsing, single-step dispatch step verification, and power transfer self-healing rewriting. Completely separate the two responsibility chains: the accompanying mode responsible for grid tracking and the symbiotic mode responsible for test tickets. This ensures that high-frequency simulations, repeated rollbacks, and multi-branch pre-simulations do not write back to the accompanying mode and do not occupy the continuous refresh capability of the main dispatch screen.

[0023] In existing scheduling scenarios, the reason why transfer verification tends to remain at the level of manual experience is not due to a lack of power flow algorithms, but rather because the operational and simulation operations have long shared the same set of state representations: the cross-sections seen by the duty officer on the main interface have to fulfill both monitoring responsibilities and temporary calculations, leading to cross-section refreshes, manual data setting, and simulation rollbacks becoming intertwined. There are two existing operational modes: a companion mode for synchronous operation, handling operational verification and incident analysis, and a symbiotic mode for offline applications after cross-section synchronization, handling two-ticket generation and joint drills. Simultaneously, the system aggregates models and states through EMS, PMS, and the information security system, and uses WebAPI, a publishing server, gRPC, and a Kubernetes cluster to form a computing channel.

[0024] Based on this foundation, the task of step one is not to rebuild a simulation platform, but to clarify within the existing platform who is responsible for continuously mapping the physical power grid and who is responsible for undertaking one-time power transfer tests, thus cutting off the state pollution chain at the source.

[0025] This step is completed collaboratively by the companion mode twin engine, the publishing server, and the symbiotic mode sandbox engine. The companion mode twin engine continuously receives the EMS's CIME model and current operating section, PMS equipment ledger, and secondary device and action association information from the information security side, maintaining a companion power grid locally with the same name, topology, and state as the physical power grid. When the browser receives a transfer verification trigger command, the user's computer does not directly modify the companion power grid, but instead sends the verification request plus the current operation topic to the publishing server via WebAPI. The publishing server then requests a new symbiotic mode sandbox instance from the container cluster via gRPC.

[0026] Subsequently, the companion mode performs only two tasks: first, it freezes the current cross-sectional snapshot; second, it copies this snapshot, along with the model index table, equipment status table, protection setting association table, and operation process constraint table, into the sandbox instance. Up to this point, the companion mode continues to track the physical power grid, while the sandbox obtains an independent starting point that will no longer be refreshed or overwritten by external updates.

[0027] Upon receiving the transfer verification trigger instruction, the publishing server uses a unified timestamp. Generate symbiotic cross-section base The co-existing cross-section base includes at least a primary topology table, a switch status table, a comprehensive equipment status table, a bus voltage table, a line and main transformer load table, a protection device activation / deactivation table, a backup automatic transfer threshold table, an object identification code table, an equipment alias table, and an operating unit table. When the maximum difference in timestamps of each sub-table exceeds the preset synchronization tolerance, the co-existing cross-section base is refused to be generated and a cross-section asynchrony alarm is returned.

[0028] Upon receiving a verification request, the twin engine in the companion mode first performs a section freezing action, which means writing the current primary equipment switch position, disconnector position, bus energization relationship, main transformer tap position, line power flow direction, secondary device activation / deactivation position, and standby automatic transfer availability status into a symbiotic section base.

[0029] Freezing is not simply copying database records; it involves packaging the association chains that will actually be used in subsequent deductions: the device identification code still uses a unique identifier consistent with the CIME node, and the device aliases, interval affiliations, plant / station levels, and primary and secondary mapping relationships in the ledger are not renamed. This ensures that when object unification is performed in step two, any natural language device name can ultimately be attributed to a unique object in this base. To avoid the symbiotic mode pulling incremental states from the outside again after loading, the subscription to the companion refresh channel is cut off after the symbiotic cross-section base is written, retaining only the read-only index.

[0030] Even if the operator subsequently performs queries, zooms in on graphics, or synchronizes new cross-sections on the main screen, the power transfer verification within the sandbox continues along the original starting point. The interface actions regarding synchronizing the real-time status of the power grid, dynamic power flow changes, and right-clicking to close or open switches or set the status of integrated equipment correspond precisely to the data collection boundary of the source status before freezing in this step.

[0031] Taking the power transfer verification of a substation in a certain area as an example, the operator first completes the cross-section synchronization on the main interface, and sees that the busbars, main transformers, and outgoing lines in the station are all displayed according to their current operating positions. Then, by clicking the power transfer verification entry on the browser page, the system does not directly change the switches on the current main image, but generates a coexisting cross-section base in the background that is consistent with the current screen. After that, even if the operator continues to browse other substation screens, or clicks on cross-section synchronization again, the power transfer test that is currently underway in the background will maintain its original equipment arrangement and power flow distribution. It will not suddenly jump to a new operating time, nor will it write the opening and closing results of the test back to the main image. The visible result on site is: the main screen continues to perform monitoring, while the sandbox screen separately performs test tickets; the two are from the same source but are isolated.

[0032] After obtaining the symbiotic profile base, the release server selects an idle worker node in the container cluster and starts a pre-packaged symbiotic mode image. This image includes at least a physical model loader, a mechanism model loader, an operation flow constraint loader, and a script execution queue, but does not include the continuous refresh task for the symbiotic mode. During loading, the system topology is restored once, then the secondary protection and automatic device relationships are attached. Subsequently, a device state register area that only takes effect within the sandbox is established, so that any subsequent script actions only modify the state bits in the register area, without modifying the symbiotic mode source table. For implementation paths requiring stronger boundary isolation, a short-lifecycle approach of one container per verification can be adopted; for implementation paths with continuous batch verification, a long-lifecycle approach of one sandbox instance per shift can be adopted, but each command still corresponds to an independent profile base and an independent script queue. Regardless of the path used, three types of objects are uniformly output externally: symbiotic instance identifier, object index directory, and state baseline table. The former is used to bind the execution context of this command in step two, the middle is used for direct invocation of object normalization and action mapping, and the latter serves as the initial comparison baseline when step three performs step-by-step scheduling suspension verification.

[0033] In a preferred embodiment, after receiving a request, the publishing server first verifies whether a complete EMS model, PMS ledger, and insurance association exist at that moment. If the verification is successful, it then issues a creation command to the Kubernetes cluster. The cluster loads the symbiotic mode image from the image repository and mounts the read-only model volume. If a certain type of source data is missing pages, such as a missing alias mapping for a certain interval in the ledger, the system does not proceed to step two. Instead, it directly returns a blocking result indicating an incomplete object index and retains the already generated symbiotic instance identifier for manual completion and reloading.

[0034] If a parallel expansion scheme is adopted, the container orchestration can be replaced with a process sandbox or virtual machine sandbox with equivalent functionality, and the WebAPI / gRPC link can be replaced with a message bus plus a service gateway. As long as the principles of continuous network tracking in companion mode, segment separation in symbiotic mode, and script execution without rewriting the source segment are still satisfied, they all fall under the same inventive concept.

[0035] When the co-occurrence mode detects that a model update task is in progress at the freeze time, it does not directly capture the half-update state. Instead, it delays until the model index table, primary and secondary mapping table, and cross-section status table are in the same version before generating the co-occurrence cross-section base. This avoids the misalignment situation where step two maps the equipment aliases in the dispatch order to the old index, while step three executes according to the new topology. For the transfer verification involving cross-regional tie lines, it is preferable to simultaneously solidify the boundary substation, tie switch, and receiving end load summary information in the co-occurrence mode so that the boundary conditions seen in the sandbox are consistent with the freeze time. If only a single station switching is simulated, only the cut subnet of the station and its upstream power supply path can be loaded to shorten the base loading link, but the object identification code remains unique across the entire network and is not locally modified.

[0036] In use, by first freezing the associated cross section and then peeling off the symbiotic cross section base, step one separates production monitoring and transfer testing onto two non-overlapping state chains, allowing subsequent scripts to repeatedly perform trial calculations without affecting the main network mapping. By loading the device index, protection association, and process constraints together in the symbiotic mode, step two no longer requires temporary cross-database object searching, and the device name in the command can directly fall into a unique object.

[0037] Step 2: Translate the dispatch text written by the duty officer in natural language into an action script matrix that can be executed line by line in the symbiotic mode sandbox, following the symbiotic instance identifier, object index directory and state baseline table formed in Step 1. This ensures that subsequent micro-state step-by-step deductions are based on definite objects, definite actions and definite order, rather than vague spoken language.

[0038] Although step one has separated the physical power grid into an independently operable symbiotic cross-section base, a critical breakpoint still exists in the power transfer verification: the dispatcher submits Chinese dispatch order text, while the symbiotic mode sandbox can execute underlying scripts with clear objects, states, and sequences. If this step still relies on manual line-by-line device selection, the isolation simulation chain established in step one will fall back to manual model configuration at the entry point.

[0039] Therefore, the command text is compressed into a mechanism mapping result oriented towards power objects and switching actions, and this result is aligned item by item with the object index directory output in step one, so that step three no longer needs to guess which device, which target state, or which execution order this sentence corresponds to.

[0040] This step is jointly completed by the command input interface on the browser side, the semantic parsing service on the publishing server, and the script assembler in the symbiotic mode sandbox. The command input interface on the browser side receives the command text entered manually or read back from the production management system, and first cuts it into a sequence of command clauses according to line numbers, full stops, semicolons, or line breaks; the semantic parsing service on the publishing server executes the power semantic funnel on each sequence of command clauses, first extracts device tokens and action tokens, then uses the object index directory given in Step 1 to perform object landing verification, and then combines with the status baseline table to judge whether the action has a starting condition in the current symbiotic section; the script assembler in the symbiotic mode sandbox then rewrites the normalized objects and action tokens that have passed the verification into an action script matrix. Each row in this action script matrix only retains four types of fields, namely execution order, object identification code, target state, and precondition constraints; in this way, when Step 3 reads, it can directly schedule and verify each single step in sequence.

[0041] In the preferred implementation, the semantic parsing service is deployed in the publishing server container, uses a UTF-8 text receiving interface, and performs layout normalization before entering word segmentation: unify consecutive spaces, spoken pauses, full-width and half-width parentheses, and arrow symbols commonly written manually into internal marks, and then cut out the sequence of command clauses according to the principle of retaining the integrity of actions within a sentence and the order between sentences.

[0042] When each sequence of command clauses enters the Chinese word segmentation stage, instead of directly applying the general word segmentation dictionary, it preferentially calls the power-specific knowledge graph for plant names, bay names, device aliases, protection names, state names, and action terms, and uses the segmentation rule of giving priority to the longest device phrase, absorbing the action phrase later, and backfilling the remaining fragments, cutting "After the 110 kV Jia Line is transferred from operation to maintenance, disconnect the circuit breaker of the Jia Line" into voltage level, line object, state migration action, and switch action. Immediately afterwards, in the stop word removal stage, connection words such as "will", "afterwards", "and", "again", "after in place" that do not carry physical control meaning but will disrupt the action boundary are deleted, and only the core tokens that determine the object and action are retained. After this processing, the original whole command sentence will be converged into a dense token chain oriented to grid objects, and there will be no misbinding of downstream objects due to natural language rhetoric differences. The semantic parsing flow chart has given the basic link of first word segmentation and then stop word removal. In this step, the rule of giving priority to long device words and absorbing actions later is further embedded in it, so that the text has boundary stability in the power scenario before entering object normalization.

[0043] Taking a common field dispatch order as an example, the duty officer enters "Transfer the 110kV A busbar transformer at the North Station to maintenance and disconnect the A busbar PT switch" into the command input interface. After receiving the order, the system first retains the control-related segments: North Station, 110kV, A busbar, busbar transformer, transfer to maintenance, A busbar PT switch, and disconnect. Then, it deletes connecting words like "transfer" and "disconnect". At this point, the operation ticket is not immediately generated on the interface. Instead, two converged lexical chains are obtained in the background: the first chain points to a state transition, and the second chain points to a switch operation. The result that the duty officer can see is that the original sentence is still displayed as is, but two new objectified records to be verified are added below it for further checking.

[0044] After the candidate lexical chain is formed, the semantic parsing service uses the object index directory output in step one as the sole reference to perform normalized object unification for each device lexical. The unification process does not use a single fuzzy matching method, but rather a three-layer convergence process: first, it filters out objects with the same name from different stations based on the substation level and voltage level; then, it filters out heterogeneous objects such as busbar transformers and line transformers based on equipment category; finally, it merges objects with the same name based on the alias table, ledger name, and diagram name, converging busbar transformers, busbar PTs, and A-type busbar PTs to the same object identification code. After object unification is completed, the system reads the status baseline table and performs initial condition verification on the action lexical.

[0045] For example, a transition from operation to maintenance is only accepted if the current state baseline table records the object as being in the operation state; if the state baseline table shows the object is already in the maintenance state, the command clause is marked as having a false precondition, and the browser returns the specific reason for the blockage. Subsequently, the action unwinder breaks down complex actions into single-step scheduling sequences: state transition actions are broken down into corresponding protection switching, switch opening / closing, and flag modification sequences, while single switch actions directly form a single-step schedule. The script assembler finally writes these single-step schedules into the action script matrix, attaching a source clause number and a precondition mark to each line for execution in step three. After this processing, the output of step two is no longer natural language text, but rather an execution script that is individually coupled to the symbiotic mode sandbox.

[0046] When unifying objects, the candidate object set is first filtered by plant name and voltage level, then filtered again by equipment category and interval affiliation, and finally a unique endpoint is determined based on the equipment alias table, ledger name, and diagram name. If the number of candidate objects is not 1, an ambiguous object error is returned and not written to the action script matrix. During the parsing of compound actions, target state actions such as transitioning from operation to maintenance or from maintenance to standby are expanded into several single-step schedules according to the preset state transition table. Each row of the action script matrix includes at least the step number, object identification code, action type, target state, preceding state, following state, source clause number, and rollback flag.

[0047] In one preferred embodiment, the publishing server first calls the trie tree to complete alias normalization and then calls the finite state transition table to complete action unfolding. For compound expressions such as changing from running to maintenance, the finite state transition table pre-sets the operation unfolding sequence corresponding to the target state of the integrated device; for single-action expressions such as opening, closing, and withdrawing from the backup power supply self-switching, they are directly mapped into single-line scripts. If the corresponding device name does not exist in the object index directory, the browser side immediately returns that the device object has no landing point; if the device exists but the action term is not in the action word library, it returns that the action term is not included; if both the object and the action exist but the state baseline table does not meet the starting conditions, it returns that the current section state does not support this operation. In an extended solution parallel to this, the trie tree can be replaced by a prefix automaton with the same function, and the action unroller can be replaced by a sequence expander based on a rule graph. As long as it still runs along the single-chain logic of determining the object based on the object index directory, verifying the starting point with the state baseline table, and providing the action script matrix for execution, it maintains the same principle as this invention.

[0048] The word segmentation word library consists of a power plant name library, a device alias library, a bay name library, an action term library, and a state term library, which are respectively sourced from the EMSCIME model, the PMS device account, the protection and control device list, and the dispatching regulation term list; when performing word segmentation, the rules of prioritizing the longest device phrase, absorbing the action phrase later, and falling back the remaining fragments to the general word library are adopted. The stop word list consists of conjunctions that do not carry control semantics, and at least includes "will", "and", "its", "to", "again", "after", "then".

[0049] By first performing a power semantic funnel and then object normalization, step two compresses the spoken abbreviations, conjunctions, and compound expressions in the dispatching order text into a stable candidate word element chain, reducing device boundary drift. By introducing the object index directory and the state baseline table into object normalization and starting condition verification at the same time, the action script matrix output by step two has completed triple convergence of object positioning, action unfolding, and order execution before entering step three. By attaching a source clause number and a precondition constraint mark to each single-step dispatching, step three can directly point back to the specific statement in the original dispatching order text when a risk interception occurs, and step four can also perform fixed-point rewriting of the original script based on this when rewriting the transfer supply strategy.

[0050] Object normalization mapping Perform substation filtering, voltage level filtering, device category filtering, bay attribution filtering, and alias matching in sequence; if the number of final candidate objects is 1, output the corresponding object identification code; if it is 0, output that the object has no landing point; if it is greater than 1, output object ambiguity and terminate the clause from entering the model.

[0051] Step 3: After placing the action script matrix output from Step 2 into the symbiotic mode sandbox, instead of waiting for the entire command to be executed before checking the start and end states, a micro-state section that can be suspended and reviewed is immediately formed after each single-step scheduling is completed. Topology verification, electromechanical transient verification, and dynamic power flow verification are carried out synchronously around this micro-state section. This allows for the early interception of the three types of risks most likely to be hidden in the transient state: asynchronous loop closure, protection false triggering, and path overload. As a result, when Step 4 takes over, what is obtained is not a general alarm, but a blocking result with step number, risk category, and section snapshot.

[0052] Step three is defined as a micro-state step-by-step dynamic simulation and multi-dimensional interception based on single-step scheduling. It clarifies the risk identification of the entire scheduling operation process as executing each dispatch order line by line, and performs dynamic power flow calculation and risk warning analysis during the pre-simulation process. This indicates that the focus of this step is not to perform another ordinary power flow calculation, but to tightly integrate single-step scheduling execution with intermediate state risk verification. Complex power transfer often fails not because of the final power supply path, but because of temporary short-term paralleling, protection setting touchdowns, or instantaneous load compression at a certain step in the middle. Therefore, only looking at the first and last steady states will miss the truly dangerous moments. Step three therefore follows the action script matrix of Step two. The publishing server sends the script line by line into the symbiotic mode sandbox, and the symbiotic mode sandbox immediately freezes the equipment switch positions, the overall equipment target state, power flow distribution, and protection activation status after each line is executed, forming a micro-state section. All subsequent judgments are performed around this micro-state section, without reinterpreting the original natural language dispatch order.

[0053] In the preferred implementation, the following actions are all completed collaboratively by the publishing server and the symbiotic mode sandbox. The publishing server issues single-step schedules line by line according to the execution order field in the action script matrix. Each time the symbiotic mode sandbox executes a line, it writes the updated topology adjacency relationship, electrical quantities at both ends of the break, protection device activation position, standby automatic transfer available position, and main transformer and line load values ​​into the micro-state register area, and immediately sets the script queue to a suspended flag. After suspension, the topology path is recalculated first, then the break impact judgment is performed, then the protection contact edge judgment is performed, and finally the path load judgment is performed; only when none of the items trigger blocking is the script queue released from suspension and enter the next single-step schedule. If any item triggers blocking, the system retains the current micro-state register area, source clause number, and physical step number for direct use in step four. After this processing, the output of step three is not a single safe / unsafe conclusion, but a blocking record with location, type, and section.

[0054] ActionScript Matrix Each line must include at least: step number, object identifier, action type, target state, preceding state, following state, source clause number, rollback flag, and execution priority.

[0055] The current topology adjacency table, switch status table, integrated equipment status table, voltage / phase angle / frequency table at both ends of the break point, protection activation / deactivation table, backup automatic transfer available table, line and main transformer load table, and risk marker table are all updated. After each single-step scheduling operation is completed, the micro-state register is refreshed first. Then perform topology verification, transient verification, and dynamic power flow verification; if any solver fails to converge, it is directly blocked according to the protection principle, and the solution is marked as unconverged. Microstate register area It should include at least the following: current topology adjacency table, switch status table, integrated equipment status table, protection activation / deactivation table, backup automatic transfer available table, voltage / phase angle / frequency table at both ends of the break point, line and main transformer load table, risk label table, and source clause number table.

[0056] In the symbiotic mode sandbox, when performing circuit breaker closing, circuit breaker opening, disconnector switching, or integrated equipment target state migration, the status bit of the corresponding object identification code is first updated according to the status baseline table, and then the topology traverser is called to recalculate whether the two ends of the switch are reconnected by different power paths.

[0057] If the topology traverser determines that the action connects the two originally separate network segments into a closed loop, the risk verification engine continues to read the voltage amplitude at the left end of the break point. Voltage amplitude at the right end of the fracture phase angle at the left end of the fracture phase angle at the right end of the fracture Frequency at the left end of the fracture and the frequency at the right end of the break Constructing the fracture impact index: Where: fracture impact index : Indicates the degree of overall inconsistency between the two ends of the switch break in the current micro-state, with a value range of . The larger the value, the less suitable it is to continue this step; Voltage weighting coefficient Phase angle weighting coefficient Frequency weighting coefficient : These represent the proportions of voltage difference, phase angle difference, and frequency difference in the comprehensive judgment, respectively, with a value range of 1. ; Voltage amplitude at the left end of the fracture Voltage amplitude at the right end of the break : Represents the per-unit voltage across the switch to be operated, with a value range of . Phase angle at the left end of the fracture Angle with the right end of the fracture : Represents the phase angle of the voltages on both sides, with a value range of . Frequency at the left end of the fracture Frequency at the right end of the break : Represents the frequency scalars on both sides, with a value range of . ; When the fracture impact index When the script falls within the blocking interval defined in the rule table, the script queue remains suspended. Simultaneously, the row containing the single-step scheduling is highlighted on the browser side, and an unexpected loop-closing warning is given. For example, in a script that first closes the tie switch and then opens the original power supply circuit breaker, immediately after the tie switch is set to the closed position, the list on the left side of the main diagram does not automatically jump to the next step. Instead, it first highlights the row corresponding to the tie switch in red, allowing the operator to directly see that the two busbars have been temporarily connected. Therefore, the system refuses to continue executing subsequent opening actions. This fixes the loop-closing risk to a specific visible physical step, rather than tracing it back after the entire dispatch order has been completed.

[0058] After the passage is granted, the coexistence mode sandbox sends the same micro-state section to the electromechanical transient solver and the dynamic power flow solver. The electromechanical transient solver generates the transient voltage, current and power angle swing trajectory after the single-step action based on the current switch position, protection activation position and backup automatic transfer available position. Then, it compares the trajectory peak value with the protection setting table item by item. Once the triggering condition of any protection device or backup automatic transfer logic is met, the system records the single-step scheduling as a protection maloperation risk and does not proceed to the next step.

[0059] Subsequently, the dynamic power flow solver calculates the transferred path load on the micro-state section after protection verification, and introduces the load transition before and after a single step to construct the path limit exceedance coefficient. : Where: Path violation coefficient : indicates the first The overall limit violation degree of the target path in the current microstate, with a value of A value greater than 1 indicates that the path has entered the blocking zone; the path load after the action. : Indicates the first step after single-step scheduling execution The load value of the line or main transformer is taken as [value]. Pre-action path load : Indicates the first step before single-step scheduling execution The load value of the line or main transformer is taken as [value]. Transition weight coefficient : Indicates the amplification degree of a single-step load mutation, with a value range of . Path allowable limit : indicates the first The maximum allowable load for a line or main transformer under the current operating mode, with a value range of [value range missing]. ; In engineering implementation, implicit trapezoidal integration or predictive-correction integration is preferred for electromechanical transient solvers, while Newton-Raphson method or fast decoupling method is preferred for dynamic power flow solvers. If integrators and power flow solvers with equivalent functions are used, as long as the protection contact results and path over-limit coefficients are input and output according to the same micro-state section, the principle of this step remains unchanged. Taking the script of load carried by tie line after the main transformer is out of operation as an example, after the main transformer circuit breaker is switched, the system first displays in the protection panel area that a certain standby automatic transfer logic is close to the trigger boundary, and then marks the path over-limit coefficient line corresponding to the receiving end line in red in the load list area. The script therefore stops at this step and does not continue to execute the next transfer command. Protection false triggering and heavy overload are observed simultaneously in the same micro-state to avoid the conclusions caused by looking at power flow or protection alone.

[0060] By using the fracture impact index Used for synthesis loop verification, including path limit violation coefficients. Used for heavy overload verification, and with the protection contact edge discrimination sandwiched between the two, step three forms a cross-interception chain around the same microstate section. By outputting the physical step number, source clause number, and microstate register snapshot together during blocking, step four can directly wake up the entire network load rebalancing calculation and rewrite the action script matrix based on this, thus forming a single-chain connection between the preceding and following steps.

[0061] Step 4: After Step 3 has located the risk to a physical step number, a snapshot of a microstate register area, and a set of path limit violation coefficient tables, this step completes the blocking, routing, allocation, rewriting, and re-verification preparations along the same symbiotic instance identifier, so that the intercepted transfer scheme is transformed into another set of new action script matrices that can continue to enter Step 3.

[0062] Step 3 can only answer which step cannot continue, but it cannot directly provide a chain of solutions such as which power supply to replace, which operation to modify first, and whether the process can continue after modification.

[0063] Among them, after any micro-state identifies overload or hidden risks, the system enters a safety block, full network load rebalancing calculation and original dispatch control script correction; the two forms of the accident handling plan are: selecting the transfer scheme according to existing rules and performing full network rebalancing when there is a heavy overload, or switching to manual processing mode when existing rules are insufficient.

[0064] Therefore, the physical step number, microstate register snapshot, path violation coefficient table and source clause number output from step three are used to complete the correction within the same coexistence mode sandbox, instead of restarting another round of disconnected analysis.

[0065] In the preferred implementation, the following actions are collaboratively performed by the publishing server, the symbiotic mode sandbox, and the rebalancing solver. The publishing server freezes the current position of the script queue based on the physical step number and marks any unexecuted single-step schedules as segments to be rewritten. The symbiotic mode sandbox locks the current microstate register snapshot and extracts the receiving-end load object, original power supply path object, tie switch object, main transformer object, and adjacent backup power supply path object from the object index directory, forming the search boundary for the rebalancing solver. The rebalancing solver first excludes paths that have triggered blocking or cannot be implemented at the current cross-section, and then performs routing and allocation on the remaining tie relationships. Finally, the publishing server writes the obtained power supply switching sequence back to the action script matrix and deletes or reorders single-step schedules that conflict with the new scheme. The output is not an analysis suggestion, but a revised action script matrix that can be resubmitted to step three.

[0066] When step three returns the limit violation coefficient for a certain path When the limit is exceeded, the publishing server first traces the current power supply source and adjacent connection boundary of the receiving load object in the object index directory based on the line or main transformer object where the coefficient is located, and then puts the backup power supply paths that can participate in the transfer into the rebalancing solver one by one.

[0067] In this process, any path identified in step three as having protective edges, asynchronous loop closure, or missing object identification codes in the microstate register snapshot is directly eliminated, retaining only candidate power supply paths that are topologically reachable, have closable protection, and have a landing point on the cross-section. Subsequently, the rebalancing solver calculates the rebalancing path selection cost for each candidate power supply path: Where: Rebalancing route selection cost : indicates the first The comprehensive acceptance cost of each candidate power supply path ranges from [value range missing]. The smaller the value, the more suitable it is to be selected as an alternative supply chain path; path set : indicates the first The candidate power supply path includes a set of lines and main transformers, with values ​​being a finite discrete set; the path limit exceedance coefficient. Following the definition in step three, it represents the first... The degree of exceeding the limit for a line or main transformer, with a value range of [value range missing]. Post-action path load Following the definition in step three, represents the first microstate in the current microstate. The load value of each line or main transformer is within the range of [value range missing]. ; Path allowable limit Following the definition in step three, it represents the first... The maximum allowable load for a line or main transformer, with a value range of [value range missing]. ; route switching depth : indicates the use of the first The normalized length of newly added opening and closing actions and integrated equipment state transition actions when adding candidate power supply paths, with a value range of [value range missing]. Power supply compatibility factor : indicates the first The degree of inconsistency between the candidate power supply path and the receiving-end load in terms of voltage level, protection coordination, and operation sequence, with a value range of [value range missing]. Weighting coefficient 、 、 、 : These represent the proportions of over-limit risk, path load rate, switching depth, and power supply compatibility in the comprehensive judgment, respectively, with a value range of 1. And the sum of the four is 1; As a supplement: the weighted scoring formula is a hierarchical sorting rule, specifically: the first layer eliminates candidate paths that do not meet the requirements of topology reachability, protection coordination, positive remaining capacity, and legal operation order; the second layer prioritizes the path with the largest remaining bottleneck capacity among the remaining candidates; the third layer selects the path with the fewest new single-step scheduling requirements if there are still ties; the fourth layer selects the path with the fewest conflicts with the original script if there are still ties.

[0068] Candidate transfer paths are only included in the candidate set if they simultaneously meet four conditions: topology reachability, protection compatibility, positive bottleneck remaining capacity, and valid operation sequence. Script rewriting follows the order of first removing the hazardous action, then inserting the alternative communication action, and finally restoring the receiving end state; preceding actions that do not conflict with the new path and have passed verification remain unchanged.

[0069] For example, after a tie switch is closed, step three marks the path limit exceeding coefficient corresponding to the receiving-end line in red and stops on that line. The system then traces outwards two reachable tie paths around that receiving-end line. One path is deleted because the automatic transfer switch is in the off position, while the other path, although it adds an extra bus tie detachment action, has complete protection activation conditions and is therefore retained for the solution. The operator's interface first sees the original action line frozen, then sees a set of alternative power supply path records, instead of the entire ticket being directly invalidated. After clarifying which paths are feasible, the system proceeds to load allocation.

[0070] After the candidate power supply paths are determined, the rebalancing solver does not apply all receiving-end loads to a single path. Instead, it proportionally distributes the receiving-end loads based on the carrying capacity of each candidate power supply path and the cost of rebalancing path selection, while simultaneously adjusting the symbiotic mode balancing injection amount. The virtual generator here is a summary representation of the net injected power of each power supply zone within the symbiotic mode sandbox, used to redistribute the injection and receiving power balance without altering the physical model structure.

[0071] Preferably, the dynamic power flow solver first calculates the capacity margin of each candidate power supply path. Then, the load sharing ratio is generated according to the following formula: Where: Load sharing ratio : indicates that it is assigned to the first The percentage of receiving-end load for each candidate power supply path is taken as a value. The sum of the load sharing ratios of all candidate power supply paths is 1; available capacity margin. : indicates the first The remaining load space that can be accommodated by each candidate power supply path is the bottleneck capacity of the candidate path, and its value is [value missing]. Rebalancing Path Costs : Following the previous definition, it means that the first The comprehensive acceptance cost of each candidate power supply path ranges from [value range missing]. Total number of candidate paths : Indicates the number of candidate power supply paths participating in the cost-sharing calculation, and the value is a positive integer; After the risk sharing ratio is determined, the publishing server rewrites the action script matrix in the following order: first, remove the source of risk; then, connect the alternative path; and finally, restore the receiving end state. Single-step scheduling that directly conflicts with the original blocking steps is deleted. Switch opening and closing actions and integrated equipment target state migration actions corresponding to the new power supply path are inserted into the segment to be rewritten. The source clause numbering maintains the inheritance relationship, and new actions are supplemented with new clause mapping tags. If the rewritten action script matrix is ​​sent to step three again and there are still path limit exceeding coefficients, step four freezes and rewrites again following the same process. If all candidate power supply paths do not meet the constraints, the system retains the blocking state and switches to manual processing mode, converting the currently failed rewriting scripts into a draft manual handling plan.

[0072] Taking a generalized implementation as an example, when a station's original plan to have a single tie line handle all the load is blocked in step three, the system splits the receiving-end load into two candidate power supply paths and adds the following sequence to the script: first disconnect the original power supply circuit breaker, then close the first tie switch, and finally close the second tie switch. When the duty officer re-initiates the verification, the interface displays a newly rewritten ticket. The rebalancing result is directly converted into an executable script, thus ensuring that the output of step four can be seamlessly fed back to step three.

[0073] In practice, by first freezing the intercepted steps and then pruning candidate power supply paths around the microstate register snapshot, step four confines the rebalancing solution within a precise local risk boundary. This is achieved by introducing a rebalancing path selection cost. and load sharing ratio Step four unifies path mobility and load separability onto the same solution chain.

[0074] Step 5: Using the symbiotic instance identifier as the boundary, converge the final action script matrix, the final microstate register snapshot, and the source clause number into the same unified release object, and then assign this unified release object to the dispatch instruction ticket and the power grid accident handling plan, respectively.

[0075] The first four steps have completed semantic modeling, micro-state verification, and rebalancing rewriting. However, when the scheduling site actually executes the rewriting, the final recipient is not the script inside the sandbox, but the scheduling instruction ticket and contingency plan document in the production management system. If the output of step four is simply copied to the business interface, three types of breaks are likely to occur: the rewritten step sequence is not synchronized to the ticket field, the final power supply relationship is not expanded into the contingency plan text, and the same operation corresponds to different source clause numbers in the ticket and the contingency plan.

[0076] The existing system foundation includes browser plugins for automatically filling in the PMS drafting interface, generating contingency plans, and linking intelligent invoicing. Secure closed-loop confirmation and automatic circulation of digital business invoices are the final steps. Therefore, the key now is not to re-evaluate trends, but to encapsulate the final, approved state into a formally circulated business object.

[0077] In the preferred implementation, the following actions are collaboratively performed by the publishing server, the symbiotic mode sandbox, the closed-loop confirmation service, and the ticket circulation adapter. The publishing server first reads the final action script matrix, the final micro-state register snapshot, the path limit violation coefficient table, the break impact index record, the protection action record, and the source clause number from the last release result; the closed-loop confirmation service seals these objects before publishing, no longer allowing the current symbiotic instance identifier to insert new script rewrites; the ticket circulation adapter then splits the sealed unified publishing object into two output chains, one forming a scheduling instruction ticket field stream for the PMS ticket drafting interface, and the other forming a contingency plan field stream for the accident handling document template.

[0078] Unified publishing target The process includes at least the following fields: header field, step sequence field, object field, status field, operation unit field, risk description field, and contingency plan text fragment field. Transactional backfilling rules: The invoice transfer adapter writes in the order of header field, step field, verification description field, and submission field; if any field backfilling fails, a full invoice rollback is triggered, and no partially completed state is retained in the business system. Both output chains use the same physical step number sequence as the main thread and share the same object identifier and the same target status description, thus ensuring that the written-back invoices and contingency plans can be cross-referenced. If any field is missing, conflicting, or reversed during mapping, the system stops backfilling and adds the error position back to the current symbiotic instance identifier, waiting for manual correction before triggering step five again.

[0079] The closed-loop confirmation service, under the current symbiotic instance identifier, checks the final action script matrix and the final microstate register snapshot item by item to confirm that each single-step schedule has found the corresponding object and state in the final state; then it checks the path limit violation coefficients left over from step three. fracture impact index And the protection action records are summarized into a closed-loop release coefficient. : Where: Closed-loop release coefficient : Indicates the final release status of the unified release object before it enters the business process, with a value range of . The closer the value is to 1, the more suitable it is to enter the backfilling stage; path set : Represents the set of all lines and main transformer objects involved in the final action script matrix, with values ​​being a finite discrete set; Fragment set : Represents the set of all circuit breaker objects in the final action script matrix that have undergone opening / closing or state transition, and its value is a finite discrete set; path limit violation coefficient. Following the definition in step three, it represents the first... The degree of exceeding the limit for a line or main transformer, with a value range of [value range missing]. ; fracture impact index Following the definition in step three, it represents the first... The degree of overall inconsistency of each break point object, with a value range of [value range missing]. Protecting legacy landmarks : Indicates whether there are still unresolved protection trigger conditions in the final state, with a value range of . Field conflict flag : Indicates whether there are still missing items, reversed order, or broken source clause numbers within the unified release object; the value range is [range missing]. ; Weighting coefficient Weighting coefficients Weighting coefficients Weighting coefficients : These represent the percentages of path violation, breach impact, legacy protection, and field conflict in the final determination, with values ​​ranging from [value range missing]. ; When the closed-loop release coefficient Enter the pre-set clearance zone and protect the remaining signs. Field conflict flags When both are zero, the unified publishing object is written to the pending backfill area; otherwise, the current symbiotic instance identifier remains frozen, and the browser interface displays the specific conflict location.

[0080] Taking a certain station's power transfer scheme as an example, after the script rewritten in step four passes the second verification, the previously highlighted contact switch steps return to normal display. However, the system does not immediately write the invoice to the PMS. Instead, it first checks whether the newly added branch power supply actions have all formed the corresponding states in the final microstate register snapshot. Only when the state chain and the source clause number are closed simultaneously is the submit invoice button lit up. This separates the simulation pass and the formal invoice into two gates to prevent the business flow from being released prematurely.

[0081] As another implementation method: the ticket backfilling stage is allowed only if all objects corresponding to the final action script matrix can be found in the snapshot of the final microstate register area, and there are no unresolved protection trigger conditions, path over-limit conditions, break-point impact conditions, and field mapping conflict conditions.

[0082] After the closed-loop confirmation is completed, the ticket circulation adapter splits the unified release object into two types of business payloads. The first type is the scheduling instruction ticket payload, which must at least include the physical step number, the name of the operation object, the object identification code, the target status, the execution order, the operation unit, the preconditions, and the lockout prompt; the second type is the accident handling plan payload, which must at least include the risk topic, the fault background, the affected scope, the backup supply path description, the step sequence, and the recovery suggestions.

[0083] Neither type of business payload reassembles free text; instead, it uses the final action script matrix as its skeleton, the source clause number as its source index, and the final microstate register snapshot as its state endpoint. If a browser plugin path is used, the browser plugin sends the scheduling instruction ticket payload field by field to the PMS ticket drafting interface via the WebAPI, with the preferred writing order being: ticket header field - step field - verification description field - submission confirmation field. If a reserved interface path is used, the publishing server serializes the two types of business payloads into structured messages and sends them to the business system via the gRPC gateway or an equivalent functional interface service.

[0084] When any field fails to be filled in, the adapter first records the position of the failed field, then processes it in the order of rolling back the original field, stopping the current step, and retaining the unified release object, without pushing half of the ticket to the business side. In one specific implementation, after the dispatcher clicks to generate the contingency plan and fills it in, the power grid graphic on the left remains unchanged, and the PMS ticket drafting interface on the right automatically displays the operation steps in the ordered order. The accident handling contingency plan window simultaneously displays the fault background, transfer path, and operation instructions; the dispatcher only needs to verify the operation unit and issuance information to proceed to the subsequent process. Verified internal objects are converted into two types of formal documents in one go, reducing secondary transcription.

[0085] Through closed-loop release coefficient The risk assessment results of steps three and four are compressed into a final confirmation threshold before release. Step five avoids prematurely writing the document when the verification is completed but the fields are not yet closed. This ensures that both types of official documents come from the same unified release object. Through the parallel design of browser plugin paths and reserved interface paths, it not only aligns with the existing PMS document drafting interface's automatic filling method but also reserves equivalent expansion space for future integration with other business systems.

[0086] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

[0088] 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 units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units 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 through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0090] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A power grid transfer verification method based on digital twinning, characterized in that: include, A twin power grid with associated mode is established based on the real-time status of the power grid. When conducting power transfer rehearsals or operation ticket verification, data sections are captured from the associated mode and separated to start the asynchronous coexistence mode. Import unstructured scheduling operation text, and generate a structured underlying operation script matrix through Chinese word segmentation, stop word removal, normalized object normalization, and action vector extraction; In asynchronous symbiotic mode, single-step scheduling operations are executed line by line according to the structured underlying operation script matrix, and topology analysis, electromechanical transient and dynamic power flow cross-verification are performed after each micro-state switching action. When an overload or hidden risk is identified, a safety shutdown, a full-network load rebalancing, and a rewriting and re-verification of the original dispatch control script are performed. After verification, the instruction sequence that has passed the safety check is backfilled into the production management system and a dispatch instruction ticket and a power grid accident handling plan are generated.

2. The power grid transfer verification method based on digital twins according to claim 1, characterized in that: When establishing a twin power grid in symbiotic mode, the CIME model and real-time cross sections of EMS, the equipment ledger of PMS, and the real-time data of the information protection system are collected. Based on the data, a physical model of the primary system and a mechanism model of the secondary system are established, and the symbiotic mode is made to run synchronously with the real-time state of the power grid. The asynchronous symbiotic mode is started in the container cluster.

3. The power grid transfer verification method based on digital twins according to claim 2, characterized in that: When capturing and extracting data sections from the coexisting mode, the current switch status, disconnector status, bus energization relationship, main transformer operation status, line power flow information, and secondary protection activation / deactivation status are synchronously solidified, and the synchronous solidification results are used as the initial sections for power transfer pre-rehearsal and operation ticket verification in the asynchronous coexisting mode.

4. The power grid transfer verification method based on digital twin according to claim 1, characterized in that: The parsing of unstructured scheduling operation text is performed in the following order: Chinese word segmentation, stop word removal, normalized object normalization, and action vector extraction. Chinese word segmentation is based on power entities and action terms in the power proprietary knowledge graph. Stop word removal is used to remove redundant function words that do not represent control meaning and retain operation sequence information.

5. The power grid transfer verification method based on digital twins according to claim 4, characterized in that: Normalization of objects includes unifying the mapping of heterogeneous colloquial descriptions of the same device and binding the device name filled in by the operator to the standard CIME node identification code in the twin physical model; Action vector extraction includes parsing the specific action intent and combining the specific action intents into a structured underlying operation script matrix according to the execution order.

6. The power grid transfer verification method based on digital twins according to claim 5, characterized in that: In the asynchronous symbiotic mode, single-step scheduling operations are executed one by one according to the structured underlying operation script matrix. After each micro-state switching action is completed, the current pre-run process is immediately suspended. The topology relationship, electromechanical transient process and dynamic power flow state corresponding to the micro-state are cross-validated before deciding whether to continue executing the next single-step scheduling operation.

7. The power grid transfer verification method based on digital twins according to claim 6, characterized in that: Cross-verification includes: performing risk interception of the combined loop for the states at both ends of the switch break, performing protection maloperation interception for transient electrical fluctuations caused by micro-state operations, performing heavy overload interception for the target path after single-step load transfer, and establishing a correlation between each interception result and the micro-state switching action that triggered the interception result and its corresponding physical operation steps.

8. The power grid transfer verification method based on digital twin according to claim 7, characterized in that: When cross-validation identifies overload or hidden risks, it first performs a security block on the current pre-process and highlights the specific physical operation steps that are blocked and reported as errors. Then, it triggers a full-network load rebalancing by eliminating the single-step over-limit as a constraint, and keeps the remaining unexecuted steps in the asynchronous coexistence mode in a state of waiting to be rewritten.

9. The power grid transfer verification method based on digital twins according to claim 8, characterized in that: The whole network load rebalancing includes re-searching for interconnection relationships across the entire network, calculating alternative power sources, adjusting the output of virtual generators, and determining the load transfer ratio allocation; the original dispatch control script rewriting includes replacing the corresponding steps in the original script based on the alternative power sources and the load transfer ratio allocation, and then re-entering cross-validation.

10. The power grid transfer verification method based on digital twin according to claim 9, characterized in that: When the cross-validation is successful, the instruction sequence that has passed the security check will be backfilled into the production management system via the browser plugin WebAPI or reserved interface. Standardized dispatch instruction tickets will be generated according to the execution order of the structured underlying operation script matrix, and power grid accident handling plans corresponding to the dispatch instruction tickets will be generated simultaneously.

Images