Transcript SURF Presentation - Distributed Systems and Networks Lab

Community Seismic
Network for Early Warning
Rishi Chandy
Rita A. and Øisten Skjellum SURF Fellow
Daniel Obenshain
Kiyo and Eiko Tomiyasu SURF Scholar
Daniel Rosenberg
Kiyo and Eiko Tomiyasu SURF Scholar
Annie Tang
Mentors: K. Mani Chandy, Robert Clayton, Andreas Krause
California Institute of Technology
Who are we?
Daniel Obenshain
Annie Tang
Rishi Chandy
Daniel Rosenberg
Our Mentors
Dr. K. Mani Chandy
Professor of
Computer Science
Dr. Andreas Krause
Assistant Professor of
Computer Science
Dr. Rob Clayton
Professor of
Geophysics
Michael Olson
Grad Student
Computer Science
Background

Earthquakes are dangerous threats
– USGS estimates 2000 deaths and $200 billion
damages from 7.8 magnitude quake
Background

Earthquakes are dangerous threats
– USGS estimates 2000 deaths and $200 billion
damages from 7.8 magnitude quake

Early warning could minimize suffering
– Activate safeguards in critical operations
Background

Earthquakes are dangerous threats
– USGS estimates 2000 deaths and $200 billion
damages from 7.8 magnitude quake

Early warning could minimize suffering
– Activate safeguards in critical operations

Providing early warning is an interesting problem
– Bayesian decision theory, geology, distributed
computing
Background

Earthquakes are dangerous threats
– USGS estimates 2000 deaths and $200 billion
damages from 7.8 magnitude quake

Early warning could minimize suffering
– Activate safeguards in critical operations

Providing early warning is an interesting problem
– Bayesian decision theory, geology, distributed
computing

Current seismic network is too sparse
– Can’t provide enough early warning
Sensor Network is too Sparse
A sensor network of
one hundred sensors.
A sensor network of
one thousand sensors.
SCSN (Southern California Seismic Network) has ~350 sensors right now.
Sensor Network is too Sparse
Ten thousand sensors!
Both a 3 second wave and a 1 second wave.
Early Warning Can Help
Slow trains
Early Warning Can Help
Slow trains
Stop elevators
Early Warning Can Help
Slow trains
Stop elevators
Open fire station doors
Early Warning Can Help

Southern California Edison Territory
The information can
also help the electrical
grid.
Early Warning Can Help
The information can
also help the electrical
grid.
 The grid can be shut
down and made safe
prior to severe
shaking.

Southern California Edison Territory
Early Warning Can Help
The information can
also help the electrical
grid.
 The grid can be shut
down and made safe
prior to severe
shaking.
 Power back in a day,
not weeks after
earthquake.

Southern California Edison Territory
Benefits
Provide Early Warning
 Easy deployment in areas without existing
seismic networks

– Peru and Indonesia
 Cell phones are prevalent

Identify hard-hit areas quickly
– Direct first responders
That’s why we’re
doing it.
What about how
we’re doing it?
Expand the Network

We want to add more data.
Expand the Network
We want to add more data.
 Why not get data from as many sources
as possible?

Expand the Network
We want to add more data.
 Why not get data from as many sources
as possible?
 Add in acceleration devices of different
types, cell phones, laptops, etc.

Expand the Network
We want to add more data.
 Why not get data from as many sources
as possible?
 Add in acceleration devices of different
types, cell phones, laptops, etc.
 The User installs some client software and
his or her acceleration data becomes part
of the network.

The Client
Server
Registration
Handler
Server
Alert
Listener
Registration
Handler
Sensor
Handler
Calculation
Handler
Handlers and Queues managed
Returns Proceed, Error, or New Handlers
Registration handler invoked on first run
Controller
Alert
Handler
Core processing
Error, No
Update, or
Handlers
Picking Algorithm

How often should the client send data to
the server?
Picking Algorithm
How often should the client send data to
the server?
 Only when significant shaking is occurring.

Picking Algorithm
How often should the client send data to
the server?
 Only when significant shaking is occurring.
 How does the client know?

Picking Algorithm
How often should the client send data to
the server?
 Only when significant shaking is occurring.
 How does the client know?
 It performs a simple calculation on the
incoming data stream.

Picking Algorithm
How often should the client send data to
the server?
 Only when significant shaking is occurring.
 How does the client know?
 It performs a simple calculation on the
incoming data stream.
 We call this the “Picking Algorithm.”

Picking Algorithm
STA/LTA > trigger
Picking Algorithm
STA/LTA > trigger

STA – Short Term Average : the average
acceleration over the past several data
points
Picking Algorithm
STA/LTA > trigger
STA – Short Term Average : the average
acceleration over the past several data
points
 LTA – Long Term Average : the average
