An intelligent diagnosis method and system for operation quality of an on-line monitoring device of a pollution source based on EOBD

Abstract

The present application provides an EOBD-based pollution source online monitoring equipment operation quality intelligent diagnosis method and system, to solve the technical problems that the existing technology highly depends on manual experience, the troubleshooting efficiency is low and the problems are easy to be missed, and the specific content comprises: S1. Constructing an online monitoring equipment operation quality intelligent diagnosis model and loading it to a mobile terminal, completing the parameter initialization of the online monitoring equipment operation quality intelligent diagnosis model; the online monitoring equipment operation quality intelligent diagnosis model comprises a plurality of digital sub-models generated based on expert checking logic conversion; the present scheme breaks the high dependence of traditional on-site inspection on manual experience, shortens the time consumption of single-point inspection from days to ten minutes, effectively avoids the omission and subjective bias of manual troubleshooting; at the same time, without deploying high-cost hardware on the enterprise side, the low-cost full-process closed-loop management of on-site non-human intervention type rapid inspection and problem rectification is realized, and the precision and supervision efficiency of environmental protection law enforcement are significantly improved.

Description

Technical Field

[0001] This invention relates to the field of environmental monitoring and data processing technology, and in particular to an intelligent diagnostic method and system for the operation quality of online pollution source monitoring equipment based on EOBD. Background Technology

[0002] Current diagnostic solutions for illegal and non-compliant issues with online monitoring equipment mainly suffer from the following technical deficiencies:

[0003] The first category is off-site intelligent analysis systems. These systems can only perform preliminary screening of suspicious points in data uploaded to the cloud, lacking the support of on-site underlying data, making it difficult to directly identify illegal acts.

[0004] The second type is dynamic control devices deployed at the enterprise level. Although they can secure evidence, the cost of a single set of hardware is high, making it difficult to promote them on a large scale.

[0005] Furthermore, both of the above methods ultimately require regulatory personnel to conduct on-site manual verification. Due to the complexity of on-site conditions, the variety of monitoring equipment brands, and the significant differences in operating interfaces, traditional manual on-site inspections heavily rely on the professional experience of the inspectors. This is not only time-consuming and labor-intensive (inspections of a single company often take more than a day), but also prone to omissions. The lack of standardized screening procedures makes it difficult to guarantee the comprehensiveness and impartiality of the inspections. Summary of the Invention

[0006] To address the technical problems of existing technologies, such as high reliance on manual experience, low efficiency, and easy omissions in on-site inspections, this invention provides an intelligent diagnostic method and system for the operational quality of online pollution source monitoring equipment based on EOBD. The specific content includes: S1. Constructing an intelligent diagnostic model for the operational quality of the online monitoring equipment and loading it onto a mobile terminal, completing the parameter initialization of the intelligent diagnostic model; the intelligent diagnostic model for the operational quality of the online monitoring equipment includes multiple digital sub-models generated based on expert verification logic transformation; S2. The mobile terminal establishes a direct communication link with the field data acquisition and transmission instrument via an NFC near-field communication module, and sends data reading commands to the field data acquisition and transmission instrument based on a preset communication protocol to obtain the core data of the target pollution source online monitoring equipment; S3. The core data is imported as input data into the intelligent diagnostic model for the operation quality of the online monitoring equipment, triggering the automated operation of the intelligent diagnostic model for the operation quality of the online monitoring equipment; the intelligent diagnostic model for the operation quality of the online monitoring equipment parses the core data and performs cross-validation and logical comparison of the core data in different dimensions through multiple digital sub-models, outputting a diagnostic result vector characterizing the abnormal operation behavior of the equipment; S4. Based on the diagnostic result vector, a standardized diagnostic report containing specific problems of abnormal operation is generated, and the standardized diagnostic report is pushed to a preset management terminal node to further trigger problem rectification.

[0007] Preferably, in step S1, the step of constructing an intelligent diagnostic model for the operation quality of online monitoring equipment includes: a1. extracting a set of verification rules for the online monitoring equipment of pollution sources in terms of function settings, instrument parameters, and operation and maintenance processes; a2. converting the set of verification rules into a conditional judgment logic tree, and constructing sub-models for equipment functionality inspection, instrument setting inspection, illegal behavior detection, and fraud identification, respectively.

[0008] a3. The above sub-models are encapsulated into the intelligent diagnostic model for the operation quality of the online monitoring equipment, forming an executable algorithm set including 150 standardized inspection items.

