Many water boiler manufacturers are not able to detect the occurrence of failures in the machines they produce before they can pose inconvenience and sometimes danger for costumers and workers. Moreover, the number of boilers that have to be monitored, are many times in the range of the thousands or even millions, proportionaly to the number of costumers a company possesses. The detection of these failures in real time, would provide a signi cant improvement to the perception that consumers have of a certain company, since, if these failures occur, maintenance services can be deployed almost as soon as a failure happens. In this paper, an application prototype capable of monitoring and preventing failures in domestic water boilers, on the y, is presented. This application evaluates measurements which are performed by sensors within the boilers, and identi es the ones that greatly di er from those received previously, as new data arrives, detecting tendencies which might illustrate the occurrence of a failure. The incremental local outlier factor is used with an approach based on the interquatile range measure to detect the outlier factors that should be analysed.
One of the major problems faced by manufacturers of domestic equipment and components of any kind, is the lack of ways to detect the occurrence of failures in these machines before they can pose an inconvenience and sometimes danger for costumers and workers. Speci cally, the detection of these instances in real time, would provide a signi cant improvement to the perception that a consumer has of a certain company, since, if these failures occur, maintenance services can be deployed almost as soon as a failure happens. Ideally, by using predictive techniques, the detection of these issues before they happen by analyzing the metrics that de ne the behavior of a certain component, becomes a desirable goal. Another issue faced by many companies, especially the ones that provide products for a household, is the fact that the number of machines that have to be monitored, are many times in the range of the thousands or even millions. This poses a problem, since the amount of data that has to be analyzed can be in the order of several Gigabyte, and needs to be processed in mere seconds.
In the speci c case of domestic and industrial water boilers, as well as other heating equipment, the nature of these failures has to do with disruptions in the operation of these machines, in both a domestic and industrial context. In order to overcome this monitoring problem, sensors can be installed within water boilers, in order to record data related to several parameters and how they change over time. The main objective for this paper, therefore, was the development of an analytical backend application, capable of processing streams of data from measurements from boiler sensors, in real time, detecting outliers within them, which signify the occurrence of failures in a water boiler in di erent contexts. After this detection has been achieved, an analysis on the components responsible for that failure has to be done, ideally also in real time, so that this information can be passed on to maintenance services, so they act to solve these issues. It should also be able to deal with signi cant amounts of data in a short amount of time from di erent equipment/boilers.
After this introduction, a list of di erent implemented approaches related to outlier detection in boilers is mentioned in section 2. Section 3 presents the proposed application for outlier detection in data streams by analyzing its individual constituent parts, as well as an overview of an o ine phase to assert the relevance of the di erent parameters. Finally, the results for this application performance are analyzed in section 4, rst regarding the used methodology for outlier detection in data streams, then the overall advantages of using the proposed module for data processing, and nally the results of the o ine phase and the knowledge added to the application derived from it. In section 5, conclusions taken from these results are presented, as well as suggestions for future work. 2
A considerable amount of work has been done on the topic of fault detection in
several types of boilers. In [1{3], di erent cases of boiler faults and data mining
techniques for their detection are presented. The biggest limitation for these
cases however, is that none of these deal with outlier detection in data streams,
or data sequences that arrive continuously and have to be analyzed in a real
time manner. All of these approaches take time to assemble data, analyze it in
order to create training datasets and only then construct a model capable of
classifying or clustering boiler measurements. Therefore, even if the data has
a temporal component, it is not analyzed in an on the y manner. The work
presented in [
Due to this lack of cases for real time outlier detection in boilers, a more
general approach was taken, analyzing outlier detection in data streams for data
from di erent contexts, as presented in [
In this section, an overview of the entire application is provided. Figure 1 ilustrates the di erent phases within the application. The dataset used to test this application consisted on a collection of measurements received by the sensors within a domestic water boiler, collected over a period of 24 hours, and in which the parameters were controlled at will, in order to simulate di erent types of real world situations, namely equipment faults. Each observation was provided in JavaScript Object Notation (JSON) format, and it contained four kinds of attributes: { Numerical: these are continuous, quantitative values supplied by the water boiler sensors, which indicate physical measurements, for example the water temperature within the boiler at a speci c point in time; { Categorical: these on the other hand, are attributes that have qualitative values, and indicate the state of water boiler components, work modes that the boiler might have (for example if at a certain point in time, the boiler is being used to heat water from a shower, or if it is being used for central heating) and also general descriptive information about the characteristics of the boiler, operation time, as well as many other parameters; { Timestamp: a especially important attribute since messages did not arrive at xed time intervals; { Boiler ID: an identi er of the water boiler the present observation belongs to. For this project only one water boiler was available, so the ID was unique.
Another interesting characteristic of these data points is that each JSON message is only sent if some measurement value changes showing only the changed attributes. If, for example, the ame which warms up the water within the boiler was turned o at time t0, and then turned on at time t10, in the messages from [t1; t9], the attribute relative to the state of this ame would not show up in the messages.
Because the domain of these boiler measurements is only known by a small group of people, and the water boiler measurements arrive in a data stream like fashion, it is not possible to present a throughout list of all speci c attributes within these categories. Since each message only shows measurements that change, or that are di erent from previous ones, there is always a chance that a new attribute might show up.
The continuous reception of JSON messages was simulated with a server that send JSON messages at speci ed time intervals via a local TCP/IP connection, to a single port. That is, a socket connection was created in the local machine, in order to send the data. It is important to notice that, in order to preserve simplicity, JSON messages were not sent according to their timestamps, as that would require additional calculations for the exact times that were not particularly relevant for this project. The time interval for these messages could be constant and controlled by the user, or randomized, depending on what tests had to be performed.
The algorithm chosen to perform the failure detection procedure in the
described boiler data was the Incremental Local Outlier Factor (LOF) [
The proposed incremental LOF algorithm computes LOF values for each data record inserted in a sliding window with a xed size and constantly updated values, and instantly determines whether the inserted data record is an outlier. Speci cally, it speci es two di erent situations: (i) If LOF (q) < 1, then q is an inliner (ii) If LOF (q) 1, then q is an outlier
As the reader may deduce, the cases when LOF values are equal or just slightly bigger than 1 cannot be accurately labeled by relying solely on the incremental LOF, since it only provides a clear binary distinction for the cases above. The solution for this problem is addressed later on.
Despite this algorithm provides a simple yet e ective way to detect outliers
from dynamic data, it does present some aws which need to be addressed. The
rst challenge is faced when using this algorithm with the provided data. Since
each JSON message has both numeric and categorical attributes, the Euclidean
Distance alone does not work because it does not deal with categorical attributes.
Instead, the Overlap Distance Measure [
Since in a distance measure as di erent the values are as larger the distance
is, the distance measure had to be changed for this particular application: if the
values are the same, 0 is given as a distance measurement, otherwise 1 is given.
For a measurement with both numeric and categorical attributes, the Euclidean
and the Overlap distances, respectively, are computed and added together [
Another major limitation for the incremental LOF algorithm is the fact that
outliers cannot usually be well evaluated if LOF values are very close to 1,
because there is a certain degree of subjectiveness depending on the window
values that are presented. For example, a 1.2 value might be an outlier in a
certain window, but it might not be one in a di erent window. In order to
address this limitation, the notions of boxplot and interquartile range were used,
as de ned in [
The interquartile range (IQR), is the di erence between the values of the
third (Q3) and rst (Q1) quartiles and it can be used to detect outliers [
Q3 + 1:5
IQR
Armed with these conclusions, labeling data points based on their LOF values becomes trivial: 1. The LOF values within a given window W are sorted, and the median (Q2) is determined; 2. Q1 and Q3 are determined as the 25% percentile and 75% percentile values in the window, respectively; 3. The IQR can then be calculated by Q3 Q1; 4. Data points are then labeled as outliers, if their LOF values are bigger then Q3 + 1:5 IQR
In order to apply this algorithm in a distributed scenario, in which
measurements from a large number of boilers need to be processed at the same time,
a suitable data processing engine has to be used. Spark is a fast and
generalpurpose cluster computing system for large-scale data processing, and was chosen
to process the measurements from water boilers. It provides high-level APIs in
Java, Scala, Python and R, and an optimized engine that supports general
execution graphs [
Once the processed data points are properly labeled, in order to make them more interpretable for the user, they were stored in a MySQL Database, so that a visual representation of all data points can be provided in a near real time fashion (Figure 2). This way, outliers are more intuitive and observable for front-end users. Using the Node.js library provided by JavaScript server side applications, a server was created, with the intent of extracting the data points from the referred MySQL database. The extracted messages and respective labels are then requested to the Node.js server by a client, in order to graphically represent the data in our browser, at a speci ed local host port. The library used to achieve a real time graphical representation was D3.js. Because the knowledge of the domain was scarce, there was no information about which speci c attributes were responsible for the results of the incremental LOF algorithm.
This o ine learning phase uses the knowledge gained from the outlier detection phase, in order to determine which attributes are more signi cant in the labeling of the data points.
The Classi cation And Regression Tree (CART) algorithm [
As shown in Table 1, the values of the incremental LOF algorithm can change greatly depending on the parameters. The left and central cases analyze the same 10 LOF values, for di erent parameters, and the last case compares the rst 10 data points in 3 consecutive windows. Looking at both the left and central cases, it becomes apparent that it tends to be a stabilization of the LOF values as the parameter values increase. In the case of N, the larger the window size, the more faithfully statistics can be derived for the whole data stream, and thus di erences between data points become less signi cant, unless there is a great discrepancy between the measured attributes. When the k nearest neighbor is increased, the resulting LOFs do not follow a clear tendency. As discussed in section 3, LOF values are classi ed by using the Interquartile Range concept for each sliding window of values. Figure 3 illustrates a series of boxplots for di erent windows created using the Minitab Sofware, one with only normal values, and another with both normal and outlier values. The window size N is of 500 and the nearest neighbor k value is of 10.
Observing Figure 3 it is possible to notice the subjective nature of LOF values from time instance to time instance. Each boxplot contains the value of the median for each of the di erent windows, as well as the extreme values of the box, i.e., the values of the rst and third quartiles. Table 2 presents the values of these three statistics, as well as their interquartile ranges for three di erent box plots.
By knowing these parameters, it becomes quite simple to establish a labeling value limit by using Equation 2. The LOF values at T 0 are shown in Table 3. Having presented the results from the used outlier detection algorithm in a data stream, it is now time to look at how the Spark Streaming module behaved, when it comes to implementing the incremental LOF algorithm, by analyzing its processing time for multiple cases.
By looking at these results, it is clear that data processing for algorithms of lower complexity works better in the Spark Streaming Module. In the case where N=50 and K=5, the average scheduling delay in the processing of boiler measurements, that is, the time each message needs to wait before it gets processed, is pretty much zero. This means that the chosen batch interval of 1 second was su cient to handle the algorithm computations. In the case where N=500 and K=11 though, as shown in Table 4, it becomes evident that data processing is not viable, due to the fact that the processing time of each JSON message is much larger than the batch interval.
Speci cally the processing time for N=500 and K=11 is exactly two times bigger than that of the de ned batch interval. This of course causes an increasing scheduling delay because JSON messages arrive faster than the time that Spark Streaming takes to process them.
The reason why the data processing time takes this long for bigger values of the N and k parameters, is mainly because of the sequential nature of the incremental LOF algorithm. Since all the operations depend on themselves, one operation cannot be completed without concluding the previous one, which defeats the paradigm of data parallelization that Spark uses. Even though a lot of partitions might be formed, they cannot be executed in parallel e ectively, because one speci c operation can create a bottleneck, and because all operations have to be done in sequence, the processing time is completely dependent on that bottleneck.
As can be seen in Table 5, in the case in which the input is kept at 1 record per second, the number of partitions within each RDD is not that signi cant. Because of this fact, having more cores available for data processing is irrelevant, since there are not enough partitions to divide among the nodes, resulting in a very similar performance. This situation changes when the input number is increased, namely, data processing becomes signi cantly faster when all cores from the local machine are used with a di erence of about 90 ms when there are 5000 input messages.
It is important to notice that because Spark was deployed in local mode, the advantages of data parallelization are smaller than executing it in a distributed environment with multiple JVMs and nodes.
Another relevant aspect to take into account is that, because only measurements from a single water boiler were provided, the parallelization by source suggested in section 3 and the possible bene ts it would have for the processing speed were impossible to test in this use case. 4.3
As discussed in section 3, a key interest for this application, would be to determine what are the most signi cant attributes from each measurement, that lead to their classi cation as being outlier or normal. In order to accomplish this, a Classi cation And Regression Tree was built as shown in Figure 4 and Table 6. Some interesting and meaningful variables were deemed relevant, like the primary temperature in the water boiler. Ultimately, the results of this decision tree model can only be evaluated accurately if one possesses labeled measurements in order to test the model predictive capacity. Unfortunately, there were no labeled measurements available to do it. The goal of this paper was to develop a backend application capable of detecting outliers in data stream measurements from sensors of multiple water boilers.
Regarding the use of the incremental LOF algorithm, the overall result was fairly reasonable, considering that there was no labeled data available. The developed prototype is able to detect both single and collective outliers in a time interval of one second, if the window size and k neighbors is not too high. The subjectiveness of the original incremental LOF values was solved by continuously determining statistics based in boxplots for each window of values, for each new measurement that arrived.
Apache Spark and Spark Streaming provide an easy, compact syntax to perform map reduce operations. An analysis was conducted on the e ects of the applications level of parallelism, which showed the potential for future work in a distributed computation environment. Because there were only measurements from one water boiler, parallelization by data source was not achieved, but nevertheless data was divided into partitions successfully, proving that it is possible to implement this in future projects.
The o ine phase was also a very relevant step for understanding the domain of the measurements, and provide insights on which parameters from the sensor measurements were more relevant for outlier classi cation.
The proposed algorithm was too complex to process measurements from water boilers, not being fast enough when the number of samples and nearest neighbors in the incremental LOF algorithm is large. This is due to the sequential nature of incremental LOF. To adapt it to parallel processing is a promising research line.
Another challenge is to use labeled test datasets to evaluate the performance of this work. Approaches for outlier detection using supervised learning should also be tested.
Regarding the Apache Spark engine and the Spark Streaming module, since all tests were performed in local mode, the data processing speed was reasonable. However, Spark could be deployed in a distributed computation scenario with multiple nodes (JVMs) and even more cores.
The o ine phase could be done online using the Very Fast Decision Tree algorithm instead of the CART algorithm that was used in this work. Acknowledgements This work is partially nanced by the ERDF European Regional Development Fund through the Operational Programme for Competitiveness and Internationalisation - COMPETE 2020 Programme within project POCI-01-0145-FEDER-006961, and by National Funds through the FCT Fundac~ao para a Ci^encia e a Tecnologia (Portuguese Foundation for Science and Technology) as part of project UID/EEA/50014/2013.