A method for operating a power dispatching system based on a master-slave mode

Abstract

The present invention discloses a method for operating a power dispatching system based on a master-slave mode, aiming to solve the technical problem in the prior art that the collaborative guarantee capability of the backup power dispatching system cannot meet the needs of emergency response and rapid transfer. The method includes: monitoring and flexibly switching the working mode processes of two power dispatching subsystems; using controllable application nodes to operate and control the power grid system and collect data returned by the power grid system; synchronizing the model data in the system through master-slave consistency submission and master-slave asynchronous replication operations; synchronizing the real-time data of each business in the system through real-time library synchronization technology; and synchronizing the manual operation data in the system through message agent forwarding technology. The present invention can quickly and accurately manage the data of the power dispatching system in the master-slave mode, improve the collaborative guarantee capability of the backup power dispatching system, and improve the ease of maintenance of the system.

Description

Technical Field

[0001] The invention relates to an operating method of an electric power dispatching system based on a master-slave mode, and belongs to the technical field of electrical automation. Background Art

[0002] The power grid is a critical piece of national infrastructure, directly supporting the national economy and people's livelihoods. The safe and stable operation of the grid is a crucial guarantee for economic development and social stability. Power dispatching organizations, the control and command centers for power system operations, shoulder the crucial tasks of organizing grid operations and directing incident handling and recovery. These organizations are crucial for ensuring the safe and stable operation of the grid.

[0003] In order to adapt to the needs of the rapid development of the power grid, prevent the loss of functions of the existing dispatching center due to major accidents, natural disasters and other emergencies, ensure the uninterrupted operation of power dispatching and command, improve the emergency response capabilities and reliability of power grid dispatching, and ensure the safe and stable operation of the power grid, it is urgent to explore new operating methods of the dispatching system.

[0004] In order to improve the performance of the power dispatching system, a master-slave mode dispatching system was introduced. The main and backup dispatching systems of traditional power master stations adopt a "separate-site self-contained" operation mode, that is, the server, switch, database and other hardware equipment of the backup dispatching system are located at different locations from the main dispatching system equipment. In this operation mode, the basic platform of the backup dispatching system and the commercial database, real-time database, graphic model and listing information under the SCADA (Supervisory Control and Data Acquisition) and FES (Front-End System) are synchronized with the main dispatching system, but the plant station telecontrol data, alarm information and four remote debugging are all collected independently by the backup dispatching system; the PAS, AVC and other modules of the backup dispatching system also adopt an independent operation mode and need to be maintained separately; and there is no planned value channel from the backup dispatching system to the power plant, and it does not have the function of issuing planned values, and there is no interactive channel with the provincial and network-level dispatching systems.

[0005] At present, there are mainly the following problems in the construction of the backup dispatching system: 1) There are deficiencies in the technical support system architecture of the backup dispatching system; 2) The technical support system of the backup dispatching system is not fully functional; 3) The normalized application and operation and maintenance mechanism of the backup dispatching system need to be improved; 4) The collaborative guarantee capability cannot meet the needs of rapid transfer. Summary of the Invention

[0006] In order to solve the problem that the collaborative guarantee capability of the existing backup power dispatching system cannot meet the needs of emergency response and rapid transfer, the present invention proposes a power dispatching system operation method based on the master-slave mode. Through master-slave mode management and multiple data synchronization technologies in dual mode, the data consistency, real-time performance and reliability of the master-slave mode power dispatching system are guaranteed, the collaborative guarantee capability of the backup power dispatching system is improved, and the maintainability of the system is improved.

[0007] In order to solve the above technical problems, the present invention adopts the following technical means:

[0008] The present invention proposes a method for operating a power dispatching system based on a master-slave mode, wherein the power dispatching system includes two independent power dispatching subsystems with consistent functional structures. The method comprises the following steps:

[0009] Obtaining the working modes of two power dispatching subsystems and performing working mode monitoring, wherein the working modes include a master mode and a slave mode;

[0010] Manage the control authority of application nodes in the power dispatching subsystem according to the master-slave mode;

[0011] Use controllable application nodes to operate and control the power grid system and collect data returned by the power grid system;

[0012] Synchronize the model data in the two power dispatch subsystems through master-slave consistency submission and master-slave asynchronous replication operations;

[0013] Synchronize the real-time data of each business in the two power dispatching subsystems through real-time database synchronization technology;

[0014] Synchronize manual operation data in two power dispatching subsystems through message agent forwarding technology;

[0015] Synchronize file data in two power dispatching subsystems through remote synchronization service;

[0016] The working modes of the two power dispatching subsystems are switched according to the mode switching instruction.

[0017] Furthermore, the method for monitoring the working mode is:

[0018] Obtaining the operating mode information of each power dispatching subsystem through a master-slave mode manager deployed on the power dispatching subsystem, wherein the operating mode information includes a system number, a system operating mode, and a refresh time;

[0019] Each power dispatch subsystem reads the configuration information through its master-slave mode manager and obtains the address of the proxy server of the opposite system;

[0020] Each power dispatching subsystem sends its own working mode information to the address of the proxy server of the opposite system, receives the working mode information of the opposite system, and summarizes the working mode information of the two power dispatching subsystems.

[0021] Furthermore, the method for managing the control authority of the application nodes in the power dispatching subsystem according to the master-slave mode is as follows:

[0022] Determine whether the subsystem to which the application node belongs is a power dispatching subsystem in the master mode; if so, determine that the subsystem is controllable; otherwise, determine that the subsystem is uncontrollable;

[0023] If the subsystem is controllable, determine whether the application node is a duty node. If it is a duty node, determine that the application node is controllable; otherwise, determine that the application node is uncontrollable.

[0024] Get the control status of all application nodes and perform global registration of node control status;

