A method for identifying abnormal operating conditions in drainage systems based on data fusion models

Abstract

This invention relates to the field of electronic digital data processing technology and discloses a method for identifying abnormal operating conditions in drainage systems based on a data fusion model. It addresses the problem of insufficient data privacy protection in traditional methods during the fusion of multi-source data from drainage systems. The invention first collects multi-source data from the drainage system, classifies and labels the data by source. A differential privacy mechanism is applied to add noise perturbation, preserving statistical characteristics and storing the data in isolated buffers. Access control logic is implemented during data extraction, and the data is encrypted before transmission to the fusion layer. Standardization transformation and time series alignment are performed, and anonymized identifiers are embedded to form a fused dataset. An anomaly identification model is constructed, performing feature extraction, pattern matching, and classification judgment, while simultaneously recording privacy compliance logs. An identification report is generated, feeding back to the control terminal to update the collection parameters and verify the privacy mechanism, applying adjusted protection logic for the next cycle. This method improves identification accuracy and data security.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, specifically to a method for identifying abnormal operating conditions in drainage systems based on a data fusion model. Background Technology

[0002] As a core component of urban infrastructure, drainage systems play a crucial role in identifying abnormal operating conditions for ensuring public safety, preventing floods, and optimizing water resource management. With the rapid development of the Internet of Things (IoT), sensor technology, and big data analytics, multi-source data fusion models have become the mainstream method for identifying abnormal operating conditions in drainage systems. This method integrates multimodal data such as water level, flow rate, water quality, and video surveillance, and utilizes machine learning algorithms to achieve real-time fault detection and risk prediction, improving identification accuracy and response efficiency. However, existing technologies generally suffer from insufficient data privacy protection during multi-source data fusion, leading to an increased risk of sensitive information leakage and hindering system security and widespread application.

[0003] For example, CN103175513A discloses a watershed hydrological and water quality monitoring system and method based on the Internet of Things. This method collects hydrological data through fixed and mobile sensors and combines video technology for real-time monitoring and anomaly identification, enabling the detection of conditions such as overflow and pollution in drainage systems. This patent emphasizes the comprehensiveness and real-time nature of data collection, but does not address privacy protection mechanisms during multi-source data fusion, such as encryption and anonymization of location data or user-related information, leading to a risk of leakage during data transmission and sharing. CN119826125B discloses an underwater smart pipeline fault detection method and system based on sensor breakpoint detection. This system improves detection accuracy by identifying faulty sensors and their extended sensors and fusing multi-source data to analyze abnormal pipeline conditions. This patent focuses on sensor breakpoint identification and data integration optimization, but also neglects data privacy protection during the fusion process. For example, it lacks differential privacy algorithms or access control strategies, causing sensitive data involving geographical location or device identification to face security risks during cross-system fusion.

[0004] While the aforementioned existing technologies have made progress in anomaly identification efficiency, none have fully considered the privacy risks of multi-source data fusion. In practical applications of drainage systems, multi-source data often contains privacy-sensitive information such as geographic coordinates and real-time monitoring records. Traditional methods lack effective protection measures, leading to data leaks that may cause misuse of personal information or system attacks, seriously affecting the reliability and compliance of the system. Therefore, there is an urgent need for an anomaly identification method that strengthens data privacy protection in multi-source data fusion to address the shortcomings of existing technologies and achieve safe and efficient drainage system management. Summary of the Invention

[0005] (a) Technical problems to be solved

[0006] To address the shortcomings of existing technologies, this invention provides a method for identifying abnormal operating conditions in drainage systems based on a data fusion model, which solves the problem of insufficient data privacy protection in the process of multi-source data fusion in drainage systems in traditional methods.

[0007] (II) Technical Solution

[0008] To achieve the goal of safe and efficient drainage system management mentioned in the background section, the present invention provides the following technical solution:

[0009] A method for identifying abnormal operating conditions in drainage systems based on a data fusion model includes:

[0010] S1: Collect multi-source data from the drainage system, perform preliminary classification of the multi-source data, and label its source attributes;

[0011] S2: Apply differential privacy mechanism to the collected multi-source data, add noise perturbation to the classified data, while retaining the overall statistical characteristics of the data, and store the perturbed data in groups in an isolated buffer.

[0012] S3: Extract packet data from the isolation buffer, restrict data access permissions through access control logic, allow only authorized modules to read specific packets, and transmit the read data to the fusion layer;

[0013] S4: Perform standardization transformation on the transmitted data in the fusion layer, map data from different sources to a unified format space, and then align the data according to the time series, while embedding anonymization identifiers during the alignment process;

[0014] S5: Construct an anomaly identification model based on the fused dataset, input the aligned data into the model for feature extraction and pattern matching, classify and judge potential abnormal operating conditions, and record privacy compliance logs simultaneously during the judgment process;

[0015] S6: Generate an identification report based on the classification results, feed the report back to the system control terminal, verify the effectiveness of the privacy mechanism in the feedback loop, and apply the adjusted protection logic to the data collected in the next cycle.

[0016] In a preferred embodiment, multi-source data from the drainage system is collected, and the multi-source data is initially classified and its source attributes are labeled, including:

[0017] Collect multi-source data from the drainage system and deploy sensors and edge nodes at key locations;

[0018] Set up water level channel, flow rate channel, water quality channel and visual channel, perform time calibration uniformly, and apply adaptive sampling strategy;

[0019] Perform preliminary classification at the edge nodes and generate source attribute tags;

[0020] Implement primary / backup redundancy and data integrity auditing;

[0021] Implement quality control and privacy parameter recommendations;

[0022] Categorized data, source tags, audit logs, and privacy recommendations are written into an isolated queue.

[0023] In a preferred embodiment, a differential privacy mechanism is applied to the collected multi-source data, adding noise perturbation to the classified data while preserving the overall statistical characteristics of the data, including:

[0024] Read the categorized metric stream, source attribute tags, integrity credentials, and privacy parameter suggestion table.

[0025] Perform range pruning on the field and complete time sequence alignment;

[0026] Choose either the Laplace or Gaussian mechanism based on the field type and statistical purpose;

[0027] Establish a privacy budget and adopt a consistent accounting approach;

[0028] Generate noise and add it to the cropped data;

[0029] Post-processing for performing nonnegative constraints and monotonic projections.

[0030] In a preferred embodiment, storing the perturbed data groups in an isolation buffer includes:

[0031] Temporal downsampling and coordinate gridding are performed on video metadata;

[0032] Add noise to the tag count and ratio;

[0033] Set a threshold for grouped samples and merge duplicate requests;

[0034] Data is grouped by equipment type and pipe section number;

[0035] Generate batch objects and publish them to the corresponding topic;

[0036] The encryption and key rotation strategy is used to store the data in an isolated buffer.

[0037] Budget accounting and audit records are completed simultaneously.

[0038] In a preferred embodiment, packet data is extracted from the isolation buffer, access control logic restricts data access permissions, allowing only authorized modules to read specific packets, and the read data is transmitted to the fusion layer, including:

[0039] Extract the packet data from the isolation buffer in read-only mode;

[0040] Access control using a combination of roles and attributes is employed to verify the permissions of the requester.

[0041] Determine extraction priority and establish leases based on demand tags;

[0042] Decryption is limited to the minimum time slice after the consistency check passes;

[0043] Transmit disturbance data and necessary metadata through a dedicated intranet channel;

[0044] Logs are kept throughout the extraction process and digitally signed.

[0045] The output object submits a structured array to the fusion layer.

[0046] In a preferred embodiment, the transmitted data undergoes a standardization transformation at the fusion layer, mapping data from different sources to a unified format space. This data is then aligned according to time series, with anonymization identifiers embedded during the alignment process, including:

[0047] Compliance data is read from the isolation buffer and filtered and verified using the window identifier and rule version number as consistency anchors;

[0048] Write the indicator batches into the transformation queue and determine the processing order based on the source metadata;

[0049] Perform standardization transformation to map different source data to a unified format space and eliminate heterogeneous differences by using fixed field unit caliber;

[0050] Handle missing measurement points and out-of-bounds values, and record relevant markers and original information in the processing summary;

[0051] Data is aligned according to time series and synchronization is driven based on priority;

[0052] Anonymized identifiers are embedded during the alignment process, and row-level labels are generated for model-side association.

[0053] In a preferred embodiment, an anomaly detection model is constructed based on the fused dataset, and the aligned data is input into the model for feature extraction and pattern matching, including:

