Iot data rules engine algorithm

Abstract

The application discloses an Internet of Things data rule engine algorithm, comprising the following steps: a data receiving and preprocessing step: real-time receiving data streams from multiple Internet of Things devices, and preprocessing the data streams to obtain standardized data; a rule matching step: inputting the standardized data into a rule engine, the rule engine pre-storing multiple rules, each rule comprising a trigger condition and an execution action; a weight calculation step: calculating a comprehensive weight value for each rule, the calculation of the comprehensive weight value depending on a historical performance credibility obtained based on rule historical trigger records and an instant correlation degree obtained based on comparison of the current data and a trigger condition threshold value; a rule sorting and execution step: sorting all rules in descending order according to the comprehensive weight values, and generating a rule execution sequence. The application can improve the Internet of Things data quality and rule precision of an intelligent power station, support collaborative analysis and self-learning, and reduce cost and improve efficiency.

Description

IoT Data Rule Engine Algorithm Technical Field

[0001] This invention relates to the field of data processing, and more specifically to an Internet of Things (IoT) data rule engine algorithm. Background Technology

[0002] In the application of IoT technology, existing IoT data processing and rule engine technologies have several shortcomings, forming the technical background of this case: First, the data streams generated by IoT devices are easily affected by electromagnetic interference, sensor malfunctions, environmental fluctuations, etc., resulting in noise. Existing technologies mostly use static thresholds for noise filtering, which cannot adapt to dynamic changes in device operating conditions. This can easily lead to misjudging normal data as noise or missing real noise, making it difficult to guarantee the quality of preprocessed data and affecting the accuracy of subsequent rule matching. Second, when evaluating rule priority, rule engines often rely solely on whether the trigger threshold is met, without quantifying the rule's historical performance and current data. The urgency of the association with thresholds can lead to rules with high misjudgment rates being prioritized, resulting in ineffective maintenance, or rules corresponding to urgent faults being delayed due to insufficient priority. Third, for IoT device data in multiple physical locations, existing technologies often analyze single-device data in isolation, failing to identify the linkage effects between devices and easily missing hidden faults caused by multi-device collaboration. Fourth, existing rule engines lack online self-learning capabilities; rule performance evaluation data is not dynamically updated with actual operating results. After long-term use, rule reliability becomes disconnected from actual operating conditions, making it difficult to adapt to rule performance degradation caused by equipment aging and changes in operating conditions, leading to decreased fault identification accuracy and increased maintenance costs. These shortcomings of existing technologies mean that IoT data rule engines cannot meet the high reliability maintenance requirements of scenarios such as smart power plants in terms of data processing quality, rule execution accuracy, multi-device collaborative analysis capabilities, and long-term adaptability. Therefore, an IoT data rule engine algorithm is proposed. Summary of the Invention

[0003] The present invention solves the above-mentioned technical problems through the following technical solution, and the present invention includes the following steps:

[0004] Data reception and preprocessing steps: Real-time reception of data streams from multiple IoT devices, and preprocessing of the data streams to obtain standardized data;

[0005] Rule matching steps: Standardized data is input into the rule engine. The rule engine has multiple rules pre-stored, each of which includes triggering conditions and execution actions;

[0006] Weight calculation steps: Calculate a comprehensive weight value W for each rule. The calculation of the comprehensive weight value depends on the historical performance confidence C obtained based on the rule's historical trigger records and the immediate relevance R obtained based on the comparison of the current data with the trigger condition threshold.

[0007] Rule sorting and execution steps: Sort all rules in descending order according to the comprehensive weight value W, generate a rule execution sequence, and check and trigger the rules that meet the conditions in sequence according to this sequence, and execute the corresponding device control or alarm commands.

[0008] The data stream preprocessing includes data cleaning and smoothing steps:

[0009] A sliding window model is used to obtain recent data sequences, and the moving average μ and moving standard deviation σ of the data within the window are calculated.

[0010] The outlier index Z is quantified by calculating the multiple of each data point's deviation from the moving average relative to the moving standard deviation. The calculation method is as follows:

[0011] ;

[0012] Where x is the current data point;

[0013] Data points whose anomaly index Z exceeds the dynamic threshold are identified as noise and are filtered out or smoothed out.

[0014] Furthermore, the dynamic threshold Adaptive adjustments are made based on historical fluctuations in the data stream;

[0015] The adjustment method is as follows:

[0016] Record and maintain a historical anomaly index sequence calculated from historical data points according to time windows, and calculate the moving average of this sequence. and with the base threshold The linear superposition calculation process is as follows:

[0017] ;

[0018] Where k is the sensitivity adjustment coefficient. It is the moving average of the historical anomaly index sequence.

[0019] Furthermore, when calculating the historical performance confidence level C, it is necessary to call the historical trigger records of the rules, which contain the number of true positive triggers TP and the number of false positive triggers FP;

[0020] Among them, the number of true positive triggers (TP) refers to the number of times a corresponding equipment abnormality or malfunction has actually occurred after the rule is triggered, while the number of false positive triggers (FP) refers to the number of times a false alarm has been confirmed after the rule is triggered.

[0021] Furthermore, the calculation process for the historical performance reliability C is as follows: using the number of true positive triggers TP and the number of false positive triggers FP, the reliability is quantified by calculating the proportion of the number of true positive triggers in the total number of effective triggers. The specific calculation process is as follows:

[0022] .

[0023] Furthermore, the calculation process for the instantaneous relevance R is as follows:

[0024] For numerical trigger conditions, the normalized result of the absolute difference between the current data value x and the trigger condition threshold t is calculated and mapped to a similarity score. The specific calculation process is as follows:

[0025] ;

[0026] Where U and L represent the upper and lower limits of the normal range of this type of data, respectively.

[0027] Furthermore, the calculation process of the comprehensive weight value W is as follows: the historical performance reliability C and the immediate relevance R are linearly fused using preset weight coefficients. The calculation process is as follows:

[0028] ;

[0029] Where α and β are preset weighting coefficients and satisfy α+β=1.

[0030] Furthermore, it also includes a multi-source data collaborative analysis step: for IoT device data from different physical locations, the statistical correlation ρ between their data sequences is calculated to determine whether there is a linkage effect in the device operating status; the calculation process of the correlation ρ is as follows:

[0031] ;

[0032] in, Let X be the covariance of the data sequences of device X and device Y. and , respectively, are the standard deviations of the two sequences;

[0033] when If the sensitivity exceeds the preset threshold, cross-device collaboration rules will be triggered.

[0034] Furthermore, it also includes a feedback learning step: based on the triggering effect feedback of the executed rule, the historical triggering record of the rule is dynamically updated; specifically, if the executed action effectively solves the problem, its true positive trigger count (TP) is increased, otherwise its false positive trigger count (FP) is increased, thereby realizing the online self-learning and continuous optimization of the rule engine.

