Disaster Detection System using Wireless Sensor Networks

Alex Haun, Kerry Rice, Andrew Skinner University of Tennessee, Knoxville ahaun2@utk.edu, jrice4@utk.edu, askinne2@utk.edu

Abstract
With growing populations and increasing population densities of land in the modern word, it is becoming increasingly more important to gain protection over those things which threaten our livelihood. As technology swiftly progresses, the practices used in preventing or warning of impending danger should take advantage of the seemingly infinite applications of new and advancing technology. One such application relies on the use of wireless sensor networks to detect and transmit information about the occurrence of an event in the environment. This project seeks to provide an implementation of such a network that is able to detect earthquake, floods, and tornados. The events are detected by sensors in the field, transmitted wirelessly to a central base station, and displayed to an observer via a graphical user interface.

Figure 1: Moteiv Tmote Invent

1. Introduction
In the spring of 2008, a unique and exciting challenge was presented to our design team. In general, the task was to design a system project using a sensor network, to develop and integrate the software and hardware, perform experiments on real systems, and demonstrate the results to an audience of peers. The main purpose of the project was to gain knowledge, experience, and insight in the field of embedded systems using primarily wireless sensor networks. The sensors used in the network were the Moteiv Tmote Invent sensor motes (Figure 1), which boast a wide variety of sensors applicable to many different applications. The secondary purpose of the project was to come up with a creative application of wireless sensor networks influenced by current societal wants or needs. The design team decided to create a disaster detection system of sorts, utilizing the various features of the Tmote Invent sensor mote. The Tmote provides several sensors onboard, including light, temperature, acceleration, and sound sensors, which can be used in conjunction with the many communications features to monitor the environment.

The detection system was proposed to detect disasters such as earthquakes, floods, and tornados. In order to detect an earthquake, the system uses the mote accelerometers to detect lateral and vertical movements that seismic activity would generate. The photo sensor of the mote was used in addition to external hardware sensors for sensing flood and wind disasters. Several individual motes were deployed to collect data and indicate the occurrence of a disaster event. As the data were collected by the motes, the information was transmitted over a single-hop network to a base station mote (which was connected to a PC). In order to process the data and display the results to a user in a very useful way, a graphical user interface (GUI) was proposed. The proposed interface required the ability to acquire the data, separate and process the data, and display it to the user in real-time. Being part of a disaster detection system, the interface also required the ability to indicate to the user the occurrence of a potentially deadly event (such as an earthquake) using visual cues. In order to rapidly design and test the user interface, the Microsoft Visual C++ environment was used. The proposed goals of the project are summarized as follows: Implement earthquake detection Build a small scale model for testing earthquake detection Implement light intensity detection (used with the flood sensor and wind sensor)

Build external sensors to detect flood levels and wind speed Implement multi-hop communication Implement real-time data acquisition Design warning system GUI

2. System Architecture
2.1 Overview

The disaster detection system consists of two system architectures working in concert: hardware and software. The hardware architectures consist of the Tmote Invent sensor motes and a custom flood sensor circuit. The hardware architecture of the sensor motes was designed and implemented by the manufacturer. Communication with the mote hardware is provided via software and TinyOS, therefore the specific hardware architecture of the Tmote Invent is not discussed here. The custom flood sensor circuit created for this project is discussed in this section, along with the software architecture designed to implement each detection system component. The software system consists of sensor software, hopper software, base station software, and the graphical user interface. The sensor software consists of four separate programs, each designed to read a single Tmote sensor in the context of a specific disaster event. Earthquake detection uses the x- and y-direction accelerometers, while flood and tornado detection both use the light sensor with external sensor circuitry. The detection network consists of several motes placed throughout the environment. Each mote was programmed to read a specific sensor, packet the sensor data, and transmit the data as fast as possible. The transmitted packets are picked up and re-transmitted by hopper motes. A base station mote receives the data from the hopper motes and transmits it to a PC via a serial port. Finally, the graphical user interface receives the data from the serial port, processes the data, and displays it to the user.

