1. 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

2. Who are we? Daniel Obenshain Annie Tang Rishi Chandy Daniel Rosenberg

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

4. Background Earthquakes are dangerous threats Earthquakes are dangerous threats –USGS estimates 2000 deaths and $200 billion damages from 7.8 magnitude quake

5. Background Earthquakes are dangerous threats Earthquakes are dangerous threats –USGS estimates 2000 deaths and $200 billion damages from 7.8 magnitude quake Early warning could minimize suffering Early warning could minimize suffering –Activate safeguards in critical operations

6. Background Earthquakes are dangerous threats Earthquakes are dangerous threats –USGS estimates 2000 deaths and $200 billion damages from 7.8 magnitude quake Early warning could minimize suffering Early warning could minimize suffering –Activate safeguards in critical operations Providing early warning is an interesting problem Providing early warning is an interesting problem –Bayesian decision theory, geology, distributed computing

7. Background Earthquakes are dangerous threats Earthquakes are dangerous threats –USGS estimates 2000 deaths and $200 billion damages from 7.8 magnitude quake Early warning could minimize suffering Early warning could minimize suffering –Activate safeguards in critical operations Providing early warning is an interesting problem Providing early warning is an interesting problem –Bayesian decision theory, geology, distributed computing Current seismic network is too sparse Current seismic network is too sparse –Can’t provide enough early warning

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

9. Sensor Network is too Sparse Ten thousand sensors! Both a 3 second wave and a 1 second wave.

10. Early Warning Can Help Slow trains

11. Early Warning Can Help Slow trains Stop elevators

12. Early Warning Can Help Slow trains Stop elevators Open fire station doors

13. Early Warning Can Help The information can also help the electrical grid. The information can also help the electrical grid. Southern California Edison Territory

14. Early Warning Can Help The information can also help the electrical grid. The information can also help the electrical grid. The grid can be shut down and made safe prior to severe shaking. The grid can be shut down and made safe prior to severe shaking. Southern California Edison Territory

15. Early Warning Can Help The information can also help the electrical grid. The information can also help the electrical grid. The grid can be shut down and made safe prior to severe shaking. The grid can be shut down and made safe prior to severe shaking. Power back in a day, not weeks after earthquake. Power back in a day, not weeks after earthquake. Southern California Edison Territory

16. Benefits Provide Early Warning Provide Early Warning Easy deployment in areas without existing seismic networks Easy deployment in areas without existing seismic networks –Peru and Indonesia  Cell phones are prevalent Identify hard-hit areas quickly Identify hard-hit areas quickly –Direct first responders

17. That’s why we’re doing it. What about how we’re doing it?

18. Expand the Network We want to add more data. We want to add more data.

19. Expand the Network We want to add more data. We want to add more data. Why not get data from as many sources as possible? Why not get data from as many sources as possible?

20. Expand the Network We want to add more data. We want to add more data. Why not get data from as many sources as possible? Why not get data from as many sources as possible? Add in acceleration devices of different types, cell phones, laptops, etc. Add in acceleration devices of different types, cell phones, laptops, etc.

21. Expand the Network We want to add more data. We want to add more data. Why not get data from as many sources as possible? Why not get data from as many sources as possible? Add in acceleration devices of different types, cell phones, laptops, etc. 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 User installs some client software and his or her acceleration data becomes part of the network.

22. The Client Registration Handler Registration Handler Sensor Handler Sensor Handler Server Registration Handler Server Registration Handler Error, No Update, or Handlers Calculation Handler Calculation Handler Alert Handler Controller Registration handler invoked on first run Returns Proceed, Error, or New Handlers Handlers and Queues managed Core processing Server Alert Listener Server Alert Listener

23. Picking Algorithm How often should the client send data to the server? How often should the client send data to the server?

24. Picking Algorithm How often should the client send data to the server? How often should the client send data to the server? Only when significant shaking is occurring. Only when significant shaking is occurring.

25. Picking Algorithm How often should the client send data to the server? How often should the client send data to the server? Only when significant shaking is occurring. Only when significant shaking is occurring. How does the client know? How does the client know?

26. Picking Algorithm How often should the client send data to the server? How often should the client send data to the server? Only when significant shaking is occurring. Only when significant shaking is occurring. How does the client know? How does the client know? It performs a simple calculation on the incoming data stream. It performs a simple calculation on the incoming data stream.

27. Picking Algorithm How often should the client send data to the server? How often should the client send data to the server? Only when significant shaking is occurring. Only when significant shaking is occurring. How does the client know? How does the client know? It performs a simple calculation on the incoming data stream. It performs a simple calculation on the incoming data stream. We call this the “Picking Algorithm.” We call this the “Picking Algorithm.”

28. Picking Algorithm STA/LTA > trigger

29. Picking Algorithm STA – Short Term Average : the average acceleration over the past several data points STA – Short Term Average : the average acceleration over the past several data points STA/LTA > trigger

30. Picking Algorithm STA – Short Term Average : the average acceleration over the past several data points STA – Short Term Average : the average acceleration over the past several data points LTA – Long Term Average : the average acceleration over more data points LTA – Long Term Average : the average acceleration over more data points STA/LTA > trigger

