Water conservancy intelligent dispatching system based on digital twinning

Abstract

The application relates to the technical field of water conservancy dispatching and information management, in particular to a water conservancy intelligent dispatching system based on digital twinning. The system comprises a twinning dispatching module, an evidence and compliance module and a contract execution module. The twinning dispatching module acquires and forms a multi-source data snapshot, generates a target digital twinning object and a twinning version identifier, generates a scenario set and executes simulation to obtain a scenario simulation result and output a dispatching plan. The evidence and compliance module generates a dispatching compliance certificate and a dispatching evidence graph representing the dependency relationship among the multi-source data snapshot, the twinning version identifier, the scenario set, the dispatching plan and the dispatching compliance certificate. The dispatching evidence graph is written into a storage certificate account book. The contract execution module encapsulates a control sequence into a control instruction contract and issues the contract to a field control system to obtain an execution return receipt. The control sequence is verified during the execution process, and a rollback action or a degraded dispatching plan is triggered when the verification fails. The application realizes verifiable consistency association and traceable record of the generation and execution process.

Description

Technical Field

[0001] This invention relates to the field of water conservancy project scheduling and information management technology, and in particular to a water conservancy intelligent scheduling system based on digital twins. Background Technology

[0002] Water conservancy project scheduling typically involves the joint operation and control of multiple objects such as reservoirs, gates, pumping stations, and canal systems. Scheduling decisions require comprehensive information including inflow forecasts, project conditions, operational constraints, and scheduling objectives. With the development of technologies such as digital twins and cyber-physical systems (CPS), existing solutions attempt to construct simulation models corresponding to physical water conservancy objects in virtual space, and then perform scenario simulations and scheduling solutions based on these models to output control command sequences for on-site execution.

[0003] For example, prior art with publication number CN118586299B discloses a simulation method and system for irrigation district water resource management based on digital twins. It obtains the inflow process based on rainfall forecast data combined with runoff generation and geographic information data, constructs a simulation model of canal coefficient values ​​based on gate information and channel cross-section data, and calculates gate opening and closing schemes using optimization algorithms to obtain gate opening and closing schemes for irrigation district water resource scheduling. This type of scheme can generate scheduling schemes around the link of "model construction—simulation deduction—optimization solution—scheme output." However, based on the existing publications, it mainly describes the process of simulation model construction and scheduling scheme solution. It does not provide clear technical limitations on how to form verifiable consistency records between the data snapshots, twin model versions, scenario deduction processes, and constraint satisfaction conditions upon which the scheduling scheme depends, or how to establish a verifiable correspondence between the execution process and execution receipts and the aforementioned generation basis after the scheduling scheme is issued to the field control system.

[0004] Furthermore, CN115688491B proposes using blockchain for digital twin simulation of water conservancy projects. This involves receiving, storing, and monitoring digital scenario data, water conservancy business data, and model projection data through a blockchain module to support the storage and sharing of relevant data. However, based on its published content, this type of solution focuses on the storage and monitoring of data and projection data, without providing a clear description of the verifiable correlation mechanism between the basis for generating scheduling plans, compliance verification results, and on-site execution receipts, which is tightly coupled with the scheduling execution process.

[0005] Meanwhile, digital twin water conservancy platform solutions also propose platform-based architectures such as data baseboards, model platforms, and knowledge platforms to support decision-making processes in application scenarios such as forecasting, early warning, rehearsals, and contingency plans. However, judging from their publicly available content, the platform architecture typically focuses on decision generation and display, without providing unified and clear limitations on how to establish a verifiable consistency relationship between the scheduling plan generation link and the on-site control execution link, or on how to provide the record foundation required for consistency verification in post-event review.

[0006] Therefore, a major technical problem that urgently needs to be solved in this field is: in the process of generating and issuing water conservancy scheduling plans based on digital twins, how to establish a verifiable consistency association between the basis for generating the scheduling plan (multi-source data snapshots, twin model versions, scenario simulation results and constraint rules, etc.) and the on-site execution process and execution receipts, and form a traceable record, so that the scheduling plan can achieve consistency verification during version changes, execution deviations and post-event review, and provide a record basis for reproduction. Summary of the Invention

[0007] To overcome the aforementioned technical deficiencies, the present invention aims to provide a water conservancy intelligent scheduling system based on digital twins. This invention introduces a scheduling evidence graph (a directed acyclic graph of nodes and dependent edges) into the digital twin scheduling link to associate and store multi-source data snapshots, twin versions, scenario simulations, scheduling plans, and compliance proofs. Simultaneously, it achieves verifiable consistency association and traceable recording between the generation basis and the execution process by issuing control command contracts and obtaining execution receipts, and by using operation monitoring and rollback modules for consistency verification and rollback / degradation.

[0008] This invention discloses a water conservancy intelligent scheduling system based on digital twins, including: a twin scheduling module, an evidence and compliance module, a contract execution module, and a strategy and constraint library;

[0009] The twin scheduling module includes a data access module, a twin state engine, a scenario generation and simulation module, and a scheduling solution module. The data access module is used to acquire multi-source data related to water conservancy scheduling and form multi-source data snapshots. The twin state engine is used to generate target digital twin objects based on multi-source data snapshots and generate twin version identifiers. The scenario generation and simulation module is used to generate scenario sets based on target digital twin objects and perform simulations to obtain scenario simulation results. The scheduling solution module is used to output scheduling plans based on scenario simulation results and a strategy and constraint library. The scheduling plan includes control sequences sorted by time.

[0010] The evidence and compliance module includes a scheduling compliance proof module, a scheduling evidence graph module, and an evidence storage module. The scheduling compliance proof module is used to generate scheduling compliance proofs based on the scheduling plan. The scheduling evidence graph module is used to generate a scheduling evidence graph that represents the dependencies between multi-source data snapshots, twin version identifiers, scenario sets, scheduling plans, and scheduling compliance proofs. The scheduling evidence graph is a directed acyclic graph composed of nodes and dependency edges, and the nodes include at least proof nodes and execution nodes. The evidence storage module is used to write the scheduling evidence graph into the evidence storage ledger.

[0011] The contract execution module includes a control command contract module and an operation monitoring and rollback module. The control command contract module is used to encapsulate the control sequence into a control command contract and send it to the field control system to obtain an execution receipt. The operation monitoring and rollback module is used to verify the control command contract based on real-time observation data during the execution process, and to trigger a rollback operation or a degraded scheduling plan when the verification fails.

[0012] Preferably, the scheduling evidence graph includes at least graph nodes corresponding to multi-source data snapshots, twin version identifiers, scenario sets, scheduling plans, scheduling compliance proofs, and execution receipts, and establishes dependency edges between nodes to represent dependency relationships.

[0013] Preferably, the graph node types include at least data nodes, twin nodes, scenario nodes, plan nodes, proof nodes, and execution nodes; the dependency edge types include at least mapping edges from data to twins, generation edges from twins to scenarios, solution edges from scenarios to plans, verification edges from plans to proofs, and distribution edges from plans to executions.

[0014] Preferably, the evidence storage module stores any map node. Generate node digest value And the node digest value satisfies:

[0015]

[0016] in, For the preset hash function, To normalize the serialization function, This indicates a splicing operation. To use the graph nodes The set of dependent edges that terminate at the endpoint.

[0017] Preferably, the scheduling compliance proof module outputs constraint satisfaction evidence, which includes the maximum constraint residual. And the maximum constraint residual satisfies:

[0018]

[0019] in, To plan the number of discrete moments in the time domain, To constrain the number of entries, For the first Constraints at time The residual expression; the scheduling compliance proof module in The constraint satisfaction flag is written into the proof node.

[0020] Preferably, the scheduling compliance proof module outputs risk satisfaction evidence, which includes opportunity constraint satisfaction criteria, and the opportunity constraint satisfaction criteria are satisfied as follows:

[0021]

[0022] And based on the scenario set, the probability is estimated by sample, and the sample estimate is... satisfy:

[0023]

[0024] in, This represents the probability of an event occurring within a set of scenarios. For a moment Simulated water level, This is the upper limit of the water level. For the preset probability threshold, For the number of scenarios; when the first The scenario at any moment satisfy hour ,otherwise ,in Indicates the first The scenario at any moment Simulated water level.

[0025] Preferably, the evidence of risk satisfaction includes a set of risk budget allocation parameters. And satisfy:

[0026]

[0027] in, For the first The probability threshold corresponding to each chance constraint. This is a preset total risk threshold.

[0028] Preferably, the scheduling solution module includes a first solver and a second solver, which output a first candidate control sequence and a second candidate control sequence respectively based on the simulation results of the same scenario; the scheduling compliance proof module calculates the difference between the two. And the degree of difference satisfy:

[0029]

[0030] in, and The first candidate control sequence and the second candidate control sequence are respectively at time... The control quantity, For discrete time intervals; when At that time, the scheduling solution module executes a consistency arbitration process to determine the control sequence, where This is a preset difference threshold.

