Abstract

Many applications based on Internet of Things (IoT) technology have recently founded in industry monitoring area. Thousands of sensors with different types work together in an industry monitoring system. Sensors at different locations can generate streaming data, which can be analyzed in the data center. In this paper, we propose a framework for online sensor fault detection. We motivate our technique in the context of the problem of the data value fault detection and event detection. We use the Statistics Sliding Windows (SSW) to contain the recent sensor data and regress each window by Gaussian distribution. The regression result can be used to detect the data value fault. Devices on a production line may work in different workloads and the associate sensors will have different status. We divide the sensors into several status groups according to different part of production flow chat. In this way, the status of a sensor is associated with others in the same group. We fit the values in the Status Transform Window (STW) to get the slope and generate a group trend vector. By comparing the current trend vector with history ones, we can detect a rational or irrational event. In order to determine parameters for each status group we build a self-learning worker thread in our framework which can edit the corresponding parameter according to the user feedback. Group-based fault detection (GbFD) algorithm is proposed in this paper. We test the framework with a simulation dataset extracted from real data of an oil field. Test result shows that GbFD detects 95% sensor fault successfully.

1. Introduction

Internet of Things (IoT) has been paid more and more attention by the government, academe, and industry all over the world because of its great prospect [1–3]. In the IoT application field, intelligent industry is an important branch. A wired or wireless sensor network is the basic facility of the industry monitoring IoT. These networks comprising of thousands of inexpensive sensors can report their values to the data center. The aim of the monitoring system is to guarantee the process of production.

Fault detection is an important process for industry monitoring IoT, but it is a difficult and complex task because there are many factors that influence data and could cause faults. And faults are application and sensor type dependent [4–6]. Sensors in an industry monitoring IoT have three features:   Big: thousands of sensors on different devices are working together,   Multitypes: many physical quantities are needed to determine the production status,   Uncertainty: different workload is needed according to the production plan and some devices need shut down for examination. So the values of correlative sensors will change between different levels.

From the data-centric view, we focus on the Outliers, Stuck-at faults and Spikes [7]. From the application and system view, we focus on the rational and irrational trend detections. A rational trend means the sensor value transforms from one level to another smoothly and it is caused by a rational reason, such as shut down a device. An irrational trend means value changed when something is wrong with a device. The typical two mistakes of the monitoring system are taking a rational trend for an Outlier, or ignoring an irrational trend while values are still in range.

In this paper, we propose a self-learning sensor fault detection framework for industry monitoring IoT. The data model design is described in Section 3. In Section 4, the framework and the core algorithm are discussed. A simulation experiment base on real data is shown in Section 5.

Many researchers pay their attention to building a smart monitoring system. Bressan et al. [8] created a solid routing infrastructure through RPL. Castellani et al. [9] concentrate on the actual implementation of the communication technology and presented a lightweight implementation of an EXI library. Yuan et al. [10] present a parallel distributed structural health monitoring technology based on the wireless sensor network. An IoT communication framework for distributed worldwide health care applications is maintained in [11]. All these works are focused on the basic frameworks, protocols, and communication technologies of monitoring systems but discussed less on sensors management.

For modeling sensor network data, Guestrin et al. [12] propose a framework, for the nodes in the network to collaborate in order to fit a global function to each of their local measurements. This is a parametric approximation technique and has more parameters then our approach. References [13, 14] study the problem of computing order statistics in a sensor network. There has also been work on predicting and caching the values generated by the sensors [15, 16], which can result in significant communication savings. But all these approaches are not fit our setting.

A similar approach for sensor fault detection in streaming data is described by Yamanishi et al. [17]. In contrast to our work, their method does not operate on sliding windows but rather on the entire history of the data values. Chan et al. [18] extend the study of algorithms for monitoring distributed data streams from whole data streams to a time-based sliding window, but their focus is on presenting a communication-efficient algorithm.

