Bot-Based Emergency Software Applications for Natural Disaster Situations

Abstract

Upon a serious emergency situation such as a natural disaster, people quickly try to call their friends and family with the software they use every day. On the other hand, people also tend to participate as a volunteer for rescue purposes. It is unlikely and impractical for these people to download and learn to use an application specially designed for aid processes. In this work, we investigate the feasibility of including bots, which provide a mechanism to get inside the software that people use daily, to develop emergency software applications designed to be used by victims and volunteers during stressful situations. In such situations, it is necessary to achieve efficiency, scalability, fault tolerance, elasticity, and mobility between data centers. We evaluate three bot-based applications. The first one, named Jayma, sends information about affected people during the natural disaster to a network of contacts. The second bot-based application, Ayni, manages and assigns tasks to volunteers. The third bot-based application named Rimay registers volunteers and manages campaigns and emergency tasks. The applications are built using common practice for distributed software architecture design. Most of the components forming the architecture are from existing public domain software, and some components are even consumed as an external service as in the case of Telegram. Moreover, the applications are executed on commodity hardware usually available from universities. We evaluate the applications to detect critical tasks, bottlenecks, and the most critical resource. Results show that Ayni and Rimay tend to saturate the CPU faster than other resources. Meanwhile, the RAM memory tends to reach the highest utilization level in the Jayma application.

1. Introduction

During the last few years, there has been a special interest in the development of software applications focused on providing help during and after the occurrence of natural disasters of great magnitude [1,2,3]. The normal life of people is destabilized, there is chaos and the need for help, rescue, and relief to the victims of the catastrophe. All of this can cause human, structural, and economic losses that can rise incalculably if not managed properly. In this crisis context, emergency response teams composed of spontaneous volunteer and experts have a key role in helping reduce the impact of the natural disasters. They are typically coordinated by social, public, and national organizations responsible for sending the appropriate resources to the most affected areas and also for reporting the news. Emergency response teams need to work fast, and the decision makers must base their decision on the collected data from different sources as soon as possible [4].

Nowadays, technology such as mobile devices and smartphones have driven the development of applications devised for large-scale natural disasters to aid victims and also to facilitate the collaboration between spontaneous volunteers [5,6]. However, in a serious emergency situation, people will always turn to the software they use every day, the software that is most familiar to them. It is unlikely that a person who can potentially participate as a spontaneous volunteer in the face of a serious emergency remembers in advance to install and learn how to use a large-scale disaster application. Especially in a stressful situation, either as an affected person or as a person in charge of volunteer work or being part of an emergency team, people will tend to turn to the software they know best and have available on their smartphones [7,8]. Social media has also been successfully used to rapidly evaluate the impacts of disasters in real time [9,10].

1.1. Research Objectives

In this paper, we analyze the feasibility of using bot-based software applications for emergencies devised to assist social organizations that are activated upon the occurrence of large-scale natural disasters. The applications are executed on commodity hardware usually available from public organizations, such as universities, during the emergency situation. Most components forming the architecture are from existing public domain software, and some of them are consumed as an external service as in the case of Messenger or Telegram.

This problem is challenging, since we need to understand how the application behaves under high rates of workloads, which components can became bottlenecks, and which are the saturation points of the applications to then efficiently deploy them to support unexpected peaks of user requests. We investigate how the communication affects the performance of each task of the applications, which resources (CPU, RAM, network) saturate faster, and how can we use replicas to support higher workload. We analyze the capability of bot-based software to achieve efficiency, scalability, fault tolerance, elasticity, and mobility in commodity data centers by using container technology.

1.2. Contribution

We present and evaluate three bot-based applications that can help organizations help citizens who suffered from natural disasters. Bots have been previously used for medical purposes [11], for communication and training [12], and also for crisis communication and management [13]. However, to the best of our knowledge, there is no previous work evaluating the performance of bot-based applications to show that those applications are able to cope with critical mission requirements. In particular, we focus on critical resources and critical tasks when stressing the systems to unexpected peaks of user requests in natural disasters situations.

The three bot-based applications are named Jayma, Ayni, and Rimay. Jayma gives supports to people who are in dangerous situations during a natural disaster. For example, it informs a group of predefined contacts whether the person is in danger or not and the location where he/she is. Ayni coordinates teams (small and large) of volunteers in the field. Ayni assigns tasks to volunteers and receives status reports and additional information. Rimay coordinates tasks assigned to organizations that provide support in a natural disaster situation. Users access these applications through bots of Telegram and Messenger. This is relevant because bots are a mechanism to integrate into the software that people use as part of their lives. These bot-based applications can be used by victims and also by volunteers to coordinate relief work.

We deploy the applications on a computational platform based on container technology, container orchestration, and virtual machines. Containers allow the deployment of applications independently of the operating system, since it encapsulates the applications and their dependencies in portable modules that run under the same operating system kernel. Containers facilitate the deployment of applications in a wide range of operating systems such as Linux, Windows, or Mac. This container orchestration technology guarantees application mobility and also ensures fault tolerance through data replication and volatile applications where data do not need to be recovered after a failure.

