A distributed urban drainage monitoring method, system, device and medium

Abstract

The application provides a distributed urban drainage monitoring method, system, device and medium, relates to the technical field of urban drainage monitoring, and comprises the following steps: acquiring monitoring data of a plurality of monitoring nodes in a target drainage area; according to a topological connection relationship of an urban drainage pipe network, the monitoring nodes are divided into at least one local topological subnet; the number of local topological subnets is configured with a corresponding edge computing node; the edge computing node determines a first monitoring result based on the monitoring data of the monitoring nodes and corresponding standard monitoring data; if the first monitoring result is abnormal, the self-state of the monitoring node is pre-checked, if it is determined that the monitoring node has a self-fault, the monitoring data of the monitoring node is reported to a central cloud platform based on the edge computing node; if it is determined that the monitoring node has no self-fault, the monitoring node is marked as a suspected event node; a corresponding edge computing node triggers a distributed collaborative diagnosis process to obtain a second monitoring result and report the second monitoring result to the central cloud platform.

Description

Technical Field

[0001] This application relates to the field of urban drainage monitoring technology, and in particular to a distributed urban drainage monitoring method, system, equipment and medium. Background Technology

[0002] Currently, centralized monitoring technology is used in the field of urban drainage pipe network monitoring. This solution, designed to meet the need for unified overall management of the pipe network, deploys monitoring nodes at key locations such as main drainage pipes, critical inspection wells, and discharge outlets. These nodes continuously collect monitoring data on water level, flow rate, and water quality. All data collected from these nodes is transmitted back to a central cloud platform, which then performs centralized integration, calculation, and analysis according to preset rules, enabling unified identification, judgment, and early warning of pipe network anomalies. However, this solution, with its core approach of unified data transmission and centralized computation on the central cloud platform, faces significant challenges in large-scale pipe network monitoring scenarios. The massive data transmission consumes substantial communication bandwidth, and the centralized computation places a heavy computational load on the central cloud platform, potentially leading to data transmission congestion, prolonged analysis latency, and delayed anomaly response. Furthermore, distorted data from node failures enters the analysis process simultaneously, increasing the risk of misjudgments and missed anomalies, ultimately resulting in a simultaneous decline in both the efficiency and accuracy of the monitoring system.

[0003] Therefore, there is an urgent need for a distributed urban drainage monitoring method and system to improve the operational efficiency and accuracy of the drainage monitoring system, reduce communication bandwidth usage and computing power pressure on the central cloud platform, and improve the identification and response speed and judgment accuracy of abnormal events in the pipeline network. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a distributed urban drainage monitoring method, system, equipment, and medium.

[0005] A first aspect of this application provides a distributed urban drainage monitoring method, comprising:

[0006] Acquire monitoring data from multiple monitoring nodes in the target drainage area; the monitoring nodes include a first type of monitoring node and a second type of monitoring node, wherein the number of monitoring data types of the first type of monitoring node is greater than the number of monitoring data types of the second type of monitoring node;

[0007] Based on the topological connection relationship of the urban drainage pipe network, the monitoring nodes are divided into at least one local topological subnet; the number of local topological subnets is configured with corresponding edge computing nodes, and communication connections are established.

[0008] Each monitoring node determines its first monitoring result based on the monitoring data of the monitoring node and the corresponding standard monitoring data, using the edge computing nodes of its local topology subnet.

[0009] If the first monitoring result is abnormal, a self-state pre-check is performed on the monitoring node to determine whether it is a fault of the monitoring node itself.

[0010] If the fault is determined to be in the monitoring node itself, the monitoring data of the monitoring node will be reported to the central cloud platform based on the edge computing node.

[0011] If it is determined that the monitoring node has no fault of its own, then the monitoring node will be marked as a suspected event node;

[0012] In response to the appearance of a suspected event node in any local topology subnet, the corresponding edge computing node triggers the execution of a distributed collaborative diagnostic process to obtain a second monitoring result and report it to the central cloud platform.

[0013] A second aspect of this application provides a distributed urban drainage monitoring system, comprising:

[0014] The data acquisition module is used to acquire monitoring data from multiple monitoring nodes in the target drainage area. The monitoring nodes include a first type of monitoring node and a second type of monitoring node, wherein the number of monitoring data types of the first type of monitoring node is greater than the number of monitoring data types of the second type of monitoring node.

[0015] The topology partitioning module is used to divide the monitoring nodes into at least one local topology subnet based on the topological connection relationship of the urban drainage pipe network.

[0016] Edge computing nodes are configured to correspond to the number of local topology subnets and establish communication connections; each edge computing node is used to determine the first monitoring result for each monitoring node in its local topology subnet based on the monitoring data of that monitoring node and the corresponding standard monitoring data.

[0017] The status pre-inspection module is used to perform a status pre-inspection on the monitoring node if the first monitoring result is abnormal, and to determine whether the fault is caused by the monitoring node itself.

[0018] The data reporting module is used to report the monitoring data of the monitoring node to the central cloud platform based on the edge computing node if the fault is determined to be the fault of the monitoring node itself.

[0019] The event node marking module is used to mark a monitoring node as a suspected event node if it is determined that the monitoring node has no fault of its own.

[0020] The distributed collaborative diagnosis module is used to respond to the occurrence of a suspected event node in any local topology subnet. The corresponding edge computing node triggers the execution of the distributed collaborative diagnosis process, obtains the second monitoring result, and reports it to the central cloud platform.

[0021] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described distributed urban drainage monitoring method.

[0022] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described distributed urban drainage monitoring method.

[0023] The beneficial effects of the distributed urban drainage monitoring method, system, equipment, and medium provided in this application are as follows: This application divides monitoring nodes into two categories with different data types and quantities, divides local topology subnets based on the pipeline network topology, and configures corresponding edge computing nodes to achieve distributed processing of monitoring data. Edge computing nodes first determine the initial monitoring result based on monitoring data and standard data. In case of anomalies, they first perform a pre-check of their own node status, distinguishing between node faults and suspected event nodes. Suspected events trigger distributed collaborative diagnosis before reporting the results. This application's combination of hierarchical processing and fault pre-check reduces invalid data reporting, and the distributed deployment of edge computing reduces the computing power pressure on the central cloud platform. Simultaneously, by distinguishing between faults and events, the accuracy of monitoring results is improved, avoiding misjudging node faults as drainage anomalies, thus enhancing the reliability and efficiency of drainage monitoring. Attached Figure Description

[0024] Figure 1 A schematic flowchart of a distributed urban drainage monitoring method provided in an embodiment of this application;

[0025] Figure 2 This is a structural block diagram of a distributed urban drainage monitoring system provided in one embodiment of this application;

[0026] Figure 3 This is a schematic block diagram of an electronic device provided in an embodiment of this application.

[0027] The attached diagram is labeled as follows:

[0028] 20. Distributed urban drainage monitoring system; 21. Data acquisition module; 22. Topology partitioning module; 23. Edge computing node; 24. Status pre-inspection module; 25. Data reporting module; 26. Event node marking module; 27. Distributed collaborative diagnosis module;

[0029] 300. Electronic device; 301. Processor; 302. Input device; 303. Output device; 304. Memory; 305. Communication bus. Detailed Implementation

[0030] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0031] To make the purpose, technical solution, and advantages of this application clearer, the following will be described in conjunction with the appendix. Figure 1-3 The following is an explanation using specific examples.

[0032] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a distributed urban drainage monitoring method provided in an embodiment of this application. The method includes:

[0033] S101: Acquire monitoring data from multiple monitoring nodes in the target drainage area; the monitoring nodes include a first type of monitoring node and a second type of monitoring node, wherein the number of monitoring data types of the first type of monitoring node is greater than the number of monitoring data types of the second type of monitoring node.

[0034] In this embodiment, real-time data collected by multiple monitoring nodes deployed within the target drainage area is acquired. The monitoring nodes are divided into two categories: the first category of monitoring nodes is deployed in key sections of the pipeline network and key areas prone to water accumulation or pollution, collecting various types of monitoring data such as water volume, water level, flow velocity, and water quality (e.g., COD, ammonia nitrogen), providing comprehensive data support for the accurate diagnosis of abnormal events; the second category of monitoring nodes serves as auxiliary monitoring points, deployed in secondary sections of the pipeline network, collecting only basic data such as water volume and water level, to achieve comprehensive monitoring coverage and reduce overall deployment costs. The two types of nodes work together to form a monitoring network with full coverage and key focus.

[0035] S102: Based on the topological connection relationship of the urban drainage pipe network, the monitoring nodes are divided into at least one local topological subnet; for each local topological subnet, a corresponding edge computing node is configured and a communication connection is established.

[0036] In this embodiment, based on data acquisition and combined with the topological connections of the urban drainage network, all monitoring nodes are divided into at least one local topological subnet. The urban drainage network refers to the collective term for the pipeline system and ancillary facilities within the city limits used for collecting, transporting, treating, and discharging rainwater and sewage. The topological connections refer to the logical relationships of connection methods, locational relationships, and water flow directions among the pipes and monitoring nodes in the drainage network. Each local topological subnet, divided according to the network's topological connections, comprises an independent area containing several monitoring nodes. Monitoring nodes within each local topological subnet belong to the same network branch or adjacent areas. This division in this embodiment is not random but strictly follows the water flow direction and pipe connections of the network, ensuring that monitoring nodes within each local topological subnet belong to the same network branch or adjacent areas, facilitating subsequent collaborative diagnosis.

[0037] This embodiment also configures corresponding edge computing nodes for each subnet according to the number of local topology subnets and establishes stable communication connections. The edge computing nodes are deployed near the local topology subnets and are computing devices with the ability to collect, process and analyze data nearby, in order to reduce data transmission latency and reduce cloud computing pressure.

[0038] S103: For each monitoring node, the edge computing node of its local topology subnet determines the first monitoring result based on the monitoring data of the monitoring node and the corresponding standard monitoring data.

[0039] In this embodiment, the preliminary diagnosis of monitoring data is independently completed by the edge computing nodes of each local topology subnet. The monitoring data collected by each monitoring node is transmitted to the edge computing node of its local topology subnet. The edge computing node compares and analyzes the monitoring data with preset standard monitoring data. The standard monitoring data is dynamically calibrated based on factors such as the location of the monitoring node in the pipeline network, seasonal changes, and daily operating conditions, and is used as a benchmark to determine whether the monitoring data is normal. The standard monitoring data is compiled by the edge computing node periodically by statistically analyzing the data distribution of the monitoring node under historical normal operating conditions, taking the mean or median of each monitoring data type as the benchmark value, and updating it quarterly according to seasonal changes (such as flood season and non-flood season) and changes in pipeline operating status.

[0040] Through comparative analysis, the edge computing node determines the first monitoring result. The first monitoring result is a preliminary judgment result (normal or abnormal) of whether the monitoring node's data is within the normal range after the edge computing node compares the monitoring data collected by the monitoring node with the standard monitoring data. That is, it determines whether the data collected by the monitoring node is within the normal range. If the data is within the standard range, it is judged as normal; if it exceeds the standard range, it is judged as abnormal.

[0041] S104: If the first monitoring result is abnormal, perform a self-state pre-check on the monitoring node to determine whether it is a fault of the monitoring node itself.

[0042] In this embodiment, for cases where the first monitoring result is abnormal, it is necessary to first rule out interference from the monitoring node's own faults to avoid misjudging equipment failures as pipeline network anomalies. Here, a monitoring node's own fault refers to a situation where the data collected is distorted or abnormal due to problems with the monitoring node itself, such as power outages, communication link failures, sensor damage, or abnormal sensitivity.

[0043] Edge computing nodes will perform a self-state pre-check on abnormal monitoring nodes, checking indicators such as the power supply status, communication link, and sensor sensitivity of the monitoring nodes to determine whether the data abnormality is caused by a fault in the monitoring node itself.

[0044] S105: If the fault is determined to be in the monitoring node itself, the monitoring data of the monitoring node will be reported to the central cloud platform based on the edge computing node.

[0045] In this embodiment, if the pre-inspection confirms that the fault is caused by the node itself, the edge computing node will promptly report the node's monitoring data and fault status information to the central cloud platform. The central cloud platform is a cloud management platform used to manage all local topology subnets, edge computing nodes and monitoring data, receive reported information, perform global analysis and issue disposal instructions. The cloud platform coordinates the maintenance personnel to carry out repairs and replacements to ensure the integrity of the monitoring network.

[0046] S106: If it is determined that the monitoring node has no fault of its own, then the monitoring node will be marked as a suspected event node.

[0047] In this embodiment, if the pre-inspection determines that the monitoring node has no fault of its own, it means that the abnormal data originates from the abnormality of the pipeline network itself (water accumulation, blockage, pollution, etc.). At this time, the monitoring node is marked as a suspected event node. The suspected event node is the monitoring node that has been confirmed by the pre-inspection of its own status to have no equipment fault, but its monitoring data is abnormal, corresponding to the monitoring node of the pipeline network abnormal event.

[0048] S107: In response to the appearance of a suspected event node in any local topology subnet, the corresponding edge computing node triggers the execution of a distributed collaborative diagnostic process to obtain a second monitoring result and report it to the central cloud platform.

