A smart water conservancy monitoring and early warning system based on Internet of Things

Abstract

The application discloses a kind of based on Internet of Things's wisdom water conservancy monitoring early warning system, it is related to water conservancy monitoring technical field, atlas generation module is traversed to the logical connection between each subtask and adjacent subtask in task topology model, extract the data update maximum interval threshold and tolerance sign between each pair of subtask, generate the adaptive logic network atlas between monitoring task and equipment, scheduling execution module is based on adaptive logic network atlas analysis current monitoring subtask when the inconsistent probability of beat of multiple device parallel execution, quantize the timing deviation degree between each subtask, execute corresponding scheduling strategy.The early warning system is by constructing the technical process of task structure modeling, equipment attribute extraction, adaptive relationship analysis, coordination atlas generation, dynamic scheduling control and intelligent early warning response, significantly enhance the overall intelligent level and emergency response capability of water conservancy monitoring system.

Description

Technical Field

[0001] This invention relates to the field of water conservancy monitoring technology, specifically to a smart water conservancy monitoring and early warning system based on the Internet of Things. Background Technology

[0002] With the intensification of climate change and the frequent occurrence of extreme weather events, the spatial and temporal distribution of water resources is becoming increasingly uneven, and water conservancy problems such as floods, droughts, and water pollution are becoming more and more prominent. Traditional water conservancy management methods are no longer able to meet the needs of modern society for safe, efficient, and scientific water conservancy regulation. Against this backdrop, smart water conservancy, as a new management model that integrates new-generation information technology with water conservancy projects, is increasingly becoming an important direction for the development of the water conservancy industry.

[0003] The existing technology has the following drawbacks:

[0004] 1. Existing early warning systems lack time-series correlation modeling and dynamic coordination control mechanisms between multiple monitoring tasks. In practical applications, different types of monitoring tasks (such as water level, water quality, flow rate, etc.) often need to be deployed on heterogeneous IoT devices. These devices have significant differences in sampling period, communication latency, and response capabilities, which often leads to problems such as data asynchrony, information redundancy, and response lag during task execution.

[0005] 2. The early warning system cannot identify the coupling relationship and dependency order between tasks, resulting in a lack of global coordination in scheduling and a lack of a unified task-device adaptation mechanism. It is difficult to achieve optimal resource allocation among different devices. Overall, current technology lacks an integrated solution for intelligent coordination and dynamic early warning for multiple tasks and multiple devices.

[0006] Based on this, the present invention proposes an Internet of Things-based smart water conservancy monitoring and early warning system. By constructing a technical process that covers task structure modeling, equipment attribute extraction, adaptation relationship analysis, coordination graph generation, dynamic scheduling control, and intelligent early warning response, the overall intelligence level and emergency response capability of the water conservancy monitoring system are significantly enhanced. Summary of the Invention

[0007] The purpose of this invention is to provide a smart water conservancy monitoring and early warning system based on the Internet of Things to address the shortcomings of the prior art.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a smart water conservancy monitoring and early warning system based on the Internet of Things, comprising a model building module, a data acquisition module, a matching analysis module, a map generation module, a scheduling execution module, and a monitoring and early warning module;

[0009] Model building module: Divide the water conservancy objects to be monitored into task structures, identify the logical order and data dependencies between each monitoring sub-task, and build a task topology model for water conservancy monitoring;

[0010] Data acquisition module: Acquires the cycle control attributes of IoT monitoring devices deployed at different water conservancy nodes;

[0011] Matching Analysis Module: Based on the task topology model and cycle control attributes, analyze the matching relationship between each monitoring subtask and the equipment, and establish a framework for the adaptation mapping relationship between monitoring subtasks and equipment;

[0012] The graph generation module traverses the logical connections between each subtask and its adjacent subtasks in the task topology model, extracts the maximum data update interval threshold and tolerance flag between each pair of subtasks, and generates an adaptation logical network graph between the monitoring task and the equipment.

[0013] Scheduling and execution module: Based on the adaptation logic network graph analysis, the probability of inconsistent timing of the current monitoring subtasks when they are executed in parallel on multiple devices is analyzed, the degree of timing deviation between each subtask is quantified, and the corresponding scheduling strategy is executed.

[0014] In a preferred embodiment, the graph generation module traverses the logical connection relationships between each monitoring subtask node in the task topology model, identifies the data dependency edges between adjacent tasks, and extracts the maximum data update interval threshold and data buffer tolerance flag for each edge.

[0015] Obtain the beat control attributes of the device matched by each subtask node from the adaptation mapping relationship framework;

[0016] For each task-dependent edge, the coordination level and edge delay risk score of the sub-task edge are calculated by combining the attributes of the devices corresponding to the two sub-task nodes before and after it.

[0017] Based on the subtask node information and edge attributes, an adaptation logic network graph representing the subtask execution logic is constructed.

[0018] In a preferred embodiment, the graph generation module constructs an adaptation logic network graph representing the execution logic of the subtasks based on the subtask node information and edge attributes:

[0019] In the adaptation logic network graph, nodes are used to represent monitoring subtask units and include task identifier, matching device identifier, synchronization capability level and execution priority;

[0020] Edges are used to represent subtask dependencies and include the maximum data update interval, buffer tolerance flag, coordination level, and latency risk score.

[0021] The generated graph structure is encapsulated in a structured manner to form a data structure containing a list of nodes, a list of edges, and full graph statistical indicators.

[0022] In a preferred embodiment, the logic for obtaining the coordination level is as follows: calculate the sum of the sampling period and response time of the upstream subtask device, determine whether the sum of the sampling period and response time is less than the maximum data update interval allowed by the downstream subtask device, and determine whether the upstream and downstream subtask devices support synchronous upload or buffering mechanisms.

[0023] The logic for obtaining the edge delay risk score is as follows: calculate the sum of the sampling period and response time of the upstream subtask device, divide it by the maximum data update interval of the downstream task, obtain the risk ratio, and then classify the risk level.

[0024] In a preferred embodiment, the scheduling execution module obtains the execution parameters of the subtask nodes and their corresponding devices in the adaptation logical network graph, including the sampling period, response time, synchronization capability level, and the maximum allowed update interval of the subtask dependency edges.

[0025] For each pair of dependent subtask nodes, calculate the probability of their rhythm inconsistency, and construct a system-level coordination risk index by weighting the coordination level of each side.

[0026] Perform timing deviation analysis on all task paths, identify synchronous path task chains whose cumulative delay exceeds the theoretical delay, and identify the task node with the largest delay as the bottleneck task node.

[0027] For bottleneck task nodes and their paths, perform scheduling optimization operations based on the policy library;

[0028] The application results of the scheduling strategy are used to update the state attributes of the corresponding task nodes and task edges in the graph, including sampling period, response time, coordination status flag and delay risk level, and the adjustment version information is recorded.

[0029] In a preferred embodiment, the scheduling strategy includes a dynamic sampling frequency adjustment strategy, an edge caching strategy, and a data fusion and rearrangement strategy, wherein,

[0030] Dynamic sampling frequency adjustment strategy: Adjust the task sampling period according to the task rhythm requirements in the path to meet the synchronization requirements;

[0031] Edge caching strategy: Enable the device's cache upload mechanism and configure the data batch upload window;

[0032] Data fusion and rearrangement strategy: Time alignment, loss compensation, and window merging are performed on asynchronous data from multiple tasks.

[0033] In a preferred embodiment, the calculation logic for the probability of timing inconsistency is as follows: the probability of timing inconsistency is obtained by dividing the number of edges with sampling delays exceeding the execution window of downstream tasks by the total number of edges.

[0034] In a preferred embodiment, the matching analysis module obtains the execution requirements of each monitoring subtask in the task topology model. The execution requirements include the monitoring indicator type, sampling timeliness, temporal dependency with adjacent tasks, synchronization requirement level, and data buffer tolerance.

[0035] Based on task indicators and the spatial region they belong to, a set of candidate devices that meet the monitoring capabilities and deployment scope is selected from the device attribute library;

[0036] For each task and its candidate devices, adaptation metrics are calculated separately. These metrics include Time Synchronization Accuracy (TSA), Buffer Tolerance Accuracy (BTA), and Response Capability Accuracy (RCA).

[0037] Based on the adaptation metrics, generate adaptation relationship items between tasks and devices, including task ID, device ID, various adaptation scores, comprehensive matching level, whether it is the preferred device, and scheduling status flags, and organize all adaptation items into an adaptation mapping relationship framework.