We present a comprehensive performance evaluation study on a single processor and on multiple processors with different workloads. For each application, we detect the most critical tasks, meaning the tasks that saturate faster supporting fewer requests per unit of time. We also evaluate the utilization levels of the CPU, RAM, and communication network. This information can be used by the engineer in charge of the data center to efficiently deploy the applications. The results show that the CPU is the most critical resource in Ayni and Rimay reporting utilization levels close to 60–70%. Meanwhile, the Jayma application tends to saturate faster the RAM memory than other resources.

1.3. Outline

The remaining of this paper is organized as follows. Section 2 describes the computational platform and the technologies used to deploy the applications. Section 3 present the bot-based applications: Ayni, Rimay, and Jayma. Section 4 presents the experimental results. Section 5 presents related work and summarizes the features of our applications. Section 6 presents a discussion about the limitations of our work. Section 7 concludes and present future work.

2. Platform Design

The design of our platform includes four main components: (1) a Front-end, (2) a Back-end, (3) a Bot Back-end which is an API REST that responds to user requests from the Messenger chat of Facebook and/or Telegram, and (4) a Data Repository like MongoDB [14]. Each component can be replicated, distributed, and partitioned based on the workload and communication requirements. Users connect to the Front-end using a smartphone, a tablet, or a computer. The Back-end hosts the applications and communicates with the data repository component. The Back-end performs data searches and executes transactions. The Data Repository stores the data in non-relational databases such as MongoDB [14] or Cassandra [15]. Both the Back-end and the Data Repository can be deployed on different servers. Our platform uses a container [16] and container technology [17], which allow the deployment of applications based on microservices, to achieve auto-scalable, fault-tolerant, and stateless systems, making the configuration of the infrastructure transparent for the programmer. In particular, we use Kubernetes [18] and Docker [19] due to their wide dissemination in the technology community and the support available in the software communities. In Figure 1, we show the general scheme of the architecture, where Nginx [20] is the access point, which is the application server and works as a proxy. The container orchestrator manages and redirects requests to a container. Finally, the figure shows the interaction between different Back-ends and different Data Repositories such as MongoDB, Cassandra, MariaDB, etc. The orchestrator also starts new instances of the applications running in the containers. New instances are started when failures occur or when more resources are needed to support user demand. To this end, ImageRepo maintains an undeployed image of all orchestrated containers. As a particular example, Figure 2 shows the deployment of the complete platform distributed among a cluster of servers coordinated by a container orchestrator.

Figure 3 summarizes the technologies used to implement the bot-based application on the platform. Our platform supports different types of configurations: unshared, virtual machine monitor (VMM), cloud computing, and container. In the non-sharing configuration, we install the operating system (OS) that manages the resources, the run-time libraries, and then, we deploy the applications. Another possibility is to connect the hardware directly to the VMM (hypervisor) independent of the operating system. The star (*) symbol shows this configuration in Figure 3. Cloud computing provides tools to manage virtual machines and their resources, which facilitates tasks such as self-scaling (elastic), live migration, and resizing a virtual machine based on workload. Similarly, container technology and orchestrator provide tools to create container-based, self-scaling (elastic) microservices. It automatically manages the containers using a load-balancing algorithm. Using containers without orchestrator requires manual intervention (on the host VM) to manage the containers.

3. Bot-Based Applications for Natural Disasters

In this section, we describe the design of the bot-based applications evaluated in this work: that is, the Jayma, Ayni, and Rimay applications.

3.1. Jayma Application