[0049] In this embodiment, when a suspected event node appears within any local topology subnet, the corresponding edge computing node immediately triggers a distributed collaborative diagnostic process. This distributed collaborative diagnostic process, triggered by the edge computing node, performs multi-monitoring node, multi-dimensional collaborative analysis based on the suspected event node and its surrounding related nodes, as well as the pipeline topology relationship, to ultimately determine a standardized process for the details of the pipeline abnormal event, thus achieving accurate judgment of abnormal events.

[0050] Unlike independent judgments from a single node, distributed collaborative diagnosis utilizes multi-dimensional, multi-node collaborative analysis based on surrounding monitoring data and pipeline topology information of the suspected event node to ultimately obtain a second monitoring result. This second monitoring result, derived through distributed collaborative diagnosis, provides a final judgment on the specific type, scope of impact, and severity of the pipeline anomaly event. It clarifies the specific type, scope of impact, and severity of the anomaly event before reporting it to the central cloud platform. The central cloud platform receives the information reported by each edge computing node, performs global aggregation, and provides decision-making support to urban drainage management departments, facilitating timely response measures and reducing the risks of urban flooding and water pollution caused by drainage anomalies.

[0051] As can be seen from the above, this application categorizes monitoring nodes into two types with different data types and quantities. It also divides local topology subnets based on the pipeline network topology and configures corresponding edge computing nodes to achieve distributed processing of monitoring data. Edge computing nodes first determine the initial monitoring result based on monitoring data and standard data. In case of anomalies, they first perform a pre-check of their own status, distinguishing between node faults and suspected event nodes. Suspected events trigger distributed collaborative diagnosis before reporting the results. This application's combination of hierarchical processing and fault pre-check reduces invalid data reporting. The distributed deployment of edge computing reduces the computing power pressure on the central cloud platform. Simultaneously, by distinguishing between faults and events, the accuracy of monitoring results is improved, avoiding misjudging node faults as drainage anomalies, thus enhancing the reliability and efficiency of drainage monitoring.

[0052] In one embodiment of this application, the distributed collaborative diagnostic process includes:

[0053] Based on the pipeline network topology, identify the upstream and downstream associated monitoring nodes of suspected event nodes;

[0054] The monitoring data of upstream and downstream related monitoring nodes are evaluated for quality to obtain a data quality score. If the data quality score is less than or equal to the first preset quality threshold, compensation calculation is performed using historical data pattern matching or monitoring data of adjacent non-directly related monitoring nodes. If the diagnostic conditions are still not met after compensation, the collaborative diagnosis process is terminated, and the monitoring data of the suspected event node and the first monitoring result are reported to the central cloud platform.

[0055] If the data quality score is greater than the first preset quality threshold and less than or equal to the second preset quality threshold, the search range of upstream and downstream related monitoring nodes will be expanded, and then the subsequent diagnostic process will be executed.

[0056] If the data quality score is greater than the second preset quality threshold, and the suspected event node is a first-class monitoring node, then a second monitoring result is generated based on the monitoring data of upstream and downstream related monitoring nodes, the monitoring data of the suspected event node, and the topological relationship of the local topology subnet.

[0057] If the data quality score is greater than the second preset quality threshold, and the suspected event node is a second type of monitoring node, then the monitoring data of the suspected event node and the monitoring data of the upstream and downstream related monitoring nodes are comprehensively analyzed using the preset correlation analysis rules to generate a second monitoring result.

[0058] The second threshold is greater than the first threshold. The first preset quality threshold is used as the minimum standard for determining whether the data is acceptable, and the second preset quality threshold is used as the standard for determining whether the data is excellent and can be directly used for diagnosis.

[0059] In this embodiment, upstream and downstream associated monitoring nodes of suspected event nodes are obtained based on the topological connection relationship of the urban drainage pipe network. The upstream and downstream associated monitoring nodes are directly or indirectly connected to the suspected event nodes based on the pipe network topology and water flow direction, and are monitoring nodes that characterize the operating status of the pipe network around the suspected event nodes. This embodiment constructs a basic network for multi-node collaborative analysis around the suspected event nodes.

[0060] After acquiring upstream and downstream related monitoring nodes, the monitoring data is first assessed for quality. This assessment revolves around four dimensions: data completeness, real-time performance, accuracy, and consistency. Specifically, data completeness refers to the integrity of the monitoring data, determining whether there are missing or disconnected data. Data real-time performance refers to the timeliness of data transmission from acquisition to edge computing nodes, assessing whether data transmission latency is within acceptable limits. Data accuracy refers to the degree of consistency between the monitoring data and the actual operating status of the pipeline network, detecting whether the data deviates from a reasonable fluctuation range. Data consistency refers to the logical matching degree of monitoring data from adjacent related nodes within the same time period, quantified by calculating the Pearson correlation coefficient or mean absolute error of the monitoring data between suspected event nodes and upstream and downstream related monitoring nodes within a preset time window; a higher correlation coefficient or smaller error results in a higher consistency score.

[0061] This embodiment quantifies the monitoring data of upstream and downstream related monitoring nodes through multi-dimensional evaluation to obtain a data quality score. The data quality score refers to the score that quantifies the reliability of the monitoring data through multi-dimensional data quality evaluation. The higher the score, the more reliable the data. The higher the data quality score, the more reliable the monitoring data of upstream and downstream related monitoring nodes.

[0062] The first preset quality threshold is the minimum acceptable score for monitoring data quality. Monitoring data below this threshold is of extremely poor quality and cannot be directly used for diagnosis. The second preset quality threshold is the cutoff for good monitoring data quality. Data above this threshold is of excellent quality and can be directly used for diagnosis. The first and second preset quality thresholds are not fixed values ​​but are dynamically determined based on the historical monitoring data distribution of each local topology subnet, always ensuring that the second threshold is greater than the first threshold. Specifically, edge computing nodes periodically calculate the data quality score distribution of all monitoring nodes within their subnet under historical normal operating conditions. The score value corresponding to the bottom 10%-20% quantile is used as the first preset quality threshold, and the score value corresponding to the top 30%-40% quantile is used as the second preset quality threshold. When the subnet operating conditions change significantly (such as pipeline renovation or the addition of new monitoring nodes), the edge computing nodes automatically trigger threshold recalibration to ensure that the quality assessment standards are adapted to the actual state of the pipeline network.

[0063] If the data quality score is less than or equal to the first preset quality threshold, it indicates that the monitoring data quality of the current upstream and downstream related nodes is poor (with a large number of missing data and excessive data deviation), and cannot be directly used for collaborative diagnosis. In this case, compensation calculation is required to supplement the data. Among them, historical data pattern matching refers to retrieving historical monitoring data of similar operating conditions and similar time periods from the local topology subnet to which the suspected event node belongs, and supplementing missing data and calibrating abnormal data through pattern comparison. The monitoring data of adjacent non-directly related monitoring nodes (i.e., monitoring nodes that are not directly connected to the suspected event node but belong to the same local topology subnet) are also compensated. If the quality of the monitoring data still does not meet the diagnostic conditions required for collaborative diagnosis after compensation calculation, the current collaborative diagnosis process is terminated, and the original monitoring data of the suspected event node and the first monitoring result are reported to the central cloud platform for further analysis and handling by the central cloud platform and experts.

[0064] The diagnostic criteria refer to the minimum data integrity requirements to support effective collaborative diagnosis, specifically including three sub-criteria: the number of valid associated nodes is no less than 80% of the minimum number of diagnostic nodes; the missing rate of monitored data types (at least water volume and water level for Category I nodes, and at least water volume for Category II nodes) does not exceed 20%; and the average data quality score is no lower than the first preset quality threshold. All three sub-criteria must be met simultaneously to be considered as meeting the diagnostic criteria. These three sub-criteria are determined based on statistical analysis of historical successful diagnostic cases using edge computing nodes. All cases that successfully completed collaborative diagnosis and received on-site verification within the past year are statistically analyzed, and the 25th percentile of each indicator among successful cases is taken as the minimum requirement.

[0065] If the data quality score is greater than the first preset quality threshold and less than or equal to the second preset quality threshold, the search scope of upstream and downstream related monitoring nodes is expanded. This expansion process extends further upstream and downstream along the pipeline topology, breaking through the limitations of the initial search, incorporating more monitoring nodes that are not directly connected but belong to the same pipeline branch, supplementing more monitoring data, improving data richness and reliability, and then continuing the subsequent collaborative diagnostic process to improve the accuracy of the diagnostic results.

[0066] If the data quality score is greater than the second preset quality threshold, a second monitoring result needs to be generated based on the type of suspected event node using the corresponding diagnostic method. Specifically, if the suspected event node is a first-type monitoring node, the second monitoring result is generated by multi-dimensional fusion analysis based on the monitoring data of upstream and downstream related monitoring nodes, the multiple types of monitoring data of the suspected event node itself, and the topological connection relationships of the local topological subnet. If the suspected event node is a second-type monitoring node, the first step is to attempt to obtain first-type monitoring nodes with direct topological association with the suspected event node and a data quality score greater than the second preset quality threshold as full-scale association reference nodes. Data expansion is then performed to expand the second-type monitoring nodes to the data dimensions of first-type monitoring nodes. Based on the expanded full-scale monitoring data, the second monitoring result is generated using the same collaborative diagnostic logic as for first-type monitoring nodes. If a full-scale association reference node that meets the conditions cannot be obtained, the second monitoring result is generated by comprehensively comparing and logically analyzing the basic monitoring data of the suspected event node and its upstream and downstream related nodes based on preset association analysis rules. This ensures that the diagnosis of different types of nodes is tailored to their data characteristics, improving the accuracy of the diagnosis. The association analysis rules are a set of pre-defined rules used to analyze the logical relationship and matching degree between suspected event nodes and related node data, including data type mapping and logical operation conditions.

[0067] If the data quality score is greater than the second preset quality threshold, and the suspected event node is a second-type monitoring node, the edge computing node performs a data augmentation operation. Specifically, the edge computing node obtains first-type monitoring nodes that have a direct topological association with the second-type suspected event node and whose data quality score is greater than the second preset quality threshold, as full-scale association reference nodes. Based on the historical monitoring data of each full-scale association reference node, the edge computing node establishes a mapping relationship between simplified monitoring data and full-scale monitoring data, which is constructed using a linear regression method. Using the mapping relationship of each full-scale association reference node, combined with the current simplified monitoring data of the second-type suspected event node, the edge computing node reverse-engineers its missing full-scale monitoring data, obtaining multiple target full-scale data estimates. The edge computing node determines the weights based on the pipeline distance between each full-scale association reference node and the second-type suspected event node, and performs a weighted summation of each target full-scale data estimate to obtain the final full-scale monitoring data. Based on the augmented full-scale monitoring data, the edge computing node generates a second monitoring result using the same collaborative diagnostic logic as the first-type monitoring node.

[0068] For example, the edge computing node acquires first-class monitoring nodes that have a direct topological association with the second-class suspected event node and whose data quality score is greater than a second preset quality threshold, as full-data association reference nodes. Based on the historical monitoring data of each full-data association reference node, the edge computing node establishes a mapping relationship between simplified monitoring data (such as water volume and water level) and full-data monitoring data (such as COD, ammonia nitrogen, and flow rate), constructed using a linear regression method. Using the mapping relationship of each full-data association reference node, combined with the current simplified monitoring data of the second-class suspected event node, the edge computing node reverse-engineers its missing full-data, obtaining multiple target full-data estimates. The edge computing node determines the weights based on the pipeline distance between each full-data association reference node and the second-class suspected event node, with closer nodes having higher weights. The target full-data estimates are then weighted and summed to obtain the final full-data. Subsequently, based on the expanded full-data, the edge computing node generates a second monitoring result using the same collaborative diagnostic logic (such as water balance analysis and abnormal propagation path identification) as the first-class monitoring node. Simultaneously, edge computing nodes calculate the goodness of fit for each mapping relationship. If the goodness of fit for all mapping relationships is lower than the preset goodness of fit threshold, the confidence level of the data augmentation result is reduced, and a low-confidence augmentation marker is attached when reporting the second monitoring result for review by the central cloud platform or operations and maintenance personnel. The goodness of fit threshold is dynamically determined based on the distribution of goodness of fit of historical mapping relationships between all first-type and second-type monitoring nodes within the local topology subnet. The 70th percentile of the historical mapping relationship goodness of fit sample set is used as the base threshold, and it is adjusted upwards or downwards according to the importance of the region where the suspected event node is located. The edge computing nodes update the goodness of fit threshold quarterly.

[0069] If there are significant contradictions between the expanded data and the data of upstream and downstream related nodes, the system will still revert to the preset correlation analysis rules for diagnosis, and the expansion process and contradiction information will be reported to the central cloud platform.