acceleration over more data points

Picking Algorithm
STA/LTA > trigger
STA – Short Term Average : the average
acceleration over the past several data
points
 LTA – Long Term Average : the average
acceleration over more data points
 trigger – a threshold

Picking Algorithm
Short Term Average
Long Term Average
Accelerometer
Picking Algorithm
Short Term Average
Long Term Average
New Data
Accelerometer
Picking Algorithm
Short Term Average
Long Term Average
Accelerometer
Picking Algorithm

If STA/LTA > trigger is true, then we have
“picked.”
Picking Algorithm
If STA/LTA > trigger is true, then we have
“picked.”
 The algorithm then waits a little bit before
sending a message to the server.

Picking Algorithm
If STA/LTA > trigger is true, then we have
“picked.”
 The algorithm then waits a little bit before
sending a message to the server.
 This is to make sure it sends data from
the peak of the wave.

Picking Algorithm
1 2 3
Pause for this length of time before
sending a message to the server.
1. Detected significant shaking
2. Maximum shaking
3. Sent message to server
Picking Algorithm

After sending a message to the server, the
client will wait a while before picking
again.
Picking Algorithm
After sending a message to the server, the
client will wait a while before picking
again.
 This is to stop the client from picking
multiple times for the same shaking.

Picking Algorithm
1
2
Delay for this length of time
before picking again.
1. Last message sent to server
2. The coda of the earthquake, where
we don’t want to pick
Picking Algorithm

Five tunable parameters.
Picking Algorithm

Five tunable parameters.
– Length of STA
Picking Algorithm

Five tunable parameters.
– Length of STA
– Length of LTA
Picking Algorithm

Five tunable parameters.
– Length of STA
– Length of LTA
– Value of trigger
Picking Algorithm

Five tunable parameters.
– Length of STA
– Length of LTA
– Value of trigger
– How long to wait after picking before sending
a message to the server
Picking Algorithm

Five tunable parameters.
– Length of STA
– Length of LTA
– Value of trigger
– How long to wait after picking before sending
a message to the server
– How long to wait between messages
Picking Algorithm

Five tunable parameters.
– Length of STA
– Length of LTA
– Value of trigger
– How long to wait after picking before sending
a message to the server
– How long to wait between messages

They can all be tuned by the server, on a
client-by-client basis.
GUI

Acceleration data is displayed in real time
on the user’s screen.
GUI
Acceleration data is displayed in real time
on the user’s screen.
 Promotes use of the software.

GUI
Acceleration data is displayed in real time
on the user’s screen.
 Promotes use of the software.
 Can be used in science classrooms to
explain project.

GUI
Acceleration data is displayed in real time
on the user’s screen.
 Promotes use of the software.
 Can be used in science classrooms to
explain project.
 Each message to the server marked by a
red line.

GUI

3 Axes
GUI
3 Axes
 Data streams from
the right

GUI
3 Axes
 Data streams from
the right
 The red line
represents a message
to the server

Sensor Validation

Tested our sensor with artificial event.
Sensor Validation
Tested our sensor with artificial event.
 Compared our sensor to the SCSN
(Southern California Seismic Network)
sensor in the basement of Millikan Library.

Sensor Validation
Tested our sensor with artificial event.
 Compared our sensor to the SCSN
(Southern California Seismic Network)
sensor in the basement of Millikan Library.
 Caused seismic activity with a
sledgehammer.

Sensor Validation
Sensor Validation
We have since switched to better noise filtering
and a better sensor
 Still, the correlation is visible

Client Side Overview

Registration
– Keys, location, sensor type, address (optional)
– Client ID

Data Storage
– SAC file, ring buffer

Heartbeat
– Sensor “check in”, log request, playback
request
Registration

TCP Message:
– Keys, location, sensor type, address (optional)
– Client ID

Key Generator:
– Key pair: public key & private key
– DSA
Registration

Skyhook
– Software only Hybrid Positioning System (XPS)
 Combine WPS, GPS, and Cellular Towers
– Accuracy: 10 to 20 meters
– Latitude, longitude, address
– Reasons to choose Skyhook:
 GPS signal is not always available
 Fast and accurate
 Cons: needs Wi-Fi
– IP Address
Data Storage

Ring Buffer
– New data is pushed in
– Oldest data is deleted
– Keep STA/LTA

SAC File
– Seismic Analysis Code
– Analyze data in time series
Data Storage

SAC File (continue)
– Header
 Sampling interval, start time, length, station
location, etc.
– Logs
Heartbeat

TCP Message
– Time, location, Client ID
– Log Request, Playback Request, Updates

