Design and implementation of a mobile device app for network-based earthquake early warning systems (EEWSs): application to the PRESTo EEWS in southern Italy

A fundamental feature of any earthquake early warning system is the ability of rapidly broadcast earthquake information to reach a wide audience of potential end users and stakeholders, in an intuitive, customizable way. Smartphones and other mobile devices are nowadays continuously connected to the Internet and represent the ideal tools for earthquake alerts dissemination to inform a large number of users about the potential damaging shaking of an impending earthquake.

Here we present a mobile app (named ISNet EWApp or simply EWApp) for Android devices which can receive the alerts generated by a network-based Early Warning system. Specifically, the app receives the earthquake alerts generated by the PRESTo EEWS, which is currently running on the accelerometric stations of the Irpinia Seismic Network (ISNet) in southern Italy. In the absence of alerts, EWApp displays the standard bulletin of seismic events that have occurred within the network. In the event of a relevant earthquake, the app has a dedicated module to predict the expected ground-shaking intensity and the available lead time at the user's position and to provide customized messages to inform the user about the proper reaction to adopt during the alert. We first present the architecture of both the network-based system and EWApp and then describe its essential operational modes. The app is designed in a way that is easily exportable to any other network-based early warning system.

1 Introduction

When an earthquake occurs the rapid assessment of its impact is essential for timely and appropriate emergency operations, such as securing people and crucial infrastructures exposed to serious damage effects. Earthquake early warning systems (EEWSs) are now starting to be considered as an effective strategy for real-time earthquake risk reduction. EEWS are real-time modern information systems aimed at providing rapid notification of the potential damaging effects of an impending earthquake, through the rapid telemetry and processing of data from dense instrument arrays deployed in the source region of the event of concern or surrounding the target infrastructure. A crucial feature of any EEWS is the ability to communicate rapid earthquake information to potential end users and stakeholders in a user-friendly, user-oriented, and customizable way. With the huge, increasing, worldwide spread of mobile cell phone technologies and wireless Internet connection, smartphones are the ideal candidates for receiving broadcast alerts.