31. Picking Algorithm STA – Short Term Average : the average acceleration over the past several data points STA – Short Term Average : the average acceleration over the past several data points LTA – Long Term Average : the average acceleration over more data points LTA – Long Term Average : the average acceleration over more data points trigger – a threshold trigger – a threshold STA/LTA > trigger

32. Picking Algorithm Accelerometer Long Term Average Short Term Average

33. Picking Algorithm Accelerometer New Data Long Term Average Short Term Average

34. Picking Algorithm Accelerometer Short Term Average Long Term Average

35. Picking Algorithm If STA/LTA > trigger is true, then we have “picked.” If STA/LTA > trigger is true, then we have “picked.”

36. Picking Algorithm If STA/LTA > trigger is true, then we have “picked.” If STA/LTA > trigger is true, then we have “picked.” The algorithm then waits a little bit before sending a message to the server. The algorithm then waits a little bit before sending a message to the server.

37. Picking Algorithm If STA/LTA > trigger is true, then we have “picked.” If STA/LTA > trigger is true, then we have “picked.” The algorithm then waits a little bit before sending a message to the server. 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. This is to make sure it sends data from the peak of the wave.

38. Picking Algorithm Pause for this length of time before sending a message to the server. 1 2 3 1.Detected significant shaking 2.Maximum shaking 3.Sent message to server

39. Picking Algorithm After sending a message to the server, the client will wait a while before picking again. After sending a message to the server, the client will wait a while before picking again.

40. Picking Algorithm After sending a message to the server, the client will wait a while before picking again. 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. This is to stop the client from picking multiple times for the same shaking.

41. Picking Algorithm Delay for this length of time before picking again. 1 1.Last message sent to server 2.The coda of the earthquake, where we don’t want to pick 2

42. Picking Algorithm Five tunable parameters. Five tunable parameters.

43. Picking Algorithm Five tunable parameters. Five tunable parameters. –Length of STA

44. Picking Algorithm Five tunable parameters. Five tunable parameters. –Length of STA –Length of LTA

45. Picking Algorithm Five tunable parameters. Five tunable parameters. –Length of STA –Length of LTA –Value of trigger

46. Picking Algorithm Five tunable parameters. 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

47. Picking Algorithm Five tunable parameters. 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

48. Picking Algorithm Five tunable parameters. 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. They can all be tuned by the server, on a client-by-client basis.

49. GUI Acceleration data is displayed in real time on the user’s screen. Acceleration data is displayed in real time on the user’s screen.

50. GUI Promotes use of the software. Promotes use of the software.

51. GUI Acceleration data is displayed in real time on the user’s screen. Acceleration data is displayed in real time on the user’s screen. Promotes use of the software. Promotes use of the software. Can be used in science classrooms to explain project. Can be used in science classrooms to explain project.

52. GUI Acceleration data is displayed in real time on the user’s screen. Acceleration data is displayed in real time on the user’s screen. Promotes use of the software. Promotes use of the software. Can be used in science classrooms to explain project. Can be used in science classrooms to explain project. Each message to the server marked by a red line. Each message to the server marked by a red line.

53. GUI 3 Axes 3 Axes

54. GUI Data streams from the right Data streams from the right

55. GUI 3 Axes 3 Axes Data streams from the right Data streams from the right The red line represents a message to the server The red line represents a message to the server

56. Sensor Validation Tested our sensor with artificial event. Tested our sensor with artificial event.

57. Sensor Validation Tested our sensor with artificial event. Tested our sensor with artificial event. Compared our sensor to the SCSN (Southern California Seismic Network) sensor in the basement of Millikan Library. Compared our sensor to the SCSN (Southern California Seismic Network) sensor in the basement of Millikan Library.

58. Sensor Validation Tested our sensor with artificial event. Tested our sensor with artificial event. Compared our sensor to the SCSN (Southern California Seismic Network) sensor in the basement of Millikan Library. Compared our sensor to the SCSN (Southern California Seismic Network) sensor in the basement of Millikan Library. Caused seismic activity with a sledgehammer. Caused seismic activity with a sledgehammer.

59. Sensor Validation

60. We have since switched to better noise filtering and a better sensor We have since switched to better noise filtering and a better sensor Still, the correlation is visible Still, the correlation is visible

61. Client Side Overview Registration Registration –Keys, location, sensor type, address (optional) –Client ID Data Storage Data Storage –SAC file, ring buffer Heartbeat Heartbeat –Sensor “check in”, log request, playback request

62. Registration TCP Message: TCP Message: –Keys, location, sensor type, address (optional) –Client ID Key Generator: Key Generator: –Key pair: public key & private key –DSA

63. Registration Skyhook 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

64. Data Storage Ring Buffer Ring Buffer –New data is pushed in –Oldest data is deleted –Keep STA/LTA SAC File SAC File –Seismic Analysis Code –Analyze data in time series

65. Data Storage SAC File (continue) SAC File (continue) –Header  Sampling interval, start time, length, station location, etc. –Logs

66. Heartbeat TCP Message TCP Message –Time, location, Client ID –Log Request, Playback Request, Updates Purpose Purpose –Active Sensors –Current Locations –Communication between client and server –Calibration