[0054] An anomaly detection model is built on the fused dataset, and the aligned data is input into the processing chain.

[0055] Load a multi-layered processing chain targeting liquid level, flow rate, water quality, and video to capture mutations and anomalies;

[0056] Data is injected using a rolling batch method, and the integrity summary is verified to be consistent with the window.

[0057] By using a sliding window combined with robust statistical methods, first-order difference, rolling mean, standardized residuals, and coefficient of variation are extracted.

[0058] Perform pattern matching between single-dimensional features and the working condition database, and perform cross-dimensional verification to remove noise.

[0059] In a preferred embodiment, potential abnormal operating conditions are classified and judged, and privacy compliance logs are recorded simultaneously during the judgment process, including:

[0060] We employ weighted aggregation to introduce hysteresis control to classify and judge potential operating conditions and handle multiple types of conflicts;

[0061] Semantic version management is linked to the threshold range rules for updating the working condition database through canary releases;

[0062] Perform offline training using historical window labeled data and monitor input distribution drift using online calibration;

[0063] Privacy compliance logs are recorded synchronously at each stage of the process;

[0064] The generated structured response is then passed downstream.

[0065] In a preferred embodiment, an identification report is generated based on the classification judgment result, the report is fed back to the system control terminal, and the effectiveness of the privacy mechanism is verified in the feedback loop. Adjusted protection logic is then applied to the collected data in the next cycle, including:

[0066] A comprehensive identification report is generated based on the classification results, using Extensible Markup Language (Extensible Markup Language) format and an attached digital signature.

[0067] The report is sent to the system control terminal via the intranet message bus, and a confirmation is received before the retry mechanism is executed.

[0068] Privacy mechanism verification is performed on associated batches in the feedback loop, including noise coverage minimization check, consistency check, and access scope check.

[0069] Based on the verification, an adjustment plan will be developed and applied to the collection and extraction process in the next cycle in a phased release manner.

[0070] Compared with existing technologies, this invention provides a method for identifying abnormal operating conditions in drainage systems based on a data fusion model, which has the following advantages:

[0071] 1. This invention reduces irrelevant exposure and ensures temporal consistency at the front end by using source attribute labeling and edge pre-classification. At the processing layer, differential privacy-based cropping, budgeting, and noise-adding strategies are used to hierarchically protect water level, flow rate, water quality, and video metadata. Constrained post-processing maintains statistical availability. In the storage and transmission stages, isolation buffers, group encryption, key rotation, and read-only access control converge the minimum necessary set. At the fusion layer, a unified unit caliber and fixed timeline are used to achieve multi-source alignment and embed anonymized identifiers for verifiable playback. At the recognition layer, hierarchical features and cross-dimensional patterns are matched. By reducing false positives from single-source noise and introducing hysteresis control to stabilize alarms, the system achieves verifiability and traceability at the governance layer through embedded privacy compliance logs, budget ledgers, and chain auditing. At the feedback layer, the system iterates the strategy to the next window through closed-loop linkage of report receipts, parameter distribution, and privacy verification. This allows the system to maintain the timeliness and accuracy of anomaly detection without exposing the original coordinates and device identifiers. Ultimately, it achieves safe, stable, and replicable identification and operation and maintenance optimization of urban drainage anomalies, thereby solving the problem of insufficient data privacy protection in the process of multi-source data fusion of drainage systems in traditional methods.

[0072] 2. This invention achieves seamless integration with existing monitoring platforms through a fixed key name and unified time window interface specification; employs idempotent receipts, dead-letter resubmission, and phased release to ensure traceable and rollbackable policy distribution; prioritizes edge processing and uses group-based read-only isolation buffers to reduce bandwidth and storage pressure; enhances compliance and security through minimum authorization sets and key rotation; and introduces drift monitoring and threshold self-calibration to ensure stable model operation under changing operating conditions and fluctuating data distribution, thereby reducing overall maintenance costs and shortening fault response links, thus improving system scalability and long-term operational reliability. Attached Figure Description

[0073] Figure 1 This is a flowchart of the abnormal operating condition identification method for drainage systems based on a data fusion model according to the present invention. Detailed Implementation

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

[0075] Example: Figure 1 A method for identifying abnormal operating conditions in drainage systems based on a data fusion model is presented, including:

[0076] S1: Collect multi-source data from the drainage system, perform preliminary classification of the multi-source data, and label its source attributes;

[0077] S2: Apply differential privacy mechanism to the collected multi-source data, add noise perturbation to the classified data, while retaining the overall statistical characteristics of the data, and store the perturbed data in groups in an isolated buffer.

[0078] S3: Extract packet data from the isolation buffer, restrict data access permissions through access control logic, allow only authorized modules to read specific packets, and transmit the read data to the fusion layer;

[0079] S4: Perform standardization transformation on the transmitted data in the fusion layer, map data from different sources to a unified format space, and then align the data according to the time series, while embedding anonymization identifiers during the alignment process;

[0080] S5: Construct an anomaly identification model based on the fused dataset, input the aligned data into the model for feature extraction and pattern matching, classify and judge potential abnormal operating conditions, and record privacy compliance logs simultaneously during the judgment process;

[0081] S6: Generate an identification report based on the classification results, feed the report back to the system control terminal, verify the effectiveness of the privacy mechanism in the feedback loop, and apply the adjusted protection logic to the data collected in the next cycle.

[0082] S1: Collect multi-source data from the drainage system, perform preliminary classification of the multi-source data, and label its source attributes. The specific implementation is as follows:

[0083] Multi-source data from the drainage system were collected and preliminarily classified and labeled. First, based on the pipe network topology, sensors and edge nodes were deployed at key locations including main drainage wells, branch pipe junctions, pump station inlets and outlets, and the inlet channel of the sewage treatment plant, with coverage assessed at 80%-95%. For the water level channel, probes were fixed to the underside of manhole covers, with a measurement accuracy of ±2mm and a resolution of 1mm, calibrated quarterly. For the flow channel, vortex or ultrasonic probes were used, with a flow velocity range of 0.05–15 m / s, an accuracy of ±2%, and a resolution of 0.01 m / s. The system records pressure fluctuations as an auxiliary indicator and calibrates every six months. The water quality channel maintains a 20–50 cm immersion depth in the inlet channel, measuring pH 4–10, turbidity 0–1000 NTU, and monitoring ammonia nitrogen and total phosphorus. pH accuracy is ±0.05, and turbidity accuracy is ±2%FS, calibrated monthly. The visual channel is installed at the pump station outlet and overflow wellheads, with an adjustable support height of 1–3 m. Normally, H.265 encoding and keyframe extraction are performed locally, with a minimum detectable crack or foreign object edge of 5 mm. When an anomaly occurs, event segments are uploaded. All channels undergo unified time calibration, prioritizing PTP, followed by NTP. When both are unavailable, a local monotonic clock is activated, and a local time identifier is written into the data for subsequent alignment and error control.

[0084] For real-time online plant-level systems, an adaptive sampling scheduling strategy is adopted, with a normal sampling period of 15 seconds. When the first-order difference of liquid level exceeds 3 mm continuously within a 15-second window, or the intra-frame motion vector density exceeds 0.15 and lasts for at least 60 seconds, the system enters high-frequency mode. The exit condition is that the above two indicators are lower than 1 mm / 15 seconds and 0.05 respectively, and are met continuously for 10 minutes, after which the normal frequency is restored. The threshold is adaptively updated according to the quantile of the sliding window over the past 30 days, with an update cycle of 7 days. Clock robustness is achieved through drift monitoring and retry control: when the absolute drift of any pair of time sources is greater than 20 ms for three consecutive times, a time synchronization switch is triggered, and three retries are performed with an interval of 10 seconds. If it still fails, a ±100 ms timing fault tolerance window is enabled during the fusion phase, while retaining the degradation flag.

[0085] For large watershed systems, the normal sampling period is 5-15 minutes, and the first-order difference increases accordingly.

[0086] Edge nodes are responsible for the initial classification to reduce backhaul load and shorten alarm paths. Classification rules are stored in a local lightweight database. The core fields of each rule entry include: rule number, device type, feature key, threshold set, priority, and fallback strategy, along with the rule version number and effective time. Device types cover liquid level, flow rate, chemical, visual, and meteorological data. Examples of feature keys include first-order difference of liquid level, flow rate variance, co-correlation coefficient of hydrogen ion concentration and turbidity, and intra-frame motion vector density. The threshold set includes warning threshold, high-risk threshold, and fallback threshold. A smaller priority value indicates a higher processing order. The fallback strategy can be set to discard, buffer retry, or downsampling to continue. The rule table also stores the rollback target version field. Edge nodes automatically match and execute the corresponding rules based on device type and feature key. When computing or bandwidth resources are limited, liquid level and flow rate are processed first, followed by chemical and visual data, ensuring that core safety-related data enters subsequent processes first.