[0038] In a preferred embodiment, the system further includes a monitoring and early warning module, which is used to collect monitoring data uploaded by each device in real time, and to perform streaming processing and multi-dimensional feature extraction on the data using a preset hydraulic model, detect abnormal behavior and preliminarily determine the level of abnormality, and trigger the corresponding early warning response strategy based on the abnormality type library and rule model engine when an abnormal event is detected.

[0039] In a preferred embodiment, the monitoring and early warning module receives real-time monitoring data streams uploaded by multi-source IoT monitoring devices, the data streams including water level, water quality, flow rate, and rainfall parameters;

[0040] For various monitoring tasks, the corresponding water conservancy models are called to extract features from batches of data. The water conservancy models include water level dynamic model, flow velocity-water level coupling model, water quality pollution model, and rainfall-inflow-reservoir water level linkage model. Multidimensional anomaly features are extracted for each data window.

[0041] The extracted structured feature vectors are input into the anomaly type knowledge base and rule model engine to match the defined anomaly event types and determine whether they meet the preset anomaly rule conditions, including univariate deviation, trend change, first-order difference directionality and multi-indicator coupling relationship.

[0042] When an abnormal event is identified, the response strategy mapping rule is found according to the event type, an early warning response strategy is generated, and the strategy is triggered in stages according to the severity of the event.

[0043] The technical effects and advantages provided by the present invention in the above technical solution are as follows:

[0044] This invention analyzes the matching relationships between monitoring subtasks and equipment through a matching analysis module, establishing an adaptation mapping framework between monitoring subtasks and equipment. A graph generation module traverses the logical connections between each subtask and its adjacent subtasks in the task topology model, extracting the maximum data update interval threshold and tolerance flag between each pair of subtasks, generating an adaptation logical network graph between monitoring tasks and equipment. A scheduling and execution module analyzes the probability of inconsistent timing of the current monitoring subtask when multiple devices execute in parallel based on the adaptation logical network graph, quantifies the degree of timing deviation between subtasks, and executes corresponding scheduling strategies. This early warning system, by constructing a technical process encompassing task structure modeling, equipment attribute extraction, adaptation relationship analysis, coordination graph generation, dynamic scheduling control, and intelligent early warning response, significantly enhances the overall intelligence level and emergency response capability of water conservancy monitoring systems. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0046] Figure 1 This is a framework diagram of the early warning system of the present invention. Detailed Implementation

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

[0048] Example 1: Please refer to Figure 1 As shown, this embodiment provides a smart water conservancy monitoring and early warning system based on the Internet of Things, including a model building module, a data acquisition module, a matching analysis module, a map generation module, a scheduling and execution module, and a monitoring and early warning module;

[0049] Model building module: Divide the water conservancy objects to be monitored (such as rivers, canals, and reservoirs) into task structures, identify the logical order and data dependencies between each monitoring sub-task (such as water level, water quality, flow, and rainfall), and build a task topology model for water conservancy monitoring for subsequent dynamic adaptation and scheduling. The task topology model is sent to the matching analysis module and the map generation module.

[0050] Data acquisition module: Acquires the clock control attributes of IoT monitoring devices deployed at different water conservancy nodes, including sampling period, response time, communication mode, data synchronization method, etc., to describe the capabilities and limitations of the devices in monitoring tasks. The clock control attributes are then sent to the matching analysis module.

[0051] Matching Analysis Module: Based on the task topology model and cycle control attributes, analyze the matching relationship between each monitoring subtask and the equipment, and establish an adaptation mapping relationship framework between monitoring tasks and equipment. The adaptation mapping relationship framework includes the time synchronization requirements between task segments, data buffer tolerance, and equipment response capabilities. The adaptation mapping relationship framework is sent to the map generation module.

[0052] The graph generation module traverses the logical connections between each subtask and adjacent subtasks in the task topology model, extracts the maximum data update interval threshold and tolerance flag between each pair of tasks, and generates an adaptation logic network graph between the monitoring task and the device by combining the response capabilities and advancement methods of each device. This graph is used to characterize the coordination during task execution and is then sent to the scheduling execution module.

[0053] The scheduling and execution module analyzes the probability of inconsistent timing of the current monitoring task when it is executed in parallel on multiple devices based on the adaptive logical network graph analysis, quantifies the degree of timing deviation between each sub-task, and executes the corresponding scheduling strategy (such as dynamic sampling frequency adjustment, edge cache activation, data fusion and rearrangement, etc.) to ensure the consistency of task collaborative execution. The execution result of the scheduling strategy is sent to the monitoring and early warning module.

[0054] Monitoring and early warning module: Based on coordinated execution, it collects monitoring data uploaded by various devices in real time, and uses a preset hydraulic model to perform streaming processing and multi-dimensional feature extraction on the data. It detects abnormal behavior of key parameters such as hydrology and water quality and makes a preliminary judgment on the level of abnormality. When a suspected abnormal event is detected (such as sudden flood, pollution spread, sudden change in flow, etc.), it triggers the corresponding early warning response strategy based on the established abnormality type library and rule model engine, issues alarm signals in a graded manner, and links relevant hydraulic control systems or management personnel.

[0055] This application analyzes the matching relationships between each monitoring subtask and the equipment through a matching analysis module, establishing an adaptation mapping framework between monitoring subtasks and equipment. A graph generation module traverses the logical connections between each subtask and its adjacent subtasks in the task topology model, extracting the maximum data update interval threshold and tolerance flag between each pair of subtasks, generating an adaptation logical network graph between monitoring tasks and equipment. The scheduling and execution module analyzes the probability of inconsistent timing of the current monitoring subtask when multiple devices execute in parallel based on the adaptation logical network graph, quantifies the degree of timing deviation between each subtask, and executes the corresponding scheduling strategy. This early warning system, by constructing a technical process encompassing task structure modeling, equipment attribute extraction, adaptation relationship analysis, coordination graph generation, dynamic scheduling control, and intelligent early warning response, significantly enhances the overall intelligence level and emergency response capability of the water conservancy monitoring system.

[0056] The workflow of the early warning system is as follows:

[0057] The required water conservancy objects (such as rivers, canals, and reservoirs) are divided into task structures, and the logical order and data dependencies between various monitoring sub-tasks (such as water level, water quality, flow rate, and rainfall) are identified. A task topology model for water conservancy monitoring is constructed for subsequent dynamic adaptation and scheduling. The cycle control attributes of IoT monitoring devices deployed on different water conservancy nodes are obtained, including sampling period, response time, communication mode, and data synchronization method, to describe the capabilities and limitations of the devices in the monitoring tasks. Based on the task topology model and cycle control attributes, the matching relationship between each monitoring sub-task and the devices is analyzed, and a framework for the adaptation mapping relationship between monitoring tasks and devices is established. The map includes time synchronization requirements between task segments, data buffer tolerance, and device response capabilities.

[0058] The logical connections between each subtask and its adjacent subtasks in the task topology model are traversed to extract the maximum data update interval threshold and tolerance flag between each pair of tasks. Combining the response capabilities and execution methods of each device, an adaptation logic network graph between monitoring tasks and devices is generated to characterize the coordinability during task execution. Based on the adaptation logic network graph, the probability of inconsistent timing of the current monitoring task during parallel execution by multiple devices is analyzed, the degree of temporal deviation between subtasks is quantified, and corresponding scheduling strategies (such as dynamic sampling frequency adjustment, edge caching activation, and data fusion rearrangement) are implemented to ensure the consistency of task collaborative execution. Based on coordinated execution, monitoring data uploaded by each device is collected in real time, and the data is processed using a pre-set hydraulic model for streaming and multi-dimensional feature extraction. Abnormal behavior of key parameters such as hydrology and water quality is detected, and the anomaly level is preliminarily determined. When a suspected abnormal event is detected (such as sudden floods, pollution spread, or sudden flow changes), the corresponding early warning response strategy is triggered based on the established anomaly type library and rule model engine, issuing alarm signals at different levels and linking relevant hydraulic control systems or management personnel.

[0059] Example 2:

[0060] 1) The model building module divides the water conservancy objects to be monitored (such as rivers, canals, and reservoirs) into task structures, identifies the logical order and data dependencies between each monitoring sub-task (such as water level, water quality, flow, and rainfall), and builds a task topology model for water conservancy monitoring for subsequent dynamic adaptation and scheduling. The task topology model is sent to the matching analysis module and the map generation module.