[0031] Preferably, the control instruction contract includes at least a target object identifier, an execution time window, control parameter boundaries, preconditions, and postconditions; wherein, the preconditions include at least verification conditions for constraint satisfaction markers and risk satisfaction evidence in the proof node, and the postconditions include at least verification conditions for the actual state fragments in the execution receipt, and the execution receipt includes at least the actual state fragments.

[0032] Preferably, the control command contract module adopts a two-stage issuance mechanism, including a pre-submission stage and a submission stage. In the pre-submission stage, a pre-submission request containing the control command contract digest value is sent to the field control system and a pre-submission token is obtained. In the submission stage, a submission command is sent with the pre-submission token to make the control command contract effective, and the pre-submission token is written to the execution node. The control command contract digest value is a hash value calculated by a preset hash function on the control command contract.

[0033] Preferably, the operation monitoring and rollback module calculates the execution deviation index. and in satisfying When a rollback operation or a degraded scheduling plan is triggered, and

[0034]

[0035] in, The number of sampling points. For the first Observations at each sampling point The predicted values ​​are generated from the scheduling plan and the target digital twin object. This is a preset threshold.

[0036] Preferably, the rollback operation includes canceling an incomplete control instruction contract or issuing a reverse control instruction contract corresponding to the control instruction contract; and the operation monitoring and rollback module writes the trigger cause identifier, rollback operation identifier, and degraded scheduling plan identifier into the execution node of the scheduling evidence graph.

[0037] Preferably, the twin state engine includes a shadow twin update submodule, which is used to load candidate model parameters to form a shadow digital twin object without replacing the target digital twin object, and generate a shadow scheduling compliance certificate based on the shadow digital twin object; the twin state engine replaces the model parameters of the target digital twin object and updates the twin version identifier only when the constraints contained in the shadow scheduling compliance certificate are marked as true and the risk satisfaction evidence meets the preset threshold.

[0038] Preferably, the scheduling compliance proof module generates a solver configuration identifier, which includes at least a solver type identifier, a solver parameter set identifier, and a random seed. and random seed Write proof nodes to enable deterministic reproduction of the scheduling plan based on multi-source data snapshots and twin version identifiers.

[0039] Preferably, it includes a scheduling reproduction and audit interface, which is used to reconstruct a scheduling operation link based on the scheduling evidence graph and the evidence ledger, and output an audit package containing multi-source data snapshots, twin version identifiers, scenario sets, scheduling plans, scheduling compliance proofs, and execution receipts.

[0040] Compared with existing technologies, the above technical solution has the following advantages:

[0041] 1. Achieve a closed-loop trusted link for scheduling that is "verifiable, traceable, and reproducible": Through the structured association between multi-source data snapshots, twin version identifiers, scenario sets, scheduling plans, scheduling compliance proofs, and execution receipts, as well as the records in the scheduling evidence graph and evidence ledger, the basis for generating scheduling plans, the basis for compliance judgments, and the on-site execution results can form a consistent evidence chain, which facilitates pre-event verification, in-event monitoring, and post-event audit review.

[0042] 2. Improve the security, compliance, and controllability of scheduling schemes and reduce the risk of exceeding limits: By generating and recording compliance evidence such as maximum constraint residuals, opportunity constraint sample estimation, and risk budget allocation, the degree of constraint satisfaction and risk satisfaction can be quantified before the scheduling scheme is executed, and the compliance conditions are solidified into verifiable data items, reducing the probability of erroneous deployment under conditions that do not meet security constraints.

[0043] 3. Enhance the stability and interpretability of the scheduling solution process: By using dual solvers in parallel, calculating the difference degree and using a consistency arbitration mechanism, the system triggers verification and arbitration when the solution is unstable or the results are inconsistent, and retains the arbitration basis and difference degree records, making the scheduling results more robust and interpretable.

[0044] 4. Improve the certainty and consistency of on-site execution and reduce deviations from control instructions: By constraining the preconditions and postconditions of the control instruction contract and implementing a two-stage issuance mechanism, pre-submission verification is completed before execution and effective control is achieved during the submission stage. Combined with execution receipt verification, the risk of execution deviations and malfunctions caused by network jitter, duplicate issuance, or parameter out-of-bounds errors is reduced.

[0045] 5. Enhance adaptive handling capabilities and operational continuity in abnormal scenarios: By implementing deviation index monitoring, threshold-triggered rollback operations, or degraded scheduling plans, the system can promptly enter conservative control or restore a safe state when there are deviations between observations and predictions, changes in equipment status, or degradation of data quality, and form a traceable handling chain record.

[0046] 6. Reduce uncertainty introduced by model updates and suppress the impact of parameter drift: Through the shadow twin update admission mechanism, when model parameters or calibration results are updated, a shadow digital twin object is generated first and shadow inference and shadow compliance proof verification are performed. The target digital twin object parameters are replaced and the twin version identifier is updated only when the admission conditions are met, thereby reducing the impact of model updates on scheduling security and consistency.

[0047] 7. Improve the quality of multi-source data utilization and reduce the impact of data anomalies on scheduling: By unifying the time stamp of multi-source data, controlling quality, filling in missing data and anomaly labeling, and forming multi-source data snapshots containing metadata and verification information, subsequent twin modeling, simulation and solution calculations have a more stable data input foundation, and it is easier to locate the source of data anomalies.

[0048] 8. Improve the clarity of cross-departmental collaboration and responsibility interfaces: By identifying and storing key objects (snapshots, versions, scenarios, plans, proofs, contracts, receipts), the interaction boundaries between the dispatch center, operation and maintenance platform and field control system are clear, which facilitates collaborative handling, responsibility tracing and compliance auditing.

[0049] 9. Improve the efficiency of review and optimization iteration: By recording random seeds, solution configuration identifiers and key process parameters, the scenario generation, simulation and scheduling solution process under the same input conditions can be repeatedly executed, which facilitates comparative experiments and continuous optimization of scheduling strategies, threshold configurations and model parameters.

[0050] 10. Facilitates project implementation and expansion: Through modular architecture and field-level data structure definition, the system can adapt to different water conservancy objects and different data source access methods, and can be expanded and deployed by region, watershed or project group. At the same time, it provides compatibility space for adding new constraint types, control objects or evidence storage strategies in the future. Attached Figure Description

[0051] Figure 1This is a schematic diagram of the process of a water conservancy intelligent scheduling system based on digital twins according to the present invention;

[0052] Figure 2 A schematic diagram of a Dispatch Evidence Graph (DAG);

[0053] Figure 3 This is a schematic diagram of the two-stage distribution sequence;

[0054] Figure 4 Update the access diagram for Shadow Twin;

[0055] Figure 5 This is a schematic diagram comparing water level curves;

[0056] Figure 6 This is a schematic diagram showing the change of the performance deviation index over time. Detailed Implementation

[0057] The advantages of the present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments.

[0058] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0059] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0060] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0061] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0062] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0063] In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the convenience of the description of the invention and have no specific meaning in themselves. Therefore, "module" and "part" can be used interchangeably.

[0064] This embodiment provides 1. A water conservancy intelligent scheduling system based on digital twins, characterized in that it includes: a twin scheduling module, an evidence and compliance module, a contract execution module, and a strategy and constraint library; wherein, the twin scheduling module includes a data access module, a twin state engine, a scenario generation and simulation module, and a scheduling solution module; the data access module is used to acquire multi-source data related to water conservancy scheduling and form multi-source data snapshots; the twin state engine is used to generate a target digital twin object based on the multi-source data snapshots and generate a twin version identifier; the scenario generation and simulation module is used to generate a scenario set based on the target digital twin object and perform simulation to obtain scenario simulation results; the scheduling solution module is used to output a scheduling plan based on the scenario simulation results and the strategy and constraint library, the scheduling plan including a control sequence ordered by time; the evidence and compliance module includes a scheduling compliance proof module, a scheduling certificate module, and a scheduling solution module. According to the graph module and the evidence storage module, the scheduling compliance proof module is used to generate scheduling compliance proofs based on the scheduling plan. The scheduling evidence graph module is used to generate a scheduling evidence graph that represents the dependencies between multi-source data snapshots, twin version identifiers, scenario sets, scheduling plans, and scheduling compliance proofs. The scheduling evidence graph is a directed acyclic graph composed of nodes and dependency edges, and the nodes include at least proof nodes and execution nodes. The evidence storage module is used to write the scheduling evidence graph into the evidence storage ledger. The contract execution module includes a control instruction contract module and an operation monitoring and rollback module. The control instruction contract module is used to encapsulate the control sequence into a control instruction contract and send it to the field control system to obtain an execution receipt. The operation monitoring and rollback module is used to verify the control instruction contract based on real-time observation data during the execution of the control instruction contract, and trigger a rollback operation or trigger a degraded scheduling plan when the verification fails.