[0035] Compared with existing technologies, this invention has the following advantages: The IoT data rule engine algorithm uses a sliding window model combined with an anomaly index Z and adaptive dynamic thresholds for data cleaning and smoothing, effectively filtering out noise and ensuring standardized data quality; it determines rule weights by comprehensively considering the historical performance reliability and immediate relevance of rules, and executes rules according to weight, improving the accuracy and efficiency of rule triggering; it dynamically updates historical rule trigger records through feedback learning, enabling online self-learning and continuous optimization of the rule engine; and it calculates the correlation of device data sequences through multi-source data collaborative analysis, triggering cross-device collaborative rules, balancing single-device data processing and multi-device linkage effect detection, enhancing the comprehensiveness and adaptability of data processing, and comprehensively improving the reliability and intelligence level of IoT data processing, device control, and alarm response, making the system more worthy of widespread adoption. Attached Figure Description

[0036] Figure 1 is a flowchart of the present invention. Detailed Implementation

[0037] The embodiments of the present invention are described in detail below. These embodiments are implemented based on the technical solution of the present invention, and provide detailed implementation methods and specific operation processes. However, the scope of protection of the present invention is not limited to the following embodiments.

[0038] As shown in Figure 1, this embodiment provides a technical solution: an IoT data rule engine algorithm, including the following steps:

[0039] Data reception and preprocessing steps: Real-time reception of data streams from multiple IoT devices, and preprocessing of the data streams to obtain standardized data;

[0040] Rule matching steps: Standardized data is input into the rule engine. The rule engine has multiple rules pre-stored, each of which includes triggering conditions and execution actions;

[0041] Weight calculation steps: Calculate a comprehensive weight value W for each rule. The calculation of the comprehensive weight value depends on the historical performance confidence C obtained based on the rule's historical trigger records and the immediate relevance R obtained based on the comparison of the current data with the trigger condition threshold.

[0042] Rule sorting and execution steps: Sort all rules in descending order according to the comprehensive weight value W, generate a rule execution sequence, and check and trigger the rules that meet the conditions in sequence according to this sequence, and execute the corresponding device control or alarm commands.

[0043] The data stream preprocessing includes data cleaning and smoothing steps:

[0044] A sliding window model is used to obtain recent data sequences, and the moving average μ and moving standard deviation σ of the data within the window are calculated.

[0045] The outlier index Z is quantified by calculating the multiple of each data point's deviation from the moving average relative to the moving standard deviation. The calculation method is as follows:

[0046] ;

[0047] Where x is the current data point;

[0048] Data points whose anomaly index Z exceeds the dynamic threshold are identified as noise and are filtered out or smoothed out.

[0049] For data streams from IoT devices in smart power plants (such as main transformer temperature sensors and generator current sensors), a sliding window model is used to extract recent data sequences, calculate the moving average and moving standard deviation, and then use an anomaly index to quantify the degree of deviation of data points from normal fluctuations. Combined with dynamic threshold filtering / smoothing of noise (such as electromagnetic radiation interference and anomalies caused by loose sensor connectors), this avoids misjudgments / missed judgments caused by static thresholds not being able to adapt to power plant operating condition fluctuations (such as peak current increases and temperature fluctuations caused by transformer load changes). This ensures the accuracy of the pre-processed data, provides a high-quality data foundation for subsequent rule matching such as over-temperature alarms and over-current protection, reduces erroneous equipment control commands caused by noise (such as accidental start of the cooling system and accidental tripping), and improves the operational stability and safety of smart power plants.

[0050] For example, in the scenario of monitoring the winding temperature of a 35kV main transformer in a smart power station, the transformer is equipped with a high-precision fiber optic temperature sensor that collects winding temperature data (unit: °C) once every minute. The core control rules are "start the forced cooling system when the temperature is ≥88℃" and "trigger an emergency alarm when the temperature is ≥98℃". The data needs to be pre-processed to filter out abnormal temperature values ​​caused by electromagnetic interference from the transformer core and instantaneous attenuation of the fiber optic link.

[0051] Application of the sliding window model: Set the sliding window size N=5 (that is, each time the temperature data of the most recent 5 collection cycles are taken to form a recent data sequence). During a peak electricity consumption period in summer, the original temperature data collected by the sensor are x1=75, x2=76, x3=78, x4=77, x5=82 (the first 5 data points, which are consistent with the normal temperature trend of load increase). The 6th data point collected later is x6=102 (an abnormally high value caused by electromagnetic pulse interference in the iron core).

[0052] Moving average Calculation: Based on the 1st to 5th data points in the window, calculate using the formula. Calculations and substitution of data yield:

[0053] This value reflects the average winding temperature over 5 minutes, eliminating the influence of random fluctuations at a single data point.

[0054] Moving standard deviation Calculation: First, follow the formula Calculate the sum of each data point and Substituting the sum of squared deviations into the data, we get:

[0055] ;

[0056] Because power plant data needs to balance volatility and reliability, the sample standard deviation (denominator N-1) is used, and the variance formula is: ,Right now ;

[0057] Then follow the formula Calculate the standard deviation, and get (°C), this value reflects the normal fluctuation range of temperature within 5 minutes, providing a quantitative benchmark for judging "abnormal data".

[0058] Anomaly index Z calculation: according to the formula Calculate the Z-values ​​for the first 1-6 data points respectively:

[0059] The first x=75, ;

[0060] The second x=76, ;

[0061] The third x = 78. ;

[0062] The fourth x = 77. ;

[0063] The 5th x = 82, ;

[0064] The 6th x = 102, As can be seen, the Z value of x=102 is much higher than that of other data points, significantly deviating from normal fluctuations.

[0065] Dynamic threshold determination and noise processing: Combining dynamic threshold logic, the basic threshold of the preset temperature data in the smart power plant is determined. Considering that temperature fluctuations are slightly larger during the summer peak electricity consumption period, the sensitivity adjustment coefficient k is set to 0.4.

[0066] The moving average of the historical anomaly index sequence is obtained by calculating the anomaly index over 15 historical sliding windows. According to the formula Calculate the dynamic threshold and substitute it to get ;

[0067] Compare the Z-values ​​of each data point with The 6th data point It was determined to be noise;

[0068] The replacement value was calculated using the weighted average of the first 5 non-noise data points within the window (the 5th data point, x=82, is weighted at 1.2 because it more closely reflects the current temperature trend, while the others are weighted at 1.0). Replace 102℃ with 79.7℃; avoid triggering the "temperature ≥ 98℃ emergency alarm" due to abnormally high values, prevent unnecessary power plant operation and maintenance shutdowns, and ensure that the pre-processed data accurately reflects the actual temperature status of the transformer, so that the subsequent "temperature ≥ 88℃ start forced cooling" rule can be triggered normally based on real data.

[0069] The dynamic threshold Adaptive adjustments are made based on historical fluctuations in the data stream;

[0070] The adjustment method is as follows:

[0071] Record and maintain a historical anomaly index sequence calculated from historical data points according to time windows, and calculate the moving average of this sequence. and with the base threshold The linear superposition calculation process is as follows:

[0072] ;

[0073] Where k is the sensitivity adjustment coefficient. It is the moving average of the historical anomaly index sequence;