[0061] The model building module, as one of the core front-end modules for smart water conservancy monitoring and early warning, is mainly responsible for the structured analysis and topological modeling of the monitoring tasks for the monitored water conservancy objects, in order to support subsequent equipment adaptation, scheduling execution, and anomaly early warning. This module takes watershed-level, regional-level, or engineering-level water conservancy scenarios as the starting point for modeling. Based on the spatial layout and functional zoning of the monitored objects, and combined with the coupling logic and information flow sequence between different monitoring indicators, it constructs a task topology structure with temporal and hierarchical characteristics. Its construction process includes the following steps:

[0062] By using pre-set or GIS-accessed spatial data, the types and spatial locations of water conservancy objects within the monitoring range are identified, including basic monitoring units such as river cross-sections, irrigation canal nodes, reservoir areas, and pumping station gates. Based on the physical distribution and water conservancy connections of these objects, spatial hierarchical partitioning is performed, such as upstream-midstream-downstream, main channel-tributary, and controlled area-non-controlled area, to facilitate subsequent partitioned modeling and monitoring tasks.

[0063] For different types of water conservancy objects, extract the set of sub-task indicators that need to be monitored, for example:

[0064] For river cross-sections: including water level, flow velocity, water quality (such as dissolved oxygen, ammonia nitrogen, pH), and river width;

[0065] For reservoirs: This includes reservoir water level, inflow rate, outflow gate status, sediment concentration, etc.

[0066] For channels: including flow rate, lining temperature, degree of siltation in the cross section, etc.

[0067] All monitoring subtasks are categorized according to their physical and business attributes to facilitate unified abstract representation in the task structure diagram later.

[0068] Identify whether there are temporal dependencies or data-driven relationships between different monitoring subtasks. For example, at a certain cross-section, flow velocity measurement may depend on real-time water level changes; while the assessment of a sudden pollution event may only be confirmed when flow rate, pH value, and ammonia nitrogen concentration all reach abnormal thresholds. Therefore, it is necessary to establish triggering logic links between monitoring tasks, mainly including:

[0069] Precedence dependency: A task can only be executed after another task has been completed or reached a specific state;

[0070] Synchronous execution relationship: Multiple tasks need to be completed synchronously at the same sampling time to ensure data timeliness;

[0071] Buffer dependency: A task is allowed a certain range of time deviation or data delay, but exceeding this range will affect the judgment of subsequent tasks.

[0072] The above relationships can be represented by a task state transition graph or a causal chain, and then converted into a topological edge connection method.

[0073] Based on the aforementioned partitioning information and task logic, a task topology graph is constructed. Each node in the graph represents a monitoring subtask, and each edge represents the dependency or data coupling relationship between nodes. Each edge is appended with the following attributes: maximum allowable sampling interval (for cycle time constraints); effective data transmission window (representing buffer tolerance); whether it is a strongly synchronized edge (if so, it must be executed simultaneously); and the identifier of the water conservancy region it belongs to (for easy partitioned scheduling). The task topology graph can be represented as a directed graph data structure, and its node and edge attributes will be sent as structured input to subsequent modules.

[0074] To support the operation of the graph generation and scheduling algorithm, this module supplements the calculation of the structural attributes of each subtask node, including:

[0075] Task priority weight: Based on the scope of impact and response time of the task, it can be classified into levels, which can be achieved by static weight table or dynamic calculation.

[0076] Recommended task execution cycle value: automatically calculated based on historical data statistics cycle or upstream task cycle;

[0077] Anomaly Sensitivity Score: This task metric is used to evaluate the contribution of global anomaly early warning.

[0078] These attributes are used to assist the scheduling module in sorting tasks and allocating resources.

[0079] Finally, the completed task topology graph model is standardized and encapsulated to form a unified data structure, including: a task node list (containing monitoring object type, indicators, and location codes), a node attribute table, a task edge relationship table, an edge attribute table, and partition index information. This task topology model will be simultaneously transmitted to the "Matching Analysis Module" for calculating task-device adaptation relationships, and to the "Graph Generation Module" for subsequent graph structure expansion and graph algorithm analysis of the adaptation graph.

[0080] Taking a medium-sized river as an example, its upstream section is equipped with rain gauges and water level gauges, its midstream section with a water quality monitoring station, and its downstream section with automatic gate control equipment. The model building module will identify the following task topology links:

[0081] The rain gauge task is linked to the upstream water level monitoring task (preceding dependency); the water level monitoring task is linked to the midstream water quality analysis task (synchronization edge); and the water quality analysis task is linked to the gate control task (driving edge, with a maximum response delay of 10 minutes). These relationships will form a directed task graph, where each task node will carry additional attributes such as its region, suggested sampling frequency, and anomaly sensitivity level, used to support graph generation and scheduling optimization.

[0082] 2) The data acquisition module acquires the clock control attributes of IoT monitoring devices deployed at different water conservancy nodes, including sampling period, response time, communication mode, data synchronization method, etc., to describe the capabilities and limitations of the devices in the monitoring task. The clock control attributes are then sent to the matching analysis module.

[0083] The data acquisition module is a key module for modeling the capabilities of monitoring equipment in smart water conservancy monitoring and early warning. Its main function is to acquire and extract various cycle control attributes from IoT monitoring devices deployed at different water conservancy nodes to comprehensively evaluate the scheduling adaptability and operational constraints of each device in different monitoring tasks. The processing logic of this module not only requires standardized parameter acquisition from multi-source heterogeneous devices but also the construction of a unified device performance description structure to provide basic data support for subsequent matching analysis and scheduling optimization. Its execution process includes the following detailed steps:

[0084] First, the node device directory management interface is called to identify and bind all devices connected to the water conservancy monitoring system to nodes. Each device needs to include basic metadata such as a unique device ID, the monitoring object it belongs to (e.g., river cross-section, reservoir outlet), sensor type (e.g., water level sensor, conductivity probe, rain gauge), installation location information (GIS coordinates or node code), and the zone it belongs to.

[0085] Based on this, the fields of device parameter items from different manufacturers and with different interface protocols (such as Modbus, LoRaWAN, NB-IoT, MQTT, etc.) are standardized to form a standard template of device attributes that can be structured and parsed. For example, fields such as "sampling_interval", "interval_sec", and "sampling frequency" used by different device manufacturers are unified into the "sampling period" attribute, and its unit and range are recorded.

[0086] For each registered device, the data interface or device firmware configuration interface is periodically or as needed to extract its key clock control attributes. These mainly include:

[0087] Sampling Interval: The minimum interval between the device performing one complete sampling task, measured in seconds or minutes. Some devices have a dynamically configurable sampling interval range; the current setting and allowable adjustment range are recorded here.

[0088] Response time (or Response Latency): The average time required from task triggering to the device completing data acquisition and uploading. It can be calculated by the difference between the "task trigger time" and "data reception time" in the device's historical records. For example: Device response time = average value (in all task records: data reception time - task trigger time).

[0089] Communication Mode: Specifies the communication method and data reporting mechanism used by the device, such as periodic push (timed), event-triggered reporting, edge cache merging and uploading, request-response mode, etc. This information is used to determine whether the device has synchronous scheduling capabilities.

[0090] Data synchronization mode: This indicates whether the device supports capabilities such as timestamp alignment, edge cache time sorting, and multi-channel concurrent upload, determining whether the device supports collaborative task execution with other devices. Devices with strong synchronization capabilities can support highly coupled monitoring tasks (such as joint analysis of water level and flow).

[0091] The above parameters are extracted and uniformly encapsulated into a beat control attribute structure. The structure contains fields such as attribute items, current value, value range (if any), unit, and synchronization level identifier.

[0092] To achieve more efficient equipment adaptation assessment, this module further calculates the scheduling adaptability index of the equipment based on the aforementioned cycle control attributes, including but not limited to:

[0093] Time-Response Coefficient (TRC): Represents the device's ability to respond promptly to scheduled tasks. It is calculated as the normalized reciprocal of the weighted average of the device's sampling period and response time. A larger value indicates a faster response. TRC = 1 / (Sampling Period × α + Response Time × β), where α and β are set weight parameters, and α = 0.6 and β = 0.5.

[0094] Synchronous-Collaboration-Index (SCI): This index is used to evaluate devices based on their communication mode, data synchronization method, caching capacity, and other attributes. A higher score indicates that the device is more suitable for collaborative task execution.