[0087] After classification, a source attribute tag is generated for each data point and bound to the original payload to form a structured object. The minimum set of fields for the tag includes sensor number, pipe segment number, spatial coordinates, timestamp, equipment status, calibration information, optical information, and engineering extensions. The sensor number uses a readable segmented encoding, with a spare suffix derived during redundancy switching. The pipe segment number corresponds one-to-one with the pipeline network ledger. The spatial coordinates use the Global Geodetic Coordinate System (GGS) and can also provide local coordinate references. The timestamp uses Coordinated Universal Time (UTC) and is accurate to milliseconds. The equipment status includes battery charge ratio, wireless signal strength, and health status enumeration. The calibration information includes the calibration date and temperature compensation switch. The optical information includes the lens angle and illuminance value. The engineering extension is used to record engineering parameters such as pipe diameter and pipe material. The tagged object also carries a rule version number field from the metadata to ensure consistency with the field-level strategies of the subsequent differential privacy mapping and fusion modules.

[0088] Key nodes implement automatic switching to the nearest upstream and downstream node. For real-time online devices, edge nodes monitor the main device's viability with a 10-second heartbeat interval. If the heartbeat is lost three times consecutively, the device is considered disconnected, and a backup device is activated within 2 seconds, with the switchover time recorded. For ordinary devices, monitoring is performed every 15 minutes. The backup device inherits all source attributes of the main device and only updates the timestamp and device status. To avoid frequent oscillations, a 30-minute back-off suppression is set. All switchover events and sensor alarms are uniformly written to a chained audit log for subsequent traceability and quality report statistics.

[0089] Data integrity and auditing employ a two-layer mechanism. The fast verification layer calculates CRC32 for each data packet and sends it with the packet. The receiving end completes verification in milliseconds and triggers retransmission as needed. The auditing and non-repudiation layer digitally signs the data packet digest and the hash of the previous record. The digest algorithm is SHA256, and the signature algorithm is ECDSAP256. The device private key is rotated every 180 days. During the rotation period, dual-signature acceptance is enabled. The key is stored in the secure element and indicated through the key identification field. If fast verification fails, it can be retransmitted up to 3 times, with backoff intervals of 2 seconds, 4 seconds, and 8 seconds, respectively. Data packets that fail signature verification or chain continuity verification are directly discarded, and an audit alarm is generated simultaneously. Communication adopts a layered strategy: ground pump stations and plant nodes prioritize the use of mains power in combination with wired or high-bandwidth wireless, while underground and weak coverage points use battery power and short message methods. The maximum bitrate of video event segments is 2Mb per second, the maximum duration of a single event is 30s, and the daily quota for a single node is 1GB. After exceeding the quota, only 1fps keyframes and time-series metadata are uploaded to ensure the sustainability of bandwidth and power.

[0090] Simultaneously, the first round of data quality control is completed on the edge side. Each channel sequentially performs out-of-bounds checks, outlier identification, and missing data imputation: out-of-bounds checks are determined based on the threshold set in the rule table; outliers are removed using the interquartile range method or the 3-times standard deviation method; missing data is imputed using nearest-neighbor interpolation or first-order Kalman prediction, and the method used and the window length are written into the extended domain to retain processing traces; to cope with time-lapse degradation, the liquid level channel is used as the main timeline in the fusion stage, and the other channels are aligned across sources using the nearest neighbor method; when the deviation exceeds 100 milliseconds, linear interpolation correction is performed, and two fields, alignment method and alignment error, are added to the marked object to record the alignment strategy used and the corresponding error range, thereby ensuring interpretability and consistency of repeated experiments;

[0091] The privacy side outputs a parameter suggestion table that can be directly consumed. Based on the location sensitivity and field sensitivity in the source attributes, the system generates corresponding perturbation and masking strategies for each piece of data. Location sensitivity is divided into three levels: high, medium, and low, corresponding to precise underground coordinates, site-level location, and plant-level location, respectively. Field sensitivity is divided into direct identification, quasi-identification, and non-identification. The default mapping is as follows: high sensitivity uses a noise scale of 0.12, with 60-second downsampling of the timestamp and 50-meter gridding of the coordinates; medium sensitivity uses a noise scale of 0.06, with 30-second downsampling and 20-meter gridding; low sensitivity uses a noise scale of 0.02, with 10-second downsampling and 5-meter gridding. Direct identification uses salted hashing or pseudo-identification; quasi-identification uses coordinate gridding and time downsampling; non-identification retains its original value. This mapping is output as a structured object and bound to the rule version and effective time, for direct reading and application by the next stage of differential privacy mechanisms.

[0092] After data undergoes security and quality encapsulation at the edge, it is written to four named queues in the isolation buffer: an indicator queue, carrying categorized liquid level, flow, chemical, visual, and meteorological data, along with execution priority and quality labels; a metadata queue, carrying source attribute tag objects; an audit queue, carrying fast checksums, signatures, preorder hashes, and chain numbers; and a privacy queue, carrying a mapping table from location and field sensitivity to perturbation scales and masking strategies. If the receiving end detects that a rule version is outdated, it pauses queuing and automatically pulls a new rule. If the pull fails, the data is transferred to the isolation queue and an event identifier is generated for audit closure. Edge cache is cyclically stored for 48 hours, raw data on the central side is retained for 30 days, and de-identified features are retained for 3 years. These retention periods are written to the meta field for data governance and compliance verification.

[0093] In a 20km long main pipeline demonstration, monitoring nodes were deployed at intervals of 500–1000 meters. Under normal conditions, each channel collected data at a 5-minute cycle and transmitted it back in layers. Under simulated overflow conditions, the liquid level channel triggered high-frequency sampling first and linked visual event uploading. After edge nodes completed classification, source marking, quality control, and two-layer integrity encapsulation according to rules, they enqueued the four types of objects and generated privacy parameter suggestions simultaneously. The fusion module read the four queues and completed synchronization according to the main timeline and cross-source alignment strategy. The differential privacy mechanism implemented hierarchical perturbation and masking based on the suggestion table, and finally output structured, traceable, and auditable standardized input, providing a reproducible data foundation for anomaly identification and subsequent control strategies.

[0094] S2: Apply differential privacy mechanism to the collected multi-source data, add noise perturbation to the classified data while preserving the overall statistical characteristics of the data, and store the perturbed data in groups in an isolation buffer. The specific implementation is as follows:

[0095] After performing differential privacy processing on the classified multi-source data, the results are written to an isolated buffer in groups, and the four types of output mentioned above are read directly: D1 is the classified indicator stream, D2 is the source attribute tag, D3 is the integrity and audit credentials, and D4 is the privacy parameter suggestion table; the goal is to retain as much of the statistical and temporal characteristics required for anomaly identification as possible without exposing sensitive information such as location and device identification, and to establish a closed loop for budgeting, accounting and auditing.

[0096] First, the fields are pruned and time-series aligned to determine the global sensitivity of each field and suppress outliers. Based on the equipment type and dimensions shown in D2, acceptable ranges are set as follows: water level 0 to 5000 mm, flow velocity 0 to 15 m / s, pH 4 to 10, turbidity 0 to 1000 NTU, ammonia nitrogen 0 to 100 mg / L, and total phosphorus 0 to 10 mg / L. These pruning ranges also serve as the upper bound of the global sensitivity; correspondingly, the global sensitivity for water level is set at 5000 mm, flow velocity at 15 m / s, and pH at... 6. Turbidity is set at 1000 NTU, ammonia nitrogen at 100 mg / L, and total phosphorus at 10 mg / L. For time alignment, liquid level and flow rate are aligned with a 15-second sampling period. Chemical data are calculated and output with a 60-second window, and the average and extreme values ​​of the window are output. Visual data only retains the timestamps and event tags of keyframes. For statistics published in the form of window averages, their effective sensitivity is calculated by dividing the global sensitivity by the number of samples in the window. The calculated value and the number of samples in the window are recorded together in the processing metadata for easy subsequent verification.

