Active Disaster Response System for a Smart Building

2.1. Disaster Warning System

Disaster warning systems are used to broadcast warning messages to the public and, thus, warn people of imminent disasters. Sing et al. [7] developed a seismic early warning alert system that can forewarn an urban area of a forthcoming strong quake, so that people could take appropriate actions and respond to that situation effectively. Rahman et al. [8] developed a warning system, named OpenStreetMap (OSM), which provides a specific service to notify people about warning information and to help them determine the shortest path for evacuation. Wijesinghe et al. [9] utilized GSM information to build a disaster early warning network and adopted the network to deliver warning messages. When the proposed disaster warning system receives alert messages from the warning network, it will make a loud noise, turn on warning lights and broadcast messages to notify people. Azmi et al. [10] proposed a disaster emergency warning system based on the DVB-T (Digital Video Broadcasting-Terrestrial) standard. Adam et al. [11] and Chu et al. [12,13] used social media, such as Twitter and Facebook, to collect disaster information. Based on the collected information, they then broadcasted warning messages to registered users through smart phones. Although these warning systems can send alerts to the public, none of them adopted CAP standards for encoding alert messages. Because their warning messages are not machine-readable, these warning systems are incompatible with smart devices to take appropriate actions to keep people away from potential danger. ADRS is a further extension of our previous research on cyber-physical elements of a disaster-prepared smart environment [14,15]. Compared to our previous work, this paper mainly focuses on the design and implementation of a proof of concept prototype to automatically perform emergency tasks when an earthquake happens.

2.2. Disaster Surveillance System

In order to collect disaster information promptly, some research efforts have been devoted to developing disaster surveillance systems. Di Martino et al. [16] utilized radar monitoring of geographic information to assess the damage of a natural disaster to support a rescue decision. Lu et al. [17] adopted virtual human resources (VHR) to get ground information and to evaluate the damage of collapsed buildings. However, their system cannot collect the information about trapped victims inside a building. Similarly, Post et al. [18] used Earth observation and modeling technologies to monitor disaster damages. Although their system estimates the threatened areas of some natural disasters, such as landslide or flooding, it cannot provide detailed information on the affected people. In short, all of the above methods cannot provide detailed information about victims trapped inside a building. In order to address this problem, ADRS utilizes embedded controllers to maintain a temporary network, as stated earlier. Based on our design, victims can post an emergency message to an embedded controller through a one-hop network. Therefore, they have a good chance of being found in the one-hop transmission range.

2.3. Disaster Information Collection

Some crowdsourcing strategies have been developed to collect disaster information. Vivacqua et al. [19] proposed a collective intelligence technique to manage disaster information. Yin et al. [20,21] first utilized social media to quickly gather information about disaster situations from people close to threatened areas. They then used the collected information to help relief workers to conduct rescue actions. Shan et al. [22] and Seop et al. [23] adopted smart phones to collect disaster information. People can upload pictures, videos and text messages to a remote server to report damage to the environment. Farber et al. [24] adopted disaster portals to collect disaster messages via the Web 2.0 social network. The collected information is used to help command centers to gather disaster information rapidly. Unlike existing works, ADRS utilizes embedded controllers inside a building to maintain a temporary network for trapped victims.

3.1. Overview of ADRS

Figure 1 shows a use scenario of ADRS. When a natural disaster happens, the Central Weather Bureau (CWB) publishes CAP warning messages. The messages are received and interpreted by Tibbo embedded boards inside a building (Step 1). If a warning message indicates that a strong earthquake is coming, these components of ADRS will automatically perform emergency tasks, such as opening doors, cutting off power and gas, and so on (Step 2), in order to prevent the loss of lives, to reduce the chance of injuries and to minimize economic losses. After the earthquake, ADRS configures Tiboo EM1000-TEV embedded boards [6] to construct a temporary network (Steps 3 and 4). After the network connections to the outside world are recovered, Tibbo will deliver these messages to relief workers nearby or the server of a command center, so that rescue actions can be well planned (Steps 5 and 6).

3.2. Emergency Broadcast System

In our prototype, we designed and implemented an emergency broadcast system that simulates the Central Weather Bureau to publish warning messages. We adopt PubNub's real-time push service [25] to push warning messages to Tibbo devices and smart phones in a building. As Figure 2 shows, PubNub can deliver hundreds of thousands, even millions, of real-time messages to devices at the same time by utilizing cloud infrastructure and services. In our implementation, we used a smart phone to act as an emergency broadcast system that publishes disaster warning messages. For this, we first registered a PubNub account to get its own subscribe key and publish key. We then used the publish key and the subscribe key to publish and retrieve warning messages with PubNub APIs (Application Programming Interfaces), shown in Table 1.

