Dioxin real-time monitoring data cloud management and retraining system

Abstract

A dioxin real-time monitoring data cloud management and retraining system comprises an edge monitoring device deployed in a pollution source site and a cloud management platform deployed in a cloud server, the edge monitoring device collects working condition parameters related to dioxin emission, and the working condition parameters related to dioxin emission are predicted through a built-in dioxin prediction model. Reasoning the collected data in real time to obtain a concentration prediction result, sending the collected data and the concentration prediction result to the cloud management platform, and receiving a model updating instruction of the cloud management platform; and the cloud management platform performs incremental retraining on the current dioxin prediction model by using the historical data in the historical database to obtain an updated dioxin prediction model, and sends the dioxin prediction model passing verification to the target edge monitoring device. A closed-loop evolution pollutant monitoring system is created, high-precision dioxin monitoring is maintained at low cost, the intelligent level and reliability of environmental monitoring are greatly improved, and the method has remarkable environmental and social benefits.

Description

Technical Field

[0001] This invention relates to the field of environmental pollution monitoring technology, and more specifically, to a cloud-based system for real-time dioxin monitoring data management and retraining. Background Technology

[0002] Dioxins are highly toxic and persistent organic pollutants, primarily emitted from industrial processes such as waste incineration. Due to their extremely low concentrations and complex detection methods, real-time monitoring is extremely challenging. Traditional methods typically rely on laboratory analysis after sampling, which cannot provide timely feedback on changes in emission levels, limiting effective emission control and reduction measures. To overcome the challenges of real-time monitoring, predictive emission monitoring systems (PEMS) and other soft-sensoring methods have emerged in recent years. These systems indirectly estimate dioxin emission concentrations by monitoring process parameters such as incineration temperature, pressure, and flow rate using machine learning models. However, existing PEMS systems are complex, expensive, and difficult to implement, requiring periodic retraining and calibration by supplier professionals to adapt the model to real-world operating conditions. This reliance on manual parameter tuning and offline calibration is not only time-consuming and labor-intensive but also struggles to respond promptly to changes in operating conditions.

[0003] Dioxins are typical persistent organic pollutants, and their formation and emission processes exhibit significant operational condition dependence and time lag. On the one hand, the formation and resynthesis of dioxins are coupled with multiple factors, including combustion zone temperature, flue gas residence time within the dioxin resynthesis sensitive temperature range, chlorine-containing components in the flue gas, catalytic heavy metals, and activated carbon injection. These operational variables show a strong nonlinear correlation, with the dioxin resynthesis sensitive temperature range being approximately 200℃–450℃. On the other hand, dioxin emission levels are typically obtained offline through laboratory methods such as high-resolution chromatography / mass spectrometry, resulting in a time lag of several hours or even days between sampling and obtaining the toxicity equivalent (TEQ) result. This leads to a misalignment between online operational data and actual emission labels on the timeline. Existing online prediction methods based on empirical formulas or simple statistical models struggle to effectively address the aforementioned strong coupling, multivariate nature, and label lag issues. If the model does not match the operational conditions, it can easily lead to prediction distortion or even misjudgment of emission risks.

[0004] Meanwhile, the data dependency problem of machine learning models is particularly prominent in environmental monitoring. Due to the scarcity of real dioxin emission data, existing emission prediction models are often trained only on limited historical data, resulting in insufficient generalization ability and difficulty in maintaining long-term accuracy. Even if the initial model performs well under experimental conditions, its performance will gradually decline once deployed in the field due to changes in combustion conditions, waste composition, and other factors. A common practice is to train the model offline and then deploy it directly to the device. However, models obtained with fixed training samples may not be able to adapt to the data distribution under different scenarios in the future. Changes in the application scenario of the model will lead to performance degradation, making it difficult to meet the needs of the field in a timely manner. Therefore, how to maintain the predictive accuracy of the model after deployment has become an important challenge in the field of environmental monitoring.

[0005] With the development of the Internet of Things (IoT) and cloud computing, cloud-edge collaborative model update frameworks are beginning to be applied across various fields. The cloud, with its powerful storage and computing capabilities, can collect monitoring data from multiple edge devices and use this data to retrain and iterate AI models, incorporating new information into the models. The updated models are then synchronously distributed to the edge devices, ensuring that the devices are always running the latest optimized algorithms and maintaining the accuracy of the inference results. This architecture of real-time edge inference combined with continuous cloud training is crucial in dynamic IoT environments, enabling the system to cope with rapidly changing conditions. For example, reports indicate that continuous cloud training and optimization of AI models, followed by pushing updated models to edge devices, enables the continuous evolution of the entire system, improving monitoring accuracy and response speed. However, in the field of environmental monitoring, existing publicly available solutions often focus on one-time model optimization or algorithm improvements, such as introducing fuzzy control to enhance model accuracy, but lack adaptive update mechanisms for on-site data after deployment.

[0006] Therefore, the existing technology has problems and needs further improvement and development. Summary of the Invention

[0007] (I) Purpose of the invention: In order to solve the problems existing in the prior art, the purpose of this invention is to provide a pollutant monitoring platform that can continuously evolve itself, overcome the defects of static solidification of traditional models, realize learning while running, and provide a high-precision, low-cost, and easy-to-maintain cloud management and retraining system for real-time dioxin monitoring data for environmental protection monitoring.

[0008] (II) Technical Solution: To address the aforementioned technical problems, this technical solution provides a cloud-based management and retraining system for real-time dioxin monitoring data, comprising edge monitoring equipment deployed at the pollution source site and a cloud management platform deployed on a cloud server. The edge monitoring device includes a sensor assembly, an edge computing unit, a first communication unit, and a model update unit. The sensor assembly collects operating parameters related to dioxin emissions to obtain collected data. The edge computing unit uses a built-in dioxin prediction model to infer concentration prediction results from the collected data in real time. The first communication unit sends the collected data and concentration prediction results to the cloud management platform and receives model update instructions from the cloud management platform. The model update unit verifies the updated dioxin prediction model sent by the cloud management platform and replaces the old dioxin prediction model, thereby upgrading the dioxin prediction model. The cloud management platform includes a data management subsystem, an anomaly detection subsystem, a model training subsystem, a model version management subsystem, and a model distribution subsystem. The data management subsystem stores and cleans collected data, constructing a timestamped historical database. The anomaly detection subsystem monitors for prediction errors exceeding limits or data distribution drift, triggering model retraining requests. The model training subsystem uses historical data from the historical database to incrementally retrain the current dioxin prediction model, obtaining an updated dioxin prediction model. The model version management subsystem stores dioxin prediction model version information and verifies the accuracy of the new dioxin prediction model. The model distribution subsystem sends the verified dioxin prediction model to the target edge monitoring device.

[0009] The operating parameters related to dioxin emissions collected by the sensor assembly include at least the following: temperature of the high-temperature combustion zone in the furnace, flue gas temperature and residence time in the dioxin resynthesis sensitive temperature zone, oxygen content in the flue gas, characteristic parameters of chlorine content in the flue gas and / or their proxy variables, proxy variables reflecting the presence of catalytic heavy metals, flue gas velocity, furnace negative pressure, activated carbon injection rate, and inlet temperature of the bag filter.

[0010] The sensor assembly further includes a data preprocessing module, which preprocesses the collected data before the edge computing unit performs real-time inference on the collected data, including outlier filtering, time synchronization, and data standardization.

[0011] The model update unit verifies the integrity of the updated dioxin prediction model sent by the cloud management platform through hash verification.