[0074] Dynamic thresholds can adaptively adjust based on historical fluctuations in data streams from IoT devices (such as transformers and generator sensors in smart power plants). This solves the problem that static thresholds cannot adapt to changes in equipment operating conditions (such as data fluctuations caused by peak / off-peak electricity consumption and seasonal temperature differences in smart power plants). It avoids misjudging normal data as noise when the static threshold is too low during periods of large operating condition fluctuations (such as misjudging abnormal indices corresponding to normal high temperatures in transformers during peak electricity consumption), and also prevents the static threshold from being too high during periods of stable operating conditions and missing real noise (such as abnormal values ​​generated by slight sensor interference). This significantly improves the accuracy and adaptability of noise identification, further ensuring the reliability of standardized data after preprocessing. It provides stable and realistic data support for subsequent rule matching, weight calculation, and smart power plant equipment control (such as cooling system start / stop and fault alarms).

[0075] For example, in a scenario involving temperature monitoring of the 35kV main transformer windings in a smart power station, the specific process is as follows:

[0076] Scenario and basic parameter settings: Based on transformer operation and maintenance specifications, preset basic thresholds. (Based on the average level of noise fluctuations under normal transformer operating conditions, a static threshold fixed at 2.0 would not be able to adapt to changes in operating conditions); Sensitivity adjustment coefficient k = 0.3 (calibrated by the power plant operation and maintenance team based on historical data; the larger the k value, the more sensitive the dynamic threshold is to historical fluctuations; here, k = 0.3 balances sensitivity and stability); Historical anomaly index sequence The data is taken from the 10 most recent sliding windows (each window corresponds to 5 minutes of temperature data, i.e., covering the noise fluctuation records of the past 50 minutes) to calculate the historical anomaly index moving average. .

[0077] Historical anomaly index sequence collection and Calculation: Assuming the main transformer recently experienced a change in operating conditions from "peak electricity consumption (windows 1-5) to low electricity consumption (windows 6-10)," the historical anomaly indices calculated for each window are as follows: (During peak hours, temperature fluctuations are large, the equipment heat dissipation load is high, and the Z-value corresponding to the noise is relatively high.) (During off-peak hours, the load is low, temperature fluctuations are gentle, and the Z-value corresponding to the noise is relatively low).

[0078] Calculated using the arithmetic moving average method The formula is:

[0079] Substituting the data, we get:

[0080] .

[0081] Dynamic threshold under different working conditions calculate:

[0082] Peak electricity consumption period adaptation: If the current period is during peak electricity consumption (such as peak load in the evening during summer), the historical anomaly index sequence is updated with the Z values ​​of the most recent 5 peak windows:

[0083] ,at this time Substituting into the dynamic threshold formula, we get:

[0084] ;

[0085] in This is the exponential moving average of abnormalities during peak electricity consumption periods. This is the dynamic threshold during peak electricity consumption.

[0086] If the temperature data point x=86℃ is collected at this time (current window) , Calculate according to the formula ),because The data was determined to be normal high temperature (caused by normal heat dissipation load of the transformer during peak hours), thus avoiding the problem of the static threshold 2.0 misjudging the data as noise;

[0087] Off-peak electricity consumption adaptation: If the current period is an off-peak electricity consumption period (such as the early morning load off-peak), the historical anomaly index sequence is updated with the Z values ​​of the most recent 5 off-peak windows: , , , , ,at this time Substituting into the formula, we get: ;

[0088] in This is the abnormal exponential moving average during periods of low electricity consumption. This is the dynamic threshold for when electricity consumption is underestimated.

[0089] If the temperature data point x=72℃ is collected at this time (current window) , ,calculate ),because The noise was identified as noise (possibly caused by slight electromagnetic interference to the sensor), thus avoiding the problem of the static threshold 2.4 failing to detect this noise.

[0090] Long-term adaptation and effectiveness verification of dynamic threshold: After entering winter, the heat dissipation conditions of the transformer improve, and the historical anomaly index sequence decreases overall. Assume that the Z value of the most recent 10 windows is:

[0091] , , , , , , , , , ,calculate:

[0092] Corresponding

[0093] ;

[0094] This is the moving average of the anomaly index during winter. This is the dynamic threshold during winter.

[0095] If the temperature data point x=68℃ is collected at this time (current window) , , ),because The noise was identified as a temporary loosening of the fiber optic connector and replaced with the average normal data value of 61℃ within the window. If a fixed static threshold of 2.0 is used, Z=3.2 in winter will frequently misjudge normal data (winter temperature fluctuations are small, and normal Z values ​​are mostly below 1.0). If the static threshold is set to 2.5, it will miss the real noise of Z=2.3 during the summer peak. The dynamic threshold can be adjusted in real time according to the season and load conditions, always maintaining the accuracy of noise judgment, ensuring the quality of transformer temperature data preprocessing, and ensuring that subsequent rules such as "start cooling system when temperature ≥ 88℃" and "trigger alarm when temperature ≥ 98℃" are reliably executed based on real data, avoiding equipment control errors.

[0096] When calculating the historical performance confidence level C, the historical trigger record of the rule needs to be called. The record contains the number of true positive triggers TP and the number of false positive triggers FP.

[0097] Among them, the number of true positive triggers (TP) refers to the number of times a corresponding equipment abnormality or malfunction is confirmed to have occurred after the rule is triggered, and the number of false positive triggers (FP) refers to the number of times a false alarm is confirmed to have occurred after the rule is triggered.

[0098] By explicitly calling historical trigger records containing true positive trigger counts (TP, where a device abnormality or fault is confirmed after the rule is triggered) and false positive trigger counts (FP, where a false alarm is confirmed after the rule is triggered) when calculating the historical performance credibility of a rule, the historical validity of the rule can be accurately quantified. This avoids judging rule performance solely based on the number of triggers while ignoring the difference between "valid triggers" and "invalid triggers." This provides real and detailed basic data for the subsequent calculation of historical performance credibility C, thereby ensuring the accuracy of rule weight calculation. This reduces unnecessary operation and maintenance costs in smart power plants caused by rule misjudgment (too many FPs) or the risk of missed faults due to ignoring valid triggers (TPs not being fully counted), and improves the rule engine's accuracy in identifying device abnormalities and the effectiveness of operation and maintenance response.

[0099] For example, in the scenario of a 35kV main transformer in a smart power station, regarding the core rule 1 "fault alarm triggered when transformer winding temperature ≥ 98℃" (used to respond promptly to winding overheating faults and prevent insulation aging or breakdown), a historical trigger record system for this rule should be established as required by this case. The specific process is as follows:

[0100] Recording System Setup: Rule 1's historical trigger record ledger must include six core fields: "Trigger Time, Temperature Data at Trigger Time, Supporting Monitoring Data (Cooling System Status, Load Rate), Operation and Maintenance Confirmation Result (TP / FP), Confirmation Basis, and Processing Result." TP / FP confirmation requires dual evidence.

[0101] Maintenance personnel conduct on-site inspections (such as checking the appearance of the windings and measuring insulation resistance).

[0102] Multi-device collaborative verification (such as comparing data from backup temperature sensors and cooling system pressure / flow data) avoids subjective judgment errors.

[0103] Historical trigger event collection (August 1st - August 31st, 2024, a total of 1 month):