[0009] Preferably, in step S2, the steps of establishing a direct communication link and acquiring core data include: b1. The mobile terminal acquires the device identification information of the field data acquisition and transmission instrument through NFC sensing; b2. Based on the device identification information, the communication link is verified; core data in the field data acquisition and transmission instrument is extracted according to a preset data structure, the core data including: device parameter data, daily maintenance data, log data, real-time monitoring data, and historical monitoring data.

[0010] Preferably, in step S3, the specific processing steps of cross-validation and logical comparison include: c1. Extracting the operation and maintenance timestamp and operation type from the log data, and the concentration fluctuation sequence from the historical monitoring data; c2. Aligning the operation and maintenance timestamp and the concentration fluctuation sequence with the time axis; c3. Determining, through the fraud detection sub-model, whether the variance or mean of the concentration fluctuation sequence exceeds the preset dynamic threshold boundary within the time window of a specific operation type. If so, marking the corresponding abnormal operation behavior node in the diagnostic result vector.

[0011] Preferably, the steps for triggering the closed-loop process of problem rectification include: pushing the standardized diagnostic report to the user terminal of the relevant responsible personnel; generating a status tracking task bound to the standardized diagnostic report on the server side, receiving and verifying the rectification feedback data for the specific problem of abnormal operation in real time; and updating the node status of the status tracking task to closed loop after the rectification feedback data passes the verification.

[0012] An intelligent diagnostic system for the operational quality of online pollution source monitoring equipment based on EOBD is characterized by comprising: a model configuration module for constructing an intelligent diagnostic model for the operational quality of the online monitoring equipment and loading it onto a mobile terminal, and completing parameter initialization; a data acquisition module for establishing a direct communication link with a field-end data acquisition and transmission device via the NFC near-field communication module of the mobile terminal, and acquiring core data based on a preset communication protocol; an intelligent diagnostic module for inputting the core data into the intelligent diagnostic model for the operational quality of the online monitoring equipment, and outputting a diagnostic result vector characterizing abnormal operating behavior of the equipment through cross-validation and logical comparison operations; and a closed-loop output module for generating a standardized diagnostic report based on the diagnostic result vector, and pushing and tracking the rectification status.

[0013] A computer-readable storage medium includes a processor and a memory, on which a computer program is stored, which, when executed by the processor, implements the above-described method steps.

[0014] This invention transforms expert verification experience into a digital intelligent diagnostic model for the operational quality of online monitoring equipment and embeds it in a mobile terminal. It utilizes NFC near-field communication technology to establish a direct connection with the field data acquisition and transmission instrument, enabling the extraction of multi-dimensional core data within seconds.

[0015] This method relies on an automated diagnostic model to cross-validate and intelligently calculate equipment parameters, logs, and historical monitoring data, accurately identifying violations and abnormal behaviors and automatically generating standardized reports. Compared to existing technologies, this solution breaks away from the heavy reliance on human experience in traditional on-site inspections, reducing the time for a single-point inspection from days to within ten minutes, effectively avoiding omissions and subjective biases inherent in manual inspections. Simultaneously, it eliminates the need for additional high-cost hardware deployment at the enterprise level, achieving a low-cost, unmanned, rapid on-site inspection and problem rectification process with a closed-loop management system, significantly improving the accuracy and efficiency of environmental law enforcement and supervision. Attached Figure Description

[0016] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0017] Figure 1 The present invention provides a flowchart of an intelligent diagnostic method for the operational quality of online pollution source monitoring equipment based on EOBD. Detailed Implementation

[0018] To make the objectives and advantages of the present invention clearer, the present invention will be further described below with reference to embodiments; it should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the present invention.

[0019] Preferred embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0020] Detailed Description of Embodiments To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the scope of protection of the present invention.

[0021] This embodiment provides an intelligent diagnostic method for the operational quality of online pollution source monitoring equipment based on EOBD. This method transforms traditional on-site manual verification into a data flow and algorithm processing process that can be executed by a computer. The method primarily relies on a mobile terminal configured with a specific algorithm model, acquiring real-world data from the site via near-field communication and performing automated calculations using a local model.

[0022] The complete data processing flow and step logic of this method are as follows:

[0023] Step S1: Construct an intelligent diagnostic model for the operation quality of online monitoring equipment and complete parameter initialization.

[0024] The core objective of this step is to transform abstract expert verification experience into a digital model file executable by mobile terminals. At the data input level, the verification rule set for online pollution source monitoring equipment across three dimensions—functional settings, instrument parameters, and operation and maintenance procedures—is extracted as the raw input data. At the processing and execution level, a rule transformation processing step is first performed, parsing and converting the aforementioned textual verification rule set into a computer-executable conditional decision logic tree. Specifically, based on different logic tree branches, four-dimensional digital sub-models are constructed: a device functionality check sub-model for verifying the integrity of the equipment's hardware and software functions; an instrument setting check sub-model for comparing the legality of parameters such as range, slope, and intercept; a violation detection sub-model for identifying sequences of illegal operations; and a fraud identification sub-model for identifying data tampering characteristics.

