Main and standby switching method and system for water dispatching automation system

Abstract

The invention provides a main and standby switching method and system for a water dispatching automation system, and relates to the field of water dispatching automation and data processing. The method aims at solving the problems that in an existing method, business event flow sequential logic is ignored, and instructions are prone to being disordered and lost due to switching. The method is applied to a framework comprising a main system, a standby system and a time source, and the main system and the standby system are synchronous in time. When executing the water dispatching control instruction, the main system generates a water dispatching event containing instruction content and a timestamp, and stores the water dispatching event in a shared event sequence cache region; the standby system periodically pulls an event, simulates execution after verification by a business rule engine in combination with an associated context, constructs an event node tree diagram with a weight, and prunes based on an actual result; and when the switching is triggered, comparing the actual result of the main system with the execution sequence of the standby system, matching an adaptive path, and avoiding error instruction marks. The method guarantees the time sequence consistency and logic correctness of the event flow, achieves the intelligent seamless switching of a main system and a standby system, and guarantees the continuous and stable operation of a water dispatching service.

Description

Technical Field

[0001] This invention relates to the fields of water dispatch automation and data processing technology, and in particular to a method and system for switching between primary and backup systems in a water dispatch automation system. Background Technology

[0002] The water dispatch automation system is the core hub for the operation and scheduling of water conservancy projects. It is responsible for real-time monitoring of hydrological information in rivers and reservoirs, and automatically controlling equipment such as gates and pumping stations to achieve comprehensive objectives such as flood control, water supply, and power generation. Given that the continuity and reliability of its operation are directly related to the safety and stability of water conservancy projects, the water dispatch automation system typically adopts a dual-machine hot standby architecture. When the primary system fails, it must quickly switch to the standby system to ensure uninterrupted water dispatch operations.

[0003] Existing water dispatch automation system master-slave switching methods mainly focus on ensuring data consistency. The mainstream technical means include two types: one is heartbeat detection-based switching, where the master and standby systems confirm their survival status through periodic heartbeat signals. If the standby system does not receive a heartbeat from the master system within the timeout period, it determines a fault and initiates a switchover; the other is database mirroring-based synchronization, where the master system replicates critical business data to the standby system database in real time or near real time to ensure that the standby system has the latest data snapshot.

[0004] However, existing methods have significant drawbacks: the operation of a water dispatch automation system is essentially a sequential flow of instructions (event sequences) that occur over time, such as "open gate A - adjust pump station B frequency - close gate C". Existing technologies only focus on the static synchronization of data states, ignoring the dynamic timing logic of instruction execution. When the main system fails during the execution of the event sequence, simple data mirroring cannot inform the backup system of the instruction execution progress and subsequent execution logic. Direct switching can easily lead to duplicate execution, loss, or reversal of instructions, causing serious dispatching accidents such as water level loss of control, and failing to guarantee the continuity of water dispatch operations. Summary of the Invention

[0005] This invention provides a method and system for switching between primary and backup systems in a water dispatching automation system, which solves the problem that the existing technology cannot guarantee the consistency of the timing and logical correctness of water dispatching business event flows, and realizes intelligent, reliable and seamless switching between primary and backup systems.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A method for master / standby switching in a water regulation automation system is applied to a system including a master system, a standby system, and a time source. Both the master system and the standby system are connected to the time source, which is used for time synchronization. The method includes: When the primary system executes any water dispatch control command, it generates a water dispatch event containing command-related content and a timestamp. The water dispatch event is appended and stored in a shared event sequence buffer, which records water dispatch events of a specified time length in sequence form. The standby system retrieves new water dispatch events from the shared event sequence buffer at a set period, performs simulated execution locally based on the retrieved water dispatch events, updates its internal state based on the simulation results, and maintains multiple execution result sequences in a tree-like structure locally after the updated internal state is updated. When a primary / standby switchover is triggered, the actual execution result of the primary system is compared with the execution result sequence in the standby system to determine the appropriate execution path, and new water dispatch events are received and processed based on this execution path.