Figure 3a shows the user interface of the emergency broadcast system on an Android smart phone. This mobile emergency app (application) provides key functions to publish warning message, such as publish, subscribe, unsubscribe, history records, and so on. Figure 3b shows a warning message about an earthquake received by an end user.

3.3. Active Disaster Response System

The active disaster response system consists of three key components: CAP message parser and actuators, emergency message board and emergency report system.

3.4. Prototype of ADRS and Use Scenarios

Figure 10 shows the prototype of ADRS, which consists of three parts of the Tibbo development kit. They are the input/output control lines and the Wi-Fi SPI module. Tibbo boards are used to receive warning messages published by the Central Weather Bureau and parse the XML-based format CAP messages to extract disaster information. In addition, a Wi-Fi SPI module is adopted so as to provide a wireless network function to Tibbo, which can also collect household members' messages. These messages are stored in the flash memory. Because a user can connect to a Tibbo in one hop to post emergency messages, he or she, if trapped, will be found in the transmission range of one hop, which is around 20 to 30 m. The last part of ADRS is the input/output control lines, which are used to control relay switches, so that home devices can be turned on or off and opened or closed. In our prototype, Tibbo can control alerts, doors, power, gas, etc., or even use Wi-Fi wireless networks to control devices, like personal computers, to save important data. We installed ADRS in the smart home demo room (EB208) in the CSIE (Computer Science and Information Engineering) department at National Yunlin University of Science and Technology, Taiwan.

Figure 11 shows a CAP message containing an earthquake alert delivered by the PubNub service. After receiving the warning message, ADRS converts it to a human readable version for people in the building (shown in Figure 12) and performs associated emergency tasks.

Please note that ADRS should go through a rigorous testing before it can be deployed. In order to address the issue of power failure, in our prototype, the ADRS connects to a UPS (uninterruptible power supply) that provides emergency power when the input power source fails. In addition, the electric door lock we adopted can be unlocked by remote (i.e., ADRS) or by hand. When the unlock button of the electric door is pressed, the power of the control circuit is cut, so that the remote cannot prevent the door from being opened.

We note that ADRS, in addition to earthquakes, can process alerts for other types of disasters and be extended to respond to them in and out of buildings. For example, when landslides and debris flows happen, ADRS can trigger message signs put up before tunnels and bridges to warn drivers to slow down and pull over. For flash floods, ADRS can change the traffic light to red, so that the roads can be closed. It also can turn on pumps to extract floodwater or start automatic flood barriers, to save low-lying buildings from rising water levels. For tornados, ADRS can automatically open the outside doors and vents to equalize air pressure inside and outside of a house, preventing it from exploding and also unlock each shelter door to minimize the chance of such a tragedy. For volcanic eruptions, ADRS can cooperate with microcontrollers to close all windows and doors to protect people from volcanic ash.

ADRS should be able to deal with false negatives, which are false alarms due to system errors. Because CAP messages are also posted on authenticated websites, such as NCDR in Taiwan [26], we can adopt a two-way communication to avoid false alarms induced by system software errors. ADRS, before performing emergency tasks, should use the hyperlink in the alert segment of the received CAP message to connect to the authenticated website and search for the same CAP message. If the same CAP message cannot be found, ADRS should cancel the emergency tasks to avoid false alarms. In addition, performing routine maintenance on the hardware devices is also needed to avoid possible false alarms caused by system hardware errors. ADRS also should be able to deal with false negatives when the system fails to respond. Among the solutions, one of the practical ways is to use an external watchdog timer to detect the status of ADRS. During normal operation, ADRS regularly resets the watchdog timer to prevent it from timing out. If, due to a hardware fault or program errors, ADRS fails to restart the watchdog, the timer will elapse and generate a timeout signal. The timeout signal is then used to reset ADRS or to perform predefined tasks, such as sending a warning message to the person who is in charge of the maintenance of ADRS. We consider the above mechanism used to deal with false positives and false negative as future work.

4.1. Reduction in Operation Time