[0095] If the device's communication mode is "event-triggered", the synchronization method supports "timestamp alignment", and the caching mode supports "edge fusion upload", then the device's SCI level is high; otherwise, it will be downgraded according to its capabilities.

[0096] Each device's cycle control attributes are encapsulated into a unified data description unit, forming a device cycle control attribute dictionary table. This table uses the device ID as the key and a structured attribute set as the value, containing the following fields: Device-ID (unique device number), monitoring location code (belonging node), sampling period value and allowable range, response time statistics, communication mode identifier, synchronization capability level, time response coefficient (TRC), cooperative synchronization index (SCI), and other extended attributes (such as maximum bandwidth, power supply mode, etc.). Finally, this attribute structure is sent to the matching analysis module in the form of data packets, where subsequent modules perform adaptability calculations and scheduling selection based on task requirements and device attributes.

[0097] For example, a Type A water level sensor located in a main canal has a sampling period of 300 seconds, a response time of 5 seconds, uses NB-IoT communication, periodic push notifications, and has a timestamp upload function. The data is as follows: sampling period: 300 seconds, response time: 5 seconds, communication mode: periodic reporting, synchronization method: supports timestamp alignment, TRC calculation result: 1 / (300×0.7+5×0.3)=approximately 0.0044, SCI score is medium level (stable communication but average synchronization capability). This information will be used in subsequent task scheduling to determine whether it is suitable for participating in joint tasks with high synchronization requirements or for performing relatively independent monitoring tasks with low data frequency.

[0098] 3) The matching analysis module analyzes the matching relationship between each monitoring subtask and the equipment based on the task topology model and the beat control attributes, and establishes an adaptation mapping relationship framework between monitoring tasks and equipment. The adaptation mapping relationship framework includes the time synchronization requirements between task segments, data buffer tolerance, and equipment response capabilities. The adaptation mapping relationship framework is sent to the map generation module.

[0099] The matching analysis module is a crucial bridge between task modeling and scheduling execution. It is responsible for analyzing the matching relationships between each monitoring subtask and available equipment based on the task topology model output by the "model building module" and the equipment cycle control attributes provided by the "data acquisition module." It also establishes a task-equipment adaptation mapping framework that can be used for subsequent map construction and scheduling calculations. Its core objective is to achieve bidirectional matching between task requirements and equipment capabilities, ensuring that timing synchronization, resource utilization, and task completion quality are fully considered during task collaborative scheduling. The processing flow of this module includes the following steps:

[0100] First, each monitoring subtask node in the task topology model is analyzed item by item to extract its task execution constraints, including: required monitoring indicators (such as water level, flow velocity, water quality parameters, etc.); sampling timeliness requirements (e.g., sampling every 5 minutes, with a maximum allowable delay of 2 minutes); temporal dependencies with upstream / downstream tasks (e.g., flow calculation can only be started after water level sampling); synchronization requirement level (e.g., must be executed synchronously with upstream nodes, allowed within ±1 minute, etc.); and data buffer tolerance (i.e., whether the task allows for short-term data delays or loss). This information is then standardized and expressed as a task requirement vector for structured comparison with equipment attributes.

[0101] Based on the monitoring indicator type and spatial location of each task node, the IoT device resource library is filtered to select a set of candidate devices with the monitoring capabilities required for the task. For example, if the task is "midstream section water level monitoring", only devices within the current zone that are water level sensors are considered. The device filtering logic is as follows: Candidate device set = the set of all devices that meet the following conditions: monitoring capability matching (device type ∈ monitoring indicator required by the task) and spatial range matching (device deployment location ∈ water conservancy area or sub-area to which the task belongs). If no device meets the conditions, the task is marked as "unschedulable" and a corresponding exception log is generated.

[0102] For each "task node-candidate device" combination, its compatibility is calculated based on task requirements and device attributes. This compatibility is used to measure the combination's performance in areas such as time synchronization, sampling frequency, and response capability. The following three metrics are primarily calculated:

[0103] ① Time-Synchronization-Adaptability (TSA) is used to evaluate whether the device's sampling period matches the task's synchronization window. The logic is as follows:

[0104] If the device sampling period is less than or equal to the maximum synchronization period requirement of the task, and the device supports synchronous upload, then TSA = high.

[0105] If the device sampling period is greater than the maximum synchronization period requirement of the task, and it has an edge caching mechanism, then TSA = Medium;

[0106] If the device sampling period is greater than the maximum synchronization period requirement of the task, and there is no edge caching mechanism, then TSA = low;

[0107] ② Buffer-Tolerance-Adaptability (BTA) represents the degree to which a task's tolerance for data latency / loss matches the device's communication pattern:

[0108] If the task allows for moderate buffering latency and the device supports resume download or cached upload, then BTA = high;

[0109] If the task cannot tolerate delays and the device has no synchronization or buffering capabilities, then BTA = Low;

[0110] ③ Response Capability Adaptability (RCA): This assesses whether the device's response time meets the real-time requirements of the task. The logic is as follows:

[0111] If the device response time is less than or equal to the maximum allowable response time of the task × 0.8, then RCA = High;

[0112] If the device response time is greater than the maximum allowable response time of the task × 0.8, then RCA = Low;

[0113] The matching results between each task and each candidate device are structured into adaptation items, recording the following: Task ID and Device ID; Matching metric scores TSA, BTA, RCA (which can be labeled with scores or textual levels); Overall adaptation level (e.g., calculated by weighted average, with the total weight determined by configuration); Whether it is the preferred device (labeled according to the highest adaptation level); Matching status flags (schedulable / requires adjustment / unschedulable); Adaptation items are organized into a table or graph structure (such as an adjacency list), forming a task-device adaptation mapping framework to represent the current adaptability overview of the scheduled resources.

[0114] Select a set of devices that meet the following two conditions from the device attribute library as candidate devices for a certain task:

[0115] Indicator matching: The monitoring capabilities of the equipment must cover the indicators required for the task;

[0116] Spatial matching: The equipment deployment location is within the area to which the task belongs (such as the same cross section or the same control area).

[0117] Let the set of candidate devices be D. i , where i is the task number.

[0118] For each task Its candidate devices Calculate three adaptation metrics: Time Synchronization Adaptability (TSA), Buffer Tolerance Adaptability (BTA), and Response Capability Adaptability (RCA).

[0119] Time Synchronization Adaptability (TSA): This metric reflects the compatibility between task synchronization requirements and device sampling capabilities and upload methods. Indicates device The sampling period, This indicates the device's synchronization capability level (1 indicates strong synchronization is supported; 0 indicates no synchronization is supported). Indicates task T i The maximum allowed sampling interval, and the adaptation logic are as follows: If and ,but High; if and ,but In the middle; if but The category is low, and can be converted into a quantitative score through rating: high = 3, medium = 2, low = 1.

[0120] Buffer Tolerance Adaptability (BTA): This metric measures whether a task's tolerance for data latency is compatible with the device's data upload mode. Let... This indicates the task's tolerance for buffering (1 indicates allowed, 0 indicates disallowed). This indicates the device's data upload mode (e.g., supports cached upload, resume upload, etc.), and the adaptation logic is as follows: If and Supports cached upload High; if and caching is not supported. Low; other cases are In the middle, the rating is also converted to high=3, medium=2, low=1.

[0121] Response Capability Adaptability (RCA): This metric indicates whether the device can complete sampling and data upload within the required timeframe. Indicates the device response time. This indicates the maximum allowed response time for the task. The adaptation scoring logic is as follows: If High; if and In the middle; if Low, the rating is converted to High=3, Medium=2, Low=1.

[0122] The assumption is that task T1 requires the following: the indicator type is water level, the sampling period is ≤5 minutes, the maximum response time is 30 seconds, the synchronization requirement is strong synchronization, and the buffer tolerance is allowable.

[0123] Candidate device D1: Sampling period is 3 minutes, response time is 20 seconds; supports timestamp aligned upload and caching; then the adaptation index is: TSA=high (3), BTA=high (3), RCA=high (3), the comprehensive score Score=0.5×3+0.2×3+0.3×3=3.0 is a high-level match, and D1 is the preferred device.

[0124] The adaptation relationships between all tasks and their candidate devices are centrally encapsulated into a unified data structure object, called the adaptation mapping relationship framework. The framework structure includes: a task list (task ID, metrics, region, timing requirements, etc.); a candidate device list (device ID, attributes); an adaptation relationship list (task-device combinations, scores, status, etc.); and matching summary statistics (number of unschedulable tasks, average matching degree, scheduling risk indicators, etc.). After encapsulation, the framework data is sent to the graph generation module to construct the graph topology of "task-device-tick coordination".