Ding et al. [19] combined trajectories of all nodes and the paramealgorithm which requires low computational overhead. The proposed algorithm compared its sensor reading with the median value of its neighbors’ readings. Gao et al. [20] approach WSN fault detection problems using spatial correlation with the assumption of similar reading within cross range of neighbor nodes. Krishnamachari and Iyengar [21] tried to solve the faulty node detection problem by using localized event region and they assume that the system knows the location of sensor. In an industry monitoring sensor network, finding out a neighbor automatically is very hard. In our approach, we separate sensors into groups according to the production flow charts.

3. Data Model Design

This section focuses on the sensor data model design. We model sensors from the view of value for Outliers, Stuck-at faults, and Spikes detection and from the application view for event detection. The events we are interested in are rational trend and irrational trend.

3.1. Sensor Value

For detection the Outliers, Stuck-at faults, and Spikes, we propose a statistics method. Figure 1 shows the mechanism of Statistics Sliding Windows (SSW). For sensor , the current value and the previous values form the current windows . In the recent history, we can define windows with the same length and get the set . We estimate the values in each sliding window by Gaussian distribution, (Formula (1)). If , a Stuck-at fault is detected. And when is big enough, a Spikes fault may happened:


Figure 1 
Estimation of the data distribution in the Statistics Sliding Windows (SSW) for one time instance.

There is a buffer named in front of the current window . With the new samples coming into , the obsolete samples deserted by will become a member of . When the size of reach , the oldest window in will be discarded and the current will join as . With SSW, large numbers of historical sensor values are regressed to pairs of Gaussian characteristics. In a real application, we need not hold all the recent values in the memory.

3.2. Status Group

In the industry monitoring IoT, the status of a production line may be uncertain. With the different manufacturing techniques and different workloads, some devices in the production line may be shut down. In this case, the whole production line is still working, but values of sensors monitoring the shutdown devices will run out of range (Outliers). At the same time, related devices may also change with the shutting down operation. In an industry monitoring IoT, the rational status transformation of sensors should be recognized and ignored.

Figure 2 shows a typical flow chat of a gas-processing plant. P-1, P-2, and P-3 are three parallel subpipelines which are controlled by V-1, V-2, and V-3, respectively. Each sub-pipeline can be shut down independently and this operation will affect the value of P-0-1, a pressure sensor on the main input pipeline. In our approach, we deposit the sensors in the goal-processing plant into several status groups. Although the application background is important to the disposition method, we can follow some common rules as follows: (1)Sensors on the opposite side of a valve are not in the same group. A valve is a typical controller in the industrial IoT. All the devices on the backward position can be shut down by the proper valve. The sensors on the different side may be in different status.(2)If there are too many sensors which are controlled by one slave, they should be divided into different groups. In our approach, we will not put more than 10 sensors into one status group because the probable status space will expand acutely with the increasing sensor numbers. In this case, sensors can be grouped by their relative position with the most complex device, because the complex device may lead to status change most possibly.(3)The production line is normally divided into many units according to the geographical position. We can ignore the relationship between sensors in different sections.


Figure 2 
Typical flowchat of a gas processing plant.

For the 11 sensors shown in Figure 2, we divide them into four groups which are , , , and . represents the status of the main input pipeline. , , and are status groups which are derived from the three parallel subpipelines respectively.

3.3. Status Model

For a status group , all the sensors in may have different trends when the production status changed. Figure 3 shows a status transformation process. , , and are stable in the first 30 and the last 20 seconds. The interval from 30 s to 40 s is called the Status Transform Window (STW). and increase to a new level while keep the same trend. And the slopes of and are different. We use the trend vector which contains all the slopes of one sensors’s group to represent the status transformation, that is, . The trend of a sensor can be found by fitting its values by a specific size of STW. Here, we use the least-square method [22] (Formula (3)) to fit the values and record the rational trend vector by the sensor index. We use the key idea of incremental clustering algorithm [23] to handle the trend vectors, get the cosine angle between the current trend and existing vectors, respectively. If the angle is big enough then mark it a new trend. Otherwise, a repeated trend is found and we only need to merge it with the closest vector. In Section 4, the specific clustering method will be given for details:


Figure 3 
Status transformation process for two time instances.

4. Design of Architecture

In this section we propose the architecture for sensor fault detection in industry monitoring at first. Then, how to realize our algorithm is discussed.