[0070] As can be seen from the above, the distributed collaborative diagnosis process of this application first obtains the upstream and downstream related nodes of the suspected event node and performs data quality assessment. Based on different quality scores, a differentiated processing strategy is adopted: when the data quality score is less than or equal to a first preset quality threshold, data compensation or termination of diagnosis is performed; when the data quality score is greater than the first preset quality threshold and less than or equal to a second preset quality threshold, the search range is expanded; when the data quality score is greater than the second preset quality threshold, a second monitoring result is generated based on the node type using a corresponding analysis method. The differentiated processing method for different data quality scores used in this embodiment avoids the impact of low-quality data on diagnostic accuracy, maximizes the use of effective data through data compensation and range expansion, and employs different analysis logics for the characteristics of the two types of monitoring nodes, improving the targeting and accuracy of collaborative diagnosis and enabling reasonable determination of abnormal events.

[0071] In one embodiment of this application, based on the pipeline network topology, the upstream and downstream associated monitoring nodes of a suspected event node are obtained, including:

[0072] Based on a directed graph model with local topological subnets, a topological search is performed upstream and downstream of suspected event nodes along the water flow direction to determine at least one initial associated node.

[0073] Based on preset data validity rules, the monitoring data of the initial associated nodes are evaluated for quality to obtain a quality score; the initial associated nodes with a quality score lower than the preset participation diagnostic threshold are removed to obtain the first set of associated nodes; wherein, the participation diagnostic threshold is used to screen the minimum data quality requirements that can be included in the effective set of associated nodes; the first preset quality threshold ≤ participation diagnostic threshold ≤ second preset quality threshold;

[0074] The first set of associated nodes is processed to obtain the set of effective associated nodes, which includes at least one upstream and downstream associated monitoring node.

[0075] In this embodiment, the upstream and downstream associated monitoring nodes of suspected event nodes are obtained based on the pipeline network topology relationship. This requires the use of a directed graph model of the local topology subnet. The directed graph model is a logical model that pre-stores information such as the water flow direction, pipeline connection method, and node distribution location within the local topology subnet. Nodes represent monitoring nodes, and directed edges represent the water flow direction and pipeline connection relationship.

[0076] During the acquisition process, it is necessary to trace the monitoring nodes upstream from the suspected event node along the direction of water flow, and extend the monitoring nodes downstream to the direction of water flow, and screen out the upstream and downstream related monitoring nodes that are directly connected to or adjacent to the suspected event node.

[0077] After acquiring and filtering upstream and downstream related monitoring nodes, the first set of related nodes is further processed to obtain the effective set of related nodes. The first set of related nodes is the set of nodes remaining after the data quality assessment of the initially screened upstream and downstream related monitoring nodes is completed and nodes that do not meet the quality standards are removed. The effective set of related nodes is the final set of related nodes determined after the first set of related nodes is verified in terms of quantity and dynamically expanded.

[0078] Based on the preset data validity rules, the monitoring data of the initial associated nodes are evaluated to obtain a quality score. The data validity rules are consistent with the evaluation dimensions of the subsequent data quality scores. The initial associated nodes with quality scores lower than the preset diagnostic threshold are removed, and the remaining nodes form the first associated node set.

[0079] The participation threshold for diagnosis is dynamically set based on the historical data quality score distribution of monitoring nodes within the local topology subnet and the diagnostic reliability requirements. Specifically, the edge computing node uses the average data quality score of all monitoring nodes within the subnet during their historical normal operation as a benchmark, multiplied by a preset reliability coefficient to obtain the initial participation threshold for diagnosis. This threshold is further adjusted based on the redundancy of monitoring nodes within the subnet: when the density of monitoring nodes within the subnet is high and the redundancy is large, the participation threshold for diagnosis is increased to eliminate more low-quality data; when the monitoring nodes within the subnet are sparse, the participation threshold for diagnosis is decreased to ensure the number of effective nodes. The edge computing node recalculates and updates this participation threshold for diagnosis every quarter or when the subnet topology changes.

[0080] The specific value of the reliability coefficient is determined by the edge computing node based on the historical failure rate and data integrity rate of the monitoring nodes within the subnet: Reliability coefficient = 0.5 × (1 - historical failure rate) + 0.5 × historical data integrity rate; where the historical failure rate is the proportion of the cumulative duration of data anomalies caused by the monitoring nodes of the subnet due to their own failures in the past year to the total running time, and the historical data integrity rate is the ratio of the actual amount of data returned by all monitoring nodes of the subnet in the past year to the theoretical amount of data that should be returned.

[0081] As can be seen from the above, this application searches for initial associated nodes of suspected event nodes based on a directed graph model of a local topology subnet. Then, it performs a quality assessment of the initial nodes using preset data validity rules and removes low-quality monitoring nodes, obtaining a first set of associated nodes. Further processing yields a set of valid associated nodes. The directed graph model ensures that the search for associated nodes aligns with the water flow direction and conforms to the operational rules of the drainage network. Data quality assessment removes invalid monitoring nodes, avoiding interference from low-quality data in the diagnosis. The process of selecting the set of valid associated nodes ensures the reliability and reasonable quantity of node data participating in collaborative diagnosis, further providing high-quality node data and improving the stability of the diagnostic foundation.

[0082] In one embodiment of this application, the first set of associated nodes is processed to obtain a valid set of associated nodes, including:

[0083] Determine whether the first set of associated nodes meets the preset minimum number of diagnostic nodes requirement;

[0084] If the conditions are met, the first set of associated nodes will be determined as the effective set of associated nodes participating in collaborative diagnosis.

[0085] If the conditions are not met, the first-level topology connection relationship is expanded outward along the direction of water flow based on the directed graph model. The newly searched monitoring nodes are added as new associated nodes, and the data quality assessment and judgment steps are repeated until the minimum number of diagnostic nodes is not exceeded and the cumulative number of expansions is not greater than the preset maximum number of nodes, or the number of expansions reaches the preset maximum tracing depth. The finally obtained associated nodes are taken as the effective associated node set.

[0086] If the conditions are still not met after expansion, the expansion is terminated, and the currently obtained associated nodes are taken as the set of valid associated nodes.

[0087] In this embodiment, it is determined whether the first set of associated nodes meets the preset minimum number of diagnostic nodes requirement. This minimum number of diagnostic nodes is preset based on the accuracy requirements of collaborative diagnosis and is determined according to the type of suspected event nodes and the complexity of the pipeline network. For example, for the first type of suspected event nodes in the core area, the minimum number of diagnostic nodes is set to 3-5, and for the second type of suspected event nodes in the auxiliary area, the minimum number of diagnostic nodes is set to 2-3.

[0088] To further enhance the robustness of diagnosis, this embodiment introduces a dynamic adjustment mechanism for edge computing nodes, based on a preset minimum number of diagnostic nodes. When the historical fluctuations of monitoring data in the area where a suspected event node is located are significant (measured by the ratio of the data standard deviation to the mean, with a fluctuation coefficient greater than 0.3), the minimum number of diagnostic nodes increases by 20%-30%. When the historical incidence of abnormal events in the area is high, the minimum number of diagnostic nodes automatically increases by 10%-20%. Conversely, for areas with long-term stable operation, the minimum number of diagnostic nodes decreases by 10% to optimize the efficiency of computing resource utilization. This dynamic adjustment mechanism is executed by the edge computing nodes based on statistical analysis of the subnet's historical operating data.

[0089] If the number of nodes in the first associated node set meets the preset minimum number of diagnostic nodes, it means that the current number of associated nodes is sufficient to support collaborative diagnosis. No additional operation is required, and the first associated node set is directly determined as the effective associated node set for participating in collaborative diagnosis.

[0090] If the number of nodes in the first set of associated nodes is less than the preset minimum number of diagnostic nodes, then it is necessary to expand the first-level topological connection relationship outward along the water flow direction based on the directed graph model of the local topological subnet. This first-level topological connection relationship is the pipeline connection relationship directly connected to the suspected event node or the screened associated node. That is, it goes beyond the initial range of directly associated nodes and extends the search further upstream and downstream, adding monitoring nodes that are indirectly connected to the suspected event node but belong to the same pipeline branch, thus expanding the number of upstream and downstream associated nodes.

[0091] After expansion, a data quality assessment step needs to be performed again on the newly added upstream and downstream related nodes to remove those with substandard data quality and update the first set of related nodes. After the update, it is determined whether the number of nodes meets the minimum number of diagnostic nodes requirement. If it does, the updated first set of related nodes is considered a valid set of related nodes; if it still does not meet the requirement, the above expansion, assessment, and judgment steps are repeated until the number of upstream and downstream related nodes meets the requirement or the preset maximum number of expansions is reached. This maximum number of expansions is a preset upper limit for node expansion to avoid unlimited expansion of related nodes and affecting diagnostic efficiency.

[0092] If the number of nodes in the first associated node set still does not meet the minimum number of diagnostic nodes after reaching the preset maximum number of expansions, the current collaborative diagnostic process will be terminated. The edge computing nodes will then report the monitoring data of the suspected event nodes, the first monitoring results, and the explanation that the number of nodes is insufficient for diagnosis to the central cloud platform. Experts will then conduct a comprehensive analysis and make further judgments based on global data. Alternatively, maintenance personnel may be arranged to investigate the node deployment in the area, supplement monitoring nodes, and improve the monitoring network.

[0093] As can be seen from the above, this application first determines whether the first set of associated nodes meets the minimum number of diagnostic nodes requirement. If it does, it is directly used as a valid set; otherwise, it expands along the topology direction and repeats the quality assessment and judgment until the requirement is met or the constraint condition is reached. The dynamic expansion mechanism of this embodiment not only ensures the minimum number of nodes required for collaborative diagnosis, ensuring sufficient data support for diagnosis, but also avoids reduced diagnostic efficiency and resource waste caused by excessive expansion by limiting the expansion boundary and number of expansions. At the same time, it uses the finally obtained associated nodes as a valid set, balancing diagnostic accuracy and efficiency, and avoiding diagnostic bias caused by insufficient number of nodes.

[0094] In one embodiment of this application, a distributed urban drainage monitoring method further includes:

[0095] The correlation coefficients between suspected event nodes and their upstream and downstream monitoring nodes are calculated in advance based on historical monitoring data and updated regularly.

[0096] The direction of the monitoring node whose absolute value of the correlation coefficient is greater than the preset correlation threshold is determined as the priority expansion direction. Priority search is performed in the priority expansion direction until the number of associated nodes in the priority expansion direction reaches the preset minimum number requirement of the priority expansion direction, and then the other direction is expanded.

[0097] If the absolute values ​​of the correlation coefficients in both directions are less than the preset correlation threshold, the hydraulic gradients in the upstream and downstream directions of the suspected event node are calculated based on the hydraulic model of the local topology subnet. The system is then expanded in the direction with the larger hydraulic gradient until the number of monitoring nodes in that direction reaches two-thirds of the minimum number of diagnostic nodes required, and then the system is expanded in the other direction.

[0098] In this embodiment, the correlation coefficient between suspected event nodes and their upstream and downstream monitoring nodes is calculated in advance based on historical monitoring data and updated periodically. This correlation coefficient is used to quantify the degree of correlation between data changes between suspected event nodes and upstream and downstream monitoring nodes, and its value ranges from [-1, 1]. The closer the absolute value is to 1, the stronger the correlation between the data changes of the two nodes; the closer the absolute value is to 0, the weaker the correlation.

[0099] When determining the expansion direction of associated nodes, the correlation coefficient is used as the primary criterion. Specifically, the direction of the monitoring node whose absolute correlation coefficient is greater than the preset correlation threshold is determined as the priority expansion direction. The preset correlation threshold is a pre-set benchmark value used to judge the strength of the correlation between node data. This embodiment adopts a differentiated threshold setting method based on the hydraulic sensitivity classification of local topology subnets. The edge computing node first calculates the average historical correlation coefficient between all adjacent monitoring node pairs in the local topology subnet, and uses 70% of this average value as the benchmark correlation threshold. Based on this, the correlation threshold is adjusted in stages according to the hydraulic sensitivity of the pipeline: for sensitive pipe sections with small diameter (≤300mm) and gentle slope (≤0.5%), the correlation threshold is reduced by 0.1 from the benchmark value to expand the search range of associated nodes and avoid missing early weak abnormal signals; for non-sensitive pipe sections with large diameter (≥800mm) and steep slope (≥1.5%), the correlation threshold is increased by 0.1 from the benchmark value to filter low-correlation nodes and improve search efficiency.

[0100] After determining the priority expansion direction, prioritize the search in that direction and continuously add related nodes until the number of related nodes in the priority expansion direction reaches the preset minimum number requirement for that direction (this minimum number requirement is preset according to the importance of the priority direction and is not less than half of the minimum number of diagnostic nodes). Then, switch to another direction for expansion to ensure that node data with strong correlation is obtained first and improve the efficiency of collaborative diagnosis.

[0101] If the absolute values ​​of the correlation coefficients in both directions (upstream and downstream) are less than the preset correlation threshold, it indicates that the data correlation between the suspected event node and the upstream and downstream nodes is weak. At this time, the judgment criteria are switched and expanded. Specifically, the hydraulic gradient in the upstream and downstream directions of the suspected event node is calculated based on the hydraulic model of the local topology subnet.

[0102] A hydraulic model is a pre-established mathematical model used to simulate the flow patterns (such as flow velocity, water level, hydraulic gradient, etc.) of water within a pipe network. Hydraulic gradient refers to the drop in water level per unit length of pipe when water flows along it, representing the flow trend and energy change of the water. The larger the hydraulic gradient, the faster the water flow and the greater the possibility and speed of the propagation of abnormal events.