[0025] Determine whether the controllable application node is unique. If there is only one controllable application node, configure the control authority for issuing control instructions for the application node. Otherwise, change the control state of the application node to uncontrollable.

[0026] Furthermore, the operations for master-slave consistency submission are as follows:

[0027] Call model_modify in the main mode through the service bus to send the model operation request to the power dispatch subsystem in the main mode;

[0028] The power dispatch subsystem in the main mode performs permission judgment, maximum ID generation, model inverse operation statement generation, transaction submission, secondary device table trigger information acquisition operations according to the model operation request, and generates the main mode execution result;

[0029] If the master mode execution result is that the data is successfully stored in the database, the secondary device table trigger information obtained by the master mode is submitted in a transaction, and a model operation request is sent to the power dispatch subsystem in the slave mode;

[0030] If the result of the main mode execution is that the data entry fails, an error is returned to the client of the power dispatch subsystem in the main mode;

[0031] The power dispatching subsystem in slave mode performs permission judgment, maximum ID generation, and transaction submission operations according to the model operation request, and generates the slave mode execution result;

[0032] If the result of the slave mode execution is that the data is successfully put into storage, the model inverse operation statement generated by the master mode is cleared. If the result of the slave mode execution is that the data is failed to be put into storage, the model inverse operation statement generated by the master mode is executed to restore the equipment records in the power dispatching subsystem in the master mode to the state before the model operation request is executed.

[0033] Furthermore, the operation of master-slave asynchronous replication is as follows:

[0034] The power dispatching subsystem in master mode receives model operation requests and calls the data dispatching service to modify the model and save the model data;

[0035] Generate archive files based on model data saved in master mode and master-slave mode synchronization targets;

[0036] Call the data loading process according to the archive file, synchronize the model data saved in the master mode to the power dispatch subsystem in the slave mode, and return the slave mode data saving result;

[0037] Determine whether to delete the archive file based on the result of saving the slave mode data.

[0038] Furthermore, the real-time library synchronization technology includes scheduled synchronization, stage data synchronization and snapshot data synchronization. Among them, scheduled synchronization reads the data in the database of two power dispatching subsystems according to the preset synchronization interval, and synchronizes the read data to the power dispatching subsystem on the opposite side; stage data synchronization synchronizes the operating data in one power dispatching subsystem to another power dispatching subsystem through the interface trigger; snapshot data synchronization stores the real-time data in any power dispatching subsystem in the form of snapshots, and sends the data snapshots to the power dispatching subsystem on the opposite side.

[0039] Furthermore, scheduled synchronization supports relative data synchronization between two power dispatching subsystems at the same time, and does not support breakpoint resumption; stage data synchronization is one-way synchronization and supports breakpoint resumption.

[0040] Furthermore, the manual data synchronization method is:

[0041] Obtain manual operation information through the power dispatch subsystem and send manual operation messages to the local application server and message agent;

[0042] Use the local application server to perform application operations based on manual operation messages and save local manual operation data;

[0043] Forwarding manual operation messages to the message agent of the opposite power dispatch subsystem through the point-to-point service of the message agent;

[0044] The manual operation message is forwarded to the application server on the opposite side through the message agent of the power dispatching subsystem on the opposite side;

[0045] The opposite-side application server performs application operations according to the manual operation message and saves the opposite-side manual operation data.

[0046] Furthermore, the file data synchronization method is:

[0047] Obtain the file directory that needs to be synchronized through the file synchronization service of the power dispatch subsystem and send it to the remote synchronization service;

[0048] Use remote synchronization services to synchronize operation logs based on file directory changes;

[0049] According to the synchronization operation log, two power dispatching subsystems are connected through a remote agent to perform file synchronization operations.

[0050] Furthermore, the file modification method is: according to the client request, the file is modified in the power dispatching subsystem in the main mode, and the modified file is stored using the file management service.

[0051] The following advantages can be obtained by adopting the above technical means:

[0052] The present invention proposes a method for operating a power dispatching system based on a master-slave mode, improves the existing backup dispatching system construction, provides two power dispatching subsystems with the same structural framework, and makes up for the problems of insufficient architecture and incomplete functions of the existing backup dispatching system. The method of the present invention can monitor the working mode of the power dispatching subsystem in real time and provide flexible mode switching. When a failure occurs in the main mode system, seamless switching can be achieved to avoid the expansion of the accident and improve the reliability of power dispatching. During the operation of the system, the method of the present invention provides different data synchronization operations according to the synchronization requirements of different data in the system, which can provide both real-time data synchronization and delayed synchronization, ensuring the consistency of data in the master-slave mode system, and the data has real-time and reliability, improving the collaborative guarantee capability of the power dispatching subsystem in the slave mode, and can meet the needs of rapid transfer.

[0053] Some operations in the method of the present invention require maintenance and operation in master mode, and then synchronously shared in slave mode, which can effectively communicate the maintenance workload of the entire system and improve the maintainability and ease of maintenance of the system. The present invention combines the successful experience of domestic and foreign dispatching agencies and other industries in building emergency systems to build a safe, reliable, efficient and flexible power grid backup dispatch system, achieving reliable, efficient and flexible backup of dispatch sites, technical support systems and dispatch personnel, meeting all-round emergency needs, and ensuring the uninterrupted and reliable operation of power dispatch services. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 A framework diagram of a power dispatching system according to an embodiment of the present invention;

[0055] Figure 2 Schematic diagram of system working mode monitoring in an embodiment of the present invention;

[0056] Figure 3 Schematic diagram of system working mode switching in an embodiment of the present invention;

[0057] Figure 4 Schematic diagram of the principle of master-slave consistency submission in an embodiment of the present invention;

[0058] Figure 5 Schematic diagram of the same-city model in an embodiment of the present invention;