[0097] Subsequently, the perturbation mechanism and privacy budget were determined, and a unified accounting standard was adopted to avoid ambiguity. Specific mechanisms were selected based on field type and statistical purpose: the Laplace mechanism was used to publish single-point results for point value sequences such as water level and flow velocity; the Gaussian mechanism was used when publishing statistics such as window mean or total amount to better control mean square error; noise intensity was determined based on the ratio between the field's global sensitivity and the privacy budget parameter—the higher the sensitivity or the smaller the budget, the stronger the added noise; budget mapping followed the privacy parameter recommendations output by S1: high-sensitivity locations were allocated a smaller privacy budget and superimposed with larger noise, while medium-sensitivity and low-sensitivity locations were allocated a larger privacy budget and superimposed with smaller noise; the default configuration was 0.5 for high sensitivity, 1 for medium sensitivity, and 2 for low sensitivity, with the Gaussian mechanism's failure probability... The parameter is uniformly taken as 1 multiplied by 10 to the power of -6; the privacy accounting uses the Rényi differential privacy accountant, which accumulates at multiple preset levels and is uniformly converted into an equivalent privacy budget and failure probability at the end of each settlement window to avoid implementation ambiguity caused by the coexistence of different accounting methods; the budget is accumulated at the top of the hour in a fixed 15-minute non-overlapping window, and multiple releases of the same data within the same window share the same budget pool, with a maximum of 20% of the unused budget carried over to the next window; when the privacy parameter suggestion table of S1 is found to be missing or outdated, the system activates a downgrade budget strategy, namely high sensitivity 0.5, medium sensitivity 1, and low sensitivity 2, and pushes a downgrade alarm in the privacy policy release topic (the information channel used to release privacy parameters and alarms) to prompt the rules to be updated as soon as possible;

[0098] Noise generation employs a validated random source, utilizing a deterministic random bit generator compliant with NIST SP80090A. The seed is derived from a hardware entropy source and rotated every 60 minutes. To ensure isolation between different data streams and prevent replay, a namespace identifier is generated for each noise sequence. This identifier is obtained by concatenating the sensor identifier and field name in a fixed order and then calculating a digest. Simultaneously, a monotonically increasing counter value is assigned to each noise output, and this counter is provided as an additional input to the random bit generator. Complete metadata is recorded for each perturbation, including the noise intensity scale, the type of mechanism used, the privacy budget parameter Epsilon, the failure probability parameter Delta, the pruning interval used, the namespace identifier, and the counter value. These records are used for budget accounting and audit trails.

[0099] After adding noise to the truncated data, constrained post-processing is performed to improve usability and suppress systematic bias. First, non-negative constraints are applied to the single-point results of liquid level and flow rate, and monotonic projection of isotropic regression is performed within a short time window. The PAV method is used to maintain physical rationality and avoid unreasonable backsliding. Second, least squares projection with non-negative constraints is applied to the window-level statistics to make the perturbed window mean and total as close as possible to the corresponding statistics without noise within the feasible region, thereby reducing overall bias. For values ​​that still exceed the physical range after adding noise, truncation is performed and marked as truncated in the metadata. At the same time, the weight of such samples is reduced in the window consistency projection to avoid the accumulation of truncation bias. All of the above post-processing is a deterministic projection of the perturbed results, which belongs to the differential privacy post-processing closure and does not weaken privacy guarantees. The methods, parameters and correction error ranges used are recorded through the postprocess field.

[0100] Video data is protected only for metadata, without altering pixel content. Timestamps are downsampled to a 60-second granularity and Gaussian dithering is applied, with a mean of 0, a standard deviation of 15 seconds, and truncation within ±60 seconds. Coordinates use a 50m grid and are injected with a uniform random offset of 0–25m. Keyframe frequency is maintained at 1fps, and event labels are replaced with pseudo-labels instead of direct labels. For the label count and binary event ratio, the count term uses a Laplacian noise reduction mechanism with a sensitivity of 1; the ratio term also uses a Laplacian noise reduction mechanism with a sensitivity equal to the reciprocal of the number of samples within the window. The release threshold is a minimum of 20 samples per group.

[0101] To avoid small sample leakage and reduce correlation risks, when publishing window-level aggregations, the number of samples in a group must be no less than 20; if the threshold is not met, the system will directly return "unavailable" without deducting budget; for multiple queries from the same sensor within the same time window, the system will merge the responses and only provide summary statistical results for that window after the window ends; when a caller initiates a custom sliding window query, the required budget will be linearly amortized according to the overlap ratio between the sliding window and the fixed window; duplicate requests with the same window identifier will be forcibly merged to avoid duplicate budget deductions.

[0102] After the perturbation is completed, the data is grouped according to a unified rule and written and audited in one go. The key used for grouping is the device type and pipe segment number. At the same time, the location sensitivity level and field sensitivity level are retained in the group information for subsequent access control and policy classification. Each group generates a batch object, which includes the perturbed data ontology, a snapshot of the source attributes, metadata about the adopted mechanism and budget, and relevant information for verifying integrity. The batch object is published to four topics with drainage as the prefix through the message middleware: indicator topic, source and processing metadata topic, budget consumption and audit record topic, and privacy parameter and policy update topic. The message body adopts JSON format and UTF-8 encoding. When a single message exceeds the capacity limit, fragmented writing is enabled. The fragment information is marked with three items: fragment identifier, fragment sequence number, and total number of fragments. The receiving end reassembles them in order and verifies the fast check value. Each message carries a fast check value and a digital signature value, and is marked with a window identifier and rule version number.

[0103] The isolation buffer employs packet-based encryption, periodic key rotation, and read-only access strategies. The key for each packet is generated and stored within a hardware security module that complies with FIPS 140-2 requirements. The key rotates every hour; during rotation, the old key is only allowed to be read until it expires, but is no longer used for writing. Data is encrypted using TLS 1.3 during transmission, and data packets include a sending timestamp and a one-time random number. The receiving end only accepts packets whose time difference from the local time is no more than 3 minutes and whose random number has not been used, to prevent replay attacks. Any unauthorized access attempts are logged in the audit log topic, containing the time, source address, and packet identifier, and triggering an alarm. The initial buffer capacity is 10GB, which can automatically expand or shrink based on the data inflow rate to ensure stable concurrent writes during peak periods.

[0104] Budget accounting and audit records are completed synchronously during the writing process, generating a budget ledger record for each disturbance batch. Record items include: request identifier, sensor identifier, corresponding field name, disturbance mechanism used, privacy budget parameter Epsilon, failure probability parameter Delta, pruning interval, noise scale, noise stream namespace, incrementing counter, window identifier, and group identifier. This record is written to both the audit topic and the central audit database to support long-term review. When the budget is exhausted, the query interface returns "unavailable" and initiates rate-limited retry, with a maximum of three retries at intervals of 5 minutes, 10 minutes, and 20 minutes respectively. If still unsuccessful, it guides users to try again in the next budget window or reduces the query granularity. If the version of the privacy parameter suggestion table mentioned above is found to be outdated or missing, the system pushes a downgrade alert in the privacy policy publishing topic and enables the default budget, while temporarily reducing the query frequency until the rules are updated and take effect.

[0105] Set an engineering acceptance threshold for statistical availability, using a fixed-window offline replay set of no less than 100 windows with a duration of 15 minutes as the baseline. The root mean square error of the window mean should not exceed 10% of the corresponding noise-free baseline, and the recall rate of abnormal peaks should not be less than 90%. If the target is not met, the system will prioritize reducing the allowable error of window consistency projection or appropriately expanding the stable range of pruning without increasing the privacy budget, in order to improve statistical availability. All adjustments will be recorded in the privacy policy release topic for subsequent policy tracking and review.

[0106] S3: Extract packet data from the isolation buffer, restrict data access permissions through access control logic, allowing only authorized modules to read specific packets, and transmit the read data to the fusion layer. Specifically, this is implemented as follows:

[0107] Data is extracted from the isolation buffer in read-only mode, and the data sources are limited to four categories: indicator data, source and processing metadata, budget and audit records, and privacy parameters and policy updates; all reads and writes are anchored by window identifiers and rule version numbers to ensure strict correspondence with previous steps in the time calibration and audit chain.