[0103] After calculating the hydraulic gradient in the upstream and downstream directions, the system prioritizes expanding in the direction with the larger hydraulic gradient, continuously searching for and supplementing associated nodes until the number of monitoring nodes in that direction reaches two-thirds of the minimum required number of diagnostic nodes, before expanding in the other direction. This strategy combines data correlation and water flow patterns to achieve accurate and efficient expansion of associated nodes, avoiding the reduced diagnostic efficiency caused by blind expansion. Simultaneously, the acquired associated nodes can maximize support for collaborative diagnosis, improving the accuracy of diagnostic results.

[0104] As can be seen from the above, this application pre-calculates and periodically updates the correlation coefficients between suspected event nodes and upstream and downstream nodes, thereby determining the priority expansion direction and prioritizing the search. When the correlation is insufficient, it prioritizes expansion towards directions with large hydraulic gradients based on the hydraulic model. The application of correlation coefficients can quickly locate nodes with high correlation to suspected events, improving expansion efficiency and reducing invalid expansion. The reference hydraulic gradient closely matches the hydraulic characteristics of the drainage network, ensuring that the expansion direction conforms to the anomaly propagation law. Prioritizing expansion towards highly correlated and high hydraulic gradient directions can quickly obtain effective diagnostic nodes, shorten the diagnostic cycle, and improve the correlation between associated nodes and suspected events, further ensuring diagnostic accuracy.

[0105] In one embodiment of this application, a second monitoring result is generated based on monitoring data from upstream and downstream associated monitoring nodes, monitoring data from suspected event nodes, and the topological relationship of local subnets, including:

[0106] The monitoring data of suspected event nodes are synchronized and aligned with the monitoring data of upstream and downstream related monitoring nodes according to the time series to generate multiple monitoring sequences along the pipeline flow direction;

[0107] Based on the topological relationship of local topological subnets, a water balance analysis model centered on suspected event nodes is constructed, and the deviation between the total upstream inflow and the total downstream outflow is calculated respectively.

[0108] If the deviation value is greater than the preset balance threshold, the abnormal propagation path and the migration direction of the pollutant will be identified based on the fluctuation characteristics and changing trends of the data in the monitoring sequence.

[0109] Based on the abnormal propagation path, migration direction, preset rainfall intensity, and surface runoff data, the abnormal event is determined, and a second monitoring result is generated.

[0110] In this embodiment, the monitoring data of suspected event nodes are synchronized and aligned with the monitoring data of upstream and downstream related monitoring nodes according to time series, generating multiple monitoring sequences along the pipeline flow direction. Time series synchronization and alignment uses a unified timestamp as a benchmark to match the monitoring data of suspected event nodes with those of each related node, ensuring that various types of data at the same point in time can be compared and analyzed, and avoiding analysis errors caused by time deviations.

[0111] The monitoring sequence is a dataset formed by arranging the monitoring data of suspected event nodes and upstream and downstream related nodes in chronological order according to the direction of water flow in the pipeline network. Each sequence corresponds to the monitoring data changes of a pipeline branch, which makes it easy to intuitively observe the data fluctuation patterns.

[0112] Based on the topological relationships of local topological subnets, a water balance analysis model centered on suspected event nodes is constructed, and the deviation between the total upstream inflow and the total downstream outflow is calculated. The water balance analysis model, based on the pipe connections and flow direction of the local topological subnets, simulates the mathematical model of water supply and demand balance within the pipe network, following the balance principle that the total upstream inflow ≈ the total downstream outflow.

[0113] The deviation value is the difference between the total amount of water flowing into the area where the suspected event node is located from all upstream associated nodes and the total amount of water discharged from the area by all downstream associated nodes. The larger the deviation value, the more likely there is an abnormal situation such as water accumulation, blockage, or leakage in that area of ​​the pipeline network.

[0114] Determine the relationship between the deviation value and the preset balance threshold. If the deviation value is greater than the preset balance threshold, it indicates that there is a significant water imbalance in this area of ​​the pipeline network, and there is a high probability of an abnormal event. At this time, it is necessary to identify the abnormal propagation path and the migration direction of the pollutants based on the fluctuation characteristics and changing trends of the data in the monitoring sequence.

[0115] The preset balance threshold is dynamically generated based on historical hydraulic data and real-time operating conditions of the local topology subnet, rather than using fixed empirical values. The edge computing node first obtains the water balance deviation values ​​for all normal operating periods of the local topology subnet over the past year, calculates its standard deviation σ and historical mean μ, and sets the basic balance threshold as μ+2σ, corresponding to the upper limit of the 95% confidence interval of the deviation value under normal operating conditions. Based on this, the edge computing node introduces real-time operating condition correction coefficients: when there is rainfall during the monitoring period, the amplification factor is multiplied by 1.2, 1.5, 2.0, and 2.5 respectively, depending on the rainfall intensity level (light rain, moderate rain, heavy rain, torrential rain); when the monitoring period is during the flood season or non-flood season, the adjustment factor is multiplied by 1.3 or 0.9 respectively. Through this dynamic threshold determination method, the balance threshold can adapt to changes in the hydraulic state of the pipe network, avoiding misjudgments caused by fixed thresholds under special operating conditions.

[0116] Fluctuation characteristics refer to the changes in peak values, trough values, and rates of increase / decrease in the data within the monitoring sequence. Anomaly propagation paths are the specific routes by which abnormal events spread from suspected event nodes to surrounding areas within the pipe network. Pollutants are the pollutants (COD, ammonia nitrogen, etc.) that cause abnormal water quality in the pipe network, and their migration direction is the direction in which the pollutants propagate within the pipe network along with the water flow.

[0117] Based on the abnormal propagation path, migration direction, preset rainfall intensity, and surface runoff data, the abnormal event is identified, generating a second monitoring result. Rainfall intensity, defined as the amount of rainfall per unit time, is used to determine whether the abnormal event is related to rainfall. Surface runoff data includes the volume and velocity of surface water flowing into the pipe network after rainfall, characterizing the impact of surface precipitation on pipe network operation. By comprehensively analyzing the above information, the type, scope, severity, and cause of the abnormal event can be accurately determined, ultimately forming a second monitoring result that includes the aforementioned information.

[0118] In this embodiment, after identifying the abnormal propagation path, the edge computing node further performs the following dual verification analysis:

[0119] The first step is to perform upstream and downstream transmission quantification analysis. Specifically, the edge computing node determines the target anomaly time when abnormal data appears at the suspected event node and detects whether abnormal data appears at the upstream node. If an anomaly exists at the upstream node, the first anomaly time of the upstream node is obtained. Based on the pipe length L between the upstream node and the suspected event node and the preset hydraulic propagation velocity v (calibrated based on pipe diameter, slope, and historical monitoring data), the theoretical propagation delay Δt = L / v is calculated, thus obtaining the standard anomaly time Tstd = Tup + Δt. The target anomaly time Ta is compared with the standard anomaly time Tstd to calculate the time deviation. If the time deviation is less than or equal to the preset time deviation threshold, the abnormal propagation path is determined to be highly matched with the hydraulic conduction law, and an upstream conduction confidence score is generated; if there is no abnormality in the upstream node or the time deviation is greater than the preset time deviation threshold, the upstream conduction confidence score is reduced.

[0120] The second step is to perform a consistency analysis along the same line. Specifically, the edge computing node acquires monitoring data from other monitoring nodes that belong to the same branch line or the same pipe section as the suspected event node, and constructs a set of line characteristic parameters, including average water level, water level fluctuation rate, average flow rate, flow rate change rate, average COD concentration, and water quality parameter fluctuation coefficient.

[0121] Edge computing nodes, based on a directed graph model of local topology subnets, combine pipeline topology connections and water flow direction to identify monitoring nodes located on the same branch or in the same pipe segment as suspected event nodes, without other branches flowing into or out of them, forming a set of associated nodes along the same line. If the number of nodes in the associated node set along the same line is less than two, the consistency confidence level of that line is set to the preset minimum confidence level of 0.3, and the consistency analysis process along the same line is terminated to avoid confidence level distortion due to insufficient samples.

[0122] The normalized deviation between the characteristic parameter Pi of the edge computing node for calculating the suspected event node and the average characteristic parameter P of other monitoring nodes on the same line. When calculating the average characteristic parameters of the same line, weights are assigned based on the data quality score and node type of each monitoring node: the weight of the first type of monitoring node is greater than the weight of the second type of monitoring node, and the monitoring node with the higher data quality score has an even higher weight.

[0123] Edge computing nodes calculate the consistency confidence level along the same line based on the normalized deviation D using a preset S-shaped confidence mapping function:

[0124]

[0125] in, The confidence level for consistency along the same line; among which, The baseline deviation threshold is the 75th percentile of the normalized deviation between all pairs of nodes on the same line under the historical normal operating conditions of this subnet. This is the steepness coefficient, ranging from 5 to 10, used to control the sensitivity of confidence level to decreasing as bias increases. When the normalized bias D is less than or equal to... hour, ≥0.5; when D is greater than hour, It approaches 0 as D increases. Edge computing nodes are recalculated quarterly based on historical subnet operational data. and .

[0126] If the normalized deviation D is less than or equal to the preset consistency deviation threshold (which is 1.2 times the baseline deviation threshold), the anomaly is determined to be a common problem of the line, and the consistency confidence level of the same line is above 0.7; if the normalized deviation D is greater than the preset consistency deviation threshold, it is determined to be a local point anomaly, and the consistency confidence level of the same line is below 0.5, and the consistency confidence level of the same line is generated.

[0127] The consistency deviation threshold is determined using a statistical analysis method based on historical successful cases. Specifically, the edge computing node performs statistical analysis on historical successful diagnostic cases, and counts all cases that have successfully completed collaborative diagnosis and received on-site verification within the past year. The 25th percentile of each indicator in the successful cases is taken as the minimum requirement.

[0128] The third step involves the edge computing node weighting and fusing the upstream and downstream transmission confidence scores with the consistency confidence scores along the same line to obtain a comprehensive confidence score. Based on this comprehensive confidence score, the abnormal event judgment results are corrected to generate a second monitoring result.

[0129] Specifically, the reliability factors for upstream and downstream transmission confidence and consistency confidence of edge computing nodes are first evaluated based on the number of monitoring nodes participating in the upstream and downstream transmission analysis, the average data quality score, and the magnitude of time deviation. The reliability factor for upstream and downstream transmission confidence is as follows:

[0130]

[0131] in, The number of monitoring nodes that effectively participate. To minimize the number of monitoring nodes as expected, The average data quality score for participating nodes. This represents the maximum permissible value for time deviation.

[0132] The reliability factor for the consistency confidence level of the same line is determined comprehensively based on the number of nodes in the associated node set, the distribution of node types, and the stability of the normalized deviation D; the reliability factor for the consistency confidence level of the same line is:

[0133]

[0134] in This represents the number of effective monitoring nodes along the same route. To meet the minimum number of monitoring nodes required for the same line, The proportion of the first type of monitoring nodes among the nodes on the same line, where D is the normalized bias.

[0135] Based on the above reliability factors, the edge computing nodes calculate the dynamic fusion weights:

[0136] ;

[0137]

[0138] in, The value is a very small positive number to prevent division by zero. When the reliability factor of a certain confidence level is lower than the preset reliability threshold (e.g., 0.3), the confidence level is not included in the fusion, and the other confidence level is directly used as the comprehensive confidence level; if the reliability factors of both are lower than the reliability threshold, the comprehensive confidence level is the minimum of the two and is marked as the low confidence fusion result.

[0139] After obtaining the comprehensive confidence level, the edge computing node corrects the anomaly judgment result based on the following multi-level correction mechanism. Specifically, if the comprehensive confidence level is greater than or equal to the first comprehensive confidence level threshold (0.85), the anomaly judgment result is marked as high confidence confirmation, and a second monitoring result including anomaly type, scope of impact, and confidence level is directly generated. This result is then reported to the central cloud platform as the final diagnostic conclusion.

[0140] If the overall confidence level is greater than or equal to the second overall confidence threshold (0.6) and less than the first overall confidence threshold, the abnormal event judgment result is marked as a medium confidence warning. The edge computing node triggers the compensation verification process, extracts historical diagnostic records of similar hydraulic conditions in the local topology subnet where the suspected event node is located over the past 30 days, and calculates the matching degree between the historical diagnostic results and the current judgment result. If the matching degree is greater than the preset matching threshold (e.g., 0.7), the confidence level of the current judgment result is increased to be greater than or equal to the first overall confidence threshold and marked as reported after historical verification. If the matching degree is less than or equal to the matching threshold, the original confidence level is maintained, and a prompt message suggesting on-site verification is attached when reporting the second monitoring result. The first overall confidence threshold being greater than the second overall confidence threshold is set based on historical experience.

[0141] If the overall confidence level is less than the second overall confidence level threshold, the abnormal event judgment result is marked as low confidence and pending verification. The edge computing node does not directly generate the second monitoring result, but packages the monitoring data of the suspected event node, the first monitoring result, the upstream and downstream transmission confidence level, the consistency confidence level of the same line, the overall confidence level, and the reliability factor corresponding to each confidence level, and reports them to the central cloud platform. The central cloud platform will then conduct a comprehensive analysis based on the global data of the adjacent local topology subnets, or the operation and maintenance personnel will conduct on-site verification and confirmation.

