CN117371978A - Water supply project equipment fault tracing method based on Internet of things platform - Google Patents

Abstract

The invention discloses a water supply project equipment fault tracing method based on an internet of things platform, which comprises the following steps of: the method comprises the steps that an Internet of things platform establishes a water supply project equipment data analysis system, and states of all equipment and reported data are analyzed in real time; generating an alarm aiming at equipment which is offline and has heartbeat data and no sensor data, and carrying out alarm filtering at the same time; establishing a root cause fault tracing rule base, analyzing an alarm event and positioning an alarm component; establishing a fault tracing knowledge base for storing all fault reasons currently known by each component of the front-end sensing equipment; and analyzing historical monitoring data before the failure of the alarm component based on a Mann-Kendall algorithm, and combining a failure tracing knowledge base to locate the failure cause. According to the equipment monitoring data based on the Internet of things platform, equipment fault reasons are automatically traced according to the equipment fault phenomena and the monitoring data, manual timely checking is guided, and the equipment operation and maintenance efficiency can be remarkably improved.

Description

A method for tracing the source of equipment faults in water supply projects based on the Internet of Things platform

Technical field

The present invention relates to the field of fault tracing of water supply monitoring equipment, and in particular, to a method of fault tracing of water supply project equipment based on the Internet of Things platform.

Background technique

The basic driving force of the Internet of Things platform is the monitoring data of various front-end sensing devices. Based on these monitoring data, business work such as water supply engineering and water supply pipe network operation monitoring, pipe burst diagnosis, and water loss analysis can be carried out.

The IoT platform of the water supply project is connected to a large number of front-end sensing devices such as flow, pressure, water quality, and water level. Due to aging of the equipment, dead battery, hardware failure, RTU software failure, and even bad weather, etc., problems may occur in the reporting of equipment monitoring data, as mentioned above. Problems are often not discovered in time. Once discovered, the existing fault traceability method also requires experienced operation and maintenance personnel to conduct on-site inspections to identify the cause of the fault. It relies too much on manual experience and has a lag in processing, and then monitors the operation of the water supply project and pipe explosions. Businesses such as diagnosis and water damage analysis are affected.

Therefore, it is necessary to develop a method for tracing the source of equipment faults in water supply projects based on the Internet of Things platform.

Contents of the invention

The purpose of the present invention is to invent a device fault traceability method based on the Internet of Things platform in view of the problems existing in the existing equipment fault identification and traceability troubleshooting processes. The Internet of Things platform is used to analyze equipment data to identify faulty equipment in a timely manner, combined with the established root cause faults. The traceability rule base, fault traceability knowledge base, and Mann-Kendall algorithm locate faulty components and trace possible causes of faults to guide manual rapid investigation and processing.

In order to solve the above technical problems, the present invention provides a water supply project equipment fault tracing method based on the Internet of Things platform, which includes the following steps:

S1: The Internet of Things platform accesses the water supply project equipment data and establishes a data analysis system to analyze the online and offline status of each equipment and the reported monitoring data in real time;

S2: Generate alarms for devices that are offline, have heartbeat data but no sensor data, and have abnormal sensor data, and perform alarm filtering;

S3: Establish a root fault tracing rule base, analyze alarm events, and locate the root fault components through multiple subordinate alarm events;

S4: Establish a fault traceability knowledge base to store all currently known fault causes of each component of the front-end sensing equipment;

S5: Based on the Mann-Kendall algorithm, the historical monitoring data before the alarm component failure is analyzed, and the algorithm analysis is combined with the fault traceability knowledge base to locate the specific cause of the fault.

In the above technical solution, in step S1, the Internet of Things platform of the water supply project is connected to a large number of front-end sensing devices for flow, pressure, water quality and water level. In addition to completing the device data access, it is also necessary to establish a device data analysis system. Perform real-time analysis on the offline and online status of the device and whether the data reported by the device is normal.

In the above technical solution, the step S1 includes:

(1) Equipment online and offline status analysis

The reporting frequency of monitoring equipment in water supply projects generally reports multiple times a day. Considering that some monitoring equipment is deployed in relatively remote locations and may have unstable signals, the equipment that reports every t hours (0<t<12) is set to 3t hours. If a report can be completed within 3 hours, it is considered online; if it is not reported for 3 consecutive hours, it is considered offline;