[0108] Access control is implemented using a combination of roles and attributes. In addition to verifying the module role of the requester, it also needs to match the segment number, location sensitivity level, field sensitivity level, window identifier, and rule version number. Access is denied if any condition is not met. Extraction requests must carry a short-term access token in JWT format, issued by the central authorization service and signed with ECDSAP-256. The payload includes the module identifier, allowed group range, allowed window and rule versions, expiration time, random number, and audience field. The default validity period is 5 minutes, with a 60-second clock deviation allowed. The revocation list takes effect immediately. The system supports temporary authorizations for maintenance or emergency use, with a maximum duration of 30 minutes. These authorizations automatically expire and are written to the audit log upon expiration.

[0109] Extraction scheduling prioritizes requests based on demand tags and anomaly types; for example, dynamic indicator groups are prioritized when traffic anomalies occur. To avoid concurrency contention and duplicate extractions, the system establishes a lease for the target group at the start of extraction, with a default lease period of 30 seconds, automatically renewed with a 10-second heartbeat. Each extraction generates a unique extraction identifier, and the idempotent key consists of the extraction identifier and the window identifier. Duplicate requests directly return the previous result summary without further decryption and transmission. A concurrency limit of 5 and a request limit of 10 per second are set for each module. Requests exceeding the limits are queued and retried exponentially in increments of 2, 4, and 8 seconds. When the queue length exceeds the threshold, the system returns to a rate-limiting state and writes it to the audit log.

[0110] Decryption follows the principle of minimization and is only performed after a consistency check passes. Decryption is only allowed if the window identifier and rule version number in the request are completely consistent with the group batch. The decryption scope is limited to the minimum time slice required for this query, with a time slice length of 15 minutes. Decrypted data resides only in memory. After transmission, it is immediately securely zeroed out and the temporary key material and handle are released. The maximum residency time is no more than 60 seconds. If the timeout occurs, it is forcibly zeroed out and a failure is returned. If the version does not match or the permissions are insufficient, the system returns a clear error code and provides the most recently available window and version information, without any downgraded plaintext output.

[0111] Transmissions occur only on a dedicated intranet channel, using TLS 1.3. AES-256-GCM encryption with SHA-384 as the handshake hash is preferred. Data packets consist of a header, a perturbation body, and a checksum. The header includes a group identifier, window identifier, rule version, and transmission identifier. The tail carries a key-based integrity checksum using HMAC-SHA256. The receiving end can only enqueue packets after recalculating the checksum and confirming its consistency; otherwise, the packet is discarded and re-extraction is triggered. A maximum of three retries are allowed, with retry intervals of 1 second, 3 seconds, and 9 seconds respectively. The replay window for random numbers is 3 minutes, and the same random number cannot be reused. If consecutive failures occur, a level-two alarm is triggered, and a maintenance work order is generated.

[0112] Logs and auditing are integrated throughout the entire extraction process. Upon authorization, a log draft is immediately generated, containing module identifier, timestamp, target group, window identifier, rule version number, and operation type. All fields are completed and fixed before decryption and transmission. Logs are divided into 1MB volumes and archived 24 hours apart. Each log entry is hashed and digitally signed, with the hash, signature, pre-hash, and digest persistently stored. Sensitive fields are reversibly anonymized, and key escrow information is recorded for evidence recovery under authorized conditions. The log stream is synchronously written to budget and audit record topics for unified compliance verification and offline playback. Unauthorized attempts and rate-limiting events also enter the audit stream and are broadcast as alerts in the privacy policy publishing topic. Audit logs are retained for 180 days by default, and the log signing key rotates every 90 days. Old signatures are accepted within the rotation window, but newly generated logs are only signed with the new key.

[0113] The output object follows the principle of minimization. The structure submitted to the fusion layer only contains the perturbed indicator data, a necessary subset of the source attributes, window identifier, rule version number, integrity summary, and audit reference, without carrying unnecessary sensitive information such as original coordinates and device serial numbers. Field naming is consistent with the preceding steps to facilitate time alignment and cross-source registration. Transmission uses a structured array, and the message body clearly separates the data segment from the metadata segment. The receiving end completes idempotent enqueueing and order restoration based on the window identifier and rule version number. To avoid duplicate extraction, the receiving end releases the lease immediately after confirming data enqueueing. If a rollback occurs, the lease is retained until timeout or the next retry is completed. Each successfully enqueued batch generates an audit reference and is associated with the corresponding entry in the budget ledger to support end-to-end traceability.

[0114] Failure recovery and policy linkage adopt a unified approach. If integrity verification fails or rule version mismatch occurs, it is recorded as a Level 1 alarm; if three consecutive transmission failures occur, it is recorded as a Level 2 alarm. Both types of alarms are written into the alarm branch of the audit topic and simultaneously broadcast to the privacy policy publishing topic. When the authorization scope changes or temporary authorization takes effect, the privacy policy publishing topic pushes a change message, which takes effect immediately at the next token verification or lease renewal. If the token is about to expire or has been revoked, the system will reject new decryption requests and return a refresh prompt. To control resource consumption, the system implements quota management at both the single module and single pipeline levels. For sudden requests, degraded extraction is performed according to the minimum available batch, but access control and consistency constraints are not relaxed.

[0115] S4: At the fusion layer, perform a standardization transformation on the transmitted data, mapping data from different sources to a unified format space. Then, align these data according to time series, embedding anonymization identifiers during the alignment process. Specifically, this is implemented as follows:

[0116] At the fusion layer, standardized transformation and time-series alignment are performed on the controlled transmission data, and anonymization identifiers are embedded during the alignment process. Compliant data is read only from four categories of topics prefixed with "drainage". Strict screening and verification are performed using window identifiers and rule version numbers as consistency anchors to ensure one-to-one correspondence with the time base and disturbance version of the previous steps. The indicator batches are first written into the transformation queue, and the processing order is determined by combining the grouping information in the source and processing metadata. Dynamic indicators, liquid level, chemical indicators, and video metadata are processed in order of priority. A first-come, first-served strategy is adopted within the same window, and data from the same source is not split across batches.

[0117] The standardized format uses fixed fields and units to eliminate heterogeneous differences. Water level is standardized to meters; when the source is centimeters, it is converted to 100 centimeters equals 1 meter, retaining two decimal places and rounding. Flow rate is standardized to liters per minute; when the source is cubic meters per second, it is converted to 1 cubic meter per second equals 60,000 liters per minute, retaining one decimal place. pH is dimensionless and retains one decimal place. Turbidity is normalized to real numbers between 0 and 1. Specifically, the raw NTU is truncated to the range of 0 to 1000, then divided by 1000 to obtain the standardized result, retaining three decimal places. The truncated values ​​are recorded in the processing summary. The truncation direction is consistent with the standard; ammonia nitrogen and total phosphorus are uniformly expressed as milligrams per liter, both retaining two decimal places; video metadata is quantified using a fixed standard: keyframes are sampled at 1 frame per second, brightness is taken as the average value of the Y channel and linearly normalized to 0 to 1, retaining three decimal places; contrast is taken as the standard deviation of brightness and normalized to 0 to 1; motion vectors are taken as the average displacement amplitude based on block matching between adjacent keyframes and normalized to 0 to 1; when a keyframe is missing in a certain second, the value of the previous second is used, and if there are more than 60 consecutive missing keyframes, it is marked as a default; all conversions record the original unit, target unit, and rounding digits in the change metadata and write it into the processing summary to support verification;

[0118] Missing measurement points are uniformly represented in memory as IEEE 754 non-numerical values, written as null during JSON serialization, serving as placeholders but not participating in statistical calculations such as mean, variance, and extreme values; the processing summary adds a missing value flag for each missing value and accumulates the count; out-of-bounds values ​​are truncated to a defined interval before entering the unified format space, and the truncation flag, original value, and upper and lower limits of the truncated interval are recorded to facilitate subsequent statistical bias auditing; the unified format space is carried by a two-dimensional array, with rows corresponding to time scales, and columns in a fixed order: water level, flow rate, pH, turbidity, ammonia nitrogen, total phosphorus, video brightness, video contrast, and video motion vector, and additionally retains anonymization tags, window identifiers, rule version numbers, integrity summaries, and audit references; numerical columns are all stored using 32-bit floating-point, and string columns use unified encoding; if a data source does not exist in a certain window, no new column is added for that source, only a default flag is filled in the corresponding column to maintain the stable column order;