[0007] Furthermore, the process of the backup system performing local simulation based on the retrieved water adjustment events is as follows: The corresponding water adjustment event and the associated context covered by the event are obtained. The water adjustment event includes gate scheduling, and the associated context includes the current water level data, the current opening degree of the target gate, the status of other equipment linked to the target gate, and relevant safety rules. The water adjustment event and associated context are input into the business rule engine for verification. The business rule engine pre-configures security rules for various water adjustment events. After the business rule engine verifies the event, simulation is performed locally based on the water adjustment event and associated context.

[0008] Furthermore, after the business rule engine passes the verification, the process of simulating locally based on the water level adjustment event and related context is as follows: a simulation environment is established in the isolated environment based on the related context, and constraints are established based on the historical related context of the previous time step. The constraints include the change range of each parameter that can be determined within the time between the previous time step and the water level adjustment event as the corresponding normal range; the simulation is performed locally based on the simulation environment and constraints to deduce possible future states.

[0009] Furthermore, if the verification fails, based on the rule conflict event, the event with the highest similarity between the historical associated context and the current associated context is selected from the historical data as the replacement event.

[0010] Furthermore, the deduction of possible future states also includes: generating corresponding simulated future events based on the success or failure of the simulation execution, adding corresponding associated contexts to any simulated future event; configuring an event node tree diagram, which is based on the most recently pulled water survey event as the root node and presents multiple weighted decision paths, with each decision path corresponding to a possible development state of the simulated future event; forming the trunk of the event node tree diagram based on events that do not conflict with the main system's expectations, creating branch nodes according to the simulated results that differ from the trunk, and assigning path weights based on the data fluctuations and rule conflicts of the associated contexts in the branch nodes, with larger weights for smaller data fluctuations and rule conflicts in the associated contexts.

[0011] Furthermore, updating the internal state of the backup system based on the simulation results includes: retrieving several consecutive water level adjustment events and the actual results of each water level adjustment event from the shared event sequence buffer at a set period; and pruning conflicting paths in the event node tree diagram based on the actual results, while retaining conflict-free paths.

[0012] Furthermore, determining the appropriate execution path when triggering a primary / standby switchover includes: after triggering the primary / standby switchover, determining the event node tree diagram closest to the primary system; matching the current actual state with each node in the event node tree diagram; if a trunk node is matched, switching directly to the nearest node; if a branch node is matched, prioritizing the matching branch with the highest weight for switching.

[0013] Furthermore, when triggering a primary / standby switchover, the following additional steps are taken: if the primary system executes an erroneous instruction, and the erroneous instruction is simulated in the standby system and marked as a low-weight branch, then after triggering the primary / standby switchover, the corresponding branch is avoided, or after the primary / standby switchover, the system reverts to the state of the previous backbone node and issues an alarm.

[0014] Furthermore, the shared event sequence cache adopts a first-in-first-out storage mechanism. When the stored water dispatch events exceed the specified time length, the oldest stored water dispatch events are automatically deleted. The specified time length is determined based on the historical execution cycle of the water dispatch business and can be dynamically adjusted according to actual business needs.

[0015] This invention also provides a primary / backup switching system for an automated water dispatching system, comprising a primary system, a backup system, a time source, a shared event sequence cache, and a business rule engine. Both the primary and backup systems are connected to the time source, the shared event sequence cache, and the business rule engine. The primary system generates water dispatching events containing instruction-related content and timestamps when executing water dispatching control commands, and appends these events to the shared event sequence cache. The backup system retrieves new water dispatching events from the shared event sequence cache according to a set period, performs simulated execution locally based on the retrieved events to update its internal state, and compares the actual execution result of the primary system with its own execution result sequence when a primary / backup switch is triggered to determine the appropriate execution path. The time source provides time synchronization services for the primary and backup systems. The shared event sequence cache records water dispatching events of a specified time length in sequence form. The business rule engine pre-configures security rules for various water dispatching events and verifies the water dispatching events and their associated contexts.