(2) Analysis of data reported by equipment

Common equipment reporting data problems in water supply projects mainly include: no data reporting when offline, heartbeat data reporting but no equipment sensor data, and sensor data anomalies; sensor data anomalies refer to monitoring data that exceeds the normal range related to water supply.

In the above technical solution, in the step S2, the Internet of Things platform analyzes the online and offline status of the device and the data reported by the device in real time. For the device offline, the device only has heartbeat data but no sensor monitoring data, and the device sensor data has code hopping or errors. For abnormal data, corresponding alarm information is generated in a timely manner to facilitate fault location and traceability; for periodically reported equipment monitoring data, the same fault of the same type of equipment will periodically generate multiple repeated alarm information for filtering; When the reported data is judged by the system and is recognized as the same event occurring continuously, only the alarm of the initial event will be retained until the event is restored; only the same event that occurs again after the recovery will be judged as a new event and a new alarm will be generated.

In the above technical solution, in step S3, a large number of chain alarm events caused by a certain root fault are called event tides. In an event tide, events are hierarchical and distributed in a tree-like causal sequence, mainly composed of It consists of three parts: the root event, the subordinate events caused by the root event, and a driving path from the root event to a subordinate event. This path can trace the cause of the event forward or backward;

Sort out the relationship between all alarm information and equipment components of the project, establish a root fault tracing rule base, and locate the root fault components through multiple subordinate alarm events.

In the above technical solution, in the step S3, in the water supply project, if the flow meter and pressure meter monitoring data of the same monitoring point are transmitted to the Internet of Things platform through the RTU,

When an alarm indicates that the flow and pressure monitoring data of the monitoring point are abnormal at the same time, the root cause may be an RTU failure;

When an alarm indicates that the flow monitoring data is abnormal but the pressure is normal, the root cause may be a flow meter failure;

When an alarm indicates that the pressure monitoring data is abnormal but the flow rate is normal, the root cause may be a pressure gauge failure.

In the above technical solution, in step S4, a fault traceability knowledge base is established to store all currently known fault events, fault causes, pre-fault monitoring data conditions, and correlations between faulty components of each component of the front-end sensing equipment. , the fault events include: antenna damage, communication module damage, battery aging, battery failure to charge, RTU software failure, monitoring data failure caused by sensor failure, no data reporting, heartbeat data but no sensor data, abnormal monitoring data Jitter, code hopping, erroneous data, voltage and signal before failure are normal.

In the above technical solution, in step S5,

After analyzing the causes in the fault traceability knowledge base, it was found that battery problems are often the main cause of faults caused by the equipment itself. Therefore, consider analyzing the battery status before the fault to confirm whether it is a battery problem;

Based on the Mann-Kendall algorithm, the historical monitoring data before the alarm component failure is analyzed. Regarding the voltage data, the voltage of the normal battery is relatively stable, accompanied by small random fluctuations. When the alarm component fails due to battery problems, the battery voltage before the failure will appear as a whole. For downward trend, the Mann-Kendall algorithm is used to analyze the overall voltage trend:

Define the voltage test statistic S: ;

where sign is a symbolic function, when When less than, equal to, or greater than 0, sign (X _i -X _j ) takes -1, 0, or 1;

;

Obtain the device voltage data before the fault and perform calculations to analyze whether there was a problem with the device battery before the fault. When the Z calculation result is less than 0, it is considered that the voltage is in an overall downward trend. It is considered that there is a problem with the device's battery, causing the fault.

The water supply project equipment fault tracing method based on the Internet of Things platform of the present invention has the following advantages: (1) The present invention can detect fault types in time, overcoming the existing technology's reliance on manual experience and lag in processing; (2) By detecting alarm events Filtering can reduce many unnecessary alarms and improve the usability of alarms; (3) Give priority to battery fault diagnosis, narrow the scope of traceability, and effectively improve the accuracy of traceability.

Description of the drawings

Figure 1 is a flow chart of the water supply project equipment fault tracing method based on the Internet of Things platform of the present invention.

Detailed ways

The implementation of the present invention will be described in detail below with reference to the accompanying drawings, but they do not constitute a limitation of the present invention and are only used as examples. At the same time, the advantages of the invention will become clearer and easier to understand by explaining it.