[0125] Suppose a task "T1" is "synchronous sampling of water level at downstream cross-sections every 10 minutes", with a maximum allowable response time of 3 seconds. Candidate device "D1" has a sampling period of 5 minutes, a response time of 2 seconds, and uploads data using edge caching and timestamp alignment.

[0126] The calculation is as follows:

[0127] TSA: High (device sampling period is less than the task sampling frequency requirement);

[0128] BTA: High (supports caching and synchronization);

[0129] RCA: High (2 seconds less than 3 seconds × 0.8);

[0130] Overall matching degree: High enough to be scheduled to the device marked as the preferred device.

[0131] 4) The graph generation module traverses the logical connections between each subtask and adjacent subtasks in the task topology model, extracts the maximum data update interval threshold and tolerance flag between each pair of tasks, and generates an adaptation logic network graph between the monitoring task and the device by combining the response capability and advancement method of each device. This graph is used to characterize the coordination during the task execution process and is then sent to the scheduling execution module.

[0132] The graph generation module is a crucial link in the intelligent water conservancy monitoring and early warning system. It is primarily responsible for structurally integrating the previously constructed task topology model with the adaptation mapping framework to generate an adaptation logic network graph with execution coordination assessment capabilities. This graph not only reflects the temporal relationships and data dependencies between tasks but also integrates the execution characteristics and response capabilities of the equipment, serving as the core foundation for subsequent scheduling and execution modules to make optimization decisions and allocate tasks. Its generation process involves multiple stages, including task logic structure traversal, equipment attribute mapping, and graph node and edge attribute assignment, specifically including the following steps:

[0133] The graph generation module first traverses the "task topology model" to identify the directed logical edge relationships between all task nodes. Each edge represents a data dependency or execution sequence relationship between two subtasks, such as "water level monitoring to water quality analysis" or "rainfall monitoring to river flow velocity monitoring".

[0134] During the traversal, for each pair of adjacent task nodes, the following constraint attributes are extracted and recorded: Maximum Update Interval (Max-Update-Interval): This represents the longest waiting time a downstream task can take after receiving data from the upstream task; exceeding this threshold indicates execution delay. Buffer Tolerance Flag: This flag indicates whether a downstream task is allowed to receive delayed data or perform "nearest value padding." Tasks marked as unbufferable require strong synchronization. Logical traversal is implemented using breadth-first search (BFS) or topological sorting strategies to ensure the consistency and rationality of the task execution sequence.

[0135] While acquiring the logical connections between tasks, the system retrieves the candidate devices corresponding to each task node from the adaptation mapping framework and obtains their core response characteristics, including: actual sampling period, average response time, push mode (e.g., periodic push, event-driven, and request-response), and synchronization capability level (e.g., strong synchronization, weak synchronization, and asynchronous). For a logical edge (from task T1 to task T2), the system retrieves the attributes of the devices matched by T1 and T2 and calculates whether they have the capability for coordinated connection.

[0136] The graph generation module traverses all monitoring sub-task nodes and their logical connections in the task topology model, identifying each pair of adjacent sub-task nodes with sequential or data dependency relationships, and constructing a set of logical edges. Each logical edge represents a directed dependency between a predecessor task node and a successor task node. During the traversal, the time constraint information carried by the logical edge is extracted from the task topology model, mainly including the maximum data update interval threshold and the data buffer tolerance flag. The maximum data update interval threshold refers to the longest time interval that a successor task node can tolerate for upstream task data transmission, typically in seconds or minutes. The data buffer tolerance flag indicates whether the successor task is allowed to receive delayed data or use cached data as input; if it is "no," it indicates that this logical edge is a strong synchronization edge.

[0137] Secondly, the graph generation module calls the adaptation mapping framework to extract device information matching each sub-task node and obtain the relevant device's clock control attributes. These attributes include, but are not limited to, sampling period, response time, and synchronization capability level. The sampling period, denoted as P, is the minimum time interval required for a device to complete a full sampling task; the response time, denoted as R, is the average time elapsed from the triggering of the sampling task to successful data upload. The synchronization capability level characterizes whether the device supports synchronization mechanisms such as edge caching and timestamp alignment, affecting subsequent coordination assessments. Coordination analysis is performed on each pair of logically connected task nodes and their corresponding device combinations, calculating the coordination level and edge latency risk score of the logical edge as graph edge attributes. The calculation process for the coordination level is as follows:

[0138] First, calculate the data generation delay time of the upstream subtask device. The calculation formula is as follows: ,in, This indicates the sampling period of the device matched by the upstream subtask node, in seconds or minutes; This indicates the average response time of the device, expressed in units of 1 / 2π and 1 / 3π / 2. same This represents the total latency required for the upstream device to complete data upload from task initiation. Then, this total latency is divided by the maximum data update interval that subsequent task nodes can tolerate. By comparing and considering the synchronization capabilities of the devices, the coordination level is evaluated according to the following rules: like If both upstream and downstream devices support timestamp alignment or edge caching mechanisms, then the coordination level of this logical edge is "high"; if If the equipment lacks synchronization capabilities, the rating is "low".

[0139] Next, the edge delay risk score is calculated. This metric is used to assess the level of execution latency risk for a logical edge in a task chain. Its calculation formula is as follows: The definitions of each parameter are consistent with those described above. Risk levels are then determined based on the ratios of the calculated results: like This indicates a smaller delay. The risk level is low; if This indicates that the delay is close to the tolerable threshold. The risk level is medium; if This indicates that the delay exceeds the maximum tolerance threshold. The risk level is high. For example, if the sampling period of the device matched with an upstream task is 4 minutes and the response time is 1 minute, then... If the maximum update interval for subsequent tasks is 6 minutes, then... If both upstream and downstream devices support timestamp synchronization, the coordination level is high.

[0140] Finally, based on the above analysis results, the graph generation module constructs an adaptive logical network graph. This graph is a directed graph structure, where: each node represents a monitoring subtask unit, carrying attributes including task identifier (Task-ID), matching device identifier (Device-ID), synchronization capability level, and task priority; each edge represents a task dependency relationship, carrying attributes including: maximum data update interval, buffer tolerance flag, coordination level (high / medium / low), and edge latency risk score (low / medium / high); the graph supports dynamic updates of node and edge attributes to adapt to real-time optimization during the scheduling phase; after the graph structure is constructed, it will be encapsulated into a data structure containing a node list, an edge list, and full graph statistical indicators, and sent to the scheduling execution module for scheduling strategy decision-making and cycle control strategy formulation.

[0141] Based on task logic edges and device attributes, the graph generation module performs coordination analysis and assigns the following evaluation attributes to each task edge:

[0142] ① Coordination Level, calculated as follows: If the device response time of T1 + the sampling period of T1 ≤ the maximum allowed update interval of T2, and both devices support timestamp synchronization or buffering mechanisms, the coordination level is high; if the time conditions slightly exceed the threshold, or either device only supports partial synchronization, the coordination level is low; this level describes whether a pair of task nodes can coordinate to complete the task under actual device execution.

[0143] ② Edge-Latency-Risk-Score: This quantifies the risk level of device execution latency on the task chain. The processing logic is as follows:

[0144] Edge delay risk = (T1 device response time + sampling period) ÷ T2 maximum data update interval; if edge delay risk < 0.5, low risk, low score; if edge delay risk is between 0.5 and 1, medium risk, medium score; if edge delay risk is greater than 1 to high risk, high score; this score will be used by the subsequent scheduling module to determine whether the execution order or priority of the task needs to be adjusted.

[0145] All task nodes, device information, task edge relationships, and their coordination attributes are integrated into a structured graph model. This graph structure is in the form of a directed graph, and the specific design is as follows:

[0146] Node: Represents a task unit, with attributes including task ID, matched device ID, synchronization capability level, execution priority, etc.

[0147] Edge: Represents the dependency between tasks. Attributes include: data dependency relationship (predecessor-successor), maximum update interval, buffer tolerance flag, coordination level (high / low), and edge delay risk score (high / medium / low). This graph allows dynamic updates of node and edge attributes and can be used as a state graph input for task scheduling algorithms during runtime. It can also be used for graph algorithm analysis (such as path consistency evaluation and bottleneck node identification).