providing simulated earthquake signals that could be measured using a mote placed inside the house. The earthquake detection software consists of two versions and was designed to read the accelerometer on the Tmote Invent so that the data could be transmitted, processed, and displayed in a useful manner. The two versions of the software are essentially identical, the only difference being the sensor used (x or y) and the corresponding state variable (which is used by the GUI to display the data). The software is based upon the Oscilloscope application provided with the Tmotes, which is capable of sensing and displaying temperature, voltage, light intensity, and two-dimensional motion. The earthquake detection programs have been optimized to use only the necessary components: the accelerometer and the radio. The software periodically reads the accelerometer, packets the data, and transmits the data packet to other motes via the radio. In order to provide sensor readings faster and more efficiently, no processing of data is performed on the motes. Listing 1 shows the pseudo-code for the earthquake detection motes. Settimerfor100ms; State=X|Y; When_timer_fires{ data=gather_data(X|Y_sensor); } When_data_ready{ send_to_base(state,data); display_on_leds(data); }
Listing 1: Pseudo-code for earthquake detection

2.3

Flood Detection

2.2

Earthquake Detection

The initial goal of the disaster detection system project was to create a simulation environment capable of simulating simple seismic activity and implementing software capable of detecting the seismic activity. The environment was based upon a simple model of an ordinary living arrangement, such as an apartment complex or dormitory building. The design consisted of a small-scale, two story building constructed of foam board. The building was placed on a low-friction surface that allowed the building to be easily shaken and moved,

The flood detection system consists of custom external hardware sensors, as well as Tmote software designed to read the external sensors, packet the data, and transmit the data in much the same way as the earthquake software. The following subsections discuss both the hardware and software components of the flood detection system. 2.3.1 Hardware

The hardware component of the flood detection system consists of a custom flood sensing circuit. The circuit was designed such that when a probe is entered into a volume of water (the first level) a circuit connection is closed, sending a signal to the main logic of the circuit, whereupon a light emitting diode (LED) is turned on. If the water level increases (and a second

embedded probe comes into contact with water at the second level) a second signal is sent to the main logic. The second signal corresponds to a very high water level (the difference between the two water levels is about four inches) and triggers a relay that sets off another LED. The relay holds the alarm signal for a period time before releasing the alarm, thus preventing successive triggers from turbulent water. Figure 2 shows the flood sensor circuit.

Tmote. Listing 2 shows the pseudo-code for the water detection mote. Settimerfor100ms; State=flood; When_timer_fires{ data=gather_data(photo); } When_data_ready{ send_to_base(state,data); }
Listing 2: Pseudo-code for flood detection

2.4

Tornado Detection

Figure 2: Flood detection circuit indicating water level 2.

The flood detection circuit provides three levels of light intensity (off, level 1, and level 2) which can be detected by a Tmote using the built-in light intensity sensor. In order to minimize false readings due to ambient light, a custom enclosure was created to house the flood detection circuit and a Tmote Invent. Figure 3 shows the completed flood sensor and enclosure.

The tornado detection system was initially intended to consist of an external sensor circuit to be used in conjunction with a Tmote, similar to the flood detection system. The circuit was to be similar to a wind-powered generator, in that the presence of wind would rotate a turbine, providing power to a circuit, which in turn could be measured by a Tmote. However, due to budget constraints, a viable wind generator circuit could neither be purchased nor constructed. One problem with using a real wind-generator circuit is that real wind must be generated before the circuit can produce a signal measurable by the Tmote. Therefore a suitable simulation alternative was sought. The solution was found in an inexpensive forever flashlight. The flashlight uses no batteries and works by providing a lever arm which can be rotated by the user to provide power to the LEDs, behaving almost exactly as desired for our disaster system- a slow rotation corresponds to light winds and provides little light, whereas a fast rotation corresponds to strong winds and provides more light. The varying light intensities provides by the flashlight can be measured using a Tmote configured similarly to the flood detection mote. The tornado detection software is nearly identical to the flood detection software, with the difference being in the state variable. Listing 3 shows the pseudo-code for the tornado software.