After a natural disaster strikes, Jayma (https://citiaps.usach.cl/portafolio/jayma, accessed on 28 January 2022) gives information about safe places and meeting points, recommends routes to follow, and spreads information through the Messenger bot. For the Messenger bot, the app creates a network of the user’s contacts. These contacts are included in the Jayma network after they agree to participate by using the Jayma app.

The Back-end of the application supports a website for the administrator. The administrator can send disaster alerts to users. When the administrator sends an alert message, users receive a notification (Facebook Messenger message) indicating that a natural disaster has occurred. The administrator can also submit relevant information such as safe points. Figure 4 shows some screenshots of the Jayma bot. The application supports the following tasks:

1.

Send alerts: The administrator sends alert messages to the users included in the Jayma network.

2.

Access to the main menu: Lists all the application options (Figure 4a).

3.

Information: Provides information on meeting points or safe areas. These are safe geographic locations (latitude and longitude) and are activated by the administrator. Upon accessing the link, the bot delivers a Google Maps map with the last known location and the route to the closest meeting point (Figure 4b–d).

4.

Report user status: The bot asks the user for the location. Once the bot receives the location, it asks the user if they are well. The bot notifies the user’s contacts of their status and location. In case the user is unwell, the bot asks what is the problem (panic/injured/infrastructure problems/needs supplies). See Figure 4e,f.

5.

Contact management: Adds new contacts to the Jayma network. It also allows deleting a contact and listing current contacts. To include a person as a new contact, the app sends a message to that person with a link to the bot.

3.2. Rimay Application

Rimay (https://citiaps.usach.cl/portafolio/rimay, accessed on 28 January 2022) manages and coordinates groups of volunteers using the Telegram bot. Each group of volunteers has a leader who receives tasks from one or more coordinators or administrators. Coordinators can use a web page to easily manage tasks and collect statistics. Figure 5 and Figure 6 show some screenshots of the Rimay bot.

The application supports the following tasks:

1.

Enrollment: Users request to register as volunteers. When the coordinator accepts the request, the data associated with the volunteer are stored in the system. In addition, the coordinator can assign the coordinator role to new users (Figure 5a,b).

2.

Create event: The coordinator creates an event such as a forest fire. In addition, the coordinator can create tasks for each event, such as distributing face masks. Tasks have information such as where the face masks are stored and a job description. Volunteers can accept or decline assignments. Volunteers can also finish assignments when they are completed. The coordinator can also finish the event when it is complete. (Figure 6a).

3.

Delete user: The coordinator can delete users from the system.

4.

Send file: The coordinator can send a file to the volunteers.

5.

Help/Status: Reports the status of volunteers.

6.

Send report: Volunteers can send a report (attached file) to the coordinator. See Figure 6b.

Figure 7 shows the steps executed during the execution of different tasks on the Rimay application. In particular, in this example, the coordinator sends the command “newTask” to the Telegram bot to create a new task. The bot asks for the name of the task. After the coordinator answers, the bot asks if he/she wants to upload a file. The coordinator uploads an image file. Then, the bot asks if he/she want to add a GPS location and the coordinator responds by sharing a geolocation. The bot displays a menu showing the existing volunteers. Then, the coordinator selects a volunteer who will receive the new task. Finally, the coordinator sends a request to the Back-end component to verify the information and to store it in a database. The boxes $S_i$ with $i=1,2,3,4,5$ represent the time it takes for the person to respond. The boxes $Tbo{t}_i$ with $i=1,2,3,4,5$ represent the processing times of the bot. $Tb{e}_1$ represents the processing time of the Back-end. Notice that during the execution time $Tb{e}_1$, the bot thread is free until it gets the response. Figure 5 shows screenshots of the login web page and the information provided the Rimay application running on the Front-end.

3.3. Ayni Application

The Ayni application (https://citiaps.usach.cl/portafolio/ayni, accessed on 28 January 2022) manages groups of volunteers through a bot of Telegram. These volunteers sign up for the current emergency and they inform about their characteristics (physics, skills, knowledge, etc.). Volunteers can participate in tasks created for a particular emergency. Figure 8 shows the general scheme of the application. We use a cache because the bot needs to be stateless for replication and also needs to store information of a given task as the execution of the task advances in different components of the platform. The application supports the following tasks:

1.

Create emergency: The coordinator creates a specific emergency and selects volunteers to participate in it.

2.

View emergency details: Displays the specifications of an emergency.

3.

Create Task: The coordinator creates tasks assigned to the emergency. In turn, it chooses volunteers who are asked if they want to participate in the assigned task.

4.

Create volunteer: People register into the system.

5.

Task details: Displays the task specifications.

6.

Volunteer details: Displays the volunteers characteristics.

7.

Volunteers agree to participate: A volunteer agrees to participate in an emergency.

8.

Tasks per emergency: Displays the tasks for each emergency.

9.

Active tasks for emergencies: Only active tasks assigned to emergencies are displayed.

10.

Tasks completed by emergency: Only tasks completed by emergencies are displayed.

11.

Volunteer accepts task: A volunteer accepts the task.

12.

Volunteer completes task: A volunteer informs that the assigned task has been completed.

4. Experiments

4.1. Platform Configuration

We evaluate the performance of the applications on a processor with 32 Cores, a RAM of 64 GB, HDD of 1.8TB, CPU MHz 1298. We deploy the applications on a single processor using Dockers. Figure 9 shows the configuration for a single processor. We use one VM to run the nginx, one for the back-end, and one virtual machine for the data repository. In particular, we use MongoDB as the data repository component. Each virtual machine has two cores, 4 GB of RAM, and 100 GB of hard disk. To detect bottlenecks and measure resource utilization, we use Jmeter 5.3 [21], which is a free software implemented in java.

We also evaluate the performance of the application on two processors with the same characteristics as described above. The bandwidth between both processors reported by iperf (https://iperf.fr/, accessed on 28 January 2022) is 17 Gbits/s. Figure 10 shows the deployment of the apps in one of those processors. The Bot-back-end and the Back-end are worker components. Each worker has a virtual machine with 3 cores and 4 GB of RAM. Other components are executed on VM with two cores and 4 GB of RAM. The Master component executes Kubernetes. Only for the Ayni app, we use REDIS as a cache service to store the current state of the flow of each process. That is, if the task has a single action (such as help), only the first state of the task is saved and then deleted at the end of the flow of the task. However, if the task is longer, the flow of sub-tasks is saved until the complete flow is finished. The repoimage component is used by Kubernetes (it is the container image repository) when the deployment of the first container is performed. The applications are replicated on three workers, and to support fault tolerance when a worker fails, Kubernetes uses RepoImages to look for the corresponding image and deploy it in the selected worker. The validation of the tasks executed by the applications was based on expert consensus.

4.2. Bottlenecks and Performance Evaluation for Ayni

In this section, we evaluate the saturation points reported by different tasks executed in Ayni. To stress the app, we do not include the communication via the Telegram api because it limits the number of requests per second that we can send to the application to 30. In the following experiments, we send 600, 900, 1200, and 1500 requests to the application every 30 s. We deploy the application on a single processor according to Figure 9. We also show results of the Ayni application running on two processors according to Figure 10.

In

Table 1. Maximum number of requests supported by each task of the Ayni application on a single processor and with a distributed configuration.

Task	#Requests (Single)	#Requests (Distributed)
01 Create Emergency	100	180
02 Create Task	200	360
03 Create Volunteer	60	100
04 View Emergency Details	400	770
05 Task Details	400	760
06 Volunteer Details	60	100
07 Volunteers Agree to Participate	400	750
08 Tasks per Emergency	400	750
09 Active Tasks for Emergencies	400	750
10 Tasks Completed by Emergency	200	380
11 Volunteer Accepts Tasks	400	770
12 Volunteer Completes Tasks	200	380

, we show the tasks executed by the Ayni application and the number of requests per second supported by each task before it fails. We show that there are two critical tasks: “03—Create volunteers” and “06—Volunteer details”. Both tasks support a maximum of 60 requests per second on a single processor and 100 requests when the Ayni application is deployed on two processors. With more requests, the tasks became unstable, and some requests are not completed. Other tasks support a larger number of requests, as in the case of “05—Task details”, “07—Volunteers agree to participate” and “13—Volunteers accept tasks”.

Figure 11 shows the requests processed successfully in a single processor (red line) and requests not completed (green line). We show the results obtained by the task “10—Tasks Completed by Emergency”. The x-axis shows the advance of time in seconds. We divide the x-axis into segments of 30 s each. We start with 600 requests in the first time segment. Then, in the following segments, we increase by 300 the total number of requests. The results show that not all requests are completed in the fourth segment. That is, with an incoming rate of 40 requests per second (1200 request in 30 s), the system begins to saturate, and some requests are discarded. The system reports that 11.78% of the requests are not processed.

Figure 12 shows results obtained with a distributed deployment. In particular, we plot the utilization of different resources used by MongoDB (top) and the workers (bottom). Figure 12a shows that the CPU utilization reported by MongoDB reached peaks close to 60% in the last time interval. Similarly, Figure 12b shows the resource utilization reported by the workers. In this case, the CPU tends to be more demanding, reaching almost 100% of utilization in the last interval of time. On the other hand, the disk and memory utilization remains almost constant in both components (MongoDB and worker). Therefore, the CPU is the most critical resource for the Ayni application. We obtain a similar behavior with other tasks.

Figure 13 shows the communication cost reported by each of the components deployed to run Ayni in a distributed manner. The x-axis shows the time advance and the y-axis shows the communication cost in bytes. The blue line represents the component worker (an Ayni instance), which reports the highest load on the network, followed by the Master (brown line) and in third place is MongoDB (light blue line). These results show how the communication rate tends to increase every 30 s. This is because every 30 s, the number of requests entered into the system increases. Notice that the peaks in red color and dark blue color are scaled ×100 for a better representation. Therefore, these peaks do not represent a high communication cost.

4.3. Bottlenecks and Performance Evaluation for Rimay

In this section, we present the performance evaluation of the Rimay application as the number of users increases every 30 s. Each user is a thread in the application and consecutively executes 10 requests. We set an interval of time of 3 s between requests. Different users can send requests in parallel.

In

Table 2. Single processor: Execution time reported by different tasks executed by the Rimay application.

Task	Avg. Time (ms.)	# Tasks per s.	Exec. Time (s.)
Enrollment	88.93	2.72	132.28
		2.94	204.33
		3.03	276.49
		3.09	348.68
Create event	7.38	1.89	94.99
		2.1	143.2
		2.2	191.24
		2.25	239.28
Send report	112.03	3.85	109.03
		4.23	165.29
		4.42	221.4
		4.52	278.4
Help/Status	7.32	1.63	36.9
		2.22	45.05
		2.64	53.07
		2.95	61.09

, we show results for an experiment with four time intervals of 30 s each. In the first time interval, we process requests of 100 users; in the second time interval, we process requests of 200 users, and in the last time interval, we process requests of 600 users. In the second column of the table, we show the average response time in milliseconds (ms.) reported by each task. The average response time is computed as the average of the results obtained in each time interval. We also show the number of tasks processed per second (s.) and the execution time in seconds required to process all the requests injected in each time interval. As expected, as the number of simultaneous users increases, the response time increases due to requests accumulated.

We also deploy the Rimay application on two processors as described in Figure 10. We use three cores for the workers and two cores for other components.

Figure 14 shows Rimay’s performance when running the “Enrollment” task with a distributed deployment. The x-axis shows the time advance in seconds. The y-axis shows the utilization of resources (CPU, memory, and disk). During the first 30 s, the application processes 100 requests from users. In the next 30 s, the system processes 300 requirements. In the last time interval, from $x=60$ s, the system processes 600 requests. Figure 14a shows that the resource utilization reported by MongoDB is below 50%. On the other hand, in Figure 14b, we show that the CPU and memory utilization in the workers are similar. The memory utilization slightly increases in each time interval, and the CPU reports peaks close to 70%.

Figure 14b presents down peaks, which are due to the execution of a new group of threads. For example, at the beginning of the second interval of 30 s, we change the configuration of the application from a group of 100 threads to a group of 300 threads. All the threads are executed in a time window of 30 s to avoid saturating the system with additional threads. This parameter is called the ramp-up period. Therefore, when a thread pool is started, T threads are running per second. In other words, in the first time interval, we use $T=100$ threads to process the incoming requests. In the second time interval, we use $T=300$ threads, and so on. Notice that in the second time interval, when the application processes 10 requests per second (300/30 s), the CPU become a critical resource. Therefore, this figure shows that the CPU tends to saturate in the Rimay application, reaching utilization levels of 90% of utilization. Others tasks report similar behavior.

Figure 15 shows the number of bytes transferred through the network by each one of the components deployed to execute Rimay in a distributed manner. These results show how the communication rate tends to increase in stages every 30 s. This is because every 30 s, the number of requests increases. The Master component reports the highest communication costs because it has to periodically check for the status of other components. Note that the pink line is scaled ×1000 for a better illustration of the graph.

4.4. Bottlenecks and Performance Evaluation for Jayma

In this section, we show the performance of the Jayma application as we increase the number of users and therefore the number of simultaneous requests. In the distributed case, we deploy the workers that actually execute Jayma on virtual machines with three cores. MongoDB and the Master that executes components such as nginx use virtual machines with two cores.

In

Table 3. Number of requests supported by each task of Jayma on a single processor and in a distributed manner with two processors.

Task	#Requests (Single)	#Requests (Distributed)
Send alert	<1200	<1680
Access to the main menu	>1500	>1500
Information	>1500	>1500
Report user status	>1500	>1500
Contact management	<120	<1100

, we show the number of requests per second supported by each task before it fails. We show that the task “Contact management” supports a maximum of 120 requests per second on a single processor. However, when the application is deployed on two processors, the task supports up to 1100 requests. With more requests, the tasks become unstable, and some requests are not completed. Other tasks support a larger number of requests.

Figure 16 shows the utilization achieved by the CPU and the RAM memory for the task “Send alert” when the application is deployed on a single processor. At the beginning of the experiment, we process 600 requests. Then, for each interval of 30 s, we increase the number of requests to 900, 1200, and 1500 requests. The graph shows that the CPU remains below 50% of utilization. Only at the end of the experiment when the number of requests tends to saturate the system, the CPU reaches utilization levels close to 100%. On the other hand, the utilization of the RAM memory tends to increase faster, reaching also 100% during the last interval of time.

In Figure 17a, we show the resource utilization reported by Jayma with a distributed deployment. MongoDB presents average utilization levels of 40%. There are two CPU peaks close to 70% during the last time interval due to the increasing workload. In Figure 17b, we show that Jayma requires a larger amount of RAM memory, reaching utilization levels close to 100% in the last time interval. The CPU also reports high levels of utilization above 90%. Therefore, in the Jayma application, both resources (CPU and memory) tend to be critical when the application is overloaded. Finally, Figure 18 shows the communication cost for the task “Report User Status”. As expected, the communication cost tends to increase as we increase the number of requests to be processed every 30 s.

5. Related Work

In this section, we first present some discussion about software applications used to help, assist affected people, and manage resources after a natural disaster occurs. Then, we discuss previous work using bot systems aimed to inform and to aid people.

The evaluation and prediction of the outcome of natural disasters have been extensively studied in the technical literature. The studies presented in [22,23,24,25] use agent-based simulation tools for population modeling, infrastructure development planning, country reconstruction humanitarian support operations, and simulation of rivers and overflows, among others. These studies can be used by people involved in planning rescue activities.

A study performed after the tsunami in Tailandia 2004 [26] presents the problems detected in the public management of natural disasters such as logistic problems for distributing goods for emergency relief; lack of effective collaboration among institutions in different levels; lack of encouragement for participation of local and international non-governmental organizations (NGOs); lack of education and knowledge for tsunami in potential disaster-affected communities and lack of information management or database system. The authors present the use cases of an application to solve logistic problems for distributing goods for emergency relief and to coordinate help between different institutions and NGOs. They conclude that NGOs must coordinate the tasks during a disaster in addition to sharing vital information with each other during effective communication channels.

As communication networks are a critical resource during a natural disaster, the work in [27] provides guidelines to support fault tolerance with different communication networks such as wifi, SDR, Satellite Telephony, etc., using information obtained during Hurricane Katrina. The authors propose using a relational database and a front-end deployed on a grid computing to support a high load of requests in a short time. The author shows that the fastest recovering network is in data networks. This supports our proposal of using bot-based applications.

Different software applications—without bots running on social platforms such as Messenger of Facebook or Telegram—have been presented in the technical literature [28,29,30,31,32,33]. The system presented in [28] was initially developed in 2–3 weeks in response to the tsunami in Sri Lanka (2004) by volunteer developers. Today, it has a series of libraries and APIs: Location API, GIS API, generic Reporting API, DataBase, and Synchronization API, among others. It supports different operations such as the registration of organizations, the request management system, and the register of persons. However, the system is deployed on a single processor, and the authors do not present a performance evaluation. Therefore, its proper deployment during a natural disaster requires engineers who are experts in fault tolerance, saturated systems, and managing peaks of requests.

A mobile application presented in [29] takes advantage of probabilistic geosocial information collected before the event to guide an earthquake victim and rescuers during and after the earthquake. It has four operation modes. The standby mode is used to collect data about users, their regularly visited locations, and their social relationships. Another mode, alert mode, warns of an imminent earthquake based on data collected from a variety of sensors and government alert systems. In disaster mode, it helps users cope with their tasks, such as the evacuation and rescue of victims buried under the rubble of collapsed buildings. In recovery mode, it facilitates family reunification, provides information on help centers, and sends warnings about the spread of disease. The authors present the use cases for the application without validation. Moreover, they do not provide detail about the architecture, the components, or the performance of the application. The work in [30] presents a prototype of a spontaneous voluntary coordination app. It uses PostgreSQL as the webserver. However, it has not been tested on a large scale. The authors present results based on the simulation of 200,000 agents, but they do not report information about how the application behaves under a high load of user requests, fault-tolerant deployment, scalability, or possible bottlenecks. Similar to [30], the authors in [31] present an application to organize pre-qualified volunteers (e.g., volunteers with medical skills). The application allows enrolling and characterizing volunteers, and through a survey, the application predicts the willingness of users to participate in a rescue of which they are notified by a smartphone application. As in the previous case, the paper does not give information about the architecture of the application, implementation, or about the performance evaluation.

There are applications for emergency management designed for P2P networks [4,32]. However, managing a P2P network requires implementing a distributed hash table (DHT) and communication protocols such as Pastry or Chord. Moreover, high peaks of workloads are difficult to manage, tending to saturate not only computation resources but also communication channels as messages travel from one peer to another until they reach their destination.

A classification model is used in [33] as part of a conceptual framework for the development of emergency applications. The authors evaluate the proposal using a model to select, classify, and prioritize tweet messages obtained from the Mexico 2017 earthquake for rescue operations. The authors do not report about the training time and about the execution time of the model. Moreover, the ability of the model to fit other datasets is not discussed.

Some applications collect data from real-time sensors and drones [34,35]. Sensors have been used in fixed [36,37,38] and mobile sensor networks [39,40] for environmental monitoring and for planning rescue operations. In particular, drones have been proven to be a useful tool to obtain a map to support searching in a post-disaster scenario [41]. In the same line, the work presented in [42] simulates disaster scenarios and analyzes data by using the unmanned aerial vehicle technology +BIM model’s monomer and visual information query. The authors propose using these technologies to look at the disaster data for planning and early warning. However, these kinds of applications do not include the participation of volunteers, the managing of rescue tasks, or the communication with victims.

Nowadays, bot-based software applications have been widely used in different areas such as journalism [43], where bots are used to personalize the information given to users. A user interacts with the bots, which delivers increasingly specific information through the use of questionnaires and machine learning techniques. These bots are typically implemented on Twitter, Facebook, and Telegram platforms. Bots are also used in the supply chain process [44] to analyze the user queries and provide information on the queried orders and supplies; they are also used in e-commerce and retail companies [45,46] where users can register, and then the bot shows catalogs, guides, shopping carts, reviews, tracks the purchases, and generates purchase orders; for medical assistance [11,47], virtual robots represented in a bot are used to communicate with patients and assist them in their routine needs; and they are also used for data collection [13,48,49]. In particular, the bot presented in [48] is designed to collect and validate real-time crowd-sourced flood users reports via social media (Messenger of Facebook bot or Twitter) to enhance the city’s resilience to extreme weather events. The system is deployed on Amazon Web Server (AWS) to support fault tolerance and scalability. However, none of these applications require processing a large amount of user requests as fast as possible without saturating the available resources.

As we explained before, bots are typically used to collect data from different users. In the context of crisis and disaster management, the authors in [13] present a framework for a disaster-related information retrieval system and immediate notifications to support the execution of mine safety procedures. The system utilizes instant messaging (IM) applications as the user interface to look up information and send messages to announce the occurrence of disaster events. Following the same idea of using bots to collect data, the authors in [49] present their experience of applying a bot-based system for the government of Taiwan for disaster response operations. In particular, they describe a framework for implementing a bot as the data management system. The bot is designed to answer questions containing keywords from a given list. If the user forgets the keywords, the application will not allow them to advance or give correct information. The paper evaluates the usability of the application by checking if people were able to finish the tasks. Bots can be also used to provide information after a natural disaster strikes. This is the case of the work presented in [50], which allows sharing videos with subtitles and sign language for deaf people to help them during the evacuations. The authors report a usability satisfaction level of 95% in deaf people and 60% in hearing people. In addition, the authors in [51] present a bot using Telegram to provide emergency information to foreign people in Japan. It includes evacuation information and real-time disaster information, and the real-time disaster information is based on the user’s current location. People can also share disaster-related pictures via the proposed application. People can share images of the disaster; however, it does not take into account, for example, whether the photos are real or if they are analyzed by experts.

In

Table 4. Main features presented by Ayni, Rimay, Jayma, and other applications presented in the technical literature. In the column Validation, we use the letter (A) if the experiments were performed on a real system, (B) with simulations and/or (D) with synthetic data. (C) indicates whether the application was validated by experts. In the column Type, we use the number (1) to indicate that a guideline is presented, (2) for applications or simulators that have been implemented, and (3) for papers presenting a model or proposal not actually implemented.

App/Ref.	Perf.	Usab.	Scal.	Fault Tol.	Validation	Type	Deployment
Rimay	Yes	−	Yes	Yes	(A), (C)	(2)	Parall./Distrib.
Ayni	Yes	−	Yes	Yes	(A), (C)	(2)	Parall./Distrib.
Jayma	Yes	−	Yes	Yes	(A), (C)	(2)	Parall./Distrib.
[13]	−	−	−	Yes	(A)	(2)	Distrib.
[22,23,24]	−	−	−	−	(B), (C)	(2)	Sequential
[25]	−	−	−	−	(B), (D)	(2)	Sequential
[27]	−	−	−	Yes	−	(3)	Distrib.
[28]	−	−	−	−	(C)	(2)	Sequential
[29]	−	−	−	−	−	(3)	Not Specified
[30]	Yes	Yes	−	−	(B)	(2)	Not Specified
[31]	−	−	−	−	−	(3)	Sequential
[32]	−	−	−	−	−	(2)	Distrib.
[33]	−	−	−	−	(B)	(1), (2)	Not Specified
[48]	−	−	Yes	Yes	−	(2)	Sequential
[49]	−	Yes	−	−	(C)	(1), (2)	Sequential
[50]	−	Yes	−	−	(C)	(2)	Sequential
[51]	−	−	−	−	−	(2)	Sequential

, we compare the main features presented by Ayni, Rimay, Jayma, and other bot-based applications designed for crisis situations such as natural disasters. The table summarizes which applications support fault tolerance (Fault Tol.), scalability (Scal.), if the authors present a performance evaluation taking into account botlenecks, critical tasks, and hardware resources (Perf.) and a usability evaluation (Usab.) of applications. The column Validation shows (A) if the experiments were performed on a real system, (B) with simulations and/or (D) with synthetic data. (C) indicates whether the application was validated by experts. In the column named Type, we use the number (1) for previous work presenting a guideline, (2) for applications or simulators that have been implemented, and (3) for previous work presenting a model or proposal not actually implemented. Finally, the column Deployment indicates if the applications can be executed sequentially, in parallel, and/or distributed or if it is not specified.

Notice that most of the previous works describe the application proposed, but they do not present experiments to evaluate their features. Moreover, previous works are typically focused on specific natural disasters and are not re-used later. In this paper, we evaluate the performance achieved by Ayni, Rimay, and Jayma, which also support fault tolerance, scalability, and can be executed in parallel and distributed data centers due to being built using common practice for distributed software architecture design. In particular, we use Dockers and Kubernetes technologies. Additionally, we execute the experiments on real systems, and we validate the tasks executed by each application based on expert consensus. To the best of our knowledge, no previous work studies the behavior and performance achieved by applications designed for natural disasters situations running on commodity hardware usually available from public organizations such as universities.

6. Discussion

The bots designed for Jayma, Ayni, and Rimay run on third-party platforms such as Messenger of Facebook and Telegram. These platforms apply some restrictions to prevent malicious uses and an inefficient user experience. In other words, they restrict the development and the execution of our applications as follows.

The bots of Ayni and Rimay, which use Telegram (https://core.telegram.org/bots/faq, accessed on 28 January 2022), are implemented with https. Telegram supports the upload of files up to 50 Mb each, and the maximum download of each file is 20 Mb. Additionally, we can send up to 30 messages per second to different users and 20 messages per second to the same group. This is a very strong restriction, as it limits the number of users we can reach per second during an emergency situation.

The bot of Jayma uses the Messenger (https://developers.facebook.com/docs/graph-api/overview/rate-limiting, accessed on 28 January 2022) of Facebook, which allows each user to send up to 250 messages per second to different recipients. However, it limits the number messages a given user can send to a given recipient per hour to 200. It supports a maximum upload of 25 Mb per file and a maximum of 2000 characters per message.

Therefore, the applications presented in this work are designed to meet the restrictions and recommendations of the external platform. However, if Messenger or Telegram fail, our applications will not be able to run. On the other hand, we choose to rely on these platforms because in case of emergency situations, people tend to use applications they are familiar with rather than to download, install, and learn how to use new applications, as shown in [7,8]. A comparative analysis of the use of applications for communication via messages compares WhatsApp, Viber, and Telegram in [8]. Despite the fact that Viber and Telegram presented better security properties, WhatsApp widely exceeds the number of users worldwide with at least 60% of users, this due to its popularity, ease of use, and its current support of Facebook. A study [7] with 4000 people showed that 70% use Facebook and 24% use Twitter. Facebook seems to be especially attractive to mobile users. Internet skills turn out to not be significant for the choice of use of Facebook, but it is only the mere choice of wanting to use it. Facebook use is influenced by age and gender. For Twitter, age and income influence its use but not gender and education.

7. Conclusions and Future Work

In this work, we evaluate the feasibility of using bots in three applications to collect the information of affected people and also to register spontaneous volunteers and to coordinate the tasks executed in different missions. In particular, we present a performance evaluation to detect the critical tasks and saturation points of the bot-based software applications. The first application called Jayma is designed to send a message to the contacts of the affected people with information about their status and location. The second application is designed to manage a set of events and tasks created by administrators and to coordinate volunteers who want to help. The third application, Ayni, is aimed at registering volunteers and managing emergency campaigns and tasks. The bots of these applications run on third-party platforms such as Messenger of Facebook and Telegram. This limits the number of messages we can send per second to the users. In addition, if these platforms fail, our applications will not be available. However, these are well-known platforms, and a person who can potentially participate as a spontaneous volunteer will be familiar with them and will not need to install any additional software.

We implement the applications as stateless and deploy them on a microservices-based platform with Kubernetes and Docker technologies. Therefore, the applications can be deployed and executed in parallel due to its replication capabilities and also on distributed environments. The platform architecture contains a front-end, a back-end, a bot-back-end, and a repository (database). We instrument the codes to obtain benchmarks of the tasks executed in each application that run on different resources.

We show that the applications are able to cope with critical mission requirements. This fact is shown throughout a comprehensive performance evaluation study on actual commodity hardware. To this end, we conduct experiments to analyze and evaluate potential bottlenecks and determine capacity in terms of the number of requests served per second in each of the applications. The validation of the tasks executed by the applications was based on expert consensus. The experiments on a single processor showed that the Ayni application supports less than 60 requests per second without crashing. With a higher number of requests per second, some tasks became unstable, and some requests did not complete. In this application, the CPU tends to saturate faster than other resources. In the Rimay application, the CPU is also a critical resource showing utilization levels close to 70%. Meanwhile, in the Jayma application, the RAM memory is the most critical resource, showing utilization levels close to 100%.

The results show that it is possible to build a software stack designed to support the execution of software applications that have properties for emergencies such as high availability, elasticity, fault tolerance, scalability, mobility (change data center dynamically), and multi-environment. All these features have not been included and evaluated in previous bot-based software applications. The multi-environment is satisfied by using bots of social media applications commonly used by people plus the use of Dockers that allow deployment on different operating systems and facilitate deployment in the cloud. Mobility is achieved by using Dockers and Kubernetes for application management and monitoring. Fault tolerance is achieved by using Kubernetes and Docker registry (Container Database), data replication, and volatile applications where data do not need to be recovered after a failure. Scalability is achieved by using Kubernetes. A configuration file allows generating replicas of the application and also stateless applications design.

As future work, we plan to include new communication channels between the users and other agents rather than friends or family to prevent disaster events that can propagate to other cities or communities such as blackouts or floods. We also plan to re-design the bots of the applications so they can be executed without third-party platforms such as Telegram. However, this will require disseminating the applications and training the population so that they will be prepared to use them. Finally, we plan to develop a capacity-planning methodology to automatically determine the number of replicas of each component of the applications to then efficiently deploy them in data centers provided by public organizations.