[0012] The anomaly triggering mechanism of the anomaly detection subsystem includes, Data acquisition layer anomaly triggering retraining: sensor fault detection, identifying abnormal signals output by sensors; human intervention identification, detecting unnatural features in the data; Data feature layer anomaly trigger retraining: Data distribution drift detection, which calculates the statistical distribution change of input features using the population stability index PSI or KL divergence, and triggers when the distribution difference exceeds a preset threshold; Time series fluctuation detection, which calculates the volatility and autocorrelation coefficient of data through a sliding window to identify short-term drastic changes; Emission level compliance detection, which monitors the fluctuation of emission results and triggers when it exceeds a preset compliance threshold. Model performance layer anomaly triggers retraining: Prediction error exceeding limit detection, calculates the deviation between the predicted value and the historical average / actual value, and triggers when the deviation exceeds a preset threshold; Model self-checks decreased accuracy, evaluates model accuracy through cross-validation or independent hold-out set, and automatically enters the retraining queue when the core indicators are lower than the preset threshold.

[0013] The model training subsystem employs at least one of the following methods for retraining: Incremental learning: Fine-tuning model parameters using new data while retaining knowledge from the old model; Transfer learning: When real dioxin label data is lacking, simulated data under similar operating conditions or labeled data from other devices are used as approximate labels; Federated learning: Jointly trains models by aggregating parameters or averaging gradients, while protecting the data privacy of edge monitoring devices; Algorithm support: Model training can be performed using SGD optimization algorithm, LSTM / CNN neural network or ensemble learning algorithm.

[0014] Federated learning includes the following steps: The cloud management platform sends initial model parameters to the edge monitoring devices; Edge monitoring devices use local data to train models and upload them for parameter updates; The cloud management platform aggregates parameter updates from various edge monitoring devices to generate a globally applicable dioxin prediction model.

[0015] The model training subsystem verifies the dioxin prediction model obtained through incremental retraining, and the verified dioxin prediction model becomes the updated dioxin prediction model. Validating the dioxin prediction model obtained through incremental retraining includes: cross-validation: dividing the dataset into multiple subsets and using them alternately as the training and validation sets to evaluate the model's generalization ability; and setting aside a validation set: dividing an independent validation set from historical data and comparing the accuracy of the new and old models on the validation set to ensure that the updated model has better performance.

[0016] The model version management subsystem further includes: Version rollback function: When the accuracy of the new dioxin prediction model does not meet the requirements, it supports rolling back to a historical stable version; at the same time, performance indicators are recorded for version comparison. Hash verification mechanism: The model file of the dioxin prediction model is hash-signed to ensure the integrity of the dioxin prediction model during transmission and storage; Performance metrics record: Store key metrics for the dioxin prediction model.

[0017] The edge computing unit includes a time scheduling module, which identifies idle time segments between real-time inference tasks and executes non-real-time auxiliary tasks within these idle segments. Specifically, the time scheduling module includes the following steps: The time scheduling module identifies the core tasks of the edge monitoring device and splits and adapts the non-real-time auxiliary tasks before embedding them for execution. Then, the long-running non-real-time auxiliary tasks are broken down into micro-tasks with fixed durations, and the number of micro-tasks is allocated according to the idle window duration.

[0018] The process of breaking down long-duration non-real-time auxiliary tasks into micro-tasks of fixed duration and allocating the number of micro-tasks according to the idle window duration includes: constructing an abstract timeline; sequentially allocating the micro-tasks of the same non-real-time auxiliary task to the idle windows of the abstract timeline, prioritizing the filling of earlier windows; updating the execution status of each micro-task in real time on the abstract timeline; and sending a non-real-time auxiliary task completion signal corresponding to the current micro-task to the edge monitoring device after all micro-tasks are completed.

[0019] (III) Beneficial Effects: This invention provides a cloud-based management and retraining system for real-time dioxin monitoring data. It comprehensively applies IoT cloud platform, machine learning model training and updating, and edge monitoring device deployment technologies to perform real-time prediction of pollutants, dynamic model updates, and device-side model deployment, thereby improving the intelligence and accuracy of environmental monitoring. It creates a closed-loop evolving pollutant monitoring system, solving the problems of static model fixation and lack of adaptability in existing technologies. It can maintain high-precision dioxin monitoring at a low cost for a long time, greatly improving the intelligence and reliability of environmental monitoring, and has significant environmental and social benefits. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the structure of a cloud-based system for real-time dioxin monitoring data management and retraining according to the present invention; Figure 2 This is a schematic diagram illustrating the process by which the hash verification module in the cloud management and retraining system for real-time dioxin monitoring data verifies the updated dioxin prediction model sent by the cloud management platform. Figure 3This is a schematic diagram illustrating the specific process of data anomaly triggering retraining in a dioxin real-time monitoring data cloud management and retraining system according to the present invention. Detailed Implementation

[0021] The present invention will be further described in detail below with reference to preferred embodiments. More details are set forth in the following description in order to provide a full understanding of the present invention. However, the present invention can obviously be implemented in many other ways different from those described herein. Those skilled in the art can make similar extensions and derivations based on actual application situations without departing from the spirit of the present invention. Therefore, the scope of protection of the present invention should not be limited by the content of this specific embodiment.

[0022] The accompanying drawings are schematic diagrams of embodiments of the present invention. It should be noted that these drawings are for illustrative purposes only and are not drawn to scale, and should not be construed as limiting the actual scope of protection of the present invention.

[0023] A cloud-based system for real-time monitoring data of dioxins, used for real-time monitoring of toxic pollutants such as dioxins. Figure 1 As shown, it includes edge monitoring equipment deployed at the pollution source site and a cloud management platform deployed on a cloud server.

[0024] The edge monitoring device includes sensor components, an edge computing unit, a first communication unit, and a model update unit. The sensor components collect operating parameters related to dioxin emissions, obtaining collected data. The edge computing unit uses a built-in dioxin prediction model to infer concentration prediction results from the collected data in real time. The first communication unit sends the collected data and concentration prediction results to the cloud management platform and receives model update instructions from the cloud management platform. The model update unit verifies the updated dioxin prediction model sent by the cloud management platform and replaces the old dioxin prediction model, thus upgrading the dioxin prediction model.

[0025] The cloud management platform includes a data management subsystem, an anomaly detection subsystem, a model training subsystem, a model version management subsystem, and a model distribution subsystem. The data management subsystem stores and cleans collected data, constructing a timestamped historical database. The anomaly detection subsystem monitors for prediction errors exceeding limits or data distribution drift, triggering model retraining requests. The model training subsystem uses historical data from the historical database to incrementally retrain the current dioxin prediction model, obtaining an updated dioxin prediction model. The model version management subsystem stores dioxin prediction model version information and verifies the accuracy of the updated dioxin prediction model. The model distribution subsystem sends the verified dioxin prediction model to target edge monitoring devices, enabling the retraining system to have adaptive evolution capabilities oriented towards emission risks.

[0026] The operating parameters related to dioxin emissions collected by the sensor assembly include at least: furnace high-temperature combustion zone temperature, flue gas temperature and residence time in the dioxin resynthesis sensitive temperature zone, flue gas oxygen content, flue gas chlorine characteristic parameters and / or their proxy variables, proxy variables reflecting the presence of catalytic heavy metals, flue gas velocity, furnace negative pressure, activated carbon injection rate, and bag filter inlet temperature, etc., and may also include reference values ​​of actual dioxin concentration measured offline in laboratories. The first communication unit sends the collected operating parameters related to dioxin emissions, i.e., the collected data, to the cloud management platform for constructing an operating feature set that matches the dioxin formation mechanism.

[0027] The sensor assembly also includes a data preprocessing module, which preprocesses the collected data before the edge computing unit performs real-time inference on the collected data, including outlier filtering, time synchronization, and data standardization.