Figure 3: Flood detection circuit inside the enclosure.

2.3.2

Software

The flood detection software is a very simple program that periodically reads the Tmotes built-in photo sensor, and transmits the reading over the network. Similar to the earthquake software, no processing (or scaling) of the flood sensor data is performed on the

Settimerfor100ms; State=wind; When_timer_fires{ data=gather_data(photo); } When_data_ready{ send_to_base(state,data); }

program included all of the functionality required for this project, and therefore no modifications were necessary.

2.7

User Interface

2.5

Hopper Communication

A real-world deployment of a disaster detection system would seek to be a preventative measure for some nearby population. The goal of the system would be to measure an event as soon as it occurs and send the data to an observer before the event reaches the observer, thus providing an early warning. While the wireless sensor motes used in this project have a fairly large range of over one hundred feet, the range is very limited in the context of a disaster detection system. Successful early warning signals may need to travel several miles to the observer (rather than several feet). Therefore, we needed a solution capable of transmitting measured data to a location vastly outside of the native range of the mote. The solution we used is a multi-hop network. Multi-hop networks work as follows: a mote A generates a message to be sent to another mote Z that lies outside of the broadcast range of A. A transmits its message and another mote B receives the message. Since the message is not destined for B, B retransmits the message. Our project works by having the sensor motes send data to the hopper mote, which in turn sends the data to the base station mote. This approach simulates a multihop network.

The user interface is the largest component of the project. The program obtains data from the base station mote, processes the data, and displays the data to an observer. While the source code of the interface is rather lengthy, the architecture is rather simple. The software is event-driven, relying on events and timers to determine the execution path of the program (examples are mouse clicks and alarm timers). Other than basic user interface functionality that is expected from GUI users, there are three basic events handled by the interface: 1) data is available to be read, 2) an alarm timer has fired, and 3) a reset signal has been received. The interface can receive data in one of two ways: by reading the serial port, or by reading a recording of a previous experiment. As data becomes available, the interface reads the next message from the source and prepares it for processing. The data processing task consists of five main steps: 1) extract the data type from the message, 2) extract the data from the message, 3) convert the data to a numerical level value, 4) display the data on the interface, and 5) if the level value crosses some threshold, start an alarm timer to indicate a warning. Messages are received as byte arrays and can be decoded so that sections of interest can be extracted. An example message is shown in Table 1. Step 1 of the data processing task checks that the message is of type 0x06. If the message is the correct type it seeks to the state section of the message and extracts the data type from the state variable. The data type indicates the type of event observed to measure the data, such as earthquake-x, earthquake-y, flood, or tornado. The type can be one of four values: 0x0001 for earthquake-x, 0x0010 for earthquake-y, 0x0011 for flood, and 0x0000 for tornado.
06 Msg type 04 7D Not used Example Message Packet 01 08 00 Not used Counter 00 01 00 00 State Data Table 1: Example message packet FF FF FF FF Not used 00 02 Source

2.6

Base Mote Communication

Communication with the base mote is important in our project. One of the main goals of the project was to not only detect and measure the occurrence of an event, but to display the event meaningfully to an observer. In order for the data to be processed and displayed, it must first be received. The base station mote receives the data coming from the network and sends the data to the PC for processing. The software for the base station mote is a program called TOSBase that is provided by Moteiv. TOSBase receives messages from the radio and forwards them to a PC via a serial connection. The PC can then read and process the data from the serial port. The TOSBase

The second step of data processing is to extract the data from the message. The data section consists of bytes 13 and 14 in the message. This value is the actual sensor reading from the Tmote and is used for the flood and tornado data types. For the earthquake data types, we dont want the actual sensor reading; instead we want the difference between the current reading and the previous reading. This difference is located in the source section of the message (bytes 15 and 16).

The third step of data processing consists of converting the data to a numerical level value. The numerical level value is used to determine how to draw the intensity level on the interface. The interface works almost exactly like an analog meter, similar to those used in audio electronics. An example of the meter display can be seen in Figure 4.