[0148] After the graph is generated, the adapted logical network graph is structurally serialized and encapsulated. The output data structure includes: a node list (task node attribute set), an edge list (task dependency and coordination attributes), and full graph statistical indicators (average coordination, bottleneck task identification, optimal execution path, etc.). This graph data is transmitted to the scheduling and execution module through an interface for task priority allocation, scheduling strategy calculation, and cycle control strategy generation.

[0149] The task chain is set from T1 (upstream water level sampling) to T2 (downstream water quality analysis). T1 is matched with device D1, with a sampling cycle of 5 minutes and a response time of 30 seconds. T2 is matched with device D2, with a maximum allowed update interval of 6 minutes and supports timestamp upload.

[0150] Judgment: The total delay of D1 is 5.5 minutes, which is less than 6 minutes, so the coordination level is high. The edge delay risk score is 5.5 / 6 = 0.92, so it belongs to the medium risk edge. This information will be marked as "high coordination / medium risk" in the graph edge attributes and used to evaluate whether sampling frequency optimization or edge buffer compensation needs to be introduced during the scheduling phase.

[0151] 5) The scheduling and execution module analyzes the probability of inconsistent timing of the current monitoring task when it is executed in parallel by multiple devices based on the adaptive logical network graph, quantifies the degree of timing deviation between each sub-task, and executes the corresponding scheduling strategy (such as dynamic sampling frequency adjustment, edge cache activation, data fusion and rearrangement, etc.) to ensure the consistency of task collaborative execution. The execution result of the scheduling strategy is sent to the monitoring and early warning module.

[0152] The scheduling and execution module is the core control link in smart water conservancy monitoring and early warning. Its responsibility is to conduct in-depth analysis of the rhythm coordination during task-equipment execution, based on the adapted logical network diagram, identify potential timing conflicts or coordination obstacles, and then dynamically adjust the execution methods, equipment operating parameters, and data processing flows of each monitoring sub-task to ensure the coordination consistency and execution efficiency of the entire monitoring task chain. This module not only needs to handle the rhythm differences of asynchronous data acquisition from multiple devices but also needs to consider various factors such as communication constraints, caching strategies, and data integration rules. Its workflow includes the following steps:

[0153] First, execution parameters such as sampling period, response latency, and synchronization capability of all task nodes and their matching devices are extracted from the adaptation logical network graph. For each pair of task nodes with logical edges in the graph (i.e., there is a data dependency or execution order relationship), the probability of timing inconsistency is calculated based on their device characteristics to quantify the risk of timing deviations during their collaborative execution. The processing logic is as follows: For a task pair (T1 to T2) and its corresponding device (D1, D2), the following is defined: Total latency of D1 = Sampling period of D1 + Response time of D1, Execution window of D2 = Maximum allowable data update interval of T2. If the total latency of D1 > Execution window of D2, a potential timing conflict is considered to exist. The proportion of timing conflicts among all task edges is then calculated.

[0154] The probability of inconsistent rhythm is calculated as the number of conflicting edges divided by the total number of edges. Simultaneously, weights are assigned to each edge based on its coordination level to construct a coordination risk index for the entire graph, which serves as one of the priority objective functions for scheduling optimization.

[0155] Further timing deviation assessments are performed on task nodes in the task topology graph to identify "bottleneck tasks" that may cause end-to-end timing imbalances due to device latency, sampling differences, or communication congestion. The analysis logic is as follows: For any path P = {T1 to T2 to ... to Tn}: Cumulative path execution delay = ∑(sampling period of each Ti-matched device + response time). Compared with the theoretical ideal synchronous path (i.e., all tasks are executed sequentially according to the maximum allowed period), the deviation value = actual delay - ideal path time. If the deviation value ranks in the top N% of the entire graph, the path is marked as a "critical timing path," and the task with the longest delay in the path is identified as the bottleneck task. This analysis supports priority intervention and localization of dynamic scheduling strategies, i.e., prioritizing the adjustment of the sampling frequency or execution mechanism of bottleneck tasks to improve the rhythm consistency of the overall task chain.

[0156] Based on the analysis results, corresponding scheduling optimization strategies are implemented for task segments with inconsistent or significant deviations in timing, using the scheduling strategy library. These strategies include, but are not limited to:

[0157] ① Adaptive Sampling Rate (ARR) is suitable for devices where the sampling period can be adjusted. It proposes frequency adjustment suggestions based on the location and period parameters of the bottleneck task along the path. The processing logic is as follows: If the current sampling period of task T is X, and the execution delay of the upstream task is Y, and the target coordination window is Z: if X > ZY, then it is recommended to adjust X to ZY. This method can coordinate task rhythm within the parameter range allowed by the device.

[0158] ② Edge caching and latency tolerance configuration: If a device cannot sample frequently but has edge caching and data timing marking capabilities, a caching strategy can be enabled to temporarily store multiple sampled data entries and upload them uniformly within a reasonable time window to simulate near real-time behavior. The cache refresh cycle and upload batch processing time are adjustable parameters, and the strategy combination is set according to the task's buffer tolerance.

[0159] ③ Data fusion rearrangement and time window alignment: For multiple asynchronous tasks that are simultaneously used as input to a certain aggregation task (such as a summary analysis node), fusion processing will be performed before data access, including: time alignment of data collected in different time periods; missing data imputation (such as linear interpolation, previous value filling); dynamic configuration of asynchronous merging window size; this strategy is suitable for scenarios in complex data dependency structures that avoid "first data delay dragging down the entire process".

[0160] The scheduling and execution module is responsible for analyzing the rhythm coordination during the parallel execution of multiple tasks based on the adapted logical network graph, quantifying the risk of timing deviations between tasks, and improving system-level collaborative efficiency through strategy scheduling. Before task execution, the module first extracts the key execution parameters of all sub-task nodes and their matching devices from the adapted logical network graph, including:

[0161] Sampling period (P): The interval between each sampling task of the device, in seconds or minutes;

[0162] Response time (R): The average time required for a device to complete data reporting from the moment a task is triggered;

[0163] Synchronization Capability Level (S): Indicates whether the device supports capabilities such as timestamp alignment and edge caching;

[0164] Maximum allowed update interval (I_max): Represents the longest window of time that a downstream subtask can tolerate before receiving data from the upstream.

[0165] Next, for each pair of subtask nodes (T1 to T2) with task dependencies, the probability of their clock inconsistency under the current device configuration is calculated to reflect the risk of the task chain losing synchronization during concurrent execution.

[0166] Calculate whether there is a risk of rhythm inconsistency on each task edge (i.e., task dependency path). The judgment logic is as follows: Let... The sampling period of the device matched for task T1; The response time of the device matched for task T1, and the maximum allowed data update interval for task T2. If If an edge is found to have a beat conflict, then that edge is considered to have a beat conflict. The number of conflicting edges is counted for all task edges in the entire graph. The total number of sides is The probability of inconsistent beats occurring is: The higher the value of this indicator, the higher the risk of scheduling out-of-sync in the system, and the more powerful the scheduling strategy needs to be implemented to intervene.

[0167] By further combining the coordination level of each task edge in the graph, different weights are assigned to beat conflict edges to construct a system-level coordination risk index. This is used as a priority reference for overall scheduling optimization. Each task edge is defined as follows: The corresponding coordination level weight is (For example, if high coordination has a weight of 1 and low coordination has a weight of 3), then the system-level risk index is calculated as follows:

[0168] This index reflects the risk intensity and concentration of all beat conflicts in the entire graph. It analyzes each task link path (i.e., the execution sequence that a task depends on) in the graph, cumulatively evaluates its total execution latency and compares it with the ideal synchronous path to identify the path with the largest timing deviation. Let a certain task path... The cumulative execution delay for the path is:

[0169] ,in, Indicates the first in the path The sampling period of the device matched to each task; Indicates the first in the path The response time of the device matched to each task. Let the execution time of the ideal synchronization path be: ,in The system recommends or uses the theoretically shortest sampling period. Therefore, the path timing deviation is: If the deviation value ranks in the top N96 of all paths, the path is identified as a "critical timing path", and the task node with the largest delay is the bottleneck task node, which should be prioritized for scheduling optimization.