[0059] Figure 6 Schematic diagram of the remote mode in an embodiment of the present invention;

[0060] Figure 7 This is a flowchart of master-slave consistency submission in an embodiment of the present invention;

[0061] Figure 8 This is a flowchart of master-slave asynchronous replication in an embodiment of the present invention;

[0062] Figure 9 Schematic diagram of real-time data synchronization in an embodiment of the present invention;

[0063] Figure 10 This is an architectural diagram of manual data synchronization in an embodiment of the present invention;

[0064] Figure 11 This is a flow chart of manually operating message agent forwarding in an embodiment of the present invention;

[0065] Figure 12 Flowchart of data proxy forwarding in an embodiment of the present invention;

[0066] Figure 13 This is an architectural diagram of file synchronization in an embodiment of the present invention;

[0067] Figure 14 This is a flowchart of application node control authority determination in an embodiment of the present invention. DETAILED DESCRIPTION

[0068] The technical solution of the present invention will be further described below with reference to the accompanying drawings:

[0069] The present invention proposes a method for operating a power dispatching system based on a master-slave mode. The power dispatching system framework of the method is a dual-system framework, including two independent power dispatching subsystems that can perform hot standby and have the same functional structure, which can be called A and B systems. The power dispatching system framework of the present invention is as follows: Figure 1As shown, both systems A and B include conventional application functions of power dispatching systems such as front-end, SCADA, alarm, history, calculation, AGC, AVC, PAS, plan, section, and graphics. The working modes of systems A and B are divided into master mode and slave mode. When system A is in master mode, system B is in slave mode, and vice versa. In an embodiment of the present invention, only the power dispatching subsystem whose working mode is master mode can perform actual operational control of the power grid. In slave mode, the power grid is not controlled by default. Only after manual switching of part of the control rights can it be controlled in slave mode. The switching of control rights can be refined to the plant level, allowing different plants to perform control in different modes. The working mode can be switched automatically or manually according to actual needs.

[0070] The two power dispatching subsystems in the present invention can realize the following functions:

[0071] (1) In the main mode, the power dispatching subsystem deploys conventional applications to collect data, process data, store history, monitor and alarm, perform real-time calculations, perform online analysis, and perform operational control on the power grid operation status;

[0072] (2) In slave mode, the power dispatching subsystem deploys conventional applications to collect, process, store, monitor, calculate, and analyze grid operation status data. Online operations can be performed in slave mode, and the operation information is automatically synchronized to the master mode. The slave mode can select individual control rights or individual plant control rights as needed;

[0073] (3) Master and slave mode model maintenance. By default, model maintenance is performed in the master mode. After the maintenance is completed, you can choose to publish it to the slave mode immediately or with a delay.

[0074] (4) The master and slave modes communicate with the substations through independent acquisition channels to collect substation power grid operation data;

[0075] (5) Both master and slave modes provide remote graphics services (RGS) for monitoring workstations to remotely access the graphic monitoring interface in different modes as needed;

[0076] (6) The master and slave modes have independent historical databases for historical storage, including relational databases, time series databases, etc.

[0077] (7) The master-slave mode is managed and switched through an independent master-slave mode management module. When switching between the master and slave modes, the control right switching management is required, and the grid control operation is only allowed in the master mode;

[0078] (8) The operation information (manual setting, listing) in the master-slave mode is automatically synchronized to ensure the consistency of the operation information between the master and slave modes. When the model between the master and slave modes adopts delayed synchronization, only the master mode is allowed to operate during the delayed release period, and the master mode operation information is automatically synchronized in batches when the delayed synchronization expires. The slave mode can compare with the existing operation information and determine the incremental operation to be stored in the database.

[0079] The method of the present invention mainly includes a system working mode management method, a system data synchronization method and a system control authority management method. The system working mode management method is responsible for managing the working modes of two power dispatching subsystems to ensure that under normal operating conditions, only a unique subsystem operates in the main mode; the system data synchronization method synchronizes various data information in the two power dispatching subsystems, and the system control authority management method manages the control authority of application nodes in the two power dispatching subsystems to ensure that only the subsystem in the main mode can perform power grid dispatching operations.

[0080] The system working mode management method includes the following steps:

[0081] Step A: Monitor the working modes of the two power dispatching subsystems.

[0082] A master-slave mode manager is set up in the power dispatching subsystem to realize the working mode monitoring function through the real-time interaction of the working mode information between the two subsystems. Figure 2 As shown in the figure, the specific operations of working mode monitoring are:

[0083] Step A01: Obtain the working mode information of each power dispatching subsystem through the master-slave mode manager deployed on the power dispatching subsystem. The working mode information includes the system number (A or B), the system working mode (master mode or slave mode) and the refresh time, etc.

[0084] Step A02: Each power dispatching subsystem reads configuration information through the master-slave mode manager to obtain the address of the proxy server of the opposite system.

[0085] Step A03: Each power dispatching subsystem sends its own working mode information to the address of the proxy server of the opposite system, and receives the working mode information of the opposite system from the opposite system, and summarizes the working mode information of the two power dispatching subsystems.

[0086] The present invention monitors the system's operating mode while checking the refresh time of the operating mode information. If the operating mode information has not been refreshed within the specified timeframe, an alarm notification will be issued. Users can use this alarm information to check for anomalies such as inter-system network interruptions or peer system failures, allowing them to implement troubleshooting measures. If the inter-system network is interrupted, causing the present invention's two subsystems to "split brain" into two systems, the system operating mode monitoring will issue a system interruption alarm, allowing the user to determine the master-slave operating mode for each subsystem. If a subsystem is destroyed by a natural disaster or other circumstance, the system operating mode monitoring will issue a system interruption alarm, allowing the user to determine the master-slave operating mode for each subsystem based on the extent of the damage.