Figure 5: Detection system showing low levels for all detectable disaster types.

3. Technical Approaches
3.1
Figure 4: Detection system user interface showing the intensity level meters for each of the detectable disasters.

Disaster Detection

The final step of data processing is to display the numerical level value to the user. Each meter contains twenty possible level values. The data reading required to reach each level is different for each type of disaster since the readings come from different sources. The program simply reads the level value and lights up all of the lights below and up to the value, and turns off all lights above the value. The term lights is used here in reference to the color bands on the meters. The meter to be used for the reading is determined based upon the state variable extracted previously. If the level value is sufficient to trigger a warning alarm, the appropriate alarm is selected and the corresponding timer is started. There are two types of alarms in the system: a warning alarm that flashes in the upper right corner of the program, and a disaster alarm that flashes around the meter reading the disaster. The alarms are simple: once set, they are fired periodically by the timer. Each time the timer event is fired, the color of the alarm is switched between the alarm color and the background color, thereby producing the flashing effect. The alarms continue to flash even after the meter displays calm readings. This is due to the fact that earthquakes (and other disasters) do not tend to linger persistently; instead the disaster releases large amounts of energy in bursts that can last anywhere from fractions of a second to minutes. The alarms can be silenced by selecting the Alarms>Reset menu option. An example of the interface showing low reading levels for all disaster types can be seen in Figure 5.

We approached the technical side of the project by first determining how we were going to measure the earthquakes waves. Earthquakes tend to generate two types of waves, so we attempted to measure both of them. The Tmote Invents already have this capability using the built-in accelerometers, so we just needed to write simple code to suit our needs. The Oscilloscope program was the basis for the earthquake detection code. All of the non-essential components were removed to save power and time. The earthquake code originally switched between two states, one for the x-accelerometer and another for the yaccelerometer, allowing a single mote to measure both directions of a simulated earthquake. However, the two states were separated into two separate programs (thus requiring two motes to read both directions) for testing and validation purposes. An added benefit of splitting the code is increased time resolution in the measurements, which can help overcome the effects of dropping packets in a busy network, while a disadvantage is the requirement of an additional mote. The motes were to be deployed in an environment potentially susceptible to earthquake activity (in our case, the foam board building created for the experiments). Once the motes were powered on and data became available, the program would send the data to the hopper mote, which would in turn send the data to the base station mote. The detection of floods and tornados are very similar in our system. Both floods and tornados are detected with external hardware circuitry, which in the presence of an event turn on a series of LEDs. The light intensity of the LEDs is measured by the flood and tornado motes using the built-in photo sensor. In order to display the data meaningfully to an observer, the data must be sent to a PC some distance away from the sensor motes. In order to accomplish this, we simulated a multi-hop network. A multi-hop network

is a wide system of motes that can communicate with each other, and send on information to the base station by means of the fastest communication. Figure 3 shows how a multi-hop system works in an ideal situation. The brown boxes indicate motes in our network, with the ones closest to the events monitoring the system. The other motes are used only to send information to our base station.

Figure 6: Multi-Hop Network

Since we did not have access to as many motes as this picture represents, we had to simulate a multi-hop system as best we could. We used a hopper mote for our system to simulate the multi-hop. This hopper mote was placed between the base station and the event motes and its only job was to receive and send information. It would receive the data from the event motes and transmit the data to our base station. A specific routing table was used for the multi-hop system so that when other hopper motes are added to the system it is easily expandable for other motes. These motes would also have specific routing tables to send the packets to the base station as quickly as possible.

3.2

Disaster Display

