Article Contents
How does Android’s new Earthquake Alerts System work? In short: As quickly and reliably as possible, according to the project’s lead engineer, Marc Stogaitis. And on July 23rd, plenty of people in the Philippines appreciated it when Google successfully detected a magnitude 6.7 earthquake-in-progress, alerting residents and helping many reach safety before it hit them.
It started life at a hackathon
You might not be aware of it, but earthquakes have killed over 800,000 people worldwide in the last 20 years, according to USGS estimates. Google’s new feature isn’t just fascinating on a technical level (and we’re about to dive in and show you just how interesting it all is), but it will also have a much more real impact of saving lives as it rolls out to more countries over time. It’s heavy stuff, to be sure, but it’s also pretty cool to geek out over the minutiae behind how it works and how the idea came to be. I bet most of you weren’t expecting it to have started life at a hackathon.
According to Stogaitis, the project’s beginnings were quite humble, with the software engineers on Google’s “physical safety and activity recognition” team ruminating over the question, “What can a phone detect?” and spitballing different ways that a phone’s on-device sensors might be used to help, with ideas including car crashes, tornados, and earthquakes. Over the course of a one-week team hackathon, Google pared the idea down to a prototype. I wasn’t told how well that early proof-of-concept worked, but it was apparently enough to develop into the life-saving alerts now live in ten countries today. (The car crash detection idea panned out too.)
Of course, there were a lot of unknowns to start. I’m told early questions include things like, “How much does a phone shake during an earthquake?” and, “Is there anything else that can make phones shake across large areas that look like P and S waves but aren’t?” (P waves and S waves, or compressional waves and shear waves, describe the motion of the ground/rock during an earthquake.) In the truest engineering traditions, answering these questions meant taking lots of measurements. I’m told the team was particularly excited when it realized S-waves and even the early-indicating P-waves could be detected with good accuracy by phones, period.
A physics-based approach
Stogaitis tells us that his team was learning and answering these questions “at the rate of earthquakes.” You might think that a company known for its downright magical machine learning would resort to using the concept again here, but instead, the team went for a “direct physics-based approach,” sans AI. After all, the physics of earthquakes are well understood, and that means they can be directly quantified, measured, and detected programmatically directly rather than training a black box with countless unknown parameters, force fed a bunch of noisy data.
There was still some learning and tuning involved, according to Stogaitis:
“Looking at tradeoffs between — like, how much you should trust the speed that you’re seeing vs how much should you trust the amplitude of the wave? How much weight do you put on each? How much does a phone shake when there’s an earthquake?”
Phones might have plenty of sensors in them, but they’re not seismometers anchored deeply into the ground. Beyond just looking at data to answer these questions, Google also hired some seismologists to validate and approve the system.
Still, even with a relatively straightforward approach, there were a few issues to address as the engineers accrued data. Key among them were the two problems of working out a detection threshold that prevented false positives and ensuring that it was earthquakes Google was detecting.
“You’re looking for things that propagate out to a lot of people and make phones shake but aren’t earthquakes”
You can get any algorithm to simply say “yes” to all motion and technically detect every single earthquake that happens. The problem is almost all of its assessments will be false positives. But look at enough data for verified earthquakes, and you can come up with certain limits for the types of motions observed to hit a higher degree of precision. Even the kind of building that a phone is in can affect measurements and motion, so Google had to learn the right parameters and values. But earthquake detection also involves ruling out other events that could be misinterpreted as earthquakes — and they’re actually more numerous than you’d think. “You’re looking for things that propagate out to a lot of people and make phones shake but aren’t earthquakes.”
Fun fact, I’m told that during early testing, AMBER alerts could actually be a potential issue. Think about it: a bunch of phones shaking at the same time in a wide area. The mechanism and cause are totally different, but the behavior as observed by an accelerometer could be similar. Thankfully, that was easily tuned out. Thunderstorms were also a problem, but the physics of the situation worked out in Google’s favor — the wave of reports travels at the speed of sound in air rather than the much faster speed of ground-shaking, and they’re usually much smaller than earthquakes.
Ultimately, Stogaitis’s team wrangled the data well enough to come up with a model that, to date, has not had a single false positive alert. But detecting the motion of an earthquake on a single Android device is, at best, just one-third of the equation.
The Android earthquake army
Google’s system doesn’t just capture data from one phone, it pulls it from hundreds if not thousands, taking advantage of the massive number of Android devices in the wild. But, you might be curious to hear, not all Android devices in a given area are actively listening for earthquakes.
It all comes down to device distribution.
The earthquake-detecting logic is bundled into Play Services, which means that it’s ubiquitous to almost all Android phones. (Or, at least, the ones that matter — sorry, Huawei.) But it actually uses phones that are charging and connected to power to detect the “physics” signs we just discussed of an earthquake in progress. The feature specifically uses devices that are charging (wired or wirelessly) for two crucial reasons: Since they’re connected to power, it’s less likely to impact battery life, and because they’re stationary, they’re better for measuring motion data.
So how many phones does Google need in an area to accurately detect an earthquake?
“The short answer is, it depends on the earthquake and where the phones are positioned. If all the phones are in one spot, that makes it a little harder to figure out where it is. You can still know there’s an earthquake, but it might reduce the accuracy.”
Google harnesses the data from as many phones as it can in a given area. I’m told that the number required for an accurate detection varies based on things like the earthquake itself and the distribution of devices across the geography. If they’re all in one spot, accuracy is reduced, but Google can still detect the earthquake. Spread out more to see the progression of the waves better, and you can get by with fewer phones. But not too spread out; the more phones near the epicenter, the faster Google can detect it. Earthquakes that happen out in the middle of nowhere — say, underwater or really deep underground — might not be detected until they hit the shore or surface (and Android devices). It all comes down to device distribution.
I’m told around 100 devices in an earthquake zone is the minimum for good-quality data. And once phones see what’s happening and report back to Google with their data, the next step kicks in.
Server-side, Google’s ears are to the ground, waiting for word from all the phones in an area. When phones ping Google’s servers with data, that includes the measurements recorded, the time, and the abstract location for remote processing.
Google tells us it built this data gathering model with privacy in mind, and all data is “de-identified.” That means a phone’s ping to Google with potential earthquake-detecting data isn’t associated with things like your phone number, name, or Gmail accounts, etc. Google just knows a phone somewhere was shaking; it’s not tied to anything else. Sever-side data access is also restricted on Google’s end, and only a few people can access it. Furthermore, Google only uses coarse location, with that coarsening happening on-device, so they don’t know the precise location. Thankfully, I’m told that doesn’t reduce accuracy, and the resolution of “coarse” location is good enough given the speed at which earthquakes move:
“It’s moving pretty quickly, which means it will go through a city pretty quickly. Our location is roughly city-level, is kind of how you think about it — the coarseness of it. If there are small differences in location, it’s usually not a big deal.”
As an earthquake propagates outwards, phones closest to it detect the movements associated with it first, alerting Google that something might be up. Once a certain threshold across an area is hit as the “wave” of the earthquake spreads, and enough reports come in from devices with data that meets certain thresholds, Google can determine that there is an earthquake happening, how big it probably is, where it is, where it’s going to go, and who can still be notified outside the spread of the “wave.” Then it blasts out those notifications. Best-case scenario, I’m told this can all happen in seconds. And, again, this last step sounds simple, but it really isn’t.
Back to the phones for notifications
You might think that earthquake detection itself is the biggest issue the team would face, but getting a system to reliably deliver notifications to potentially millions of people with a minimum of lag was actually one of Stogaitis’s team’s biggest challenges. Google had to build out a bunch of new infrastructure just to handle this system for faster alerts. Of course, the whole pipeline of earthquake -> device detection -> server communication -> warning varies. And just being on Wi-Fi vs. cellular data can have an impact on alert latency — and Wi-Fi is faster. Cellular networks have their own limitations and congestion as a shared medium.
Left: The full-screen warning for big earthquakes. Middle: the warning for smaller quakes. Right: an after-the-fact notification.
Even with Google’s added infrastructure, there’s no hard and fast limit for how long earthquake alerts take to arrive. Again, the location of the earthquake itself is often the biggest source of latency in the system, but we’re told that folks will usually get warnings within seconds of phones picking up the earliest cues.
“The algorithm is mostly just waiting for enough data to come in, and it’s constantly — every 1/10th of a second — recomputing: ‘Is this an earthquake? Is this an earthquake?’ And as soon as there’s enough data that’s come in, that’s when it says, ‘Okay, this is an earthquake.'”
Sometimes, you might not get an advance warning at all if you’re really close to the epicenter, and if it’s an especially big quake, alerts could be sent to a very wide area. As we hinted on before, ultimately, warning is a function of distance. Still, in most cases, Stogaitis claims alerts should land on phones within seconds of Google knowing what’s happening:
“Each earthquake depends. We usually talk about seconds of warning — so you might get tens of seconds, up to a minute, but more likely 10-5 seconds. And sometimes you might not get a warning before the earthquake hits. The first phones to be hit by the earthquake can’t be warned before shaking happens”
Alerts are, again, part of Play Services and can be received on Android devices dating back to 5.0 Lollipop. We don’t have precise platform distribution numbers anymore, but based on the last data we got and Google’s most recent hints, that probably means somewhere around 95-97% of devices worldwide can receive alerts. Google also shows alerts after the fact in Search for related queries.
Alerts sent to customers include the location of the earthquake, its magnitude, and the time of the quake. In many cases, this will give customers enough time to take some level of precaution, even if it’s simply moving out from under a bookshelf or taking cover. If it’s a really strong earthquake that could genuinely harm lives or property, a more urgent full-screen warning is sent. The cutoff for any notification at all is magnitude 4.5 — below that, and Google won’t send alerts. Such earthquakes might be felt, but they are unlikely to cause damage or kill people. Google also sends an after-the-fact notification with more information about the earthquake once it’s passed.
Cautious and methodical rollout
The earthquake that happened in the Philippines last Sunday was the strongest test that Google’s alert system had yet. However, alerts have also been sent for smaller earthquakes, including a handful in New Zealand. On average, Stogaitis tells us an alert is sent out every few weeks these days, mostly for quakes on the smaller side, around 4.5-5 on the Richter scale.
Part of that low average has to do with the limited rollout so far. Right now, this fancy crowdsourced detection system is only live in New Zealand, Greece, Turkey, the Philippines, Kazakhstan, Kyrgyz Republic, Tajikistan, Turkmenistan, and Uzbekistan. Though Google also does alerts on the US west coast, those are based on the existing USGS ShakeAlert detection system and its network of seismometers. In fact, Google looked at the ShakeAlert model when designing this system as an example, and the ultimate partnership between Google and the USGS for alerts fortuitously stemmed from Google’s efforts to expand its alerting infrastructure for its own crowdsourced system.
Google wants to make sure it can learn all it can in each new area as it rolls out
Even with its success, Google and Stogaitis’s team are sticking to a cautious and methodical rollout. In fact, the deployment to date is based on an internal assessment ranking countries where it would do the most good. Sure, places like Japan see a lot of earthquakes, but they already have their own detection and alerts system in place. While Google may eventually bring it to those kinds of markets, the team wanted to ensure the feature came first to countries with more or bigger earthquakes without any system of their own, ensuring it does the most benefit possible country-by-country without rushing things.
Another part of the reason for the slow rollout is that earthquakes and geography are different everywhere, and Google wants to make sure it can learn all it can in each new area as it rolls out, studying to see if it needs to be tuned at all for new markets:
“Since we’re going region by region, it allows us to study those areas and see if we need to tune the system. Because that’s one of the remaining questions: do you need to change the system for an area or not? This is a way for us to verify, and so far, we haven’t had to make big changes for any particular area. We can use basically the same technique from area to area. And doing it this way allowed us to validate that.”
So far, we’re told Google hasn’t had to adjust the system to account for that, but it’s something that needed to be validated before they could be sure. In the future, Stogaitis tells us the team might fine-tune the model more specifically on a per-region basis:
“We think that over time we might have region-specific models, just because we can see that we can probably improve the accuracy of the magnitude estimation, for example, if we had a more custom model per region, and better target where we’re going to send alerts. But looking at it now, having a global model works pretty well.”
Nerding out over the finer technical aspects with Stogaitis over most of a forty-five-minute interview last week, one of the bigger details I took away was just how glad he and his team were to be working on the project and the positive impact it’s likely to have. From a week-long feasibility study at a hackathon to a ten-country rollout, all the way to a magnitude 6.7 earthquake just south of Manila, Android’s new Earthquake Alerts System leverages the platform’s strengths to save lives.
Shaking things up: How your phone is changing the way we detect earthquakes
Source: Poinoy Wattpad
إرسال تعليق