[0119] Time series alignment is performed within a unified space, with a fixed 10-second step time axis anchored to the preceding network time synchronization benchmark. The default time zone is East 8, with a maximum allowable deviation of 1 second. Alignment priority is given in the following order: flow rate, water level, water quality, and video metadata. Priority sources are aligned first, and then other sources are synchronized using these as anchors. At each time scale, if multiple records appear for the same source, only the one with the closest time is retained, and the rest are discarded with a cumulative duplicate discard count. If a source is missing at a certain scale, flow rate and water level are allowed to be linearly interpolated, with a maximum span of 30 seconds. If the span exceeds 30 seconds, it is recorded as a default, and the interpolation flag and span number of seconds are recorded in the processing summary. Water quality and video metadata are held forward, with a maximum holding time of 60 seconds. If the span exceeds 60 seconds, it is recorded as a default, and the holding flag and span number of seconds are recorded. Cross-window data merging is strictly prohibited. The window identifier and rule version number of each row must be completely consistent with the input batch. Inconsistent rows are directly rejected and an audit entry is generated. After alignment, a two-level consistency check is performed: first, the field range and decimal places are checked, and then the consistency anchor is checked. Only data that passes the check is included in the matrix construction.

[0120] During the alignment process, an anonymized identifier is generated for each time scale. The system uses a key-based message authentication method to calculate a digest for the window identifier, group identifier, time scale, and sequence number, and takes the first 16 hexadecimal characters as the row-level label. The label is only used for row association and replay on the model side, does not contain the original device identification information, and does not reveal the source. If traceability is required, a mapping can be completed through audit reference in an authorized environment. Each row output carries the window identifier, rule version number, and integrity digest to ensure consistency with the previous perturbation version and its audit chain. The key material used to generate the label is managed and rotated by the audit domain and is not persisted in this module. The matrix only retains the generated label values.

[0121] The matrix is ​​constructed with time-scaled rows and a fixed column order, which remains unchanged. Numerical columns are rounded uniformly: water level is rounded to two decimal places, flow rate is rounded to one decimal place, and other chemical and video-related values ​​are rounded to the number of decimal places specified above. The matrix follows the principle of minimization, excluding unnecessary sensitive information such as original coordinates, equipment serial numbers, sensor installation angles, and original timestamps, as well as undisturbed values ​​or data outside the window. Before output, the window identifier and rule version number are checked line by line to ensure they match the input. Any inconsistent lines are removed before output, and the reason for removal is written into the audit reference for subsequent traceability.

[0122] The memory cache is used to support short-term reuse and batch processing acceleration. The cache is granular with a window size and a maximum lifespan of 5 minutes or one inference batch completion, whichever comes first. For duplicate requests with the same window and rule version number, if the cache is hit, the cache is returned directly. The cache expires immediately and is rebuilt according to the window size when the lifespan expires or a version change occurs. The cache adopts the least recently used strategy, and the window cache limit is 100. When the cache is evicted, the anonymized tag index and internal pointer associated with the window are cleared simultaneously. If the cache is missed and reconstruction still fails, the system returns a service unavailable error to the caller with an error description of reconstruction failure, and generates a severity-level alarm entry to notify the upstream to adjust the strategy or queue.

[0123] In the demonstration project, the main road sample window formed 500 rows and 14 columns on a 10-second time axis. After converting the water level from centimeters to meters, the difference from the mean of the reference baseline was less than 0.01 meters; after converting the flow rate from cubic meters per second to liters per minute, the peak error was less than 0.5; the truncation ratio of turbidity after normalization did not exceed 1%; after unifying the video metadata to 1 frame per second, the missing filling ratio did not exceed 2%; end-to-end standardization and alignment were completed in about 1.5 seconds, and all output rows passed the consistency anchor check and carried an integrity summary and audit reference, which could be directly used by the subsequent feature extraction module.

[0124] S5: Construct an anomaly detection model based on the fused dataset, input the aligned data into the model for feature extraction and pattern matching, classify and judge potential abnormal operating conditions, and simultaneously record privacy compliance logs during the judgment process. The specific implementation is as follows:

[0125] An anomaly detection model is built on the controlled matrix output by the fusion layer. Feature extraction and pattern matching are performed on the aligned data to classify and judge potential abnormal conditions. Privacy compliance logs are recorded synchronously throughout the process. This step only accepts the fixed key name matrix produced above. If any field outside the whitelist appears or any whitelist field is missing, the batch is rejected and an architecture mismatch error is recorded. Before entering the model, integrity digest verification is performed on each batch. The integrity digest is a 256-bit hexadecimal string generated using a secure hash algorithm. Each row in the batch is recalculated and compared. If any row is inconsistent, the entire batch is rejected and a level 1 alarm is written. At the same time, the row number of the first inconsistent row, the expected digest, and the actual digest are recorded. All rows in the batch must have the same window identifier and rule version number. Any inconsistency is rejected. Missing tests are represented in memory as non-numerical values ​​and expressed as null values ​​in the structured objects of the output and logs. They are not included in the calculation of mean, variance, threshold hit and score, nor are they included in the sample coverage.

[0126] The model initializes by loading a multi-layered processing chain: the first layer focuses on liquid level and flow rate to capture hydraulic abrupt changes; the second layer focuses on water quality to identify chemical anomalies; and the third layer focuses on video metadata to supplement structural and motion background. Dimension priority relationships and linkage rules are derived from the operating condition library and take effect during initialization along with the threshold and category tables. Input is processed in rolling batches with a default batch size of 10 rows, injected from earliest to latest time to maintain causal order. When the percentage of valid samples in a batch is less than 70%, the batch is marked as undecidable and added to the retry queue, retrying up to 3 times at intervals of 1 minute, 3 minutes, and 9 minutes. If the model is still undecidable after retrying, the output is "Undetermined label," the score is 0, and the reason field is marked as "insufficient samples."

[0127] Feature engineering employs a sliding window combined with robust statistics, with a window length of 60 seconds and a step size of 10 seconds. For water level and flow rate sequences, first-order differences, three-point rolling means, and three-point rolling medians are calculated, and standardized residual estimation is performed using the median absolute deviation to identify sudden increases and decreases as well as persistent shifts. For pH, turbidity normalized values, ammonia nitrogen concentration, and total phosphorus concentration, the mean, standard deviation, and threshold exceedance ratio within the window are calculated, where the threshold exceedance ratio refers to the percentage of samples falling into the alarm interval. For video brightness, video contrast, and video motion intensity, window energy and coefficient of variation are calculated, and short-term stability is provided to characterize rapid fluctuations in illumination and motion changes. Within the window, missing data is statistically analyzed using available samples; if the effective sample coverage is less than 70%, the feature is set to default and the reason for indeterminacy is recorded. All derived features undergo robust truncation before write-back, limiting the absolute value of the standardized score to no more than 6, and the number of truncations is included in the metrics and written into the audit reference.

[0128] Pattern matching is divided into two levels: first, single-dimensional hits are performed, followed by cross-dimensional verification. In the single-dimensional hit stage, each feature is compared with the prior patterns in the operating condition database: a sudden increase in liquid level accompanied by a decrease in flow rate is identified as a blockage candidate; a continuous rise in liquid level with enhanced video motion is identified as an overflow candidate; and an increase in the proportion of ammonia nitrogen or total phosphorus exceeding the threshold in the water quality is identified as a pollution candidate. The cross-dimensional verification stage is used to eliminate isolated noise: when liquid level is matched but flow rate does not decrease and there is no enhanced motion in the video, the conclusion is downgraded to suspected and a low-confidence prompt is output; when water quality is matched but liquid level and flow rate remain stable, the conclusion is changed to pending verification and added to the observation queue. Matching rules are managed by configuration files, and priority chains are loaded from the operating condition database: overflow judgment prioritizes the joint chain of liquid level and flow rate, blockage judgment prioritizes the joint chain of flow rate and video, and pollution judgment prioritizes the slight linkage chain between water quality and liquid level or flow rate.

[0129] The classification judgment uses weighted aggregation and introduces hysteresis control. The default weights are level 0.4, flow rate 0.3, water quality 0.2, and video 0.1. An alarm is triggered when the comprehensive score reaches 0.7 and cleared when it is below 0.5. After the alarm is triggered, it is maintained for at least two windows, and is only cleared when the score of two consecutive windows is below 0.5. When the confidence of any single dimension exceeds 0.9, the single dimension priority rule is triggered. A temporary alarm is generated first, and cross-dimensional confirmation is performed in the next window. If the confirmation fails, it is automatically canceled. In case of multiple class conflicts, the score takes precedence. When the score difference is less than 0.05, the decision is made according to the fixed priority order of blockage, overflow, leakage, and pollution, and the second-best category is output as a candidate label. The hysteresis state is recorded in the metric to suppress frequent switching.