Referring to Figure 1, it can be seen that the present invention provides a water supply project equipment fault traceability method based on the Internet of Things platform, which includes the following steps:

S1: The IoT platform establishes a device data analysis system to analyze the status of each device and the reported data in real time;

The Internet of Things platform of the water supply project is connected to a large number of front-end sensing devices such as flow, pressure, water quality, and water level. In addition to completing the device data access, it is also necessary to establish a device data analysis system to determine the offline and online status of the device and whether the data reported by the device is normal. Perform real-time analysis.

(1) Equipment online and offline status analysis

The reporting frequency of monitoring equipment in water supply projects generally reports multiple times a day. Considering that some monitoring equipment is deployed in relatively remote locations and may have unstable signals, the equipment that reports every t hours (0<t<12) is set to 3t hours. If a report can be completed within 3 hours, it is considered online; if it is not reported for 3 consecutive hours, it is considered offline;

(2) Analysis of data reported by equipment

Common equipment reporting data problems in water supply projects mainly include: no data reporting when offline, heartbeat data reporting but no equipment sensor data, and sensor data anomalies. Sensor data anomalies refer to monitoring data that exceeds the normal range related to water supply, such as pipe network flow pressure. The upper limit of pipeline specifications is exceeded, the water level of the pool exceeds the depth of the pool, etc., and there are obvious erroneous data such as negative numbers for water level, pressure, and water quality.

S2: Generate alarms for devices that are offline, have heartbeat data but no sensor data, and have abnormal sensor data, and perform alarm filtering at the same time;

The IoT platform analyzes the online and offline status of the device and the data reported by the device in real time. For abnormal situations such as the device being offline, the device only having heartbeat data but no sensor monitoring data, and device sensor data showing code skips, error data, etc., corresponding alarm information needs to be generated in a timely manner. Facilitates fault location and traceability; for periodically reported equipment monitoring data, the same fault of the same type of equipment will periodically generate multiple repeated alarm messages, which need to be filtered; when the reported data is judged by the system, it is identified as the same When events occur continuously, only the alarm of the initial event is retained until the event recovers; only the same event that occurs again after recovery will be judged as a new event and a new alarm will be generated.

By filtering alarm events, many unnecessary alarms can be reduced and the availability of alarms can be improved.

S3: Establish a root fault tracing rule base, analyze alarm events, and locate alarm components;

A large number of chain alarm events caused by a certain root failure is called an event wave. In an event wave, events are hierarchical and distributed in a tree-like causal sequence. It mainly consists of three parts: the root event and the subordinate events caused by the root event. And a driving path from the root event to a subordinate event, from which the cause of the event can be traced forward or backward.

Sort out the relationship between all the alarm information and equipment components of the project, establish a root fault tracing rule base, and locate the root fault components through multiple subordinate alarm events; for example, in a water supply project, the flow meter and pressure meter monitoring data of the same monitoring point pass through the RTU Transmitted to the IoT platform, when the alarm prompts that the flow and pressure monitoring data of the monitoring point are abnormal at the same time, the root cause may be an RTU failure; when the alarm prompts that the flow monitoring data is abnormal but the pressure is normal, the root cause may be a flow meter failure. .

S4: Establish a fault traceability knowledge base to store all currently known fault causes of each component of the front-end sensing equipment;

Establish a fault traceability knowledge base to store all currently known fault events, fault causes, pre-fault monitoring data, and relationships between faulty components, such as antenna damage, communication module damage, battery aging, etc. Monitoring data failure caused by battery failure, RTU software failure, sensor failure, etc., no data reported, heartbeat data but no sensor data, abnormal jitter of monitoring data, code hopping, erroneous data, voltage before failure, whether the signal is normal, etc.

S5: Based on the Mann-Kendall algorithm, analyze the historical monitoring data before the alarm component fails, and locate the cause of the failure based on the fault traceability knowledge base;

Different external reasons or equipment's own reasons are likely to cause the same fault phenomenon. If we only rely on collecting the currently known fault causes of each component for fault traceability matching, it is easy to form a situation where the fault phenomenon matches many traceability results, which cannot effectively improve the fault traceability. Accuracy of fault traceability. After analyzing the causes in the fault traceability knowledge base, it was found that battery problems are often the main cause of faults caused by the equipment itself. Therefore, consider analyzing the battery status before the fault to confirm whether it is a battery problem, which can effectively narrow down fault traceability. scope to improve traceability accuracy.