4.1. A Self-Learning Framework

The self-learning sensor fault detection architecture is shown in Figure 4. There are four modules in our approach.(1)Application DB: all the parameters are stored in the Application DB, including the threshold for sensor and the history statistics result , . The grouping information is also serialized in this database. This DB is the interface for high layer application which can get the sensor fault prediction and input the user feedback. (2)Detection Thread: it is a background service and contains the main detecting process. Since our approach is an online detection, a series of detection thread will be created and maintained by the working thread pool and a related status queue. When new data is coming, the working thread dispatcher a wakes up a pending thread to handle it. (3)Self-Learning Thread: the self-learning thread uses the OS timer as a driver. The user feedback about the detection result will be rechecked by this thread to revise the trend vectors.


Figure 4 
A self-learning sensor fault detection framework.
4.2. The GbFD Algorithm

Dividing the sensors into status group is the key idea in our approach. For group-based sensor fault detection, we propose the (group-based fault detection) GbFD algorithm.

The GbFD Algorithm 1 starts by initializing the global parameters (line 6-7); then it instantiates the two core processes SelfLearningThread and DetectionThread. The input of GbFD is defined as a set that contains one time samples for a status group.

(1) let be the statistics sliding windows size;
(2) let be the outlier detection threshold for sensor S and let P be the
  global list to keep all of the ;
(3) let U and V be the global arrays to keep the last 10 gaussian
  distribution characteristics for each sensor;
(4) let be the status transform windows size and be the trend
  vector merging threshold for group , all the rational trend vectors
  of are stored in ;
(5) procedure GFD  ()
(6)  init P, loading from Appilcation DB;
(7)  init U and V, loading the last 10 distribution characteristics from
  Application DB;