[0025] The overall model expression for online monitoring and compliance diagnosis is:

[0026] M_total = { M_func, M_set, M_illegal, M_fake}

[0027] in:

[0028] M_total is the overall model for online monitoring compliance diagnosis, which includes 150 standardized inspection items;

[0029] M_func is the device functionality check sub-model, expressed as: M_func (D_param) = ∧ (i=1 to N)fi (D_parami) where D_param is the device parameter dataset, D_parami is the i-th device parameter, fi is the i-th function judgment rule, N is the total number of function check items, and the output is 1 for normal function and 0 for abnormal function.

[0030] M_set is the instrument setting check sub-model, with the expression: M_set (P) = 1, if Plow ≤ P ≤ Phigh; otherwise, it is 0. P is the instrument parameter, and Plow and Phigh are the upper and lower limits of parameter compliance. The output is 1 for parameter compliance and 0 for parameter exceeding the limit.

[0031] M_illegal is the illegal behavior detection sub-model, expressed as: M_illegal (Lop) = ∪ (j=1 to M)gj (Lopj)Lop is the operation log sequence, Lopj is the j-th operation log, gj is the j-th violation judgment rule, M is the number of violation types, and the output is 1 for violation and 0 for no violation;

[0032] M_fake is the fraud detection sub-model, expressed as: M_fake(Top, Scon) = 1 if Var(Scon) > Thvar or Mean(Scon) > Thmean; otherwise, 0. Top is the operation timestamp, Scon is the concentration fluctuation sequence, Var(Scon) is the concentration variance, Mean(Scon) is the concentration mean, and Thvar and Thmean are dynamic thresholds. An output of 1 indicates suspected fraud, and 0 indicates normal data. After generating intermediate results, the algorithm encapsulates the above four digital sub-models at the code level, forming an executable algorithm set including 150 standardized inspection items, thus generating a complete "Intelligent Diagnostic Model for Online Monitoring Equipment Operation Quality". At the output and deployment level, this intelligent diagnostic model for online monitoring equipment operation quality is loaded into the non-volatile memory of the mobile terminal. When the system starts, the mobile terminal's processor loads the model file into the running memory and completes the initialization and allocation of the variables and parameters required for model operation, putting it in a ready state that can be triggered and invoked at any time. Step S2: Establish a direct communication link and acquire core data. This step aims to ensure the authenticity and integrity of the input data and construct a lossless data acquisition path through a hardware-level physical direct connection. During the connection establishment phase, the mobile terminal is brought close to the field data acquisition and transmission instrument. The mobile terminal uses its built-in NFC near-field communication module to sense and acquire the device identification information of the field data acquisition and transmission instrument (as initial input data). Subsequently, the mobile terminal's processor initiates a communication link verification request based on the parsed device identification information; after successful verification, a low-level direct communication link is established with the field data acquisition and transmission instrument based on a preset communication protocol. During the data extraction phase, the data reading logic is triggered upon successful link establishment. The mobile terminal sends a preset data reading command to the field data acquisition and transmission instrument. The data extraction algorithm sends addressing commands to the storage unit of the data acquisition and transmission instrument according to the preset underlying data structure, traversing and extracting core data. The final output core data matrix specifically includes five dimensions of information: device parameter data, daily maintenance data, log data, real-time monitoring data, and historical monitoring data. The aforementioned core data was completely extracted and cached in the mobile terminal's local memory, serving as the foundational input data for subsequent intelligent diagnostic modules. Steps