[0028] Outlier filtering refers to removing invalid or abnormal data collected by sensor components. Time synchronization refers to aligning multiple data sets collected by sensor components according to their timestamps. Data standardization involves normalizing or standardizing the collected data to adapt it to the input requirements of the dioxin prediction model.

[0029] The model update unit verifies the integrity of the updated dioxin prediction model sent by the cloud management platform through the hash verification module, ensuring that the received dioxin prediction model has not been tampered with.

[0030] The hash verification module verifies the updated dioxin prediction model sent by the cloud management platform, such as... Figure 2 As shown, the specific steps include:

[0031] Step 1: The cloud management platform generates a model hash digest.

[0032] After verifying the accuracy of the updated dioxin prediction model, the model version management subsystem of the cloud management platform calculates a unique hash digest for the updated dioxin prediction model using the SHA-256 hash algorithm. This hash digest is then bound to the metadata of the dioxin prediction model and stored in the model version database. A transmission packet containing the dioxin prediction model, the hash digest, and the metadata is generated. The metadata includes the version number of the dioxin prediction model and its generation timestamp.

[0033] Step 2: The cloud management platform encrypts and transmits the dioxin prediction model, hash digest, and metadata.

[0034] The model distribution subsystem of the cloud management platform encrypts the transmission packets before sending them to the target edge monitoring device. The model distribution subsystem can use the TLS 1.3 protocol to encrypt the transmission packets. The model distribution subsystem can send the transmission packets via MQTT or HTTPS channels.

[0035] The specific structure of the transmission packet is shown in the table below.

[0036]

[0037] Step 3: Edge monitoring equipment receives and preprocesses data.

[0038] After receiving the transmission packet, the first communication unit of the edge monitoring device decrypts the packet and extracts the dioxin prediction model, hash digest, and metadata. It then performs a preliminary check on the transmission packet to quickly detect bit errors during transmission. If the check fails, the transmission packet is discarded and the cloud is notified of the transmission corruption. The first communication unit decrypts the transmission packet using the TLS protocol, and the preliminary check can be performed using a 32-bit CRC32 algorithm.

[0039] Step 4: The edge monitoring device recalculates the received updated dioxin prediction model hash value.

[0040] The model update unit of the edge monitoring device calls the built-in encrypted hash algorithm, which can be the SHA-256 algorithm. Then, it performs hash calculation on the received dioxin prediction model: reads the binary stream of the dioxin prediction model, processes it in blocks of fixed size to avoid memory overflow (the fixed block size can be 4KB); updates the hash state block by block, and finally generates a local hash digest.

[0041] Step 5: The edge monitoring device compares the obtained hash value and processes the result.

[0042] The model update unit of the edge monitoring device compares the local hash digest with the hash digest byte by byte.

[0043] If the two are completely consistent, the model file is determined to be complete and unaltered, and the verification passes. Perform the following operations: back up the old dioxin prediction model file, which is used for version rollback; replace the old dioxin prediction model in the edge computing unit with the new dioxin prediction model; and send a confirmation message to the cloud management platform confirming successful verification and model update completion.

[0044] If the two are inconsistent, the model file is determined to have been tampered with or corrupted, and the verification fails. The following actions are performed: delete the received dioxin prediction model; send an error message indicating that the hash mismatch verification failed to the cloud management platform and request a new dioxin prediction model to be reissued; and record an error log containing the timestamp, model version, local hash digest, and the difference between the hash digest and the model file.

[0045] Step 6: The edge monitoring device and the cloud management platform record the entire process log of hash verification, including time, device ID, model version, hash value, and verification result, for subsequent security auditing and troubleshooting.

[0046] The data management subsystem of the cloud management platform can also treat the collected data from each sensor component as a feature layer, extract local micro-features from each feature layer, and then superimpose and integrate the feature layers to output the superimposed and integrated local features, that is, a fused data block that retains all original micro-features. When the model training subsystem trains the dioxin prediction model, it uses the fused data block that retains all original micro-features as the input of the dioxin prediction model, which clearly reflects the subtle changes in the operating conditions of the local area of ​​the combustion chamber and improves the prediction accuracy of the dioxin concentration prediction model for low-concentration dioxin emissions.

[0047] Specifically, the steps include the following: Layer mapping of sensor component data: The data collected by each sensor component, i.e., operating parameters such as combustion chamber temperature, flue gas pressure, activated carbon injection quantity, and oxygen content, is mapped to an independent feature layer. Each independent layer corresponds to the microscopic changes in the collected data recorded by one sensor component. For example, the combustion chamber temperature sensor corresponds to a temperature height layer, which records the microscopic changes in temperature in different regions; the flue gas pressure sensor corresponds to a pressure normal layer, which records the local gradient changes in pressure. Each feature layer independently stores the raw data without preprocessing such as averaging or normalization, ensuring that local details are not prematurely masked. Feature layers include height maps, normal maps, detail enhancement maps, and texture maps. The feature maps corresponding to different sensor components are of different types, as shown in the table below.

[0048]

[0049] Extract subtle features from each feature layer: For each feature layer, divide it into local windows according to the time or spatial dimensions to focus on microscopic changes; the time dimension could be a 1-second sampling window, and the spatial dimension could be the front / middle / rear region of the combustion chamber. Within each local window, retain local features such as instantaneous sensor drift, parameter fluctuations in local areas, and precursory signals of anomalies. Instantaneous sensor drift includes small pressure jumps at a sampling point that do not exceed the measurement range; parameter fluctuations in local areas include sudden temperature increases in a certain area of ​​the combustion chamber; and precursory signals of anomalies include small local decreases in activated carbon injection. Local changes exceeding a preset threshold within the local window are marked, such as temperature gradients > 0.3℃ / cm, as key details for subsequent overlay.

[0050] Multiple feature layers are integrated by spatial-temporal alignment and overlay: all feature layers are aligned by timestamp and spatial location to ensure that the overlay represents multi-dimensional details within the same spatiotemporal context. Timestamp refers to the same sampling time, and spatial location refers to the same monitoring area. For each aligned local window, the local features of each feature layer are directly overlaid. For example, in a certain time window and the central region of the combustion chamber, the local sudden rise feature of the temperature height layer is overlaid with the local fluctuation feature of the pressure normal layer, and the details of both are preserved. Different layers are pre-weighted according to the degree of influence of the corresponding features on dioxin formation. The weight only affects the prominence of details. For example, if the weight of temperature change is higher than that of pressure, the feature details of temperature change are more prominent than those of pressure. Among them, core influencing layers, such as combustion chamber temperature and activated carbon injection rate, are weighted at 3; important influencing layers, such as flue gas pressure and oxygen content, are weighted at 2; and auxiliary reference layers, such as flue gas velocity, are weighted at 1.

[0051] Output of integrated local features: The local feature details of all sensor component layers within the same spatiotemporal window are weighted and superimposed to output a fused data block that retains all original microscopic features. This data block serves as input to the dioxin prediction model, avoiding the problem of global averaging that erases details in traditional fusion methods. The fused data block, retaining all original microscopic features, clearly reflects subtle operating condition changes in local areas of the combustion chamber, improving the prediction accuracy of the dioxin concentration prediction model for low-concentration dioxin emissions.

[0052] Among the subtle features extracted from each feature layer, the local features of instantaneous drift, parameter fluctuations in local regions, and abnormal precursor signals are extracted as follows.

