Earthquake Early Warning ShakeAlert 2.0:
Public Rollout
Monica D. Kohler
*1
, Deborah E. Smith
2
, Jennifer Andrews
3
, Angela I. Chung
4
, Renate Hartog
5
, Ivan
Henson
4
, Douglas D. Given
2
, Robert de Groot
2
, and Stephen Guiwits
2
Abstract
Cite this article as
Kohler, M. D.,
D. E. Smith, J. Andrews, A. I. Chung,
R. Hartog, I. Henson, D. D. Given, R. de
Groot, and S. Guiwits (2020). Earthquake
Early Warning ShakeAlert 2.0: Public
Rollout,
Seismol. Res. Lett.
XX
,1
–
13,
doi:
10.1785/0220190245
.
Supplemental Material
The ShakeAlert earthquake early warning system is designed to automatically identify
and characterize the initiation and rupture evolution of large earthquakes, estimate the
intensity of ground shaking that will result, and deliver alerts to people and systems
that may experience shaking, prior to the occurrence of shaking at their location. It is
configured to issue alerts to locations within the West Coast of the United States. In
2018, ShakeAlert 2.0 went live in a regional public test in the first phase of a general
public rollout. The ShakeAlert system is now providing alerts to more than 60 institu-
tional partners in the three states of the western United States where most of the
nation
’
s earthquake risk is concentrated: California, Oregon, and Washington. The
ShakeAlert 2.0 product for public alerting is a message containing a polygon enclosing
a region predicted to experience modified Mercalli intensity (MMI) threshold levels that
depend on the delivery method. Wireless Emergency Alerts are delivered for M 5+
earthquakes with expected shaking of MMI
≥
IV. For cell phone apps, the thresholds
are M 4.5+ and MMI
≥
III. A polygon format alert is the easiest description for selective
rebroadcasting mechanisms (e.g., cell towers) and is a requirement for some mass noti-
fication systems such as the Federal Emergency Management Agency
’
s Integrated
Public Alert and Warning System. ShakeAlert 2.0 was tested using historic waveform
data consisting of 60 M 3.5+ and 25 M 5.0+ earthquakes, in addition to other anomalous
waveforms such as calibration signals. For the historic event test, the average M 5+ false
alert and missed event rates for ShakeAlert 2.0 are 8% and 16%. The M 3.5+ false alert
and missed event rates are 10% and 36.7%. Real-time performance metrics are also pre-
sented to assess how the system behaves in regions that are well-instrumented,
sparsely instrumented, and for offshore earthquakes.
Introduction
The goals of the ShakeAlert earthquake early warning (EEW)
system for the West Coast of the United States, like other sim-
ilar systems around the world, are to automatically identify and
characterize an earthquake rapidly after it begins, estimate the
intensity of ground shaking that will result, and deliver alerts to
people and systems that may experience shaking (
Given
et al.
,
2014
,
2018
;
Kohler
et al.
, 2018
). Its objective is to issue alerts
for a defined level of ground motion before that ground motion
occurs at a user
’
s location. The U.S. Geological Survey (USGS),
together with partner organizations, has been developing and
operating ShakeAlert for the highest-risk areas of the United
States by leveraging the current earthquake monitoring capa-
bilities of the Advanced National Seismic System (ANSS;
USGS, 2017
).
In 2018, ShakeAlert went live in a regional public test of the
first phase of a general public rollout (hereafter, referred to as
“
ShakeAlert 2.0
”
). This event was preceded in 2016 by the
Production Prototype version (referred to as
“
ShakeAlert
1.0
”
;
Kohler
et al.
, 2018
), which went live in California only,
and began providing notifications to a limited group of about
20 early adopter community participants through pilot imple-
mentations. In 2017, Production Prototype 1.2 went live to a
small group of community participants on the entire West
Coast (California, Oregon, and Washington). The ShakeAlert
system is now providing alerts to institutional users such as
transportation systems (e.g., Bay Area Rapid Transit, Los
Angeles County Metropolitan Transportation Authority) and
1. Department of Mechanical and Civil Engineering, California Institute of
Technology, Pasadena, California, U.S.A.; 2. U.S. Geological Survey, Pasadena,
California, U.S.A.; 3. Seismological Laboratory, California Institute of Technology,
Pasadena, California, U.S.A.; 4. Seismological Laboratory, University of California,
Berkeley, Berkeley, California, U.S.A.; 5. Department of Earth and Space Sciences,
University of Washington, Seattle, Washington, U.S.A.
*Corresponding author: kohler@caltech.edu
© Seismological Society of America
Volume XX
•
Number XX
•
XXXX XXXX
•
www.srl-online.org
Seismological Research Letters
1
commercial entities developing hardware for alert delivery in
the three states of the western United States where most of the
nation
’
s earthquake risk is concentrated (
Federal Emergency
Management Agency [FEMA], 2008
).
The overall goal of the ShakeAlert product is to issue warn-
ings of potentially damaging earthquake shaking to the public
(
Given
et al.
, 2014
,
2018
). To that end, the 2018 ShakeAlert
product for public alerting is a message containing a polygon
enclosing a region predicted to experience modified Mercalli
intensity (
Wood and Neumann, 1931
)
MMI
≥
IV for an
earthquake of
M
≥
5
:
0. Recall that whereas MMI is an empiri-
cal measure of ground-shaking intensity, magnitude is an
empirical measure of the energy released by an earthquake.
Estimated ground shaking in the form of MMI level is used as
the basis of alert thresholds, in part because future algorithms
may not explicitly estimate an earthquake
’
s location or mag-
nitude (e.g., ground motions only) and because this is a more
direct way to estimate the potential for structural and non-
structural damage. MMI is chosen because it combines the
attributes of peak ground acceleration (PGA) and peak ground
velocity (PGV), which both correlate with the strength of felt
shaking and the expected damage (
Wald
et al.
, 1999
). An MMI
threshold of IV is chosen to alert populations who might expe-
rience moderate to strong ground shaking (the
“
damage
”
threshold), to accommodate shaking estimate uncertainties in
the system, and to maximize potential alert times. Alerts are
only provided for earthquakes that have at least some minimal
potential to cause structural or nonstructural damage, defined
here as
M
5.0+. To be effective, alerts must be provided quickly
enough to arrive at most users
’
locations before the arrival of
damaging ground motion; the threshold at which damage
occurs depends on the specific application. By design, these
alerting thresholds are monitored and may change based on
system performance and user demand.
This article focuses on the software architecture of
ShakeAlert 2.0, relative to its predecessor (ShakeAlert 1.0),
which was described by
Kohler
et al.
(2018)
, and on the per-
formance of the system during testing with both real-time and
historic event datasets. The testing process includes a more
extensive quantitative measure of how well the system alerts
for specific levels of ground motion, and assessments of these
measures for the real-time and historic event datasets are pre-
sented. For a comprehensive description of ShakeAlert history
and overall goals, particularly within the context of USGS
infrastructure, see
Given
et al.
(2018)
.
Phase 1 Rollout
In fall 2018, ShakeAlert entered phase 1 of alerting in
California, Oregon, and Washington. More than 60 institu-
tional partners are now alerting personnel and taking auto-
mated actions, important steps in a strategy of phased
rollout leading to full public operation. Concurrent with the
fall 2018 release of ShakeAlert 2.0, it was announced that
ShakeAlert was
“
open for business,
”
which included plans
to accelerate the recruitment and development of technical
partnerships. This officially marked the end of the production
prototype (or pilot) phase in which, by design, the number of
partners working on
“
proof-of-concept
”
pilot projects (e.g.,
using alerts to close a valve to protect a water supply or open
a firehouse door) was kept small. In addition, the introduction of
a ShakeAlert
“
license to operate
”
debuted, allowing partners in
the advanced stages of their relationship with ShakeAlert to take
their products to the market provided they continue to abide by
restrictions on alerting thresholds and meet the latency require-
ment to deliver alerts to 95% of their end users within 5 s.
To participate in a ShakeAlert technical partnership, part-
ners must meet some basic criteria. Alerts and automated
actions must be fast enough to be effective, and the partners
must develop a plan to address meeting and sustaining the
latency requirement described earlier. Automated actions must
be tolerant of system errors including false, missed, or late
alerts and incorrect intensity estimates, and must make every
effort not to have the potential to result in injury, damage, or
loss. As of September 2019,
>
60 technical partners have
been working with the ShakeAlert Joint Committee for
Communication, Education, and Outreach (JCCEO) to
develop, test, and implement appropriate personal protective
actions and specialized responses that prioritize human safety.
The end user
–
JCCEO partnership draws on existing industry
best practices and social science research to optimize human
response in taking a protective action such as drop, cover, and
hold on or other mandated action as defined in a partner
’
s
standard operating procedure.
Three mobile phone apps (MyShake, QuakeAlert, and
ShakeAlertLA) designed to deliver alerts derived from
USGS-issued ShakeAlerts moved into the testing phase as part
of the phase 1 rollout. All app partners are required to (1) have
the institutional capacity to manage and sustain the app,
(2) have appropriate server capacity, (3) demonstrate timely
delivery of alerts, and (4) deliver postalert messages. All app
development teams must provide appropriate education and
training in partnership with the JCCEO. In addition, all devel-
opers must abide by USGS-mandated alerting thresholds. On
31 December 2018, the first large-scale test of an app began in
Los Angeles County with the release of the ShakeAlertLA app
by the City of Los Angeles. It had
>
400
;
000 downloads in the
first month it was available.
Broader public alerting (e.g., via FEMA
’
s Wireless
Emergency Alert [WEA] system) at the
M
5.0 and MMI IV
levels will begin when existing mass alerting technologies are
able to deliver ShakeAlerts at the speed or scale needed for
effective EEW and with the concurrence of the state emergency
management agency. ShakeAlert partners are working with
both public and private mass alert system operators, including
FEMA
’
s Integrated Public Alert and Warning System, cellular
carriers, mass notification companies, and others, to provide
2
Seismological Research Letters
www.srl-online.org
•
Volume XX
•
Number XX
•
XXXX XXXX
this functionality. Mass notification companies (e.g., Regroup
and Everbridge) have existing infrastructure to alert college
campuses, large businesses, and cities about severe weather,
active shooters, and so on using modalities such as reverse
911, SMS, email, and push notifications from apps. Both
Regroup and Everbridge are ShakeAlert technical partners,
and they are testing the viability of EEW alert delivery via sev-
eral of the modalities that they currently offer. Finally, suffi-
cient, broad public awareness, education, and training are
being conducted in partnership with each state
’
s emergency
management agency. The USGS has invested resources in a
partnership with Denver-based Nusura, Inc., to develop stra-
tegic communication resources (e.g., talking points, fact sheets,
animations, engagement strategies, teaching resources) that are
part of tool kits that will be used by ShakeAlert stakeholders in
all three states. The Nusura tool kits emphasize appropriate
protective actions, preparedness principles, and setting appro-
priate expectations from ShakeAlert. Parallel resources (but
focused more on the technical side) are in development by the
USGS Office of Communication and Publishing. Materials will
be used for public meetings and other gatherings, and will also
be available on the web (see e.g.,
Data and Resources
). USGS
maintains an active Twitter presence @USGS_ShakeAlert
(8800+ followers as of November 2019). In addition, the
USGS is collaborating with the Incorporated Research
Institutions for Seismology to develop technical animations
(e.g., the difference between magnitude and intensity), educa-
tional activities, and other resources that can be used by
classroom teachers, emergency managers, and in free-choice
learning environments such as museums. There has been con-
siderable effort to leverage and build on existing resources
developed by partners such as the Earthquake Country
Alliance (developers of The Great ShakeOut). In addition, on
the USGS end, ShakeAlert is being marketed as a critical new
offering of ANSS products that contribute to earthquake risk
reduction.
Alert areas and thresholds
ShakeAlert issues alerts for earthquakes that fall within the U.S.
West Coast reporting region, a polygon that includes the states
of California, Oregon, and Washington and extends a short
distance into Baja California and Canada (Fig.
1
). The
−132°
−130°
−128°
−126°
−124°
−122°
−120°
−118°
−116°
−114°
−112°
32°
34°
36°
38°
40°
42°
44°
46°
48°
50°
−132°
−130°
−128°
−126°
−124°
−122°
−120°
−118°
−116°
−114°
−112°
32°
34°
36°
38°
40°
42°
44°
46°
48°
50°
(a)
(b)
Figure 1.
(a) Advanced National Seismic System (ANSS) network
stations (green triangles) in the western United States, making up
the three tier 1 regional seismic networks used by ShakeAlert 2.0
as of May 2019. A tier 1 center is a seismic network covering a
broad area with an established data processing center (
U.S.
Geological Survey [USGS], 2019
), consisting here of the Pacific
Northwest Seismic Network, the Northern California Seismic
Network, and the Southern California Seismic Network. The
alerting region is shown by the dashed red outline. Not all sta-
tions are required to be within the alerting region. In the Pacific
Northwest, the alerting region extends to just west of the
Cascadia subduction zone. (b) Earthquakes used in historic event
testing. The color version of this figure is available only in the
electronic edition.
Volume XX
•
Number XX
•
XXXX XXXX
•
www.srl-online.org
Seismological Research Letters
3
ShakeAlert system publishes alerts for
M
3.5+ earthquakes, and
they are made available for all delivery partners. However, the
USGS has mandated higher minimum thresholds that are tail-
ored for specific types of alert delivery system. For example,
WEA can only be delivered for
M
5+ earthquakes and only
to people (i.e., their wireless devices) who could potentially
experience damaging shaking (MMI IV+). For cell phone
apps, the mandated thresholds are slightly lower
—
M
4.5+
and weak shaking (MMI III) or greater. For earthquakes with
magnitudes
≥
M
6.0, an estimated line (finite-fault) source will
be included in the alert if available, providing an indication of
both the strike and extent of the rupturing fault. Estimated
ground motion is also provided.
Updates to regional networks (sensors and
telemetry)
The ShakeAlert project plan calls for a network of 1675 high-
quality, real-time seismic stations: 1115 in California and 560
in Oregon and Washington. At the beginning of 2019,
>
900
stations were contributing to the system (Fig.
1a
), although
some of them still require upgrades, primarily to accommodate
faster and more reliable telemetry. Station construction has
been focused on seismic high-risk areas; therefore, despite
being incomplete, the ShakeAlert network is sufficient for
rapid alerting in parts of Southern California; the San
Francisco Bay area, including Silicon Valley; and the
Seattle
–
Tacoma area. Alert delivery in areas where the network
is not complete will experience additional latency plus latencies
contributed by the delivery modality that was used. USGS is
working with state emergency managers and alert delivery
organizations to address this challenge, including communi-
cating this limitation to end users.
Software and Central Processing
Architecture
ShakeAlert 2.0 produces both point-source and line-source
earthquake solutions, has added ground-motion estimation
products, and has reduced the number of false and missed
events. The ShakeAlert 2.0 system has also satisfied govern-
ment cybersecurity requirements and includes improved
operational procedures.
The ShakeAlert 2.0 algorithm and hardware architecture,
shown schematically in Figures S1 and S2 (available in the sup-
plemental material to this article), is an improvement over
ShakeAlert 1.0 (
Kohler
et al.
, 2018
), which was in operation
since 2016. In particular, each ShakeAlert 2.0 production
server has two algorithms that can detect earthquake events.
The first algorithm, Earthquake Point-Source Integrated
Code (EPIC), triggers from seismic ground-motion data and
generates a point-source estimate, which includes magnitude,
location, and origin-time (OT) parameters. This algorithm is
largely based on Earthquake Alarm Systems (ElarmS, one of
the original ShakeAlert algorithms;
Chung
et al.
, 2019
). The
second algorithm, Finite-Fault Rupture Detector (FinDer), also
triggers from seismic data and generates both a point-source
and a line-source estimate; hence, this additionally yields fault
length and strike information (
Böse
et al.
, 2012b
). The source
parameters from these two independent algorithms are then
combined in the Solution Aggregator (SA) algorithm. Next, the
eqInfo2GM algorithm takes the information from the SA and
generates ground-motion estimates for the earthquake in the
form of contour messages and map messages. Last, the infor-
mation is sent through the Decision Module (DM) algorithm,
which runs on six alert servers maintained by the USGS. The
DM runs a series of quality tests and checks if certain thresh-
olds are exceeded to determine if the alert will be sent out and
distributed to end users such as emergency responders, Bay
Area Rapid Transit train system, the City of Los Angeles, and
other users. A Heartbeat Monitor algorithm also running on
the alert servers characterizes overall system health. Figure S1
summarizes the algorithms and message-sharing pathways
among the four contributing regional networks, starting from
the incoming seismograms (Fig. S1, bottom), to alerts sent to
general public (Fig. S1, top).
EPIC algorith
ShakeAlert originally consisted of three point-source algorithms:
ElarmS, Onsite, and Virtual Seismologist (VS;
Allen and
Kanamori, 2003
;
Allen, 2007
;
Wurman
et al.
, 2007
,
Böse
et al.
,
2009
,
2012a
;
Cua and Heaton, 2009
;
Cua
et al.
, 2009
). Although
VS was able to accurately locate and estimate the magnitude of
earthquakes, it was consistently slower than the other two algo-
rithms (
Chung
et al.
, 2019
) and was removed from ShakeAlert
in 2016. In early 2017, it was decided that to streamline
ShakeAlert processing, the remaining algorithms should be
merged as the system
’
s single point-source algorithm.
Because ElarmS historically created more alerts for earthquakes
and more accurate estimates of the earthquake location and
magnitude than Onsite (
Chung
et al.
,2019
), it was used as
the basis for the new algorithm. The resulting algorithm,
EPIC, came online in 2018 with the release of ShakeAlert 2.0.
EPIC was created from the most recent version of ElarmS:
“
ElarmS 3
”
(
Chung
et al.
, 2019
). EPIC is identical to ElarmS 3
in how it creates triggers (i.e., it uses the identical classic short-
term average/long-term average picker), how it evaluates trig-
ger quality, and how it determines the best location (minimiz-
ing travel-time difference via a grid search) and magnitude
(using peak
P
-wave displacement up to 4 s after the trigger,
averaging magnitude estimates from a minimum of four sta-
tions); see
Chung
et al.
(2019)
for details. One difference from
ElarmS 3 is that the EPIC waveform processor applies a differ-
ent discrete-time high-pass filter and then performs an addi-
tional baseline correction to the incoming seismograms,
features taken from the Onsite code. ElarmS 3 used a first-
order Butterworth filter with a filter coefficient that was the
same for all sampling frequencies (
Kanamori
et al.
, 1999
),
4
Seismological Research Letters
www.srl-online.org
•
Volume XX
•
Number XX
•
XXXX XXXX
which led to slightly different cutoff frequencies for channels
with different sample rates (
Chung
et al.
, 2019
). The EPIC
waveform processor uses a second-order Butterworth filter
with a prescribed cutoff frequency of 0.075 Hz, that is, the filter
coefficients depend on the sample rate. EPIC also uses a simple
baseline correction by removing the average amplitude calcu-
lated using the previous 60 s of the waveform from each sam-
ple. If this length of data is not yet available, such as when the
algorithm is first started or following a gap in data, the avail-
able data are used so as not to delay further processing.
EPIC is susceptible to magnitude saturation, performing well
for
M
<
∼
7, because it uses ground acceleration and velocity as
inputs. However, because of the sensitivity of the algorithm, it is
able to consistently create faster and more accurate estimates of
location and magnitude than other point-source algorithms
(
Cochran
et al.
,2018
;
Chung
et al.
,2019
). Provided adequate
station coverage, EPIC can create alerts for earthquakes as small
as
M
3.0. The combined use of EPIC and FinDer, described next,
allows ShakeAlert to create rapid, accurate alerts for a large
range of earthquake magnitudes, from
M
3.0 and up.
FinDer algorithm
The FinDer algorithm (
Böse
et al.
, 2012b
,
2015
,
2018
) became a
component of ShakeAlert in March 2018 after extensive devel-
opment and testing. This algorithm eliminates magnitude sat-
uration and extends ShakeAlert
’
s alert magnitude range to
M
9.0+. It also estimates finite-fault parameters leading to
improved characterization of ground motion. Unlike EPIC
and previous point-source algorithms tested and used by
ShakeAlert, FinDer is not dependent on a picking algorithm.
It instead uses a complementary methodology based on the
spatial pattern of ground-motion amplitudes to produce the
additional finite-fault parameter characterization.
The input data for FinDer are the maximum PGA values
within 120 s time windows recorded by all available stations
in the network; these values are gridded (5 km resolution,
to match templates) and contoured using functions in the
Generic Mapping Tools library (
Wessel and Smith, 1998
),
and then converted to a binary map image that shows regions
above and below a configured threshold. FinDer then uses tem-
plate matching to compare this observation image with tem-
plate images for different fault lengths and orientations (using
functions in the openCV library;
Bradski and Kaehler, 2013
).
FinDer characterizes the best-matching image in terms of fault
centroid, length, and strike. Fault length is used to estimate
magnitude using the relations of
Wells and Coppersmith
(1994)
for crustal events. Because FinDer is primarily con-
cerned with matching near-source, high-frequency ground
motions, and scaling relations are necessarily averaged over
earthquakes with a range of characteristics (e.g., stress drop),
FinDer magnitudes can differ from catalog magnitudes (
Böse
et al.
, 2018
). In the future, it would be preferable for FinDer to
report ground-motion estimates directly.
A second method of magnitude estimation is used when the
template-based magnitude is
<
M
5.5. In these cases, station
amplitudes are assigned a phase type (
P
or
S
) depending on the
expected arrival time, and the
Cua and Heaton (2009)
ground-
motion prediction equation (GMPE) is used to find the pre-
dicted magnitude with the lowest misfit to match the ampli-
tudes. Whereas the template-matching method assumes that
observations are peak ground motions (i.e.,
S
-wave or later)
and tends to underestimate final earthquake magnitude in
the earliest alerts, this amplitude regression method facilitates
faster estimation of larger magnitudes.
The lowest acceleration amplitude threshold used by FinDer
within ShakeAlert 2.0 is 2 cm
=
s
=
s, which permits detection of
earthquakes with magnitude down to
∼
3
:
0 in areas of good net-
work coverage. Event detection is controlled within FinDer by
trigger parameters that include the number of stations needed to
trigger an event and a minimum number of station connections
(in which two triggered stations are considered
“
connected
”
if
their separation is less than a specified maximum distance). In
ShakeAlert 2.0, a maximum distance of 50 km permits good
event detection performance in regions of moderate or good sta-
tion coverage, such as the urban areas of Seattle, San Francisco,
and Los Angeles, but can lead to a failure of detection in areas of
low station coverage. The required number of triggered stations,
currently set to four, controls a trade-off between the risk of false
alerts and the delay to event detection.
In ShakeAlert 2.0, FinDer is configured to use a set of generic,
symmetric ground-motion templates, computed using the
GMPE of
Cua and Heaton (2009)
for a fixed depth of
10 km. This tailors FinDer for determining onshore hazard, for
example that posed by major West Coast crustal faults such as
the San Andreas and Hayward. However, for offshore seismic
regions such as the Cascadia subduction zone or Mendocino
triple junction, FinDer needs an extended template set that
accounts for asymmetric monitoring and the larger depths of
interface and slab events (
Böse
et al.
,2015
). This has not yet
been implemented and will be a priority for future development.
Because of the limited template set used by FinDer, which
results in significant mislocation for earthquakes in out-of-
network or sparsely instrumented regions, FinDer cannot
generate an alert that is not also declared by EPIC.
However, its results can still be used by the SA to determine
the alert location, rupture parameters, and magnitude.
SA and DM algorithms
The SA algorithm receives alert messages from the EPIC and
FinDer algorithms. The SA combines the point-source infor-
mation from those two algorithms and sends out an alert
message that is received by the DM algorithm. The DM algo-
rithm makes the final decision whether or not to release
the alert to end users, based primarily on the SA
’
s determina-
tion of whether location and magnitude are within reporting
thresholds.
Volume XX
•
Number XX
•
XXXX XXXX
•
www.srl-online.org
Seismological Research Letters
5
The two algorithms that send alert messages to the SA
(
“
senders
”
) assign uncertainty values to their point-source esti-
mates. FinDer does this using fixed uncertainty values that
were determined from the average algorithm performance
for a catalog of real-time and historic events. EPIC
’
s uncer-
tainty values are from empirical relationships between the
EPIC event location errors and the number of stations that
are contributing to the event, derived from a comparison of
EPIC (ElarmS) event locations with the ANSS catalog for the
time period May 2012 to December 2012. The SA algorithm
screens the alert messages that it receives using bounds on
the acceptable point-source parameters: location, depth, mag-
nitude, origin time (OT), and their uncertainty values. These
bounds are simply sanity checks, with the exception of loca-
tion, which checks for an epicenter within the ShakeAlert
reporting regions. The SA associates the event messages and
identifies when the differences are within an acceptable limit.
Namely, the messages from the two senders will be associated
together when their locations are within 100 km and their OTs
are within 30 s. The SA computes the combined point-source
parameters as the average of the sender parameters weighted
by the normalized sender parameter uncertainties. This is com-
puted as 1
=
algorithm parameter uncertainty
2
, normalized
so that the sum of weights for all algorithms equals 1.
The SA algorithm is configured to only accept alerts from
senders reporting alerts within an approved region for that
sender. This is useful for sender algorithms that are sensitive
to station density, such as FinDer, which is assigned a polygon
region that approximately encloses the instrument network (i.e.,
excludes offshore regions). Different magnitude bounds can also
be assigned to individual senders. There is the option to require
the SA to wait for a confirmation message from a second sender
(i.e., second algorithm) when the first sender magnitude is above
a threshold value, but this is not currently being implemented.
The DM algorithm receives alert messages from the SA
algorithm and from the eqInfo2GM module discussed in
the
EqInfo2GM ground-motion estimation algorithm
section.
The DM has its own set of bounds on the point-source param-
eters for issuing its alert messages. These bounds can differ
from the SA bounds; currently, this is the case for magnitude.
The SA is allowed to issue lower magnitude event messages,
which are useful for monitoring the system performance,
whereas the DM alerts have a higher magnitude threshold.
The DM will also pass along the FinDer information that is
included in the SA messages to the DM when the event mag-
nitude meets or exceeds a threshold, currently set at
M
6.0.
EqInfo2GM ground-motion estimation algorithm
The eqInfo2GM algorithm computes estimated ground motion
for the earthquake parameters provided by the SA and is a new
component for ShakeAlert 2.0. The core calculations involve
GMPEs and ground-motion intensity conversion equations
(GMICE) to provide estimated PGA, PGV, and shaking
intensity in MMI units. Messages incorporating ground-
motion estimates are sent to the DM, which will in turn send
out these alerts if they meet various criteria (see the
SA and
DM algorithms
section).
GMPE and GMICE selections follow those currently used
by the regional seismic networks to provide as much consis-
tency as possible with other USGS products (e.g.,
ShakeMap):
Chiou and Youngs (2008)
and
Worden
et al.
(2012)
for the Pacific Northwest and
Boore and Atkinson
(2008)
and
Wald
et al.
(1999)
for northern and southern
California. These implementations closely follow those in
ShakeMap v.3.5, as documented in
Worden and Wald (2016)
,
though because of the paucity of source characterization infor-
mation available on the early warning timescale, many terms
are unused or simplified (e.g., fault type, aftershock terms; see
Thakoor
et al.
, 2019
, for all implementation details).
The eqInfo2GM algorithm provides ground-motion infor-
mation in two formats, contour and grid, which differ in their
computation time, message size, resolution, and accuracy. The
contour message is the faster, more simplified product, and the
system is currently configured to compute a contour for MMI
levels of II and above. For a given earthquake magnitude, the
region-appropriate GMPE and GMICE are used to compute
the distance from the line source (if available) or epicenter
at which the specified MMI level is expected, assuming a site
condition (
V
S
30
value, or average shear-wave velocity in the
upper 30 m of soil) of 500 m
=
s. At regular angular intervals
around the source, this distance is converted to coordinates
describing a closed, eight-vertex polygon. The maximum size
of this message type is on the order of tens of kilobytes, and
computation time is on the order of 0.001
–
0.01 s.
The grid or map message is computed using a fixed grid that
covers the ShakeAlert reporting region and has a grid point
spacing of 0.2° (
∼
20 km). For each grid point, the
V
S
30
value
(derived from regional knowledge of geologic units, topogra-
phy, or both) is combined with the distance to source (for line
source if available, otherwise epicenter) and earthquake mag-
nitude, to compute the estimated ground motion. The maxi-
mum size of this message type is on the order of hundreds of
kilobytes, and the computation time is 0.01
–
1.5 s. This com-
putation time increases with increasing earthquake magnitude
because it depends on the grid extent and the number of seg-
ments describing the line source; the upper time limit of 1.5 s
corresponds to an
M
7.8 scenario line-source earthquake using
the maximum number of grid points (
∼
6000).
ActiveMQ message broker and server structure
Communication involving data or message passing between
ShakeAlert servers (Fig. S1) is provided by the Apache
ActiveMQ open-source software. ActiveMQ acts as a message
broker and uses ShakeAlert-defined
“
topics
”
to which a server
can subscribe to either provide or obtain a message (data) on
the topic. For example, the ground-motion information from
6
Seismological Research Letters
www.srl-online.org
•
Volume XX
•
Number XX
•
XXXX XXXX
the eqInfo2GM algorithm is forwarded to users via a separate
ActiveMQ topic from the point-source and line-source alert
messages.
In addition to the pair of prealert production servers at each
regional seismic network (i.e., Pacific Northwest Seismic
Network based in Seattle, Northern California Seismic
Network based in Menlo Park and Berkeley, and Southern
California Seismic Network based in Pasadena), there is an
overlying alert layer that consists of two virtual servers at three
of the four sites: USGS
–
Pasadena, USGS
–
Menlo Park, and
USGS
–
Seattle (Figs. S1 and S2). As with production, there
are two identical servers for failover capability. Although
the algorithms and the SA run on the prealert production
server layer, the DM runs at the alert layer. The advantages
of the alert layer are that it simplifies that part of the system
that is responsible for sending alerts directly to the public.
Because the alert layer only runs the DM, the ActiveMQ
broker, and a heartbeat monitor, the servers are lightweight
when it comes to processing and memory requirements.
This allows for easy virtualization, which in turn allows for
horizontal scaling to accommodate a growing number of user
subscriptions. Another benefit of separating the alert layer
from the production servers is increased security. By moving
the alert servers away from the production servers, external
connections to the production servers can be shut down, elimi-
nating all but a few subnets from seeing them on the Internet.
To further distance the production servers from the alert serv-
ers, the alert servers are configured to become subscribers to
ActiveMQ SA brokers on the production hosts. From the pro-
duction standpoint, the alert server is just an external user sub-
scribing to its data feed; all knowledge of the alert servers and
how they relate to production is removed. External alert users
only have access to the alert layer. In addition, because the alert
servers run only a few required processes, they can be hardened
against constant public exposure.
Within the coming year, a proxy layer will be developed and
deployed that will replace the ActiveMQ infrastructure at the
alert layer. Currently, each ActiveMQ broker can reliably han-
dle
∼
1000 concurrent connections. This will not be sufficient
going forward as more users subscribe to the ShakeAlert data
feeds. The new proxy layer will be able to handle the increas-
ingly large number of connections (
≤
10
6
) and will give users an
interface with which to manage their own accounts. Currently,
the accounts are created and managed by the ShakeAlert staff,
an inefficient way to manage an increasing number of sub-
scribers. The new proxy layer will most likely be established
using the Neural Autonomic Transport System open-source,
cloud-native messaging system, or some other resilient,
high-performance, messaging system.
Security
ShakeAlert uses two-factor authentication for administrative
access to the ShakeAlert servers. Each ShakeAlert server
handles access control through Pluggable Authentication
Modules for Linux and does not rely on a central authentica-
tion server. An independent firm conducts a periodic penetra-
tion test that includes vulnerability scanning, brute force login
attempts, port scans, and social engineering tests. In addition,
the ShakeAlert staff performs routine vulnerability scans and
has an aggressive patch management plan. Production servers
have limited access and are set up with strict firewall configu-
rations shielding them from the external world. No ports are
opened to the public. Connections are only allowed from sub-
nets that contain other ShakeAlert production servers.
System Testing and Performance
Performance of ShakeAlert 2.0
—
False alerts and
missed events
In preparation for public rollout, testing of the ShakeAlert 2.0
algorithms was conducted in ShakeAlert
’
s Testing and
Certification Platform (TCP). TCP was developed as a major
component of ShakeAlert to test new candidate code and new
operating system environments before they are implemented
in production (
Cochran
et al.
, 2018
). Figure S2 shows sche-
matically how the testing process fits into the ShakeAlert archi-
tecture. To assess the quality of new candidate code, it is tested
against a baseline, which nearly always consists of the perfor-
mance given by the system running in production at that point
in time. This is a quantitative methodology for assessing poten-
tial code improvements. The discussion next describes the per-
formance of the ShakeAlert 2.0 test (specifically v.2.0.1) and
includes results for historic events, real-time performance,
and performance of the system that was in place for significant
2018 and 2019 events. See
Data and Resources
for details on
data source.
Following the
Cochran
et al.
(2018)
methodology, the first
component of testing involves comparing the ShakeAlert
point-source solution with the ANSS comprehensive catalog
(ComCat) solution for earthquake source parameters (hypo-
centers, magnitudes, and OTs). During testing, an earthquake
solution match is declared (as opposed to a false alert) if the
magnitude difference between ShakeAlert and ComCat is within
2.0 magnitude units, the location estimate is within 100 km, and
the OT estimate is within 15 s. In addition, timeliness is quan-
tified by looking at the alert time associated with the largest dis-
tance traveled by an
S
wave to a contour with MMI = IV to
assess whether the alert was early enough to be useful. This met-
ric depends on the distance between the MMI = IV contour and
the epicenter, and constant
S
-wave velocity. It is thus comple-
mentary to additional assessments of ground motion discussed
in the
Ground-motion assessment
section.
In the historic event test of ShakeAlert 2.0, four instances of
the algorithms including EPIC, FinDer, SA, DM, and
eqInfo2GM were run in parallel with each other. The historic
data suite consists of 60 earthquakes, both mainshocks and
aftershocks, that occurred in California and the Pacific
Volume XX
•
Number XX
•
XXXX XXXX
•
www.srl-online.org
Seismological Research Letters
7