Purpose
– Active Sensors
– Current Locations
– Communication between client and server
– Calibration
Data
Data
We have lots of it.
Server

Four main tasks
– Handle new user registration
Server

Four main tasks
– Handle new user registration
– Listen for pick messages
Server

Four main tasks
– Handle new user registration
– Listen for pick messages
– Handle heartbeat messages
Server

Four main tasks
– Handle new user registration
– Listen for pick messages
– Handle heartbeat messages
– Analyze data

Main tech
– Java, PHP, Javascript, XML
– MySQL
– Apache Java Libraries
Server
Registration
Handler
Pick Handler
Heartbeat Handler
Database
Associator
Messaging

Open and extensible XML schema
– Allows others to join the network

We use TCP and UDP
UDP vs TCP
We send messages using two different protocols.

TCP (Transmission Control Protocol)
– Handshake delay
– Error correction
UDP vs TCP
We send messages using two different protocols.

TCP (Transmission Control Protocol)
– Handshake delay
– Error correction

UDP (User Datagram Protocol)
– Fast
– Unreliable
Pick Message Handler
Pick messages are sent using UDP packets.
 Reasons:
– Unsure of condition of network
– Speed is important
Pick Message Handler

Listen for incoming picks
Pick Message Handler

Listen for incoming picks
– Parse message
Pick Message Handler

Listen for incoming picks
– Parse message
– Check signature
Pick Message Handler

Listen for incoming picks
– Parse message
– Check signature
– Check for playback flag
 If the flag is not present, the pick is stored in the
database.
 If the message is flagged as playback, it is written
to a separate table in the database.
Security

All messages from the client are verified
using XML signatures.
Security

All messages from the client are verified
using XML signatures.
– Client has private key, Server knows public
key
Security

All messages from the client are verified
using XML signatures.
– Client has private key, Server knows public
key
– Client signs messages using its private key
Security

All messages from the client are verified
using XML signatures.
– Client has private key, Server knows public
key
– Client signs messages using its private key
– Server verifies messages using the stored
public key
Security

All messages from the client are verified
using XML signatures.
– Client has private key, Server knows public
key
– Client signs messages using its private key
– Server verifies messages using the stored
public key
This prevents any message interception
attacks
 We can control valid clientIDs

Server-side Challenges

Incoming messages from a vast network
– Can’t get overwhelmed
– Want to grab as much data as we can
– Application must be scalable

Response time is critical
– Excessive latency is unacceptable
– Indiana Jones effect

Methods must be accurate and precise
– EW is useless otherwise
Registration

Clients sends XML
– Latitude, Longitude
– Public Key

Server returns XML
– Unique clientID
Example Registration XML
<registration>
<publicKey>349oi3j4oij32ui23</publicKey>
<location>
<latitude>40.779761</latitude>
<longitude>-74.0310</longitude>
</location>
<locationDescription>
1200 E California Blvd Pasadena, CA 91125
</locationDescription>
<sensor>usb:deviceID</sensor>
</registration>
Heartbeat

Clients update us on their status
– location

Server returns:
– Software updates
– Tunable parameters
– Playback waveforms
– Log Requests

Location is updated in DB
Playback Operation

We can distribute waveforms for clients to
simulate
Playback Operation
We can distribute waveforms for clients to
simulate
 Stress-test the network
 Evaluate new algorithms
 Determine network latencies

Log Requests

Clients send Pick Messages using UDP
– Sufficient for early warning calculation
Log Requests

Clients send Pick Messages using UDP
– Sufficient for early warning calculation
– Insufficient for later analysis

After an earthquake, server requests logs
during Heartbeat
Server Operation
Clients’
Clients’
Clients’
Clients’
Registration
Registration
Registration
Registration
Handlers
Handlers
Handlers
Handlers
Equipment, devices,
notification systems
Error, No
Update, or
Handlers
Registration
Listener
Alert
Listener
Calculation
Handler
Handlers and Queues managed
Server’s Registration Listener is self-contained
Controller
Warning
Handler
Core processing
Signed
Regstr
Mesg
Clients’
Clients’
Clients’
Clients’
Registration
Registration
Registration
Alert Handlers
Handlers
Handlers
Handlers
Server-side Analysis

Bayesian decision-making
Server-side Analysis

Bayesian decision-making

Once posterior is sufficient, we send EW
Next Steps

Cell phones w/
accelerometers
– Android
Laptops w/
accelerometers
 Google App Engine

– Robust, scalable
Acknowledgements
Thanks to Professors K. Mani Chandy, Rob
Clayton, Andreas Krause, and Michael
Olson for their mentorship and guidance
 Our generous SURF sponsors

– Rita A. and Øisten Skjellum
– Kiyo and Eiko Tomiyasu
Thank You
Q&A Session