[0053] Local feature extraction for instantaneous drift: Within a local time window, such as 1 second / 10 sampling points, the current sampling point value is directly compared with the original value of the previous sampling point. A preset small drift threshold is used. If the difference is within the small drift threshold and does not exceed the sensor's physical range, it is marked as instantaneous drift, and the original value of that point is retained. The preset small drift threshold is determined based on the sensor's accuracy, such as 0.1 kPa for pressure and 0.2℃ for temperature. It should be noted that the average value of all points within the window is not calculated here; only the original difference between adjacent points is compared. For example, in the feature layer corresponding to the pressure sensor component, the previous point value is 100.0 kPa, and the current point value is 100.08 kPa. The difference is 0.08 kPa < the small drift threshold of 0.1 kPa, and it does not exceed the range of 0-200 kPa. Therefore, 100.08 kPa is directly retained and marked as instantaneous drift + 0.08 kPa, without averaging the pressure value within the window to 100.04 kPa.

[0054] Local feature extraction of parameter fluctuations in local areas: For sensor components with spatial partitions, such as the temperature of combustion chamber zones A / B / C, the numerical change amplitude of 3-5 consecutive sampling points is observed within a local spatial window and a local time window. A small fluctuation threshold is preset, such as 0.3℃ for temperature. If the total change amplitude of consecutive points exceeds the threshold, it is marked as a local fluctuation, and all original values ​​within the window are retained. It should be noted that in this process, only the changes within the same spatial area are analyzed, and values ​​from different areas are not merged. For example, in the temperature feature layer of combustion chamber zone A, the sampling values ​​within 5 seconds are 250.0℃, 250.2℃, and 250.5℃, with a total change of 0.5℃, which is greater than the small fluctuation threshold of 0.3℃. All temperature values ​​within the window and the local sudden increase of 0.5℃ are retained, and the temperature of zones A / B / C is not averaged to 249.8℃.

[0055] Localized extraction of abnormal precursor signals: The normal baseline value of the sensor components is determined, such as the normal average activated carbon injection rate of 10 kg / h, determined by historical stable operating conditions. This can be preset in the cloud management platform. Within a local time window, it is observed whether consecutive sampling points consistently fall below a small percentage threshold of the baseline value, such as 5%, i.e., 9.5 kg / h. If three or more consecutive sampling points meet the condition and do not trigger the alarm threshold, they are marked as precursor signals, and the original values ​​are retained. The alarm threshold is a preset value, specifically 9 kg / h. It should be noted that this process compares consecutive points within the local window with a fixed baseline value, without merging with the daily / all-time average. For example, in the activated carbon injection rate layer, consecutive values ​​within a 1-minute window are 9.8 kg / h, 9.7 kg / h, and 9.6 kg / h, all below the 9.5 kg / h threshold, failing to reach the alarm threshold of 9 kg / h. The values ​​within the window and the precursor decline marker are retained, and the daily average of 9.9 kg / h is not used as the judgment criterion.

[0056] It should be noted that each sensor's feature layer is processed independently and is not mixed with data from other layers. The results of each local window are used only for preserving its own details and are not merged with other windows to generate global statistics. For example, the instantaneous drift of the pressure sensor is extracted only within its own 1-second window, and is not merged with the temperature sensor window data, nor is the drift value of all windows averaged to obtain the global drift amount.

[0057] The anomaly detection subsystem's anomaly triggering mechanisms include: data acquisition anomaly triggering retraining, data anomaly triggering retraining, and model performance anomaly triggering retraining.

[0058] Data acquisition anomaly triggering retraining includes sensor component fault detection and human intervention identification. Sensor component fault detection identifies abnormal signals output by the sensor component, including: data jumps: the difference between adjacent sampling points exceeds 10% of the sensor component's physical range (this 10% is a preset threshold and can be modified as needed); continuous no response: no data output or fixed output values ​​for 5 consecutive sampling cycles; exceeding the physical range: the output value exceeds the sensor component's calibrated physical range, such as a temperature sensor exceeding -40℃ to 120℃. Human intervention identification detects unnatural characteristics of the data, including: long-term abnormal stability: fluctuation rate <0.01 for 10 consecutive sampling windows, far below the normal operating condition fluctuation threshold (each window contains 100 data points); mechanical regular fluctuations: data exhibits a fixed period unrelated to equipment operating conditions, such as repeating every 60 seconds; contradictory operating condition logic: for example, the sensor component continues to output high concentration emission values ​​when the equipment is shut down, inconsistent with actual operating conditions.

[0059] The specific process of retraining triggered by data acquisition anomalies is as follows: The sensor assembly collects operating parameters related to dioxin emissions in real time, i.e., collected data, which includes temperature, flue gas flow rate, pollutant concentration, etc. The data preprocessing module preprocesses the collected data, such as denoising and format conversion from analog to digital signals, and then sends it to the cloud management platform. The anomaly detection subsystem of the cloud management platform performs real-time analysis on the preprocessed collected data to determine whether it conforms to the above-mentioned anomaly characteristics. If an anomaly is detected, the anomaly detection subsystem marks the anomaly type and sends it to the model training subsystem; The model training subsystem verifies the authenticity of the anomaly. When the model training subsystem receives the same anomaly three times in a row, a retraining task is triggered. Specifically, the dioxin prediction model can be retrained using the corrected dataset or supplementary fault data.

[0060] Data anomaly triggering retraining includes data distribution drift detection, time series fluctuation detection, and emission level compliance detection. Data distribution drift detection calculates the difference between the current input features, such as temperature distribution and flow rate distribution, and historical baseline distribution using the Population Stability Index (PSI) or KL divergence. A PSI > 0.2 or a KL divergence > 0.5 indicates drift. Time series volatility detection calculates data volatility and autocorrelation coefficients using a sliding window to identify short-term, drastic changes, i.e., deviations from the normal time series trend or fluctuation range. If volatility > twice the historical mean or autocorrelation coefficient < 0.1, retraining is triggered. The sliding window size is 1 hour, with a step size of 10 minutes. Volatility refers to fluctuations compared to the standard deviation or mean, and the normal range for autocorrelation coefficient is 0.3-0.8. Emission level compliance detection monitors the volatility of emission results. Retraining is triggered when a preset compliance threshold is exceeded. Specifically, it monitors dioxin concentration. Retraining is triggered when the monitored dioxin concentration exceeds the national environmental protection standard threshold (e.g., 0.1 ng TEQ / m³) or a preset warning threshold. The national environmental protection standard threshold is 0.1 ng TEQ / m³, and the preset warning threshold can be 0.08 ng TEQ / m³. TEQ / m³.

[0061] like Figure 3 As shown, the specific process of data anomalies triggering retraining is as follows: The preprocessing module extracts features from the preprocessed collected data to obtain feature data, such as hourly statistical features. The first communication unit encrypts and sends the feature data to the cloud management platform. The anomaly detection subsystem compares the current feature distribution with the historical baseline and calculates the PSI / KL divergence; the historical baseline can specifically be the feature distribution during model training. The anomaly detection subsystem uses a sliding window to analyze the volatility and autocorrelation coefficient of the data; Real-time comparison of emission values ​​with preset thresholds; When any indicator exceeds the threshold, the anomaly detection subsystem sends a retraining trigger signal to the model training subsystem, triggering retraining. The model training subsystem then initiates retraining of the dioxin prediction model to update the model to adapt to new data distributions or fluctuation patterns.

[0062] The anomaly detection subsystem compares the current feature distribution with historical benchmarks and calculates the PSI. The specific process is as follows.

[0063] Variable binning: For continuous variables, the variable is divided into several intervals to ensure that each interval has a sufficient number of samples in the baseline population and to avoid having a proportion of 0; for categorical variables, the category is used directly as the interval.

[0064] Calculate the percentage of each interval: For each interval, calculate the percentage of the baseline group, p. i and the current group percentage qi , , .