[0104] Triggering Event 1 (August 6, 15:20): The main temperature sensor collected data of 99.5℃, triggering an alarm according to Rule 1; the supporting data showed that the current of cooling system fan No. 3 was 0A (normally it should be 5A), and the transformer load rate was 85% (not exceeding the rated value); the maintenance personnel conducted an on-site inspection within 1 hour and found that the motor of fan No. 3 was burned out, and the local temperature of the winding reached 100℃ (measured by an infrared thermometer), confirming a real fault. This was recorded as a true positive trigger count TP1. Subsequent handling: After replacing the fan, the temperature dropped to 82℃.

[0105] Triggering Event 2 (August 14, 09:10): The main temperature sensor collected data of 98.3℃, triggering an alarm according to Rule 1; the accompanying data showed that all fans in the cooling system were operating normally (current was 5-5.2A), with a load rate of 60%, and the standby temperature sensor data was 83℃; the maintenance personnel conducted an on-site inspection and found that the main sensor probe was covered with insulating oil dirt. After cleaning, the data returned to 83℃, and the equipment was normal. This was recorded as a false positive trigger number FP1. Follow-up action: Establish a weekly cleaning plan for the sensor.

[0106] Triggering event 3 (August 22, 23:00): The main temperature sensor collected data of 101.2℃, triggering an alarm according to rule 1; the accompanying data showed that the cooling system inlet valve was faulty (flow rate was only 30% of normal), and the load rate was 90%; the maintenance personnel handled the situation on-site urgently and found that the inlet valve core was stuck and the winding had slightly overheated and discolored, confirming that there was a real fault, which was recorded as a true positive trigger number TP2. Subsequent handling: After replacing the valve core, the temperature dropped to 78℃.

[0107] Triggering event 4 (August 28, 11:30): The main temperature sensor collected data of 98.8℃, triggering an alarm according to rule 1; the supporting data showed that the cooling system and load rate were normal, and the backup sensor data was 84℃; the maintenance personnel found that the sensor signal cable had poor contact due to vibration, causing the instantaneous data jump. The equipment was normal, and it was recorded as a false positive trigger number FP2. The follow-up action was to reinforce the cable joint.

[0108] The core value of TP / FP recording is evident in the fact that Rule 1 was triggered 4 times within one month. Through the recording system in this case, it is possible to clearly distinguish between TP=2 (TP1, TP2) and FP=2 (FP1, FP2). If TP / FP is not recorded, and only "4 triggers" are counted, the maintenance team cannot determine the actual performance of Rule 1: they cannot know whether the rule timely avoided the escalation of the fault in the two TPs (e.g., if TP,2 had not been alarmed, it might have led to winding insulation breakdown, increasing maintenance costs by more than 10 times), nor can they find the root cause of the two FPs (sensor cleaning, cable contact issues). With TP / FP recording, not only is accurate data provided for subsequent calculation of the historical performance reliability C, but it also points the way for rule optimization (e.g., optimizing sensor maintenance procedures for the root cause of FP), avoiding the problems of "blindly trusting the rules and wasting manpower" or "underestimating the rules and missing fault diagnosis".

[0109] Compared to the risk scenario without TP / FP records: Assuming Rule 1 is triggered again on August 30th (temperature 99.1℃), if TP / FP is not recorded as in this case, the operations team may face two types of misjudgments:

[0110] Because of the frequent triggering in the past (4 times), it was subjectively determined that "most of them are false alarms", and personnel were delayed or not dispatched to handle them. If this time it is actually a cooling system oil pump failure (TP3), it will cause the winding to overheat and be damaged, resulting in a power outage of more than 24 hours.

[0111] To avoid missing a fault and immediately dispatching personnel to handle it, if this is a sensor misread (FP3), it will waste 2 hours of work time for 2 maintenance personnel (the cost of maintenance per instance is about 800 yuan). TP / FP records allow the maintenance team to make quick decisions based on objective data such as "past TP rate of 50% and FP root cause has been partially resolved" (such as first remotely retrieving backup sensor data for verification, and then deciding whether to handle it on-site), balancing fault response speed and maintenance costs.

[0112] The historical performance reliability C is calculated as follows: using the number of true positive triggers (TP) and the number of false positive triggers (FP), the reliability is quantified by calculating the proportion of true positive triggers in the total number of valid triggers. The specific calculation process is as follows:

[0113] ;

[0114] By converting the number of true positive triggers (TP) and false positive triggers (FP) of a rule into a quantifiable historical performance credibility (C), the rule's past effective triggering capability is transformed from a qualitative description into a quantitative value. This avoids the bias of judging the reliability of a rule solely based on the number of triggers or subjective experience, and allows for a direct comparison of the historical performance of different rules. This provides a precise and quantifiable core basis for the subsequent calculation of the comprehensive weight value (W), thereby ensuring that rules with high credibility (high historical performance credibility C) in smart power plants receive higher priority during sorting and execution. This reduces the risk of failures caused by ineffective operation and maintenance or missed judgments (few TP) due to misjudgments (more FP) caused by low credibility rules (low historical performance credibility C), and improves the rule engine's response accuracy and operation and maintenance efficiency to equipment anomalies.

[0115] For example, in the scenario of a 35kV main transformer in a smart power station, we focus on two core alarm rules: Rule 1 ("Winding temperature ≥ 98℃ triggers a fault alarm") and Rule 2 ("Cooling system fan current ≤ 4A triggers a fault alarm," used to monitor fan jamming or motor failure). We calculate the historical performance reliability C of these two rules, as follows:

[0116] Data collection scope and basic information: Statistics on the trigger records of the two rules within the period from August 1st to August 31st, 20xx (1 month). The confirmation basis for TP / FP is the same as before (on-site inspection + multi-device collaborative verification) to ensure the authenticity of the data.

[0117] Rule 1 (Temperature Alarm): According to statistics, it was triggered 4 times in 1 month, of which the number of true positive triggers was TP. C =2 (fan burnout on August 6th and inlet valve malfunction on August 22nd, both confirmed to be genuine faults), number of false positives triggered (FP) C =2 (Sensor dirt on August 14, poor cable contact on August 28, no equipment abnormality confirmed), consistent with previous data.

[0118] Rule 2 (Current Alarm): Triggered a total of 5 times within 1 month. The specific triggering events and confirmation results are as follows:

[0119] Trigger 1 (August 5th, 08:30): Fan 1 current 3.8A, Rule 2 triggered; on-site inspection revealed wear on the bearing of Fan 1, resulting in a decrease in speed, confirming the fault, recorded as... ;

[0120] Trigger 2 (August 12, 16:40): Fan 2 current 3.5A, rule 2 triggered; on-site inspection revealed a loose connection in the power supply line of Fan 2, confirming the fault, recorded as... ;

[0121] Trigger 3 (August 18, 21:10): Fan 3 current 4.0A, rule 2 triggered; on-site inspection showed the fan was operating normally, the current fluctuation was caused by a momentary drop in mains voltage, confirmed to be fault-free, recorded as follows. ;

[0122] Trigger 4 (August 25, 10:20): Fan 1 current 3.2A, triggering rule 2; on-site inspection revealed that dust accumulation on the fan 1 blades caused increased load, confirming the fault, recorded as... ;

[0123] Trigger 5 (August 30, 14:50): Fan 4 current 3.9A, triggering rule 2; on-site inspection revealed a slight inter-turn short circuit in the Fan 4 motor coil, confirming the fault, recorded as... ;