The voltage of a normal battery will be in a relatively stable state, accompanied by small random fluctuations. The problem battery will show a downward trend in voltage. The decrease process will also be accompanied by random fluctuations in voltage, which will continue to decrease until it cannot meet the power supply needs of the device, resulting in abnormal data or even no data. Report.

Based on the Mann-Kendall algorithm, the historical monitoring data before the alarm component failure is analyzed, mainly focusing on the voltage data. The voltage of the normal battery is relatively stable, accompanied by small random fluctuations. When the alarm component fails due to battery problems, the battery voltage before the failure will be overall Showing a downward trend, the Mann-Kendall algorithm is used to conduct trend analysis on the voltage data for a period of time before the fault:

Define the voltage test statistic S: ;

where sign is the sign function, n is the length of the voltage sequence before the fault, X _i and X _j are the voltage monitoring values corresponding to the i and j time series respectively, when When less than, equal to, or greater than 0, sign (X _i -X _j ) takes -1, 0, 1; voltage trend value ;

Obtain the equipment voltage data before the failure for calculation, and analyze whether the equipment battery has problems before the failure. When the voltage trend value Z calculation result is less than 0, it is considered that the voltage is in an overall downward trend, and it is considered that there is a problem with the equipment battery, causing the failure.

Therefore, after locating the faulty component through step S3, combined with the knowledge base established in step S4, the historical voltage data before the component failure is analyzed, especially to determine whether it is caused by the battery failure of the device itself, to further narrow the scope of traceability, locate the specific cause of the failure, and effectively improve Traceability accuracy.

Case:

The IoT platform prompts that a monitoring site is offline and no data is reported. This alarm has been filtered and the device continues to be offline without repeated alarms. Since no new data has been reported and the alarm has not been cleared, the equipment fault needs to be traced to its source. Based on the root fault tracing rule base established by the project, the alarm event is analyzed, and based on the fact that neither the sensor nor the heartbeat data is reported, the faulty component may be the RTU.

Based on the fault traceability knowledge base established by the project, the historical data such as flow, pressure, and voltage before the fault were analyzed. It was found that the flow and pressure data before the fault were within the normal range, while the voltage data had shown an overall downward trend for some time before the fault. Therefore, according to The fault traceability knowledge base determined that the cause of the fault was that the equipment was offline due to battery failure and the data could not be reported. Subsequently, the operation and maintenance personnel conducted manual troubleshooting to confirm the battery problem. After replacing the battery, the data was restored. The fault traceability technology has been applied and verified in the project.

Others not described in detail belong to the prior art.

Claims (7)

1. The water supply project equipment fault tracing method based on the Internet of things platform is characterized by comprising the following steps of:

s1: the method comprises the steps that an Internet of things platform is accessed to water supply project equipment data, a data analysis system is established, and online and offline states of all the equipment and reported monitoring data are analyzed in real time;

s2: generating an alarm aiming at equipment which is offline, has heartbeat data, has no sensor data and has abnormal sensor data, and filtering the alarm;

s3: establishing a root-cause fault tracing rule base, analyzing alarm events, and positioning a root-cause fault component through a plurality of subordinate alarm events;

s4: establishing a fault tracing knowledge base for storing all fault reasons currently known by each component of the front-end sensing equipment;

s5: analyzing historical monitoring data before the failure of the alarm component based on a Mann-Kendall algorithm, and positioning specific failure reasons by combining algorithm analysis with a failure tracing knowledge base;

in the step S5 of the process described above,

the reasons in the fault tracing knowledge base are analyzed, so that the battery problem is often the main reason in the fault caused by the self reason of the equipment, and therefore, the analysis of the battery state before the fault is considered to determine whether the battery problem is the battery problem;

based on the Mann-Kendall algorithm, historical monitoring data before the failure of the alarm component is analyzed, and aiming at voltage data, the voltage of a normal battery is stable and accompanied by small random fluctuation, when the alarm component is failed due to battery problems, the voltage of the battery before the failure can wholly show a descending trend, and the Mann-Kendall algorithm is adopted to carry out trend analysis on the voltage data before the failure for a period of time:

defining a voltage test statistic S:；