[0065] In this embodiment, a digital twin-based intelligent water conservancy scheduling system is provided. This system is deployed in the computing and evidence storage environment of a water conservancy scheduling center and communicates with the field control system via a dedicated network or secure tunnel. It is used for intelligent scheduling of the joint operation of water conservancy objects such as reservoirs, gates, pumping stations, water diversion points, and canal systems. The system generates multi-source data snapshots using multi-source data as input. These snapshots drive a twin state engine to generate a target digital twin object and output a twin version identifier. Further, it performs simulations under a set of scenarios and obtains a scheduling plan through a scheduling solution module. A scheduling compliance proof module generates a scheduling compliance proof and writes constraint satisfaction evidence and risk satisfaction evidence into the proof node. Finally, a scheduling evidence graph module... A scheduling evidence graph is constructed and written into the evidence ledger by the evidence storage module to form a traceable record. At the same time, the control command contract module encapsulates the scheduling plan into a control command contract and issues it to the field control system through a two-stage delivery mechanism to obtain execution receipts. The operation monitoring and rollback module performs consistency verification based on the execution receipts and real-time observation data, and triggers rollback or downgrade of the scheduling plan when the verification conditions are not met. In addition, the shadow twin update submodule generates a shadow digital twin object during the model update phase and uses shadow scheduling compliance proof as an admission condition to control the timing of model replacement. This realizes a verifiable consistency association and traceable record basis between the basis for scheduling plan generation and the field execution process. It also enables the scheduling plan to be consistent in the scenarios of version change, execution deviation and post-event review and has the record basis required for reproduction.

[0066] like Figure 1 As shown, the digital twin-based intelligent water resources scheduling system includes a twin scheduling module, an evidence and compliance module, a contract execution module, and a strategy and constraint library. The twin scheduling module includes a data access module, a twin state engine, a scenario generation and simulation module, and a scheduling solution module. The evidence and compliance module includes a scheduling compliance proof module, a scheduling evidence graph module, and a storage module. The contract execution module includes a control command contract module and an operation monitoring and rollback module. Furthermore, the digital twin-based intelligent water resources scheduling system may also include an access control and key management unit, a time synchronization unit, an alarm and audit output unit, and a data archiving unit to support the security and maintainability of multi-source data acquisition, storage, and cross-system collaboration. However, to avoid unnecessary limitations on the system scope, the following will use... Figure 1 The core modules shown will be explained in detail.

[0067] For ease of explanation later, the following conventions are used for the symbols in this paper: Represents the discrete time index. This represents the number of discrete moments within the planning time domain. Indicates a constraint index. Indicates the number of constraints. Indicates the number of scenarios. Represents the maximum constrained residual. Indicates time The simulated water level random variable, Indicates the upper limit of the water level. This represents the probability threshold of the opportunity constraint. Represents the sample estimate of the chance constraint. Indicates the first The probability threshold of the opportunity constraint. Indicates the total risk threshold. and This indicates that the two candidate control sequences are at time [time]. The control quantity, Indicates the difference between the two solvers. Indicates the difference threshold. Indicates the first Observations at each sampling point Indicates the first Predicted values ​​for each sampling point Indicates the number of sampling points. Indicates the performance deviation index. Indicates the execution deviation threshold. Indicates a random seed. Indicates the first Graph nodes Indicates the first A set of dependent edges whose endpoints are graph nodes. Indicates the first The node summary value of each graph node. This represents a normalized serialization function. Indicates the preset hash function, Indicates splicing operation

[0068] Detailed explanation of "Multi-source data acquisition" and "Multi-source data snapshot formation" in the data access module:

[0069] The data access module is used to acquire multi-source data related to water conservancy scheduling and form multi-source data snapshots. To ensure the verifiable consistency of subsequent twin modeling and scheduling solutions, the data access module not only completes data acquisition, but also completes data time stamp unification, quality control, missing data completion, anomaly labeling, field normalization, and snapshot encapsulation. During snapshot encapsulation, traceable metadata and verification information are formed, so that any multi-source data snapshot can be mapped to its acquisition source, acquisition time window, processing rule version, and quality mark, thereby providing a verifiable input basis for subsequent proof nodes and evidence storage nodes.

[0070] Source types and access methods of multi-source data:

[0071] In this embodiment, the multi-source data includes at least a combination of the following source types: First, water and rainfall observation data, provided by rain gauges, water level stations, flow stations, evaporation stations, radar rainfall grid data, or meteorological forecast interface data; Second, engineering operating condition data, provided by gate opening sensors, gate hoist status sensors, reservoir capacity curve tables, pump station power metering devices, frequency converter operating parameters, and water level sensors at key canal sections; Third, equipment health status data and alarm event data, provided by the field control system, edge gateway, or operation and maintenance platform; Fourth, static or semi-static basic data, provided by the engineering archive system or configuration library, including canal section parameters, roughness parameters, gate chamber geometric parameters, pump station rated power, equipment start-up and shutdown rules, and scheduling zone boundaries, etc.

[0072] In terms of specific access methods, the data access module can be implemented using a "field-side edge gateway aggregation + dispatch center-side subscription reception" approach. The field-side edge gateway performs preliminary caching and protocol conversion on raw data from multiple sensors and field control systems. The dispatch center-side data access module subscribes to topics via a message bus or pulls data via a secure API. The message bus can be implemented using a publish-subscribe mechanism, and the secure API can be implemented using HTTPS, dedicated VPN lines, or dedicated data links. When multi-source data comes from the real-time database of the field control system, the data access module can obtain sampled values ​​and event data through OPC UA, Modbus / TCP, IEC 60870-5-104, or equivalent industrial protocols, and uniformly map them into an internal field model. When multi-source data comes from a third-party forecasting platform, the data access module can obtain grid forecasts, time-series forecasts, or ensemble forecasts through REST interfaces or file interfaces, and convert them into forecast data structures that can be consumed by the scenario generation and simulation module. When multi-source data comes from manual input or offline files, the data access module can import structured templates and perform legality verification and change auditing on the fields.

[0073] Time synchronization and acquisition time window definition:

[0074] Because different data sources have different sampling periods and transmission delays, in order to ensure a "consistent view at the same moment" for multi-source data snapshots, the data access module defines a unified time base and acquisition time window before forming multi-source data snapshots. In this embodiment, time synchronization is provided by a time synchronization unit, which can provide a unified clock for the scheduling center and edge gateway based on NTP / PTP or BeiDou time synchronization, and write the clock deviation and synchronization status as metadata into the multi-source data snapshot. The acquisition time window can be defined in the form of a "fixed lookback window before the snapshot time", for example, using the snapshot timestamp as the right endpoint of the window and a fixed window length as the left endpoint of the window, selecting the sampled value closest to the snapshot timestamp from the window or using a weighted average to obtain a representative value. The fixed window length is set according to the data source category. For high-frequency operating condition data, it can be set to 1 minute to 5 minutes; for water level and flow data, it can be set to 5 minutes to 15 minutes; and for meteorological forecast data, it can be set to 1 hour or 3 hours to ensure that a usable snapshot can still be formed in the event of network jitter or short-term missing data.

[0075] Data quality control, missing data completion, and anomaly labeling:

[0076] The data access module performs data quality control when forming multi-source data snapshots. The data quality control includes at least range verification, mutation verification, temporal consistency verification, and cross-source consistency verification. Range verification is used to determine whether the sampled value falls within the allowable range of the project, such as whether the gate opening is between 0 and the maximum opening, or whether the reservoir water level is between the dead water level and the check flood level. Mutation verification is used to determine whether the change in sampled value at adjacent times exceeds a reasonable threshold, such as whether the change in reservoir water level exceeds the preset upper limit within a 5-minute sampling period. Temporal consistency verification is used to determine whether the same sensor has reversed timestamps, duplicate timestamps, or no updates for a long time in the time series. Cross-source consistency verification is used to determine whether there are obvious contradictions between different data sources, such as whether the outflow and gate opening, or the upstream and downstream water levels violate the basic hydraulic relationship.

[0077] When a missing value is detected, the data access module performs missing value completion and marks the completion method. Missing value completion can adopt one or more combinations of "last most recent value preservation", "linear interpolation", "physical relationship-based estimation" and "model-based filter estimation", and the completion method identifier is written into the multi-source data snapshot. When an outlier occurs but can still be used for subsequent analysis, the data access module does not directly delete the outlier. Instead, it writes the outlier and the outlier mark into the multi-source data snapshot at the same time, and selects whether to reduce weight, remove or trigger re-collection in the subsequent twin state engine according to the outlier mark.

[0078] Field standardization, unit unification, and internal field model:

[0079] To ensure the reproducibility of subsequent modules, the data access module maps fields from different sources to an internal field model. For example, it maps "GateOpening," "OpenRate," and "Gate Opening" from different manufacturers' devices to "Actual Gate Opening," and "ReservoirLevel," "RWL," and "Reservoir Level" to "Actual Reservoir Level." Regarding unit standardization, the data access module standardizes rainfall to millimeters, water level to meters, flow rate to cubic meters per second, power to kilowatts, and time to ISO 8601 or an equivalent format, and writes the version number of the unit mapping table to the multi-source data snapshot. When coordinate system differences exist, the data access module standardizes spatial coordinates to a preset coordinate system and records the coordinate system identifier.