[0087] Step B: Switch the working modes of the two power dispatching subsystems according to the mode switching instruction.

[0088] In the normal mode switching process, the master-slave mode manager of the power dispatching subsystem in the master mode receives the mode switching instruction from the client or system server, and updates the working mode of the system according to the mode switching instruction, and sends the updated working mode of the system to the peer system. The master-slave mode manager of the peer system automatically switches its own working mode to the corresponding mode according to the received information, such as Figure 3 As shown, system A is in master mode. After receiving the mode switching instruction, system A first switches the working mode of system A from master mode to slave mode, then sends the updated slave mode of system A to system B, and finally switches the working mode of system B from slave mode to master mode.

[0089] In this embodiment of the present invention, the system's operating modes include not only master mode and slave mode, but also forced master mode and forced slave mode. Forced master mode indicates that the subsystem is manually switched to master mode, and the other subsystem automatically switches to slave mode. Similarly, forced slave mode indicates that the subsystem is manually switched to slave mode, and the other subsystem automatically switches to master mode.

[0090] During a forced mode switch, when a subsystem's master-slave mode manager receives a switch instruction to switch the subsystem to master mode, the subsystem's master-slave mode manager first switches the system's operating mode to forced master mode and then sends the subsystem's operating mode to the peer system. Upon discovering that the original system is operating in forced master mode, the peer system automatically switches its own operating mode to slave mode and sends the operating mode to the original system. Upon discovering that the other system is operating in slave mode, the original system switches its operating mode from forced master mode to master mode, completing the mode switch. Similarly, subsystems can use a similar method to switch to forced slave mode.

[0091] In this embodiment of the present invention, the power dispatching system can be a local system or a remote active-active system, depending on the deployment locations of the two subsystems. In a local active-active system, the two power dispatching subsystems are deployed in the same city, while in a remote active-active system, the two power dispatching subsystems are deployed in different cities. Because the two subsystems operate simultaneously, they serve as hot standby for each other. However, there are differences in system data synchronization between local active-active systems and remote active-active systems.

[0092] The system data synchronization method includes the following steps:

[0093] Step C: Synchronize the model data in the two power dispatching subsystems through master-slave consistency submission and master-slave asynchronous replication operations.

[0094] Model data synchronization is divided into master-slave consistency submission and master-slave asynchronous replication; master-slave consistency submission is carried out by the model service program to write data to the subsystem database of the master-slave mode respectively. If the submission is successful in both master and slave modes, the model operation is officially submitted successfully. Otherwise, the master-slave mode is restored to the state before the operation through model rollback, and the real-time consistency of the master-slave model data is guaranteed by strong consistency technology; the master-slave asynchronous replication mode uses commercial library components or commercial library service programs provided by the platform to asynchronously synchronize the model data in the master mode to the corresponding commercial library in the slave mode, ensuring the ultimate consistency of the system model data in the master-slave mode.

[0095] In the embodiment of the present invention, the working principle of master-slave consistency submission is as follows: Figure 4 As shown, specifically including:

[0096] Step C1-1, call the system's model service interface through the client to generate a request message for requesting model operation; wherein, the client is the power dispatching system client deployed on the workstation, and the client is used to provide the dispatching personnel with the main interface for operation. By operating the client front-end interface, the processing and operation of the model data on the server are completed, such as the operation of modifying the model.

[0097] Step C1-2: The client model operation request calls the model_modify of the main mode through the service bus. This process is mainly a network transmission process, which sends the client model operation request to the power dispatching subsystem in the main mode.

[0098] Step C1-3, the power dispatching subsystem in the main mode performs operations such as authority judgment, maximum ID generation, model inverse operation statement generation, transaction submission, and secondary equipment table trigger information acquisition (i.e., the statement generated by the secondary equipment table trigger information) according to the client model operation request, completes the core stage of the main mode model service processing, and generates the main mode execution result.

[0099] In steps C1-4, the power dispatch subsystem in master mode returns the master mode execution results to the regional system model_modify in the form of a message. Regional systems are independent of the master-slave model and are used to coordinate the operations of various participants. They are connected to the power dispatch subsystems in master and slave mode via a network. Steps C12 and C14 represent the request and return phases of a service bus call.

[0100] Step C1-5: The regional system parses the main mode return message content. If the main mode storage fails, an error is returned to the client. If the main mode storage succeeds, the secondary device table trigger information obtained by the main mode is submitted locally in a transaction.

[0101] Step C1-6, the regional system model_modify forwards the master mode return message content and model operation request to the slave mode model_modify. The power dispatching subsystem in the slave mode performs operations such as authority judgment, maximum ID generation, and transaction submission based on the client model operation request, completing the core stage of the slave mode model service processing and generating the slave mode execution result.

[0102] Step C1-7: The slave model model_modify sends the slave model execution result in the form of a message to the master model_modify via the service bus.

[0103] Step C1-8: The master mode parses the message returned by the slave mode. If the slave mode fails to store data, the master mode executes the pre-written model inverse operation statement to restore the master mode device record to the state before modification. If the slave mode stores data successfully, the master mode clears the pre-written model inverse operation statement.

[0104] Step C1-9: The main mode returns the result of processing the model inverse operation statement (executing or clearing the model inverse operation statement) to the regional system model_modify.

[0105] Step C1-10: The regional system analyzes the main mode's processing of the inverse operation statement and returns the result to the calling client.

[0106] The commit statement in the actual data submission phase of the main mode model service includes the following information: 1. The reverse operation rollback statement of the operated record ID; 2. The mark record in the model reverse operation information table that records that the ID was successfully submitted with success_flag=1; 3. The primary key ID that the current session is operating on, which is used to generate the rollback statement information of the triggered table in the trigger; 4. The actual operation commit_sql statement of the record ID.