[0124] In summary, Rule 2 , .

[0125] Calculation of historical performance credibility C:

[0126] Calculation of the historical performance reliability C of Rule 1: Substitute into the formula Known , ,have to This means that in the past, 50% of the alarms triggered by Rule 1 were valid (real faults), and 50% were false alarms, indicating a moderate level of reliability.

[0127] Calculation of the historical performance reliability C for Rule 2: Substitute into the formula Known , ,have to This means that in the past, 80% of the alerts triggered by Rule 2 were valid, and 20% were false alarms, indicating a high degree of reliability.

[0128] The impact of historical performance credibility C on rule priority:

[0129] Assume that at 15:00 on August 31st, the main transformer simultaneously meets the triggering conditions of both rules, with a winding temperature of 99.2℃ (rule 1 triggered, instantaneous correlation). Calculations: Normal temperature range L=60℃, U=95℃, threshold t=98℃. ,have to );

[0130] Fan 4 draws 3.8A (triggered by rule 2; normal current range L=4.5A, U=5.5A; threshold t=4A). ).

[0131] Set α=0.6 (historical credibility weight) and β=0.4 (immediate relevance weight), and calculate the overall weight W:

[0132] Rule 1 ;

[0133] Rule 2 ;

[0134] because Rule 2 is prioritized, and the operations team addresses fan current issues first—this order aligns with actual needs: Rule 2 has higher reliability (80% effectiveness), and prioritizing its response prevents fan failures from reducing cooling capacity and exacerbating winding overheating (the cause of the alarm in Rule 1). If historical performance reliability (C) is not calculated, only following the rules... Prioritizing rule 1 may delay fan failure handling and cause the problem to escalate.

[0135] Risks associated with calculating the credibility C of a comparison without historical performance:

[0136] If the historical performance reliability C is not calculated according to the process in this case, and the rule performance is judged solely by the "number of triggers," with Rule 1 triggering 4 times and Rule 2 triggering 5 times, it may be mistakenly judged that "Rule 2 triggers more frequently and has a higher probability of false alarms," ​​thus prioritizing the execution of Rule 1; or subjectively believing that "temperature alarms are more important" and prioritizing the execution of Rule 1, both of these would lead to delayed processing of fan failures (high reliability alarms): Assuming that the 3.8A current of Fan 4 is an early signal of inter-turn short circuit in the motor, a 1-hour delay in processing would cause the motor to burn out, increasing the repair cost from 500 yuan (early repair) to 5000 yuan, and may also cause the cooling system to fail, further increasing the winding temperature to 105°C, triggering an emergency shutdown (loss of approximately 20,000 kWh of power generation from the power station). However, the historical performance reliability C calculation, by quantifying reliability, avoids such subjective misjudgments, ensures that high reliability rules are prioritized for response, and balances the priority of fault handling with maintenance costs.

[0137] The calculation process for the instantaneous relevance R is as follows:

[0138] For numerical trigger conditions, the normalized result of the absolute difference between the current data value x and the trigger condition threshold t is calculated and mapped to a similarity score. The specific calculation process is as follows:

[0139] ;

[0140] Wherein, U and L represent the upper and lower limits of the normal range for this type of data, respectively;

[0141] By normalizing the absolute difference between the current data x and the threshold t under numerical trigger conditions, the fuzzy judgment of "whether the data is close to the threshold" is transformed into a quantitative real-time relevance in the 0-1 range. This avoids ignoring the differences in the degree of data deviation from the threshold based solely on the binary judgment of "meeting / not meeting the threshold" (such as the different urgency of slightly exceeding the alarm threshold and far exceeding the threshold in a smart power plant). Furthermore, by using the normal range UL of the data, the normalization result is ensured to fit the actual operating conditions of the equipment. This allows the real-time relevance to truly reflect the urgency of the current data for rule triggering, providing accurate real-time operating condition basis for the calculation of the comprehensive weight W. Consequently, the rule ranking is more in line with the current equipment status, improving the rationality of the smart power plant's response priority to anomalies of different urgency levels, and reducing the delay in emergency fault response or the over-response to non-emergency faults caused by ignoring the degree of data deviation.

[0142] For example, in the scenario of a 35kV main transformer in a smart power station, we focus on two numerical triggering rules: Rule 1 (“Winding temperature ≥ 98℃ triggers a fault alarm”, historical performance reliability). (Consistent with the previous text), Rule 3 ("Cooling system inlet water pressure ≤ 0.3MPa triggers fault alarm") is used to prevent insufficient cooling. Historical trigger records are TP=7 times and FP=3 times, calculated as follows: The instantaneous relevance R under different data scenarios is calculated, and the response priority is determined by combining the weights. The specific process is as follows:

[0143] Rule parameter settings:

[0144] Rule 1 (Temperature Alarm): According to the transformer operation and maintenance specifications, the normal operating range of winding temperature is as follows:

[0145] (The lower limit of normal; below this value may result in excessive heat dissipation and wasted energy.) (Normal upper limit; exceeding this value for an extended period requires attention to heat dissipation) Trigger threshold (The threshold value that requires an alarm);

[0146] Rule 3 (Pressure Alarm): The normal operating range of the cooling system inlet water pressure is... (The lower limit of normal is required; below this value, the cooling flow is insufficient.) (Normal upper limit; exceeding this value may damage the pipes), trigger threshold (The threshold value that requires an alarm);

[0147] The two rules have α=0.6 (historical credibility weight) and β=0.4 (immediate relevance weight).

[0148] Real-time relevance R calculation in different data scenarios:

[0149] Scenario 1 (Non-emergency anomaly, data slightly exceeding threshold): At 16:30 on August 31, the main transformer simultaneously triggered two rules, and the winding temperature... (Slightly over) ), inlet water pressure (Slightly lower) );

[0150] Calculating R in Rule 1: Substitute into the formula ,have to:

[0151] ;

[0152] Calculating R in Rule 3: Substitute into the formula ,have to:

[0153] ;

[0154] Scenario 2 (Emergency Anomaly, Data Far Exceeds Threshold): At 17:00 on August 31, the fault worsened, and both rules were triggered again, causing the winding temperature to rise. (far exceeding) ), inlet water pressure (far lower) );

[0155] Calculation of R for Rule 1:

[0156] ;

[0157] Calculation of R in Rule 3: ;

[0158] The impact of R-value on rule weight W and response priority:

[0159] Scenario 1 (Non-emergency):

[0160] Rule 1:

[0161] ;

[0162] Rule 3:

[0163] ;

[0164] because Rule 3 takes precedence. Although the urgency is not great, the slightly lower inlet pressure (0.28 MPa) makes Rule 3 more reliable. ),and This indicates that the data is close to the threshold, and prioritizing processing can prevent the pressure from dropping further and causing insufficient cooling, which is in line with the "prevention is better than cure" operation and maintenance logic.

[0165] Scenario 2 (Emergency):

[0166] Rule 1:

[0167] ;

[0168] Rule 3:

[0169] ;