[0080] The encapsulation structure, snapshot identifier, and verification information of multi-source data snapshots:

[0081] The multi-source data snapshot generated by the data access module includes at least a snapshot identifier, a snapshot timestamp, a collection time window, a set of data source identifiers, a set of fields, a set of quality markers, a set of missing test completion markers, synchronization status information, and verification information. The snapshot identifier is used to uniquely identify the multi-source data snapshot. The snapshot identifier can be formed by combining the snapshot timestamp, the scheduling area identifier, and the sequence number, or by forming a digest value calculated after normalization and serialization. The verification information may include field-level checksums, snapshot-level checksums, or signature information, which are used to verify that the snapshot has not been tampered with during cross-network transmission or cross-system calls.

[0082] For ease of understanding, this embodiment will provide a field-level example of multi-source data snapshots, as follows:

[0083] Taking a multi-source data snapshot of a certain scheduling area at "2025-02-04 08:00:00" as an example, the snapshot may contain the following fields (for ease of reading, the meaning of the fields and example values ​​are explained in consecutive statements below): The snapshot identifier is "SNAP-20250204-080000-AREA01-00017", the snapshot timestamp is "2025-02-04 08:00:00", the acquisition time window is "[07:50:00, 08:00:00]", the data source identifier set includes "rain gauge station A, water level station B, flow station C, gate controller G1, pump station controller P1, canal cross-section sensor S2", and the field set includes "rainfall = 12.4mm, actual reservoir water level = 98.30m, inflow = Outbound flow = The data includes: actual gate opening = 0.45, actual pump station power = 520kW, water level at key section of canal system = 2.18m, equipment health status = normal, alarm summary = none; quality marker set includes "actual reservoir water level = reliable, actual gate opening = reliable, inflow = reliable, outflow = reliable"; missing measurement completion marker set includes "rainfall = original, water level at key section of canal system = linear interpolation"; synchronization status information includes "time synchronization deviation = 12ms, synchronization status = normal"; verification information includes "snapshot-level checksum = XXXX (example)"; the multi-source data snapshot is referenced as an input object in subsequent modules and is associated with twin version identifier, scheduling plan and execution receipt in the evidence chain.

[0084] Detailed explanation of the twin state engine's "Target Digital Twin Object Generation" and "Twin Version Identifier Formation":

[0085] The twin state engine is used to generate a target digital twin object based on multi-source data snapshots and generate a twin version identifier. The target digital twin object is used to describe the structure, parameters and state consistent with the physical hydraulic object in virtual space, so that subsequent scenario simulation and scheduling solutions can be performed on the target digital twin object. In order to ensure that the scheduling plan at different times is traceable and reproducible, the twin state engine generates not only the model structure and parameters when generating the target digital twin object, but also generates a corresponding twin version identifier, and writes the twin version identifier into the twin node of the evidence graph.

[0086] Composition and hierarchy of the target digital twin object:

[0087] In this embodiment, the target digital twin object includes at least an object layer, a model layer, and a state layer. The object layer is used to describe the topological relationships and attributes of entity objects such as reservoir objects, gate objects, pumping station objects, canal system objects, and water distribution point objects. The model layer is used to describe computable models such as the reservoir water balance sub-model, the gate flow calculation sub-model, the canal system one-dimensional hydraulic sub-model, and the equipment constraint sub-model. The state layer is used to describe the state variables at the current snapshot time, such as the current water level and capacity of the reservoir, the current opening degree of the gate, the current start / stop status of the pumping station, and the water level and flow distribution of the canal system.

[0088] Mapping and consistency handling from multi-source data snapshots to model state:

[0089] After receiving a multi-source data snapshot, the twin state engine first performs field mapping and state fusion. Field mapping is used to map fields in the multi-source data snapshot to model state variables. For example, it maps "actual reservoir water level" to the water level state variable in the reservoir state layer and "actual gate opening" to the gate opening state variable in the gate state layer. State fusion is used to handle situations where the same state variable may come from multiple data sources. For example, the reservoir water level may come from both water level stations and radar height estimation. The twin state engine can perform weighted fusion of multi-source observations based on quality labels, equipment health status, and historical reliability. After fusion, it outputs a unique state variable value and records the fusion weight and source identifier as state metadata so that it can explain "which sources and what fusion rules were used for this state variable" during subsequent auditing.

[0090] Model parameter loading, calibration, and parameter drift handling:

[0091] The twin state engine loads model parameters from the configuration library, including canal roughness parameters, cross-sectional geometric parameters, gate flow coefficient parameters, pump station efficiency curve parameters, and reservoir capacity-water level curve parameters. When multi-source data snapshots indicate that recent operating conditions deviate from the model output over a long period, the twin state engine can enter a calibration process to update some parameters. The calibration process may include methods such as parameter sensitivity analysis, least squares fitting, Kalman filtering, or particle filtering to correct parameters without changing the model structure. To avoid parameter drift leading to uncontrollable scheduling results, the output of the calibration process does not directly replace the target digital twin object parameters. Instead, it first generates candidate model parameters and submits them to the shadow twin update submodule for admission determination. Only after admission is passed will the target digital twin object parameters be replaced and the twin version identifier be updated.

[0092] The composition and generation method of twin version identifiers:

[0093] The twin version identifier includes at least the model structure version number, the model parameter version number, and the calibration data version number. The model structure version number identifies the version of the model structure (topology, equation set, component connection relationship). For example, the model structure version number increments when the channel topology changes, a gate object is added, or the form of the model equation changes. The model parameter version number identifies the parameter set version. For example, the model parameter version number increments when the roughness parameter set or flow coefficient set changes. The calibration data version number identifies the historical data range and data source version used for calibration. For example, the calibration data version number is updated when the training range used changes from "last 7 days" to "last 30 days" or a new data source is added. In this embodiment, the twin version identifier can be output in a combined format of "structure version number - parameter version number - calibration version number" and can be supplemented with "model code version number" as metadata to locate the model implementation version when reproducing the problem later.

[0094] For ease of understanding, the following example of a twin version identifier is provided in this embodiment, as follows:

[0095] Taking a certain scheduling calculation as an example, the twin version identifier can be "TV-STRUCT-012;TV-PARAM-108;TV-CALIB-007", where "TV-STRUCT-012" represents the 12th structural version, "TV-PARAM-108" represents the 108th parameter set version, and "TV-CALIB-007" represents the 7th calibration data version. The twin version identifier is written into the evidence graph as a key field of the twin node and is referenced in the association between the scheduling plan, compliance proof, and execution receipt.

[0096] Detailed explanation of "Scenario Set Formation" and "Simulation Output" in the Scenario Generation and Simulation Module:

[0097] The scenario generation and simulation module is used to generate a scenario set based on the target digital twin object and perform simulation to obtain scenario simulation results. The scenario set is used to express uncertainties such as water inflow, rainfall and equipment availability, so that the scheduling solution module can output a more robust scheduling plan under controllable risk constraints. To ensure the reproducibility and auditability of the scenario set, the scenario generation and simulation module records the scenario generation configuration when generating the scenario set, including distribution parameters, correlation structure, sampling method and random seed, and writes it into the metadata field of the proof node or scenario node.

[0098] Expression and sampling of uncertainties in water inflow and rainfall:

[0099] In this embodiment, the uncertainty of inflow can be expressed by the inflow forecast sequence and its error distribution, and the uncertainty of rainfall can be expressed by the rainfall forecast grid and its error distribution. The error distribution can be obtained from historical error statistics and can be grouped according to season, weather pattern, or watershed status. The sampling method can be Monte Carlo sampling, Latin hypercube sampling, or importance sampling to cover the typical uncertainty space with a limited number of scenarios. When it is necessary to express temporal correlation, an autoregressive error model or covariance matrix sampling can be used to make the errors of adjacent time points reasonably correlated. When it is necessary to express spatial correlation, a correlation field generation method can be used to make the rainfall errors of adjacent sub-watersheds reasonably correlated.

[0100] Equipment availability and failure scenario generation:

[0101] In this embodiment, equipment availability can be generated from equipment health status data, historical failure rate, and maintenance plan; for example, if the gate hoist may become unavailable within a certain time window in the future, the gate opening change rate constraint or achievable opening range for the corresponding time period in the scenario will change; if the pump station may be shut down due to maintenance, the pump station start / stop control quantity for the corresponding time period in the scenario will be fixed as shutdown; the equipment availability scenario can be jointly generated with the inflow and rainfall scenario to form a combined scenario set, so that the scheduling solution can cover multi-source uncertainties.

[0102] Context set identifiers and context weights:

[0103] After the scenario set is formed, the scenario generation and simulation module outputs a scenario set identifier, which is used to uniquely identify the generation rules and content of the scenario set. Each scenario in the scenario set can have equal weights, or weights can be assigned according to the probability of occurrence. The weight assignment rules are written into the scenario node metadata together with the scenario generation configuration, so that the subsequent opportunity constraint sample estimation and risk budget allocation can be verified.

[0104] For ease of understanding, the following scenario set generation example will be provided in this embodiment, as follows:

[0105] With a planning time domain of 24 hours and a number of scenarios of A simplified example illustrating the formation of the scenario set: Suppose the inflow forecast sequence is "[300,320,340,360]", and error sampling yields five error sequences, namely " " " " " The inflow sequences for the five scenarios are as follows: " " " " If an equipment availability scenario is also introduced, for example, in scenario 4 the pump station is unavailable for the last two hours, then the control variable for the corresponding pump station in scenario 4 will be fixed as shutdown for the last two hours; the scenario set identifier can be "SCEN-20260204-AREA01-00003", and a random seed is recorded. To ensure reproducibility.

[0106] Simulation results and scenario simulation output:

[0107] The scenario generation and simulation module performs simulations for each scenario. The simulation uses the target digital twin object as the computational carrier, and the inputs are the inflow, rainfall, equipment availability, and initial state under that scenario. The output is the scenario simulation result. The scenario simulation result includes at least the water level sequence, outflow sequence, gate opening sequence, pumping station power sequence, and constraint residual sequence under each scenario, and may include derived indicators such as ecological flow satisfaction, flood peak reduction index, and canal storage and discharge index. The scenario simulation result serves as the common input of the scheduling solution module and the scheduling compliance proof module, and the twin version identifier and multi-source data snapshots on which its generation depends are associated through evidence graphs.

[0108] Detailed explanations of the "Solution Modeling", "Dual Solver Consistency Arbitration", and "Schedule Formation" modules in the scheduling solution module:

[0109] The scheduling solution module is used to output a scheduling plan based on the scenario simulation results and the strategy and constraint library. In this embodiment, the scheduling plan includes a control sequence ordered by time. The control sequence includes at least the gate opening control quantity and the pump station start and stop control quantity, and can be extended to the water distribution control quantity. To improve reliability, the scheduling solution module includes a first solver and a second solver to solve in parallel, and triggers a consistency arbitration process when the difference exceeds a threshold.

[0110] The objectives and constraints of the scheduling solution are as follows:

[0111] The objectives of the scheduling solution are provided by the strategy and constraint library, which may include "minimizing the risk of exceeding limits", "minimizing the cost of scheduling deviation", "minimizing energy consumption", "maximizing water supply satisfaction", and "minimizing the number of gate actions". The constraints are provided by the strategy and constraint library, which may include "reservoir water level not exceeding the upper limit", "discharge flow not exceeding the upper limit", "gate opening change rate not exceeding the upper limit", "pump station power not exceeding the upper limit", and "ecological discharge flow not lower than the lower limit". At the same time, the scheduling solution module can read the constraint residual sequence from the scenario simulation results and use it to quickly screen infeasible solutions.

[0112] Differentiated configurations of the first and second solvers:

[0113] The first solver can employ mathematical programming-based methods, such as mixed integer programming or nonlinear programming, to directly optimize the objective under constraints. The second solver can employ heuristic or metaheuristic methods, such as rolling time-domain greedy search, simulated annealing, or genetic algorithms, to quickly obtain feasible solutions under complex constraints or discrete control. The two solvers employ different solution philosophies, so that the difference in their outputs can reflect "solution stability and model uncertainty" and can serve as an important source of evidence for reliable solutions.

[0114] Dual solver discrepancy calculation and consistency arbitration:

[0115] After the dual solvers output the first and second candidate control sequences in parallel, the scheduling compliance proof module calculates the difference:

[0116]

[0117] in, The first candidate control sequence at time... The control quantity, For the second candidate control sequence at time... The control quantity, For the degree of difference, For the preset difference threshold; when When the consensus arbitration process is initiated, it may include verifying the constraint satisfaction and recalculating the objective function for the two sets of candidate control sequences respectively, and prioritizing the candidate control sequence that is marked as true for constraint satisfaction and has better evidence of risk satisfaction or better objective function value; when neither set of candidate control sequences passes the constraint satisfaction verification, a third solution strategy or a degraded scheduling plan is triggered, and the arbitration process is recorded in the proof node.

[0118] For ease of understanding, the following example of difference calculation is provided in this embodiment, as follows:

[0119] Let the number of discrete time points in the planning time domain be... The gate opening control quantities of the two candidate control sequences are respectively , , , ,as well as , , , The degree of difference is:

[0120]

[0121]

[0122] When the difference threshold At that time, because Arbitration is not triggered; when the difference threshold is set to At that time, because Arbitration is triggered. At this time, the arbitration process will perform constraint verification on the two sets of candidate control sequences and select the output scheduling plan in combination with the objective function. Information such as "Trigger reason = difference exceeds threshold", "difference = 0.0175", "threshold = 0.015", and "final selection = first candidate control sequence" will be written into the metadata field of the proof node.

[0123] Detailed explanation of "Constraint Satisfaction Evidence," "Risk Satisfaction Evidence," and "Risk Budget Allocation" in the Scheduling Compliance Proof Module:

[0124] The scheduling compliance proof module is used to generate scheduling compliance proof based on the scheduling plan. The scheduling compliance proof includes at least constraint satisfaction evidence and risk satisfaction evidence, and writes key evidence into the proof node to support pre-execution verification and post-execution verification. In this embodiment, constraint satisfaction evidence includes the maximum constraint residual, risk satisfaction evidence includes opportunity constraint sample estimation, and when there are multiple opportunity constraints, outputs a risk budget allocation parameter set.

[0125] Calculation and recording of maximum constraint residuals:

[0126] Maximum constraint residuals satisfy:

[0127]

[0128] in, For the first Constraints at time The residual expression is given, where a positive residual indicates a violation of the constraint, and a negative or zero residual indicates that the constraint is satisfied; when When a constraint is satisfied, it is marked as true; otherwise, it is marked as false. The constraint index and time index that caused the maximum residual are recorded, so that it can be directly located later to determine "which constraint and which time" caused the infeasibility.

[0129] For ease of understanding, this embodiment will provide the following example of step-by-step calculation of the maximum constraint residual, as follows:

[0130] set up , Constraint 1 is "water level does not exceed the upper limit", and constraint 2 is "discharge flow does not exceed the upper limit", resulting in the residual sequence: when hour , ,when hour , ,when hour , Then, the "non-negative maximum residuals" calculated time-by-time are 0.0, 0.3, and 0.4, respectively, and further... At this point, the proof node can record "Constraint satisfied flag = no", "Maximum constraint residual = 0.4", "Maximum residual time index = 3", and "Maximum residual constraint index = 2", and can also include a residual detail index so that the verifier can retrieve the complete residual array.

[0131] Chance-constrained sample estimation, threshold comparison, and writing to fields:

[0132] The criterion for satisfying the opportunity constraint is:

[0133]

[0134] And achieved through sample estimation:

[0135]

[0136] in For indication, when The time value is 1 if the time is right, and 0 otherwise; the scheduling compliance proof module calculates the time value for each time step. and take the minimum value. Write the corresponding time index into the proof node to avoid incomplete verification caused by only recording a single time.

[0137] For ease of understanding, the following example of opportunity-constrained sample estimation will be provided in this embodiment, as follows:

[0138] Set upper limit of water level Number of scenarios At some point Water level simulation value , , , , The indicated quantity is , , , , ,thereby If the probability threshold If the risk is not satisfied, the evidence is invalid; the proof node can record "probability threshold = 0.95", "sample estimate minimum value = 0.8", "corresponding time index = 2", "number of scenarios = 5", and "upper limit value = 100.0", and record the scenario set identifier and random seed used for calculation. .

[0139] Consistency between the risk budget allocation parameter set and verification:

[0140] When multiple opportunity constraints exist, risk budget allocation satisfies:

[0141]

[0142] in For the first Opportunity constraint threshold, The total risk threshold; proof node records and And record each The corresponding constraint identifiers enable verifiers to review whether the allocation is out of bounds or has been tampered with.

[0143] For ease of understanding, the following risk budget allocation example will be provided in this embodiment, as follows:

[0144] set up , , , ,but ;when The budget constraint is met; the proof node can record "Total risk threshold = 0.95" and "Assignment threshold set = "Corresponding constraint set = [upper limit water level opportunity constraint, upper limit discharge opportunity constraint, canal system safe water level opportunity constraint]".

[0145] Detailed explanation of the "Field-level Definitions of Nodes and Edges", "Directed Acyclic Constraints", and "Consistency Verification Before Writing" in the Scheduling Evidence Graph module:

[0146] The scheduling evidence graph module is used to generate a scheduling evidence graph that represents the dependencies between multi-source data snapshots, twin version identifiers, scenario sets, scheduling plans, scheduling compliance proofs, and execution receipts. The scheduling evidence graph is a directed acyclic graph consisting of nodes and dependency edges, and each node includes at least a proof node and an execution node. Figure 2 As shown, the scheduling evidence graph includes at least data nodes, twin nodes, scenario nodes, planning nodes, proof nodes, and execution nodes, and establishes dependencies through mapping edges, generation edges, solution edges, verification edges, distribution edges, and receipt association edges.

[0147] Minimal set and extended fields of node fields:

[0148] In this embodiment, each type of node includes at least the following set of fields: node identifier, node type, creation timestamp, associated object identifier, input reference set, output reference set, node summary value placeholder field, and node metadata field. The associated object identifier points to the object represented by the node; for example, a data node is associated with a multi-source data snapshot identifier, a twin node with a twin version identifier, a scenario node with a scenario set identifier, a plan node with a scheduling plan identifier, a proof node with a scheduling compliance proof identifier, and an execution node with a control instruction contract identifier and a pre-commit token. The node metadata field records the rule version, processing pipeline version, and key parameter summary used to generate the node, ensuring auditability.

[0149] Dependency edge field and acyclicity constraint:

[0150] Dependency edges must include at least edge identifier, edge type, starting node identifier, ending node identifier, and edge metadata fields; acyclicity constraints are used to ensure that dependencies do not form closed loops, avoiding logical contradictions such as "plans depend on execution receipts, and execution receipts depend on plans"; the scheduling evidence graph module can perform topological sorting verification before writing, and if a loop is found, it will refuse to write and trigger an alarm.

[0151] Pipeline and consistency verification for evidence graph generation:

[0152] The scheduling evidence graph module follows a fixed pipeline when generating the graph: first, data nodes are created and multi-source data snapshot identifiers are referenced; then, twin nodes are created and twin version identifiers are referenced and mapping edges are established; then, scenario nodes are created and scenario set identifiers are referenced and generation edges are established; then, plan nodes are created and scheduling plan identifiers are referenced and solution edges are established; then, proof nodes are created and scheduling compliance proof identifiers are referenced and verification edges are established; then, execution nodes are created and control instruction contract identifiers are referenced and issuance edges are established. When an execution receipt is returned, a receipt association reference is appended to the execution node or an execution receipt child node is created and a receipt association edge is established. During each creation step, the scheduling evidence graph module performs a reference existence check to ensure that "the referenced object has been generated and the identifier can be resolved," and performs a field integrity check to ensure that "the corresponding fields of the node type are complete." This process prevents the formation of a link structure lacking a reference basis.

[0153] Detailed explanation of the evidence storage module's "normalized serialization", "node digest value calculation", and "batch writing and receipt":

[0154] The evidence storage module is used to write the scheduling evidence graph into the evidence storage ledger. To ensure verifiable consistency, the evidence storage module normalizes and serializes the nodes and dependent edges and calculates the node summary value. Then, it writes the nodes into the evidence storage ledger in batches and obtains the write receipt. The write receipt can be written to the execution node or the proof node to form a verifiable mark that "evidence storage is completed".

[0155] The node digest value satisfies:

[0156]

[0157] in For the first 1 node This is the set of dependency edges ending at this node; normalized serialization function. The system outputs fields in a preset order and sorts collection fields lexicographically, ensuring consistent serialization results for the same content across different machines; a preset hash function is also included. SHA-256 or an equivalent algorithm can be used, and the hash result is stored as a hexadecimal string or a byte array.

[0158] For ease of understanding, this embodiment will provide examples of how node digest values ​​are formed, as follows:

[0159] When the node content of a certain data node contains "Snapshot ID=SNAP-20250204-080000-AREA01-00017; Snapshot Timestamp=2025-02-04 08:00:00; Field Set={Rainfall=12.4mm, Actual Reservoir Water Level=98.30m, Inflow= If the actual gate opening is 0.45, and the quality label set is {actual reservoir water level = reliable, actual gate opening = reliable}, and its incoming edge set is empty (data nodes can be root nodes), then... Output in a fixed field order The output is a standard representation of an empty set. After concatenation, a hash is calculated to obtain the node digest value. When a subsequent verifier rereads the multi-source data snapshot and calculates the hash using the same serialization rules, the same node digest value should be obtained, thus verifying that the content of the data node has not been tampered with. When a data node has incoming edges, the set of incoming edges is also included in the digest calculation, so that "tampering with edge relationships" will also lead to digest inconsistencies.

[0160] Detailed explanation of the "Contract Construction", "Precondition / Postcondition Fields", and "Two-Phase Issuance Interaction" of the Control Command Contract Module:

[0161] The control instruction contract module is used to encapsulate the scheduling plan into a control instruction contract and send it to the field control system to obtain an execution receipt. The control instruction contract includes at least the target object identifier, execution time window, control parameter boundaries, preconditions, and postconditions. The preconditions are used to verify whether the scheduling compliance proof is met before execution, and the postconditions are used to verify whether the execution receipt is met after execution.

[0162] Field construction rules for control instruction contracts:

[0163] In this embodiment, the target object identifier of the control instruction contract includes the gate object identifier, the pump station object identifier, or the combined object identifier; the execution time window is determined by the corresponding time period in the scheduling plan; the control parameter boundaries are determined by the strategy and constraint library, such as the upper and lower bounds of the gate opening control quantity, the upper limit of the rate of change, the upper limit of the pump station power, etc.; the precondition field at least includes clauses such as "proof node reference", "constraint satisfaction flag must be true", and "the minimum value of the chance constraint sample estimate must not be less than the probability threshold"; the postcondition field at least includes clauses such as "the actual state fragment in the execution receipt satisfies the upper limit constraint", "the actual opening in the execution receipt falls within the control parameter boundary", and "the timestamp of the execution receipt falls within the execution time window"; in addition, the control instruction contract may also include timeout policy field, retry policy field, and rollback policy field, but their specific contents can be optional fields and do not impose unnecessary limitations on the system scope.

[0164] Two-phase distribution mechanism and interaction sequence:

[0165] like Figure 3 As shown, the two-phase delivery mechanism includes a pre-submission phase and a submission phase. In the pre-submission phase, the control command contract module sends a pre-submission request to the field control system. The pre-submission request carries at least the control command contract summary value and the execution time window. After receiving the request, the field control system performs a validity check and returns a pre-submission token. In the submission phase, the control command contract module sends a submission command carrying the pre-submission token. The field control system atomically sets the control command contract to be effective locally and starts execution. After execution is completed or a key milestone is reached, an execution receipt is returned. The control command contract module writes the pre-submission token to the execution node to form a verifiable link.

[0166] For ease of understanding, the following example of control instruction contract summary value will be provided in this embodiment, as follows:

[0167] If the control instruction contract fields are "Target object identifier = Gate-01; Execution time window = [08:00:00, 09:00:00]; Control parameter boundary = Opening degree [0.35, 0.60]; Precondition = Proof node constraints are marked as true and risk is supported by evidence; Postcondition = Execution receipt actual water level does not exceed the upper limit and actual opening degree falls within the boundary", then the control instruction contract module first performs normalization and serialization according to a fixed field order, then calculates the summary value and sends a pre-submission request; During the pre-submission stage, the field control system can compare the received summary value with the locally recalculated summary value. If they match, a pre-submission token is returned; After the pre-submission token is returned, the control instruction contract module associates the pre-submission token with the control instruction contract identifier and writes it into the execution node, so that subsequent audits can confirm that "the contract corresponding to this execution node has indeed been pre-submitted and confirmed by the field side".

[0168] Detailed explanations of "Prediction Alignment," "Deviation Index Calculation," "Triggering Rollback or Degradation," and "Handling Link Writing" for the Operation Monitoring and Rollback module:

[0169] The operation monitoring and rollback module is used to verify control command contracts based on real-time observation data during execution, and triggers rollback or degraded scheduling when verification fails. To ensure the verifiability of deviation indicators, the operation monitoring and rollback module performs time alignment between observation and prediction data before calculating deviation indicators, and writes the alignment method and sampling window into the execution node metadata. The deviation indicators satisfy:

[0170]

[0171] in The number of sampling points. For the observed values, For predicted values; when Trigger a rollback operation or a degraded scheduling plan, and write the triggering reason, rollback operation identifier or degraded scheduling plan identifier into the execution node to ensure that the handling is traceable and auditable.

[0172] To facilitate understanding, this embodiment will provide an example of step-by-step calculation of the execution deviation index, as follows:

[0173] Set the number of sampling points The observed values ​​and predicted values ​​are respectively , , , , , ,but:

[0174]

[0175] when No action is triggered when the observed value deviates significantly; A rollback or degradation will be triggered if the threshold is exceeded. Figure 6 An example is provided showing the curve of deviation index changing over time and the deviation threshold. The operation monitoring and rollback module can calculate it in the same way for each time period. And perform a trigger judgment.