[0107] The above four types of statements are submitted in a transaction begin...end, so as to ensure that when commit_sql is submitted successfully, the record marked with success_flag=1 in the public_model_undo table in the model center that is successfully stored, the operated record, and the rollback statement of the affected trigger table are all submitted successfully.

[0108] In a dual-active system in the same city, systems A and B can share a commercial database that contains databases of different roles, such as the primary database and the backup database. The specific structure is as follows: Figure 5 As shown, the present invention solves the single point of failure problem of the database by utilizing multiple roles within a commercial database cluster. The platform commercial database service module is responsible for the management of the master and standby databases. The master and slave systems submit query data to the master database based on data requirements, and the commercial database synchronization function completes the synchronization of the standby database data.

[0109] In a remote active-active system, each system A and B corresponds to a commercial database, and the commercial databases of the two systems are maintained separately. Figure 6 As shown, model operations can be synchronized using either master-slave consistency commit or master-slave asynchronous replication. System internal data, such as historical data, is stored independently on both sides. Master-slave consistency commit is used in scenarios with high data consistency requirements, such as model data maintenance; master-slave asynchronous replication is used in scenarios such as sampling and alarm data.

[0110] Master-slave consistency commit is based on the three-phase commit protocol of the data service. The three-phase commit relies on the coordinator role. The coordinator is a set of scheduling services deployed in two subsystems. The commercial libraries of the A and B systems serve as participant clusters. The coordinator performs unified scheduling and sends instructions to all participants. The participants will feedback the operation status to the coordinator, and the coordinator will decide the next instruction based on the feedback. The specific operation process of master-slave consistency commit is as follows: Figure 7 As shown:

[0111] (1) Inquiry stage: The dispatch service sends a submission inquiry request to all commercial library services to confirm whether the commercial library of each power dispatch subsystem can respond normally. If the commercial library can submit, it returns a positive response, otherwise it returns a negative response.

[0112] (2) Pre-submission stage: The scheduling service decides whether to perform the pre-submission operation based on the feedback from the inquiry stage. Specifically, it can be divided into the following two situations:

[0113] (201) If the scheduling service receives a positive response from both systems A and B: the transaction is pre-committed. Here, the transaction refers to the model modification request issued by the client to the commercial library. The scheduling service sends a pre-commit request to all commercial library services and enters the preparation phase. After receiving the pre-commit request, the commercial library service will execute the transaction operation and record the undo and redo information in the transaction log. If the commercial library service of a subsystem successfully executes the transaction operation, it returns a positive response and starts waiting for the final instruction. If the commercial library service cannot execute the transaction operation, it returns a negative response.

[0114] (202) If the scheduling service receives at least one negative response or does not receive a response after a waiting timeout, the transaction is aborted. The scheduling service sends an interrupt request to the business library services of the two subsystems. If the business library service receives an interrupt request from the scheduling service or does not receive a scheduling service request after a timeout, the transaction is aborted.

[0115] (3) Formal submission phase: The scheduling service decides whether to continue the formal submission of the transaction based on the responses of the participants in the pre-submission phase. This can be divided into the following two situations:

[0116] (301) If the scheduling service receives a positive response from all subsystems: The scheduling service enters the committed state from the pre-commit state and sends a formal commit request to the business library services of all subsystems. After receiving the formal commit request, the business library service performs a formal transaction commit and releases all transaction resources after completing the transaction commit. It then sends a haveCommitted positive response to the scheduling service.

[0117] (302) If the scheduling service receives at least one negative response or still does not receive a response after waiting for a timeout: abort the transaction. The specific operation is the same as the abort in the pre-commit phase.

[0118] (4) After the scheduling service receives the positive response from all subsystems, it completes the task.

[0119] The master-slave asynchronous replication function of the commercial database data of the A and B systems is implemented based on the data submission of the platform archive files. The main process is as follows: Figure 8 As shown:

[0120] Step C2-1: Use the power dispatching subsystem in the main mode to receive the model operation request, use the client to call the data dispatching service, modify the model and save the model data, and return immediately after the data is saved successfully. If the data save fails, there is no need for subsequent data synchronization.

[0121] Step C2-2: Generate multiple transaction-level archive files according to the master-slave mode synchronization target through the data dispatching service based on the system configuration, and use them to synchronize data to the power dispatching subsystem in the slave mode.

[0122] Step C2-3: Monitor the generation of archive files through the archive file capture process. Once an archive file is found to be generated, call the data loading process of the remote center through the high-speed resource network multi-threaded concurrent synchronization.

[0123] Step C2-4: The data loading process synchronizes the model data saved in the master mode to the power dispatching subsystem in the slave mode according to the archive file content, completes the data saving, and returns the slave mode data saving result to the archive file capture process.

[0124] Step C2-5: The archive file capture process obtains the data saving result of the slave mode according to the data loading process of the remote center, and then determines whether to delete the local archive file.

[0125] When the power dispatching subsystem in slave mode saves data normally, the archive file is deleted; when the power dispatching subsystem in slave mode sends an exception, such as: network exception, data storage exception, data loading process exception, the archive file capture process does not delete the archive file; when the power dispatching subsystem in slave mode saves an internal logical error, the archive file is moved to the error directory and the error information saved from the system is recorded for subsequent processing.

[0126] Step D: Synchronize the real-time data of each business in the two power dispatching subsystems through real-time database synchronization technology.