issues nearly prevented this from occurring. Some of the most difficult issues encountered included: reading from the base mote via serial port, writing to the base mote via serial port (for handshaking), and correctly receiving and interpreting the data from the base mote. These issues were particularly troublesome in that the Visual Studio platform had much difficulty in communicating with software running on Cygwin (even through a standard serial interface). Many times packets could be received, only to be unreadable. In the few cases where packets were readable, they often contained different values than expected. In order to fix this problem initially so that the GUI could be created, tested, and calibrated, a mechanism for playing previously recorded runs was implemented. The runs were created by reading the data from the serial port and storing the data in a file. The file was then loaded into the detection program and was read as if in real-time. This ability provided very helpful as an experiment could be generated with known disaster level values and could subsequently be played back on the GUI to validate the display of the data. Near the end of the project, it was discovered that one of the issues concerning real-time communication with the base station mote was the required use of handshaking to receive data. Handshaking is a technique used to synchronize devices intending to communicate with each other. The Tmotes send a byte to the receiving device which is in turn supposed to reply with the same byte. While this seems rather simple, it is very difficult to implement in Visual Studio and the TinyOS community has provided little, if any, documentation on the communications protocols used by the Tmote Invent sensor motes. In order to correctly decode the data received at the base station, each disaster type had to be isolated, and each packet had to be analyzed to discover the relevant information. The resulting structure of the message packets used in our project were completely different than the documented message packets, which further increased the difficulty of communication. Therefore, the real-time capability of the disaster detection GUI was not fully implemented.

The ability to detect disaster is of no use if one cannot display the data relating to the disaster meaningfully. In order to display our data measurements, we decide to build a disaster detection graphical user interface program. The user interface was designed to show the mote readings for each of the four detectable disaster types (earthquake x and y, floods, and tornados). The system uses a series of meters similar to analog electronic meters, such as those found in audio equipment. The original intent of the user interface was to be able to acquire data from the Tmote network in real-time via the base station mote. However, several technical

4. Experiments
4.1 Earthquake Detection

4.1.1 Setup To setup for the earthquake detection, it was just bringing together all of our motes and materials. The constructed apartment building was placed with motes inside different rooms in the apartment. These motes were programmed with our earthquake detection software to read the x/y waves of our simulated earthquake. The hopper mote was placed between the event motes and the

base station and loaded with the hopper program. Our base station mote was programmed with the Oscilloscope Java applet that can display the waves in real time and save the data for later use. Once the disaster GUI was added, the need for the Java app was no longer there. Once everything was in place we started to shake the house in the x/y directions to simulate our earthquake. The resulting waves were then transmitted through the hopper to the base station and displayed on the base station GUI applications. The data was then either saved through the Java app for later processing or just displayed on the disaster GUI. 4.1.2 Results and Analysis Since we are observing two different types of waves there are two sets of data used in the results, the x and y waves. Our first experiments involved using the Oscilloscope Java app which can be seen in Figure 7. This figure shows the resulting wave the base station received from our hopper mote, which was received from the sensor motes in the building. The resulting data was then saved using the functionality provided with the applet, and stored away for later processing.

Figure 8: Raw Data taken from Oscilloscope App

Figure 9: Matlab Processing Earthquake Data Figure 7: Oscilloscope Applet receiving Earthquake

During our first experiments our disaster GUI was not available so we used MATLAB to help analyze our results. To do this we had the saved files of data from our earlier runs ready to analyze. Since this is a disaster system, we need to be able to characterize when the person needs to be warned when the waves become too strong. Our MATLAB program reads in the text files and compares the values to three different wave values. If the value reaches the threshold a warning message is printed to the user to warn them of the disaster. Once the disaster GUI was implemented the GUI itself could sound an alarm if the disaster level was too high. In this way the user can stay informed of the disasters severity. Figure 8 shows some example data recorded by our Java applet and Figure 9 shows the MATLAB program analyzing our results.

The earthquake detection system had two different ways of analyzing the results: MATLAB and the detection GUI. The MATLAB program was not real time but was used to analyze the results more thoroughly, allowing us to determine the threshold values for use in the GUI. MATLAB was useful in determining the parameters for the GUI, but is not very useful as a display system, whereas the GUI elegantly displays the disaster measurements to the user. Once the earthquake detection was taken care of the water and wind sensors were put to the test.

4.2

Wind and Water Detection

4.2.1 Setup The setup of the wind and water detection experiment was very simple. A glass of water was used to simulate