[0033] S3. Automated Model Operation and Multidimensional Data Cross-validation. This step is the core algorithm execution stage of intelligent diagnosis, aiming to identify abnormal operating behaviors through logical operations and conflict comparisons between multidimensional data. First, the core data cached in memory in step S2 is imported into the intelligent diagnostic model for the online monitoring equipment's operating quality, triggering the model's automated operation. The model first performs formatted parsing and data cleaning on the heterogeneous core data. Subsequently, it calls multiple encapsulated digital sub-models to perform cross-validation and logical comparisons on core data from different dimensions. Taking the specific algorithm logic of the fraud detection sub-model as an example, its processing includes: Step 1 (Feature Extraction): The algorithm extracts the operation and maintenance timestamp sequence and the corresponding set of operation types from the parsed log data, and simultaneously extracts continuous concentration fluctuation sequences from historical monitoring data as intermediate processing data. Step 2 (Time Alignment): The time axis alignment process is executed to accurately map the discrete operation and maintenance timestamps onto the time axis of the continuous concentration fluctuation sequence, thereby defining the analysis time window that strictly corresponds to the specific operation type. Step 3 (Threshold Comparison): Within a defined time window for a specific operation type, the algorithm performs mathematical statistical operations on the concentration fluctuation sequence to calculate its variance or mean. Subsequently, the calculated variance or mean is logically compared with a preset dynamic threshold boundary. Output Result Generation: If the logical judgment result indicates that the variance or mean of the concentration fluctuation sequence exceeds the preset dynamic threshold boundary, the device is suspected of logical conflict or tampering. At this time, the model generates a diagnostic result vector in memory and marks the corresponding abnormal operating behavior node and violation characteristic value at the corresponding position in the vector as the final output of this step. Step S4: Diagnostic Report Generation and Problem Rectification Closed-Loop Tracking.

[0034] The equipment and daily data standard setting table is as follows:

[0035] The inspection items and content rules are as follows:

[0036] The actual inspection items are as follows:

[0037] I. Inspection Items

[0038] 1.1 Check the project's input data (retrieve fields from core data consistently).

[0039] The system retrieves data from the same "core data" set during execution, using it as input fields for the checked items. The core data includes at least:

[0040] Equipment parameter data, daily maintenance data, log data, real-time monitoring data, and historical monitoring data (and their corresponding timestamp / number fields).

[0041] Each inspection item only needs to declare in the configuration which fields it depends on (such as parameter values, limits, operationId, time, statistical series, etc.).

[0042] 1.2 General processing flow (fixed template) for each inspection item

[0043] For any inspection item (rule entry) Ck, the system executes it along the same pipeline and generates the corresponding diagnostic results:

[0044] S1 - Inspecting the Pipeline: Extraction → Preprocessing → Calculation → Judgment → Evidence Packaging → Writing to Diagnostic Vector

[0045] Extraction: Extract data from the core data according to the dependency fields declared by Ck to obtain the input Xk.

[0046] Preprocessing: Constructing time windows / aligning series / preparing units or statistics (to obtain Pk)

[0047] Calculation: Calculate the quantities required for this rule (e.g., mean, variance, error, whether it exceeds the limit, etc.) to obtain scorek.

[0048] Determination: Map scorek to hit / abnormal (to obtain hitk, along with confidence confk and reasonk reasonk)

[0049] Evidence Packaging: Package the key quantities, time windows, operationId / thresholds, etc. used in this calculation into Ek.

[0050] Write to the diagnostic vector: Write {hitk, confk, reasonk, Ek} to the corresponding node of the diagnostic result vector.

[0051] In this way, whether you have 100 or 150 inspection items, it is just "different number segments + different calculation parameters", and the process remains the same.

[0052] 1.3 Handling strategy for missing or unknown fields (ensuring template execution)

[0053] When a critical field that Ck depends on is missing or cannot be resolved:

[0054] Set the status of this inspection item to: unknown

[0055] Not included in the "hit determination" scoring

[0056] The evidence / reason code field should specify the list of missing fields or the parsing error code.

[0057] Other inspection items will continue to be performed (without disrupting the overall process).

[0058] II. Diagnostic Result Vector → Standardized Diagnostic Report

[0059] 2.1 Generate a "Problem List" from "Hit Nodes"

[0060] After the program completes its calculations, it generates a diagnostic result vector Vdiag. When a node / dimension is "hit / anomaly" (hit=1), a "problem list" record is generated in the report.

[0061] Each list of questions should contain at least:

[0062] Problem Category: Functionality / Settings / Illegal / Fraudulent (Determined by the sub-model to which the hit node belongs)

[0063] Problem Title / Inspection Item Number: Corresponding inspection item

[0064] List of problematic fields:

[0065] 1) Evidence section: Time window, key statistics (such as Mean / Var / mutation rate), thresholds used, log IDs / operationIds involved, etc.

[0066] 2) Reason code / confidence level: conf and reason are used to explain "why an exception was detected".

[0067] Sort by: Severity (first choice) + Confidence (second choice) + Time (third choice)

[0068] 2.2 Summary indicators for the report (clarify whether "unknown" is included)

[0069] Summary metrics such as "compliance rate / hit rate" are defined as follows:

[0070] The denominator only counts the evaluated items.

[0071] "Unknown" is not included in the denominator.

[0072] hitCount / compliance items are only calculated within the evaluated set.

[0073] 1. Data structure definition of the diagnostic result vector Vdiag