[0142] As can be seen from the above, this application generates a monitoring sequence by synchronizing and aligning the monitoring data of suspected event nodes with those of upstream and downstream nodes in time, constructs a water balance analysis model to calculate the deviation value, identifies abnormal propagation paths and migration directions when the deviation exceeds a threshold, and determines abnormal events by combining rainfall and surface runoff data. Time synchronization and alignment ensure the temporal consistency of the data, the water balance model can quickly locate whether there is an anomaly, the identification of abnormal propagation paths and migration directions clarifies the abnormal diffusion pattern, and the combination of rainfall and surface runoff data can accurately distinguish the types of abnormal events, improve the accuracy of abnormal event determination, and provide clear directional guidance for subsequent anomaly handling, ensuring a rapid response to drainage anomalies.

[0143] In one embodiment of this application, based on the fluctuation characteristics and changing trends of data in the monitoring sequence, the abnormal propagation path and the migration direction of pollutants are identified, including:

[0144] Extract waveform features of multiple water quality parameters and / or hydraulic parameters in the monitoring sequence within the time window of the abnormal event. The waveform features include peak arrival time, rising slope, falling steepness, and duration of fluctuation.

[0145] The waveform features are matched with a pre-set abnormal event feature template library to determine the feature similarity between suspected event nodes and upstream and downstream related monitoring nodes;

[0146] Based on the topological relationships and feature similarities of local topological subnets, an anomaly propagation directed graph is constructed, and the Dijkstra algorithm is used to find the path with the highest cumulative feature similarity from upstream to downstream as the anomaly propagation path.

[0147] The migration direction of pollutants can be determined by the arrival time sequence of peaks along the abnormal propagation path.

[0148] In this embodiment, waveform features of multiple water quality parameters and / or hydraulic parameters in the monitoring sequence are extracted within the time window of an abnormal event. The time window of an abnormal event is a preset time interval covering the entire process of an abnormal event, starting from the moment when the monitoring data of the suspected event node shows an anomaly and ending at the moment when the data tends to stabilize. Water quality parameters are indicators representing the water quality status of the pipe network; hydraulic parameters are indicators representing the water flow movement status of the pipe network; waveform features are the changing shape characteristics of the monitoring data within the time window, specifically including peak arrival time (the moment when the data reaches its maximum value), rising slope (the rate at which the data rises from the normal range to the peak), falling slope (the rate at which the data falls from the peak to the normal range), and fluctuation duration (the total time the data is in the abnormal range).

[0149] The waveform features are matched against a pre-defined abnormal event feature template library to determine the feature similarity between suspected event nodes and upstream and downstream related monitoring nodes. The abnormal event feature template library is a database pre-established based on historical abnormal event data (such as water accumulation, pollution, blockage, etc.) and includes waveform feature templates corresponding to various abnormal events. Feature similarity is used to quantify the degree of matching between the waveform features of the current monitoring sequence and the abnormal templates in the template library. The value range is [0,1]. The closer the value is to 1, the higher the matching degree and the more accurate the anomaly type determination.

[0150] The matching process uses a dynamic time warping algorithm to calculate the cumulative distance between the waveform feature vector of the current monitoring sequence and the feature vector of each abnormal template in the template library. The reciprocal of the cumulative distance is used as the feature similarity, with a value range of [0,1]. The abnormal event feature template library is constructed in the following way: the waveform feature vectors of various types of historically confirmed abnormal events are clustered, and the cluster center of each cluster is taken as the standard template. The template library is updated once a quarter.

[0151] Based on the topological relationships and feature similarities of local subnets, a directed graph for anomaly propagation is constructed. Dijkstra's algorithm is then used to find the path with the highest cumulative feature similarity from upstream to downstream, which is then identified as the anomaly propagation path. The directed graph for anomaly propagation is a logical graph constructed using monitoring nodes as vertices, topological connections between nodes as directed edges, and feature similarity as edge weights, to simulate anomaly propagation trends. Dijkstra's algorithm is used to find the shortest path from the starting point to other vertices in the graph. This algorithm can accurately filter out the main paths of anomaly propagation and eliminate interfering paths.

[0152] The migration direction of pollutants is determined by the arrival time sequence of peak values ​​along the abnormal propagation path. Since pollutants propagate within the pipe network with the water flow, the peak values ​​of abnormal data will appear sequentially along the water flow direction. Therefore, by comparing the peak arrival times of each monitoring node along the abnormal propagation path, if the peak arrival time of node A is earlier than that of node B, and node A is located upstream of node B, it is determined that the pollutant migrates from node A to node B, i.e., the migration direction is consistent with the water flow direction. Otherwise, further calibration is performed using topological relationships and hydraulic models to ultimately clarify the migration direction of the pollutants.

[0153] As can be seen from the above, this application extracts waveform features of water quality and hydraulic parameters from monitoring sequences, matches them with anomaly event feature template libraries to determine feature similarity, constructs a directed graph of anomaly propagation based on topological relationships, uses algorithms to solve for the optimal path as the propagation path, and determines the migration direction based on the peak arrival time. The waveform feature extraction accurately captures the changing patterns of anomaly data, the template library matching quickly associates anomaly types, the directed graph model combined with the algorithm ensures the scientific validity of the propagation path solution, and the application of peak arrival time accurately determines the migration direction of pollutants. The overall process improves the accuracy of anomaly propagation path and migration direction identification, providing a reliable basis for anomaly event analysis.

[0154] In one embodiment of this application, an abnormal event is determined based on the abnormal propagation path, migration direction, preset rainfall intensity, and surface runoff data, and a second monitoring result is generated, including:

[0155] The spatial distribution characteristics of abnormal events are generated by overlaying the abnormal propagation path and migration direction with the topology of the local subnet.

[0156] Acquire rainfall intensity data and surface runoff data for the areas where suspected event nodes are located, and construct a temporal-spatial evolution map of the abnormal event based on the time series of the abnormal propagation path;

[0157] If the abnormal propagation path and migration direction are consistent with the preset hydraulic direction of the pipeline network, and the duration and fluctuation amplitude of the abnormal event are positively correlated with the rainfall intensity, then the abnormal event is determined to be a rainfall-induced event.

[0158] If the abnormal propagation path and migration direction are inconsistent with the preset hydraulic direction of the pipeline network, and the fluctuation characteristics of the abnormal event are not related to the surface runoff data, then the abnormal event is determined to be a pipeline network structure event or an external intrusion event.

[0159] Based on the judgment results, a second monitoring result is generated based on the monitoring data type of the suspected event node.

[0160] In this embodiment, the abnormal propagation path and migration direction are overlaid with the topology of the local subnet to generate the spatial distribution characteristics of the abnormal event. The spatial distribution characteristics are used to visually present the distribution range of the abnormal event within the pipeline network, the locations of the affected pipelines and nodes, and the spatial trend of the abnormal propagation. By overlaying, the core area and spread range of the abnormality can be clearly located, providing spatial reference for event judgment and handling.

[0161] Rainfall intensity and surface runoff data for the suspected event nodes are acquired, and a time-space evolution map of the anomalous event is constructed based on the time series of the anomalous propagation path. The time-space evolution map is a visual map that integrates the temporal variation patterns of the anomalous event (such as the time nodes of the anomaly occurrence, spread, and stabilization) and the spatial propagation path. It can clearly present the evolution process of the anomalous event and intuitively represent the relationship between time and space.

[0162] Based on the aforementioned maps and data, the types of abnormal events are classified and determined into two categories: First, if the abnormal propagation path and migration direction are consistent with the preset hydraulic direction of the pipe network, and the duration and fluctuation amplitude of the abnormal event are positively correlated with rainfall intensity, then the abnormal event is determined to be a rainfall-induced event. The preset hydraulic direction of the pipe network is the pre-defined flow direction of normal water flow within the pipe network, consistent with the flow direction in the directed graph model of the local topological subnet. Rainfall-induced events are abnormal events in the pipe network triggered by rainfall, such as water accumulation caused by excessive rainfall, or water quality abnormalities caused by rainwater carrying pollutants. Their characteristic is that the abnormal changes are highly correlated with rainfall intensity and duration.

[0163] In the second scenario, if the abnormal propagation path and migration direction are inconsistent with the preset hydraulic direction of the pipe network, and the fluctuation characteristics of the abnormal event are not related to surface runoff data, then the abnormal event is determined to be either a pipe network structural event or an external intrusion event. Pipe network structural events are anomalies caused by defects in the pipe network's own structure, such as pipe ruptures, blockages, and interface leaks; external intrusion events are anomalies caused by external factors intruding into the pipe network, such as illegal sewage discharge and foreign objects entering the pipe network. The common characteristic of both types of events is that they are not directly related to rainfall or surface runoff, and the abnormal propagation direction will deviate from the normal water flow direction.

[0164] Based on the above judgment results and the monitoring data types of the suspected event nodes, a second monitoring result is generated. If the suspected event node is a first-class monitoring node (multiple data types), the second monitoring result will detail the abnormal event type, spatial distribution, evolution process, pollutant details, and causes. If it is a first-class node but no water quality abnormalities are detected (only hydraulic parameter abnormalities), the scope and degree of the hydraulic abnormalities will be highlighted to ensure that the second monitoring result is consistent with the characteristics of the node data and provides accurate and comprehensive basis for subsequent handling.

[0165] As can be seen from the above, this application generates spatial distribution characteristics by overlaying abnormal propagation paths, migration directions, and pipeline topology. Combined with rainfall and surface runoff data, a temporal-spatial evolution map is constructed. The type of abnormal event is determined based on the correlation between propagation direction, fluctuation characteristics, and rainfall and surface runoff. The spatial distribution characteristics and temporal-spatial evolution map clearly present the spatiotemporal patterns of abnormal events. The introduction of rainfall and surface runoff data can accurately distinguish between rainfall-induced, pipeline structure-related, and external intrusion-related events, avoiding misjudgment of event types. Simultaneously, it clarifies the spatiotemporal evolution trend of events, providing scientific support for the precise handling and subsequent prevention of abnormal events, and improving the targeted nature of drainage pipeline network anomaly management.

[0166] In one embodiment of this application, a second monitoring result is generated by comprehensively analyzing the monitoring data of suspected event nodes and the monitoring data of associated nodes using preset correlation analysis rules, including:

[0167] Based on the node type of the suspected event node, the corresponding association analysis rule is matched from the preset association analysis rule base; the association analysis rule includes data type mapping relationship, logical operation conditions and confidence evaluation parameters;

[0168] Based on the association analysis rules, effective feature parameters are extracted from the monitoring data of suspected event nodes, and collaborative feature parameters that have a preset association relationship with the effective feature parameters are extracted from the monitoring data of upstream and downstream related monitoring nodes.

[0169] The effective feature parameters and collaborative feature parameters are synchronized and aligned according to the time series, and the association matching degree is calculated based on the logical operation conditions defined in the association analysis rules;

[0170] If the correlation matching degree is greater than or equal to the preset correlation judgment threshold, a second monitoring result is generated based on the topological relationship of the local topology subnet;

[0171] If the association matching degree is less than the preset association judgment threshold, then compensation verification is performed based on the compensation judgment logic in the association analysis rules, using historical association data or monitoring data of association monitoring nodes of adjacent local topology subnets.

[0172] If the correlation matching degree calculated again after compensation verification is still less than the preset correlation judgment threshold, the comprehensive analysis process will be terminated, and the monitoring data of the suspected event node, the first monitoring result, and the correlation matching degree information will be reported to the central cloud platform.

[0173] In this embodiment, based on the node type of the suspected event node, the corresponding association analysis rule is matched from a preset association analysis rule base. The association analysis rule base is a pre-established database that stores association analysis rules corresponding to various types of nodes. It is stored according to node type (first type, second type) and is updated and optimized periodically in combination with historical diagnostic data. The association analysis rules specifically include data type mapping relationships (clarifying the basic data types that the suspected event node and the associated nodes need to be compared, such as the correspondence between water volume and water level), logical operation conditions (operation rules used to judge the rationality of data association, such as the allowable range of water volume difference), and confidence evaluation parameters.

[0174] Based on the association analysis rules, effective feature parameters are extracted from the monitoring data of suspected event nodes, and collaborative feature parameters with a pre-defined correlation with the effective feature parameters are extracted from the monitoring data of upstream and downstream related monitoring nodes. Effective feature parameters are parameters extracted from the basic monitoring data (such as water volume and water level) of suspected event nodes that can characterize the abnormal state of the nodes; collaborative feature parameters are parameters extracted from the monitoring data of upstream and downstream related nodes that have a logical correlation with the effective feature parameters (such as a positive correlation between water level and water volume).

[0175] The effective feature parameters and collaborative feature parameters are synchronized and aligned according to time series, and the correlation matching degree is calculated based on the logical operation conditions defined in the correlation analysis rules. The time series synchronization alignment here is consistent with the alignment standard of the first type of nodes, using a unified timestamp as the benchmark to ensure the accuracy of data comparison; the correlation matching degree is used to quantify the degree of logical matching between the effective feature parameters and collaborative feature parameters, with a value range of [0,1]. The closer the value is to 1, the higher the correlation between the two, and the more likely the node anomaly is a real anomaly in the pipeline network, rather than a random fluctuation.

