1. Introduction
Natural extreme events can be divided in two groups, those that can be predicted (e.g., a tsunami for which an early alert can be issued) and those that can be detected (for which it is not possible to alert the population). In any case, an evacuation plan before and after these events is necessary to mitigate further damage and diminish the impact in human life. Nowadays, hurricanes are detected several days before they hit the shore, and online monitoring of their trajectories is performed through different weather simulation systems. However, the precise instant at which they actually hit the shore line, the exact spot, and the intensity is known with just a few minutes. Floods usually follow large rains and they can be predicted; however, large rains are not always followed by a flood or landslide. While early alerts can be delivered to the under risk population, they must be issued when there is an important probability of the event to happen, as a false alarm will inevitably lead to losing confidence in the system and many times it creates unnecessary chaos and confusion.
Following the same reasoning line, earthquakes can produce tsunamis at the shore that can be predicted, and early alerts can be delivered to notify the civil population. However, earthquakes occur without any alert; the intensity and the distance to the epicenter determine the consequences it may produce. The impact of the earthquake depends on the quality of the civil infrastructure and how they resist the seismic movement.
One regular way to reduce the impact of the natural disasters is providing an adequate evacuation plan that protects people from the event and its consequences. In order to build effective evacuation and response plans, the first response organizations (e.g., firefighters, police, and government agencies) need to consider the dynamic of human population in the potentially affected areas, and also social perception from local residents when designing traffic assignment plans, evacuation procedures, and shelter locations [
1].
Internet of Things (IoT) based technology seems to be adequate to deploy a sensor network and information providers along predefined routes to shelters or safe areas, as an infrastructure to support the design of evacuation plans. This idea was initially introduced in [
2], where the authors proposed the use of special witness units (WU) that build an alternative communication network to guide people to shelters in the city of Padang, using a satellite subscription as backbone. Another important aspect that should be considered is the use of traffic lights and traffic directions in streets ensuring that people following the evacuation routes do not get into traffic jams or congested paths that prevent an efficient throughput.
Considering the evacuation challenges before and after natural extreme events and also the opportunities that provides the IoT-based solutions, this paper proposes a distributed decision support system for civilians, based on IoT devices that guide people during these evacuations towards safe places or shelters. The WU, conveniently distributed in the city, are a breadcrumb to safety. In each one, users may upload data on blockings or incidents; therefore, the actual escape routes are dynamically updated and informed at both other neighbor WU and to the Emergency Operation Center (EOC).
The next section discusses the related work on natural disasters and the way in which IoT-based technology may provide support to search, rescue, and evacuation processes. In
Section 3, the Evacuation Support System (ESS) model is described and in
Section 4 the way in which the system is implemented is introduced.
Section 5 presents the optimization method to distribute the WU and two examples are provided (one synthetic and one based on an actual city in Indonesia) that show how it operates.
Section 6 describes the mobile application that supports the evacuation process, and
Section 7 presents the conclusions and future work.
2. Related Work
The use of IoT-based technology in first response processes has been proposed in the past. In [
3,
4], the use of IoT solutions to support search and rescue teams during urban incidents was proposed. Particularly, the use of opportunistic networks as alternative backbones to provide communication between rescuers and the incident commander is proposed in [
5,
6] with different schemes to provide real-time response. In [
7], the concept of human sensors is introduced, which represents people that capture and interpret the events and then feed the system with such information. The advantages of these types of solutions have been broadly recognized; however, they are not easy to implement. For instance, the literature emphasizes the relevance to count on appropriate networks to disseminate the information and keep the coordination among first responders and civilians. Usually, VHF/UHF radio systems are used in the communication and coordination among team leaders and the command center, since they can be easily deployed and used. These radio systems provide quite reliable channels to exchange voice messages, allow people mobility and are temporarily autonomous of power supply [
8]. Although useful, radio systems have several shortcomings, such as a limited number of available channels, incapability to transmit digital information, and inability to manage message interference (e.g., the exchanged messages are frequently overwritten by more powerful devices or mixed by the antennas) [
7,
9].
Analog radio systems are also limited in supporting resilient network protocols and topologies, keeping a multi-organizational coordination, and maintaining information consistency [
8]. Without an appropriate communication support, the decisions made by the incident commander and team leaders are based mainly on their own experience, since little or no information is available to support such an activity. Thus, the coordination among teams becomes a challenge almost impossible to overcome. Given this situation, it is not surprising to see improvisation in the field [
10], which usually impacts negatively on the emergency response process, as observed in the Yarnell Hill Fire (2013) [
11] and also in the World Trade Center (2001) [
12]. Clearly, data communication in emergency scenarios continues to be an open issue, not only due to the stability of the network signal, but also because of the bandwidth and routing capability that can be provided in these types of environments.
In [
13], a novel data integration framework for developing an evacuation decision support system for wildfires is introduced. This system integrates multiple data sources including social media, census survey, geographic information systems, data layers, volunteer suggestions, and remote sensing data. It consists of four core modules: (1) dynamic population estimation, (2) stage-based robust evacuation models, (3) social perception analysis, and (4) a web-based geospatial analytics platform. Although interesting, such a framework is a theoretical proposal that requires a more in-depth analysis to determine its suitability in practice.
In [
14], a hybrid emergency evacuation approach is proposed, which uses IoT-based technology and cloud computing. This approach attempts to utilize the advantages of both infrastructures (IoT and cloud) to calculate evacuation paths in real-time during emergency evacuation. It tends to maximize the safety of the suggested evacuation paths, by adapting the evacuation to the characteristics of the hazard, evacuees’ behavior, and environmental conditions. The approach covers two emergency navigators: a Localized Emergency Navigator and a High-Risk Emergency Navigator. Depending on some defined emergency factors, the approach decides what navigator to execute. It also handles several evacuation situations, for instance when people get locked in a temporal safe place, but that is inside the emergency area.
In [
15], the authors study the agility of evacuation routes in relation to dynamically changing unpredictable hazardous conditions in smart space networks. Infrastructure safety conditions may unpredictably change through time. Due to unpredictability, evacuees’ safety can get jeopardized at any point of the evacuation route. Thus, it is not sufficient only to find the shortest evacuation routes considering present safety conditions and evacuation flow, but we should also consider other relevant characteristics that make the evacuation routes sufficiently safe along time. Like in the previous case, the evacuation model proposed in this work is focused on buildings.
In [
16], the way in which people in Bangladesh react at the moment of evacuation is analyzed considering the case of the cyclone Aila. In this study, the authors explore important factors that influence people’s evacuation decision and selection of evacuation destination. Among these factors are the content of cyclone warning and evacuation order, the timing of evacuation order, the evacuation preparation time, the people’s risk perception, the weather condition, the conditions of roads and cyclone shelters, and the distance to these shelters. In fact, different groups of people are needed to be treated differently during the design and implementation of different evacuation awareness programs, training, drills, and actions.
In [
17], the authors discuss the use of formal modeling to support robust, adaptive, and repeatable decision-making during an impending hurricane. It also details a case study of Hurricane Isabel (2003) in North Carolina, using an integrated scenario-based evacuation computational framework that allows for comparing the effects of including the three features of the evacuation in the modeling. Findings suggest that making the evacuation plan robust, adaptive, and repeatable should improve results by reducing both the numbers of people at risk and unnecessary evacuation orders and travels. The magnitude of those benefits, however, depends on uncertainty in, and evolution of, the attributes of the particular hurricane.
In order to help address the main challenges in evacuation scenarios, the next section introduces the Evacuation Support System (ESS) that operates on top of an IoT and opportunistic alternative network. It assumes as a regular operational condition that the natural disaster will produce the collapse of the communications and electricity infrastructure. We use as an example a typical evacuation of a tsunami to illustrate how to work the proposed model.
3. The Evacuation Support System Model
Cities in which natural disasters are prone to occur, for instance those at the coast of Chile, Japan, or Indonesia, usually count with an evacuation plan in the case of a tsunami alert. Although the population can be trained on the procedures to follow once the alert is issued, it is impossible to address every evacuation scenario since there are many places where people may be when the evacuation alert is delivered. The evacuation also depends on many other factors such as the time of the year (winter or summer), the day of the week (work days or weekends), and time of the day (day or night). Even evacuating during daylight is not the same at lunch time or when children are moving from their houses to schools. Consequently, there are so many alternatives that are difficult in regards to envisioning what should do with each person after the alert. In this case, the technology can provide people with the necessary elements to guide them from their actual place to a safe one.
A tsunami usually comes after an earthquake has affected the region. When the earthquake hit the city, people already know that a tsunami may happen at any moment and they should move quickly to a safe place in a chaos situation. In other cases, the earthquake may happen far away from the point where the alert is being issued and the people are not aware of the imminent danger. While in the first case, the evacuation process is followed walking away from the danger, in the second, it is possible to drive cars. In any case, after the alert, there is usually a panic period during which people tend to act in an avalanche fashion collapsing the escape routes.
The ESS proposed in this paper uses IoT devices deployed in the city to provide people a guided route towards safe areas. Although it may be argued that traditional signs may be used to support the evacuation process, it is impossible to reconfigure the routes dynamically based on unexpected situations like fallen bridges or blocked streets. The ESS works like a dynamic breadcrumbs trail that guides the population to exit from the dangerous area.
The ESS proposes a two-level hierarchical organization with the Emergency Operation Center (EOC) at the head of it. Under the EOC, a distributed system is proposed, which works following a peer-to-peer paradigm (P2P) with special nodes named Witness Units (WU) as indicated in [
2]. These units are capable of computing evacuation routes, communicating with the EOC, and working as an access point for users. Other nodes in the network are sensors distributed in the area to monitor the general conditions of the routes. For example, a surveillance camera can provide information on the state of a bridge or be used to detect blocked streets. Other nodes can act as actuators (traffic lights, barriers) that can be used to direct traffic towards safe places avoiding traffic jams.
Figure 1 shows the model of the system.
In the proposed hierarchy, the EOC communicates with the different actors using classical Internet protocols. The information flow in this level is bidirectional as WU and SC may update the actual state in the area in which they are deployed. Users may act on a different level, exchanging information in a P2P fashion or through opportunistic contacts. In this case, user nodes also have mobility and can carry information on the state of different things by taking pictures, recording audios, or simply marking in a particular spot a problem (it may be a blocked street, a collapsed structure, gas escape, or fire). The way in which users interact with the system is through an application previously installed in smartphones. The application should scan continuously for the WU access points and guide the user to the next step in the breadcrumb trail.
The EOC server should update continuously the escape routes for every WU, but the WU should be able to compute a local route too as the information provided by the users is valuable. In this way, a WU that may be eventually disconnected from the EOC may have information coming from users and other WU, and it can be in a condition to guide people in its proximity to the next safe step.
4. System Implementation
IoT is built upon the traditional network protocols, e.g., IPv6 for the network layer and TCP or UDP depending on the kind of applications. Typically, between the transport and application layer of the network, the MQTT/TCP or CoAP/UDP protocols are implemented to simplify the exchange of messages among devices that are usually restricted in memory and computing power. The Link and Physical layers, however, are more heterogeneous, as a large variety of options are available. IoT is commonly associated with wireless sensor networks, but this is not necessarily true when it is possible to connect the sensors with wires in order to ensure the information flow. Anyway, in evacuation procedures, the use of cables to connect the device to the network is not considered, as they will probably be broken after the natural event.
The Low Power Wide Area Network is oriented to the IoT WAN market to provide connectivity to devices that consume low power, have low duty cycles, and exchange a few bytes of information. There are two basic alternatives to implement this communication: (1) the cellular network based on the LTE standard that uses a licensed spectrum, and (2) the wireless WAN operating in an unlicensed spectrum. LTE is frequently used, but its evolution to the 5G standard is not clear yet. Concerning wireless protocols to be considered, in what follows, we describe the two more used today: SigFox and LoRa [
18,
19]. SigFox is a wireless technology based on Low Throughput Network that can be used as a wide area backbone with a low data rate. Typically, it is used for Machine to Machine (M2M) communications in IoT scenarios, and it can be interfaced with cellular networks (GSM and LTE). In urban areas, the communication range of SigFox is between 3 and 10 km, with data rates around 100 bps. This wide area network supports low data rate communication over larger distances; therefore, it is used to link M2M and IoT applications that transmit a few bytes per day.
On the other hand, LoRaWAN is specified by the Lora Alliance, and it provides an open global standard for secure carrier-grade IoT LPWA connectivity. It is present in many countries providing the basic service. Besides the LoRaWAN availability, LoRa devices can work in ad hoc networks that provide connectivity to devices and get into the Internet through a gateway. Data transfer can reach up to 50 Kbps, which is higher than Sigfox. In this context, both LoRa and Sigfox provide similar solutions. In the South American region, LoRa is leading the market and several companies have adopted the standard to provide connectivity to sensors. LoRaWAN provides in this scenario a good connectivity pattern. In addition, there are plenty of boards developed for open hardware platforms, like Arduino and Raspberry Pi.
4.1. WU Configuration
The model described in
Section 3 is hierarchical since the communication between the end-users and the EOC is never direct. In fact, each WU creates a standalone local area network (LAN) to which the smartphones of the users can be connected. This LAN is not truly connected to the Internet; instead, the WU has a specific application with the information that end-users may require, and it provides a way in which the WU can upload data. Besides this LAN, the WU has a LoRa working port to connect to the EOC.
The LoRa network does not depend on cell phones or external infrastructure. It works as an alternative communication network providing connectivity even in the case that power utility is down, since each LoRa node has batteries and solar panels to keep it alive. The WU in the LoRa network is an end-device [
20], while the EOC is the server. Information flow is bidirectional as the WU uploads information about the local situation recovered from the users, and they receive updates coming from the EOC about the actual situation in shelters and evacuation routes. LoRa has three MAC alternatives: (A) in which an
Aloha access control is implemented, (B) that is based on
beacon synchronization for either download and upload transmissions, and (C) in which end-devices are continuously listening. In the case of ESS, the class B MAC is selected because the EOC should keep the WU synchronized and updated all the time. In addition, the class B also provides functionality for multicast messages, and it is used to provide information oriented to particular groups of WU according to the actual situation in each city area. All WU start their operation in class A mode to comply with the standard. As soon as the EOC provides the synchronization beacon the application, they switch to class B operation mode.
The class B mode uses the beacon provided by the network server, in this case the EOC, to synchronize clocks in the end-devices (i.e., the WU). After the beacon is received, each end-device counts with a time slot previously allocated to upload information to the server. This mechanism is suitable for the crisis situation, as WU will probably be operating on batteries only supported by solar panels, so energy preservation is mandatory.
The communication threshold in LoRa can reach 3 km; this may be a short distance considering large cities, so a tree of synchronization stations should be deployed when larger distances are necessary to cover. The EOC is always the root of the tree and the repeating stations are located as to cover the territory of interest, usually providing redundancy.
5. Network Deployment
The distribution of the WU is a typical coverage problem and has been proved to be NP-Hard [
21]. As there is no known polynomial solution, we propose a heuristic approach based on a bio-inspired algorithm. In [
2], the authors proposed a greedy algorithm for providing the WU deployment. In this paper, such an idea is recovered, but a genetic algorithm is proposed to improve the characteristics of the WU distribution on the evacuation area. The next steps should be followed to organize the deployment of WU.
Given a city with area, A, it should be divided in a set of regions , such that and .
For each region, a graph should be built, where each node represents an intersection and the edges indicate the block linking and . The weight represents the distance in meters, .
Finally, a maximum desirable distance between two WU, D should be defined. The distance is measured using the weights and through the shortest path, and it represents transportation time necessary to move through the edge (instead of meters between the two points).
The original algorithm considers that, starting at a predefined WU, the graph corresponding to a region is traversed. The edge with the highest associated weight is followed at each step until the sum of the traversed edges is bigger than the predefined D. The immediate previous node traversed is tentatively used as a WU holder. The procedure is repeated until all the edges connected to the original vertex have been followed. The same algorithm is done for each node holding a WU.
In order to improve the distribution of WU, this paper proposes a Genetic Algorithm that ensures a maximum distance of D between any two consecutive nodes. Each intersection in the map is represented by a gene in the chromosome, and each chromosome contains all the intersections in the region under consideration. With this in mind, for each chromosome, an objective function is evaluated. After this, the best chromosomes are selected. To some of them, a mutation factor is applied, and the population is expanded with the muted chromosomes; then, this cross over is performed. The new generation of chromosomes is evaluated again and the process is repeated until no further improvements are obtained.
5.1. Fitness Function Model
The population involved in an evacuation procedure usually must travel a route within the city, consisting of a series of checkpoints where the WU are located. As stated above, the route is defined by each WU on the basis of the information that is being collected from the people in the field. The condition imposed for the WU network is that citizens must not travel a distance greater than D, between two consecutive checkpoints of the evacuation route.
The location of the WU are fixed and independent of the required evacuation route; therefore, a set of restrictions that guarantee an adequate distribution while minimizing the number of WU must be defined. On the map, each position where it is possible to locate a WU is modeled as a node; it is noted , within the set of nodes V of the graph. Then, each node in the network can have two possible states, depending on whether there is a WU in its position or not. We define the subset S contained in V and we note to the nodes that belong to S.
The weights of the links define the distance or the time it takes for a person to travel through the physical separation of the nodes that compose this link. Therefore, we can define the function that calculates the minimum distance between the nodes and . As it is possible that some links are obstructed or that should be avoided in some way, it is necessary to have alternative paths, and so the function calculates the distance of the m-th order route that joins with , sorted from shortest to longest path length.
Given the sets
S and
V, for each node
of
V, there exists a node
in
S such that
matches the
node closest to
. Formally speaking:
To guarantee the model conditions, it is necessary to impose the restriction that each node of the set
V is not placed more than
D units away from the nearest node that contains a WU. Therefore, we formalize the following restriction that all proposed solution must meet:
To obtain the optimal solution, it is necessary to define an objective or fitness function that verifies the previous restrictions and evaluates the quality of each possible solution. Thus, it is possible to generate a search space and find the best solution to the problem using an optimization method.
The problem’s optimization variable X can be modeled as an N digit binary number, where N is the number of nodes in the set V. The i-th digit of X (represented as 1 or 0) indicates whether there is or not a WU in the location of the node . Therefore, it would include or exclude the respective node in or from S. The fact that the optimization variable is represented by a binary number allows for directly applying optimization using a Genetic Algorithm (GA).
5.2. Optimization Stage and Validation
In the context of GA, each candidate for solution is represented by a chromosome composed of N genes. The chromosomes can perform a crossover giving rise to a new offspring individual that combines characteristics of the two original chromosomes or parents. In addition, chromosomes undergo mutations that are applied by randomly altering its genes. In each iteration, the GA method applies a selection of the best conditioned individuals, then performs a crossover between the fittest chromosomes, and, finally, the genes are randomly altered. Each complete cycle or iteration is called generation, and is repeated until the termination condition is met.
The fitness function and the GA method were both implemented in Octave with the “ga” package [
22]. Two different problems were evaluated; first, a simple case verifies the method performance, where the map was modeled as a 5 × 5 grid with a weight of 1 unit for every link, as shown in
Figure 2. As this is a synthetic case, the red dots indicate the locations where the WU should be to satisfy the condition that all blue nodes should be at distance 3 of the red ones.
In the second problem, the algorithm performance was evaluated on two real cities with high tsunami risk: Bandar Lampung in Indonesia and Niigata in Japan. The map of the cities was downloaded from openstreetmap.org as an osm model. The street model was extracted from the osm data and converted to a fully connected graph using Octave tools.
Figure 3 and
Figure 4 show the original maps for the cities. To define the value
D, the average length of paths between nodes was calculated as a reference and then a value between
and
was used. This is approximately equivalent to distances from 300 to 500 mts in the real world. The graph representation is shown on the right side of
Figure 3.
Finally, the GA was run considering two different values of
D. Like in the first example, the red dots indicate the locations of the WU.
Figure 5 and
Figure 6 show the solutions found.
The performance of the GA is shown in
Figure 7. On the left, the case of the Bandar Lampung map with
and on the right the case of Niigata with
. The plot displays best and mean penalty values, i.e., number of WU, versus current generation. As it can be seen, the algorithm stagnates at certain points (around 70 and 100 generations for Bandar and Niigata, respectively), reaching a state with a homogeneous population. To extend the procedure increasing the exploratory capacity of the method, it is recommended to increase the mutation rate to maintain the heterogeneity of the population and increasing the probability of finding better suited solutions.
6. ESS Supporting Application
The application is quite simple; it shows the local map with marks (including actual location) to the user, and arrows indicating the path to the next WU in the direction of the shelter or evacuation route. It also indicates the distance in minutes to the next WU and the obstacles or dangerous situations in the evacuation route; e.g., dropped electricity cables, fires, or destroyed bridges. The user can also act as a human sensor proving information about obstacles not informed in the system. Therefore, the user can touch the screen on a certain point, and a menu with these basic events is open allowing for the indication of new obstacles. Once the obstacle has been added to the system, the WU updates the information locally, dismissing the route going through that street and issuing the alert to the EOC.
Two screenshots of the application are shown in
Figure 8. Its user interface should be as simple as possible in order to reduce the cognitive load required to understand the information shown to the end-users. The application is based on a simple http/tcp/ip protocol and incorporates information provided by a geographical information system. It uses the open street map project to load maps, as other options require an active Internet connection to be used, and this cannot be guaranteed during the evacuation process.
In the Street Map screenshot, it is possible to see the location of the actual WU and the area in which the access point can be used (indicated with a light grey circle). Of course, this area may vary according to the buildings surrounding the WU. The arrows on the street mark the best path to the next WU.
7. Conclusions and Future Work
This paper presents the foundations of an Evacuation Supporting System (ESS) based on IoT Components and describes its main components. The system’s architecture includes the EOC server, WU, mobile devices for the end-users, and a backbone network based on LoRa. On the one hand, the WU, as breadcrumb stations in the evacuation routes, provide access to the ESS information and allow users to update the actual situation. On the other hand, the mobile application allows users to access the WU access points and their services, including shared and updated information about the evacuation routes. A genetic algorithm is proposed to determine suitable locations to deploy the WU ensuring a maximum distance between two consecutive nodes in such a way that people moving towards shelters or safe zones can follow the best and free of obstacles route. The method was evaluated on two different cities from different countries like Indonesia and Japan. In the next step, the system will be deployed within the university campus for its evaluation by students.
As part of the future work, this ESS will be extended to support vehicle evacuation routes, providing for them traffic light synchronization and even changing lane directions when necessary to facilitate the flow of cars and people.