According to the standard operating procedure (SOP) for earthquake responses, people who are inside a building should open doors and windows, cut off gas and turn off lights and power before evacuation [28,29]. Opening windows and doors can prevent the doors or the windows from being jammed by the large deformation caused by an earthquake and can ensure that people are not trapped inside. Another reason for leaving doors and windows open during and after an earthquake is to avoid possible fires or explosions due to a gas leakage inside the building. In addition, cutting off natural gas valves can avoid a possible fire or explosion due to a gas leakage. Furthermore, when a massive earthquake happens, fire can induce thick smoke and cause serious damage. Finally, electrical appliances or computers should be shut off or put into a safe mode in order to avoid possible flames, fire and loss of data. We designed ADRS to automatically perform these important tasks so as to help people evacuate faster and to keep their belongings from being damaged. In order to investigate the effectiveness of ADRS, we first measured the time needed to perform these tasks manually. The operation time of each task includes two parts. The first part is completion time, which is the time needed to complete the task. The second part is the response time, which is the time interval moving from the location of a control device to the location of another device. The response time represents human reaction time. In our experiment, we set the response time to one second. To measure the completion time of a task, we asked eight volunteers to manually perform the task and then found the average. Figure 13 lists the operation time of each task. For example, opening a door takes 3.87 s, opening a window 3.23 s and shutting down a computer 3.61 s. It requires a total of 18.52 s to do all of earthquake tasks manually. With the support of ADRS, all of these tasks are automatically and simultaneously finished in three seconds. As a result, ADRS can reduce the operation time by up to 15 s, which is long enough for people to get under sturdy furniture, or to evacuate from the third floor to the first floor, or to run more than 100 m.

4.2. Effect on Evacuation Time

The standard operating procedure for earthquakes also tells people to first evacuate to a safe place if they are on a lower floor [28,29]. They should stay away from buildings and trees to avoid potential injury. On the other hand, people on a higher floor should first find protection in a doorway or crouch under a desk or table. They then should evacuate to a safe place after the shaking becomes small. ADRS can play an important role in both scenarios to help people evacuate.

In this experiment, we investigated the effect of ADRS on evacuation time. We first asked several volunteers to evacuate from different floors inside a building to a safe place outside the building. The experiment was conducted at the Engineering Building V of National Yunlin University of Science and Technology, which is a four-floor building. The floor plan of each floor is similar to that of the first floor, which is shown in Figure 14. In our experiment, we repeated three rounds for each floor. For each round, we asked a volunteer to follow a certain path to evacuate from a floor to a safe place outside the building. Volunteers on the third or the fourth floor were asked to shut down a computer, open windows and an escape door. On the other hand, volunteers on the first and second floors needed to open windows and an escape door only. We measured the time taken by volunteers to evacuate from different floors and present the average time in Figure 15. We found that ADRS can reduce evacuation time from 6 to 10 s, which is long enough for faculty or students to get under sturdy furniture, or to evacuate from the second floor to the first floor, or to run more than 50 m.

4.3. Performance Evaluation of Emergency Message Board

ADRS utilizes Tiboo embedded boards to maintain a temporary network, so that victims trapped inside a building can still post emergency messages to a Tiboo embedded board when connections to the outside are disrupted. This experiment studies the effect of the number of connections on the success rate of packet transmission. The size of a message is 20 bytes, which represents a short emergency message in a real scenario. For each experiment, we repeat the transmission 100 times. The average results are shown in Figure 16. As is shown, the Tiboo embedded board can maintain a highly success rate of packet transmission. When the number of connection increases to four, the success rate slightly decreases to 94.64%. These figures indicate that ADRS can be applied to real scenarios for practical use.

In addition, we conducted an experiment to evaluate the effect of node failure on transmission time. Figure 14 shows the experimental environment, in which “A”, “B”, “C” and “D” represent the embedded boards, respectively. Each smart phone can connect to each embedded board in one hop. When a node fails, the original connection to the failure node should be rebuilt on other nodes, thus increasing the traffic on the affected nodes. Therefore, we investigated the effect of the number of connections on transmission time to simulate the scenario of node failure. The results are shown in Figure 17, in which the x-axis represents the number of connections on Node A. The more failure nodes there are, the higher the number of connections on Node A there is. Due to the sufficient network bandwidth, we found that the transmission time increases slightly when the number of connections increases. We also measure the transmission time of three different sizes of emergency message. These are 10-byte, 20-byte and 30-byte emergency messages. Our results show that the transmission time remains almost the same as long as the size of an emergency message is more than 20 bytes and the number of connections is small. For example, when the number of connections becomes two, the transmission time of a 10-byte emergency message is 3.24 s and that of a 20-byte emergency message 3.45 s. Our results also show that emergency messages can be posted to a node in 10 s in the experiments we have tested.