[0176] Based on the relationship between the correlation matching degree and the preset correlation judgment threshold, a differentiated processing strategy is adopted: if the correlation matching degree is greater than or equal to the preset correlation judgment threshold, it indicates that the data correlation between the suspected event node and the associated node meets the standard, and the anomaly can be determined as a real anomaly in the pipeline network. At this time, a second monitoring result is generated based on the topological relationship of the local topology subnet. The preset correlation judgment threshold is a pre-set benchmark value used to judge whether the data correlation matching degree meets the standard, with a reference range of 0.7-0.8, which can be adjusted according to the monitoring accuracy requirements of the second type of node. In order to improve the adaptability of the correlation judgment threshold to the actual operating status of the pipeline network, this embodiment introduces a threshold dynamic adjustment mechanism based on historical false alarm rate in the edge computing node. Specifically, the edge computing node records the comparison data between the judgment result of each collaborative diagnosis and the actual on-site verification result of the operation and maintenance personnel, and calculates the false alarm rate (i.e., the proportion diagnosed as abnormal but verified as normal on-site) and the missed alarm rate (i.e., the proportion diagnosed as normal but verified as abnormal on-site) on a monthly basis. If the false alarm rate exceeds 5%, the association determination threshold is adjusted upwards in steps of 0.01 until the false alarm rate drops below 5%. If the false negative rate exceeds 3%, the association determination threshold is adjusted downwards in steps of 0.01 until the false negative rate drops below 3%. The step size of 0.01 is determined based on the integral separation concept in control theory, ensuring smooth threshold adjustment while avoiding drastic fluctuations in diagnostic performance due to excessively large single adjustments. The rationality of the step size is verified through sensitivity analysis of historical false alarm and false negative rates to threshold changes. Using historical data from the past year for this subnet as a sample, the partial derivative of the false alarm rate with respect to the association determination threshold is calculated. The step size is taken as 1 / 10 of the median absolute value of the partial derivative, eventually converging to 0.01. This step size allows the threshold to converge to the optimal range within 3-5 adjustment cycles (i.e., 3-5 months), balancing adjustment efficiency and stability.

[0177] If the correlation matching degree is less than the preset correlation judgment threshold, it indicates that the current data correlation is insufficient and the anomaly type cannot be directly determined. In this case, it is necessary to perform compensation verification based on the compensation judgment logic in the correlation analysis rules, using historical correlation data or monitoring data of the correlation monitoring nodes of adjacent local topology subnets. Compensation judgment logic: The pre-set logic in the correlation analysis rules is used to supplement the verification logic when the data correlation is insufficient, clarifying the acquisition method and verification standard of the compensation data; historical correlation data is the correlation data between suspected event nodes and related nodes under historical normal or similar abnormal operating conditions, used to supplement the deficiencies of the current data; adjacent local topology subnets are adjacent subnets that have a pipeline connection relationship with the current local topology subnet and can provide collaborative data support.

[0178] The correlation matching degree is recalculated on the data after compensation verification: If the correlation matching degree recalculated after compensation verification is greater than or equal to the preset correlation judgment threshold, a second monitoring result is generated based on the topological relationship of the local topology subnet; if it is still less than the preset correlation judgment threshold, it means that the current data still cannot support accurate diagnosis, the comprehensive analysis process needs to be terminated, and the monitoring data of the suspected event node, the first monitoring result and the correlation matching degree information are reported to the central cloud platform together.

[0179] As can be seen from the above, this application extracts effective feature parameters and collaborative feature parameters based on the correlation analysis rules matching the suspected event node types, synchronizes them, calculates the correlation matching degree, and takes corresponding actions according to the matching degree. For low matching degrees, compensation verification is performed; if the matching degree is still not met, data is reported. Matching node types with analysis rules improves the targeting of the analysis; synchronized alignment of feature parameters ensures the accuracy of the analysis; the calculation of the correlation matching degree quantifies the degree of correlation between nodes; the compensation verification mechanism maximizes the use of effective data and avoids diagnostic termination due to insufficient data; and the reporting mechanism ensures that abnormal information is not missed, thus balancing diagnostic accuracy and completeness.

[0180] In one embodiment of this application, compensation verification is performed using historical correlation data or monitoring data from associated monitoring nodes of adjacent local topology subnets, including:

[0181] When the data quality score of the upstream and downstream associated monitoring nodes of the suspected event node is less than or equal to the preset compensation verification threshold, historical associated data of the suspected event node under similar hydraulic conditions are extracted from the historical database to construct historical associated feature curves.

[0182] Calculate the deviation between the current monitoring data and the historical correlation feature curve. If the deviation is less than the preset deviation threshold, the historical correlation feature curve will be used as the basis for compensation verification, and the correlation matching degree will be recalculated.

[0183] If the data quality score of the upstream and downstream associated monitoring nodes is greater than the compensation verification threshold but the association matching degree is still less than the association judgment threshold, then a collaborative compensation request is sent to one or more local topology subnets adjacent to the current local topology subnet. Monitoring data from monitoring nodes in the adjacent local topology subnets that have indirect topological associations with the suspected event node are obtained as extended collaborative feature parameters, and the association matching degree is recalculated based on these extended collaborative feature parameters. The compensation verification threshold is used to determine whether to enable the compensation verification process.

[0184] In this embodiment, the relationship between the data quality scores of upstream and downstream associated monitoring nodes of a suspected event node and a preset compensation verification threshold is determined. The compensation verification threshold is a pre-set benchmark value used to determine whether historical associated data is needed for compensation. The reference range is 60-70 points, which is lower than a first preset quality threshold. Scores higher than this threshold indicate that the data quality of upstream and downstream associated nodes is basically suitable for collaborative compensation; scores lower than or equal to this threshold require reliance on historical data for compensation. This compensation verification threshold is not a fixed empirical value but is dynamically optimized based on the historical distribution of data quality scores of monitoring nodes within the local topology subnet, combined with historical compensation success rates. Edge computing nodes statistically analyze all diagnostic cases in the subnet that have undergone compensation verification within the past year, recording the correspondence between the data quality scores of upstream and downstream associated nodes and the successful diagnosis after compensation for each verification. A logistic regression model is used to fit an S-shaped curve showing the change in compensation success rate with data quality scores. The data quality score corresponding to a 70% compensation success rate is used as the compensation verification threshold. This compensation verification threshold is recalculated quarterly, allowing the compensation verification mechanism to adapt to dynamic factors such as aging monitoring equipment and fluctuations in communication quality.

[0185] The historical database is a database that stores historical monitoring data, historical hydraulic condition data, and historical correlation data of all monitoring nodes, and can quickly extract historical data under similar operating conditions.

[0186] When the data quality score of the upstream and downstream associated monitoring nodes of a suspected event node is less than or equal to the preset compensation verification threshold, it indicates that the data quality of the current upstream and downstream associated nodes is poor and cannot be directly used for compensation verification. In this case, historical associated data of the suspected event node under similar hydraulic conditions is extracted from the historical database. Similar hydraulic conditions refer to conditions that are consistent with or similar to the hydraulic parameters such as water flow velocity, water level, and pipeline pressure in the current pipeline network. Based on the extracted historical associated data, a historical associated feature curve is constructed. This curve can intuitively represent the change pattern of the monitoring data of the suspected event node under normal similar conditions. Among them, similar hydraulic conditions refer to historical periods within a preset time window where the Euclidean distance between the hydraulic parameters such as water level and flow rate of the upstream and downstream associated monitoring nodes and the current conditions is less than the preset condition similarity threshold. The condition similarity threshold is dynamically determined based on the historical data distribution of the local topology subnet, taking the 75th percentile of the distribution of hydraulic parameter differences between adjacent periods under historical normal operating conditions.

[0187] Next, the deviation between the current monitoring data and the historical correlation feature curve is calculated. The deviation quantifies the degree of difference between the current monitoring data and the historical correlation feature curve. The smaller the deviation, the higher the consistency between the current data and the historical normal operating data. If the deviation is less than the preset deviation threshold (reference range 0.1-0.2), it indicates that the current data fluctuation is still within a reasonable range. The historical correlation feature curve is used as the basis for compensation verification, and the correlation matching degree is recalculated for subsequent anomaly judgment. The deviation threshold is dynamically determined using an adaptive sliding window method. The edge computing node takes the historical normal operation monitoring data of 30 days backward from the current time point as the center, calculates the deviation sequence between the daily monitoring data and the historical correlation feature curve of the current day, and uses the 75th percentile of this sequence as the basic deviation threshold. Then, it multiplies this by a redundancy coefficient of 1.2 to obtain the final deviation threshold. After the monitoring node has been running for more than a year, the edge computing node updates this threshold quarterly so that the deviation threshold can characterize the normal fluctuation range of the monitoring node caused by long-term changes such as equipment aging and pipeline deposition, avoiding misjudgment or omission due to fixed thresholds in long-term operation.

[0188] If the data quality score of the upstream and downstream associated monitoring nodes is greater than the compensation verification threshold, it indicates that the data quality of the current upstream and downstream associated nodes is basically qualified, but the association matching degree is still less than the association judgment threshold, and the anomaly judgment cannot be completed. At this time, cross-subnet collaborative compensation needs to be initiated. Specifically, the edge computing nodes of the current local topology subnet send collaborative compensation requests to one or more local topology subnets adjacent to the current local topology subnet. The collaborative compensation request is an instruction used between edge computing nodes to request collaborative data, including information such as the location of the suspected event node, the topological relationship, and the required data type.

[0189] The adjacent local topology subnets that receive the collaborative compensation request will feed back monitoring data from monitoring nodes that have indirect topological relationships with the suspected event node. Indirect topological relationships refer to the indirect connection between two nodes that are not directly connected but are formed through pipes and nodes in adjacent subnets, ensuring that the acquired data can indirectly characterize the network status of the suspected event node. This fed-back monitoring data is used as extended collaborative feature parameters. These extended collaborative feature parameters are obtained from adjacent subnets and are used to supplement the currently insufficient indirect related monitoring data, enriching the data source for collaborative diagnosis. Finally, based on the extended collaborative feature parameters, the correlation matching degree is recalculated, providing a more comprehensive basis for anomaly event determination.

[0190] In this embodiment, when acquiring extended collaborative feature parameters, if multiple monitoring nodes providing collaborative data exist simultaneously in adjacent subnets, the edge computing node determines the weights based on the pipeline distance between each node and the suspected event node, with closer monitoring nodes having higher weights. The collaborative feature parameters provided by each monitoring node are then weighted and fused. Simultaneously, the edge computing node evaluates the goodness of fit of the mapping relationships of each collaborative data source. If the goodness of fit of all mapping relationships is lower than a preset confidence threshold, the confidence level of this compensation verification is reduced, and a low-confidence compensation flag is attached when reporting the second monitoring result.

[0191] After the compensation verification is completed, the edge computing node will re-determine whether the association matching degree has reached the association judgment threshold. If it has, it will continue to advance the abnormal event judgment and generate a second monitoring result; if it still has not reached the threshold, it will terminate the comprehensive analysis process and report the relevant data to the central cloud platform.

[0192] As can be seen from the above, this application adopts different compensation verification methods based on the data quality scores of upstream and downstream related nodes: when the score is low, a feature curve is constructed using historical related data from similar working conditions, and the deviation is calculated for compensation; when the score is high but the matching degree is insufficient, collaborative data is requested from adjacent subnets as extended parameters for recalculation. Historical data compensation can provide effective reference when node data quality is insufficient, avoiding diagnostic failure caused by data loss. Collaborative compensation from adjacent subnets expands the data sources and fully utilizes the advantages of distributed monitoring. The flexible application of the two compensation methods improves the effectiveness of compensation verification, ensures the accuracy of the correlation matching degree calculation, and guarantees the smooth progress of the diagnostic process.

[0193] In one embodiment of this application, a second monitoring result is generated based on the topological relationship of a local topological subnet, including:

[0194] Based on a directed graph model of local topology subnets, the topological connection edges and edge weights between suspected event nodes and their upstream and downstream associated monitoring nodes are extracted; the edge weights are pre-calibrated according to the pipe diameter, slope and historical hydraulic propagation delay.

[0195] Using monitoring data from upstream and downstream related monitoring nodes as evidence variables and event types from suspected event nodes as target variables, a Bayesian network inference model is constructed.

[0196] The correlation matching degree is used as observational evidence and input into the Bayesian network inference model to calculate the posterior probability distribution of various event types corresponding to suspected event nodes.

[0197] The event type with the highest posterior probability is identified as the event type, the posterior probability value is used as the confidence level, and the scope of influence is determined based on the distribution of activated node paths in the local topology subnet in the Bayesian network inference model, thus generating a second monitoring result.