[0127] Real-time database synchronization enables real-time data synchronization between System A and System B. Although Systems A and B mirror each other, their processing strategies differ, leading to different requirements for data synchronization and consistency. For example, control services, such as AGC and AVC, require complete independence between Systems A and B, with no cross-communication. Consistency relies on synchronized processing of consistent SCADA and state estimation results. Furthermore, planning services, due to their unique processing logic, require the primary system to handle data, while the backup system accepts synchronization and takes over in the event of a primary system failure. Therefore, all stage data generated by the primary system that impacts subsequent processing must be immediately synchronized to the backup system for storage. Furthermore, for offline analysis services, such as dispatcher power flow calculations, service instances may only be initiated in System A. Processing results and related data are synchronized to System B for storage, and recovery can be performed based on the backup data stored in System B in the event of a System A failure.

[0128] Since the requirements of businesses for real-time data synchronization vary greatly, the present invention provides different data synchronization strategies and mechanisms for real-time data, which are selected and used by the application independently, such as Figure 9 As shown, it specifically includes scheduled synchronization, stage data synchronization, and snapshot data synchronization.

[0129] 1. Scheduled synchronization

[0130] Scheduled real-time data synchronization synchronizes specified datasets between systems A and B at fixed intervals. Synchronized datasets can be configured at the table, field, and record levels. The scheduled synchronization program reads real-time data from the databases of systems A and B according to the dataset configuration at the scheduled synchronization time and synchronizes it to the other system. Scheduled synchronization supports simultaneous relative synchronization of the same table in systems A and B, making it suitable for synchronizing system monitoring data. Due to the continuous nature of scheduled synchronization, it does not resume transmission.

[0131] 2. Stage data synchronization

[0132] Staged data synchronization provides an application-triggered data synchronization method. Applications within a subsystem trigger the synchronization of specified datasets through interfaces, enabling real-time data synchronization from one subsystem's real-time repository to another. Staged data synchronization supports synchronization at the table, field, and record levels. Staged data synchronization requires synchronization from the application's active subsystem to the standby subsystem, so it is only one-way synchronization; bidirectional synchronization of the same table is not considered. Staged data synchronization supports breakpoint-resume transfers, and applications can choose a synchronization strategy that supports breakpoint-resume transfers.

[0133] 3. Snapshot data synchronization

[0134] Snapshot data synchronization provides offline cross-site data backup capabilities. Applications can choose to synchronize snapshots of running data to another subsystem. If one subsystem becomes unavailable, the application can be restored from the offline snapshot in another subsystem. This method is primarily used for rapid migration and recovery of offline analytical services.

[0135] The following table compares the three real-time data synchronization methods:

[0136]

[0137] Step E: Synchronize the manual operation data of the two power dispatching subsystems through message agent forwarding technology.

[0138] Manual operation data synchronization technology automatically synchronizes user operation information across active-active systems in the same city or across different locations through inter-system message broker forwarding. Active-active systems in the same city determine master-slave status through load balancing strategies. Operation messages are sent to the master system's SCADA application and then synchronized to the backup system via a message broker to ensure that operation data remains synchronized across both locations. Upon receiving the synchronization message, the backup system completes the same operation steps as the master system and writes the information to the local real-time database. For active-active systems in the same city, write permissions must be added to the backup system to ensure data consistency in the commercial database and avoid duplicate data writes.

[0139] The types of operation synchronization include setting numbers, blocking, posting, warning suppression and other operations, and the operation synchronization granularity includes equipment, interval, plant station, and full map operations.

[0140] When the network or proxy between the two systems is abnormal, a message cache mechanism is used to cache the operation messages that need to be forwarded locally. After the system communication returns to normal, the local cached messages are retrieved and forwarded again.

[0141] The inter-system message agent forwarding technology is used to achieve two-way real-time synchronization of operation information, such as Figure 11 As shown in the figure, the power grid model and message structure of the main system (power dispatching subsystem in master mode) and the backup system (power dispatching subsystem in slave mode) are exactly the same. The two systems are connected through a message broker. The communication between the message brokers can be processed by security devices such as firewalls or encryption facilities. The synchronization of user operations of the mutual backup systems is achieved through the inter-system message broker forwarding technology.

[0142] Step E01: Set up a message agent in each of the two power dispatching subsystems to receive operation messages from the system in real time.

[0143] Step E02: When a user operates on the screen of any power dispatching subsystem, a manual operation message is sent to the local application server and a copy is also sent to the local message agent.

[0144] Step E03: The message agent forwards the manual operation message to the opposite message agent through a point-to-point service. The message may be transmitted through a data encryption platform or a network firewall or other security devices.

[0145] Step E04: The opposite-side message agent forwards the manual operation message to the application server of the opposite-side system, thereby achieving complete real-time synchronization of the manual operation data.

[0146] If a single-side system failure occurs in step E03, after the single-side system failure is restored, the inter-system data table synchronization technology is used to achieve manual operation data synchronization, such as Figure 12As shown, the two mutually redundant systems are connected via a data proxy machine. Communication between the data proxy machines can be handled by security devices such as firewalls or encryption facilities. Inter-system data table synchronization technology is used to achieve operational data synchronization, which is suitable for data recovery after a single-side system failure.

[0147] Step E05: Configure the data tables that need to be synchronized through the configuration file, including the table name and synchronization method. You can configure full table synchronization or partial field synchronization.

[0148] Step E06: A data proxy server is set up in each of the primary system and the backup system to receive data from the system in real time.

[0149] Step E07: After a single system failure is recovered, the application server in the system requiring synchronization with the other system reads the configuration file, packages the specified data table contents as required, and sends them to the data proxy server. For example, if system B fails and needs to synchronize data with system A after recovery, the application server in system A reads the configuration file, packages the specified data tables, and sends them to the data proxy server in system A.

[0150] Step E08: The data proxy server packages and sends the data to the data proxy server of the opposite system in a point-to-point manner, and the data may be transmitted through security devices such as a data encryption platform or a network firewall.

[0151] Step E09: After receiving the packaged data, the data proxy server of the opposite system parses the data content and writes it to the real-time database of the primary and backup application servers, thus achieving full data synchronization of the opposite system data table.