Several operational worldwide EEWSs are now releasing earthquake alerts leveraging smartphone technologies, with dedicated applications which may leverage the smartphone as a broadcasting target or may even transform it into a seismic detector. Japan is the leading country for earthquake early warning (EEW) development. The current Japanese EEWS, operated by the Japan Meteorological Agency (JMA, https://www.jma.go.jp/jma/indexe.html, last access: 1 April 2020) has several broadcasting channels, including television, radio, Internet, dedicated EEW-capable devices and cell phone devices. Since October 2007, the three major mobile phone companies in Japan have developed a broadcasting system to send multiple users an SMS of the EEW. Also, it is mandatory for 3G cell phones sold after 2007 to receive the warnings issued by JMA and release EEW notifications.

Another example of the use of smartphones for EEW is the MyShake app (Kong et al., 2016), which was recently developed by the EEW research group at the University of California, Berkeley. The MyShake app has the ability to recognize earthquake shaking from background noise using the sensors in every smartphone. When a potential earthquake is detected by a single smartphone, its app sends the collected data to a centralized processing hub. Aggregating the information of the multiple recording devices in the nearby area, a network detection algorithm may confirm or cancel the presence of an ongoing earthquake and possibly provide its location and magnitude. Source parameters are then used to estimate the shaking intensity and the available lead time at any target location.

After the 2011 Tōhoku earthquake in Japan, Taiwan also started to develop the Cell Broadcast Service (CBS) for disclosing emergency alerts to the public. Since May 2016, the Central Weather Bureau (CWB) has been the main central agency for issuing earthquake disaster alerts in Taiwan for events with a magnitude greater than 4.5 occurring in and around Taiwan. The Central Weather Bureau further developed four apps (in Chinese) which have been released for free by private developers, in cooperation with CWB. Users can receive real-time notifications of the location and magnitude of an earthquake and the earthquake's intensity in different areas (Chang, 2018).

In Mexico, the official earthquake alerting system is run by the government-funded nonprofit agency CIRES (http://www.cires.org.mx/index_in.php, last access: 1 April 2020), which was created after the 1985 Mexico City earthquake that killed thousands of people in the country. Based on about 100 sensors, mostly deployed along the Pacific coast of Mexico, CIRES transmits earthquake early warning alerts through a network of VHF stations and offers alert systems for buildings and personal use. More than 90 000 users in Mexico City, including almost all public schools, have CIRES receivers. The Mexico City Metro additionally receives SASMEX alerts (Suárez et al., 2018), although not for public dissemination but instead to stop trains or delay departures as necessary. More recently, in 2013, a private company, Sky Alert, former partner of CIRES, developed its own earthquake early warning system which warns people through a mobile app (https://skyalert.mx/, last access: 1 April 2020). When an earthquake is detected by the closest SkyAlert sensor of a nationwide seismic network, the recorded shaking intensity is evaluated and confirmed by the nearby recorders and a broadband alert signal is sent to the control center of SkyAlert. The alert is then shared through the MS Azure cloud, which broadcasts the message to all the SkyAlert app users, triggering a loud sound, a vocal message of the seismic alert and a text message with the information about the size of the earthquake. Since the two large earthquakes that hit Mexico in September 2017, SkyAlert has doubled its users to 5.8 million, making it one of the country's most downloaded apps.

In Europe, several cell phone applications have been developed by local and national agencies (for example INGV, http://www.ingv.it/it/, last access: 1 April 2020; EMSC, https://www.emsc-csem.org/, last access: 1 April 2020), with the major purpose of releasing earthquake information to a massive number of smartphone users in the minutes following a relevant seismic event. Most of these apps operate as a standard seismic bulletin by collecting and reporting the earthquake information as released by the reference agency. Common additional features are generally implemented, such as the possibility of activating customized notifications in the case of a significant earthquake occurring near the selected target location or, for the largest events, occurring at any distance from the user. Another relevant feature of these apps is the possibility for the users to provide their feedback after experiencing an earthquake, such as the level of shaking perceived. This complements the traditional methods of collecting data (i.e., using traditional seismic instrumentation) with information easily obtained through the Internet for an improved mapping of the damage area in the minutes after a seismic event.

The Earthquake Network project (Finazzi, 2016) started in 2013 with the aim of networking cellular phone users living in active seismic areas in order to provide a rapid earthquake alert based on the strong shaking recorded by the smartphones' built-in accelerometric sensor. The project has a similar objective to that of the Quake Catcher Network project (Cochran et al., 2009) and the Community Seismic Network monitoring system (Clayton et al., 2011). When the smartphone detects a vibration, it sends a signal to a central server network with information about the location of the smartphone. The central server checks whether the number of received signals is anomalous and high relative to active smartphones located in the same area, and in that case an earthquake warning is issued to the network.

Within this context, we developed a mobile app for Android devices (smartphones, tablets and smartwatches) to receive the broadcast alerts issued by PRESTo (Satriano et al., 2010), which is the EEWS currently operative in southern Italy, aimed at detecting small to moderate earthquakes occurring in the Campania–Lucania Apennine region. The mobile app has the main purpose of informing a wider community of smartphone users about the incoming arrival of ground shaking due to earthquakes occurring in the target region, which represents one of the highest-seismic-risk areas of the country. Moreover, in the absence of earthquakes, as is provided by existing, similar seismological apps, the standard bulletin of the events detected by the network, with all the available earthquake source information, is provided. We first synthetically describe the network infrastructure and PRESTo EEWS and then discuss the functionality, the scientific methodologies and the architecture of EWApp.

2 Scientific background and infrastructure – the Irpinia Seismic Network and PRESTo EEWS

The EWApp described here has been originally conceived to be interfaced with any regional, network-based early warning (EW) system, and it can receive and elaborate standard output parameters from various EW platforms, such as PRESTo (http://www.prestoews.org/last access: 1 April 2020), Virtual Seismologist (Cua and Heaton, 2007) and ElarmS (Allen, 2007). Here we focus on and describe the interaction of the EW app with the ISNet and the PRESTo EW system.

The Irpinia Seismic Network (ISNet; Weber et al., 2007; Iannaccone et al., 2009; Fig. 1) is a dense local network of strong-motion, short-period and broadband seismic stations deployed along the southern Apenninic chain covering the seismogenic areas of the Irpinia region. The area is one of the highest-seismic-risk regions of the Italian territory and is the location of several moderate to large earthquakes that have occurred in the last few centuries, including the 23 November 1980 event, M_s 6.9, and the 1996 (M 5.1), 1991 (M 5.1) and 1990 (M 5.4) events. The seismic network is composed of 30 real-time stations which continuously monitor the background seismicity and transmit the recorded signals to a dedicated control center. The stations are organized in subnets, each of them is composed of a maximum of six to seven stations. The stations of a given subnet are connected with real-time communications to a central data collector or local control center (LCC). The different LCCs are linked to each other and to a network control center (NCC) with different types of transmission systems. The whole data transmission system is fully digital over TCP/IP, from the data loggers through the LCC to the NCC, which is located in the city of Naples, 100 km away from the network center. To ensure a high dynamic recording range, each seismic station is equipped with a strong-motion accelerometer and a three-component velocity meter (natural period 1 s). In five station locations the seismometers are replaced by broadband (0.025–50 Hz) sensors to guarantee high-quality recording of teleseismic events.

Figure 1 Map of the Irpinia seismic area and of the ISNet. The background color shows the seismic-hazard map for the considered area (Meletti and Montaldo, 2007), and the white rectangles are the main faults of the active fault system present in the region (Colliano, San Gregorio Magno and Pescopagano faults, from the Database of Individual Seismogenic Sources). Light grey triangles are the real-time stations, while dark inverted triangles are the local control centers (LCCs). The major cities of the region are also shown on the map.

The EEWS PRESTo is currently operative in the Campania–Lucania Apennine region to rapidly detect and characterize the small to moderate earthquakes occurring in the area. PRESTo (PRobabilistic and Evolutionary early warning SysTem; Satriano et al., 2010) is a software platform for EEW that integrates algorithms for real-time earthquake location, magnitude estimation and damage assessment into a highly configurable and easily portable package. PRESTo continuously processes the live streams of three-component acceleration data from the stations for P-waves arrival detection, and, while an earthquake is occurring, it promptly performs the event detection, location, magnitude estimation, damage zone assessment and peak ground motion prediction at predefined target sites (see Sect. 3 for details; Fig. 2).

Figure 2 Scheme of PRESTo operations and in–out connections. The figure shows a simplified scheme of PRESTo, illustrating the steps of the software which are mostly relevant to EWApp (i.e., event detection, event location and magnitude estimation). Three output channels are currently available for PRESTo, while EWApp represents an additional output mode (through the ActiveMQ message broker).

Following the idea of similar tools, such as the user display (Böse et al., 2014) and the earthquake early warning display (Cauzzi et al., 2016), our EWApp is able to further elaborate the alerts generated by the backbone infrastructure, accounting for the current geographical position of the user in order to compute the amplitude and arrival time of damaging seismic waves. In this way, the app represents an independent tool to compute the expected shaking that does not require the intensity as an input parameter but only basic source information (i.e., location and magnitude) of an ongoing event, as provided by any standard EEW platform. EWApp, developed in Java, is the client of a client–server system called EWAppSystem. Once installed, EWApp continuously runs in the background mode on Android devices and starts releasing alert notifications as soon as an earthquake is detected by PRESTo. During an earthquake, a key feature of EWApp is a specific module to predict the expected level of ground shaking at the target location, within a maximum distance of 200 km from the epicenter position. In this way, the potential area of interest for the EWApp users covers both the Irpinia seismic region and the surrounding area.

3 EWApp – methodologies and graphical user interface

EWApp has a double operation mode: it can operate in passive mode (as a seismic bulletin) and in active mode (as a warning device). The block diagram of Fig. 3 shows an overview of the whole system with an illustration of the main steps and links of the app, while the specific features of each operation mode are described in detail in the following dedicated sections. The app is available in two languages (English and Italian), and when installed, the current language of the running operating system is automatically selected. At the first installation of the app, the user can select from two options. The first one is to use a fixed position, while the second one is to activate the location function in order to have continuously updated position measurements for a reliable computation of the distance from the source and, therefore, of the expected shaking. If the location service is not enabled, the app will use the last-available position of the smartphone. In both cases, to guarantee privacy policies, the user's location is hidden from the developers.

Figure 3 Block diagram of EWApp with its operation modes. The left side shows the passive mode, in which no relevant event is detected from PRESTo and the app works as a standard seismic bulletin. The right side of the block diagram illustrates the various steps and operations during the active mode, both in the case of a distant event and in the case of a close event.

3.1 Passive mode

The first mode (passive mode) is similar to a standard seismic bulletin and allows for the visualization of seismic events that could be of interest to the smartphone user. When operating in the passive mode, the app duplicates the list of the events recorded by the ISNet that have occurred within 200km of the user's position. The events are included in the app bulletin after they have been manually revised by the operator (typically, the day after the occurrence). The earthquakes can be sorted by choosing from three available options: date (origin time), distance from the current position of the user or magnitude (Fig. 4a). As the user taps on an event in the list, the relevant features of each earthquake are available to the user. Specifically, for each earthquake, EWApp shows the current user position and the epicenter on a map, together with origin time (both local and UTC time), local magnitude, epicentral coordinates (latitude and longitude), hypocenter depth and distance from the current user position (Fig. 4b).

Figure 4 Passive operation mode and earthquake bulletin. The figure shows screenshot examples of the app when working in passive mode. Panel (a) shows the earthquake bulletin with its main functions (sorting, bug reports). Panel (b) shows the details of an event, which appear when tapping on a specific earthquake. The map was created using OpenStreetMaps (© OpenStreetMap contributors 2020. Distributed under a Creative Commons BY-SA License).

3.2 Active mode

When an earthquake is detected by PRESTo, the app starts working in the active mode. The input data are the evolutionary estimates of source parameters, as released by PRESTo and consisting of the estimates of the earthquake location (hypocentral coordinates and origin time) and magnitude. Specifically, the earthquake location uses an advanced, evolutionary real-time technique based on an equal differential time (EDT) formulation and a probabilistic approach for defining the hypocenter (RTLoc; Satriano et al., 2008), using both the information from triggered arrivals and not-yet-triggered stations. Magnitude estimation is based on the evolutionary measurement of peak ground-displacement amplitudes, measured over the first 2–4 s of signal starting at the detected P-wave arrival and the estimated S-wave arrival and using an empirical relationship that correlates the final event magnitude with the logarithm of the initial peak amplitude (RTMag; Zollo et al., 2006).

As soon as the first output estimates are released by PRESTo, the app receives these input data and starts computing its own further estimates. The theoretical arrival time of the S-wave are first computed at the user position, by assuming a homogeneous velocity model for the wave propagation (v_s=3.3 km s⁻¹). Then, using the estimates of location and magnitude and a standard ground motion prediction equation (GMPE; Bindi et al., 2011), the expected level of ground shaking, in terms of peak ground motion (PGV), is computed at the user position. Depending on the distance from the user and on the predicted PGV value, the app can decide whether to issue an alert or not.

In the case of an earthquake far from the user (i.e., hypocenter ≥200 km from the user position), independently of the expected intensity, a push notification (with default sound and vibration) warns the user that a seismic event has occurred within the ISNet, although its impact at the user site is negligible (Fig. 5a). When tapping on the push notification, the relevant event parameters are available in a dedicated list of received PRESTo alerts (in the same format as those available in the standard ISNet bulletin).

Figure 5 Active operation mode with no alert. The figure shows screenshot examples of the app when working in active mode with no alert activation. Panel (a) shows the case of a distant event, while panel (b) shows the case of a closer event for which the expected shaking does not exceed the threshold. In both panels, the top image shows the pop-up notification that appears on the screen when the event occurs. The map was created using OpenStreetMaps (© OpenStreetMap contributors 2020. Distributed under a Creative Commons BY-SA License).

In the case of a closer earthquake (i.e., hypocenter <200 km from the user position), depending on the comparison between the expected intensity ($I_{\mathrm{MM}}^{\mathrm{pred}}$) and the threshold intensity value ($I_{\mathrm{MM}}^{\ast }$), two situations are possible: no alert and alert. For the specific application to the Irpinia seismic region, the threshold level for the alert declaration is currently set to I_MM=4, which corresponds to a level of perceived shaking, based on the PGV-to-I_MM conversion table from Faenza and Michelini (2010).

$$I_{\mathrm{MM}}^{\mathrm{pred}}<I_{\mathrm{MM}}^{\ast }=\text{no alert}$$

If the predicted intensity does not exceed the threshold value, a simple push notification appears on the display, with information about the hypocenter position and expected shaking level (negligible or weak; Fig. 5b). As in the previous case, when tapping on the push notification, the bulletin information is shown (list of received alerts).

$$I_{\mathrm{MM}}^{\mathrm{pred}}\ge I_{\mathrm{MM}}^{\ast }=\text{alert}$$

When the predicted intensity exceeds the threshold level, the alert mode is activated. From this moment on, the alert levels are progressively updated every second, based on the estimated outputs of location and magnitude of the event from the EW system. Depending on the earthquake location and relative distance to the user position, the display shows the countdown with the available lead time (e.g., the time available for safety actions before the arrival of strong shaking waves) and the predicted level of intensity. The lead time is computed as the remaining seconds before the arrival of S-waves and is also updated every second. To avoid jumps and discontinuities in the displayed parameters due to small changes in the earthquake location, the alert message is updated only when the estimated intensity changes (both increasing or decreasing intensities are possible). In this case, the countdown is also updated if the real-time current lead-time value differs from the previous one by more than 5 s. As for the alert cancellation, following the same strategy adopted by PRESTo, the app does not include the possibility of canceling the alert once it has been released. In the case of an expected intensity starting high and then dropping below the threshold, the user will keep on seeing the alert message on the display but with a smaller estimated value of intensity.

During the alert, the smartphone display shows a map with the epicentral position of the event; the position of the user at the current time; and two other essential pieces of information, which are the countdown (available lead time at the user's position) and the expected intensity. This last value is given both in roman numbers and in the form of a text description, such as intense, strong or weak, following the intensity-scale definition of Faenza and Michelini (2010). The countdown and the expected intensity are shown on the display and are also announced by the voice message. Then, in the last 5 s of the warning, an additional voice message saying “save yourself” is given. Such a communication format provides the most relevant pieces of information (shaking and time) both in the form of text and in the form of sound, thus allowing any user in a generic condition or location to properly react, with no distinction between indoor and outdoor positions. For the entire duration of the alert and until the expected arrival of the S-waves, the icon picture showing the “Drop, Cover and Hold On” behavior is also shown at the bottom of the screen, but no related instructions are given by the voice message. This is a standardized alert message, suitable for indoor EW applications (Fig. 6a, b).

Figure 6 Active operation mode during an alert. The figure shows screenshot examples of the app when working in active mode during an alert. Panels (a) and (b) show the expected shaking (VI, strong), the countdown and the instructions on how to behave that appears on the screen during the event. Panel (c) shows a screenshot of the screen once the earthquake has finished and the ground shaking has passed. Two buttons (green and red) appear on the screen to easily communicate the user's condition and position to a list of predefined contacts. The map was created using OpenStreetMaps (© OpenStreetMap contributors 2020. Distributed under a Creative Commons BY-SA License).

A fundamental, innovative feature of EWApp is the identification of the end of the event to warn the smartphone users that the strongest shaking has passed and the emergency time has finished. To this purpose, the app includes an ad hoc module that theoretically computes the expected end of shaking, based on the estimated magnitude of the event. The duration of the shaking (τ_shake) is defined as the time interval between the arrival of the P-wave and the moment at which, after reaching the peak, the ground velocity decreases back down to a predefined threshold value. The threshold value is set to 0.2 cm s⁻¹, which is the lower threshold for the level of macroseismic intensity equal to 4, based on the PGV intensity regression of Faenza and Michelini (2010), and is associated with a perceived level of “light” shaking. For each earthquake, the duration of the shaking (τ_shake) is computed as

$$\begin{array}{}\text{(1)}& \log \left({\mathit{\tau }}_{\mathrm{shake}}\right)=a+bM,\end{array}$$

where M is the estimated magnitude of the ongoing event (as provided by PRESTo) and a and b are empirically derived coefficients. The coefficients have been established based on the analysis of a large dataset of earthquake records from Italian and Japanese earthquakes, in the magnitude range between 3.5 and 9 and in the distance range from 0 to 200 km, which is the regional distance range the app is targeted to, for a total of 4036 three-component records. For each available record, we measure the shaking duration (τ_shake) on the horizontal components of the ground velocity (as vector composition) and determine its scaling with magnitude. For the analyzed data, indeed, we found that the duration of the shaking mainly depends on the earthquake magnitude and has no significant dependency on the source-to-receiver distance (see Fig. S2 in the Supplement). The same assumption is also used by other authors when computing the duration of a seismic event for local and regional distances (Bindi et al., 2005; Castello et al., 2007; Del Pezzo et al., 2003; Real and Teng, 1973). The Supplement contains the full theoretical explanation and the details of the computation of the shaking duration. For our data we found $a=-\mathrm{0.58}$ and b=0.35 (Fig. 7).

Figure 7 Shaking duration vs. magnitude. The figure shows the average shaking duration as a function of magnitude, on a log-linear scale. For each magnitude bin (0.5), the average value and its standard error is shown with a light grey circle and error bars. The solid line is the best-fit line, corresponding to the equation shown in the top left corner of the plot.

Finally, when the alert expires, the user has the possibility of choosing a health condition and communicating it to a list of predefined contacts. To this purpose, two intuitive buttons are positioned on the screen to communicate a safe state (green button, “I am fine”) or to ask for a help (red button, “I need help”; Fig. 6c). In both cases, EWApp obtains the current geographical position and sends a standardized text message to a list of contacts, including the position and condition of the user. The contact list can be created when EWApp is installed on the smartphone for the first time and can be changed later using a dedicated functionality within EWApp. Finally, the standardized text message can also be shared through the most common social network platforms, such as Facebook and Twitter, if the user's personal accounts are available.

4 Early warning app implementation and system architecture

PRESTo sends real-time alert messages as soon as an earthquake is detected and its source parameters (e.g., location, origin time and magnitude) are estimated. A new message is also sent as soon as those estimates change (they improve with time as new information is available), thus making the last message the most authoritative. Each message is encoded in a standard and flexible format used in seismology, QuakeML (http://www.quakeml.org, last access: 1 April 2020). The QuakeML message is sent to a message broker (such as ActiveMQ, http://activemq.apache.org/, last access: 1 April 2020) using the STOMP protocol (https://stomp.github.io/, last access: 1 April 2020). The message broker server is then able to broadcast the message to a large number of connected clients.

In practice, however, mobile devices are usually not configured to maintain a permanent connection to the Internet in order to avoid consuming the battery excessively. Moreover, they are not able to process and display in real-time a set of alert messages sent within a few tens of milliseconds, like those that can be generated by PRESTo during the processing of a single earthquake. For these reasons, to make sure that the smartphones receive them in real-time, the alert messages must be sent through a cloud messaging service such as Firebase Cloud Messaging (FCM), requiring an Internet connection (Fig. 8). The alerts sent via FCM can wake the device even when it is in standby, thus starting the process illustrated in the previous paragraph. To reduce the number of broadcast messages (in order to avoid excessive network traffic and improve scalability) it is necessary to apply a filter that selects the messages to be sent based on their relevance (e.g., maximum one message every second, the magnitude or the hypocentral distance between two consecutive sent messages must vary appreciably). To filter the incoming messages and to send them to FCM, a server proxy component called Middleware-EWApp (MEWApp) has been implemented. MEWApp is Python software that processes the incoming messages received from PRESTo via ActiveMQ, applies the above filtering criteria, extracts the most relevant information (location, origin time and magnitude), and formats them into an FCM message and sends them to the FCM cloud service. FCM is then responsible for forwarding these messages to all the installed EWApp apps which carry out the computational scheme described above, such as the shaking calculation based on the user position. Finally, the use of an FCM server for managing the alert delivery allows for handling the issue of alerting a large number of users, with no need for big hardware or software infrastructures.

Figure 8 Architecture of EWApp. The figure is a schematic representation of the whole architecture, involving the network of stations, the EW software (ISNet and PRESTo EW platform) and EWApp. PRESTo processes the ISNet station waveforms, sending evolutive earthquake information messages (in QuakeML format) to a message broker (ActiveMQ). The middleware (MEWApp) releases earthquake information to the FCM cloud that broadcasts it to all the EWApp installations. EWApp also downloads the revised ISNet bulletin on request.

5 Performance analysis

We carried out a set of tests to quantify the performance of EWApp in terms of latency times and successful delivery rate. Specifically, we measure the latency between the time of the alert as sent by the middleware app and the calculation of the expected intensity and lead time by EWApp, as explained below.

For each message i sent by the FCM and received by the smartphone, the total latency (Delay) introduced by the app can be obtained as the difference between the time of the reception of the message (T_{IN_i}) and the time of the output parameter release (T_{OUT_i}):

$${\mathrm{Delay}}_{\mathit{\_}i}=T_{\mathrm{OUT}\mathit{\_}i}-T_{\mathrm{IN}\mathit{\_}i},$$

where T_{IN_i} is the time at which the message is sent by FCM to the smartphone, T_OUT is the time at which the output parameters computed by EWApp are available and released, and i represents each available measurement.

By definition, the total latency is positive and contains the computational latency due to the smartphone operations, the time required to call the web service, and the delay between the sending of the message by the middleware server and the actual sending by FCM to the smartphone.

For the testing phase, we used a sample of nine Android smartphones with heterogeneous technical and usage characteristics. We collected data by automatically sending test alerts to all the available users for 15 d, including both weekdays and weekends. As a test earthquake, we used the M_w 6.9 1980 Irpinia earthquake, which is the strongest event that has occurred during the last 4 decades in the region of interest and represents the target event of our EEWS. The playback test consisted of sending 36 messages in the form of a random swarm (one to four events every 30 to 40 s, randomly created). Each swarm is repeated with a random period of between 6 and 9 min, for a total number of 38 808 alert events. For each available alert, we measure the total latency, as defined above. Figure 9 shows the percentage histograms of the total latency. We characterize the unimodal, nonsymmetric distribution with its mode value equal to 1.034 s and representing our best estimates of the latency introduced by EWApp.

Figure 9 Performance of EWApp in terms of total latency. The figure shows the percentage histograms of the total latency. The distribution is unimodal and nonsymmetric, with a mode value equal to 1.034 s.

Following a similar logic that has been used for the latency computation, we estimated the delivery rate as the difference between the number of received messages and the number of output messages as released by the smartphones. In this case, the test was conducted in a different way, to avoid any potential crowding of the FCM server, which could produce frequent lost messages, resulting in a nonrealistic estimate of the delivery rate. We used the same sample of nine Android smartphones, ensuring that all the smartphones were turned on during the experimentation, and sent a total number of about 1200 alert simulations. Single smartphone delivery rate values range from 41 % to 98 %, with an average value of 80 %.

It is worth noting that, both for the latency time and for the delivery rate, the observed performance is strongly affected by the use of the standard FCM cloud. Compared to a custom, dedicated solution, this has the advantage of being free, supported by default and tightly integrated into the Android platform; for instance it allows message delivery even when the smartphone is in sleep mode. On the other hand, we cannot control or improve the policies and limits on message dissemination by the service.

6 Discussion and conclusions

We developed an intuitive and user-friendly app for Android mobile devices, which is able to receive and elaborate standard output parameters from a network-based EW platform and send earthquake notifications, including alerts for expected strong shaking and a potentially damaging earthquake at the user location. EWApp is highly flexible, and, in principle, it can interact with various EW platforms (such as PRESTo, Virtual Seismologist, ElarmS), as long as the output parameters are provided in a standardized format (QuakeML). Whichever the EW platform is, the EWApp developed here is conceived to be a broadcasting channel of earthquake alerts and requires a backbone infrastructure for data collection, streaming and analysis. Here we tested EWApp and its interface with ISNet and PRESTo EW software. Specifically, we distributed the app to a limited number of academic users (within the RISSC-Lab group and the Department of Physics “Ettore Pancini” at the University of Naples Federico II) to verify its basic functionalities and receive feedback from the users.

With this aim, we have already included in the app the possibility for the users of sending general feedback to the developers. For a wider release of the app, we will prepare a dedicated questionnaire, with specific questions about the basic functions of the app. We will ask the users to fill it and will possibly modify the app according to their suggestions.

Consistently with what is done by similar apps, once an earthquake is detected (by PRESTo EEWS, in our case), the EW app is able to geolocate the user position and use it to decide in real-time how to operate, i.e., whether to issue the warning or not. A relevant feature of the app is an intelligent decision module which receives the standard output parameters from the core EW infrastructure, elaborates them and computes the expected intensity at the user position. Depending on the distance from the event and on the expected damage potential, EWApp activates personalized alert messages, containing the available lead time and the predicted level of intensity, as well as instructions on mitigating actions for the users. The estimates are continuously updated and refined with the passage of time, and the warning mode remains active as long as the ground shaking is ongoing.

An additional, and the most innovative, feature of EWApp is the two-way flow of information to and from the user, which allows for the receiving of (as input) the real-time earthquake parameters from the EW core platform and the communicating of (as output, with a dedicated module) the state of health and condition of the user after the alert period (expected shaking duration) has ended. This functionality is of extreme relevance, especially in the context of densely populated areas (such as urban areas, big industrial settlements), to the collecting of the condition of people at the end of the event for efficient planning of the rescue operations.

In a prospective new release of EWApp, several features could be implemented with special regard to the user's health monitoring. For example, the app could be interfaced with a decision-and-control expert system, combining the outputs from the regional EEWS with information from local monitoring devices (sensors), for broadcasting personalized safety instructions and customized alert messages, depending, for example, on the location of the personnel inside a given area (or inside a building). Moreover, the current geolocation functionality could be further improved, by adding the possibility of tracking the position and condition of people before, during and after the earthquake occurrence. This could be carried out using the user's device, for example, by coupling accelerometric data recorded by the smartphone to monitor the user's movements with data related to the operation and use of the device itself (i.e., web access, active calls, outgoing messages). Additionally, the position and condition of the user as monitored by the smartphone could be coupled with some other health status parameters, as provided by different devices, such as heartbeat and blood pressure sensors. In both cases, intelligent neural-network algorithms, specifically trained, could be used to identify a condition of inactivity and quiescence, which could be synonymous with users in dangerous conditions or potentially trapped under the earthquake ruins.

EWApp is currently conceived so as to receive source parameter estimates from a network-based EW platform. An additional, parallel module could be easily included in the app to receive ground-shaking parameters from a single-station, on-site, independent EW platform. In this case, EWApp would directly receive simplified pieces of information from the EW platform in the form of alert levels, quantifying the occurrence of a large or small earthquake that is distant from or close to the user position (Zollo et al., 2010).

As for the public release of the app, the app has been developed to be the front end of PRESTo EEWS, as an additional way of disseminating the alerts released by the system to the users in the area of interest of the regional network, where the ISNet monitoring infrastructure is deployed. PRESTo is currently running in an experimental phase, and a limited number of selected users are receiving alerts through SMS and emails. For EWApp, we foresee a similar prototypal experimentation, with an initial involvement of a restricted number of specialized users, who will provide feedback to correct potential malfunctions of the tool. Then, within the framework of national and European projects and initiatives related to the EEWS, we will gradually increase the number of users, including public stakeholders and citizens. For example, some schools in the Campania–Lucania region where the EEWS is running could be selected as initial experimenters to test a wider release of the app. For the public release, we will also involve a dedicated team of expert social scientists to find out the optimal way of communicating alerts.

Finally, another prospective idea that could be implemented in a new release of the app is to include a “drill-test mode”, which involves the possibility of running playback and scenario earthquakes from a dedicated list of events in order to test, for example, the procedures for the evacuation of people from buildings and/or densely populated areas. To this purpose, an upgraded version of the app could be specifically developed and released to advanced users only (such as private and public stakeholders and end users). This version could be linked to dedicated software, allowing the activation of the playback mode and the collection of confidential data related to the user's position and reaction to the drill, which could in turn be analyzed by expert social scientists to delineate the profile of the community involved in the drill.