[0130] The operating condition database and thresholds adopt semantic version management and canary release. The abnormal modes cover threshold ranges and linkage rules for categories such as blockage, overflow, leakage, and pollution, and are updated once a month by default. New versions are first tested in a 10% window for 24 hours. During the test run, the false alarm rate is required to be no higher than 5%, the false negative rate is no higher than 10%, and the AUC of the test set is no lower than 0.90 before full switch can be made. If any indicator fails to meet the standard, the system will be rolled back immediately, and the version change and rollback event will be recorded in the audit topic.

[0131] Training and calibration are divided into two paths: offline and online. Offline training uses a labeled historical window of the past 12 months, with the most recent 2 months used as a validation set to evaluate generalization performance. To align the predicted probability with the actual frequency of occurrence, the output score is calibrated by temperature scaling, and the target calibration error during the validation phase is controlled within a predetermined threshold. During the online phase, input distribution drift and label drift are monitored simultaneously. Distribution indices are calculated daily for three items: water level, flow rate, and turbidity normalized value, with the baseline distribution updated on the first day of each month as a reference. When any distribution index exceeds 0.2 for 3 consecutive days, a calibration suggestion is triggered and the historical prior weight is automatically reduced. At the same time, a prompt message is written into the privacy policy release channel so that maintenance personnel can follow up.

[0132] Privacy compliance logs are embedded throughout the model chain. Fixed fields in the log objects include timestamp, stage identifier, window identifier, rule version number, audit reference, compliance flag, reason summary, metric, model version, condition database version, and digital signature. The compliance flag is derived from three checks: disturbance coverage check, minimized output check, and consistency anchor check. The reason summary records the basis for passing or issuing a warning. Metrics include at least the percentage of valid samples, truncation count, hysteresis status, and batch default ratio. Logs are asynchronously written to the audit database and audit topic via a background thread, without blocking the inference process. Version mismatch, integrity verification failure, or trial failure will trigger an alarm level.

[0133] System performance and fallback strategies are configured around engineering reachability, with a single-window inference budget of 50 milliseconds and an end-to-end time from batch entry into the queue to output determination of no more than 3 seconds. When the load exceeds the budget, the batch size is reduced from 10 rows to 5 rows, and video features are temporarily disabled to ensure timeliness while maintaining the integrity of the main dimension. When the 95th percentile latency within the last 5 minutes falls below 3 seconds, the default batch size and video feature participation are automatically restored. The model buffer is dynamically expanded by batch, intermediate tensors are not persisted to disk, and temporary data and handles are cleaned up immediately after processing to shorten the recycling path and reduce the exposure surface.

[0134] The output is a structured response, including labels, scores, suboptimal labels, explanation summaries, window identifiers, rule version numbers, audit references, and latency in milliseconds. The explanation summary must include at least a list of key features, the hit rule number, hysteresis status, drift flags, and sample coverage. The number of key features shall not exceed 5, and each feature shall be given its name and direction. The response is transmitted downstream through the same encryption and integrity verification channel as described above, and the log summary is written to the audit topic in parallel to ensure reproducibility and traceability in subsequent report generation and policy closure.

[0135] S6: Generate an identification report based on the classification results, feed the report back to the system control terminal, verify the effectiveness of the privacy mechanism in the feedback loop, and apply the adjusted protection logic to the data collected in the next cycle. Specifically, the implementation is as follows:

[0136] Based on the classification results above, an identification report is generated, receipt verification and parameter distribution are completed, and the effectiveness of the privacy mechanism is verified in the feedback loop. The adjusted criteria are applied to the collection and extraction chain in the next cycle. The report uses a fixed key name. The severity grading rules are as follows: when the score is not lower than 0.80, it is recorded as high-level; when the score is between 0.60 and 0.79, it is recorded as medium-level; when the score is between 0.50 and 0.59, it is recorded as low-level; scores below 0.50 are only registered as observation items and no formal report is generated. The recommended measures are provided by the measure recommendation mapping table, which records fields such as rule number, applicable type, severity level, corresponding handling recommendation, table version number, and effective time. When the working condition database version changes, the measure recommendation mapping table is updated synchronously. If an inconsistency is found, the report is rejected and a level 1 alarm is recorded.

[0137] The report is primarily formatted using Extensible Markup Language (XML), with the root element named "report". A JavaScript object representation version with identical content is also generated, uniformly encoded in UTF-8. The report number consists of the prefix "RP" followed by the year, month, day, hour, minute, second, and sequence number, ensuring no repetition globally. The occurrence time is taken from the system's base clock and is consistent with the network time synchronization service mentioned earlier, with the default time zone being East 8. The maximum allowed deviation is one second. If this deviation is exceeded, the report is marked as clock drift and transferred for manual review. The report body must include a window identifier, rule version number, and audit references. It also saves a list of hit rule numbers and a summary of key features, facilitating tracing back from the report to the corresponding batch in Example 5.

[0138] The report is published via the intranet message bus. The control end should return a receipt within 1 second. If no receipt is received within the specified time, the system will retry three times at 2 seconds, 5 seconds, and 15 seconds respectively. If it still fails, a level 2 alarm is recorded, and the report is sent to the manual review queue. To avoid duplicate execution, the system sets a 5-minute idempotent window. If the same report unique identifier is received again within this window, only the existing receipt and processing result are returned, without re-issuing or writing to the database. The message bus is configured with dead-letter routing. Failed messages are retained for 24 hours and are allowed to be manually resent a maximum of three times. The maximum size of a single message is 1MB. When the maximum size is exceeded, fragmented transmission is used. The fragment size is 256KB, and each fragment carries a fragment sequence number and the total number of fragments. The control end reassembles the fragments in sequence and performs integrity verification before processing them in the database.

[0139] Parameters are issued, and each change is written to the configuration change history table. The record fields include timestamp, report number, scope, parameter name, old value, new value, and operator. Distributed mutex locks are enabled for the same scope to ensure that only one change is executed at a time. If the lock times out, the operation is revoked and an alarm is generated. When the working condition database or privacy policy is switched, changes are only performed on reports and parameters that are consistent with the current rule version. Old version reports that arrive late are only archived and saved, and no further configuration updates are triggered. If subsequent verification fails or performance degradation occurs, the system immediately restores the original parameter values ​​and notes the source version and the restored version in the record.

[0140] Privacy verification is conducted on the batches of data associated with the report and their upstream processing links, and is checked according to four essential indicators: First, noise coverage, which refers to the percentage of records within this window that meet the predetermined noise threshold, with a passing standard of no less than 95%. Second, minimization check, which confirms that the report and parameter distribution information only use location aliases and necessary fields, and do not contain coordinates, device serial numbers, or any unperturbed raw values. Third, consistency check, which requires that the window identifier and rule version mentioned above be completely consistent. Fourth, access scope check, which requires that only two roles in the minimum authorized set can access the corresponding group, namely the fusion module and the audit module, and that there should be no abnormal behavior of retrying after being rejected in the access log. If all four indicators are met, the application is deemed to have passed; if any indicator fails to meet the standard, a warning is issued, and the problem location, cause, and rectification suggestions are listed.

[0141] Based on the verification results, an adjustment plan will be formulated and executed according to the plan in the next cycle. If the noise coverage is below 95%, the privacy budget intensity for the corresponding source category will be increased: the noise scale will be appropriately increased by 10% for fields using the Laplace mechanism, and the noise standard deviation will be increased by 10% for fields using the Gaussian mechanism. At the same time, access authorization will be tightened to the necessary role set. If the coverage is not lower than 98% for two consecutive cycles, the above increment will be rolled back by 5% to ensure availability. In terms of access control, the role permissions mentioned above will be tightened simultaneously, and the validity period of temporary authorization will not exceed 30 minutes. The adjustment will be released in stages: first run for 30 minutes on 10% of the node subnet. When the coverage is not lower than 95%, all minimization checks pass, the 95th percentile of the end-to-end latency is not higher than 3 seconds, and there are no secondary alarms, the scale will be expanded to 50%, and then rolled to the entire network. If the above conditions are not met in any stage, the release will be stopped and rolled back to the previous stable configuration. At the same time, the degraded state and cache that have not yet taken effect will be cleaned up.

