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 1Map 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 2Scheme 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).

Download

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.

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 3Block 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.

Download

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 4Passive 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 5Active 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 6Active 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 7Shaking 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.

Download

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.

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 8Architecture 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.

Download

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}):

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 9Performance 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.

Download

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.

Active faults for the Irpinia region are taken from the Database of Individual Seismogenic Sources (DISS), available at https://doi.org/10.6092/INGV.IT-DISS3.2.1 (DISS Working Group, 2018). Data for Italian earthquakes are made freely available by the ITalian ACcelerometric Archive, ITACA 3.0 (https://doi.org/10.13127/itaca.3.0; Luzi et al., 2019). We acknowledge the Japanese National Research Institute for Earth Science and Disaster Prevention (NIED) for making the KiK-net and K-NET strong-motion Japanese data accessible through their website (http://www.kyoshin.bosai.go.jp/; NIED, 2020). Most of the analysis and figures were made using Gnuplot (http://www.gnuplot.info/, last access: 1 April 2020), Seismic Analysis Code (Goldstein et al., 2003; http://www.iris.edu, last access: 1 April 2020), the Generic Mapping Tools software (Wessel and Smith, 1995; https://www.soest.hawaii.edu/gmt/, last access: 1 April 2020) and OpenStreetMaps (© OpenStreetMap contributors; https://www.openstreetmap.org/copyright/en, last access: 1 April 2020).

The supplement related to this article is available online at: https://doi.org/10.5194/nhess-20-921-2020-supplement.

SC wrote the manuscript, performed the analysis of data and prepared the figures; FC developed and implemented EWApp; FC and LE built the link between the EWApp and the backbone infrastructure; AZ contributed to the manuscript conception, design and preparation. All authors equally contributed to the scientific discussions on the implementation of the app and to the manuscript revision.

The authors declare that they have no conflict of interest.

This research has been supported by the University of Naples Federico II; the Italian Ministry of University and Research (MIUR), within the program PON R&I 2014–2020 – Attraction and International Mobility (AIM) – project no. E66C19000090001; and the Horizon 2020 INFRAIA-01-2016-2017 action SERA (grant agreement no. 730900).

This paper was edited by Thomas Glade and reviewed by two anonymous referees.