[0016] Compared with the prior art, the present invention has the following beneficial effects: The primary system generates timestamped water dispatch events and stores them in a shared cache. The backup system periodically retrieves these events for simulated execution, maintaining a tree-like sequence of execution results. During switchover, the appropriate path is determined by comparing the actual results with the execution result sequence, fundamentally ensuring the temporal consistency and logical correctness of the water dispatch business event flow. The backup system's simulated execution process, combined with contextual and business rule verification, provides multiple decision-making paths for switchover through an event node tree diagram and path weight mechanism, enhancing the intelligence and reliability of the switchover. The storage mechanism of the shared event sequence cache and its dynamic adjustment of specified time lengths adapt to the needs of different water dispatch business scenarios. The error command identification and avoidance mechanism further reduces scheduling risks, enabling seamless switchover between the primary and backup systems and ensuring the continuous and stable operation of the water dispatch business. Attached Figure Description

[0017] The present invention will be further described below with reference to the accompanying drawings and embodiments: Figure 1 This is a schematic diagram of the basic process of the main / standby switching method of the water regulation automation system in this embodiment.

[0018] In the diagram: S101 - The primary system generates and stores water adjustment events; S102 - The standby system retrieves events and simulates their execution; S103 - Triggers primary / standby switchover; S104 - Determines the appropriate execution path and processes new events. Detailed Implementation

[0019] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings and examples.

[0020] like Figure 1 As shown, the water dispatching automation system master / slave switching method of the present invention is applied to a system including a master system, a backup system, a time source, a shared event sequence cache, and a business rule engine. Both the master system and the backup system are connected to the time source, the shared event sequence cache, and the business rule engine. The time source uses a GPS clock synchronization module with millisecond-level synchronization accuracy to ensure time consistency between the master and backup systems. The shared event sequence cache uses a Redis distributed cache, supporting high-concurrency read / write and stable storage performance. The business rule engine uses the Drools rule engine, which can flexibly configure security rules for various water dispatching events to adapt to the scheduling needs of different water conservancy projects.

[0021] The method specifically includes the following steps: S101: When the main system executes any water level control command, it generates a water level event containing command-related content and a timestamp; the water level event is then appended and stored in the shared event sequence buffer.

[0022] As the primary execution platform for water dispatching operations, the main system generates corresponding water dispatching events in real time when it receives and executes water dispatching control commands such as gate scheduling and pump station frequency adjustment. In addition to the command content itself, each water dispatching event includes a precise timestamp synchronized with a time source, ensuring the event's time sequence is traceable. For example, when the main system executes the control command "increase the opening of gate A from 30% to 80% at time T1," the generated water dispatching event includes the command content "Gate A opening adjustment: 30%→80%" and the timestamp of time T1.

[0023] The shared event sequence cache stores water dispatch events in the order they were generated, using a first-in, first-out (FIFO) storage mechanism. The specified time length is determined based on the historical execution cycle of the water dispatch business. For example, if the average execution cycle of water dispatch business for a certain reservoir is 24 hours, then the specified time length is set to 24 hours. When a stored water dispatch event exceeds 24 hours, the cache automatically deletes the oldest stored water dispatch event, releasing storage resources. It also supports dynamically adjusting the specified time length according to actual business needs. For example, when water dispatch business is frequent during the flood season, the specified time length can be adjusted to 12 hours to improve event storage and retrieval efficiency.

[0024] S102: The standby system pulls new water survey events from the shared event sequence buffer according to the set period, performs simulation execution locally based on the pulled water survey events, and updates the internal state according to the simulation results.

[0025] The backup system's fetch cycle is set based on the event generation frequency of the water dispatch service. For example, if a water dispatch event is generated on average every 5 seconds, the fetch cycle is set to 1 second to ensure timely acquisition of newly generated water dispatch events. After fetching a new water dispatch event, the backup system performs a simulated execution in its local isolated environment. The specific process is as follows: First, obtain the water dispatch event and its associated context. If the water dispatch event is a gate scheduling event, the associated context includes the current water level data (collected by hydrological monitoring sensors), the current opening degree of the target gate (feedback from the gate status monitoring module), the status of other equipment linked to the target gate (such as supporting pumping stations and standby gates), and relevant safety rules (such as the maximum allowable adjustment rate of the gate, water level safety threshold, etc.). If it is a pumping station adjustment event, the associated context includes the current operating power of the pumping station, the water consumption of the water supply area, and the grid voltage stability parameters.