(8)  create C DetectionThread threads, ;
(9)  start SelfLearningThread();
(10)  do
(11)   get a value set for sensors in a group ;
(12)   find a idle DetectionThread;
(13)    DetectionThread( );
(14)  while not end;
(15) return;
(16) procedure DetectionThread( )
(17)   if (IsStuck( ) or IsSpikes( ))
(18)     return;
(19)   if (IsOutlier( ) and not IsRatStatChange( ))
(20)     return;
(21)   IsRatStatChange( );
(22)  return;
(23) procedure IsStuck( )
(24)  get for sensor j by ;
(25)  if ( )
(26)    mark as a Stuck;
(27) return;
(28) procedure IsSpikes( )
(29)  get and for sensor j by ;
(30)  if ( and )
(31)    mark as a Spikes;
(32) return;
(33) procedure IsOutlier( )
(34)  use U and V to caculate ;
(35)  if ( ) mark as an Outlier;
(36) return;
(37) procedure IsRatStatChange( )
(38)  use the last values of to fit the trend vector ;
(39)  for each rational trend in
(40)     if ( )
(41)       mark as a rational status change; ;
(42)  mark the max unstable sensor as a sensor falut;
(43) return;
(44) procudure SelfLearningThread()
(45)  while (true) do:
(46)  load the user feedback;
(47)  for each miss alart
(48)     if missed Outlier then ;
(49)     if missed irrational status change then ;
(50)      IncClustering( , null);
(51)  for each false alart
(52)     if false Outlier then ;
(53)     if false irrational status change then ;
(54)     IncClustering( );
(55)  sleep( ); continues;
(56) return;
(57) procedure IncClustering( , )
(58)   if is not null then for each in ;
(59)    if there is then ;
(60)    else add   into ;
(61)  for each two , in ;
(62)     if (
(63)      ( , ); remove ;
(64) return;
Algorithm 1 
A group-based fault detection Algorithm.

In the DetectionTread, we first check the Stuck-at faults and Spikes by calling the IsStuck and IsSpikes methods. And IsRatStaChange is called two times (line 19–21) to detect the sensor status transformation. When an Outlier was detected, GbFD should give the conclusion whether it is a rational operation such as shut down the device, and if no Outlier happened, we also need to check the abnormal status transformation. The first calling of IsRatStaChange is controlled by the IsOutlier method with an AND logic; no more algorithm complexity is increased by the twice calling. The SelfLearningThread works as a background service. Its responsibility is learning the user feedback to find out the missing detection and the false detection and adjusting the relational parameters. For a new rational trend vector, we will add it to the proper group rational trend history by the IncClustering method, which can recluster the grouped trend vectors according to the specified angle threshold.

The time complexity of the GbFD algorithm is dominated by IsOutlier and IsRatStuChange methods. For a sensor in group , the detection computation takes , is the STW size, is the length of , and is the SSW size. In a real application, the two windows sizes are steerable and is less than 20 for the most part. Moreover, a proper thread dispatch mechanism will guarantee GbFD to handle the real-time detection task. And, the self-learning process is more complex due to many iterative operations, but it is a background service and does not require real-time performance.

5. Experimental Evaluation

We built an application to evaluate our framework. This application was implemented in JAVA, about 2400 lines code and used Oracle as the Application DB.

5.1. Data Preparation

We use real data from an oil field in China. This oil field has 20 oil/gas treatment plants and all of the production equipments are monitored by sensors which can be mainly classified as temperature sensor, pressure sensor, and liquid level sensor. The sampling rate of the production IoT is 60 seconds. We obtained the sample data of 10,000 sensors between January 1st 8 PM to October 31th 8 AM, 2012. Since the production lines are relatively stable, we filtered the original data by two steps. Firstly, some production units that never make a mistake were eliminated. Secondly, for a plant, we discard some data in its stable period.

Table 1 shows features of our simulation dataset. We choose more than 751 million samples from 5800 sensors. According to the corresponding flow charts, we separate the sensors into 1340 groups. Each group has 4.33 sensors in average, and the maximum group contains 8 sensors. We analyze the user feedback history and find out four typical errors. Outlier means that a value runs out of range and it is caused by the sensor failure. We put Stuck-at faults and Spikes together. The Rational Trend (RT) missed fault means that sensors submit an exceptional value after a rational user operation, such as shuting down a device for examination. And the Irrational Trend (IRT) missed fault means that something wrong happened with the production line and the sensor values changed with it but still suitable with the threshold condition.

Table 1 
Simulation data description.
5.2. Experiment

We split the simulation data into four datasets according to the time sequence. Each time we use optional three data sets to train the GbFD algorithm and the remainder is used as the testing data.

We use three pairs SSW size and STW size, which are (30, 15), (60, 20), and (90, 25), to run the four-folder cross-validation test. The result is shown in Figure 5. When and , each cross get a precision of about 80%. This result is not good enough. A satisfactory result is generated in the next test; and get a mean 95% accuracy. But with the increase of two windows size, the accuracy of GbFD will go to an opposite direction. This phenomenon indicates that the sizes of SSW and STW are strong correlating with our algorithm. Choosing the proper windows size can increase the detection sensitivity and the windows size (60, 20) is suitable with our simulation data.

(a) ,
(a) ,
(b) ,
(b) ,
(c) ,
(c) ,
(d) ,
(d) ,
(e) ,
(e) ,
(f) ,
(f) ,
Figure 5 
Four-folder cross-validation for precision and recall with different and .

6. Conclusions

We present a self-learning sensor fault detection framework in this paper. We propose a model which can represent the sensor value, sensor relationship, and sensor status transformation. GbFD algorithm is proposed to detect the sensor fault. And we use real data from an oil field for validation. Experimental results show that our system can detect 95% of data fault in the simulation data which contains 751.68 million samples from 5800 sensors.

We will continue validate our approach on other dataset to find out the proper statistical sliding window size and status transform windows size in different application contexts. Our goal is to build a sensor health management system for industry IoT that includes not only sensor fault detection, but also sensor lifecycle prediction and sensor inspection management.

Acknowledgments

The authors would like to thank Jun Ma for helping them to dispose the simulation data. This research is supported by the National Natural Science Funds of China (61202238), the State Key Laboratory of Software Development Environment Funds (SKLSDE-2011ZX-08), and the Fundamental Research Funds for the Central Universities (2012RC0209).