flooding and a forever flashlight was used to simulate high-speed winds. The flood detection circuit contains a probe which can be lowered into the glass of water. The probe can detect three levels of water: none, low, or high. Each water level corresponds to an increasing intensity of light created by the circuit LEDs. The light intensity is then measured by a Tmote and transmitted to the base station. The wind detection setup is almost identical to the water setup. The flashlight lever is spun to simulate wind, which in turn generates an amount of power that is used to the power a series of LEDs. The intensity of the LEDs is directly related to the intensity of the wind. A Tmote is used to measure the light intensity from the flashlight.

designed became apparent: using single base station mote limits the number of sensor motes that can be used (and read in real-time). In order for the base mote to read and transmit to the PC in real-time, it must first receive data, then transmit the data over the serial port. This sequence of events takes time, of which only so much is available to meet real-time requirements. In the presence of more than four sensor motes (assuming a single hopper is used and is retransmitting data packets as fast as it can receive them) some packets may be lost. One solution to compress multiple mote messages into a single message at the hopper (although this introduces additional lag at the hopper). Another solution would be to allow single sensor motes to read multiple sensors and send the readings in a single packet.

4.2.2 Results and Analysis The sensor motes works exactly as expected for the experiment, as we had prior experience with reading the photo sensor from a previous lab assignment. The results of the experiment were used to calibrate the meter levels such that the deepest detectable water level indicated a severe flood and the strongest generatable wind level indicated a sever tornado. The calibrations allowed the detection GUI to correctly display the simulated disaster.

4.3

Full Disaster
Figure 10: Interface showing alarms for several detected disasters.

4.3.1 Setup The final experiment involved a full-on disaster. Each of the four disaster types were used, with each being triggered at different times. The purpose of this experiment was to simulate a worst-case scenario for our program. The disaster scenario happened as follows: a severe storm caused a flood, then a tornado, and finally a series of earthquakes occurred. This experiment required four motes to be configured as sensor motes, one mote to be configured as the hopper, and one mote to be configured as the base station mote. Each team member was assigned a different disaster type to simulate. The PC was setup to record and display the disaster in the GUI.

5. Conclusions
The disaster detection system turned out to be a very interesting project, providing experience in developing embedded systems, integrating the system into a larger system, and understanding the impact of design choices on performance, complexity, and safety. Several of our design choices were made to simplify the process of building and testing our system. Analysis of the test results indicated that some of those decisions may have adversely affected the performance and safety our system. In the case of performance, the choice to limit each mote to detect only one type of disaster places an artificial limit on the number of sensor motes that can be used with a single hopper and base. This limit did not directly affect the results of our tests and simulation as designed, but it can be seen that a larger system may suffer from slower response times and dropped packets, both of which may decrease the safety of the system. As an example, consider the case when a system saturated with sensor motes is subjected to an earthquake. If the data packets

4.3.2 Results and Analysis The results of this experiment were displayed very well by the GUI. As expected, the water level rose to severe levels, setting off the flood alarm. Next, the wind speed picked up setting off the tornado alarm, and finally the earthquakes began, setting off the earthquake alarms. Figure 10 shows the disaster detection GUI during this experiment. While the display system showed the results much as we expected, one limitation of our system as

that are to indicate the occurrence of the earthquake are dropped due to congestion in the network, the signal may never reach the base station and the user may never know. As an early warning system, our system might fail miserably in this case. However, with the knowledge and experience we have gained with this project, we feel that our project can be improved in the following ways: 1) we can allow single motes to detect several disasters, compression all of the readings into a single message packet, 2) the hopper mote would then be able to transfer data from more than four motes in real-time, 3) the realtime serial communications issues are now known and understood, so making the interface more capable of realtime data acquisition is only reliant on additional time, 4) the use of additional hopper motes with more advanced transmission algorithms could easily scale the system to a more realistic size. Overall we feel our project was a great success and showed that the use of the Tmote Invent is not limited to the Cygwin/Linux platform and can be used in a more versatile and user-friendly system to measure and display sensor data.