Naive Bayes Classifier-Based Fire Detection Using Smartphone Sensors by Mohammad Mahdi Mahdavi Amjad Supervisors: Professor Ole-Christoffer Granmo Dr. Jaziar Radianti Terje Gjøsæter A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree Master of Science in Information and Communication Technology University of Agder Faculty of Engineering and Science Department of Information and Communication Technology (ICT) Grimstad, Norway June 2014
58
Embed
Naive Bayes Classifier-Based Fire Detection Using ... · Naive Bayes Classi er-Based Fire Detection Using Smartphone Sensors by Mohammad Mahdi Mahdavi Amjad For many years, smoke
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Naive Bayes Classifier-Based Fire Detection UsingSmartphone Sensors
by
Mohammad Mahdi Mahdavi Amjad
Supervisors:
Professor Ole-Christoffer Granmo
Dr. Jaziar Radianti
Terje Gjøsæter
A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree Master
of Science in Information and Communication Technology
University of Agder
Faculty of Engineering and Science
Department of Information and Communication Technology (ICT)
Grimstad, Norway
June 2014
Dedicated to my beloved wife, Maryam.
UNIVERSITY OF AGDER
Abstract
Faculty of Engineering and Science
Department of Information and Communication Technology (ICT)
Master’s Thesis
Naive Bayes Classifier-Based Fire Detection Using Smartphone Sensors
by Mohammad Mahdi Mahdavi Amjad
For many years, smoke detectors have been used as the most crucial fire detection sensors.
Although smoke detectors do their job very well, they are not perfect and may cause
false or late alarms. This is because they only rely on one of the fire signs which is smoke.
Fire has many other signs as well such as heat and light. It also affects its environmental
parameters such as temperature and humidity. But typically, buildings are not equipped
with sensors capable of sensing these changes. Recently, a few smartphone manufacturers
have added temperature, humidity, and barometer sensors to their products which can be
used for more reliable fire detection. In this thesis, a framework composed of one or more
smartphones and a back-end server is proposed which can detect and visualize indoor
fire. For this purpose, the smartphones continuously collect, preprocess, and analyze
data from their sensors to detect if fire exists in their surroundings. The back-end
server facilitates the analysis processes in smartphones and provides crisis management
institutions such as police, fire department, and ambulance with real-time monitoring
user interface so that they can easily grasp useful information about the fire’s location
and scale. The proposed fire detection framework is a learning system which needs to
be trained by real data. Therefore, a wide range of experiments is precisely designed
and performed to make sure that the system can immediately and accurately detect fire
in diverse environmental conditions.
Keywords: Naive Bayes Classifier, Smartphone, Sensor, Fire Detection.
4.1 Distributions of the four major parameters involved in fire detection process. 23
4.2 Various fire experiments in Safemar training yard. . . . . . . . . . . . . . 24
4.3 Variation diagrams of the four parameters captured in Safemar experiments. 25
4.4 Distributions of temperature, light, and humidity, in the training set andtheir relation to probability of fire. . . . . . . . . . . . . . . . . . . . . . . 26
4.5 Distributions of temperature variance and humidity variance in the train-ing set, and their relation to probability of fire. . . . . . . . . . . . . . . . 27
4.6 The main process of the FireDetection framework. . . . . . . . . . . . . . 28
5.1 The general components of the FireDetection framework. . . . . . . . . . 30
5.2 An example of XML messages sent from smartphone to FDBS. . . . . . . 34
5.3 The fire icon on the smartphone screen when the fire is detected. . . . . . 37
5.4 The visualizer web application showing the location and the seriousnessof the fire reports. Circles diameter represent the seriousness of the report. 40
vi
List of Tables
3.1 A training set containing labeled data rows. . . . . . . . . . . . . . . . . . 13
3.2 An example of sensor values captured from smartphone sensors. . . . . . . 13
5.2 Examples of conditional probabilities data stored in the shared preferences. 35
6.1 Confusion matrix representing the accuracy of the classification. . . . . . 41
6.2 Confusion matrix representing the accuracy of the classification whilevariance values are removed from the training set. . . . . . . . . . . . . . 42
vii
Abbreviations
AJAX Asynchronous JavaScript And XML
FDBS Fire Detection Back-end Server
HTML Hyper Text Markup Language
HTTP Hyper Text Transfer Protocol
IIS Internet Information Services
IP Internet Protocol
ITU Internationl Telecommunication Union
JSON Java Script Object Notation
MAP Maximum A Posteriori
PDF Probability Density Function
RDBMS Relational Data Base Management System
SMS Short Message Service
SOA Service Oriented Architecture
SQL Structured Query Language
XML eXtensible Markup Language
viii
Chapter 1
Introduction
According to the International Telecommunication Union (ITU), there was about six
billion mobile-cellular subscriptions in 2011 [1]. Smartphones are also increasingly get-
ting popular and only in 2013 about one billion smartphones were sold. Smartphones
are not just used for making and receiving voice calls or sending text messages. They
are more like small computers with huge processing power and memories. They are
capable of connecting to various types of networks such as wireless, High-Speed Down-
link Packet Access (HSDPA), and Long-Term Evolution (LTE) and are also equipped
with high quality sensors such as front and back cameras, Global Positioning System
(GPS), proximity, light, accelerometer, gyroscope, etc. Newer smartphones have even
more advanced temperature, barometer, and humidity sensors.
There are many ongoing projects concentrating on the data captured from smartphones.
They typically use these data for a wide range of analyses in different areas such as
national security, health, and marketing [2][3]. Additionally, smartphones data can
be used for monitoring the surroundings of the device and consequently of the person
carrying it. For instance, it is possible to collect the temperature data perceived by
a smartphone to detect the temperature of the environment in which the smartphone
resides.
In this project, I propose a framework for using smartphones sensor data to detect fire
and also real-time monitoring the smartphones environment in a back-end server. My
approach focuses on indoor fire detection and the outdoor fire detection is left as future
work. Nevertheless, the principles of indoor and outdoor fire detection are more or less
the same, except that perhaps the outdoor sensors must meet extra requirements such as
water and dust resistance. In fact, the proposed method in this thesis can be extended
1
Chapter 1. Introduction 2
for detecting much more phenomena, and from this perspective it is a general purpose
approach.
But why do we need smartphones for fire detection while buildings have fire (mostly
smoke) detection systems? The point is, a considerable percentage of conventional smoke
detectors are dead; either malfunctioning or out of battery. They also trigger many false
alarms and annoyingly beep when they are running on low battery. Moreover, the
majority of smoke detectors are only capable of triggering an alarm, while smartphones
can make calls, send messages, enable crisis management institutions to monitor the
environment, or even propose some suggestions to their owners about the nearest exit
or other necessary information in case of emergency.
The framework proposed in this thesis is designed in relation to the SmartRescue project
where the developers work on a system which uses smartphone sensors data for real-time
threat assessment. Additionally, in the SmartRescue project the system should be able
to generate evacuation plans in an immediate manner.
1.1 Problem Statement
This thesis mainly discusses the following problems:
Sensor Selection: First of all, we need to decide on the sensors which can be used in a fire
detection process. This depends on two main factors: sensors available in smartphones,
and environmental parameters that change in case of having indoor fire. Obviously, one
of the most important signs of fire is smoke, but at the moment, smartphones do not
have smoke sensors. Therefore, we need to find a way to compensate for the absence of
smoke senors in our system.
Reasoning: At the first glance, it may seem that by using the temperature sensor of a
smartphone, it is quite easy to detect fire and for this purpose, it is enough to observe
the temperature perceived by the sensor and to trigger an alarm if it exceeds a certain
threshold. According to my preliminary experiments, there are many scenarios in which
the smartphone sensors report unrealistic values. For instance, direct sunlight, heaters,
and fireplaces can strongly affect the temperature perceived by smartphone. Other
sensors such as light and humidity have similar sources of error. On the other hand,
reasoning based on thresholds causes two issue: high thresholds result in late alarm
triggering and low thresholds cause many false alarms.
Chapter 1. Introduction 3
Real-Time Monitoring: The majority of existing frameworks which use smartphone
sensors, cannot perform reasoning and monitoring simultaneously. Thus, some of them
lack remote monitoring and others can only analyze sensor data in their back-end servers.
I believe a good fire detection framework must be able to work in real-time and provide
the remote monitoring interface while providing its users with the reasoning results.
Firefighting: According to our interviews with firefighters, when they arrive to a burning
place they do not have any idea about the fire phase. This can be deadly to them since the
fire behavior depends on the phase it is in. Currently, fire fighters use their experiences
to guess the fire phase and infer based on the smoke color, the burning sound, etc.
Some fire fighting groups have Infrared (IR) cameras to detect the temperature of the
burning place. Nevertheless, entering a burning building is always quite dangerous for
them mostly because they do not know what is going on inside. Existing fire detection
systems can only show them the room in which there is some smoke and no more.
Considering the above mentioned issues, lack of central visualization in existing fire
detection systems and their inability in inference on existence of fire based on diverse
sensor measurements are the most important problems addressed in this thesis.
1.2 Problem Solution
The main components of FireDetection, the framework proposed in this thesis, and their
capabilities are as follows:
Smartphones: My experiments show that indoor fire quickly affects the room temper-
ature, humidity, and air pressure. It also has some impact on light since normally, fire
causes smoke and it may reduce the room light. Light sensor already exists in the ma-
jority of smartphones, even budget ones. Temperature, humidity, and barometer sensors
are also available in limited number of high-end smartphones. Therefore, we have suffi-
cient hardware resources available now which can be efficiently used for fire detection.
For this purpose, an Android application is developed that collects values from tem-
perature, humidity, light, and pressure sensors and using a modified implementation of
Naive Bayes Classifier, analyzes them and calculates the risk of triggering an alarm. Af-
terwards, according to the analysis results the application decides to trigger the alarm.
This application also continuously sends the sensors data and analysis results along with
the location coordinates to a back-end server over the Internet. The reasoning process
is independently done inside the smartphones, i.e. smartphones does not need to be
connected to any other machine while reasoning.
Chapter 1. Introduction 4
FireDetection Back-End Server (FDBS): Sensors data are sent to this server to be logged
(although each smartphone has its own log) and visualized. This feature enables remote
monitoring which lets crisis management institutions such as police, fire department,
hospitals, and ambulance to monitor fire location and scale in real-time. FDBS, also
performs some heavy calculations and produces the required results for Naive Bayes
Classification. The smartphones can access these results by invoking a web service
in FDBS; once they do, there is no more need to be connected to the Internet for
performing reasoning, although the remote monitoring feature still is dependent on the
Internet connectivity. For remote monitoring, a web application is designed that plots
the fire location, its seriousness, and all values captured from smartphones on a map.
This map can be very helpful to firefighters.
Experiments: The Naive Bayes Classifier implemented in this framework is a supervised
learning system which needs to be trained in order to be able to detect fire. This forces
us to study the behavior of fire in terms of its impacts on environmental parameters.
Hence, diverse experiments are designed and performed to train the reasoner module
of the framework and to test the accuracy of its reasoning process. Approximately 70
percent of the experiment results are used for training the reasoner and the rest is used
for performance evaluation.
1.3 Key Assumptions
In reality, environmental conditions can affect the perception of smartphone sensors.
Detecting if the smartphone resides in normal condition or not, needs more consideration
and is out of the scope of this thesis. Hence, during the reasoning process, it is assumed
that the smartphone is placed indoor, its sensors are functioning correctly, and the
generated data are valid. Moreover, the proposed framework is trained in southern
Norway and its functionality in other climate conditions is not guaranteed.
1.4 Importance of Topic
Smartphones are getting more popular, and nowadays it is almost impossible to find a
family in which no one owns one of them. According to Gartner, only in 2013 about one
billion smartphones have been sold in the world so that for the first time in history of
mobile phones, the number of smartphones sold was more than the number of feature
phones sold [4]. This is an opportunity for us to benefit from the smartphones’ features
Chapter 1. Introduction 5
in order to collect accurate data about our environment. Utilizing smartphone sensor
data, we can monitor our environment and manage catastrophes in a quicker and more
efficient way. This is the main aim of the framework proposed in this thesis. It can play
a significant role in future catastrophes detection and crisis management. Likewise, it
can be a good basis for systems generating evacuation plans.
1.5 Thesis Outline
Chapter 1 focuses on the general properties of the project such as the problem statement,
problem solution at a glance, key assumptions, and the importance of the topic. In
Chapter 2, a number of research projects related to various areas of this thesis are
discussed and their strengths and weaknesses are studied. The theoretical backgrounds
and the core concepts that my solution is based on, can be found in Chapter 3. Chapter 4
concentrates on the details of the experiments performed in order to understand indoor
fire behavior and also the solution proposed in this thesis. In Chapter 5, different
components of the prototype framework and its implementation details are explained
precisely. The result gained by the FireDetection framework are described in Chapter
6. Finally in Chapter 7, the highlights of the results gained are summarized and a few
possible improvements for the proposed framework are brought up.
1.6 Chapter Summary
The aim of this chapter was to define the research question and briefly bring up the
axioms of the proposed solution. The chapter also showed how such a framework can be
important considering the remarkable growth of smartphones popularity in the world.
Chapter 2
Related Work
As mentioned in the Introduction chapter, humidity and temperature sensors are rather
new in smartphones but these two parameters along with the smoke are the most crucial
parameters in fire detection. Of course smartphones are still not equipped with smoke
detection sensors, hence, at the moment we have to use other sensors for fire detection.
To the best of my knowledge, there is no smartphones-based fire detection systems in the
market or as a published research project. Nevertheless, utilizing smartphone sensor data
has been extensively scrutinized in a wide range of activity recognition, event detection,
and context awareness frameworks. For instance, there are a huge number of scientific
papers discussing methods for detecting the physical condition of the smartphone and
consequently its carrier’s body.
Typically, these framework more rely on motion and position sensors data to detect the
orientation and the movement pattern of the smartphone. The inference or reasoning
process is then done through a variety of classification and pattern recognition tech-
niques. Although the focus of these researches is not hundred percent the same as mine,
the principles of the two approaches are more or less similar. So, I think these sort of
research are very relevant to what I do in this project. In the following sections, I bring
up some related prior researches in two areas: utilizing smartphone sensors data and
the techniques used for analyzing smartphones data.
2.1 Utilizing Smartphone Sensor Data
Pascu et al. [5] propose a framework which concentrates on capturing the articulated
motions of hand gestures. To do this, they strap three smartphones on the person’s
6
Chapter 2. Related Work 7
arm, forearm, and hand which send a combination of magnetometer, accelerometer,
and gyroscope sensor values to a back-end server to be processes and visualized. One
of the most remarkable features of this framework is its ability to work in real-time
meaning that immediately after the person moves his/her arm, the information about
the movement is sent to the back-end server and is shown by an application installed on
it. Working in real-time is missing in many similar frameworks [6][7]; they typically store
the smartphone sensor data in the device memory and then transfer it to the analyzer
machine later on. Consequently, real-time monitoring will not be possible.
In this framework, the sensor data is sent to the back-end server in the form of Java
Server Object Notation (JSON) [8] messages but before sending, data packages need
to be prepared. Hence, data preparation is a very important phase in this framework.
Data preparation is composed of noise reduction, and sensors data composition. The
main shortage in this framework is reasoning. Although it is possible to observe the
hand motion in real-time, the system cannot determine the type of the gesture. In fact,
the whole system is focused on data acquisition phase and has nothing to do with the
analytic part.
Shin et al. [9], propose an Android application which can change the layout of the
smartphone’s homepage icons and even highlight the ones that most likely the user wants
to press in the next use. As features, they collect data from a wide range of sensors
such as GPS, accelerometer, and illumination. Some Android system parameters such
as time, battery level, wireless network and Bluetooth status, and call/SMS events are
also used as other features. In this application, the inference process is performed by
using Naive Bayes Classifier.
CoenoFire is another smartphone-based system introduced by Feese et al. [10] in which
an Android application collects a wide range of information about a firefighting mission.
Firefighters must place the smartphone in their suits when going to missions so that it
can collect the required information. These information contain values reported by the
sensors such as GPS, accelerometer, barometer, and microphone. GPS fixes are used to
indicate the incident location and conditions such as being on the ground or building
floors can be derived from barometer sensor data. Microphone also records the raw
audio messages that firefighters send to other teammates and using the accelerometer
sensor data, the system detects the firefighters body movement. CoenFire system has a
back-end server containing two web services: one for handling HTTP POST messages
containing smartphone data and another web-based user interface (UI) for visualization.
The data visualization in CoenoFire is real-time meaning that it is possible to monitor
the firefighters activities in the web-based UI. However, this system can only be used for
Chapter 2. Related Work 8
monitoring in back-end server and no inference takes place in it. This research does not
reveal the details of the method of using barometer sensor for detecting the floor in which
firefighters are. According to my experiments performed with a SAMSUNG Galaxy S4
and a SAMSUNG Galaxy Note II, the difference between air pressure values sensed
by barometer sensor in the first and the seconds floors of a building is not meaningful
enough to be relied on for such an inference. Additionally, the level of air pressure
strongly depends on climate condition and can even change up to 25 millibars in one
day
As another example of using smartphone sensors, Yi et al. [6] propose an Android appli-
cation for detecting the physical activity of the person carrying the smartphone from a
collection of predefined activities such as walking, going up/down stairs, running, jump-
ing, etc. To do this, they use a combination of kinematic sensors namely accelerometer,
gyroscope, and magnetic sensors. The point is that the subject person must fix the
smartphone on his chest which is a very crucial limitation. The sensor data are stored
in the device memory card and then analyzed inside the smartphone. Therefore there
is no possibility for remote activity monitoring.
Keally et al. [11], propose a framework composed of an Android application and a set
of sensors to detect the daily activity of a subject. In spite of previously mentioned
solutions in which typically smartphone sensors are the only sources of data, in this
system, a combination of smartphone sensors and some other physical sensors is fed to
the classifier. The Android application collects sensors data and performs classification.
For the classification, they exploit their Android implementation of the AdaBoost [12]
classifier. The subject needs to strap four sensors plus the smartphone to different parts
of his/her body, more specifically, head, left and right wrists, and left and right ankles.
Physical sensors capture the temperature, light, acceleration, and voice (via microphone)
and the smartphone sensors provide the classifier with the GPS and acceleration values.
Again in this paper, there is no possibility of real-time monitoring.
Hoseini-Tabatabaei et al. [13] have done a comprehensive survey on new techniques of
opportunistic mobile-centric context recognition systems. The main goals of this sur-
vey are to classify current methods, to give an overview and some analytical details of
them, and to reveal weaknesses of the current systems. It also discusses about some
of the most challenging parts of every context recognition system such as data acqui-
sition, preprocessing, feature selection or feature extraction, labeling, and classification
algorithms.
Chapter 2. Related Work 9
2.2 Classification and Pattern Recognition Techniques in
Smartphones
Typically, classification and pattern recognition techniques implemented in smartphones,
imposes extra consideration on developers. Although top smartphones are equipped
with strong processors, massive memories, and robust operating systems, the battery
drain is still an unsolved problem when it comes to heavy calculations and long oper-
ations. Most of the classification techniques and technologies are memory and process
demanding. Therefore, implementing a good classification application in smartphones
is quite challenging. Nevertheless, there are many strong frameworks proposed in this
area which function very well. For instance, Derick et al. [14] propose a system referred
to as MIRAOAD that can classify the driving style into two categorize of aggressive
and typical. MIROAD is in fact a smartphones (iPhone) application running an imple-
mentation of K-Nearest Neighbors (k-NN). This framework detects right and left turns,
aggressive right and left turns, aggressive breaking, excessive speed, etc. To do this,
the smartphones is fixed on the dashboard of the car and continuously monitors the car
maneuvers and detects aggressive ones. If the system senses a potentially dangerous
maneuver, it starts to record video and optionally sends notification messages to an
external system through the Internet connectivity of mobile network. The authors use
data from accelerometer, magnetometer, and gyroscope sensors for classification. The
proposed application dramatically drains battery and the smartphones are required to
be plugged into the power outlet during its operation process. This system does not
provide real-time monitoring of the car motion.
In contrast, Kose et al. [15] propose an Android application which can detect the
physical activity of the person carrying the device in real-time. For this purpose, they
only exploit the accelerometer sensor data and classify person’s activity into four classes
namely, running, walking, standing, and sitting. The main focus of the authors of this
is on real-time classification which is entirely performed inside the smartphone. They
also compare clustered k-NN and Naive Bayes classifiers and conclude that the former
perform far better than the latter. However, the comparison is quite shallow in this
paper and its criteria is not clear at all.
Another example of pattern recognition using smartphone sensor data, is what Bujari
et al. did [16]. In this paper, authors aim to detect if the person carrying the smart-
phone is passing a road. They again exploit data captured from accelerometer sensor to
extract a pattern for road crossing. Their solution is strictly dependent on the behavior
of the pedestrian when crossing the road; the pedestrian must walk at normal speed
Chapter 2. Related Work 10
to the light, then stop for a moment, pass the street a bit faster, and finally return to
his/her normal speed. They combine values of three different vectors (xyz) captured
from the accelerometer sensor into a single feature called magnitude to make sure that
the smartphones placement (hand, pocket, etc.) does not have any effect on the pat-
tern recognition process. In their paper, patter recognition is limited to a very simple
algorithm which works based on magnitude numeric value and the time. Authors of
this paper do not utilize any classification technique and only rely on thresholds to infer
the road cross. Activity recognition system proposed by Guiry et al. [17] performs in
a way same except that the data collected from smartphone is analyzed off-line using
various classifiers such as Support Vector Machine SVN [18], Naive Bayes, and C4.5 [19]
to classify the activity.
2.3 Chapter Summary
In this chapter, some of the most relevant research in the area of classification and
pattern recognition were discussed. It is now clear that majority of the systems that
collect smartphone sensors data, concentrate on positioning sensors and more specifically,
accelerometer to classify the physical activity of the person who carries the smartphones
into classes such as running, walking, or sitting. Some of the papers use well-known
classification techniques and others, propose their own algorithms. But the interesting
fact is that, none of the discussed systems, provides it users simultaneously with real-
time reasoning and remote monitoring. Moreover, due to implementation difficulties
and rather complicated experiments required, several aspects of fire detection using
smartphones are still untouched by the research community.
Chapter 3
Theoretical Background
As mentioned in Section 1.2, FireDetection framework is a learning system which exploits
Naive Bayes Classification for inference on the existence of fire. The framework proposed
in this thesis is discussed in depth in Chapters 4 and 5, however, understanding it
demands some knowledge about a few machine learning and data mining concepts which
are described in the following sections.
3.1 Naive Bayes Classifier
Naive Bayes Classifier is a probabilistic classifier based on Bayes’ theorem [20][21]. Bayes’
theorem describes the relation between conditional probabilities of a hypothesis and
observations as given in Eq. 3.1. Assume that h represents the hypothesis and O
represents the observation made.
P (h|o) =P (o|h)P (h)
P (o)(3.1)
where:
• P(h) = prior probability of hypothesis
• P(o) = prior probability of observations o
• P (h|o) = probability of hypothesis given o (posterior probability)
• P (o|h) = probability of o given hypothesis (likelihood)
11
Chapter 3. Theoretical Background 12
Typically, the most probable hypothesis or the maximum a posteriori hypothesis is
required to be identified. The maximum a posteriori (hMAP ) is given by Eq. 3.2.
hMAP = arg maxh∈H
P (o|h)
= arg maxh∈H
P (o|h)P (h)
P (o)
= arg maxh∈h
P (o|h)P (h)
(3.2)
Now, let H = hj ∈ {h1, h2, . . . , hm} be the hypotheses, assuming that hypotheses are
mutually exclusive and exhaustive and 〈O1 = o1, O1 = o2, . . . , On = on〉 be the various
observations made. Then the most probable hypothesis is given by Eq. 3.3.
hMAP = arg maxh∈H
P (hj |o1, o2, . . . , on)
= arg maxh∈H
P (o1, o2, . . . , on|hj)P (hj)
Po1, o2, . . . , on
= arg maxh∈H
P (o1, o2, . . . , on|hj)P (hj)
(3.3)
Naive Bayes Classifier assumes that the conditional probability of observations given
hypothesis equals to the production of conditional probabilities of each observation given
the hypothesis according to Eq. 3.4.
P (o1, o2, . . . , on|hj) =∏i
P (oi|hj) (3.4)
By substitution of P (o1, o2, . . . , on|hj) by∏iP (oi|hj) in Eq. 3.3, Naive Bayes Classifier
is given by Eq. 3.5.
hNB = arg maxhj∈H
P (hj)∏i
P (oi|hj) (3.5)
Naive Bayes Classifier is a supervised learning algorithm which means it needs to be
trained before being able to do classification. Therefore, it must have a training set.
The training set contains a number of observations and the classes in which they are
classified. For example, the training set shown in Table 3.1 contains the values of four
parameters (T, L, H, P) and a class (Fire) in which various sequence of parameter values
are classified.
Chapter 3. Theoretical Background 13
Table 3.1: A training set containing labeled data rows.
T L H P FireA B A C NOA A B A NOB B A A NOA A C C NOB A B C YESB C C A YESB A B B YES
The aim of a Naive Bayes Classifier is to classify an unseen sequence of parameter values
into one of the classes in training set. Assume that the values to be classifiers is B, A,
A, C. The classifier must classify this sequence of values into one of the Fire classes:
YES or NO. According to Eq. 3.5, the hypothesis with the bigger likelihood must be
selected. The classifier needs to refer to the training set to calculate probabilities of
each class based on the probability distribution in the training set. For calculating the
probability of the class NO, the classifier must count the number of data rows in which T
equals to B when the data row is classified as NO. There is 1 data row with this criteria
while there are 3 data rows in which the T equals to B and the data row is classified as
YES. Hence, the conditional probability of T equals to B given NO equals to 1/4. The
classifier calculates all the conditional probabilities
As shown in Table 3.2 raw values of smartphone sensors are numeric (i.e. continuous)
whereas, the input data of the Naive Bayes Classifier should be nominal. Thus, a method
is required for converting numeric data to nominal data as discussed in 3.2.1.
Table 3.2: An example of sensor values captured from smartphone sensors.
connection [32]. The FireDetection framework is a prototype so its storage performance
is not the most important issue, but I briefly mention that since the information I want
to store is not particularly large, database is not necessary. On the other hand having
text files forces the application to parse them regularly which is not a good idea as well.
I utilize the shared preferences which is a storage space managed by the Android oper-
ating system (OS) and can be used to store rather small amount of data in the form of
key-value. Typically, the shared preference space is used to keep the application configu-
rations but I use it to store the results of the calculations required by the reasoner. The
information stored in shared preference are the values of the conditional probabilities of
various observations given fire and normal based on data in training set. Table 5.2 lists
some examples of the data items stores in the shared preferences.
Table 5.2: Examples of conditional probabilities data stored in the shared preferences.
Key (string) Value (float) Description
TAgF 0.0035 cond. prob. of temperature equals to A given fire
TBgN 0.002 cond. prob. of temperature equals to B given normal
HCgF 0.00081 cond. prob. of humidity equals to C given fire
LMCgN 0.0066 cond. prob. of light mean equals to C given normal
PVFgF 0.009 cond. prob. of pressure variance equals to F given fire
The most important advantage of the shared preference is that reading from and writing
to it are quite easy in terms of programming and there is no need to implement a text
parser in the Android application. Moreover, it is private and other applications cannot
access its values.
5.1.5 Preprocessor
Preprocessor module of the smartphones is responsible for calculating mean and vari-
ance values and also performing discretization on numeric sensors data in respect to
the intervals given in Table 4.1. The momentary means and variances are calculated
by CalculateMean() and CalcualteVariance() methods respectively. The dis-
cretization process is also performed continuously by the Discretize() method.
These three methods are called when a new sensor value is reported and hence, the
Chapter 5. FireDetection Implementation 36
momentary nominal values of sensors’ numeric values are immediately accessible to rea-
soner.
5.1.6 Reasoner
The reasoner module of the smartphone is where the classification takes place. The
inputs to this module are the sensor data and the other features previously generated
by the preprocessor. The input of every single reasoning round contains the nominal
values of 12 features as mentioned in Subsection 4.2.2. For instance, assume that the
sequence of feature values is like A, A, B, . . . . Knowing the order of the parameters in
this sequence, the reasoner refers to the probability values kept in the storage and fetches
them according to the input. It needs to find the conditional probability of temperature
equals to A given fire and normal, conditional probability of humidity equals to A
given fire and normal and so on. To do this, the reasoner invokes a method called
LoadTrainingSet(String key) and provides it with the “key” associated to the
desired “value”. Considering the rule of making key names explained in 5.2, the value of
conditional probability of temperature equals to A given fire is stored in association with
the “TAgF” key. Therefore, invoking the LoadTrainingSet(String key) method
with input string of “TAgF” will return “0.0035” which is our desired probability. Once
all conditional probability values are fetched from shared preference storage, the reasoner
calculates the conditional probabilities of fire and normal given the sequence of values.
Then it calculates the risks of triggering alarm or staying silent in accordance to the
risk calculation explained in 4.3, and decides if the alarm should be triggered. The
momentary value of seriousness of the case is sent to the FDBS to be used by visualizer
for plotting maps and other monitoring purposes.
It is possible that the training set does not have the value of the conditional probability
associated with a specific key. For instance, the temperature observed by the sensor is
converted to the value X but calling the LoadTrainingSet(X) returns 0. Therefore,
considering Eq. 4.3, the value of P (Fire|T = x, L = y, . . . ) will be equal to zero
regardless of other conditional probabilities. This issue is called zero-frequency and
must be treated somehow since in reality we know that even if we do not have such a
record in our training set it does not mean that the probability of its occurrence is zero.
There a few solution to overcome this issue such as using Laplace Estimator [33] but
the easiest solution is to simply remove the effect of such a case by putting “1” instead
of “0”. This, results in extraordinarily high probability. Another option is to put a
very small value instead of zero but this may also affect the correctness of the reasoning
Chapter 5. FireDetection Implementation 37
since it means that the reasoner is relying on something other than the training set. In
FireDetection framework this problem is solved by manually checking the training set
and making sure that all possible keys have one value.
5.1.7 Alarm
There can be many types of notification generated in case of having fire such as a beep
(or ring), a voice call or an SMS sent to fire station or any other involved authorities, etc.
In this project the smartphone plays an alarm sound when detecting fire and shows a
fire icon on the application screen as depicted in Figure 5.3. Moreover, the visualization
module of the FDBS continuously observes the smartphone environment and visualize
the status of the probable fire.
Figure 5.3: The fire icon on the smartphone screen when the fire is detected.
5.2 FDBS
Battery duration is one of the main challenges in every project putting the burden of
heavy calculations on smartphones. So, I try to strip down the smartphone calculation
tasks as much as possible and perform them in FDBS. The two main tasks performed in
FDBS are maintaining the training set and calculating conditional probabilities based
Chapter 5. FireDetection Implementation 38
on it. As illustrated in Figure 5.1, the FDBS has a visualizer component as well that
provides us with remote monitoring.
5.2.1 HTTP Handler
In FireDetection framework, smartphones send their sensors data in the form of a Hyper
Text Transfer Protocol (HTTP) POST request containing an XML message as its body
to the FDBS to be stored and visualized. Therefore, the FDBS must be able to handle
HTTP POST requests. By handling I mean receiving the request, parsing XML message
in its body, extracting parameters and their values, and passing them to database and
visualizer modules. To do this, the HTTP handler must be deployed in a web server. All
modules in FDBS are developed using Microsoft technologies and the HTTP handler is
not an exception. Microsoft’s Internet Information Services (IIS) is used for deploying
the HTTP handler. The IIS must be configured so that it can redirect incoming requests
to different handlers and web applications that are deployed in it. For this purpose, the
IIS checks the extension of the incoming request and based on it, chooses the right
handler or web application to hand over the request. I defined a new extension for
requests sent from smartphones as .smrtrsq. Hence, smartphones must send HTTP
POST request to the following Uniform Resource Locator (URL):
http://IP-Address/FireDetector/request.smrtrsq
Once the extension is defined and the HTTP handler is deployed in IIS, all incom-
ing requests having the above mentioned extension will be automatically redirected to
FireDetection HTTP handler.
5.2.2 Database
The smartphone sensor data received and parsed by HTTP handler, are then delivered
to the database which is implemented in Microsoft SQLServer 2008 R2. developed by
Microsoft. The database consists of a number of tables and stored procedures available
to the handler enabling it to manipulate the database. General functionality that the
stored procedures provide is “insert into database” so that the HTTP handler can insert
the sensor data into the database. The database consists of two tables: one for storing
the training set and the other one for storing the raw data received from smartphones.
Chapter 5. FireDetection Implementation 39
5.2.3 Calculator Web Service
Although in Figure 5.1 the calculator web service is depicted as a single module, its
implementation is a bit different. The implementation details of this module is out of
the scope of this project, however, it is composed of a stored procedure in the database
and a web service in the FDBS. This module has two responsibilities: first, to calculate
the conditional probabilities required by the reasoner (i.e. classifier) and second, to
make them accessible to the reasoner as a web service. Consequently, the smartphone
does not need to perform heavy calculations during its reasoning process and the web
service helps the reasoner to keep its resources updated.
5.2.4 Visualizer
XML messages containing sensor data, GPS coordinates, and the seriousness value are
sent to the FDBS in every five seconds. Therefore, the visualizer module of the FDBS
can visualize the location of the smartphones and the momentary seriousness of fire
reports in a real-time manner. To do this, the Google Maps Application Programming
Interface (API) [34] is used for visualization. Google Maps API is a JavaScript library
that can be integrated to web applications and web sites. The map is embedded in a
C Sharp web application which interacts with the Microsoft SQLServer database and
fetches the most recent records received by executing a stored procedure. The visualizer
web application, executes this stored procedure and refreshes the map every five seconds
which means any changes in database is visualized in the map almost immediately. To
refresh the map, an Asynchronous JavaScript And XML (AJAX) library called Ajax
Control Toolkit is used.
Chapter 5. FireDetection Implementation 40
Figure 5.4: The visualizer web application showing the location and the seriousnessof the fire reports. Circles diameter represent the seriousness of the report.
As illustrated in Figure 5.4 the GPS coordinates of the fire reports are used to draw
four red circles on the map representing the places of the fire incidents. The diameters
show the seriousness of the case calculated and sent by the smartphones based on the
values of the ζ explained in Section 4.3. This map also provides users with some useful
information about the temperature, humidity, light, and the air pressure sensed by the
smartphones which have sent the fire report. These information are available by clicking
on each circle.
5.3 Chapter Summary
In this chapter, implementation details of the components of the proposed framework
were described. We saw how different components of the FireDetection framework inter-
act each other to detect and visualize probable fires. Collecting data from smartphones’
surroundings, preprocessing, analyzing, logging, and sending it to the FDBS machine,
reasoning based on it and finally, visualizing it were among the FireDetection tasks
highlighted in this chapter.
Chapter 6
Evaluation and Results
In this chapter, the results achieved by the Naive Bayes Classifier are offered. The results
are expressed in a confusion matrix which shows the percentage of correctly classified
and wrongly classified parameter sequences. A comparison between performance of the
Naive Bayes Classifier with a few other classifiers is also made and its discussion can be
found in this chapter.
6.1 FireDetection Performance
Reasoner module of the smartphones in FireDetection framework showed 76.3 percent
accuracy in classification of normal cases and 89.7 percent in classification of fire cases.
This results are given as a confusion matrix in Table 6.1.
Table 6.1: Confusion matrix representing the accuracy of the classification.
Predicted ClassesNormal Fire
Actual ClassesNormal 76.3 23.7
Fire 10.3 89.7
To test the importance of the variance values, I removed all variance values from the
training set and tested the reasoner again. As shown in Table 6.2 although the accuracy
of the classification of normal cases improves, the classification of fire cases degrades to
70.7 from 89.7 percent. Considering that the accuracy of the system on detecting fire
is more important to FireDetection framework, I decided to keep the variance values.
We can compensate for the rather low accuracy of the classification of normal cases by
exploiting the proposed risk calculation method explained in Section 4.3.
41
Chapter 6. Evaluation and Results 42
Table 6.2: Confusion matrix representing the accuracy of the classification whilevariance values are removed from the training set.
Predicted ClassesFire Normal
Actual ClassesFire 93.1 6.9
Normal 29.31 70.7
6.1.1 Alternative Discretization Methods
The proposed discretization method is used in FireDetection framework, however, there
are alternative discretization methods which can affect the classification accuracy. Data
mining tools such as Weka [35] and Orange [36] offer different discretization methods.
For example in the Orange framework, there are three discretization options: Entropy-
MDL, equal-width, and equal-frequency. Studying the Entropy-MDL algorithm [37] is
out of the scope of this thesis but the equal-length and equal-frequency method were
considered when designing intervals. These two methods can be useful when the type
of the data set and its characteristics are unknown to the classifying system, and from
that perspective the classifier is a multi-purpose system which does not care about the
data set semantics, whereas, the FireDetection framework is specialized to work with a
constant training set and can only detect fire. Therefore, it does not need automatic
discretization algorithm.
6.2 Alternative Classification Methods
There are many alternative classification methods that could be used in FireDetection
framework. To see if they show better classification accuracy, I used the Orange data
mining tool. The Orange provides many classifiers, but I chose three of them that
are: Neural Network, k-NN, and Logistic Regression. As expected [38], all three show
slightly better accuracy than the Naive Bayes Classifier but judging about their efficiency
is difficult unless all classifiers are implemented on the smartphone.
6.3 Chapter Summary
In this chapter, the results achieved by the FireDetection framework were offered. We
discussed the accuracy of the classification process and also the possible alternative
methods and technologies that could have been engaged.
Chapter 7
Conclusion
In the present thesis, I introduced the FireDetection framework which detects indoor
fire and visualizes its location and scale based on reports containing smartphone sensors
data. The FireDetection is composed of the smartphones and the FDBS. The inference
process on existence of fire is performed using Naive Bayes Classifier implemented inside
the smartphones. The smartphones also send data to FDBS for visualization purposes.
The implemented classifier, has been modified so that it can produce the ζ metric of
fire which represents the seriousness of the case, i.e. the fire report. Under defined
criteria, this metric along with GPS coordinates are plotted on a web based map. This
framework is a learning system and has been trained in southern Norway. Therefore, its
functionality is only valid in similar climates. The reason for this is that the reasoning
process is based on parameters such as temperature, humidity, and air pressure, subject
to change in different environmental conditions. As a conclusion, the highlights of the
results obtained in this project are listed as follows:
Sensor Selection: It is now safe to state that currently available smartphones can feasibly
infer on existence of fire in their surroundings. The classification (or inference) results
offered in 6.1 and also the experiments presented in Sections 4.4 and 4.5 prove our
hypothesis of fire detection using smartphone senors.
Reasoning: The reasoning process proposed in this thesis was also quite efficient both in
term of results and battery consumption in smartphones. In total Naive Bayes Classifier
gained 83.5 percent accuracy that considering the defined mechanism for triggering the
alarm, is sufficiently reliable.
Experiments: The valuable opportunity of performing exclusive fire experiments in a
real environment is definitely one of the strong points of this thesis. Highly accurate
43
Chapter 7. Conclusion 44
results gained in the reasoning process approves the quality of performed experiments
and motivates further research and development in this area.
Visualization: One of the most important goals of this project was to provide crisis
management institutions with a real-time monitoring tool helping them to know more
about a fire. The output of the visualizer web application is one step towards safer
firefighting operations.
7.1 Future Work
Some of the possible improvements of the present framework are rooted in the limitations
and assumptions we had to define at the beginning of the project. For instance, the
framework has been designed and implemented to be used in Norway and using it in
other countries with significant climate differences may lead to false results unless the
training set is updated according to the new environmental parameters. Therefore,
the first possible improvement of this framework can be the possibility of updating the
training set directly from the smartphone user interface so that there will be no need to
manipulate the code both in the smartphone and the FDBS.
The proposed framework can be extended to be used in outdoor locations as well. Mon-
itoring forests to prevent probable fires from getting too large can be an interesting
expansion of this system. But then, we need to replace the smartphone sensors with a
huge number of sensors mounted (or dropped) on various places in the forest. Outdoor
sensors must be a bit different in terms of thresholds, being water and dust resistant,
etc. However, the principles of reasoning and fire detection seems to be the same.
Another potential functionality of the FireDetection framework is providing its users
with survival hints. Currently, our smartphones can detect fire individually and the
FDBS can visualize the fire according to the information received from them. Another
reasoner residing in FDBS can analyze smartphones reports, find the best way to save
more people, and send them messages containing useful information. This interactive
system needs huge amount of prior information about the place of fire (emergency exits,
stairs, etc.) and it demands lots of memory and processing power, but it can save lives.
During the data collection and experiment phases in this project, we noticed that the
level of pressure and humidity are extremely dependent to the weather. These two
parameter can have a wide range of values. For instance, we had pressures from 1001
to 1025 millibar in different days. It would be useful if the smartphone could access the
Chapter 7. Conclusion 45
momentary mean values of the four parameters through an external web service. The
main advantage of such a web service is that the smartphone can dynamically adapt its
reasoning to the weather condition. This should be discussed in the future. Moreover,
in this project we assumed that the data captured from smartphone senors are accurate
and valid but in reality not all smartphones sense the same in the same condition.
This happens because there are various sensor vendors and smartphone manufacturers.
Although we did not have enough time to address this issue, a combination of the
external web service and data quality techniques could reduce such impacts on the
reasoning process.
Bibliography
[1] International Telecommunication Union. The World in 2011: ICT Facts and Fig-
ures. ITU, 2011.
[2] James Manyika, Michael Chui, Brad Brown, Jacques Bughin, Richard Dobbs,
Charles Roxburgh, and Angela H Byers. Big data: The next frontier for inno-
vation, competition, and productivity. 2011.
[3] C Dobre and F Xhafa. Intelligent services for big data science. Future Generation
Computer Systems, 2013.
[4] Gartner. Annual smartphone sales surpassed sales of feature phones, March 2014.
URL http://www.gartner.com/newsroom/id/2665715.
[5] Tudor Pascu, Martin White, and Zeeshan Patoli. Motion capture and activity
tracking using smartphone-driven body sensor networks. In Innovative Computing
Technology (INTECH), 2013 Third International Conference on, pages 456–462.
IEEE, 2013.
[6] Yi He and Ye Li. Physical activity recognition utilizing the built-in kinematic
sensors of a smartphone. International Journal of Distributed Sensor Networks,
2013.
[7] Lin Sun, Daqing Zhang, Bin Li, Bin Guo, and Shijian Li. Activity recognition on
an accelerometer embedded mobile phone with varying positions and orientations.
In Ubiquitous intelligence and computing, pages 548–562. Springer, 2010.
[8] Douglas Crockford. Json: The fat-free alternative to xml. In Proc. of XML, 2006.
[9] Choonsung Shin, Jin-Hyuk Hong, and Anind K Dey. Understanding and prediction
of mobile application usage for smart phones. In Proceedings of the 2012 ACM
Conference on Ubiquitous Computing, pages 173–182. ACM, 2012.