[0176] In this embodiment, rollback operations include canceling incomplete control command contracts or issuing reverse control command contracts. Cancellation is used to stop execution when the field control system has not yet been executed or is in a stopable state, while reverse control command contracts are used to restore the control quantity to a safe state when it has been executed and is reversible. The degradation scheduling plan can be preset by the strategy and constraint library, for example, using more conservative control parameter boundaries and stricter risk thresholds when data quality deteriorates or equipment availability decreases. Regardless of whether rollback or degradation is triggered, the operation monitoring and rollback module writes the trigger cause identifier, disposal type identifier, disposal timestamp, and associated execution receipt summary into the execution node to form a complete disposal chain.

[0177] Detailed explanation of "candidate parameter generation", "shadow inference", "admission determination", and "replacement and version update" in the shadow twin update submodule:

[0178] The twin state engine includes a shadow twin update submodule, which is used to load candidate model parameters to form a shadow digital twin object without replacing the target digital twin object, and generate a shadow scheduling compliance certificate based on the shadow digital twin object. The twin state engine replaces the model parameters of the target digital twin object and updates the twin version identifier only when the constraints contained in the shadow scheduling compliance certificate are marked as true and the risk evidence meets the preset threshold. Figure 4 A schematic diagram of the shadow twin update admission is provided.

[0179] Candidate model parameters can be generated based on recent observation data through calibration, such as calibrating the gate flow coefficient, the canal roughness parameter, or the pump station efficiency curve parameter. The shadow digital twin object uses the same multi-source data snapshot and the same scenario set to generate the configuration during shadow inference, thus making the shadow scheduling compliance proof comparable to the output of the current target digital twin object. The admission determination not only compares the objective function value, but also compares the minimum estimated value of the constraint satisfaction label and the chance constraint sample, avoiding the risk increase caused by only pursuing the optimization objective. When admission is approved, the twin state engine performs parameter replacement and updates the model parameter version number, and records "previous version, subsequent version, and admission evidence summary" as twin node metadata.

[0180] For ease of understanding, the following example of shadow twin admission determination will be provided in this embodiment, as follows:

[0181] Let the model parameter version number in the twin version identifier corresponding to the current target digital twin object be “TV-PARAM-108”. After calibrating the candidate model parameters to form a shadow digital twin object, a shadow scheduling compliance certificate is obtained. The maximum constraint residual is 0 and the minimum value of the chance constraint sample estimate is 0.97. The probability threshold configured in the current system is 0.95. Then the shadow scheduling compliance certificate meets the admission conditions. At this time, the twin state engine updates the model parameter version number to “TV-PARAM-109” and records “Admission basis = Shadow scheduling compliance certificate passed; Minimum value of sample estimate = 0.97; Probability threshold = 0.95; Update effective time = 2025-02-04 08:05:00” in the twin node metadata.

[0182] Detailed explanation of the reproduction record basis and solution configuration identifiers (random seed, etc.):

[0183] To ensure that post-event review has the necessary documentation for reproduction, the scheduling compliance verification module generates a solver configuration identifier, which includes at least a solver type identifier, a solver parameter set identifier, and a random seed. and random seed Write the proof node; the random seed is used for elements that may introduce randomness, such as fixed scenario sampling order, random perturbation sequence and heuristic search branch order, so that under the condition of known multi-source data snapshots and twin version identifiers, the review output is more likely to be consistent with the evidence storage schedule plan.

[0184] For ease of understanding, the following example of a solver configuration identifier record will be provided in this embodiment, as follows:

[0185] The solution configuration identifier for a certain scheduling computation can be recorded as "Solver type identifier = Solver-A; Solver parameter set identifier = ParamSet-03; Random seed". Scenario sampling method = Latin hypercube sampling; Number of scenarios Difference threshold Deviation threshold The above information will be written into the metadata field of the proof node; during the review, if the same multi-source data snapshot, the same twin version identifier, and the same random seed are used... This makes it easier to reproduce the scenario set and solution process, and thus the review output and evidence storage scheduling plan are more consistent.

[0186] Comparative experiment:

[0187] To visually demonstrate the difference between this embodiment and the closest existing technology described in the background, an exemplary comparative experiment is conducted using historical data playback. The comparative scheme adopts the approach of "directly outputting the gate opening and closing scheme and issuing it for execution after digital twin simulation and optimization solution," recording the scheduling scheme and execution data but not constructing a scheduling evidence graph, generating verifiable scheduling compliance proof nodes, setting pre / post-condition verification of control command contracts, or using a two-stage issuance and execution node structured recording mechanism. The scheme in this embodiment executes the aforementioned process and forms evidence graph storage, compliance proof, two-stage contract issuance, execution receipt verification, and rollback / degradation records.

[0188] In this embodiment, the experimental data generation process is completed as follows: First, the continuous multi-day water and rainfall observation sequence, gate opening and pumping station power sequence, reservoir water level sequence and flow sequence are extracted from the historical operation database, and the extraction time is aligned; second, for each playback moment, the data access module forms a multi-source data snapshot and writes it to the archive area to maintain input consistency in subsequent repeated experiments; third, the twin state engine generates the target digital twin object based on the multi-source data snapshot and outputs the twin version identifier, and the scenario generation and simulation module generates a scenario set under a fixed random seed s and outputs the scenario. Simulation results; subsequently, the scheduling solution module outputs the scheduling plan, and the scheduling compliance proof module generates the scheduling compliance proof; compared with the scheme that directly constructs control instructions and issues them after obtaining the scheduling plan and records the execution data, the scheme in this embodiment further constructs the scheduling evidence graph and writes it into the evidence ledger before performing two-stage issuance and execution receipt verification; finally, the two schemes are statistically analyzed for indicators such as "audit traceability time", "verifiable consistency pass rate", "anomaly handling success rate", "review input and output consistency", and "mean value of execution deviation index", and the statistical window and statistical rules are written into the experimental report metadata to make the results verifiable.

[0189] The comparison results are shown in Table 1 (the values ​​in the table are exemplary statistical results, used to illustrate the improvement direction and quantitative presentation of this type of mechanism in terms of audit traceability, execution consistency and review consistency). The statistical method for audit traceability time consumption is "the time from the discovery of an abnormal execution receipt to locating the corresponding multi-source data snapshot, twin version identifier, scenario set and scheduling plan and forming an audit package". The statistical method for verifiable consistency pass rate is "the proportion of pre-execution verification to pass and post-execution receipt verification to pass". The statistical method for abnormal handling success rate is "the proportion of handling triggered when the execution deviation index exceeds the threshold and the state is restored to a safe range after handling". The statistical method for review input and output consistency is "the proportion of review output consistent with the evidence storage scheduling plan under the same multi-source data snapshot and the same twin version identifier". The statistical method for the average execution deviation index is "the deviation index within the planning time domain is calculated by window, averaged and then normalized".

[0190] at the same time, Figure 5 The paper presents a comparison of the water level observation curves and water level prediction curves of the example test scheme and the scheme in this embodiment during the same test period, and provides the upper limit value of the water level as a reference. Figure 6 The paper presents the execution deviation index curves and deviation thresholds for two schemes within the same test period. When the verifier needs to verify the original data corresponding to the curves, they can locate the multi-source data snapshots and execution receipts for the corresponding time period according to the graph link, and recalculate using the same prediction output rule. and To verify whether the curves are consistent.

[0191] Table 1 Statistical Results of Comparative Experiments

[0192]

[0193] Table 1 provides the statistical comparison results of the scheme in this embodiment and the comparative scheme under the same historical playback test window. The indicators in Table 1 are all calculated using the same scheduling area, the same test period, and the same input data source range, and with a fixed statistical caliber. "Audit traceability time" refers to the time from the discovery of an abnormal execution receipt or a scheduling deviation event to locating the multi-source data snapshot, twin version identifier, scenario set identifier, scheduling plan identifier, and scheduling compliance proof identifier associated with the event and forming an audit package. "Verifiable consistency pass rate" refers to the proportion of executions where both pre- and post-verification checks pass out of the total number of executions. "Abnormal handling success rate" refers to the proportion of times a rollback or downgrade of the scheduling plan is triggered after the execution deviation indicator exceeds a threshold, and the key safety constraints (e.g., water level upper limit constraints) are restored to meet the requirements after handling out of the total number of triggers. "Review input-output consistency" refers to the proportion of times the reviewed output scheduling plan is consistent with the stored scheduling plan under the conditions of using the same multi-source data snapshot, the same twin version identifier, and a fixed random seed out of the total number of reviews. "Average execution deviation indicator" refers to the average value obtained by calculating the execution deviation indicator using a preset sliding window and averaging the results of each window within the planning time domain. Table 1 visually illustrates the differentiated effects of introducing scheduling evidence graphs, scheduling compliance proofs, and a two-phase delivery mechanism in this embodiment on audit traceability, execution consistency verification, and post-mortem consistency. The data in the table are consistent with... Figure 5 , Figure 6 The curves shown have a corresponding relationship.