[0065] Calculate the interval PSI value: For each interval, calculate: If q i =0, A very small positive number, such as 1e-6, needs to be added to avoid ln(0) becoming meaningless; if p i If the value is 0, then this interval is not included.

[0066] Summing gives the total PSI: .

[0067] The distribution is stable when PSI < 0.1; When the PSI value is between 0.1 and 0.25, the distribution shows a slight shift. When PSI > 0.25, the distribution shifts significantly.

[0068] Model performance anomalies triggering retraining include prediction error exceeding limits detection and model self-checking for decreased accuracy. Prediction error exceeding limits detection involves calculating the deviation between predicted values ​​and historical averages / actual values; retraining is triggered when the deviation exceeds a preset threshold. Model self-checking for decreased accuracy assesses model accuracy through cross-validation or independent hold-out sets; when core metrics fall below a preset threshold, the model automatically enters the retraining queue. Specifically, prediction error exceeding limits involves calculating the absolute / relative deviation between the model's predicted values ​​and actual monitored values ​​or historical averages; retraining is triggered when the average deviation over 10 consecutive sampling periods exceeds a preset threshold, which can be 15%. Model accuracy decrease is assessed through cross-validation or independent hold-out sets; retraining is triggered when core metrics decrease by more than 10% compared to the initial model, for example, RMSE increases from 0.02 to 0.022. In cross-validation, k=5 fold, and the independent hold-out set can comprise 20% of the total data. Core metrics include RMSE, MAE, and prediction accuracy.

[0069] The specific process of retraining triggered by abnormal model performance is as follows: Edge computing units use current dioxin prediction models to predict real-time data; The edge computing unit calculates the deviation between the predicted value and the actual value in real time and uploads it to the cloud management platform through the first communication unit; The anomaly detection subsystem uses historical and new data to perform cross-validation / holdout set evaluation of the dioxin prediction model weekly or at other preset intervals. If the deviation exceeds the limit or the accuracy index drops beyond the threshold, the anomaly detection subsystem sends a trigger retraining signal to the model training subsystem. The model training subsystem initiates a retraining task, optimizes the model weights using the latest dataset, generates a new dioxin prediction model, and sends it to the edge monitoring device to replace the old dioxin prediction model.

[0070] The anomaly detection subsystem is configured with retraining trigger rules based on emission risk: when the dioxin prediction result approaches or exceeds the dioxin emission limit multiple times within a preset time window, and / or when multiple consecutive over-limit warnings occur, the corresponding operating condition data and the latest laboratory analysis results are marked as high-risk samples and automatically pushed to the model training subsystem to perform a high-priority retraining task, and the corresponding risk event label is recorded in the model version management subsystem.

[0071] The model training subsystem is retrained in the following manner: Incremental learning: Fine-tuning model parameters using new data while retaining knowledge from the old model; Transfer learning: When real dioxin label data is lacking, simulated data under similar operating conditions or labeled data from other devices are used as approximate labels; Federated learning: Jointly trains models by aggregating parameters or averaging gradients, while protecting the data privacy of edge monitoring devices; Algorithm support: Model training can be performed using SGD optimization algorithm, LSTM / CNN neural network or ensemble learning algorithm.

[0072] When the model training subsystem retrains through incremental learning, it includes the following steps: Load the trained old dioxin prediction model and its parameters, and retain the low-level feature extraction layer of the old dioxin prediction model; Acquire new dioxin monitoring data, and perform preprocessing such data cleaning, denoising, and normalization to make it consistent with the format and distribution of the old dioxin prediction model training data; Freeze the parameters of the bottom feature extraction layer of the old dioxin prediction model, and only unfreeze the top prediction layer; The SGD optimization algorithm was used as input, with the newly added dioxin monitoring data that had undergone cleaning, denoising, and normalization preprocessing, to fine-tune the parameters of the top prediction layer. The prediction error of the fine-tuned model is evaluated using the validation set. If the error is lower than a preset threshold, the fine-tuned model is saved. If the error does not meet the standard, repeat the above steps until the dioxin prediction model converges.

[0073] The underlying feature extraction layer of the old dioxin prediction model includes CNN or LSTM layers to retain the general feature extraction capability for dioxin monitoring data.

[0074] When the model training subsystem retrains through transfer learning, it includes the following steps: Choose an old dioxin prediction model that has been pre-trained under similar operating conditions, such as a model trained based on dioxin monitoring data from other incineration equipment; When real dioxin labeling data is lacking, simulated data under similar operating conditions can be obtained, such as labeling data generated by incineration process simulation software or other equipment, as approximate labels. Replace the output layer of the old dioxin prediction model to adapt it to the label dimensions of the target data; The dioxin prediction model after replacing the output layer was trained using approximately labeled data, and the bottom feature extraction layer of the old dioxin prediction model was frozen. If a small amount of real dioxin label data exists, use it to fine-tune the top-level parameters of the dioxin prediction model; The performance of the obtained dioxin prediction model on the target data is evaluated, and the qualified dioxin prediction model is saved, which is the new dioxin prediction model.

[0075] The distribution difference between approximate label data and real label data must be less than a preset threshold to ensure the model transfer effect.

[0076] When the model training subsystem is retrained through federated learning, it includes: the cloud management platform acting as a coordinator, sending initial model parameters to the edge monitoring devices; the edge monitoring devices using local data to train the model and uploading parameter updates; and the cloud management platform aggregating the parameter updates from each edge monitoring device to generate a globally optimized model, protecting data privacy.

[0077] Specifically, The cloud management platform initializes the global dioxin prediction model parameters; Distribute the global dioxin prediction model to multiple edge monitoring devices; Each edge device uses local dioxin monitoring data for local training, calculating gradients, or updating the parameters of the local dioxin prediction model. Edge monitoring devices upload gradients or parameters to the cloud management platform via an encrypted channel, without transmitting the original data. The cloud management platform uses a parameter aggregation algorithm to perform a weighted average of the parameters uploaded by each edge monitoring device and updates the global dioxin prediction model; the parameter aggregation algorithm can specifically be the FedAvg algorithm. Repeat the above steps until the global dioxin prediction model converges, and then distribute the final dioxin prediction model to each edge monitoring device.

[0078] When the model training subsystem uses the SGD optimization algorithm for retraining, it includes the following steps: Initialize the parameters of the dioxin prediction model; Divide the training data into multiple batches; Calculate the loss function value for each batch of data; Backpropagation is used to calculate the gradient; Update parameters using SGD: Parameter = Parameter - Learning rate × Gradient; Repeat the steps to calculate the loss function value for each batch of data, backpropagate to calculate the gradient, and update the parameters using SGD: parameter = parameter - learning rate × gradient, until the loss function converges.

[0079] The calculation of the loss function value for each batch of data specifically includes, Acquire batch data consisting of N samples, each sample containing an input feature set and a true label. The input feature set includes multi-dimensional monitoring data related to dioxin emissions, such as incinerator temperature, flue gas flow rate, O2 concentration, CO concentration, and HCl concentration. The true label is the actual dioxin concentration value of the corresponding sample. Normalization is performed on the input feature set, and the true label undergoes the same normalization or retains its original units. The normalization process for the input feature set can be x... norm =(x-μ) / σ, where μ is the global mean of the training set and σ is the global standard deviation of the training set. The input feature set is time-series window data, such as a feature sequence of 10 consecutive sampling points, and the corresponding model output y is... pred,i This represents the output value of the LSTM neural network for the time window.