[0152] Step F: Synchronize the file data in the two power dispatching subsystems through the remote synchronization service.

[0153] A file service is provided in the two power dispatching subsystems of the present invention. The file service provides file and directory management functions for the local system. The file service generally adopts a one-master and one-standby configuration. The host receives the client request and stores the file in the local system. After the file is modified, the modification operation and the modified content are sent to the file service standby machine through the system's internal synchronization service to achieve consistency of dual-machine file data within the system.

[0154] In the dual-active mode in the same city and the disaster recovery mode in different locations, the file service cannot communicate directly with the system in the same city or different locations, and remote synchronization is required based on the proxy service. By configuring the directory that needs to be remotely synchronized, the file service records the remote synchronization log. The remote synchronization service performs incremental file synchronization through the remote proxy based on the file change log, redoes the operation in the remote system, and achieves consistency of file data between systems A and B. The file synchronization architecture is as follows Figure 13 shown.

[0155] To meet the need for simultaneous file modifications in both intra-city active-active and remote disaster recovery systems, the present invention's file synchronization service supports bidirectional synchronization. In active-active mode, the file management services of systems A and B simultaneously provide services to their respective applications, storing and managing their respective files. For file data used only within the system, inter-system synchronization is unnecessary and can be stored locally. Only files that need to be shared between systems A and B are synchronized.

[0156] To implement bidirectional synchronization, the file management service needs to distinguish between local requests and files synchronized remotely. This is done by adding an identifier to the client request data packet. For local client requests, the identifier is local, while for remote synchronization, the identifier is set to remote. This way, the file service does not record remote synchronization logs for remote synchronization requests, thus preventing synchronization loops.

[0157] The same file cannot be modified simultaneously in systems A and B; otherwise, the final synchronization result is unknown. To address this issue, the method of the present invention adopts a master mode control approach. When a file type faces the possibility of simultaneous modification conflicts, the modifications can be performed in the master mode system and then synchronized to the slave mode system, thus avoiding conflicts. Alternatively, the file can be locked in the master mode system. After locking, requests for relocking from the slave mode system will fail, thus avoiding conflicts caused by simultaneous modifications to the same file.

[0158] When synchronizing files remotely, it's important to consider network failures between systems A and B to ensure synchronization logs aren't lost during the failure and that synchronization can resume after the failure is resolved. The method uses persistence to save synchronization logs to the file service machine in the order they were requested. Once a network failure occurs between systems A and B, the synchronization logs are saved sequentially. After the failure is resolved, the file synchronization service synchronizes files sequentially according to the time in the synchronization logs until synchronization is complete, thus achieving eventual consistency in file data.

[0159] In an embodiment of the present invention, control applications (such as SCADA, AGC, and AVC) within the power dispatching system adopt an overall mode of independent operation, bidirectional synchronization, and unique control, achieving a master-slave active-active operational control mode. Application functions are deployed and run independently on both the master and slave system sites using a master-slave mode. Each application node relies on the system's platform services and database management to obtain model parameters and real-time measurement data from the system for independent analysis and calculation.

[0160] To meet active-active requirements, all model maintenance, parameter maintenance, and interface operations must be bidirectionally synchronized via the platform's messaging mechanism. This ensures real-time consistency of computing models and parameters, enabling the switching of master-slave systems at any time. Application operations are first sent to the master system's application node through a unified human-machine interface and then synchronized to the remaining slave system nodes via a message broker, ensuring synchronization of operational data between the master and slave nodes. Upon receiving the synchronization message, the master and slave systems complete the same operational steps, ensuring real-time synchronization of operations and maintenance between the master and slave systems.

[0161] Step G: To ensure the safety of the control system, the method of the present invention needs to determine the controllable state of each application node of the power dispatching subsystem and perform mutual verification to ensure the uniqueness of the control node at the same time. Figure 14 The specific operations are as follows:

[0162] Step G01: Determine whether the current system is controllable through the application node. Only the power dispatching subsystem on-duty application host in the master mode is controllable, and the rest are uncontrollable.

[0163] Step G02: If the current system is controllable, determine whether the application node is a duty node. If it is a duty node, the application node is controllable; otherwise, the application node is uncontrollable.

[0164] Step G03: Each application node performs global registration of the node control status, that is, statistics on whether all application nodes in the system are controllable.

[0165] Step G04: Check the control right of the controllable node to determine whether the application node is unique. If there is only one controllable application node, the check passes and the application node has the control authority to issue control instructions. Otherwise, the control state of the application node is changed to uncontrollable.

[0166] Step H: Whether in the same city or in different locations, the master and slave systems have complete data acquisition applications, each communicating with all the plants and stations under their jurisdiction, and each having the function of issuing control commands. The data acquisition application does not need to actively issue control commands to the plants and stations, but only converts the control commands received from other applications in the system into protocol messages and sends them to the plants and stations. For the safety of system operation, after receiving control commands issued by other applications in the system, the data acquisition application will determine whether the subsystem to which this node belongs is the "power dispatching subsystem in master mode". If so, the control command is allowed to be issued, otherwise the control command is not allowed to be issued, thereby ensuring the safety and uniqueness of the control command issuance.

[0167] In the embodiment of the present invention, numbers A to H are only used to distinguish different operation steps and do not limit the operation order of each step.