[0026] Then, the water adjustment event and its associated context are input into the business rule engine for verification. The business rule engine is pre-configured with various safety rules for water adjustment events, such as the safety rules for gate scheduling, which include "the single adjustment range of the gate shall not exceed 20%" and "the gate adjustment rate shall not exceed 15% opening per minute". Taking the water adjustment event "increase the opening of gate A from 30% to 80% at time T1" as an example, the associated context shows that the maximum allowable adjustment rate of gate A is 15% opening per minute. The business rule engine calculates that the adjustment range of this instruction is 50%, and the shortest time required to complete the adjustment according to the maximum allowable adjustment rate is approximately 3.33 minutes. If the instruction does not limit the execution time or the limited execution time is not less than 3.33 minutes, the verification passes; if the instruction limits the execution time to 1 minute, the verification fails. In this case, based on the rule conflict event, the event with the highest similarity between the historical associated context and the current associated context is selected from the historical data as the substitute event. For example, the historical event "adjust gate A to 80% in three parts (adjusting 20% ​​each time, with an interval of 2 minutes)" is selected as the substitute event.

[0027] After the business rule engine passes the verification, a simulation environment is established in the isolated environment based on the associated context, and constraints are established based on the historical associated context of the previous time step. The simulation environment simulates the operating scenario of the main system, including equipment operating status, hydrological environmental parameters, etc.; the constraints are determined based on the change range of each parameter between the previous time step and the current water regulation event. For example, in the previous time step (time T0, T0 is earlier than T1), the opening of gate A is 30% and the water level is 105.20 meters. During the time interval from T0 to T1, the natural rate of water level decline is 0.01 meters / 5 minutes. Then the normal range of water level in the constraints is set to [105.19 meters, 105.21 meters].

[0028] Based on the simulation environment and constraints, a local simulation is performed to deduce possible future states. During the simulation, based on whether the simulation succeeds or fails, corresponding simulated future events are generated, and a corresponding associated context is added to each simulated future event. For example, after the simulation of "increasing the gate A opening to 80%" is successfully executed, a simulated future event "Gate A is operating stably at 80% opening, and the water level drops to 104.80 meters" is generated, and the associated context includes the water level data at this time, the gate's operating status, etc.

[0029] Subsequently, an event node tree diagram is configured, using the most recent water regulation event as the root node, presenting multiple weighted decision paths. Each decision path corresponds to a possible simulated future event development state. The trunk of the event node tree diagram is formed based on events that do not conflict with the main system's expectations. For example, if the main system expects gate A to stabilize after its opening reaches 80%, the path corresponding to this simulation result is the trunk. For simulation results that differ from the trunk, such as slight stagnation during gate A's opening increase leading to extended adjustment time, branch nodes are created based on this simulated event. Path weights are assigned based on the data fluctuations and rule conflicts within the associated context of the branch node. Data fluctuations are calculated using standard deviation, and rule conflicts are counted by the number of conflicts. The weight is the weighted average of both. The smaller the data fluctuations and rule conflicts in the associated context, the greater the weight. For example, the weight of the trunk path is set to 1.0, the weight of the slightly stagnant branch path is set to 0.8, and the weight of the branch path with rule conflicts is set to 0.3.

[0030] The backup system retrieves several consecutive water level adjustment events and their actual results from the shared event sequence buffer at a set interval (consistent with the retrieval period, e.g., 1 second). Based on the actual results, it prunes conflicting paths in the event node tree diagram, retaining conflict-free paths. For example, if the primary system actually executes the event "Gate A opening increased to 80%", and the actual result is "Adjustment time 3.5 minutes, water level dropped to 104.78 meters", the deviation from the simulated result of the main path is less than 5%, then the main path is retained. If a branch path simulates an adjustment time of 5 minutes, which deviates significantly from the actual result, then that branch path is pruned. Through pruning, the paths in the event node tree diagram are ensured to closely match the actual execution of the primary system, providing a reliable decision-making basis for subsequent switchovers.