[0080] To address the high concentration sensitivity of the dioxin regression task, the weighted mean squared error (WMSE) was chosen as the core loss function; the weighting coefficients w were defined. i If the true label value of sample i is greater than or equal to the preset high concentration threshold, such as 0.1 ng TEQ / m³, then w i =k (k∈[1.5,3.0], preferably k=2); if the label value < threshold, then w i =1. The high concentration threshold is determined by the dioxin emission standards, with a preference for 50% to 80% of the standard limit.

[0081] For each sample i in the batch, calculate its sample loss value, Loss. i , , where y pred,i y represents the model's predicted dioxin concentration for sample i. true,i Let be the true label value of sample i.

[0082] The batch loss function value (Loss) is obtained by averaging and aggregating the loss values ​​of all samples within the batch. batch : .

[0083] If there are abnormal samples in the batch, such as when the true label value is greater than or equal to the preset abnormal threshold, then the loss for that sample will be... i Perform a cropping process to limit the loss to a preset maximum value, such as 5 × 5 × the batch average loss, and then calculate the batch loss function value. The anomaly threshold is determined by the 99th percentile of historical monitoring data to cover 99% of the normal sample range.

[0084] When the model training subsystem retrains the Long Short-Term Memory (LSTM) / Convolutional Neural Network (CNN), it includes the following steps: Constructing LSTM-compatible input sequences for time-series data, or extracting CNN-compatible spatial features from multidimensional monitoring data; time-series data includes continuously sampled temperature, flue gas flow, etc. LSTM layers are configured with the number of hidden units and the number of layers; CNN layers are configured with the kernel size and pooling layers. Train the network using training data and optimize the loss function; Verify model performance and adjust network structure.

[0085] When the model training subsystem uses an ensemble learning algorithm for retraining, it includes the following steps. Select multiple basic dioxin prediction models; Train each basic dioxin prediction model using training data; The prediction results of each dioxin prediction model were fused through weighted voting; Evaluate the performance of the ensemble model and adjust the weights of the base models to optimize the results.

[0086] The fusion method of the base model can be selected according to the type of prediction task (classification / regression). For classification tasks, a voting method is used, and for regression tasks, a weighted average method is used.

[0087] The model training subsystem validates the dioxin prediction model obtained through incremental retraining. The validated dioxin prediction model becomes the updated dioxin prediction model. Validation of the incrementally retrained dioxin prediction model includes: cross-validation: dividing the dataset into multiple subsets, which are used alternately as the training and validation sets to evaluate the model's generalization ability; and setting aside a validation set: creating an independent validation set from historical data and comparing the accuracy of the new and old models on the validation set to ensure that the updated model performs better.

[0088] The model training subsystem is used to train and update the dioxin prediction model based on historical operating condition time series data and dioxin toxicity equivalent (TEQ) results obtained through laboratory analysis. Specifically, when constructing training samples, the model training subsystem compensates for the time lag between dioxin sampling and laboratory analysis by aligning and matching the time window containing operating condition data of a preset duration before and after the sampling period with the corresponding TEQ labels. This allows the subsystem to learn the mapping relationship between operating condition characteristics and dioxin emission levels even under conditions of label acquisition lag.

[0089] When constructing training samples for the dioxin prediction model, the model training subsystem uses online-collected operating condition time series as input and dioxin toxicity equivalent (TEQ) results obtained through laboratory analysis as supervision labels. Through a preset time alignment and label lag compensation strategy, it matches the time window containing operating condition data before and after the dioxin sampling period with the corresponding TEQ labels. It can also calculate statistical features of operating condition parameters such as temperature, chlorine-containing characteristic parameters, catalytic metal proxy variables, and flue gas residence time within the time window, thereby forming a training feature vector corresponding to the TEQ labels.

[0090] When real dioxin TEQ-labeled data is insufficient, the model training subsystem adopts a semi-supervised and / or weakly supervised training strategy: samples with TEQ labels are used as supervision anchors, and unlabeled samples from online operating conditions are introduced into the training process through pseudo-label generation, similarity clustering, and / or consistency constraints to improve the generalization ability of the dioxin prediction model under label scarcity conditions.

[0091] The model version management subsystem also includes: a version rollback function: when the accuracy of the new model does not meet the requirements, it supports rolling back to a historical stable version; at the same time, it records the model's prediction mean square error, accuracy and other performance indicators for version comparison; a hash verification mechanism: hash signature is performed on the model file to ensure the integrity of model transmission and storage; performance indicator recording: stores the model's prediction mean square error, accuracy and other key indicators for version comparison.

[0092] The model distribution subsystem employs the following security measures: Encrypted communication: Model files are transmitted via TLS / SSL, MQTT over TLS, or HTTPS protocols; OTA (Over-The-Air) upgrade: Edge monitoring devices automatically receive, verify, and load new models via the OTA module, achieving seamless upgrades; Deployment confirmation: After deploying a new model, the edge monitoring device reports the deployment status to the cloud management platform to ensure successful updates.

[0093] A cloud-based system for real-time dioxin monitoring data management and retraining can be applied to the monitoring of other toxic pollutants, including polycyclic aromatic hydrocarbons (PAHs), volatile organic compounds (VOCs), or heavy metal vapors, by replacing or adding corresponding prediction models.

[0094] The cloud management platform also includes a regulatory interface module, which automatically generates an alarm report and pushes it to the environmental regulatory end when dioxin concentration exceeds the standard or model anomalies are detected, supporting real-time compliance monitoring and law enforcement evidence collection.

[0095] The edge monitoring device is equipped with a model verification module, which is used to detect the running status of the new dioxin prediction model. When the model inference time, resource usage, or prediction output is abnormal, it sends abnormal information to the cloud management platform.

[0096] The edge computing unit includes a time scheduling module, which identifies idle time segments between real-time inference tasks, specifically idle time segments between dioxin concentration predictions. Within these idle segments, non-real-time auxiliary tasks are executed to prevent them from consuming the computing resources required for real-time inference and to ensure the real-time output of concentration prediction results. These non-real-time auxiliary tasks include at least model state self-checks and secondary verification of non-critical data.

[0097] The time scheduling module identifies the core tasks of the edge monitoring device and embeds non-real-time auxiliary tasks after splitting and adapting them for execution. The core tasks include at least the prediction of dioxin concentration.

[0098] Specifically, the time scheduling module records the start and / or end timestamps of each core task and automatically identifies the idle window between adjacent inference tasks, such as the 60-80ms window from the end of the previous inference to the start of the next inference within a 100ms period.

[0099] For example, the edge computing unit in the edge monitoring device needs to perform a core task every 100ms: real-time inference of dioxin concentration, which takes about 20ms, leaving 80ms as a potential idle segment.

[0100] Then, the time-consuming non-real-time auxiliary tasks are broken down into microtasks of fixed duration, and the number of microtasks is allocated according to the idle window duration, for example, 6 microtasks are allocated in a 60ms window, to ensure that all microtasks are completed before the core inference task starts, without consuming inference resources. Each microtask takes ≤10ms.

[0101] An abstract timeline is constructed, which strings together multiple idle windows. The time scheduling module records the timestamps of the idle windows for the next N core tasks, such as the start / end times of the next three windows: t1~t1+80ms, t2~t2+80ms, and t3~t3+80ms. These discrete idle windows are marked as continuous available time segments on the abstract timeline, forming a cross-window time pool. Specifically, the time scheduling module pre-reads the cycle and duration of the core tasks and calculates the timestamps of the idle windows for the next N cycles. On the abstract timeline, the available time period and core task time period of each window are marked with different colors, clearly defining the executable interval of the micro-tasks.