[0142] Regarding security and retention, before transmission, reports and verification summaries generate an integrity digest and attach a digital signature. The digest algorithm is SHA-256, and the signature algorithm is ECDSAP-256. The control end only allows data to be stored after the signature is verified. Data is retained for 30 days in hot storage and 180 days in cold archiving. Static storage uses AES-256 encryption, and the key is managed by a hardware security module and rotated daily. The archive is simultaneously written to an audit index, supporting fast retrieval and playback by report identifier, window identifier, and version rule number. The serialization size of the interpretation digest is capped at 2KB. If the limit is exceeded, truncation is performed, and the digest is marked as truncated, retaining only the first 5 key features and the first 5 rule numbers.

[0143] In the demonstration project, section A of the main road was identified as overflowing, generating a report of type OVERFLOW, with the location identified as section A, a score of 0.92, and a severity rating of high. Approximately 180 milliseconds after the report was published, a confirmation was received. The control unit then increased the sampling frequency of water level and flow rate from once every 30 seconds to once every 15 seconds and wrote the change record to the configuration change history. Privacy verification results showed a noise coverage rate of 97%, and the minimization check, consistency check, and access range check all passed. The adjustment strategy was first run on 10% of the node subnet for 30 minutes, expanded to 50% after acceptance testing, and finally implemented across the entire network; the end-to-end closed-loop time was approximately 2 seconds. The report, verification summary, and parameter history have all been stored in the database and can be traced back to the rule-matching records in Example 5 by report number and window number.

[0144] The scheme in this embodiment first collects multi-source data, including water level, flow rate, water quality, and video information, through sensor nodes deployed in the urban drainage network, and performs preliminary classification and source attribute labeling. Then, a differential privacy mechanism is applied to this data, adding noise perturbations to mask sensitive features while preserving statistical characteristics, and the data is grouped and stored in an isolated buffer. When retrieving grouped data from the buffer, access control logic is implemented, allowing only authorized modules to read specific groups, and the data is encrypted and transmitted to the fusion layer. At the fusion layer, a standardization transformation is performed, mapping different source data to a unified format space, aligning them by time series to form a fused dataset, and embedding anonymized identifiers in the alignment. Based on this dataset, an anomaly detection model is built, performing feature extraction and pattern matching to classify and judge potential abnormal operating conditions, and simultaneously recording privacy compliance logs. Finally, an identification report is generated based on the judgment results, fed back to the control terminal to update the collection parameters, verify the effectiveness of the privacy mechanism, and adjust the protection logic for the next cycle accordingly, achieving closed-loop optimization of the system. Through layers of privacy protection, data fusion is ensured to be secure and efficient.

[0145] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0146] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0147] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0148] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0149] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0150] In addition, the functional modules in the embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0151] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0152] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included 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.

[0153] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for identifying abnormal operating conditions in drainage systems based on a data fusion model, characterized in that, include: S1: Collect multi-source data from the drainage system, perform preliminary classification of the multi-source data and label its source attributes, collect multi-source data from the drainage system, deploy sensors and edge nodes at key locations; set up water level channels, flow channels, water quality channels and visual channels, uniformly perform time calibration, and apply adaptive sampling strategies; Perform preliminary classification at edge nodes and generate source attribute tags; implement primary / backup redundancy and data integrity auditing; perform quality control and privacy parameter recommendations; write the classified data, source tags, audit logs, and privacy recommendations into an isolation queue; S2: Apply differential privacy mechanism to the collected multi-source data, add noise perturbation to the classified data, while retaining the overall statistical characteristics of the data, and store the perturbed data in groups in an isolated buffer. S3: Extract packet data from the isolation buffer, restrict data access permissions through access control logic, allow only authorized modules to read specific packets, and transmit the read data to the fusion layer. Extract packet data from the isolation buffer in read-only mode; use a combination of role and attribute access control to verify the requester's permissions. Extraction priority is determined based on demand tags and leases are established; decryption is limited to the minimum time slice after consistency verification is passed; perturbation data and necessary metadata are transmitted through a dedicated intranet channel; logs are recorded throughout the extraction process and digitally signed; the output object submits a structured array to the fusion layer. S4: At the fusion layer, the transmitted data undergoes a standardization transformation, mapping data from different sources to a unified format space. This data is then aligned according to time series, with anonymization identifiers embedded during the alignment process. Compliant data is read from the isolation buffer and filtered and verified using window identifiers and rule version numbers as consistency anchors. Indicator batches are written to the transformation queue, and the processing order is determined by combining source metadata. Standardization transformation is performed, mapping data from different sources to a unified format space and eliminating heterogeneous differences using fixed field unit calibers. Missing test points and out-of-bounds values ​​are handled, and relevant flags and original information are recorded in the processing summary. Data is aligned according to time series and synchronization is driven by priority. Anonymization identifiers are embedded during the alignment process, and row-level labels are generated for model-side association. S5: Construct an anomaly identification model based on the fused dataset, input the aligned data into the model for feature extraction and pattern matching, classify and judge potential abnormal operating conditions, and record privacy compliance logs simultaneously during the judgment process; S6: Generate an identification report based on the classification results, feed the report back to the system control terminal, verify the effectiveness of the privacy mechanism in the feedback loop, and apply the adjusted protection logic to the data collected in the next cycle.

2. The method for identifying abnormal operating conditions of a drainage system based on a data fusion model according to claim 1, characterized in that, Differential privacy mechanisms are applied to the collected multi-source data, adding noise perturbations to the classified data while preserving the overall statistical characteristics of the data, including: Read the categorized metric stream, source attribute tags, integrity credentials, and privacy parameter suggestion table. Perform range pruning on the field and complete time sequence alignment; Choose either the Laplace or Gaussian mechanism based on the field type and statistical purpose; Establish a privacy budget and adopt a consistent accounting approach; Generate noise and add it to the cropped data; Post-processing for performing nonnegative constraints and monotonic projections.

3. The method for identifying abnormal operating conditions of a drainage system based on a data fusion model according to claim 1, characterized in that, The perturbed data is grouped and stored in an isolation buffer, including: Temporal downsampling and coordinate gridding are performed on video metadata; Add noise to the tag count and ratio; Set a threshold for grouped samples and merge duplicate requests; Data is grouped by equipment type and pipe section number; Generate batch objects and publish them to the corresponding topic; The encryption and key rotation strategy is used to store the data in an isolated buffer. Budgetary accounting and audit records are completed simultaneously.

4. The method for identifying abnormal operating conditions of a drainage system based on a data fusion model according to claim 1, characterized in that, An anomaly detection model is built based on a fused dataset. The aligned data is input into the model for feature extraction and pattern matching, including: An anomaly detection model is built on the fused dataset, and the aligned data is input into the processing chain. Load a multi-layered processing chain targeting liquid level, flow rate, water quality, and video to capture mutations and anomalies; Data is injected using a rolling batch method, and the integrity summary is verified to be consistent with the window. By using a sliding window combined with robust statistical methods, first-order difference, rolling mean, standardized residuals, and coefficient of variation are extracted. Perform pattern matching between single-dimensional features and the working condition database, and perform cross-dimensional verification to remove noise.

5. The method for identifying abnormal operating conditions of a drainage system based on a data fusion model according to claim 1, characterized in that, Potential abnormal operating conditions are categorized and assessed, and privacy compliance logs are recorded simultaneously during the assessment process, including: We employ weighted aggregation to introduce hysteresis control to classify and judge potential operating conditions and handle multiple types of conflicts; Semantic version management is linked to the threshold range rules for updating the working condition database through canary releases; Perform offline training using historical window labeled data and monitor input distribution drift using online calibration; Privacy compliance logs are recorded synchronously at each stage of the process; The generated structured response is then passed downstream.

6. The method for identifying abnormal operating conditions of a drainage system based on a data fusion model according to claim 1, characterized in that, Based on the classification results, an identification report is generated and fed back to the system control terminal. The effectiveness of the privacy mechanism is verified in the feedback loop, and the adjusted protection logic is applied to the data collected in the next cycle, including: A comprehensive identification report is generated based on the classification results, using Extensible Markup Language (Extensible Markup Language) format and an attached digital signature. The report is sent to the system control terminal via the intranet message bus, and a confirmation is received before the retry mechanism is executed. Privacy mechanism verification is performed on associated batches in the feedback loop, including noise coverage minimization check, consistency check, and access scope check. Based on the verification, an adjustment plan will be developed and applied to the collection and extraction process in the next cycle in a phased release manner.

Images