where sign is a function of the sign,nfor the length of the pre-fault voltage sequence,X _i 、X _j respectively corresponding voltage monitoring values of the ith and the j time sequences whenWhen the ratio is less than, equal to or greater than 0,sign（X _i -X _j ）taking-1, 0 and 1; voltage trend value；

And acquiring voltage data of the equipment before the fault for calculation, analyzing whether a battery of the equipment before the fault has a problem, and when a Z calculation result is smaller than 0, considering that the voltage is in a general descending trend, considering that the battery of the equipment has the problem, and causing the fault.

2. The method for tracing the faults of the water supply project equipment based on the internet of things platform according to claim 1 is characterized in that in the step S1, the internet of things platform of the water supply project is connected with a large number of front-end sensing equipment of flow, pressure, water quality and water level, and besides completing equipment data connection, an equipment data analysis system is also required to be established, and real-time analysis is carried out on the offline and online states of the equipment and whether the reported data of the equipment are normal or not.

3. The method for tracing the faults of the water supply project equipment based on the platform of the internet of things according to claim 1 or 2, wherein the step S1 comprises the following steps:

(1) On-line and off-line status analysis of devices

Reporting frequency of monitoring equipment of a water supply project is generally reported for a plurality of times every day, and considering that some monitoring equipment is deployed at a remote position and the possibility of unstable signals exists, the equipment reported every t hours (0 < t < 12) can complete one reporting within 3t hours, and is considered to be online; if the continuous time is 3t hours, the report is not sent, and the report is taken off-line;

(2) Device report data analysis

The problem of reporting data by common equipment in water supply projects mainly comprises the following steps: when offline, no data is reported, no equipment sensor data is reported, and the sensor data is abnormal; wherein sensor data anomalies refer to monitoring data that exceeds a normal range associated with water supply.

4. The method for tracing the faults of the water supply project equipment based on the Internet of things platform according to claim 1 is characterized in that in the step S2, the Internet of things platform analyzes the online and offline state of the equipment and the data reported by the equipment in real time, and corresponding alarm information is generated in time according to the abnormal conditions that the equipment is offline, the equipment has only heartbeat data and no sensor monitoring data, the equipment sensor data has jump codes and error data, so that the faults are positioned and traced; for the periodically reported equipment monitoring data, the same fault of the same equipment can periodically generate a plurality of repeated alarm information for filtering; when the reported data is judged by the system and is identified as the continuous occurrence of the same event, only the alarm of the initial event is reserved until the event is recovered; the same event that occurs again after recovery is determined to be a new event, and a new alarm is generated.

5. The method for tracing faults of water supply project equipment based on the platform of the internet of things according to claim 1, wherein in the step S3, a large number of chained alarm events caused by a certain root fault are called event tides, and in one event tides, the events are layered and distributed in a tree-shaped causal sequence and mainly consist of three parts: the system comprises a root event, a subordinate event caused by the root event and a driving path from the root event to a subordinate event, wherein the path can trace back the occurrence reason of the event forward or backward;

and combing all alarm information and equipment component association relations of the project, establishing a root fault tracing rule base, and positioning the root fault component through a plurality of subordinate alarm events.

6. The method for tracing the faults of the water supply project equipment based on the platform of the Internet of things according to claim 5, wherein in the step S3, if the flow meter and the pressure meter monitoring data of the same monitoring point are transmitted to the platform of the Internet of things through the RTU,

when the alarm prompts that the flow and pressure monitoring data of the monitoring point are abnormal at the same time, the root event may be an RTU fault;

when the alarm prompts that the flow monitoring data is abnormal and the pressure is normal, the root event may be a flowmeter fault;

when the alarm prompts that the pressure monitoring data is abnormal and the flow is normal, the root event may be a pressure gauge fault.

7. The method for tracing the faults of the water supply project equipment based on the platform of the internet of things according to claim 1, wherein in the step S4, a fault tracing knowledge base is established for storing all fault events, fault reasons, monitoring data conditions before faults and association relations among fault components currently known by each component of the front-end sensing equipment, and the fault events comprise: antenna damage, communication module damage, battery aging, battery unable charging, RTU software fault, the fault of monitoring data that the reason of sensor trouble led to, no data report, have heartbeat data and sensor data, monitoring data unusual shake, jump code, error data, voltage and signal are normal before the trouble.