[0102] The microtasks, which are derived from the same non-real-time auxiliary task, are sequentially assigned to idle windows on the abstract timeline, prioritizing the filling of earlier windows to ensure that microtasks are completed gradually. For example, out of 12 sub-microtasks, the first 8 are assigned to the first idle window t1~t1+80ms, and the remaining 4 are assigned to the second idle window t2~t2+80ms. The abstract timeline records the number of microtasks in each window to ensure that it does not exceed the window duration.

[0103] The execution status of each microtask is updated in real time on the abstract timeline, such as completed, incomplete, or paused, ensuring no duplication or omission during cross-window execution. Specifically, before the end of each idle window, the time scheduling module saves the execution progress of the current microtask, for example, if the execution has reached the m-th microtask, the next window will continue execution from the (m+1)-th microtask. The abstract timeline marks the pause point of the microtask, and execution resumes when the next window starts. After all microtasks are completed, the abstract timeline sends a non-real-time auxiliary task completion signal corresponding to the current microtask to the edge monitoring device.

[0104] When a microtask cannot be completed within the same idle window, or when the total time of short-duration non-real-time microtasks exceeds the idle window of a single core task, the time scheduling module, through idle window concatenation on the abstract timeline and microtask cross-window progress management, splits the microtasks and distributes them across multiple consecutive idle windows for execution. This ensures that the real-time performance of the core task is not affected while still allowing the microtasks to be completed. If a microtask is not completed before the end of the idle window (e.g., a single microtask takes 10ms and the window has 5ms remaining), the time scheduling module immediately pauses the microtask, saves its progress, and automatically switches the abstract timeline to core task mode when the core task begins, prohibiting the execution of any microtasks. After the core task ends, the abstract timeline returns to idle mode and continues executing any unfinished microtasks.

[0105] The cloud management platform is also equipped with the time scheduling module. This module identifies the core tasks of the cloud management platform and embeds non-real-time auxiliary tasks after splitting and adapting them for execution. The core tasks include at least model retraining, i.e., incrementally retraining the current dioxin prediction model using historical data from the historical database.

[0106] Specifically, the time scheduling module records the start and / or end timestamps of each core task and automatically identifies the idle window between adjacent model retraining tasks.

[0107] Then, the long-running non-real-time auxiliary tasks are broken down into micro-tasks of fixed duration, and the number of micro-tasks is allocated according to the idle window duration to ensure that all micro-tasks are completed before the core inference task starts, without consuming inference resources.

[0108] An abstract timeline is constructed, which strings together multiple idle windows. The time scheduling module records the timestamps of the idle windows for the next N core tasks. These discrete idle windows are marked as consecutive available time segments on the abstract timeline, forming a cross-window time pool. Specifically, the time scheduling module pre-reads the cycle and duration of the core tasks and calculates the timestamps of the idle windows for the next N cycles. On the abstract timeline, different colors are used to mark the available time period and core task time period of each window, clearly defining the executable interval of the micro-tasks.

[0109] The microtasks, derived from the breakdown of the same non-real-time auxiliary task, are sequentially assigned to idle windows on the abstract timeline, prioritizing the filling of earlier windows to ensure the gradual completion of microtasks. The abstract timeline records the number of microtasks in each window, ensuring that it does not exceed the window duration.

[0110] The execution status of each microtask is updated in real time on the abstract timeline: before the end of each idle window, the time scheduling module saves the execution progress of the current microtask, for example, if the execution reaches the m-th microtask, the next window will continue execution from the (m+1)-th microtask. The abstract timeline marks the pause point of the microtask, and execution resumes when the next window starts. After all microtasks are completed, the abstract timeline sends a non-real-time auxiliary task completion signal corresponding to the current microtask to the cloud management platform.

[0111] When a microtask cannot be completed within the same idle window, or when the total time of short-duration non-real-time microtasks exceeds the idle window of a single core task, the time scheduling module, through idle window concatenation on the abstract timeline and microtask cross-window progress management, splits the microtasks and distributes them across multiple consecutive idle windows for execution. This ensures that the real-time performance of the core task is not affected while still allowing the microtasks to be completed. If a microtask is not completed before the end of the idle window, the time scheduling module immediately pauses the microtask, saves its progress, and automatically switches to core task mode when the core task begins, prohibiting the execution of any microtasks. After the core task ends, the abstract timeline returns to idle mode and continues to execute unfinished microtasks.

[0112] This invention proposes a cloud-based management and retraining system for real-time dioxin monitoring data that combines mechanistic constraints, label lag compensation, and emission risk-driven retraining. First, this invention explicitly incorporates operating parameters highly correlated with the dioxin formation mechanism, such as combustion zone temperature, flue gas residence time in the dioxin resynthesis sensitive temperature zone of 200℃~450℃, flue gas chlorine characteristic parameters, catalytic heavy metal proxy variables, flue gas oxygen content, and activated carbon injection rate, into the feature set. This allows the dioxin prediction model to learn features under mechanistic constraints, rather than simply relying on empirical variable selection. Second, this invention introduces time alignment and label lag compensation strategies during model training, matching the delayed TEQ labels obtained from laboratory analysis with historical operating condition time windows, thus resolving the inherent contradiction between real-time operating condition prediction and delayed emission labels in dioxin monitoring. Third, this invention directly binds anomaly detection with emission limits and safety margins. When the prediction result approaches or may exceed the emission limits, it automatically triggers retraining tasks and model version management decisions, enabling the system to have adaptive evolution capabilities oriented towards emission risks, thereby maintaining high dioxin prediction accuracy and emission compliance assurance capabilities in long-term operation.

[0113] A cloud-based management and retraining system for real-time dioxin monitoring data enables continuous model self-optimization, significantly improving monitoring accuracy. It establishes a feedback pathway from data to the model, allowing the cloud management platform to continuously retrain and optimize the dioxin prediction model using the latest field data. This ensures the model can keep pace with changes in operating conditions and maintain high-precision predictions. The accuracy of the dioxin prediction model can be maintained and improved throughout its entire lifecycle, significantly reducing indicators such as the mean square error of dioxin concentration prediction and decreasing the rates of missed and false alarms for abnormal emissions, thereby ensuring accurate and reliable monitoring results.

[0114] The cloud-based management platform automates model diagnosis and adjustment, eliminating frequent manual calibration. Dioxin prediction model optimization is centrally performed on the cloud platform, avoiding repetitive work of individual debugging on each device and saving significant manpower and resources. Simultaneously, the high-performance computing of the cloud platform shortens training iteration time, enabling rapid provision and distribution of updated dioxin prediction models after anomalies occur, achieving near real-time response and giving the monitoring system self-maintenance capabilities, greatly reducing long-term operating costs.

[0115] The cloud-based management platform continuously monitors data and dioxin prediction model errors, enabling rapid identification of abnormal emissions or model malfunctions. When a sudden increase in dioxin concentration or anomaly in data patterns is detected, the system immediately triggers alerts and model adjustments, ensuring that excessive emissions are not concealed. Simultaneously, it prevents illegal emitters from exploiting fixed algorithm vulnerabilities to evade regulation, enhancing the system's robustness and reliability.

[0116] It can be smoothly integrated into existing dioxin monitoring devices, and upgraded for intelligent enhancement through a cloud management platform; alternatively, it can be deployed as an independent cloud service, interfacing with any field sensor / analyzer capable of uploading data, providing model training and update functions, exhibiting excellent scalability and compatibility, facilitating integration with previous equipment patents or monitoring platforms, and protecting existing investments. Furthermore, the cloud management platform can flexibly adjust models and algorithms according to the needs of different pollutant types or monitoring sites, demonstrating broad applicability.