[0170] because Rule 1 takes precedence; the winding temperature of 105℃ far exceeds the threshold. Although lower than scenario 1, but " (The temperature is much higher than 1°C in scenario 1, indicating a greater actual urgency. Prioritizing this can prevent the winding insulation from burning out and avoid further damage. While the inlet water pressure of 0.1 MPa is significantly off, ...) The data indicates that it has far exceeded the normal range (no need to rely on "close to the threshold" for judgment, further processing is required). At this time, the R value accurately distinguishes the difference between "emergency fault (temperature)" and "severe deviation but low response priority (pressure)".

[0171] Compared to the risks of not calculating R-values:

[0172] If R is not calculated in the manner described in this case, and is only based on the binary logic of "triggered when the threshold is met," both rules in Scenario 1 and Scenario 2 will be considered "equal priority." In Scenario 1, the operations team may prioritize handling non-urgent issues with slightly above-average temperatures (99°C), delaying preventative handling of slightly lower pressure, resulting in the pressure further dropping to 0.1MPa in Scenario 2. In Scenario 2, they may prioritize handling pressure issues, delaying emergency cooling of the 105°C temperature, causing winding insulation damage (repair costs exceeding 100,000 yuan). The R value, by quantifying the degree to which the data deviates from the threshold, allows the rule priority ranking to align with the actual urgency, avoiding such operational decision-making errors.

[0173] The calculation process for the comprehensive weight value W is as follows: the historical performance reliability C and the immediate relevance R are linearly fused using preset weight coefficients. The calculation process is as follows:

[0174] ;

[0175] Where α and β are preset weight coefficients and satisfy α+β=1;

[0176] By linearly fusing the historical performance credibility C of a rule (reflecting the long-term reliability of the rule and reducing the risk of misjudgment) with the immediate relevance R (reflecting the urgency of the current data for the rule and conforming to real-time operating conditions), a dual balance between "historical performance" and "current needs" is achieved. This avoids the problems of ignoring current urgent faults due to relying solely on credibility C (such as delaying urgent anomalies with high R and low C) or blindly trusting unreliable rules due to relying solely on R (such as prioritizing false alarms with high R and low C). Furthermore, by adjusting α and β, it can flexibly adapt to different operation and maintenance scenarios of smart power plants (such as increasing α to emphasize reliability and increasing β to emphasize real-time performance). This allows the comprehensive weight W of the rule to accurately quantify the comprehensive value of the rule's reliability and urgency, thereby making the rule execution sequence order more in line with the actual operation and maintenance priorities, improving the accuracy and efficiency of fault response in smart power plants, and reducing operation and maintenance decision-making errors caused by single-dimensional judgment.

[0177] For example, in the scenario of a 35kV main transformer in a smart power station, three core rules are involved:

[0178] Rule 1 (winding temperature ≥ 98℃): (Historical reliability is moderate), temperature within normal range , threshold ;

[0179] Rule 2 (Fan current ≤ 4A): (High historical reliability), current within normal range , threshold ;

[0180] Rule 3 (Inlet water pressure ≤ 0.3 MPa): (Historical reliability is high), pressure is within normal range , threshold ;

[0181] α and β are set according to different operational and maintenance requirements, W is calculated and the response priority is determined, as follows:

[0182] Scenario 1: Routine operation and maintenance (focusing on rule reliability, α=0.6, β=0.4);

[0183] At 9:30 AM on September 2, 20xx, the main transformer triggered rules 1, 2, and 3 simultaneously due to increased load on the cooling system. The current data for each rule is as follows:

[0184] Rule 1: Current temperature , ;

[0185] Rule 2: Current , ;

[0186] Rule 3: Current Pressure , ;

[0187] Calculate each rule W:

[0188] ;

[0189] ;

[0190] ;

[0191] Sorting results: The operations and maintenance team prioritizes processing Rule 2 (fan current) and Rule 3 (inlet water pressure) in parallel, and then processes Rule 1 (temperature). Reasonableness: The historical reliability of Rule 2 and Rule E is higher. , Prioritize addressing issues that can be resolved at their root (low fan current and insufficient pressure are direct causes of temperature rise), avoiding simply addressing temperature (Rule 1) which can lead to recurring failures; if only R ( If the system fails to prioritize rule 1, it will delay the repair of the cooling system, causing the temperature to rise repeatedly and resulting in more than 5 invalid alarms (each alarm costs about 800 yuan in maintenance costs).

[0192] Scenario 2: Emergency Failure (focusing on real-time urgency, α=0.5, β=0.5);

[0193] At 10:10 AM on September 2nd, the main transformer experienced two independent faults:

[0194] Rule 4 (Alarm triggered when oil level ≤ 1.2m): Historically triggered TP = 3 times, FP = 2 times. (Medium credibility); Current oil level (below the threshold) ), normal range , , (Low oil level may cause winding insulation failure, which is a high-urgency situation).

[0195] Rule 2 (Fan current ≤ 4A): Current (Below the threshold)

[0196] (The urgency of the fan failure is moderate, but the rules are reliable.)

[0197] Calculate each rule W:

[0198] ;

[0199] ;

[0200] Sorting results: The operations and maintenance team split into two groups to handle the issue simultaneously. Reasonableness: Rule 4 has a high urgency level (…). Rule 2 has high credibility. The equality of W reflects the principle that "urgency and reliability are equally important," avoiding bias from a single dimension. If only credibility C is considered... Rule 2 will be prioritized, as delays in addressing oil level issues could lead to insulation breakdown (repair costs exceeding 100,000 yuan); if only R is considered... Rule 4 will be prioritized, as delaying fan repair may lead to increased temperature and compounded failures. W combines the two to achieve a balanced response.

[0201] Compared to the risks of not calculating W:

[0202] If W is not used, an alarm will be triggered in Rule 5 (gas concentration ≥ 0.5%). ")" and "Rule 2" When both rules are triggered simultaneously, rule 5 will be processed first if only R is considered. (Extremely high), but the rule has a historical misjudgment rate of 60%. This could be due to sensor misreading (such as oil mist interference with a gas sensor), prioritizing this could delay addressing fan malfunctions (high reliability), leading to insufficient cooling; considering only reliability C would prioritize rule 2, ignoring the significant risk of rule 5 if it's a genuine malfunction (gas leak could trigger an explosion), while... , Sort This avoids misjudgment and also... Remaining focused on Rule 5 (following up sensor verification) demonstrates the comprehensive decision-making value of W.

[0203] It also includes a multi-source data collaborative analysis step: for IoT device data from different physical locations, the statistical correlation ρ between their data sequences is calculated to determine whether there is a linkage effect in the device operating status; the calculation process of the correlation ρ is as follows:

[0204] ;

[0205] in, Let X be the covariance of the data sequences of device X and device Y. and , respectively, are the standard deviations of the two sequences;

[0206] when If the sensitivity exceeds the preset threshold, a cross-device collaboration rule will be triggered.

[0207] By calculating the statistical correlation ρ between data sequences of IoT devices at different physical locations in a smart power plant (such as main transformer temperature, cooling system inlet water pressure, and cooling pump current), the linkage effect of device operating status can be accurately identified. This solves the problem of missing the detection of multi-device collaborative faults (such as cooling pump failure leading to pressure drop, which in turn causes transformer temperature rise) or misjudging single device anomalies when analyzing data from a single device in isolation. It avoids the root cause location deviation caused by relying solely on local rules triggered by single device data, and enables system-level fault diagnosis and control through cross-device collaborative rules. This improves the comprehensiveness and accuracy of fault identification in smart power plant equipment, reduces the risk of equipment damage and repetitive maintenance due to undetected linkage faults, and ensures the overall operational stability of the power plant.