[0198] In this embodiment, based on a directed graph model of local topology subnets, the topological connection edges and edge weights between suspected event nodes and their upstream and downstream associated monitoring nodes are extracted. Topological connection edges represent the pipeline connection relationships between suspected event nodes and their upstream and downstream associated nodes, corresponding to actual pipeline segments in the pipeline network. Edge weights quantify the importance of topological connection edges, and are pre-calibrated based on pipeline diameter (larger diameter, higher weight), pipeline slope (greater slope, higher weight), and historical hydraulic propagation delay (shorter delay, higher weight) to ensure that the weights characterize the actual operating characteristics of the pipeline and the importance of the connection.

[0199] A Bayesian network inference model is constructed by using monitoring data from upstream and downstream related monitoring nodes as evidence variables and event types from suspected event nodes as target variables. Evidence variables serve as input data to support the inference of the target variable; here, they specifically refer to the monitoring data (such as water volume and water level) and correlation matching degree of upstream and downstream related monitoring nodes. The target variable is determined through inference; here, it specifically refers to the type of abnormal event in the pipeline network corresponding to the suspected event node. The Bayesian network inference model is a probabilistic graphical model-based inference tool that achieves uncertain inference through probabilistic dependencies between nodes. Its structure is constrained by the topological connections of a directed graph model of local topological subnets, ensuring that the inference process closely matches the actual structure of the pipeline network.

[0200] The conditional probability table of the Bayesian network inference model is learned in the following way: historical monitoring data of the local topology subnet over the past three years are collected, and domain experts annotate the data to distinguish different states such as normal operation, rainfall-induced events, pipeline structure events, and external intrusion events; the maximum likelihood estimation method is used to calculate the conditional probability of the target variable taking each state under various combinations of evidence variables, thereby generating the conditional probability table; the conditional probability table is updated every six months using newly accumulated data.

[0201] The association matching degree is used as observational evidence input into the Bayesian network inference model. The model combines the conditional probability table and calculates the posterior probability distribution of each event type corresponding to the suspected event node through probabilistic inference. The observational evidence is the known data input into the model, which is the association matching degree in this case, used to trigger model inference; the posterior probability distribution is the probability distribution of each event type calculated based on the observational evidence, representing the likelihood of different event types, with a value range of [0,1]. The sum of the posterior probabilities of all event types is 1.

[0202] Information about abnormal events is determined based on the posterior probability distribution, generating a second monitoring result. The event type with the highest posterior probability is identified as the specific type of this abnormal event. This highest posterior probability value is used as the confidence level of the event judgment to characterize the reliability of the judgment result. Simultaneously, based on the activated node paths in the Bayesian network inference model (i.e., suspected event nodes and upstream and downstream related nodes involved in the inference) and combined with the topological relationship of the local topology subnet, the scope of influence of the abnormal event (such as the pipeline segments and number of nodes involved) is determined. Finally, information such as event type, confidence level, and scope of influence are integrated to generate the second monitoring result.

[0203] If the correlation matching degree is less than the preset correlation judgment threshold, it indicates that the current data correlation degree is insufficient and abnormal events cannot be directly determined. In this case, it is necessary to use historical correlation data or correlation monitoring data of adjacent local topology subnets to perform compensation verification based on the compensation judgment logic in the correlation analysis rules, recalculate the correlation matching degree, and then execute the above Bayesian network inference process. If the correlation matching degree still does not meet the standard after compensation verification, the comprehensive analysis process is terminated and the relevant data is reported to the central cloud platform.

[0204] As can be seen from the above, this application extracts the topological connection edges and pre-labeled edge weights between suspected event nodes and related nodes, constructs a Bayesian network inference model, uses the association matching degree as evidence input, calculates the posterior probability of the event type, and determines the event type, confidence level, and scope of influence. The labeling of the topological edge weights closely matches the actual operating characteristics of the pipeline network. The conditional probability table learned by the Bayesian network model in conjunction with historical data improves the scientific nature of the inference. The calculation of the posterior probability can quantify the credibility of the event type, and the determination of the scope of influence clearly defines the area affected by the anomaly. The overall process improves the accuracy and completeness of the second monitoring results, provides quantitative evidence for the handling of abnormal events, and enhances the scientific nature of the handling.

[0205] In one embodiment of this application, if the fault is determined to be a fault in the node itself, before the edge computing node reports the monitoring data of the monitoring node to the central cloud platform, the following steps are included:

[0206] Edge computing nodes acquire historical operational data of monitoring nodes and synchronous monitoring data of upstream and downstream related monitoring nodes within a preset time window in their local topology subnet.

[0207] Based on historical operational data, the characteristic baseline of the monitoring nodes under normal operating conditions is extracted, and based on synchronous monitoring data, it is determined whether there are external disturbances that meet the preset external environmental event characteristics within the preset time window.

[0208] If it is determined that there is an external disturbance, and the fluctuation of the current monitoring data of the monitoring node meets the preset correlation conditions with the occurrence time and intensity of the external disturbance, then it is inferred that the fault is caused by an external environmental event, and the monitoring node is remarked from its own fault state to a suspected event node to trigger the execution of the distributed collaborative diagnosis process.

[0209] If it is determined that there is no external disturbance, or the current monitoring data fluctuation does not meet the preset correlation conditions with the external disturbance, the judgment result of the monitoring node itself being faulty will be maintained, and the edge computing node will report the monitoring data and fault status of the monitoring node to the central cloud platform.

[0210] In this embodiment, the edge computing node acquires historical operational data of the monitoring node and synchronous monitoring data of upstream and downstream related monitoring nodes within its local topology subnet within a preset time window. Historical operational data is a collection of data, including operational parameters, monitoring data, and status information, recorded by the monitoring node during its past normal operation, used to extract normal operating condition characteristics. The preset time window is a pre-defined fixed time interval covering the period before and after an anomaly occurs (e.g., from 1 hour before the anomaly to 30 minutes after), ensuring that environmental changes before and after the anomaly are captured. Synchronous monitoring data is the monitoring data synchronously collected by upstream and downstream related monitoring nodes within the same local topology subnet as the monitoring node within the aforementioned preset time window, used to determine whether there are external disturbances in the surrounding area.

[0211] Based on historical operational data, characteristic baselines of monitoring nodes under normal operating conditions are extracted. Based on synchronous monitoring data, it is determined whether external disturbances conforming to preset external environmental event characteristics exist within a preset time window. The characteristic baselines, based on historical operational data of the monitoring nodes, extract the benchmark range and variation patterns of monitoring data and operating parameters under normal operating conditions, used to compare whether current data fluctuations deviate from normal conditions. External environmental event characteristics are pre-defined, representing the characteristic parameters and manifestations of external environmental events (such as strong electromagnetic interference, extreme temperatures, external force collisions, etc.) that affect the operation of the monitoring nodes. External disturbances are external interferences caused by external environmental events that lead to abnormal monitoring node data but are not due to node malfunctions.

[0212] Based on the judgment results of external disturbances and data correlation, a differentiated processing strategy is adopted. If an external disturbance is determined to exist, and the fluctuation of the current monitoring data of the monitoring node meets the preset correlation conditions with the occurrence time and intensity of the external disturbance, these correlation conditions are pre-set standards used to determine whether there is a causal relationship between the data fluctuation and the external disturbance. For example, if the deviation between the time of data anomaly occurrence and the time of external disturbance occurrence is within a preset range (e.g., ≤5 minutes), and the data fluctuation amplitude is positively correlated with the intensity of the external disturbance, then it is inferred that the fault is caused by an external environmental event, not a fault of the monitoring node itself. At this time, the monitoring node is re-marked from its own fault state as a suspected event node to trigger the execution of the previously described distributed collaborative diagnosis process to further determine whether it is a pipeline network anomaly event. The time deviation threshold and intensity correlation threshold in the correlation conditions are determined using a statistical learning method based on a historical disturbance event database. The edge computing node pre-builds an external disturbance event database, collecting various historical external disturbances (strong electromagnetic interference, extreme temperature shocks, external force collisions, etc.) and the resulting monitoring node data fluctuation cases. For the time deviation threshold, the 95th percentile of the time difference between the occurrence of the disturbance and the occurrence of the data anomaly in all historical cases is used as the time deviation threshold. For the intensity correlation threshold, the Pearson correlation coefficient between the disturbance intensity and the data fluctuation amplitude in historical cases is calculated, and the 75th percentile is used as the intensity correlation threshold. After the subnet has been running for a full year, the edge computing nodes update the event database and related thresholds annually, so that the correlation conditions continuously characterize the actual disturbance response pattern.

[0213] If it is determined that there is no external disturbance, or the current monitoring data fluctuation does not meet the preset correlation conditions with the external disturbance, it indicates that the data anomaly of the monitoring node is indeed caused by its own fault and is unrelated to the external environment. In this case, the judgment result of the monitoring node's own fault is maintained, and the edge computing node promptly reports the monitoring data and fault status information of the monitoring node to the central cloud platform. The central cloud platform is used to coordinate and manage all local topology subnets, edge computing nodes and monitoring data. It is a cloud management platform that receives reported information, performs global analysis and issues disposal instructions. The cloud coordinates and arranges maintenance personnel to carry out repairs and replacements to ensure the integrity of the monitoring network. If the pre-inspection determines that the monitoring node has no fault, it indicates that the data anomaly is likely caused by the anomaly of the pipeline network itself. In this case, the node is marked as a suspected event node. Suspected event node: The monitoring node whose monitoring data is abnormal after the pre-inspection confirms that there is no equipment fault, is likely a monitoring node corresponding to the pipeline network abnormal event, and further collaborative diagnosis is initiated.

[0214] As can be seen from the above, before reporting node fault data, the edge computing nodes in this application acquire historical node operation data and upstream and downstream synchronous monitoring data, extract normal feature baselines, and determine whether there are external disturbances. Based on the correlation between disturbances and data fluctuations, the node status is re-determined. The feature baseline constructed from historical operation data provides a reference for fault determination. The judgment of external disturbances can distinguish between faults and anomalies caused by external factors, avoiding misjudging fluctuations caused by external disturbances as node faults. Re-marking suspected event nodes can trigger collaborative diagnosis, reduce the fault misjudgment rate, and ensure the accuracy of node fault reporting, thereby improving the fault tolerance and diagnostic reliability of the monitoring system.

[0215] Corresponding to the distributed urban drainage monitoring method in the above embodiments, Figure 2 This is a structural block diagram of a distributed urban drainage monitoring system provided in one embodiment of this application. For ease of explanation, only the parts relevant to the embodiment of this application are shown. References Figure 2 The distributed urban drainage monitoring system 20 includes: a data acquisition module 21, a topology partitioning module 22, an edge computing node 23, a status pre-inspection module 24, a data reporting module 25, an event node marking module 26, and a distributed collaborative diagnosis module 27.

[0216] The data acquisition module 21 is used to acquire monitoring data from multiple monitoring nodes in the target drainage area. The monitoring nodes include a first type of monitoring node and a second type of monitoring node, wherein the number of monitoring data types of the first type of monitoring node is greater than the number of monitoring data types of the second type of monitoring node.

[0217] The topology partitioning module 22 is used to partition the monitoring nodes into at least one local topology subnet according to the topological connection relationship of the urban drainage pipe network.

[0218] Edge computing nodes 23 are configured to correspond to the number of local topology subnets and establish communication connections; each edge computing node is used to determine the first monitoring result for each monitoring node in its local topology subnet based on the monitoring data of that monitoring node and the corresponding standard monitoring data.

[0219] The status pre-inspection module 24 is used to perform a status pre-inspection on the monitoring node if the first monitoring result is abnormal, and to determine whether the fault is the fault of the monitoring node itself.

[0220] The data reporting module 25 is used to report the monitoring data of the monitoring node to the central cloud platform based on the edge computing node if the fault is determined to be the fault of the monitoring node itself.

[0221] The event node marking module 26 is used to mark the monitoring node as a suspected event node if it is determined that the monitoring node has no fault of its own.

[0222] The distributed collaborative diagnosis module 27 is used to respond to the occurrence of a suspected event node in any local topology subnet. The corresponding edge computing node triggers the execution of the distributed collaborative diagnosis process, obtains the second monitoring result, and reports it to the central cloud platform.

[0223] See Figure 3 , Figure 3 This is a schematic block diagram of an electronic device provided according to an embodiment of this application. Figure 3 The electronic device 300 in this embodiment may include one or more processors 301, one or more input devices 302, one or more output devices 303, and one or more memories 304. The processors 301, input devices 302, output devices 303, and memories 304 communicate with each other via a communication bus 305. The memories 304 store computer programs, including program instructions. The processors 301 execute the program instructions stored in the memories 304. Specifically, the processors 301 are configured to invoke the program instructions to perform the functions of the modules in the aforementioned device embodiments, for example... Figure 2 The functions of the data acquisition module 21, topology partitioning module 22, edge computing node 23, status pre-inspection module 24, data reporting module 25, event node marking module 26, and distributed collaborative diagnosis module 27 are shown.

