Design and Implementation of a Sensor Network over the Fire Scene
Chia-Wei Luo, Guan-Yi Li, Chih-Hao Shih, Tzu-Han Wu
Dept. of Computer Science and Information Engineering of National Taiwan University
{b93070, b93018, b93005, b93019}@csie.ntu.edu.tw
Abstract
Although there are already plentiful study and theory of
sensor network, the realistic implementations of
applications based on sensor network are few. In
comparison with theory, implementation confronts various
obstacles on the whole. This work utilizes wireless sensors
to design and implement a sensor network in order to assist
users in planning a best evacuation route while there is an
interior fire.
Keywords: sensor network, implementation, evacuation
route, interior fire.
摘要
雖然現在已經有很多關於 感應裝置網路 的研究和理
論，但實際上感應裝置網路的實做卻還是不多。一般
來說，相較於理論，實做往往會遇到較多的困難與問
題。而這篇論文利用了無線感應裝置來設計並實做出
一個感應裝置網路來幫助使用者在火場中找出最佳逃
生路徑。
關鍵詞：感應裝置網路、實做、逃生路徑、火場。
I. Introduction
In this high-tech century, buildings like shopping malls and
department stores, office buildings and schools not only
are all designed as big as possible but also have complex
interior design in order to provide more space and
integrated functions. As a result, when it comes to fire,
how to derive a best emergency evacuation route according
to fire condition plays a crucial role. Instead of looking up
an emergency exit map attached on the wall, this study
utilizes TAROKO wireless sensors to design and
implement a sensor network which can assist users in
planning a best evacuation route dynamically.
A recent work of distributed navigation algorithms [1]
has proposed efficient distributed algorithms to aid
navigation of a user through a geographic area covered by
sensors. Although it introduced the concept of a skeleton
graph which is a sparse subset of the true sensor network
communication graph to reduce the communication
Copyright © 2008 NTU CSIE. All rights reserved.
expense, these kinds of algorithm are still too complex
under the hardware constraints. Besides, the method of
locating the position is not appropriate in interior situation.
Therefore, our work focuses on an implementation of a
small scale sensor network; that is, we utilize simple
algorithms and deploy only 50 sensors.
To begin with, we program our sensors to record the
temperature of each part of the building and establish
reliable communication between these sensors so that each
sensor can attain the temperature of all spots. And we
deploy these well-designed sensors on the first floor of our
department building. This deployment hinges on the degree
of uniform and interior design as well; therefore, the
sensors can also represent points on all routes, namely,
passages and rooms. In addition, our system does not have
a center server due to the issue of robustness, that is,
unreliability of this server in fire. So the users’ hand-held
devices such as PDA and laptops should attach an
additional sensor through USB port to request and acquire
information from sensors in the building. This special
attached sensor is identified as a sink. To fulfill the
communication between the two kinds of sensors, we
design and implement an appropriate protocol. Last but not
least, the attained information is transmitted to an
application program which is installed on the user device
and coded in Java by USB port periodically. Thus the
application program can utilize this information of
temperature and a built-in map to obtain a best evacuation
route.
II. Design Issue
Since this system is applied to the fire scene which is under
a high temperature condition at least 1000 Celsius, the
design issues should cover various factors in comparison
with other places.
Correctness
There are various fatal factors in the fire scene such as CO,
flames and high temperature; however, under hardware
constraint, we only evaluate temperature to decide whether
a spot is safe or dangerous.
Robustness
To enhance the degree of robustness, we adopt the
structure of distributed system because of the unreliability
of a center server in the fire scene. That is, every
background sensor acts as a server, storing whole data
which is requested by user. And the process of calculation
of the evacuation route is done in the hand-held device of
user.
Last but not least, the user device takes responsibility of
deriving a best evacuation route. It utilizes some simple
algorithm to accomplish this purpose.
The background sensors and the sink are coded in nesC
language while the path planner on the user device is coded
in Java language. Figure 1 shows the system structure
clearly.
The Ability to present the Outcome Easily
The outcome of a best evacuation route is printed on the
screen of a hand-held device such as a PDA and a laptop.
And the route is painted on a building plan.
Immediateness
According to the experiences, people only have about one
minute to escape when there is a fire. As a result, how to
seize the time to escape becomes a crucial issue. In order to
save time, the background sensors collect data which users
require from other sensors previously. While a user
requests data, the background sensors can transmit the data
immediately. What is more, the system includes two states,
that is, safe state and dangerous state. When the system is
in dangerous state, all background sensors push data
voluntarily instead of waiting for the request; therefore,
this mechanism which includes both push model and pull
model further enhances the immediateness.
Power Consumption
Although power saving is not the first priority in the fire
scene, we still take this issue into consideration in
peacetime. To save power, all background sensors
exchange data only when their own temperature alters.
III. System Structure
Our system is divided into three partitions. They are
background sensor, sink and user device. Additionally,
there are three corresponding modules called monitor
module, sink module and path planner module that are
installed on the three partitions.
First of all, the background sensors are responsible for
detecting temperature and maintaining the newest copies of
temperature of all background sensors; thus, these
background sensors have their own protocol to exchange
information. And while being requested from a sink or in
dangerous state, they can transmit the whole data to the
sink.
Second, the sink plays a role as a bridge between the
background sensors and the user device. It periodically
sends request out, receiving data and passing it to the user
device.
Figure 1. The system structure diagram.
IV. State Diagram
In order to satisfy the purposes of immediateness and
power saving, every background sensor has two states,
namely, the safe state and the dangerous state as shown in
figure 2. In the safe state, the background sensor just waits
for requests. When the temperature it detects exceeds a
threshold or other background sensors notify it that some
other sensors detect a dangerous temperature then it enters
the dangerous state. And if all the background sensors are
in safe states, it again returns to the safe state.
Additionally, while the background sensors are in
dangerous states, they broadcast out data in a faster period
to force user receive this information.
Figure 2. The state diagram of background sensors.
As a result, this crucial mechanism switches the system
between pull model and push model according to the states;
therefore, it can fulfill the design issues of immediateness
and power saving at the same time.
On the other hand, the state of the sink is much easier.
The sink periodically sends out request as shown in figure
3. This period is much bigger than the period used by the
background sensors in push model. While receiving data, if
the data indicates that some background sensors are in
dangerous states then the sink may notify the user with a
warning.
information of the building or floor. Since the origin
format of function Dissemination loads at most 16 bits data
and is not sufficient enough, this work modifies it to
contain 32 bits. The packet is as shown in figure 4.
Figure 4. This is the packet format which is used in the
communications between background sensors.
Figure 3. The state diagram of the sink.
V. Implementation
Since the system is divided into three partitions, including
the background sensors, the sink and the user device, the
implementation is also divided into the corresponding three
modules, that is to say, the monitor module, the sink
module and the path planner module as shown in figure 1.
Sensor ID is the assigned number of source sensor which
broadcasts this message. While one other background
sensor receives this packet, it re-broadcasts the packet to
further background sensors so that all background sensors
can receive this message eventually. Sequence number is
here to prevent the system from infinite flooding of packet,
the source sensor maintains a counter, and the value of
counter increases by 1 whenever one packet is delivered.
Therefore, sequence number can be an index for
background sensors to distinguish new message from old
one, and the sensor determines whether it should rebroadcast the packet.
Sink module
Monitor module
Once the background sensors are distributed appropriately,
the oncoming issue is how to deliver the information - the
state of all background sensors - from one background
sensor to the next. A timer is used to trigger the
temperature chip of sensor, and read the current
temperature every 500 millisecond in the monitor module.
If the temperature sensor detects is higher than 45 degree
centigrade, it is assumed that the area this sensor locates is
in danger, therefore the state bit of this sensor is set to
1;Otherwise, if the temperature is lower than 45 degree, the
state bit is set to 0. Every background sensor maintains a
state table, which contains the states of all background
sensors scattered on the same floor and is initiated with the
value 0. Here are another parameter each monitor module
maintains called Change_Bit, if the state alters from 0 to 1
or from 1 to 0, the Change_Bit is set to 1. Once
Change_Bit is set to 1, the background sensor broadcasts
the state table to all the other background sensors every
500 millisecond. And a function called “Dissemination”
[2], which is a reliable transmission protocol provided by
TinyOS system, is used to delivers the data. The main idea
is, while one background sensor is in dangerous area, all
other background sensors should “know” this situation so
that wherever the sink is located, it can receive the latest
In TinyOS 2.0, there is a basic utility application called
basestation [3] which acts as a bridge between the serial
port and radio network. When it receives a packet from the
serial port, it transmits it on the radio; when it receives a
packet over the radio, it transmits it to the serial port.
Fortunately, the latter function of this basestation is
appropriate to accomplish our task of transmitting received
temperature data to the path planner module. So we modify
this version of basestation directly.
First of all, in order to reduce the traffic of packets in the
sensor network, we design a three-way handshake protocol
to retrieve data from the monitor module to the sink
module. Our sink module broadcasts out request packets
by utilizing dissemination provided by TinyOS in a period
of 30 seconds. And all the background sensors that receive
this request answer the sink by broadcasting back a packet
which specifies the IDs of the requesting sink and
themselves. Then while the sink receives the second way
packets, it chooses one of these candidates of background
sensors and sends it a third way packet in order to notify
that background sensor that it can transmit the temperature
data to the sink now. What is more, if the background
sensors are in dangerous states, the sink may be forced to
receive temperature data continuously because the
background sensors are in push model and may broadcast
out these packets in a period of 5 seconds during dangerous
states.
For the sake of the above functions, we design an
appropriate format of packet and modify the dissemination
utility application to support a bigger packet, namely, 32bit packet. In this way, we can transmit the temperature
data of 50 background sensors in just two packets since
each temperature costs one bit to represent the two kinds of
states.
Figure 5 and figure 6 illustrate the formats of packets.
There are two kinds of formats.
Figure 5. This is the packet format used in the
communication between background sensors and sink
when type is 5 to 7.
The packet type varies from value 3 to value 9. The
packets numbered with 3, 4, 8 and 9 contain temperature
data. The definition of packet type is specified as follows:
•Type 3: The push model data packet number 1
•Type 4: The push model data packet number 2
•Type 5: The 1st way handshake packet
•Type 6: The 2nd way handshake packet
•Type 7: The 3rd way handshake packet
•Type 8: The 4th way data packet number 1
•Type 9: The 4th way data packet number 2
Path planner module
After collecting information from background sensors
through sink, it is the responsibility of the path planner
module to calculate a safest evacuation route. In order to
simplify the problem, this study derives a simple algorithm
to accomplish the purpose.
Let cost be the time spent by the user to escape from the
fire scene, our evaluating issues of the best evacuation
route are as follows:
•Cost less: The best evacuation route should cost less to
ensure that the user can escape from the fire scene.
•Fire-free: The best evacuation route should be fire-free
to ensure the safety of the user.
The cost can be derived in advance by measuring the
length of all edges between all nodes, namely, background
sensors. The length is divided by the human walking
velocity to obtain the time spent so that we can simply use
it in the next part. To ensure the best evacuation route to
cost less, we utilize shortest path algorithm to derive route
from the location of user to all exits. One advantage of
using shortest path algorithm is that the algorithm
guarantees that it can derive a solution, if there is any. Here
we use Dijkstra's shortest path algorithm as shown in
figure 7.
Figure 6. This is the packet format used in the
communication between background sensors and sink
when type is 3, 4, 8, and 9.
Figure 7. This is the Dijkstra’s shortest path algorithm.
Besides finding all paths from the location of the user to
all exits, we use BFS with limited depth to find some
redundant paths because these paths may be useful or
better than the shortest path due to safety consideration.
For example, a path with low cost but higher risk may not
be better than the path with higher cost but lower risk. The
limited depth of BFS is given as D  (1  m) , where D is
the maximum cost of all shortest paths from the location of
the user to exits. System parameter m is defined by
ourselves and relies on the computing capability of the
hand-held device. It can be obtained from experiments.
Additionally, in order to obtain the fire-free path, we
derive that Exponential Distribution is appropriate to
estimate the degree of danger. Exponential Distribution is
helpful when considering time cost and safety
simultaneously.
Given an exponential process:
that the user succeeds to escape through the path is:
P  1[1  F (t1; 2 )] [1  F (t1  t2 ; 3 )]  ...... [1  F (t1  t2  .......  tn1; n )]
 P  e  2t1  e  3 (t1 t2 )  ......  e  n (t1 t2 ...... tn )