[0031] S103: Trigger primary / standby switchover.

[0032] There are two triggering conditions for primary / standby switchover: First, the primary system fails and the standby system does not receive the heartbeat signal from the primary system within the set timeout period (e.g., 3 seconds), thus determining that the primary system has failed and triggering the switchover; Second, the switchover is manually triggered, such as when the primary system needs maintenance and upgrades, by sending a switchover command through the operation and maintenance platform.

[0033] S104: Compare the actual execution results of the primary system with the execution result sequence in the backup system to determine the appropriate execution path, and receive and process new water adjustment events based on the execution path.

[0034] After triggering the primary / standby switchover, the standby system first determines the event node tree diagram closest to the primary system. This tree diagram is updated based on the last water survey event retrieved before the switchover and the actual results. Then, the current actual status of the primary system (including equipment operating status, hydrological parameters, progress of executed events, etc.) is matched with each node in the event node tree diagram.

[0035] If a trunk node is matched, it means that the execution status of the primary system is consistent with the trunk path simulated by the backup system. The backup system directly switches to the nearest trunk node to take over the processing of subsequent new water dispatch events. If a branch node is matched, the branch with the highest weight is selected for switching. For example, if a slightly stuck branch node with a weight of 0.8 is matched, the backup system switches to this node and processes new events based on the execution logic of this branch to ensure the continuity of business execution after the switch.

[0036] If the primary system executes an erroneous instruction, and this erroneous instruction is marked as a low-weight branch (e.g., weight less than 0.5) after being simulated in the standby system, the standby system will automatically avoid this low-weight branch or roll back to the previous backbone node state after the primary / standby switchover is triggered. It will also issue an alarm message through the operation and maintenance platform to remind operation and maintenance personnel to promptly investigate the erroneous instruction problem in the primary system and avoid scheduling risks caused by the erroneous instruction.

[0037] The water dispatching automation system's primary / backup switching system of this invention corresponds in structure to the method described above, including a primary system, a backup system, a time source, a shared event sequence buffer, and a business rule engine. The connection relationships and functions of each component are as described previously. Through the execution of the aforementioned method, this system achieves intelligent, reliable, and seamless switching between the primary and backup systems, ensuring the continuous and stable operation of water dispatching services.

[0038] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for switching between primary and backup systems in a water regulation automation system, characterized in that, Applied to a system including a primary system, a backup system, and a time source, wherein both the primary system and the backup system are connected to the time source, and the time source is used for time synchronization, the primary / backup switchover method includes: When the primary system executes any water level control command, a water level control event containing command-related content and a timestamp is generated; The generated water adjustment events are appended and stored in a shared event sequence buffer, which records water adjustment events of a specified time length in a sequence format. The backup system retrieves new water-control events from the shared event sequence buffer at a set period, and performs simulation execution locally based on the retrieved water-control events to update the internal state of the backup system according to the simulation results. The updated internal state maintains multiple execution result sequences with a tree-like structure locally. In the event of a primary / backup switchover, the actual execution results of the primary system are compared with the sequence of execution results in the backup system to determine an appropriate execution path, so as to receive and process new water level adjustment events based on the execution path.

2. The method for switching between primary and backup systems in a water regulation automation system as described in claim 1, characterized in that, The local simulation execution of the backup system based on the retrieved water adjustment event includes: Obtain the corresponding water level adjustment event and the associated context covered by the water level adjustment event. If the water level adjustment event includes gate scheduling, the associated context includes the current water level data, the current opening degree of the target gate, the status of other equipment linked with the target gate, and related safety rules. The water survey event and the associated context are input into the business rule engine for verification. The business rule engine is pre-configured with security rules for various water survey events. If the business rules engine verifies the data, a simulation is performed locally based on the water level adjustment event and the associated context.