[0170] After identifying the bottleneck task node and the task edge with a clock cycle conflict, the module executes the following scheduling strategy based on the built-in strategy library: if the device sampling period of the task node... Configurable, based on the downstream maximum update interval To address the deviation from the current rhythm, an optimization of the sampling period is proposed. The target is calculated as follows: ,like If the sampling period is less than the current sampling period, it is recommended to adjust it to meet the synchronization requirements. For devices that do not support high-frequency sampling but have caching capabilities, configure a reasonable cache refresh period to meet the needs of synchronous upload of task windows. For asynchronous task aggregation points, set the fusion window width and use methods such as timestamp alignment, interpolation compensation, and previous value padding to rearrange data and avoid delay propagation.

[0171] The scheduling execution module synchronously updates the following information to the adapted logical network graph: the sampling period and response time of each task node; the coordination status marker (e.g., "coordinated") and latency risk level of each edge; the scheduling adjustment version number (for subsequent analysis, rollback, and trend tracking); and if the strategy execution fails, it records the reason and suggested alternatives (e.g., equipment replacement suggestions, expanding the sampling window, etc.). Finally, all adjustment information is encapsulated into a scheduling status data packet and sent to the monitoring and early warning module, providing a basis for data window settings, dynamic adjustment of anomaly detection thresholds, and other processes.

[0172] After executing the scheduling strategy, the status identifiers of the corresponding task nodes and edges in the adaptation logic network graph will be updated, including: the adjusted sampling period and response time limit; the caching strategy activation flag; the beat coordination flag (whether the set synchronization window has been reached); the degree of latency risk mitigation (high to medium or medium to low); and the scheduling adjustment history and version number will be recorded for subsequent evaluation of the effect and trend of scheduling optimization.

[0173] The execution results of the scheduling strategy will be encapsulated into a structured status data packet and sent to the monitoring and early warning module to guide subsequent data access, anomaly detection window adjustment, and early warning threshold optimization. The data packet content includes: the final execution cycle configuration for all tasks; the type of scheduling strategy executed; the current overall cycle consistency score; and preprocessing suggestions for dealing with high-risk edges (such as increasing sampling frequency or switching to backup equipment). This process achieves a closed-loop control of "perception-evaluation-execution-feedback," providing an adaptive scheduling foundation for subsequent operation, as shown in the example below:

[0174] Task chain: T1 (rainfall monitoring) to T2 (water level acquisition) to T3 (flow calculation), D1 (T1 device) sampling period 10 minutes, response time 1 minute; D2 (T2 device) sampling period 6 minutes, response time 2 minutes; the maximum tolerance time interval between T2 and T1 is 7 minutes.

[0175] Discovery: Total delay of T1 = 11 minutes > 7 minutes, indicating a beat conflict.

[0176] Scheduling strategy: Reduce the D1 sampling period to 5 minutes, enable edge caching for uploading; and mark T1-T2 as coordinated.

[0177] 6) Based on coordinated execution, the monitoring and early warning module collects monitoring data uploaded by each device in real time, and uses a preset hydraulic model to perform streaming processing and multi-dimensional feature extraction on the data. It detects abnormal behavior of key parameters such as hydrology and water quality and makes a preliminary judgment on the level of abnormality. When a suspected abnormal event is detected (such as sudden flood, pollution spread, sudden change in flow, etc.), it triggers the corresponding early warning response strategy based on the established abnormality type library and rule model engine, issues alarm signals in a graded manner, and links relevant water conservancy control or management personnel.

[0178] The monitoring and early warning module, as the terminal response link in smart water conservancy monitoring and early warning, is a key functional module for realizing "proactive perception—intelligent identification—real-time alarm—coordinated response." After the scheduling and execution module completes multi-task coordination, this module undertakes a series of operations, including real-time streaming processing of data uploaded from equipment, abnormal behavior identification, risk level judgment, and triggering response strategies, ensuring rapid and accurate early warning capabilities in the face of sudden hydrological and water quality events. The entire processing flow includes the following steps:

[0179] The system receives monitoring data streams uploaded by various IoT devices via a data access bus, covering key water parameters such as water level, water quality, flow rate, and rainfall. All data packets have a unified format structure, including metadata such as timestamps, data type identifiers, spatial location codes, sampling accuracy, and device status. To ensure timely and accurate processing, a sliding time window mechanism is used for streaming batch processing of the data. The processing logic is as follows: a streaming processing window is set for each type of monitoring indicator (e.g., a batch every 5 minutes); a data sliding buffer is maintained, and data within each window is aggregated; missing data is identified through the device status field, and delayed data is reordered or discarded based on timestamps (depending on the rules); identical monitoring indicators from multiple sources will undergo fusion operations, such as average, maximum, or confidence-weighted merging strategies; this mechanism effectively supports continuous processing when data is updated frequently, avoiding early warning delays caused by batch processing.

[0180] After the data window is generated, the corresponding water resources model is loaded for different monitoring tasks, and the original data is reconstructed and multi-dimensional indicators are extracted. Model types include, but are not limited to:

[0181] Water level dynamic model: Identifies continuous upward trends, abnormal fluctuations, high-frequency interference, etc.

[0182] Velocity-water level coupling model: used to invert river flow and detect abrupt changes in flow regime;

[0183] Water quality index combination model: such as constructing a comprehensive pollution level index using pH, dissolved oxygen, conductivity, ammonia nitrogen, etc.;

[0184] Rainfall-inflow-reservoir water level linkage model: used to predict reservoir scheduling pressure or downstream risks;

[0185] The feature extraction processing logic is illustrated below: If the historical normal range of a certain indicator is A~B, the following processing is performed on N consecutive sampled values: calculate the mean μ and standard deviation σ. If the current value deviates from μ by more than σ×threshold, it is marked as a slight anomaly. If the deviation factor further increases and the trend continues to strengthen, it is upgraded to a moderate / severe anomaly. The trend judgment is based on the continuous positive / negative directionality of the first-order difference. For correlated indicators (such as flow velocity and water level), cointegration analysis or residual model is used to determine the degree of coupling deviation.

[0186] After extracting structured anomaly features, they are input into a pre-defined anomaly type knowledge base and rule model engine to match the current feature's manifestation with the corresponding anomaly event type and severity level. The anomaly type library includes historical labeled data, manually generated rules, and anomaly recognition models trained based on machine learning, covering, but not limited to: floods induced by heavy rain; sudden increases in reservoir sediment inflow; illegal sewage discharge; abrupt changes in water quality (such as excessive ammonia nitrogen / heavy metals); reservoir water level control failures; and multi-indicator combined anomalies. The recognition process logic is as follows:

[0187] Iterate through the threshold conditions, duration, and relationship rules between indicators defined for each anomaly type; if the current feature combination matches any type of condition in the rule set, record the matching level and confidence level; if multiple anomaly types are matched, output the highest level event in order of risk priority; the final output of the identification results includes information such as event type, associated location, start time, scope of impact, and preliminary severity level.

[0188] Once an identifiable anomaly is confirmed, the corresponding early warning and linkage mechanism will be activated according to the event-response strategy mapping rules defined in the anomaly type library. The response strategy includes: generating and pushing early warning information (SMS, platform notification, broadcast); activating relevant equipment (such as video surveillance, remote sampling); intervening with control equipment (such as pre-opening gates, switching to backup channels); and reporting to the command platform or automatically generating briefing documents for manual processing. Simultaneously, early warnings will be issued in tiers according to the severity level of the event, with the specific tiers as follows:

[0189] Level I (Red): Immediate manual intervention and control are required; may result in personal injury or significant property damage.

[0190] Level II (Orange): Moderate risk, with a window for intervention.

[0191] Level III (Yellow): Mild anomaly, requires continued observation or localized optimization.

[0192] Level IV (Blue): Notification event, only recorded and reported;

[0193] Alarms are issued using a standardized data packet with fields including: exception type, severity level, location, trigger time, recommended handling suggestions, and response status.

[0194] All identified and responded-to anomalies will be synchronously written to the log database for subsequent event tracking, early warning rule optimization, and scheduling strategy iteration. Simultaneously, the trigger time, response effect, and misjudgment rate of the anomaly can be compared during the actual execution and prediction phases to update model weights and optimize the identification strategy, forming a closed-loop self-evolutionary mechanism.

[0195] If an anomaly detection mistakenly identifies a sudden increase in flow velocity as a flood, but it is later confirmed to be caused by gate operation, then the false alarm is marked and the judgment weight of the relevant feature combination in the anomaly identification model is updated.