[0224] It should be understood that, in the embodiments of this application, the processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0225] Input device 302 may include a touchpad, a fingerprint sensor (for collecting the user's fingerprint information and fingerprint orientation information), a microphone, etc., and output device 303 may include a display (LCD, etc.), a speaker, etc.

[0226] The memory 304 may include read-only memory and random access memory, and provides instructions and data to the processor 301. A portion of the memory 304 may also include non-volatile random access memory. For example, the memory 304 may also store device type information.

[0227] In specific implementations, the processor 301, input device 302, and output device 303 described in the embodiments of this application can execute the implementation methods described in any embodiment of the distributed urban drainage monitoring method provided in the embodiments of this application, or they can execute the implementation methods of the electronic devices described in the embodiments of this application, which will not be repeated here.

[0228] In another embodiment of this application, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program, which includes program instructions. When executed by a processor, the program instructions implement all or part of the processes in the methods described above. Alternatively, the computer program can instruct related hardware to implement these processes. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer-readable storage medium is used to store the computer program and other programs and data required by the electronic device.

[0229] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

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

[0231] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A distributed urban drainage monitoring method, characterized in that, include: Acquire monitoring data from multiple monitoring nodes in the target drainage area; the monitoring nodes include a first type of monitoring node and a second type of monitoring node, wherein the number of monitoring data types of the first type of monitoring node is greater than the number of monitoring data types of the second type of monitoring node; Based on the topological connection relationship of the urban drainage pipe network, the monitoring nodes are divided into at least one local topological subnet; Configure the corresponding edge computing nodes according to the number of local topology subnets, and establish communication connections; Each monitoring node determines its first monitoring result based on the monitoring data of the monitoring node and the corresponding standard monitoring data, using the edge computing nodes of its local topology subnet. If the first monitoring result is abnormal, a self-state pre-check is performed on the monitoring node to determine whether it is a fault of the monitoring node itself. If the fault is determined to be in the monitoring node itself, the monitoring data of the monitoring node will be reported to the central cloud platform based on the edge computing node. If it is determined that the monitoring node has no fault of its own, then the monitoring node will be marked as a suspected event node; In response to the appearance of a suspected event node in any local topology subnet, the corresponding edge computing node triggers the execution of a distributed collaborative diagnostic process to obtain a second monitoring result and report it to the central cloud platform. The distributed collaborative diagnostic process includes: Based on the pipeline network topology, the upstream and downstream associated monitoring nodes of the suspected event node are obtained; The monitoring data of upstream and downstream related monitoring nodes are evaluated for quality, and a data quality score is obtained. If the data quality score is less than or equal to the first preset quality threshold, compensation calculation is performed using historical data pattern matching or monitoring data from adjacent non-directly related monitoring nodes; if the diagnostic conditions are still not met after compensation, the collaborative diagnostic process is terminated, and the monitoring data of the suspected event node and the first monitoring result are reported to the central cloud platform. If the data quality score is greater than the first preset quality threshold and less than or equal to the second preset quality threshold, the search range of upstream and downstream related monitoring nodes is expanded, and then the subsequent diagnostic process is executed; wherein, the subsequent diagnostic process includes: If the data quality score is greater than the second preset quality threshold, and the suspected event node is a first-type monitoring node, then a second monitoring result is generated based on the monitoring data of upstream and downstream related monitoring nodes, the monitoring data of the suspected event node, and the topological relationship of the local topology subnet. If the data quality score is greater than the second preset quality threshold, and the suspected event node is a second type of monitoring node, then the monitoring data of the suspected event node and the monitoring data of the upstream and downstream related monitoring nodes are comprehensively analyzed using the preset correlation analysis rules to generate a second monitoring result. The second preset quality threshold is greater than the first preset quality threshold; The second monitoring result is generated based on the monitoring data of upstream and downstream related monitoring nodes, the monitoring data of the suspected event nodes, and the topological relationship of the local topology subnet, including: The monitoring data of the suspected event nodes are synchronized and aligned with the monitoring data of the upstream and downstream related monitoring nodes according to the time series to generate multiple monitoring sequences along the pipeline flow direction. Based on the topological relationship of the local topological subnet, a water balance analysis model centered on the suspected event node is constructed, and the deviation between the total upstream inflow and the total downstream outflow is calculated respectively. If the deviation value is greater than the preset balance threshold, then based on the fluctuation characteristics and change trends of the data in the monitoring sequence, the abnormal propagation path and the migration direction of the pollutant are identified. Based on the abnormal propagation path, migration direction, preset rainfall intensity, and surface runoff data, the abnormal event is determined, and the second monitoring result is generated. The process involves using preset correlation analysis rules to comprehensively analyze the monitoring data of suspected event nodes and the monitoring data of related nodes to generate a second monitoring result, including: Based on the node type of the suspected event node, the corresponding association analysis rule is matched from the preset association analysis rule base; the association analysis rule includes data type mapping relationship, logical operation conditions and confidence evaluation parameters; According to the association analysis rules, effective feature parameters are extracted from the monitoring data of the suspected event nodes, and collaborative feature parameters that have a preset association relationship with the effective feature parameters are extracted from the monitoring data of upstream and downstream related monitoring nodes. The effective feature parameters and the collaborative feature parameters are synchronized and aligned according to the time series, and the association matching degree is calculated based on the logical operation conditions defined in the association analysis rules; If the correlation matching degree is greater than or equal to the preset correlation judgment threshold, a second monitoring result is generated based on the topological relationship of the local topology subnet; If the association matching degree is less than the preset association judgment threshold, then based on the compensation judgment logic in the association analysis rules, compensation verification is performed using historical association data or monitoring data of association monitoring nodes of adjacent local topology subnets. If the correlation matching degree calculated again after compensation verification is still less than the preset correlation judgment threshold, the comprehensive analysis process will be terminated, and the monitoring data of the suspected event node, the first monitoring result, and the correlation matching degree information will be reported to the central cloud platform.

2. The distributed urban drainage monitoring method according to claim 1, characterized in that, The step of obtaining upstream and downstream associated monitoring nodes of the suspected event node based on the pipeline network topology includes: Based on a directed graph model of local topology subnets, a topology search is performed upstream and downstream of the suspected event node along the water flow direction to determine at least one initial associated node. Based on preset data validity rules, the monitoring data of the initial associated nodes are evaluated for quality to obtain a quality score; the initial associated nodes with a quality score lower than the preset diagnostic threshold are removed to obtain the first associated node set. The first set of associated nodes is processed to obtain a set of effective associated nodes, which includes at least one upstream and downstream associated monitoring node.

3. The distributed urban drainage monitoring method according to claim 2, characterized in that, The process of processing the first set of associated nodes to obtain a valid set of associated nodes includes: Determine whether the first set of associated nodes meets the preset minimum number of diagnostic nodes requirement; If the conditions are met, the first set of associated nodes is determined as the effective set of associated nodes participating in collaborative diagnosis; If the conditions are not met, then based on the directed graph model, the first-level topology connection relationship is expanded outward along the water flow direction, the newly searched monitoring nodes are added as new associated nodes, and the data quality assessment and judgment steps are repeated until the minimum number of diagnostic nodes is met and the boundary of the local topology subnet is not exceeded, and the number of nodes in the first associated node set after the cumulative number of expansions is not greater than the preset maximum number of nodes, or the number of expansions reaches the preset maximum tracing depth, and the finally obtained associated nodes are taken as the effective associated node set. If the conditions are still not met after expansion, the expansion is terminated, and the currently obtained associated nodes are taken as the set of valid associated nodes.

4. The distributed urban drainage monitoring method according to claim 1, characterized in that, The compensation verification using historical correlation data or monitoring data from correlated monitoring nodes in adjacent local topology subnets includes: When the data quality score of the upstream and downstream associated monitoring nodes of the suspected event node is less than or equal to the preset compensation verification threshold, historical associated data of the suspected event node under similar hydraulic conditions are extracted from the historical database to construct a historical associated feature curve. Calculate the deviation between the current monitoring data and the historical correlation feature curve. If the deviation is less than a preset deviation threshold, the historical correlation feature curve is used as the basis for compensation verification, and the correlation matching degree is recalculated. If the data quality score of the upstream and downstream associated monitoring nodes is greater than the compensation verification threshold but the association matching degree is still less than the association judgment threshold, then a collaborative compensation request is sent to one or more local topology subnets adjacent to the current local topology subnet to obtain the monitoring data of the monitoring nodes in the adjacent local topology subnets that have an indirect topological association relationship with the suspected event node, as an extended collaborative feature parameter, and the association matching degree is recalculated based on the extended collaborative feature parameter.

5. A distributed urban drainage monitoring system, characterized in that, include: The data acquisition module is used to acquire monitoring data from multiple monitoring nodes in the target drainage area; the monitoring nodes include a first type of monitoring node and a second type of monitoring node, wherein the number of monitoring data types of the first type of monitoring node is greater than the number of monitoring data types of the second type of monitoring node; The topology partitioning module is used to divide the monitoring nodes into at least one local topology subnet based on the topological connection relationship of the urban drainage pipe network. Edge computing nodes are configured to correspond to the number of local topology subnets and establish communication connections; each edge computing node is used to determine the first monitoring result for each monitoring node in its local topology subnet based on the monitoring data of that monitoring node and the corresponding standard monitoring data. The status pre-inspection module is used to perform a status pre-inspection on the monitoring node if the first monitoring result is abnormal, and to determine whether the fault is caused by the monitoring node itself. The data reporting module is used to report the monitoring data of the monitoring node to the central cloud platform based on the edge computing node if the fault is determined to be the fault of the monitoring node itself. The event node marking module is used to mark a monitoring node as a suspected event node if it is determined that the monitoring node has no fault of its own. The distributed collaborative diagnosis module is used to respond to the occurrence of a suspected event node in any local topology subnet. The corresponding edge computing node triggers the execution of the distributed collaborative diagnosis process to obtain a second monitoring result and report it to the central cloud platform. The distributed collaborative diagnostic process includes: Based on the pipeline network topology, the upstream and downstream associated monitoring nodes of the suspected event node are obtained; The monitoring data of upstream and downstream related monitoring nodes are evaluated for quality, and a data quality score is obtained. If the data quality score is less than or equal to the first preset quality threshold, compensation calculation is performed using historical data pattern matching or monitoring data from adjacent non-directly related monitoring nodes; if the diagnostic conditions are still not met after compensation, the collaborative diagnostic process is terminated, and the monitoring data of the suspected event node and the first monitoring result are reported to the central cloud platform. If the data quality score is greater than the first preset quality threshold and less than or equal to the second preset quality threshold, the search range of upstream and downstream related monitoring nodes is expanded, and then the subsequent diagnostic process is executed; wherein, the subsequent diagnostic process includes: If the data quality score is greater than the second preset quality threshold, and the suspected event node is a first-type monitoring node, then a second monitoring result is generated based on the monitoring data of upstream and downstream related monitoring nodes, the monitoring data of the suspected event node, and the topological relationship of the local topology subnet. If the data quality score is greater than the second preset quality threshold, and the suspected event node is a second type of monitoring node, then the monitoring data of the suspected event node and the monitoring data of the upstream and downstream related monitoring nodes are comprehensively analyzed using the preset correlation analysis rules to generate a second monitoring result. The second preset quality threshold is greater than the first preset quality threshold; The second monitoring result is generated based on the monitoring data of upstream and downstream related monitoring nodes, the monitoring data of the suspected event nodes, and the topological relationship of the local topology subnet, including: The monitoring data of the suspected event nodes are synchronized and aligned with the monitoring data of the upstream and downstream related monitoring nodes according to the time series to generate multiple monitoring sequences along the pipeline flow direction. Based on the topological relationship of the local topological subnet, a water balance analysis model centered on the suspected event node is constructed, and the deviation between the total upstream inflow and the total downstream outflow is calculated respectively. If the deviation value is greater than the preset balance threshold, then based on the fluctuation characteristics and change trends of the data in the monitoring sequence, the abnormal propagation path and the migration direction of the pollutant are identified. Based on the abnormal propagation path, migration direction, preset rainfall intensity, and surface runoff data, the abnormal event is determined, and the second monitoring result is generated. The process involves using preset correlation analysis rules to comprehensively analyze the monitoring data of suspected event nodes and the monitoring data of related nodes to generate a second monitoring result, including: Based on the node type of the suspected event node, the corresponding association analysis rule is matched from the preset association analysis rule base; the association analysis rule includes data type mapping relationship, logical operation conditions and confidence evaluation parameters; According to the association analysis rules, effective feature parameters are extracted from the monitoring data of the suspected event nodes, and collaborative feature parameters that have a preset association relationship with the effective feature parameters are extracted from the monitoring data of upstream and downstream related monitoring nodes. The effective feature parameters and the collaborative feature parameters are synchronized and aligned according to the time series, and the association matching degree is calculated based on the logical operation conditions defined in the association analysis rules; If the correlation matching degree is greater than or equal to the preset correlation judgment threshold, a second monitoring result is generated based on the topological relationship of the local topology subnet; If the association matching degree is less than the preset association judgment threshold, then based on the compensation judgment logic in the association analysis rules, compensation verification is performed using historical association data or monitoring data of association monitoring nodes of adjacent local topology subnets. If the correlation matching degree calculated again after compensation verification is still less than the preset correlation judgment threshold, the comprehensive analysis process will be terminated, and the monitoring data of the suspected event node, the first monitoring result, and the correlation matching degree information will be reported to the central cloud platform.

6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 4.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 4.

Images