[0074] In this embodiment of the invention, the diagnostic result vector Vdiag is organized using nodes as indices, denoted as:

[0075] Vdiag = { node_i} , i = 1..I

[0076] Each node_i contains at least the following fields:

[0077] 1) nodeId: Node identifier;

[0078] 2) checkItemId: The identifier of the item to be checked;

[0079] 3) modelClass: The sub-model category to which the node belongs, including one of the following: equipment functionality check, instrument setting check, illegal behavior detection, and fraud identification;

[0080] 4) hit: Hit / abnormality indicator value, which can be 0 or 1;

[0081] 5) Confidence: The confidence level value, which is a real number between 0 and 1;

[0082] 6) Severity: The severity level, with values ​​of L1 / L2 / L3;

[0083] 7) reasonCode: Exception reason code;

[0084] 8) evidence: A set of evidence reference fields used to generate a standardized diagnostic report problem list, which includes at least key statistics, time windows, threshold parameters, and corresponding log / operation identifiers related to the judgment.

[0085] If a required input field for a certain inspection item is missing or fails to be parsed, the corresponding node will be set as follows:

[0086] hit = 0, confidence decreases according to the severity of the missing information;

[0087] And mark the missing field or parsing error type in reasonCode.

[0088] 2. Mapping relationship between node identifiers and inspection items

[0089] The binding relationship between the nodeId and the check item is a static configuration relationship. That is, each check item (checkItemId) generates a unique node identifier (nodeId) during the model building phase and establishes the following mapping:

[0090] nodeId ↔ checkItemId ↔ modelClass

[0091] When the intelligent diagnostic model for the operational quality of the online monitoring equipment performs cross-validation on data from different dimensions, it only writes the diagnostic result field to the node corresponding to the configuration mapping, ensuring that the report can definitively pinpoint "which inspection item the problem belongs to" when it is generated.

[0092] 3. Calculation methods for confidence and severity

[0093] To ensure the reproducibility of the judgment results, the confidence level and severity are calculated using configurable determination rules.

[0094] 3.1 Method for determining confidence level (segmentation rules)

[0095] The confidence score for node_i, assuming the completeness score of the required key evidence field is q ∈ [0,1] and the threshold deviation score is d ∈ [0,1], can be determined by the following rules:

[0096] When q is below the preset integrity lower limit: confidence = q;

[0097] Otherwise: confidence = w1*q + w2*d, where w1+w2=1, and w1 and w2 are given by the configuration.

[0098] Where q is determined by whether the evidence field required by the node exists, whether it can be parsed, and whether it falls within the allowed time range; d is determined by the degree of deviation between the statistic calculated by this node and the dynamic threshold boundary.

[0099] 3.2 Method for determining severity level (threshold classification)

[0100] The severity level is determined by grading the intensity of anomalous evidence, for example:

[0101] L1: Mild abnormality (threshold just exceeded or evidence deviates only slightly);

[0102] L2: Moderate abnormality (threshold significantly exceeded and key evidence meets the main judgment criteria);

[0103] L3: Severe anomaly (threshold significantly exceeded or multiple chains of evidence are met simultaneously).

[0104] The above-mentioned tier boundaries are given by the configuration and should be consistent with d used in confidence calculation.

[0105] 4. Source mapping of standardized diagnostic report issue list fields

[0106] When generating the standardized diagnostic report, if node_i.hit = 1, a "problem list" entry corresponding to that node will be generated in the report. The field source rules for the entry are as follows (ensuring implementation):

[0107] 1) Check the item number: retrieve node_i.checkItemId;

[0108] 2) Problem category: Retrieving node_i.modelClass;

[0109] 3) Exception reason description: generated from the template corresponding to reasonCode;

[0110] 4) Key data in the evidence section: extract the statistics and threshold parameters contained in node_i.evidence;

[0111] 5) Time window: Take the operation and maintenance time window, sampling time window, or aligned analysis time window identifier from node_i.evidence.

[0112] This ensures that the report is traceable and reproducible, and the evidence section can directly locate the key intermediate results of the diagnostic calculation.

[0113] To further illustrate the feasibility of fraud detection and related statistical determination, the key quantities defined in the dynamic threshold determination include at least:

[0114] 1) Mutation rate (or relative change):

[0115] ChangeRate = (S_post - S_pre) / S_pre

[0116] Here, S_pre and S_post represent the statistical results before and after the same operation time window, respectively.

[0117] 2) Core conditions (logic or condition) for determining fraud:

[0118] A suspected anomaly is determined when any one of the following conditions is met:

[0119] Var(Scon) > Th_var; or Mean(Scon) > Th_mean; or ChangeRate is not within the configured allowed range (e.g., ±Th_k).