[0168] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for operating a power dispatching system based on a master-slave mode, characterized in that: The power dispatching system includes two independent power dispatching subsystems with the same functional structure, and the operation method includes the following steps: Obtaining the working modes of two power dispatching subsystems and performing working mode monitoring, wherein the working modes include a master mode and a slave mode; Control authority management is performed on the application nodes in the power dispatching subsystem according to the master-slave mode; the application nodes of the power dispatching subsystem whose working mode is the master mode have control authority; Use controllable application nodes to operate and control the power grid system and collect data returned by the power grid system; Synchronize the model data in the two power dispatch subsystems through master-slave consistency submission and master-slave asynchronous replication operations; Synchronize the real-time data of each business in the two power dispatching subsystems through real-time database synchronization technology; Synchronize manual operation data in two power dispatching subsystems through message agent forwarding technology; Synchronize file data in two power dispatching subsystems through remote synchronization service; The working modes of the two power dispatching subsystems are switched according to the mode switching instruction.

2. The method for operating a power dispatching system based on a master-slave mode according to claim 1, characterized in that: The methods for working mode monitoring are: Obtaining the operating mode information of each power dispatching subsystem through a master-slave mode manager deployed on the power dispatching subsystem, wherein the operating mode information includes a system number, a system operating mode, and a refresh time; Each power dispatch subsystem reads the configuration information through its master-slave mode manager and obtains the address of the proxy server of the opposite system; Each power dispatching subsystem sends its own working mode information to the address of the proxy server of the opposite system, receives the working mode information of the opposite system, and summarizes the working mode information of the two power dispatching subsystems.

3. The method for operating a power dispatching system based on a master-slave mode according to claim 1, characterized in that: The method for managing the control authority of application nodes in the power dispatching subsystem according to the master-slave mode is as follows: Determine whether the subsystem to which the application node belongs is a power dispatching subsystem in the master mode; if so, determine that the subsystem is controllable; otherwise, determine that the subsystem is uncontrollable; If the subsystem is controllable, determine whether the application node is a duty node. If it is a duty node, determine that the application node is controllable; otherwise, determine that the application node is uncontrollable. Get the control status of all application nodes and perform global registration of node control status; Determine whether the controllable application node is unique. If there is only one controllable application node, configure the control authority for issuing control instructions for the application node. Otherwise, change the control state of the application node to uncontrollable.

4. The method for operating a power dispatching system based on a master-slave mode according to claim 1, characterized in that: The operations for master-slave consistency submission are as follows: Call model_modify in master mode and slave mode respectively through the service bus to send the model operation request to the two power dispatch subsystems; The power dispatch subsystem in the main mode performs permission judgment, maximum ID generation, model inverse operation statement generation, transaction submission, secondary device table trigger information acquisition operations according to the model operation request, and generates the main mode execution result; If the main mode execution result is that the storage is successful, the secondary device table trigger information obtained by the main mode is submitted in a transaction. If the main mode execution result is that the storage fails, an error is returned to the client of the power dispatch subsystem in the main mode; The power dispatching subsystem in slave mode performs permission judgment, maximum ID generation, and transaction submission operations according to the model operation request, and generates the slave mode execution result; If the result of the slave mode execution is that the data is successfully put into storage, the model inverse operation statement generated by the master mode is cleared. If the result of the slave mode execution is that the data is failed to be put into storage, the model inverse operation statement generated by the master mode is executed to restore the equipment records in the power dispatching subsystem in the master mode to the state before the model operation request is executed.

5. The method for operating a power dispatching system based on a master-slave mode according to claim 1, characterized in that: The operation of master-slave asynchronous replication is as follows: The power dispatching subsystem in master mode receives model operation requests and calls the data dispatching service to modify the model and save the model data; Generate archive files based on model data saved in master mode and master-slave mode synchronization targets; Call the data loading process according to the archive file, synchronize the model data saved in the master mode to the power dispatch subsystem in the slave mode, and return the slave mode data saving result; Determine whether to delete the archive file based on the result of saving the slave mode data.

6. The method for operating a power dispatching system based on a master-slave mode according to claim 1, characterized in that: Real-time library synchronization technology includes scheduled synchronization, stage data synchronization and snapshot data synchronization. Among them, scheduled synchronization reads the data in the database of two power dispatching subsystems according to the pre-set synchronization interval, and synchronizes the read data to the power dispatching subsystem on the opposite side; stage data synchronization synchronizes the operating data in one power dispatching subsystem to another power dispatching subsystem through the interface trigger; snapshot data synchronization stores the real-time data in any power dispatching subsystem in the form of snapshots, and sends the data snapshots to the power dispatching subsystem on the opposite side.

7. The method for operating a power dispatching system based on a master-slave mode according to claim 6, characterized in that: Scheduled synchronization supports relative data synchronization between two power dispatching subsystems at the same time, and does not support breakpoint resumption; stage data synchronization is one-way synchronization and supports breakpoint resumption.

8. The method for operating a power dispatching system based on a master-slave mode according to claim 1, characterized in that: The manual data synchronization method is: Obtain manual operation information through the power dispatch subsystem and send manual operation messages to the local application server and message agent; Use the local application server to perform application operations based on manual operation messages and save local manual operation data; Forwarding manual operation messages to the message agent of the opposite power dispatch subsystem through the point-to-point service of the message agent; The manual operation message is forwarded to the application server on the opposite side through the message agent of the power dispatching subsystem on the opposite side; The opposite-side application server performs application operations according to the manual operation message and saves the opposite-side manual operation data.

9. The method for operating a power dispatching system based on a master-slave mode according to claim 1, characterized in that: The file data synchronization method is: Obtain the file directory that needs to be synchronized through the file synchronization service of the power dispatch subsystem and send it to the remote synchronization service; Use remote synchronization services to synchronize operation logs based on file directory changes; According to the synchronization operation log, two power dispatching subsystems are connected through a remote agent to perform file synchronization operations.

10. The method for operating a power dispatching system based on a master-slave mode according to claim 9, characterized in that: The file modification method is as follows: according to the client request, the file is modified in the power dispatching subsystem in the main mode, and the modified file is stored using the file management service.

Images