3. The method for switching between primary and backup systems in a water regulation automation system as described in claim 2, characterized in that, In the backup system, if the business rules engine verification passes, the local simulation based on the water level adjustment event and the associated context includes: In the isolated environment, a simulation environment is established based on the associated context, and constraints are established based on the historical associated context of the previous time step, wherein the established constraints include the range of change of each parameter that can be determined within the time between the previous time step and the water adjustment event as the corresponding normal range. Based on the established simulation environment and the aforementioned constraints, a local simulation is performed to deduce possible future states.

4. The method for switching between primary and backup systems in a water regulation automation system as described in claim 3, characterized in that, If the verification fails, the event with the highest similarity to the historical context is selected from the historical data as the replacement event based on the rule conflict event.

5. The method for switching between primary and backup systems in a water regulation automation system as described in claim 3, characterized in that, Based on the established simulation environment and the aforementioned constraints, local simulations are performed to deduce possible future states, including: Based on whether the simulation succeeds or fails, generate corresponding simulated future events and add corresponding associated contexts to any simulated future event; Configure an event node tree diagram, which is used to present multiple weighted decision paths based on the most recent water control event pulled as the root node. Each decision path is used to simulate a possible future event development state. The main branch of the event node tree diagram is formed based on events that do not conflict with the main system's expectations. Branch nodes are created based on the simulated results that differ from the main branch. Path weights are assigned based on the data fluctuations and rule conflicts of the associated context in the branch nodes, with greater weights for smaller data fluctuations and rule conflicts in the associated context.

6. The method for switching between primary and backup systems in a water regulation automation system as described in claim 5, characterized in that, Updating the internal state of the backup system based on the simulation results includes: According to the set period, retrieve several consecutive water-control events and the actual results of each water-control event from the shared event sequence buffer. Based on the actual results, prune conflicting paths in the event node tree diagram and retain conflict-free paths.

7. The method for switching between primary and backup systems in a water regulation automation system as described in claim 6, characterized in that, In the event of a primary / standby switchover, the appropriate execution path is determined as follows: After triggering the primary / standby switchover, determine the tree diagram of the event node closest to the primary system; Match the current actual state with the nodes in the recent event node tree diagram; If a main node is matched, switch directly to the nearest node; if a branch node is matched, prioritize the matching branch with the highest weight for switching.

8. The method for switching between primary and backup systems in a water regulation automation system as described in claim 7, characterized in that, The following are also included in the case of triggering a primary / standby switchover: If the primary system executes an erroneous instruction, and the erroneous instruction is simulated in the standby system and marked as a low-weight branch, then a primary / standby switchover will be triggered to avoid the corresponding branch, or the primary / standby switchover will be triggered to roll back to the previous backbone node state and issue an alarm.

9. The method for switching between primary and backup systems in a water regulation automation system as described in claim 1, characterized in that, The shared event sequence cache adopts a first-in-first-out storage mechanism. When the stored water dispatch events exceed the specified time length, the oldest stored water dispatch event is automatically deleted. The specified time length is determined based on the historical execution cycle of the water dispatch business and can be dynamically adjusted according to actual business needs.

10. A main / standby switching system for an automated water management system, characterized in that, It includes a primary system, a backup system, a time source, a shared event sequence cache, and a business rule engine. The primary system and the backup system are both connected to the time source, the shared event sequence cache, and the business rule engine. The primary system is used to generate water adjustment events containing instruction-related content and timestamps when executing water adjustment control commands, and to append and store the water adjustment events to the shared event sequence cache area; The backup system is used to pull new water adjustment events from the shared event sequence buffer according to a set period, perform simulated execution locally based on the pulled water adjustment events to update the internal state, and when a primary-backup switch is triggered, compare the actual execution result of the primary system with its own execution result sequence to determine the appropriate execution path. The time source is used to provide time synchronization services for the primary system and the backup system; The shared event sequence buffer is used to record water control events of a specified time length in sequence form; The business rule engine is used to pre-configure security rules for various water survey events and to verify water survey events and their associated contexts.

Images