[0120] Where Var(Scon) and Mean(Scon) are the variance and mean of the concentration fluctuation sequence; Th_var, Th_mean, and Th_k are dynamic threshold parameters derived from configuration files or historical baseline statistics.

[0121] III. Rectification Closed Loop: "Fields - Binding - Validation - Status Update" in the Rectification Response

[0122] 3.1 Minimum fields that a receipt should include (for server verification)

[0123] When the server receives the rectification response, the response must include at least:

[0124] reportId (which diagnostic report does it correspond to?)

[0125] issueId (which issue in the issue list it corresponds to)

[0126] Types of rectification (calibration / repair / replacement / parameter correction / process correction, etc.)

[0127] Finish Time

[0128] Rectification Person in Charge / Organization

[0129] Summary of key evidence for rectification (or numerical comparison: before / after, calibration error before and after, information on repaired or replaced parts, etc.)

[0130] Attachment verification information (such as hash / number or signature information, used for verification).

[0131] 3.2 Server verification rules (three types of verification that can be implemented)

[0132] After the receipt is submitted, it will be validated according to the following rules:

[0133] Correlation verification

[0134] The reportId of the receipt must exist in the task.

[0135] The issueId must belong to the set of issues pending rectification generated by this report.

[0136] The rectification type must match the issue category (function / settings / illegal / fraudulent).

[0137] Content integrity verification

[0138] The required evidence fields must be filled in according to the issue category (e.g., for setting violations, evidence of the before / after of key parameters or compliance intervals must be provided; for falsification, a summary of statistical / calibration comparison evidence must be provided).

[0139] Timing rationality verification

[0140] The finishTime must not be earlier than the start of the reporting evidence time window (or earlier than the evidence time before rectification).

[0141] If the receipt includes a calibration time / operation reference, it must fall within the allowable deviation range.

[0142] 3.3 Success / Failure and Status Update

[0143] If all three checks pass: the issueId status is updated to closed loop.

[0144] If any validation fails: the status is updated to Failure - Reason Code (e.g., association mismatch / field missing / inappropriate timing / evidence verification failure).

[0145] When all issueIds have been closed: the task status is updated to rectification completed.

[0146] Example illustration:

[0147] The operation log of an online monitoring device at a wastewater discharge outlet recorded that a "parameter modification / calibration" operation was performed at 10:00:00 on May 12, 2026. Ten sets of COD concentration data (unit: mg / L) were captured 5 minutes before and after this moment.

[0148] Pre-operation concentration sequence: 32.4, 33.1, 32.9, 33.5, 32.7

[0149] Post-operation concentration sequence: 8.2, 7.8, 33.0, 32.8, 33.2

[0150] Merged sequence: Scon = [32.4, 33.1, 32.9, 33.5, 32.7, 8.2, 7.8, 33.0, 32.8, 33.2]

[0151] Calculate statistical characteristics:

[0152] Mean = 27.96

[0153] Variance Var = 137.45

[0154] The concentration mutation rate K = (7.8−32.7) / 32.7 ≈ −0.76

[0155] Preset dynamic threshold:

[0156] Th_mean = 30.0

[0157] Th_var = 50.0

[0158] Th_k = ±0.3

[0159] Cross-comparison verification process (complete logic for wastewater scenario)

[0160] Statistical feature comparison: Variance 137.45 > Th_var 50.0, mean 27.96 deviates from baseline, mutation rate −0.76 exceeds ±0.3 interval, all three trigger anomalies;

[0161] Operation - Data Linkage Comparison: This operation involved parameter modification without a formal calibration procedure. The concentration experienced a sharp drop followed by an instantaneous recovery, which contradicts the logical smooth change that should occur during normal calibration.

[0162] Parameter-Data Consistency Comparison: No valid changes were found in the range, slope, and intercept during the same period; no parameter basis was found for the abnormal concentration.

[0163] Historical baseline comparison: Significant deviation from the concentration baseline (30–35 mg / L) of the same period in the past 7 days, indicating non-operational fluctuations;

[0164] Cross-comparison of auxiliary parameters: Within the same time window, there were no significant changes in flow rate, pH, water temperature, and dissolved oxygen, only the COD concentration dropped abnormally, which was determined to be human intervention / data falsification.

[0165] Through multi-dimensional cross-validation, the fraud detection sub-model outputs high-confidence anomalies and marks abnormal behavior nodes, violation confidence levels, key feature values, and complete evidence chain data in the diagnostic result vector. This step aims to transform the digitized diagnostic result vector into business execution instructions, forming a data-driven management closed loop. In the report generation stage, using the diagnostic result vector output in step S3 as input data, the processing engine maps and parses the marked abnormal operation nodes in the vector one by one into specific abnormal problem description text according to the preset report template mapping rules, and then renders and generates a structured and standardized diagnostic report.