And let
P1 , P2 ......Pl be the probability of the paths
derived by shortest path algorithm and limited depth BFS,
the best fire-free path with maximum P can be obtained
by:
P   max( P1 , P2 ......Pl )
Figure 9 is the pseudo code of our algorithm. And figure
10.1, 10.2 and 10.3 are diagrams that explain this
algorithm step by step.
F (t;  )  1  et , t  0
Function F denotes the probability that a node changes its
state from safe to dangerous, where  is the inverse of the
mean time of nodes to change from safe to dangerous,
which is estimated according to experiments and the state
of a node as shown in figure 8.
Figure 9. The pseudo code of our algorithm.
Figure 8. The curve of fire temperature and
.
Since the cost of every edge is estimated previously, the
degree of danger can be estimated. Given a path with n
nodes and let
t1 , t 2 ......t n 1 be the costs of the edges and
1 , 2 ......n
be the inverses of the mean time that the
nodes change from safe to dangerous state, the probability
Figure 10.1. L is the current location of the user. E1, E2,
E3, and E4 are the exits. The algorithm derives p1, p2,
p3, and p4, which are the shortest paths from L to E1,
E2, E3, and E4.
Figure 10.2. The algorithm utilizes limited depth BFS to
find the redundant paths from L to the exits.
Figure 11. The structure of a TAROKO sensor.
Figure 12. The floor plan of the department of CSIE.
VII. Experimental Result
Figure 10.3. The algorithm returns the path with
maximum success probability to the user to escape.
VI. Experimental Environment
The outcome presented on the screen of the user device is
as shown in figure 13. We simulate fire by using hair-dryer
to blow some of our deployed background sensors in order
to increase the temperature there. And the system seems
like that it works well. We use a hair-dryer to heat a
background sensor which is already on the current best
evacuation path, and the best path changes immediately in
order to avoid that dangerous node. The more detailed
demonstration
can
be
found
at
http://www.csie.ntu.edu.tw/~b93070/Something/DEMO.w
mv.
This study uses TAROKO sensors with TinyOS 2.0 as
shown in figure 11. TAROKO sensors are based on Telosb
which is developed by UC Berkeley. TAROKO are low
power, programmable and able to utilize IEEE 802.15.4 to
communicate with each other. The interior transmission
distance is up to 50 meters. And they also have USB
interface to communicate with computers. While not
attaching to a computer, they require two AA batteries to
support power, namely, 3.3 voltages.
In addition, the environment where we deploy our
sensors in is the first floor of department building of
Computer Science and Information Engineering of
National Taiwan University as shown in figure 12. It
contains 13 classrooms, 3 restrooms and 6 exits.
Figure 13. The best evacuation route is presented in the
GUI.
VIII. Discussion
During the processes of design and implementation, we
confront many obstacles. While some of the obstacles are
resolved, some other ones still remain corrigible. The
followings are the hindrance we confront and some ideas
we think of.
First, although we modify the TinyOS utility application
dissemination to establish a reliable communication, it has
its shortcomings, that is, the packet size is limited to 32
bits. In order to contain more detailed information of
temperature, maybe we can design another protocol to
replace dissemination.
Second, because of the limited scale of our experimental
environment, locating the position of the sink sensor
becomes difficult. Due to the high density of background
sensors, usually more than one background sensors can
access one sink; thus, the verification of the location of the
sink becomes vague.
What is more, we utilize temperature to measure the
degree of danger; however, it may not be accurate. Imagine
a situation that a passage is stocked by the collapse of the
building but the temperature is in safe state. This passage
should not be planned in the evacuation route. We have
come up with an idea. We can deploy two sensors of
infrared rays at two ends of a passage. Then we can infer
that the passage is stock if the sensors can not detect each
other.
Some of the above ideas are realistic and interesting.
Maybe we can extend this work to a better one by
implementing those ideas in the future.
References
[1] Chiranjeeb Buragohain, Divyakant Agrawal and
Subhash Suri, “Distributed navigation algorithms for
sensor networks,” 2006.
[2] TinyOS utility application Dissemination.
http://docs.tinyos.net/index.php/Main_Page
[3] TinyOS utility application basestation.
http://docs.tinyos.net/index.php/Main_Page