[0117] Centralized data management through a cloud-based platform enables the creation of large-scale pollution emission data across a region, providing support for environmental protection departments' decision-making. The model continuously learns from the operational characteristics of different facilities, further identifying key influencing factors and mitigation strategies for dioxin formation. The system can also provide enterprises and regulators with dashboards displaying real-time emission predictions and model status, achieving transparency and facilitating a shift in regulatory models from passive, reactive enforcement to proactive, preventative regulation.

[0118] This invention creates a closed-loop evolutionary pollutant monitoring system through cloud management and retraining, which solves the problems of static model fixation and lack of adaptability in existing technologies. It can maintain high-precision dioxin monitoring at a low cost for a long time, greatly improving the intelligence level and reliability of environmental monitoring, and has significant environmental and social benefits.

[0119] The above description illustrates preferred embodiments of the present invention and helps those skilled in the art to more fully understand the technical solution of the present invention. However, these embodiments are merely illustrative and should not be construed as limiting the specific implementation of the present invention to these embodiments. For those skilled in the art, several simple deductions and modifications can be made without departing from the inventive concept, and all such modifications should be considered within the protection scope of the present invention.

Claims

1. A cloud-based management and retraining system for real-time dioxin monitoring data, characterized in that, This includes edge monitoring equipment deployed at pollution source sites and cloud management platforms deployed on cloud servers. The edge monitoring device includes a sensor assembly, an edge computing unit, a first communication unit, and a model update unit. The sensor assembly collects operating parameters related to dioxin emissions to obtain collected data. The edge computing unit uses a built-in dioxin prediction model to infer concentration prediction results from the collected data in real time; the first communication unit sends the collected data and concentration prediction results to the cloud management platform and receives model update instructions from the cloud management platform; the model update unit verifies the updated dioxin prediction model sent by the cloud management platform and replaces the old dioxin prediction model, thereby upgrading the dioxin prediction model. The cloud management platform includes a data management subsystem, an anomaly detection subsystem, a model training subsystem, a model version management subsystem, and a model distribution subsystem. The data management subsystem stores and cleans collected data, constructing a timestamped historical database. The anomaly detection subsystem monitors for prediction errors exceeding limits or data distribution drift, triggering model retraining requests. The model training subsystem uses historical data from the historical database to incrementally retrain the current dioxin prediction model, obtaining an updated dioxin prediction model. The model version management subsystem stores dioxin prediction model version information and verifies the accuracy of the new dioxin prediction model. The model distribution subsystem sends the verified dioxin prediction model to the target edge monitoring device.

2. The dioxin real-time monitoring data cloud management and retraining system according to claim 1, characterized in that, The operating parameters related to dioxin emissions collected by the sensor assembly include at least the following: temperature of the high-temperature combustion zone in the furnace, flue gas temperature and residence time in the dioxin resynthesis sensitive temperature zone, oxygen content in the flue gas, characteristic parameters of chlorine content in the flue gas and / or their proxy variables, proxy variables reflecting the presence of catalytic heavy metals, flue gas velocity, furnace negative pressure, activated carbon injection rate, and inlet temperature of the bag filter.

3. The dioxin real-time monitoring data cloud management and retraining system according to claim 1, characterized in that, The sensor assembly also includes a data preprocessing module, which preprocesses the collected data before the edge computing unit performs real-time inference on the collected data, including outlier filtering, time synchronization, and data standardization.

4. The dioxin real-time monitoring data cloud management and retraining system according to claim 1, characterized in that, The model update unit verifies the integrity of the updated dioxin prediction model sent by the cloud management platform through hash verification.

5. The dioxin real-time monitoring data cloud management and retraining system according to claim 1, characterized in that, The anomaly detection subsystem's anomaly triggering mechanism includes: Data acquisition layer anomaly triggering retraining: sensor fault detection, identifying abnormal signals output by sensors; human intervention identification, detecting unnatural features in the data; Data feature layer anomaly trigger retraining: Data distribution drift detection, which calculates the statistical distribution change of input features through population stability index PSI or KL divergence, and triggers when the distribution difference is greater than a preset threshold; Time series volatility detection uses a sliding window to calculate the volatility and autocorrelation coefficient of the data to identify short-term drastic changes; Emissions compliance testing monitors fluctuations in emissions results and triggers a test when emissions exceed a preset compliance threshold. Model performance layer anomaly triggers retraining: Prediction error exceeding limit detection, calculates the deviation between the predicted value and the historical average / actual value, and triggers when the deviation exceeds a preset threshold; Model self-checks decreased accuracy, evaluates model accuracy through cross-validation or independent hold-out set, and automatically enters the retraining queue when the core indicators are lower than the preset threshold.

6. The dioxin real-time monitoring data cloud management and retraining system according to claim 1, characterized in that, The model training subsystem employs at least one of the following methods for retraining: Incremental learning: Fine-tuning model parameters using new data while retaining knowledge from the old model; Transfer learning: When real dioxin label data is lacking, simulated data under similar operating conditions or labeled data from other devices are used as approximate labels; Federated learning: Jointly trains models by aggregating parameters or averaging gradients, while protecting the data privacy of edge monitoring devices; Algorithm support: Model training can be performed using SGD optimization algorithm, LSTM / CNN neural network or ensemble learning algorithm.

7. The dioxin real-time monitoring data cloud management and retraining system according to claim 1, characterized in that, Federated learning includes the following steps: The cloud management platform sends initial model parameters to the edge monitoring devices; Edge monitoring devices use local data to train models and upload them for parameter updates; The cloud management platform aggregates parameter updates from various edge monitoring devices to generate a globally applicable dioxin prediction model.

8. The dioxin real-time monitoring data cloud management and retraining system according to claim 1, characterized in that, The model training subsystem verifies the dioxin prediction model obtained through incremental retraining, and the verified dioxin prediction model becomes the updated dioxin prediction model. The dioxin prediction model obtained through incremental retraining is validated, including cross-validation: the dataset is divided into multiple subsets, which are used alternately as training and validation sets to evaluate the model's generalization ability; and a validation set is reserved: an independent validation set is created from historical data, and the accuracy of the new and old models on the validation set is compared to ensure that the updated model has better performance.

9. The dioxin real-time monitoring data cloud management and retraining system according to claim 1, characterized in that, The model version management subsystem also includes: Version rollback function: When the accuracy of the new dioxin prediction model does not meet the requirements, it supports rolling back to a historical stable version; at the same time, performance indicators are recorded for version comparison. Hash verification mechanism: The model file of the dioxin prediction model is hash-signed to ensure the integrity of the dioxin prediction model during transmission and storage; Performance metrics record: Store key metrics for the dioxin prediction model.

10. The dioxin real-time monitoring data cloud management and retraining system according to claim 1, characterized in that, The edge computing unit includes a time scheduling module, which is used to identify idle time segments between real-time inference tasks and execute non-real-time auxiliary tasks within the idle segments. Specifically, this includes the following steps: The time scheduling module identifies the core tasks of the edge monitoring device and splits and adapts the non-real-time auxiliary tasks before embedding them for execution. Then, the long-running non-real-time auxiliary tasks are broken down into micro-tasks with fixed durations, and the number of micro-tasks is allocated according to the idle window duration.

11. The dioxin real-time monitoring data cloud management and retraining system according to claim 10, characterized in that, Long-running non-real-time auxiliary tasks are broken down into micro-tasks of fixed duration, and the number of micro-tasks is allocated according to the idle window duration, including the construction of an abstract timeline; The microtasks derived from the same non-real-time auxiliary task are sequentially assigned to the idle windows of the abstract timeline, with earlier windows being filled first; the execution status of each microtask is updated in real time on the abstract timeline. Once all microtasks are completed, the abstract timeline sends a non-real-time auxiliary task completion signal corresponding to the current microtask to the edge monitoring device.

Images