[0166] The specific mapping rules are as follows:

[0167] vfunc=1 corresponds to abnormal device function; vset=1 corresponds to improper instrument settings; villegal=1 corresponds to illegal activities; vfake=1 corresponds to fraud.

[0168] This process then generates a structured, standardized diagnostic report, with the following specifications:

[0169] Report format: PDF, supports encryption, verification, and record keeping.

[0170] Report content: Enterprise information includes enterprise name, monitoring location, environmental protection manager, enterprise address, inspection time, operation and maintenance unit, and signature; overall inspection status includes total inspection items, compliant items, problematic items, and compliance rate; the problem list for this inspection includes inspection items, inspection content, inspection results, and remarks; the compliant items for this inspection include inspection items, inspection content, inspection results, and remarks.

[0171] During the push and tracking phase, the mobile terminal pushes the standardized diagnostic report to a preset management node (i.e., the user terminal of the relevant responsible personnel) via a wireless communication network. Simultaneously, state machine logic is triggered on the server side to generate a status tracking task bound to the unique identifier of the standardized diagnostic report. The initial status of the task is set to "Pending Rectification." During the closed-loop confirmation phase, the server side monitors and receives rectification feedback data uploaded by the enterprise side regarding the specific issues of the abnormal operation in real time. The server side verifies the validity of the rectification feedback data according to preset verification rules; only when the rectification feedback data passes the logical verification, the server side executes a status update command, updating the node status of the status tracking task to "Closed Loop." This completes the entire technical closed loop from on-site data collection and intelligent diagnostic output to rectification status confirmation.

[0172] This embodiment also provides an intelligent diagnostic system for the operational quality of online pollution source monitoring equipment based on EOBD. This system consists of multiple logically cooperating functional modules, including: a model configuration module: used to execute step S1, constructing an intelligent diagnostic model for the operational quality of the online monitoring equipment and loading it onto the mobile terminal, completing memory allocation and parameter initialization; a data acquisition module: used to execute step S2, establishing a direct communication link with the field data acquisition and transmission device through the NFC near-field communication module of the mobile terminal, and extracting core data including equipment parameter data, daily maintenance data, log data, real-time monitoring data, and historical monitoring data based on a preset communication protocol; an intelligent diagnostic module: used to execute step S3, inputting the core data into the intelligent diagnostic model for the operational quality of the online monitoring equipment, and outputting a diagnostic result vector characterizing abnormal equipment operation behavior through cross-validation and logical comparison operations such as time axis alignment and dynamic threshold boundary comparison; and a closed-loop output module: used to execute step S4, generating a standardized diagnostic report based on the diagnostic result vector mapping, and performing targeted push notifications and server-side rectification status verification and task tracking. Furthermore, this embodiment also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method steps described in any one of steps S1 to S4 above. Through the coordinated use of hardware and software resources, this solution breaks away from the traditional on-site inspection's heavy reliance on human experience, achieving automated judgment and closed-loop tracking throughout the entire process based on objective underlying data.

[0173] This method deeply extracts practical experience from environmental law enforcement experts and industry knowledge bases, and constructs a highly intelligent online monitoring equipment operation quality diagnosis model through algorithmic modeling. This forms a standardized, replicable, and rapid compliance inspection system, effectively solving problems such as inconsistent inspection standards and insufficient accuracy, ensuring that all violations are investigated thoroughly and without blind spots. It breaks through the bottleneck of traditional inspections' high reliance on human experience, achieving unmanned, rapid on-site inspections of the online monitoring system. It completes comprehensive investigations without complex on-site operations, effectively solving the problem of incomplete investigations while ensuring the fairness and impartiality of the inspection work. Significant efficiency improvements are achieved, reducing the inspection time for a single enterprise from one day to less than 10 minutes, significantly improving the pain points of long inspection times and low efficiency in traditional on-site inspections. The entire inspection process is traceable and reviewable, with all operations leaving verifiable records. Using this method, a single mobile device can complete rapid equipment testing for over 100 enterprises daily, eliminating the need for large-scale deployment and significantly reducing regulatory manpower and material resources. This method provides regulators with a more convenient, efficient, and accurate inspection tool, comprehensively optimizes the law enforcement environment, and provides more reliable technical support for the accurate identification of illegal and irregular activities and the standardization of corporate environmental management.