[0208] For example, in a smart power station scenario involving a 35kV main transformer, we focus on data from three related devices: the main transformer winding temperature sensor (device X, acquisition period 1 minute, unit °C), the cooling system inlet water pressure sensor (device Y, acquisition period 1 minute, unit MPa), and the cooling pump A current sensor (device Z, acquisition period 1 minute, unit A). These three devices are interconnected: abnormal cooling pump current leads to changes in inlet water pressure, which in turn affects the transformer's heat dissipation efficiency (temperature fluctuation). Multi-source data collaborative analysis is conducted, and the specific process is as follows:

[0209] Scene and parameter settings:

[0210] On September 5, 20xx, from 14:00 to 14:04 (5 data collection cycles, n=5 data points), the maintenance system detected a continuous rise in transformer temperature (not reaching the 98℃ alarm threshold of Rule 1, but showing an upward trend), slightly lower than normal water pressure (not reaching the 0.3MPa alarm threshold of Rule 3), and no significant abnormality in cooling pump A current (within the normal range of 4.5-5.5A). Collaborative analysis is needed to determine if there is a hidden linkage fault; a preset correlation sensitivity threshold is required. (Calibrated by the power plant operation and maintenance team based on historical linkage fault data) A value exceeding 0.8 indicates a strong linkage effect.

[0211] Data Acquisition and Preprocessing:

[0212] Raw X, Y, and Z data of the device were collected over 5 cycles (preprocessed to remove noise), as follows:

[0213] Device X (Temperature) Data Sequence: ;

[0214] Equipment Y (inlet water pressure) data sequence: ;

[0215] Equipment Z (cooling pump A current) data sequence: ;

[0216] Correlation ρ calculation:

[0217] First, clarify the formula required for the calculation:

[0218] Covariance: ,in These are the means of sequences X and Y, respectively;

[0219] Standard deviation: , Similarly;

[0220] Correlation: .

[0221] (1) Calculate X and Y :

[0222] Step 1: Calculate the mean: ;

[0223] .

[0224] Step 2: Calculate covariance :

[0225] =(88-90.84)(0.32-0.3)+(89.5-90.84)(0.31-0.3)+(91-90.84)(0.30-0.3)+(92.2-90.84)(0.29-0.3)+(93.5-90.84)(0.28-0.3)=(-2.84)(0.02)+(-1.34)(0.01)+(0.16)(0)+(1.36)(-0.01)+(2.66)(-0.02)=-0.0568-0.0134+0-0.0136-0.0532=-0.137;

[0226] .

[0227] Step 3: Calculate the standard deviation :

[0228] ;

[0229] ;

[0230] ;

[0231] .

[0232] Step 4: Calculation :

[0233] ,

[0234] It was determined that there is a strong negative correlation between X and Y (pressure decreases when temperature rises).

[0235] Calculate X and Z :

[0236] Mean:

[0237] ;

[0238] Covariance:

[0239] ;

[0240] Standard deviation:

[0241] ;

[0242] , It was determined that there is a strong negative correlation between X and Z (the pump current decreases when the temperature rises).

[0243] Collaboration rule triggering and processing:

[0244] because , The absolute values ​​all exceed the sensitivity threshold, triggering the cross-device coordination rule: "When the transformer temperature and the cooling pump current and inlet water pressure are strongly negatively correlated, it is determined that the cooling pump output has decreased, resulting in insufficient cooling. The standby unit of cooling pump B is immediately started, and the impeller of cooling pump A is checked for blockage."

[0245] The maintenance team followed the rules: at 14:05, the backup pump B was started, and the inlet water pressure rose back to 0.35MPa; at 14:10, the transformer temperature dropped to 89℃; at 14:30, it was found that the impeller of cooling pump A was blocked by impurities. After cleaning, it returned to normal and the linkage fault was resolved in one go, without causing the temperature to reach the alarm threshold (98℃).

[0246] Risks of not performing collaborative analysis:

[0247] If the analysis is not conducted according to the technical solution in this case, and only the data of a single device is viewed in isolation: Device X (temperature 93.5℃) does not reach the 98℃ alarm threshold of Rule 1, Device Y (pressure 0.28MPa) does not reach the 0.3MPa alarm threshold of Rule 3, and Device Z (current 4.6A) is within the normal range, the maintenance team will overlook the hidden linkage fault and fail to address the problem of cooling pump A in a timely manner; at 14:10, the temperature will rise to 98℃, triggering the alarm of Rule 1. At this time, only starting the cooling fan (local rule) cannot solve the root cause of the pressure drop. At 14:20, the temperature will rise to 102℃, triggering an emergency shutdown, resulting in a 2-hour power outage at the power station (loss of approximately 15,000 kWh of power generation). The total cost of repairing cooling pump A and restoring power exceeds 20,000 yuan. However, the collaborative analysis in this case, by identifying the linkage effect, avoids this risk in advance.

[0248] It also includes a feedback learning step: dynamically updating the historical trigger record of the rule based on the trigger effect feedback of the executed rule; specifically, if the executed action effectively solves the problem, the true positive trigger count (TP) is increased, otherwise the false positive trigger count is increased, thereby realizing the online self-learning and continuous optimization of the rule engine;

[0249] By dynamically updating the historical trigger records of rules based on the triggering effect feedback of executed rules (increasing the true positive trigger count (TP) if the problem is effectively resolved, and increasing the false positive trigger count otherwise), the rule engine achieves online self-learning and continuous optimization. This avoids the rule's historical credibility (C) from deviating from actual performance due to long-term fixed TP / FP data (e.g., aging of smart power plant equipment or changes in operating conditions leading to an increase in rule misjudgment rate that cannot be adjusted). The historical credibility (C) of the rule can iterate in real time with the actual operating status of the equipment, thereby ensuring the accuracy of subsequent comprehensive weight (W) calculations. This reduces false alarms (ineffective operation and maintenance) or missed alarms (fault risk) caused by rule performance degradation, lowers the long-term operation and maintenance costs of smart power plants, and improves the rule engine's adaptability to changes in equipment status and the continuous accuracy of fault identification.

[0250] For example, in the scenario of a 35kV main transformer in a smart power station, focusing on core rule 1 ("winding temperature ≥ 98℃ triggers a fault alarm") and rule 2 ("fan current ≤ 4A triggers a fault alarm"), dynamic updates and rule optimizations of the TP / FP are carried out according to the feedback learning mechanism of this case. The specific process is as follows:

[0251] Initial state settings (September 1, 2024):

[0252] Based on data from the previous month (August 1st - August 31st), the initial historical trigger records and historical performance credibility C of the two rules are as follows:

[0253] Rule 1: Initial ,according to , to obtain the initial ;

[0254] Rule 2: Initial ,initial ;

[0255] The system is set to a feedback cycle of "completing effect confirmation and updating records within 24 hours after each rule is executed". The confirmation is based on the equipment operation data after maintenance (such as whether the temperature has dropped and whether the current has recovered) and the results of on-site review.