[0194] To further illustrate how the system works within a single operating cycle, an exemplary end-to-end process is provided: At the scheduling time of "2025-02-04 08:00:00", the data access module subscribes to the latest data from the rain gauge, water level, flow rate, gate controller, and pump station controller from the edge gateway. It aligns the data timescale with the unified clock provided by the time synchronization unit, and uses the rule of "priority to the nearest value within the window [07:50:00, 08:00:00]", forming a multi-source data snapshot SNAP-20250204-080000-AREA01-00017. Quality markers and missing data completion markers are written to the snapshot. The twin state engine reads this multi-source data snapshot, loads the canal system topology and parameter set, merges reservoir water level observations, updates the state layer variables, and outputs twin version identifiers TV-STRUCT-012; TV-PARAM-108; TV-CALIB-007. The scenario generation and simulation module uses a random seed... Generate scenario set SCEN-20250204-AREA01-00003 and complete the process. The scenario simulation outputs scenario simulation results; the scheduling and solving module runs the first and second solvers in parallel to obtain two sets of candidate control sequences and calculates the difference. ,when Not exceeding the threshold If the scheduling plan PLAN-20250204-AREA01-00009 is output directly, otherwise consistency arbitration is triggered, the arbitration result is recorded, and the scheduling plan is output. The scheduling compliance proof module calculates the maximum constraint residual based on the scheduling plan and the scenario simulation results. And perform chance-constrained sample estimation to obtain The constraint satisfaction marker, maximum constraint residual, probability threshold, and minimum sample estimate are written into the proof node. The scheduling evidence graph module creates data nodes, twin nodes, scenario nodes, plan nodes, proof nodes, and execution nodes according to a fixed pipeline and establishes dependency edges to form a scheduling evidence graph. The evidence storage module normalizes and serializes the nodes, calculates the node summary value, writes it into the evidence storage ledger, and obtains the write receipt. Subsequently, the control instruction contract module constructs the control instruction contract CONTRACT-20250204-AREA01-00005. The control instruction contract includes preconditions referencing the proof node and postconditions referencing the execution receipt field constraints. It uses a two-stage delivery mechanism to send a pre-commit request to the field control system to obtain a pre-commit token TOKEN-XXXX (example). During the submission stage, the pre-commit token is carried to make the control instruction contract effective. The field control system executes the control instruction contract and returns an execution receipt, which includes actual state fragments and key measurement point summaries. The operation monitoring and rollback module performs postcondition verification on the execution receipt and calculates the execution deviation index by window. ,when Exceeding the threshold The system triggers rollback or downgrade scheduling plans and writes the handling link into the execution node. When model parameters need to be updated during the current run, the shadow twin update submodule first loads candidate model parameters to form a shadow digital twin object and generates a shadow scheduling compliance certificate. Only when the shadow scheduling compliance certificate passes the admission criteria is the twin version identifier updated and it takes effect in subsequent scheduling cycles. Throughout the process, multi-source data snapshots, twin version identifiers, scenario sets, scheduling plans, scheduling compliance certificates, control instruction contracts, and execution receipts are all linked through a verifiable consistency association established by the scheduling evidence graph and written into the evidence ledger to form a traceable record basis. This allows any anomaly to be traced back to the corresponding input snapshot and model version along the graph link and can be handled within the same random seed. Reproduce the solution under the configuration identifier.

[0195] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A water conservancy intelligent dispatching system based on digital twins, characterized in that, include: The twin scheduling module, evidence and compliance module, contract enforcement module, and strategy and constraint library; The twin scheduling module includes a data access module, a twin state engine, a scenario generation and simulation module, and a scheduling solution module. The data access module is used to acquire multi-source data related to water conservancy scheduling and form a multi-source data snapshot. The twin state engine is used to generate a target digital twin object and generate a twin version identifier based on the multi-source data snapshot. The scenario generation and simulation module is used to generate a scenario set based on the target digital twin object and perform simulation to obtain scenario simulation results. The scheduling solution module is used to output a scheduling plan based on the scenario simulation results and the strategy and constraint library. The scheduling plan includes a control sequence ordered by time. The evidence and compliance module includes a scheduling compliance proof module, a scheduling evidence graph module, and an evidence storage module. The scheduling compliance proof module is used to generate a scheduling compliance proof based on the scheduling plan. The scheduling evidence graph module is used to generate a scheduling evidence graph that represents the dependencies between the multi-source data snapshot, the twin version identifier, the scenario set, the scheduling plan, and the scheduling compliance proof. The scheduling evidence graph is a directed acyclic graph composed of nodes and dependency edges, and the nodes include at least proof nodes and execution nodes. The evidence storage module is used to write the scheduling evidence graph into an evidence storage ledger. The contract execution module includes a control command contract module and an operation monitoring and rollback module. The control command contract module is used to encapsulate the control sequence into a control command contract and send it to the field control system to obtain an execution receipt. The operation monitoring and rollback module is used to perform verification based on real-time observation data during the execution of the control command contract, and trigger a rollback operation or a degraded scheduling plan when the verification fails.

2. The intelligent water conservancy dispatching system based on digital twins as described in claim 1, characterized in that, The scheduling evidence graph includes at least graph nodes corresponding to the multi-source data snapshot, the twin version identifier, the scenario set, the scheduling plan, the scheduling compliance proof, and the execution receipt, and establishes dependency edges between the nodes to represent dependency relationships.

3. The intelligent water conservancy dispatching system based on digital twins as described in claim 2, characterized in that, The graph node types include at least data nodes, twin nodes, scenario nodes, plan nodes, proof nodes, and execution nodes; the dependency edge types include at least data-to-twin mapping edges, twin-to-scenario generation edges, scenario-to-plan solution edges, plan-to-proof verification edges, and plan-to-execution distribution edges.

4. The intelligent water conservancy dispatching system based on digital twins as described in claim 3, characterized in that, The evidence storage module stores any graph node. Generate node digest value And the node digest value satisfies: in, For the preset hash function, To normalize the serialization function, This indicates a splicing operation. For the above map nodes The set of dependent edges that terminate at the endpoint.

5. The intelligent water conservancy dispatching system based on digital twin as described in claim 1, characterized in that, The scheduling compliance proof module outputs constraint satisfaction evidence, which includes the maximum constraint residual. And the maximum constraint residual satisfies: in, To plan the number of discrete moments in the time domain, To constrain the number of entries, For the first Constraints at time The residual expression; the scheduling compliance proof module in The constraint satisfaction flag is written into the proof node.

6. The intelligent water conservancy scheduling system based on digital twins as described in claim 5, characterized in that, The scheduling compliance proof module outputs risk satisfaction evidence, which includes opportunity constraint satisfaction criteria, and the opportunity constraint satisfaction criteria satisfy: And based on the scenario set, the probability is estimated using samples, and the estimated sample value is... satisfy: in, This represents the probability of an event occurring within the given set of scenarios. For a moment Simulated water level, This is the upper limit of the water level. For the preset probability threshold, For the number of scenarios; when the first The scenario at any moment satisfy hour ,otherwise ,in Indicates the first The scenario at any moment Simulated water level.

7. The intelligent water conservancy scheduling system based on digital twin as described in claim 6, characterized in that, The evidence that the risk is satisfied includes a set of risk budget allocation parameters. And satisfy: in, For the first The probability threshold corresponding to each chance constraint. This is a preset total risk threshold.

8. The intelligent water conservancy dispatching system based on digital twins as described in claim 5, characterized in that, The scheduling solution module includes a first solver and a second solver. The first solver and the second solver output a first candidate control sequence and a second candidate control sequence respectively based on the same scenario simulation result. The scheduling compliance verification module calculates the difference between the two. And the degree of difference satisfy: in, and The first candidate control sequence and the second candidate control sequence are respectively at time... The control quantity, For discrete time points; when At that time, the scheduling solution module executes a consistency arbitration process to determine the control sequence, wherein This is a preset difference threshold.

9. The intelligent water conservancy scheduling system based on digital twins as described in claim 6, characterized in that, The twin state engine includes a shadow twin update submodule, which is used to load candidate model parameters to form a shadow digital twin object without replacing the target digital twin object, and generate a shadow scheduling compliance certificate based on the shadow digital twin object; when the constraints contained in the shadow scheduling compliance certificate are marked as true and the risk satisfaction evidence meets a preset threshold, the twin state engine replaces the model parameters of the target digital twin object and updates the twin version identifier.

10. The intelligent water conservancy scheduling system based on digital twins as described in claim 5, characterized in that, The scheduling compliance proof module generates a solver configuration identifier, which includes at least a solver type identifier, a solver parameter set identifier, and a random seed. and the random seed Write the proof node to enable deterministic reproduction of the scheduling plan based on the multi-source data snapshot and the twin version identifier.

Images