[0174] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A method for intelligent diagnosis of the operational quality of online pollution source monitoring equipment based on EOBD, characterized in that, Includes the following steps: S1. Construct an intelligent diagnostic model for the operational quality of online monitoring equipment and load it onto a mobile terminal, completing the parameter initialization of the intelligent diagnostic model for the operational quality of online monitoring equipment; the intelligent diagnostic model for the operational quality of online monitoring equipment includes multiple digital sub-models generated based on expert verification logic transformation; S2. The mobile terminal establishes a direct communication link with the field data acquisition and transmission instrument through the NFC near-field communication module, and sends a data reading command to the field data acquisition and transmission instrument based on the preset communication protocol to obtain the core data of the target pollution source online monitoring device; S3. The core data is imported as input data into the intelligent diagnostic model for the operation quality of the online monitoring equipment, triggering the automated operation of the intelligent diagnostic model for the operation quality of the online monitoring equipment; the intelligent diagnostic model for the operation quality of the online monitoring equipment parses the core data, and performs cross-validation and logical comparison of the core data in different dimensions through multiple digital sub-models, and outputs a diagnostic result vector representing the abnormal operation behavior of the equipment; S4. Based on the diagnostic result vector, generate a standardized diagnostic report containing specific problems of abnormal operation, and push the standardized diagnostic report to a preset management node to further trigger problem rectification.

2. The intelligent diagnostic method for the operational quality of online pollution source monitoring equipment based on EOBD according to claim 1, characterized in that, In step S1, the step of constructing an intelligent diagnostic model for the operational quality of online monitoring equipment includes: a1. Extract the set of verification rules for online monitoring equipment of pollution sources in terms of function settings, instrument parameters, and operation and maintenance procedures; a2. Transform the set of verification rules into a conditional decision logic tree, and construct sub-models for equipment functionality inspection, instrument setting inspection, illegal behavior detection, and fraud identification respectively; a3. The above sub-models are encapsulated into the intelligent diagnostic model for the operation quality of the online monitoring equipment, forming an executable algorithm set including 150 standardized inspection items.

3. The intelligent diagnostic method for the operational quality of online pollution source monitoring equipment based on EOBD according to claim 1, characterized in that, Step S2, which involves establishing a direct communication link and acquiring core data, includes the following steps: b1. The mobile terminal obtains the device identification information of the field data acquisition and transmission instrument via NFC sensing; b2. Based on the device identification information, complete the communication link verification; extract the core data from the field data acquisition and transmission instrument according to the preset data structure. The core data includes: device parameter data, daily maintenance data, log data, real-time monitoring data, and historical monitoring data.

4. The intelligent diagnostic method for the operational quality of online pollution source monitoring equipment based on EOBD according to claim 3, characterized in that, In step S3, the specific processing steps for cross-validation and logical comparison include: c1. Extract the operation and maintenance timestamps and operation types from the log data, and the concentration fluctuation sequences from the historical monitoring data; c2. Align the maintenance timestamp with the concentration fluctuation sequence on the time axis; c3. Using the fraud detection sub-model, determine whether the variance or mean of the concentration fluctuation sequence exceeds the preset dynamic threshold boundary within the time window of a specific operation type. If so, mark the corresponding abnormal operation behavior node in the diagnostic result vector.

5. The method according to claim 1, characterized in that, In step S4, the steps that trigger the closed-loop process for problem rectification include: d1. Push the standardized diagnostic report to the user terminal of the relevant responsible personnel; d2. Generate a status tracking task on the server side that is bound to the standardized diagnostic report, and receive and verify the rectification feedback data for the specific problems of the abnormal operation in real time; d3. Once the rectification feedback data passes verification, update the node status of the status tracking task to "closed loop".

6. A smart diagnostic system for the operational quality of online pollution source monitoring equipment based on EOBD, characterized in that, include: Model configuration module: Used to build an intelligent diagnostic model for the operational quality of online monitoring equipment and load it onto the mobile terminal, and complete parameter initialization; Data acquisition module: Used to establish a direct communication link with the field data acquisition and transmission instrument through the NFC near-field communication module of the mobile terminal, and to acquire core data based on the preset communication protocol; Intelligent diagnostic module: Used to input the core data into the intelligent diagnostic model for the operation quality of the online monitoring equipment, and output a diagnostic result vector characterizing the abnormal operation behavior of the equipment through cross-validation and logical comparison operations; Closed-loop output module: used to generate standardized diagnostic reports based on the diagnostic result vector, and to push and track the rectification status.

7. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method according to any one of claims 1 to 6.

8. A computer-readable storage medium storing computer instructions that, when executed on a computer device, cause the computer device to perform the method according to any one of claims 1 to 6.

Images