[0256] Feedback Event 1 (Rule 1 triggers effect feedback, TP is updated):

[0257] Triggering and Execution: At 10:15 on September 2, Rule 1 was triggered due to a temperature of x=99.3℃. The operations and maintenance team executed the "check the cooling system + start the backup fan" operation according to the rule.

[0258] Effect confirmed (September 3, 09:30): The temperature stabilized at 85-87℃ within 24 hours (returned to normal). On-site inspection revealed that the bearing of the No. 2 fan in the cooling system was worn (actual fault). It was confirmed that the rule triggering effectively solved the problem.

[0259] Record update: TP count for Rule 1 from Updated to FP count held constant;

[0260] Credibility C Update: New Compared to the initial This enhances the historical credibility of Rule 1.

[0261] Feedback Event 2 (Rule 1 triggers effect feedback, FP is updated):

[0262] Triggering and Execution: At 16:40 on September 5th, Rule 1 was triggered due to a temperature of x=98.2℃, and the operations and maintenance team performed the "check the cooling system + clean the temperature sensor" operation;

[0263] Effect Confirmation (September 6, 15:00): Temperature data fluctuated greatly within 24 hours (82-97℃). Further investigation revealed that the temperature sensor probe was contaminated with insulating oil (not a device malfunction, but a rule erroneous trigger). After cleaning, the temperature data stabilized at 83℃, confirming that the rule trigger did not solve the actual problem (because there was no real fault).

[0264] Record update: FP count for rule 1 from Updated to TP count held constant;

[0265] Credibility C Update: New Returning to the initial level, it indicates that Rule 1 still has a certain misjudgment rate and needs further optimization (such as adjusting the sensor cleaning cycle).

[0266] Feedback Event 3 (Rule 2 trigger effect feedback, TP updated):

[0267] Triggering and Execution: At 08:20 on September 8, Rule 2 was triggered due to the current of fan 3 x=3.9A, and the maintenance team performed the operation of "checking the fan motor + cleaning the dust on the blades";

[0268] Effect confirmed (September 9, 07:00): Fan 3 current stabilized at 4.8-5.0A within 24 hours (returned to normal), on-site confirmation that dust accumulation on the blades caused increased load (real fault), rule triggering was effective;

[0269] Record update: TP count for rule 2 from Updated to FP count held constant;

[0270] Credibility C Update: New Compared to the initial The historical credibility of Rule 2 has been further enhanced.

[0271] Feedback on the optimization effect of learning:

[0272] Assuming both rules are triggered simultaneously at 11:00 AM on September 10th:

[0273] Rule 1: x = 98.5℃; , ;

[0274] ;

[0275] Rule 2: x = 3.8A, , ;

[0276] ;

[0277] Sorting results Operations and maintenance priority handling rule 2: If no feedback update is made (the initial version will still be used). ), ,and The small difference may lead to ambiguity in priority judgment; however, after the feedback update... This makes priorities clearer and avoids hesitation in decision-making.

[0278] The risks of learning without feedback:

[0279] If TP / FP is not updated in accordance with the method described in this case, Rule 1... This rule will remain unchanged for a long time. Even if the number of false triggers increases due to sensor aging (such as 2 new FPs in September), the historical performance reliability C will still be 0.5. The operations and maintenance team will continue to trust this rule, which may result in 3 invalid operations and maintenance (each costing 800 yuan, totaling 2400 yuan).

[0280] Rule 2 It also fails to demonstrate an improvement in credibility. Subsequent triggers may be delayed due to insufficient priority, delaying fan failure repair (such as causing insufficient cooling, temperature rise, triggering rule 1 alarm), and increasing the risk of overlapping failures. Feedback learning, on the other hand, dynamically updates TP / FP to ensure that rule performance always matches actual operating conditions, thus avoiding such problems.

[0281] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0282] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0283] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. An IoT data rule engine algorithm, characterized in that, Includes the following steps: Data reception and preprocessing steps: Real-time reception of data streams from multiple IoT devices, i.e. IoT device data, including main transformer temperature, cooling system inlet water pressure and cooling pump current, and preprocessing of the data streams to obtain standardized data; Rule matching steps: Standardized data is input into the rule engine. The rule engine has multiple rules pre-stored, each of which includes triggering conditions and execution actions; Weight calculation steps: Calculate a comprehensive weight value for each rule. The calculation of the comprehensive weight value depends on the historical performance reliability obtained based on the rule's historical trigger records and the immediate relevance obtained based on the comparison of the current data with the trigger condition threshold. Rule sorting and execution steps: All rules are sorted in descending order according to the comprehensive weight value to generate a rule execution sequence. Rules that meet the conditions are checked and triggered sequentially according to this sequence, and the corresponding device control or alarm commands are executed. When calculating the reliability of historical performance, the historical trigger records of the rules need to be called. The historical trigger records contain the number of true positive triggers and the number of false positive triggers. A true positive means that after the rule is triggered, it is confirmed that a corresponding device abnormality or malfunction has indeed occurred; a false positive means that after the rule is triggered, it is confirmed that it is a false alarm. The true positive trigger count and the false positive trigger count are used to quantify the reliability by calculating the proportion of the true positive trigger count to the total number of effective triggers. The calculation process of the instant relevance is as follows: for numerical triggering conditions, the normalized result of the absolute difference between the current data value and the triggering condition threshold is calculated and mapped to a similarity score; the calculation process of the comprehensive weight value is as follows: the historical performance credibility and instant relevance are linearly fused through a preset weight coefficient.

2. The IoT data rule engine algorithm according to claim 1, characterized in that: The data stream preprocessing includes data cleaning and smoothing steps: using a sliding window model to obtain recent data sequences, calculating the moving average and moving standard deviation of the data within the window; quantifying the anomaly index by calculating the multiple of the deviation of each data point from the moving average relative to the moving standard deviation; and identifying data points with anomaly indices exceeding a dynamic threshold as noise and filtering or smoothing them out.

3. The IoT data rule engine algorithm according to claim 2, characterized in that, The dynamic threshold is adaptively adjusted based on the historical fluctuations of the data stream. The adjustment method is as follows: a historical anomaly index sequence calculated from historical data points is recorded and maintained according to a time window, the moving average of the sequence is calculated, and it is linearly superimposed with the base threshold.

4. The IoT data rule engine algorithm according to claim 1, characterized in that: It also includes a multi-source data collaborative analysis step: For IoT device data from different physical locations, i.e. IoT device data, including main transformer temperature, cooling system inlet water pressure and cooling pump current, the statistical correlation between IoT device data sequences is calculated to determine whether there is a linkage effect in the device operation status; when the absolute value of the correlation is greater than the preset sensitivity, cross-device collaboration rules are triggered.

5. The IoT data rule engine algorithm according to claim 4, characterized in that: It also includes a feedback learning step: dynamically updating the historical trigger record of a rule based on the trigger effect feedback of the executed rule; specifically, if the executed action effectively solves the problem, the count of true positive triggers is increased, otherwise the count of false positive triggers is increased, thereby realizing the online self-learning and continuous optimization of the rule engine.

Images