[0196] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0197] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A smart water conservancy monitoring and early warning system based on the Internet of Things, characterized in that: It includes a model building module, a data acquisition module, a matching analysis module, a graph generation module, a scheduling and execution module, and a monitoring and early warning module; Model building module: Divide the water conservancy objects to be monitored into task structures, identify the logical order and data dependencies between each monitoring sub-task, and build a task topology model for water conservancy monitoring; Data acquisition module: Acquires the cycle control attributes of IoT monitoring devices deployed at different water conservancy nodes; Matching Analysis Module: Based on the task topology model and cycle control attributes, analyze the matching relationship between each monitoring subtask and the equipment, and establish a framework for the adaptation mapping relationship between monitoring subtasks and equipment; The network graph generation module traverses the logical connections between each subtask and its adjacent subtasks in the task topology model, extracts the maximum data update interval threshold and data buffer tolerance flag between each pair of subtasks, where the maximum data update interval threshold represents the longest waiting time for a downstream task after receiving upstream data, exceeding this threshold is judged as an execution delay; the data buffer tolerance flag indicates whether a downstream task is allowed to receive delayed data or perform the most recent value filling, and tasks marked as unbufferable require strong synchronization; and generates an adaptation logical network graph between monitoring tasks and devices. The scheduling and execution module analyzes the probability of timing inconsistency in the current monitoring subtasks when they are executed in parallel on multiple devices based on the adaptive logical network graph. The calculation logic for the probability of timing inconsistency is as follows: For task pairs T1 to T2 and their corresponding devices D1 and D2, the following are defined: Total delay of D1 = Sampling period of D1 + Response time of D1, Execution window of D2 = Maximum allowable data update interval of T2. If the total delay of D1 > Execution window of D2, a potential timing conflict is considered to exist. The proportion of timing conflicts in all task edges is counted, and the probability of timing inconsistency = Number of conflicting edges / Total number of edges. The degree of timing deviation between each subtask is quantified, and the corresponding scheduling strategy is executed.

2. The smart water conservancy monitoring and early warning system based on the Internet of Things according to claim 1, characterized in that: The graph generation module traverses the logical connection relationships between each monitoring subtask node in the task topology model, identifies the data dependency edges between adjacent tasks, and extracts the maximum data update interval threshold and data buffer tolerance flag for each edge. Obtain the beat control attributes of the device matched by each subtask node from the adaptation mapping relationship framework; For each task-dependent edge, the coordination level and edge delay risk score of the sub-task edge are calculated by combining the attributes of the devices corresponding to the two sub-task nodes before and after it. The logic for obtaining the coordination level is as follows: calculate the sum of the sampling period and response time of the upstream subtask device, determine whether the sum of the sampling period and response time is less than the maximum data update interval allowed by the downstream subtask device, and determine whether the upstream and downstream subtask devices support synchronous upload or buffering mechanisms. The logic for obtaining the edge delay risk score is as follows: calculate the sum of the sampling period and response time of the upstream subtask device, then divide it by the maximum data update interval of the downstream task to obtain the risk ratio and then classify the risk level. Based on the subtask node information and edge attributes, an adaptation logic network graph representing the subtask execution logic is constructed.

3. The smart water conservancy monitoring and early warning system based on the Internet of Things according to claim 2, characterized in that: The graph generation module constructs an adaptation logic network graph representing the execution logic of the subtasks based on the subtask node information and edge attributes: In the adaptation logic network graph, nodes are used to represent monitoring subtask units and include task identifier, matching device identifier, synchronization capability level and execution priority; Edges are used to represent subtask dependencies and include a maximum data update interval threshold, a data buffer tolerance flag, a coordination level, and an edge latency risk score. The generated graph structure is encapsulated in a structured manner to form a data structure containing a list of nodes, a list of edges, and full graph statistical indicators.

4. The smart water conservancy monitoring and early warning system based on the Internet of Things according to claim 3, characterized in that: The scheduling and execution module obtains the execution parameters of the subtask nodes and their corresponding devices in the adaptation logical network graph, including the sampling period, response time, synchronization capability level, and the maximum allowed update interval of the subtask dependency edges. For each pair of dependent subtask nodes, calculate the probability of their rhythm inconsistency, and construct a system-level coordination risk index by weighting the coordination level of each side. Perform timing deviation analysis on all task paths, identify synchronous path task chains whose cumulative delay exceeds the theoretical delay, and identify the task node with the largest delay as the bottleneck task node. For bottleneck task nodes and their paths, perform scheduling optimization operations based on the policy library; The application results of the scheduling strategy are used to update the state attributes of the corresponding task nodes and task edges in the graph, including sampling period, response time, coordination status flag and delay risk level, and the adjustment version information is recorded.

5. The smart water conservancy monitoring and early warning system based on the Internet of Things according to claim 4, characterized in that: The scheduling strategy includes a dynamic sampling frequency adjustment strategy, an edge caching strategy, and a data fusion and rearrangement strategy, wherein... Dynamic sampling frequency adjustment strategy: Adjust the task sampling period according to the task rhythm requirements in the path to meet the synchronization requirements; Edge caching strategy: Enable the device's cache upload mechanism and configure the data batch upload window; Data fusion and rearrangement strategy: Time alignment, loss compensation, and window merging are performed on asynchronous data from multiple tasks.

6. The smart water conservancy monitoring and early warning system based on the Internet of Things according to claim 1, characterized in that: The matching analysis module obtains the execution requirements of each monitoring subtask in the task topology model. The execution requirements include the monitoring indicator type, sampling timeliness, temporal dependency with adjacent tasks, synchronization requirement level, and data buffer tolerance. Based on task indicators and the spatial region they belong to, a set of candidate devices that meet the monitoring capabilities and deployment scope is selected from the device attribute library; For each task and its candidate devices, adaptation metrics are calculated separately. These metrics include Time Synchronization Adaptability (TSA), Buffer Tolerance Adaptability (BTA), and Response Capability Adaptability (RCA). The Time Synchronization Adaptability (TSA) is used to evaluate whether the device's sampling period matches the task's synchronization window. If the device's sampling period is less than or equal to the task's maximum synchronization period requirement and the device supports synchronous upload, then TSA is high. If the device's sampling period is greater than the task's maximum synchronization period requirement and it has an edge caching mechanism, then TSA is medium. If the device's sampling period is greater than the task's maximum synchronization period requirement and it does not have an edge caching mechanism, then TSA is low. Buffer Tolerance (BTA) indicates the degree to which a task's tolerance for data latency / loss matches the device's communication mode. If the task allows for moderate buffer latency and the device supports breakpoint resumption or cached upload, then BTA = High; if the task does not tolerate latency and the device has no synchronization or buffering capabilities, then BTA = Low. Response capability adaptability (RCA) is used to evaluate whether the device response time meets the real-time requirements of the task. If the device response time is less than or equal to the maximum allowable response time of the task × 0.8, then RCA = High; if the device response time is greater than or equal to the maximum allowable response time of the task × 0.8, then RCA = Low. Based on the adaptation metrics, generate adaptation relationship items between tasks and devices, including task ID, device ID, various adaptation scores, comprehensive matching level, whether it is the preferred device, and scheduling status flags, and organize all adaptation items into an adaptation mapping relationship framework.

7. A smart water conservancy monitoring and early warning system based on the Internet of Things according to any one of claims 1-6, characterized in that: The monitoring and early warning module is used to collect monitoring data uploaded by each device in real time, and to perform streaming processing and multi-dimensional feature extraction on the data using a preset hydraulic model to detect abnormal behavior and preliminarily determine the level of abnormality. When an abnormal event is detected, the corresponding early warning response strategy is triggered based on the abnormality type library and rule model engine.

8. The smart water conservancy monitoring and early warning system based on the Internet of Things according to claim 7, characterized in that: The monitoring and early warning module receives real-time monitoring data streams uploaded by multi-source IoT monitoring devices, including parameters such as water level, water quality, flow rate, and rainfall. For various monitoring tasks, the corresponding water conservancy models are called to extract features from batches of data. The water conservancy models include water level dynamic model, flow velocity-water level coupling model, water quality pollution model, and rainfall-inflow-reservoir water level linkage model. Multidimensional anomaly features are extracted for each data window. The extracted structured feature vectors are input into the anomaly type knowledge base and rule model engine to match the defined anomaly event types and determine whether they meet the preset anomaly rule conditions, including univariate deviation, trend change, first-order difference directionality and multi-indicator coupling relationship. When an abnormal event is identified, the response strategy mapping rule is found according to the event type, an early warning response strategy is generated, and the strategy is triggered in stages according to the severity of the event.

Images