67. Data

68. Data We have lots of it.

69. Server Four main tasks Four main tasks –Handle new user registration

70. Server Four main tasks Four main tasks –Handle new user registration –Listen for pick messages

71. Server Four main tasks Four main tasks –Handle new user registration –Listen for pick messages –Handle heartbeat messages

72. Server Four main tasks Four main tasks –Handle new user registration –Listen for pick messages –Handle heartbeat messages –Analyze data Main tech Main tech –Java, PHP, Javascript, XML –MySQL –Apache Java Libraries

73. Server Registration Handler Pick Handler Heartbeat Handler DatabaseAssociator

74. Messaging Open and extensible XML schema Open and extensible XML schema –Allows others to join the network We use TCP and UDP We use TCP and UDP

75. UDP vs TCP We send messages using two different protocols. TCP (Transmission Control Protocol) TCP (Transmission Control Protocol) –Handshake delay –Error correction

76. UDP vs TCP We send messages using two different protocols. TCP (Transmission Control Protocol) TCP (Transmission Control Protocol) –Handshake delay –Error correction UDP (User Datagram Protocol) UDP (User Datagram Protocol) –Fast –Unreliable

77. Pick Message Handler Pick messages are sent using UDP packets. Reasons: Reasons: –Unsure of condition of network –Speed is important

78. Pick Message Handler Listen for incoming picks Listen for incoming picks

79. Pick Message Handler Listen for incoming picks Listen for incoming picks –Parse message

80. Pick Message Handler Listen for incoming picks Listen for incoming picks –Parse message –Check signature

81. Pick Message Handler Listen for incoming picks 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.

82. Security All messages from the client are verified using XML signatures. All messages from the client are verified using XML signatures.

83. Security –Client has private key, Server knows public key

84. Security All messages from the client are verified using XML signatures. 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

85. Security All messages from the client are verified using XML signatures. 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

86. Security All messages from the client are verified using XML signatures. 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 This prevents any message interception attacks We can control valid clientIDs We can control valid clientIDs

87. Server-side Challenges Incoming messages from a vast network 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 Response time is critical –Excessive latency is unacceptable –Indiana Jones effect Methods must be accurate and precise Methods must be accurate and precise –EW is useless otherwise

88. Registration Clients sends XML Clients sends XML –Latitude, Longitude –Public Key Server returns XML Server returns XML –Unique clientID

89. Example Registration XML 349oi3j4oij32ui23 40.779761 -74.0310 1200 E California Blvd Pasadena, CA 91125 usb:deviceID

90. Heartbeat Clients update us on their status Clients update us on their status –location Server returns: Server returns: –Software updates –Tunable parameters –Playback waveforms –Log Requests Location is updated in DB Location is updated in DB

91. Playback Operation We can distribute waveforms for clients to simulate We can distribute waveforms for clients to simulate

92. Playback Operation We can distribute waveforms for clients to simulate We can distribute waveforms for clients to simulate Stress-test the network Stress-test the network Evaluate new algorithms Evaluate new algorithms Determine network latencies Determine network latencies

93. Log Requests Clients send Pick Messages using UDP Clients send Pick Messages using UDP –Sufficient for early warning calculation

94. Log Requests Clients send Pick Messages using UDP Clients send Pick Messages using UDP –Sufficient for early warning calculation –Insufficient for later analysis After an earthquake, server requests logs during Heartbeat After an earthquake, server requests logs during Heartbeat

95. Server Operation Registration Listener Registration Listener Alert Listener Clients’ Registration Handlers Clients’ Registration Handlers Signed Regstr Mesg Error, No Update, or Handlers Calculation Handler Calculation Handler Warning Handler Warning Handler Controller Server’s Registration Listener is self-contained Handlers and Queues managed Core processing Clients’ Registration Handlers Clients’ Registration Handlers Clients’ Registration Handlers Clients’ Registration Handlers Clients’ Registration Handlers Clients’ Registration Handlers Equipment, devices, notification systems Clients’ Registration Handlers Clients’ Registration Handlers Clients’ Registration Handlers Clients’ Registration Handlers Clients’ Registration Handlers Clients’ Registration Handlers Clients’ Alert Handlers Clients’ Alert Handlers

96. Server-side Analysis Bayesian decision-making Bayesian decision-making

97. Server-side Analysis Bayesian decision-making Bayesian decision-making Once posterior is sufficient, we send EW Once posterior is sufficient, we send EW

99. Next Steps Cell phones w/ accelerometers Cell phones w/ accelerometers –Android Laptops w/ accelerometers Laptops w/ accelerometers Google App Engine Google App Engine –Robust, scalable

100. Acknowledgements Thanks to Professors K. Mani Chandy, Rob Clayton, Andreas Krause, and Michael Olson for their mentorship and guidance Thanks to Professors K. Mani Chandy, Rob Clayton, Andreas Krause, and Michael Olson for their mentorship and guidance Our generous SURF sponsors Our generous SURF sponsors –Rita A. and Øisten Skjellum –Kiyo and Eiko Tomiyasu

101. Thank You Q&A Session