Systems and methods for early warning of seismic events

A seismic warning system comprises: a plurality of sensors, each sensor sensitive to a physical phenomenon associated with seismic events and operative to output an electronic signal representative of the sensed physical phenomenon; a data acquisition unit communicatively coupled to receive the electronic signal from each of the plurality of sensors, the data acquisition unit comprising a processor configured to estimate characteristics of a seismic event based on the electronic signal associated with a P-wave from each of the plurality of sensors; and a local device communicatively coupled to the data acquisition unit. The plurality of sensors, the data acquisition unit and the local device are local to one another.

TECHNICAL FIELD

Systems and methods provide early detection of seismic events (e.g. earthquakes), determine characteristics of detected seismic events, take actions to minimize damage in view of detected seismic events, take actions to minimize injury in view of detected seismic events and/or provide situational alarms and/or recommendations to user(s) in view of detected seismic events.

BACKGROUND

Sensors may be used to detect earthquakes. Some such sensors may also be used in earthquake early warning systems (EEWS) to determine (or estimate) characteristics of earthquakes, such as the epicenter or hypocenter of the earthquake, the magnitude of the surface wave associated with the earthquake and the time of arrival of the surface wave associated with the earthquake. The sensors of prior art earthquake detection systems are generally placed several tens of kilometers or several hundreds of kilometers apart, with the earthquake detection systems comprising data acquisition equipment at each spaced-apart sensor location. This large separation between sensors is typically required in most prior art systems, since most prior art systems have a timing accuracy on the order of seconds or hundreds of milliseconds. The placement of such sensors in close proximity is not possible, where it is desired to know the epicenter of the seismic event, since the epicenter would not be detectable.

Data acquisition equipment (typically located at the same location as the sensors) may be used to log detected data. U.S. Pat. No. 5,381,136 (Powers et al.) describes a remote logger unit for monitoring a variety of operating parameters along a fluid distribution or transmission system. An RF link is activated by which a logger unit alerts a central controller when predetermined operating limits are exceeded. Relatively more distal logger units transmit data to a central controller via relatively more proximate logger units in daisy chain fashion.

U.S. Pat. No. 8,452,540 (Sugawara et al.) describes an earthquake damage spread reducing method and an earthquake damage spread reducing system, for use in a semiconductor manufacturing apparatus, which can predict occurrence of an earthquake and prevent fall down of a boat, thus minimizing damage by the earthquake. An earthquake damage spread reducing system includes a receiving unit for receiving urgent earthquake information, based on preliminary tremors, distributed via a communication network, or alternatively, includes a preliminary tremors detection unit for directly detecting the preliminary tremors. A control unit performs a first step of stopping operation of a semiconductor manufacturing apparatus, based on the urgent earthquake information received or on the preliminary tremors detected, as well as performs a second step of holding a boat to prevent fall of the boat, in which objects to be processed are loaded in a multistage fashion.

US Patent Application No. 2014/0187142 (Liu et al.) describes a seismic alarm system designed to alarm users of an upcoming seismic event and other natural disasters, and aid victims' survival after an earthquake. The seismic alarm system includes an accelerometer, a controller, an acoustic-to-electric transducer for acoustic pattern detection, and RF module to receive emergency radio signals. The alarm system has central controlling unit that sets off an alarm after processing signals from several modules and components. The accelerometer detects seismic P wave acceleration changes for early earthquake detection. The acoustic-to-electric transducer detects human acoustics or predetermined acoustic patterns, then initiates an alarm that brings rescue attention to survivors. The RF module is tuned to receive emergency radio signals.

U.S. Pat. No. 5,910,763 (Flanagan et al.) describes a system that provides an area warning to a specific general population of an earthquake prior to the arrival of the hazardous ground motion typically associated with earthquakes, and of approaching natural disasters that could impact an area. This area advanced warning thereby provides time for users to seek shelter and through automated means to reduce property damage as well as injuries and lives lost. A preferred embodiment utilizes a plurality of “Local Station Detector Sites”, equipped with earthquake seismic motion detectors and microprocessors designed to provide a profile of existing ground motion to a “Central Processing Site” in conjunction with further analysis of similar signals from multiple sites. A warning instruction is then transmitted back to all appropriate Local Station Detector Sites to initiate transmission of local area warnings to a general population of all users in an appropriate and specific geographic area with minimal possibility of false alarms. Additionally all Local Station Detector Sites are equipped to receive notification transmissions from the Central Processing Site, which have been initiated by “Public Safety Offices” for other natural disasters, and transmit appropriate warning signals to the general population of users in specific geographic areas.

US Patent Application No. US2015/0195693 (Hoorianin et al.) describes a mobile phone and tablet-based earthquake early warning system that utilizes the on board accelerometer, gyroscope, GPS and other location and movement sensing technologies built into today's mobile smart phones and tablet devices to detect an earthquake event and send an alarm to those in nearby locations that could be adversely affected by the event.

Existing EEWS systems use various data acquisition techniques to obtain seismic activity measurements. Seismic activity measurements reveal risks of potential damage from earthquakes and provide early warning of the arrival of the S-wave (secondary wave) associated with an earthquake, making such measurements useful for preventing and/or minimizing human injury/death and damage to property. When an earthquake occurs, casualties and damage are typically positively correlated with preparedness and amount of warning time.

The US Geological Survey states that early warning of earthquakes “can give enough time to slow and stop trains and taxiing planes, to prevent cars from entering bridges and tunnels, to move away from dangerous machines or chemicals in work environments and to take cover under a desk, or to automatically shut down and isolate industrial systems. Taking such actions before shaking starts can reduce damage and casualties during an earthquake. It can also prevent cascading failures in the aftermath of an event. For example, isolating utilities before shaking starts can reduce the number of fire initiations.”

The Federal Emergency Management Agency (FEMA) has estimated the average annualized loss from earthquakes, nationwide, to be $5.3 billion. The Seismological Society of America states that “Earthquake Early Warning Systems (EEWS) could also reduce the number of injuries in earthquakes by more than 50%.”

Many countries, including the US, Canada and Japan, are investing in the deployment of EEWS, as are government authorities at other levels.

The Seismological Society of America states that EEWS, “like warnings for other natural disasters, such as tornadoes, hurricanes, and tsunamis, is a forecast of activity that is imminent. However, unlike hurricane warnings, which can come days in advance of severe weather, or tsunami warnings, which build over the course of a few minutes to a few hours before the tsunami makes landfall, earthquakes have a much shorter lead time, shorter even than a funnel cloud that starts spiraling toward the earth. A warning could be just seconds. This short warning time is a product of the physical process of an earthquake rupture. EEWS typically use seismometers to detect the first signature of an earthquake (P-wave), to process the waveform information, and to forecast the intensity of shaking that will arrive after the S-wave. For local EEWS installations, the P-wave is detected onsite (i.e., at the user location), and the difference between the P- and S-wave arrival times defines the maximum alert time. For regional networks, the P-waves are detected by sensors closest to the epicenter, and estimates are immediately relayed to earthquake alerting applications (TV, smart phones, radio, etc.) to provide businesses, citizens, and emergency responders more advance knowledge of the expected arrival and intensity of shaking at their location.”

Prior art EEWS systems make use of electronic sensors measure physical quantities (such as velocity, acceleration strain, temperature, crack, pressure, etc.) and convert these physical quantities into signals using suitable reading instruments (e.g. transducers). The particular reading instrument varies depending on the type of sensor. For example, geophones typically incorporate a wire coil with a magnet in the middle that is free to move. As the sensor shakes or vibrates (as is the case during an earthquake), the magnet moves through the coil producing a current, which can be measured to record the variations. To determine the epicenter and the magnitude of an earthquake in accordance with prior art EEWS systems, three to four sensor locations (typically spaced apart by tens of kilometers or hundreds of kilometers) detect the earthquake and communicate with each other to exchange data. The accuracy of epicenter and magnitude predictions depends on the time synchronization between sensor locations and network communication speed between sensor locations.

While existing EEWS systems provide some early warning and damage reduction capabilities, they have at least the following deficiencies:To accurately detect the epicenter and magnitude of the earthquake, the sensors must typically be located relatively far apart (typically 10's or 100's of km) from one another, since the timing accuracy of the systems is on the order of seconds or hundreds of milliseconds. Data from all sensors of interest must typically be gathered and correlated, and the data must then be processed before determining if a warning is to be issued. When sensor locations are hundreds of kilometers apart, gathering, correlating and processing data are time consuming, thereby reducing potential warning time. Some EEWS systems, for example, the system described in U.S. Pat. No. 9,372,272 (Price et al.) comprise sensors that can be placed less than 500 m apart from each other; however, such sensors must be hard wired to a central controller. This is undesirable. First, installation is difficult and complicated since long cables must be installed, which may require digging channels in the earth or through concrete. Second, the long length of the cables could lead to signal degradation and unwanted noise, resulting in unreliable detection of the P-wave signal.Existing EEWS system employ centralized processing of data, which typically involves transmittal of large amounts of data, resulting in a corresponding need for high bandwidth, highly reliable and costly network infrastructure.Existing EEWS systems also have a need to transfer high volumes of data via network communications. These data transfer requirements dictate a corresponding need for high bandwidth network capability. Establishing and/or maintaining high bandwidth networks over large areas and/or remote locations can be very difficult and costly.Generating a warning with time to arrival of the damaging S-wave requires sensors at multiple locations with time synchronization between locations and high quality network communication between locations. The network communication must be able to transmit signals between the various components of the system with minimal latency in order to be an effective EEWS. There is thus a high need for low latency network communications which may not be readily available at all times.When sensors are far apart, the geology from the epicenter to each sensor can differ significantly. Such geological differences may result in inaccurate prediction of the time and magnitude of the oncoming S-wave. Alternatively, such geological differences require the use of accurate geological models which are costly and time consuming to generate.When existing EEWS systems issue warnings, these warnings are blanket warnings to all within the warning area. It is up to the individuals or organizations within the warning area to interpret the warning, assess the danger and take any desired actions. Some choose to do nothing simply because they do not know what to do or do not think they are in danger. Prior art EEWS systems have no knowledge an individual's or organization's situation or location or least do not incorporate any such knowledge into any applicable recommended courses of action. For instance, if an individual is driving on the freeway, the recommendation should be to pull over safely and stop. However, if the individual is driving in a tunnel, pulling over and stopping inside the tunnel is not the correct action. The preferred action would be to drive through the tunnel and then pull over and stop. As another example, because the generic warnings issued by prior art EEWS systems lack situational awareness within the warning area, such generic warnings can result in an organization unnecessarily shutting down equipment or processes, which can cause unnecessary losses and create more harm than good. Still further, generic warnings (without situational awareness) issued by prior art EEWS systems can cause unnecessary panic.In many existing EEWS systems, the decision-making and actions are left for individual manual execution, which is unreliable and inefficient. In many cases, manual execution is not possible due to the short time available prior to arrival of the damage-causing S-wave. Manual execution is prone to errors. Shutdown of critical equipment typically requires concentration and thought, which may be lacking in panic-driven conditions.Some existing EEWS systems do incorporate autonomous decision-making, but these EEWS systems have been historically unreliable, are expensive or non-viable, and/or have a false-positive ratio which is too high. In addition, these autonomous EEWS systems must typically be placed over a wide area with complicated networking schemes that make them impractical for use by smaller scale businesses and individuals. These autonomous EEWS systems are typically limited to large-scale deployment by government institutions or the like. Some existing autonomous EEWS systems have not operated reliably when earthquakes actually occur. These systems may work well in the laboratory under simulated or mechanically generated vibration conditions, but can tend to fail during actual earthquakes. Also, earthquakes do not occur regularly, making it difficult to perform thorough field testing.Existing EEWS systems only allow for one-way communication from the EEWS system to individuals (affected individuals and emergency response teams) in the warning zone over communication channels which typically require high priority and reliability. Emergency response teams typically use their own communication methods which are only accessible to the public through single points of entry, such as dedicated (call-in) phone numbers. The mere volume of calls during a disaster makes these call-in numbers congested resulting in long wait times. Other than such call-in numbers, there is no provision in existing EEWS systems for affected individuals to communicate back to emergency response teams, family and friends. As a result, affected individuals and emergency response teams may be tend to rely on other available communication services, such as social media, to communicate their condition, location and emergency needs. This individual use of distributed communication channels such as social media is highly inefficient and unreliable, especially when data networks become congested in the affected area (as is typical). Also, not all people affected are connected via social media and not all emergency response teams monitor social media. Further, general data communications over communication networks during a disaster can get highly congested due to the high volume of messages and messages typically do not receive high priority.Some existing EEWS systems, such as the one depicted in US Patent Application No. 2015/0195693 (Hooriani et al.), use sensors in mobile phones and tablets to detect earthquakes and provide warnings. However, such sensors cannot detect the P-wave and can only detect large movements of the S-wave, so they cannot provide a warning of a pending S-wave.Existing EEWS systems do not monitor the surrounding structures and equipment, so any damage resulting from a seismic event cannot be qualified and quantified. Existing EEWS systems report on the seismic event parameters only and have no knowledges of parameters (other than those of the seismic event) in the region in which the warning is issued. It is up to the use of the existing EEWS system to determine the safety risks and/or potential damage that is likely to result from a seismic event. It would be useful to know if the damage from a seismic event results in (or would be likely to result in) safety risks to the personnel using the equipment or utilizing the structure. Alarms and warning can then be issued as necessary to prevent further injuries or damage.

Accordingly, there is a general desire for systems and methods for early warning of seismic events that make use of autonomous actions, which autonomous actions may be executed quickly and efficiently, without the need for manual intervention. There is a general desire for such systems and methods to overcome or at least ameliorate some the drawbacks with prior art EEWS systems.

There is also a general desire for systems and methods for early warning of seismic events which incorporate situational awareness into any warnings that are issued in the event of a seismic event.

There is also a general desire for systems and methods for early warning of seismic events which can monitor and/or control communications (e.g. multi-way communications) through a suitable communication network.

There is also a general desire for systems and methods for early warning of seismic events which provide and maintain reliable, secure and rapid communications.

DETAILED DESCRIPTION

Aspects of the invention provide systems and methods for early warning of seismic events. Such systems and methods may comprise a plurality (e.g. three) separate technologies combined to operate as a flexible condition monitoring and event prediction system—data acquisition technology, sensor technology and event prediction software technology.

The sensors of prior art EEWS are generally placed tens to hundreds of kilometers apart, with the EEWS comprising data acquisition equipment at each sensor location. This large separation between sensors is typically required in most prior art systems, since most prior art systems have a timing accuracy on the order of seconds or hundreds of milliseconds. The need for sensors to be spaced apart by such distances is illustrated schematically byFIG. 1.FIG. 1Aillustrates three prior art sensors that are relatively widely spaced apart. The thickness of the lines that surround theFIG. 1Asensors are representative of the timing accuracy of the prior art sensors. When the sensors are spaced apart from one another (as shown inFIG. 1A), the epicenter of an earthquake event (which is represented by the intersection of the three sensor circles) can be detected, despite relatively coarse timing accuracy of the sensors. In contrast, when the sensors are located relatively close to one another, as is the case inFIG. 1B, the timing inaccuracy of the sensors obscures the location of the epicenter—i.e. it is not possible to determine the location of the intersection of the three circles surrounding the sensors.

EEWS systems according to particular embodiments of the invention comprise sensors which take advantage of recent sensor developments which provide sensors with noticeably improved timing accuracy. This is shown schematically inFIG. 2, where the timing accuracy of the sensors is much better (corresponding to circular lines having less thickness).FIG. 2Aillustrates three relatively widely spaced apart sensors of the type used in EEWS according to particular embodiments of the invention. LikeFIG. 1Adescribed above, when the sensors are spaced apart from one another (as shown inFIG. 2A), the epicenter of an earthquake event can be detected to be the intersection of the three sensor circles. However, unlike the prior art circumstance, with accurate sensors, the intersection of the sensor circles can still be determined, even when the sensors are located relatively close to one another, as is the case inFIG. 2B.

In particular embodiments, the ability to locate sensors relatively close to one another is exploited to provide new EEWS functionality and performance as described further herein.

FIG. 3is a schematic diagram of a system10for early warning of seismic events according to a particular exemplary embodiment of the invention. System10of theFIG. 3embodiment comprises one or more DAUs16.FIG. 4is a schematic block diagram representation of an exemplary DAU16. Referring toFIG. 4, DAU16may comprise, without limitation, any or all of the illustrated features to help ensure reliable operation in harsh environments.FIG. 5is a diagram of the hardware of a DAU16according to an exemplary embodiment.FIG. 6is a block diagram illustrating the different software modules executed by processor100of DAU16according to an exemplary embodiment of the invention.

System10of theFIG. 3embodiment comprises a number of sensors12. Sensors12may comprise a wide range of proven sensor options to measure or sense a correspondingly wide range of phenomena. Sensors may be used to detect P-waves and S-waves, which signal the presence or absence of a seismic event. For example, the sensor options used for detecting P-wave and S-wave may comprise, without limitation, any or all of:single or multi-axial velocity sensors (or geophones);single or multi-axial acceleration sensors;piezometric patch sensors;MEMS velocity and acceleration sensors;combinations of the above; and/orthe like.

System10may also comprise or be operatively connected to additional sensors13which may be used for controlling and/or monitoring external equipment, building structures and/or other infrastructure (not shown). Such sensors13may, for example, be used to provide information to help control the proper shutdown of equipment, to verify the shutdown of equipment when a seismic event has been detected, to monitor the effect of an earthquake on building structures and/or equipment and quantify the damage that could have been or could possibly be done to such structures and/or equipment and/or the like. The sensor options used for such sensors13may comprise, without limitation, any or all of:strain sensors;temperatures sensors;hall effect sensors for controlling and verifying the shutdown of equipment;visual sensors;acoustic sensors;pressure sensors;flow sensors;humidity sensors;sensors for detecting fluid levels;combinations of the above; and/orthe like.

System10(and the corresponding method of operating system10) provides for early warning of seismic events. System10may comprise one or more of its own sensors12for detecting seismic events such as those listed above. System10may additionally or alternatively be retrofitted to interface with the sensors12of a previously installed system. System10may incorporate software and/or apps (not expressly shown in the drawing) which may operate on any combination of DAUs16(specifically, microprocessor100of DAU16—seeFIG. 4), servers51,52, local devices17and/or user computing devices14. System10(through sensors12and DAUs16) may provide any or all of detection of seismic events (detection of P-waves and/or S-waves), data analysis, determination of event characteristics (e.g. epicenter estimation, magnitude estimation, and/or the like), predictive damage assessment, predictive time to event arrival, damage prevention, early warning, situational alarming, and reliable emergency communication as further explained below.

Referring toFIG. 3, system10comprises one or more DAUs16and one or more sensors12corresponding to each DAU16. In the illustrated embodiment ofFIG. 3, system10comprises a first DAU16, with one or more corresponding sensors12A and a second DAU16B with one or more corresponding sensors12B. DAUs16A,16B and their corresponding sensors12A,12B may be collectively referred to herein as DAUs16and sensors12. Components of system10(e.g. DAUs16, sensors12, devices17and sensors13) can operate locally (i.e. in relatively small environments) and can implement local situational emergency measures (recommendations)18A,18B [collectively, local situational emergency measures (recommendations)18], which are specific to particular locations in which such local situational emergency measures18are implemented and/or to specific conditions in existence at the locations where, and/or times when, such local situational emergency measures18are implemented. Such specific conditions may be based on output from additional sensors13. Local situational emergency measures18may be communicated to and implemented on or via any suitable local device17A,17B (collectively devices17) capable of local communication with DAU16. For example, local situational emergency measures18may be communicated to the embedded controller/processor associated with a piece of industrial equipment, building structure or other infrastructure (device17) and may be implemented by causing the controller/processor to assume emergency control of the operation and/or shut down of the equipment, building structure or other infrastrcture or by causing the controller/processor to display a suitable warning message to the operator of the equipment, building structure or other infrastrcture. As another example, local situational emergency measures18may be communicated to a more general purpose computing device17which may be programmed or otherwise configured to take any suitable emergency measures. Where local devices17have sufficient capability, suitable software operating on local devices17may be used to interrogate specific local conditions and may be used in whole or in part to implement local situational emergency measures18. Device17may comprise other types of devices (e.g. audible alarms, optical warning indicators, PA systems and/or the like.

In particular embodiments, the concept of locality means that each DAU16, its corresponding sensors12, any device17to which corresponding local situational emergency measures18are communicated and/or by which corresponding local situational emergency measures18are implemented and any local sensors13do not depend on network connectivity to other systems or components of system10that are installed at relatively large distances (e.g. 10s and 100s of km) away. Components of system10that are hardwired to one another or which can communicate through a local area network LAN, may be considered to be local, but components requiring larger communication networks, such as the internet15or a cellular communication network are not considered to be local. For example, in some embodiments, the separation of the closest pairs of sensors12A or sensors12B of system10may be less than 100 m. In some embodiments, this separation is less than 50 m, making system10suitable for deployment in residential properties or in small industrial operations.

System10may also operate remotely. For example, DAUs16which detect a seismic event may communicate to remote computing devices14over the internet15or other wide area network and may implement remote situational emergency measures19. Remote computing devices14may comprise any computing device14capable of operating operational software.FIG. 3shows a number of exemplary and non-limiting types of such computing devices14—e.g. desktop computers, laptop computers, tablets, phones, other forms of personal internet devices (PIDs) and/or the like, Remote computing devices14may additionally or alternatively comprise suitable embedded processors which may be provide part of larger systems, equipment, building structures and/or other infrastructure. By way of non-limiting example, remote computing devices14may comprise a processor embedded in a vehicle (e.g. in an automobile or plane), a processor embedded in other equipment (e.g. industrial equipment), a processor associated with the monitoring of a bridge or tunnel and/or the like.

Other than being remote (e.g. separated from DAUs16by the internet15or other wide area network), remote situational emergency measures19may be similar to local situational emergency measures18. That is, remote situational emergency measures19may be specific to the locations where they are implemented and may depend on specific conditions in existence at the locations where and/or times when they are implemented. Such specific conditions may be based on output from additional sensors13. In the illustrated embodiment ofFIG. 3, remote situational emergency measures19are schematically depicted as being communicated to various types of computing devices14which may implement remote situational emergency measures19. This is not necessary, however, and, like local situational emergency measures18, remote situational emergency measures19may be communicated to and/or implemented by any suitable devices capable of communicating with DAUs16over the internet15or other wide area network. Where remote devices14have sufficient capability, suitable software operating on remote devices14may be used to interrogate specific local conditions and may be used in whole or in part to implement, effect or otherwise provide remote situational emergency measures19. For example, a remote device, such as a mobile phone14, may have the ability to detect its current location (e.g. via a GPS receiver). Accordingly, in some embodiments, DAU16and/or alerting server51(described further below) may issue an alert comprising some information about a seismic event and software resident on the phone14may consider the current location of the phone14relative to the seismic event and/or other information specific to the location of the phone14before issuing a situational emergency measure19that depends on the location of the phone14.

FIGS. 4 and 5show different schematic views of the hardware components of a DAU16according to a particular embodiment. DAU16comprises a suitable processor100which may be programmed or otherwise configured to provide the functionality and perform the methods described herein.FIG. 6shows a block diagram illustrating the different software modules which may be executed by processor100of DAU16according to an exemplary embodiment of the invention. Some of the software executed by processor100may be resident on a memory104accessible to processor100. Memory104may also be used to record data received from sensors12. TheFIG. 6software modules are explained in more detail below.

Referring toFIG. 4, processor100of DAU16is connected to receive outputs from sensors12and optionally from additional sensors13directly or through corresponding devices17. DAU16and/or sensors12,13may comprise signal conditioning circuitry (e.g. amplifiers, DACs, buffers, filters and/or the like not shown) which is well known to those skilled in the art. DAU16of the illustrated embodiment comprises a GPS receiver102that is connected to receive signal from GPS satellites20. Such signals received by GPS receiver102may provide location information and timing information. DAU16of the illustrated embodiment comprises a local communication interface106, via which DAU16can communicate local situational emergency measures18to local devices17(or to sensors13associated with local devices17). In some embodiments, local communication interface16may comprise a hard-wired interface between devices17, sensors13and DAU16, although this is not necessary. In some embodiments, local communication interface16comprises a wireless communication interface. DAU16of the illustrated embodiment comprises a remote communication interface108(e.g. an internet communication interface) which may be used to communicate remote situational emergency measures19to devices14via the internet15or other wide area network. Remote communications interface108may comprise a wired and/or wireless communications interface.

In some embodiments, each sensor12is connected to a corresponding single DAU16via hard-wired communications (or also referred to as local connections or local communications). In some embodiments, each sensor12is connected to its own dedicated DAU16via hard-wired communications. In such embodiments, the need for using long running cables to connect the sensors12to a single DAU16may be avoided. This avoids the need to dig ditches in the earth, bore holes through concrete or other structures and the like to fish had-wired cables and reduces the risk of signal degradation in a long cable; resulting in a system which is more reliable and easier to install. Hard-wired connection may be more desirable than wireless connection because hard-wired communications permit data from sensors12to be processed by DAU16relatively quickly (as compared to prior art systems relying on communication of sensor information over communication networks), enabling correspondingly fast response times and damage prevention actions and/or recommendations for local situational emergency measures18, and additional warning time for individuals and organizations that may be impacted by a seismic event.

The ability to synchronize time with high precision between different DAUs16enables installation of multiple DAUs16in close proximity and eliminates the need to connect all sensors12with long wired cables to a central controller. High precision time synchronization may be achieved in DAUs16by using a combination of GPS signal output from GPS receiver102and an optional temperature compensated crystal oscillator (TCXO)110. In particular embodiments, DAUs16may comprise a GPS receiver102(seeFIG. 4), which may be operatively connected to GPS satellites20to obtain precise time information. In situations where satellite communication is not available, DAUs16may be provided with an optional TCXO110which may be used to maintain the time accurately until satellite communication is re-established.

In particular embodiments, parameters and/or characteristics of seismic events (such as, by way of non-limiting example, epicenter of the earthquake, the magnitude of the surface wave (S-wave) associated with the earthquake and the time of arrival of the S-wave) can be determined locally by processor100based on input from sensors12in relation to a detected P-wave or S-wave. DAU16may provide multi-kilohertz sampling capability of the outputs of sensors12and sub-millisecond accuracy of the arrival times of the P-waves and S-waves associated with seismic events. In embodiments where components of system10(e.g. DAU16, sensors12and devices17) are locally connected with each other (e.g., via hard-wired connections or via a LAN), failures of wide(r) area networks (e.g. the internet or cellular communications networks) do not affect the operation of DAUs16and sensors12to provide local damage prevention actions and/or recommendations for local situational emergency measures18to devices17, because each DAU16comprises its own local processing capabilities (processor100—seeFIG. 4).

Local situational emergency measures18may include, without limitation, local sirens, visual warnings/instructions/recommendations displayed on specialized displays, equipment displays, local computing devices and/or the like (together devices17) locally connected via hardwiring or via LAN, automatic assumption of control or shutdown of devices17, instructions issued over a local public address system and/or the like.

The local-wired communications between DAU16, sensors12and devices17which receive local situational emergency measures18also reduce or eliminate the need for high data bandwidth, high reliability and high cost network infrastructure used to interconnect multiple systems or sensors located over large geographic areas. Since each DAU16can act autonomously, data from sensors12can be processed locally. The results of this processed data may be transmitted to other DAUs16(other local DAUs16or distributed DAUs16, via the internet15or some other suitable wide area network) to provide additional early warning time if deemed necessary. This transmission of results between DAUs16may involve the use of minimal bandwidth (since results, rather than raw data can be transmitted) and can be implemented over low cost data communication infrastructure. Transmission of results between DAUs16is not required but may provide additional early warning to locations further away from the epicenter. Local-wired communications also means that sensors12or system10may be placed in remote areas where reliable network connectivity is unavailable or difficult to achieve.

In some embodiments, components within system10(e.g., DAU16, sensors12, additional sensors13and/or devices17) may be connected wirelessly. In such cases, sensors12,13and any wireless transceivers (not shown) may be powered using batteries, solar, wind, geothermal, or energy harvesting from the surrounding environment. If network communications are available, then DAU(s)16can transmit earthquake parameters to user computing devices14and/or other systems (not shown) via the internet15or other suitable wide area network. Such user computing devices14and/or other systems can decide to remotely implement damage prevention actions and/or recommendations for their own local situational emergency measures18, based on the earthquake parameters determined and communicated by DAU16.

In some embodiments, DAUs16may transmit and users may receive alarms, warnings and other forms of remote situational emergency measures19through the internet (or other wide area networks)15via remote devices14; however, these remote situational emergency measures19would be subject to network delays and failures. In some embodiments, DAUs16may transmit determined event parameters or characteristics to user computing devices14and/or other systems (not shown) via the internet15or other suitable wide area network. Such user computing devices14and/or other systems can then decide on their own accord implement damage prevention actions, recommendations and/or other forms of remote situational emergency measures19, based on the earthquake parameters/characteristics determined and communicated by DAU16.

System10may also include a Controller Area Network (CAN) interface21which enables DAU(s)16to connect to vehicles and industrial controllers to obtain situational parameters and execute local situational emergency measures18that may be specific to the location or operating condition of the vehicle or industrial controller.

System10may further include a main server (not shown inFIG. 3) which may be interconnected with DAUs16and/or other prior art EEWS systems to form a large network covering a vast geographic area, although this is not a necessity. In some embodiments, such a main server may be implemented by one of DAUs16. This interconnectivity between multiple DAUs16and/or with prior art EEWS systems, if available, may improve the accuracy of epicenter estimation and/or magnitude prediction. The improved accuracy may be due to data transmitted from a large number of sensors spread throughout a large geographic area. As discussed above in relation toFIGS. 1 and 2, if the sensors are further separated from each other, the accuracy of the epicenter estimation would be less dependent on timing accuracies and geological anomalies related to P-wave and S-wave propagation. Although this interconnectivity is not necessary for implementing the features of early warning, damage prevention actions and/or recommendations for local situational emergency measures18, it may be used for remotely implementing local situational emergency measures18.

System10can be connected to output damage prevention actions (which may be part of local situational emergency measures18) to most types of electrical and/or mechanical devices17and such damage prevention actions may be used to automate shutdown of, or otherwise control the operation of, equipment, building structures, other infrastructure and systems that could be damaged during a disaster and cause more damage to the surrounding infrastructure and/or environment. By way of non-limiting example, tunnels can be closed to prevent additional vehicles from entering, trains can be stopped to prevent derailments, water systems can be shut off to prevent flooding, electricity can be shut off to prevent short circuits and fires, and pipelines can be shut down to prevent environmental damage.

FIG. 7illustrates an exemplary method50for initiating local situational emergency measures18and, optionally, remote situational emergency measures19upon sensing a seismic event. Method50may be performed by processor100of one or more (e.g. each of) DAUs16(seeFIG. 4) in system10. Method50begins in block52, where DAU16monitors the outputs of its associated sensors12. As discussed elsewhere herein, the outputs of sensors12are sensitive to P-waves and S-waves associated with seismic events. Sensors12may be located relatively close to one another—e.g. in a building, in an industrial site and/or the like. Sensors12need not be spaced by tens or hundreds of kilometers. In block53, DAU16analyzes the output signals from its corresponding sensors12to determine if a detected P-wave comprises characteristics indicative of an earthquake. This block53determination may be based on comparing the amplitudes and/or frequencies of one or more sensor signals to corresponding threshold levels. Such threshold levels may be configurable (e.g. user configurable) depending on desired sensitivity. Such threshold levels may be dependent on the particular types of sensors12and signal conditioning circuitry (not shown) which are used in system10. The block53determination is not limited to being based on amplitude and/or frequency thresholds alone and may be made on other characteristics of a detected P-wave which may be indicative of an earthquake.

DAU16continues to monitor sensors12(block52and block53NO branch) until it determines in block53that a detected P-wave is indicative of a seismic event. If DAU16determines that the incoming P-wave comprises characteristics indicative of an earthquake (block53YES branch), alerts (e.g., in the form of an audible, visual and/or electronic alarms, recommendations and/or the like) may be triggered (block54) and local situational emergency measures18may be initiated (block56) and, optionally, remote situational emergency measures19may be initiated in block57. In particular embodiments, high priority and reliable data channels are used to communicate the block54alerts to users and to implement local situational emergency measures18in block56. Remote situational emergency measures19implemented in block57may be similar to local situational emergency measures18, except that DAU16may communicate such remote situational emergency measures19over the internet15or some other wide area network (seeFIG. 3). High priority and reliable communications channels may be secured a priori with network communications service providers. The block54alerts may be effected and the block56,57situational emergency measures18may be initiated as soon as P-waves having characteristics of earthquakes are detected in block52(i.e. before the arrival of the more damaging S-waves).

Local situational emergency measures18that may be initiated in block56may depend on the specific location at which the local situational emergency measures18are implemented. For example, local situational emergency measures18at the collar of an oil well may be different than local situational emergency measures18at the office located some distance away from the collar of the oil well. Local situational emergency measures18that may be initiated in block56may additionally or alternatively depend on specific situations that may be present at a particular time in the location where local situational emergency measures18are implemented. For example, local situational emergency measures18at the collar of an oil well may be different depending on whether or not drilling is active at the time that local situational emergency measures18are implemented. Local situational emergency measures18that may be initiated in block56may additionally or alternatively depend on specific situations determinable from the output of additional sensors13associated with devices17. For example, additional sensors13associated with a drilling rig may detect the presence or absence of workers at some distance up the derrick oil well (e.g. at the racking (monkey) board or at the crown block of the derrick) and local situational emergency measures18may be different depending on whether workers are detected at such above-ground locations. Where local devices17(FIG. 3) have sufficient capability, suitable software operating on local devices17may be used to interrogate specific local conditions (e.g. data from additional sensors13or other available databases) and may be used in whole or in part to implement local situational emergency measures18. Remote situational emergency measures19that may be initiated in block57may be similar to local situational emergency measures18initiated in block56(e.g. they may depend on specific locations, situations, times and/or sensor outputs where they are implemented), except that remote situational emergency measures19may be initiated over the internet15or other wide area network as opposed to locally. Where remote devices14(FIG. 3) have sufficient capability, suitable software operating on remote devices14may be used to interrogate specific local conditions and may be used in whole or in part to implement remote situational emergency measures19.

In addition to effecting the block54alerts and initiating the block56,57situational emergency measures18,19, DAU16is also configured, in block58, to use the detected P-wave to determine or estimate a number of event characteristics (step58). Exemplary event characteristics include earthquake epicenter, earthquake magnitude, predicted earthquake S-wave characteristics and earthquake time of arrival estimations (e.g. at the DAU location or at some other location(s) of interest). For example, an earthquake epicenter location may be determined or estimated by calculating the difference between the arrival times of the P-wave from different sensor locations along with geological P-wave characteristic data and geological data. The magnitude of the earthquake may be determined or estimated based on the epicenter location and the magnitude of the P-wave output signal. Based on the calculated epicenter location and the magnitude of the earthquake, S-wave characteristics and time of arrival at one or more locations of interest may be estimated.

The information determined in block58(which is ascertained prior to the arrival of the damaging S-wave) may be used in providing or updating alerts (block54) and/or situational emergency measures18,19(blocks56,57). For example, the degree of a block54alert may be based on information determined in block58. Similarly, the specific local situational emergency measures18in block56and/or remote situational emergency measures19in block57may be based on event characteristics determined in block58. Block54alerts and block56,57situational emergency measures18,19provided prior to the arrival of the damage causing S-waves may help to mitigate human injury and damage to industrial equipment and/or building structures, loss due to unnecessary shut-down of industrial equipment and/or the like. Block54alerts and block56,57situational emergency measures18,19which are tailored based on block58event characteristics may further mitigate such injury, damage and/or loss.

The illustrative example shown inFIG. 7assumes that an actual seismic event60occurs. In block62, outputs from sensors12associated with DAU16are monitored to detect measured S-wave data and this measured S-wave data may be compared to the block58predicted S-wave characteristics. This optional block62comparison may be used to improve performance of system10, for example, to validate S-wave prediction algorithm(s) or portion(s) thereof that may be used by system10; to further tune S-wave detection algorithm(s) or portion(s) thereof that may be used by system10; and/or the like.

After a seismic event60, method50also comprises performing a post-event check in block62to ascertain the condition of buildings and or equipment of interest. The building and/or equipment of interest evaluated in block62may comprise local equipment comprising or otherwise associated with devices17. The block62evaluation may be based on measured S-wave characteristics and data from additional sensors13A,13B (collectively, sensors13) associated with devices17(e.g. equipment, building structures and/or other infrastructure of interest). Sensors13may, for example, comprise strain sensors, pressure sensors and or the like, which may be associated with the equipment, building structures and/or other infrastructure of interest (e.g. devices17). If seismic event60causes excessive strain or stress on the buildings and/or equipment of interest (block62NO branch), then method proceeds to block64which involves updating alerts (block54) and/or situational emergency measures18,19(blocks56,57) based on the updated information associated with the actual seismic event60. For example, in block56, it may be determined (based on the P-wave and/or based on sensors local to a piece of equipment) that the piece of equipment is suitable for operation, but after the actual earthquake60, it may be determined in block64that the equipment should be shut down to prevent future damage to the equipment, further damage to other equipment or buildings, further risk to individuals and/or the like. Block64may also involve recommending future maintenance decisions for the equipment, building structures and/or other infrastructure of interest and/or future design considerations for the equipment, building structures and/or other infrastructure of interest based on the output of sensors13and/or the measured S-wave characteristics.

After the conclusion of block64and/or on a block62YES branch, method50may return to block52.

In some embodiments, system10comprises one or more alerting server(s)51. Alerting server(s)51may comprise a virtual cloud of one or more server(s). In some embodiments, the functionality of alerting server(s)51is performed by DAU16(specifically, by alerting module151(FIG. 6), which may be performed by processor100). In some embodiments, alerting server51is separate and distinct from DAU16.

Security measures may be implemented to protect alerting server51from unwanted attacks or other malicious use (such as rogue insertion of false positives, or the manipulation of the server51to suppress alerts and/or generate false positives). In particular embodiments, security protections are in place to prevent inbound connections at the network layer from all senders other than those with explicit permission. In some embodiments, DAU16and alerting server51may be communicatively connected via a wired and/or wireless connection. In some embodiments, DAU16and alerting server51may be local to one another. In some embodiments, DAU and alerting server51may be remote from one another. In some embodiments, each DAU16must first be authenticated before any connections between DAU16and alerting server51can be enabled. In some embodiments, each DAU16can be identified by alerting server51via each DAU's current IP address and assigned time-limited authentication key.

FIG. 8schematically depicts an exemplary authentication process200between a DAU16and an alerting server51according to a particular embodiment. Authentication process200may be performed in part by DAU200and in part by alerting server51. Authentication process200of the illustrated embodiment starts in block202where a DAU16that wants to communicate with alerting server51transmits its current IP address to the alerting server51. Upon receipt of the IP address of DAU16, method200proceeds to block204where alerting server51transmits to DAU16an authentication key (hereinafter referred to as a “token”). The block204token may be used as an identifier by each DAU16to identify itself to the alerting server51to thereby authenticate future communications (e.g. in block208) between DAU16and the alerting server51. In block206, alerting server51associates the current IP address and token of the respective DAU16and stores such information in a whitelist database to facilitate such future communications (e.g. in block208). In block208, the whitelisted DAU16and alerting server51communicate with one another as may be suitable in any particular circumstance. As part of block204and/or block208, alerting server51may transmit a number of operational parameters to DAU16. Such parameters may include, without limitation, a Distinguished Name (DN) for the node, any policy configuration parameters for alert transmission, and destination IP addresses to be used when DAU16communicates updates to the alerting server51.

The block204token may include a validity period and expiration date. The token may, for example, be valid for a duration of 15 to 30 days; however, any suitable validity periods may be used. If, the expiry of a token is approaching (e.g. when a threshold amount (e.g. 85%) of the authentication period has expired) and continued communication is desired, then it may be desirable to renew the token (block212YES branch). It may additionally or alternatively be desirable to renew a token (block212YES branch) if the IP address of DAU16has changed (e.g. unexpectedly by the local internet connection service provider and/or the like).

If method200proceeds along the block212YES branch, then method200arrives at block214, where DAU16submits its old token together with its (potentially new) IP address and requests a new token. In block216, alerting server51verifies the old token and the (potentially new) IP address of the requesting DAU16. Block216may involve matching the block214information with the whitelist database. Once the old token and IP address of the requesting DAU16has been verified, alerting server51sends a new token to DAU16as a part of block216. Block216may optionally involve alerting server51sending operational parameters (such as those discussed above for blocks204/208). Block214may optionally involve sending one or more confirmatory communications between the DAU16and alerting server51. Method200then returns to block206, where alerting server51updates the whitelist with information regarding the new token and IP address of DAU16.

In particular embodiments, as part of the block208communications or otherwise, alerting server51transmits to DAU16operational updates (e.g. software updates, situational updates and/or the like) when such updates become available. Updates may be transmitted to DAU16via real-time or queued/batched mechanisms. Different communication links may be used for such update communications, depending on the bandwidth and connectivity of the available network connection. For example, if the available network connection has adequate bandwidth and reliable connectivity, DAU16may have a full-duplex persistent connection to alerting server51. In such case, updates, if available, may be communicated immediately to DAU16as part of block208or otherwise. By contrast, if the available network connection has low bandwidth and poor connectivity, DAU16may not establish persistent connection with alerting server51. In such case, updates may be transmitted to DAU16via a queued/batched mechanism as part of block208or otherwise. Any transmission of updates between alerting server51and DAU16will be interrupted when a seismic event occurs. In some embodiments, DAU16comprises protocols (e.g. software routines) to test any new update to ensure proper and successful installation prior to usage.

Referring toFIG. 3, alerting server(s)51are configured to deliver alerts to any registered users (i.e., individuals who have installed the system10software application on their devices14) and unregistered users (i.e., individuals who do not have the system10application installed on their devices14, but who have third-party application software that is programmatically linked to the system10infrastructure). In some embodiments, such alerts may comprise situational emergency measures19. As discussed above, situational emergency measures19may depend on or otherwise be specific to the locations of devices14where they are implemented and may depend on specific conditions in existence at the locations of devices14where and/or times when they are implemented. Such specific location conditions may be determined based on output from additional sensors13. Where remote devices14have sufficient capability, suitable software operating on remote devices14may be used to interrogate specific local conditions (e.g. from sensors13and/or other accessible databases) and may be used in whole or in part to implement, effect or otherwise provide situational emergency measures19.

The decision as to whether alerting server(s)51may send such alerts to any particular user computing device14may depend on a number of criteria, which may include, without limitation, the current location of the particular device14, the type/size/location or other characteristics of a detected seismic event, and the risk of assessment for immediate danger at the particular location of device14. Alerting servers14may send alerts to particular third parties, who request alerts event in circumstances where their particular device14does not otherwise meet the alert criteria, but another device14and/or location of interest meets the alert criteria. For example, a parent may receive notifications about a seismic event which is a material risk to his/her child's school building. Similarly, a business operator may receive an alert if the building in which his/her business is located is at risk of major damage, even if the business operator isn't present at the location at the time of the event. In some embodiments, the software application may be configured to prioritize the display of situational emergency measures19on such third parties' devices14. Specifically, each software application may be configured to first display guidance in respect of situational emergency measures19relevant to the current location of a device14if a seismic event is relevant at that current location. Alerts (including, possibly, situational emergency measures19) in respect of other locations may be displayed subsequently or upon user request.

In particular embodiments, alerting server51is configured to apply one or more customized alerting policies to different users or groups of users depending on various parameters (e.g. user-configurable parameters). Such parameters may include, without limitation, the user's location (e.g. location of device14), the type/size/location or other characteristics of a detected seismic event, and the risk of assessment for immediate danger at the location of the device14. Such parameters may be configured by operators such as government or private entities. The one or more customized alerting policies (which may include situational emergency measures19) may be preset by different operators, and may operate concurrently. Exemplary customized alerting policies include, without limitation, the following:a government emergency alerting policy where alerts (which may include situational emergency measures19) are provided to anyone within a given geographical region of any seismic event at or above a threshold magnitude; andan alerting policy unique to a particular facility such as a large office building where alerts (which may include situational emergency measures19) are provided to all the workers (or specifically, those who are known to be in the building at the time of the report as reported by the location services on their devices14) if any seismic event is detected to be at or above a threshold magnitude during business hours and/or if the type of seismic event is likely to cause structural damage to the particular building itself.

In particular embodiments, system10further comprises one or more notification servers52. Notification server(s)52may comprise a virtual cloud of one or more server(s). In some embodiments, the functionality of notification server(s)52is performed by DAU16(specifically, by notification module152(FIG. 6), which may be performed by processor100). In some embodiments, notification server52is separate and distinct from DAU16. Alerting server(s)51may be configured to transmit alert(s) (which may include situational emergency measures19) to the one or more notification server(s)52. Notification servers52may be connected to one or more notification channels. Exemplary notification channels include, without limitation, “push notification” for smartphones14or similar PIDs14, live connections to a government-run Emergency Alerting System (EAS) and/or the like. Alerting server(s)51may be configured to transmit alert(s) to the notification server(s)52via an Application Programming Interface (API) which comprises a number of parameters. Such parameters may include, without limitation, the time/date of the seismic event, the calculated magnitude of the seismic event, any uncertainty factors in respect of the accuracy in calculating the magnitude of the seismic event, and the location of the particular sensor12that first detected the event. Notification server(s)52may be configured to receive such alert(s) (which may include situational emergency measures19) and transmit such alert(s) rapidly and directly to the one or more notification channels without applying further analysis or decision logic. In other respects, notification server(s)52and the alert(s) communication by notification server(s)52may be similar to notification servers51and the alert(s) communicated by alerting server51described herein.

As discussed above, alerting server51may be configured to deliver alerts to the devices14of any registered users and unregistered users meeting particular criteria. Alerting server51may also be configured to apply one or more customized alerting policies to different users or groups of users depending on various user-configurable parameters. One of such configurable parameters may be the current location of the user device14. In particular embodiments, alerting server(s)51is configured to respond to requests from the user's device14about specific information related to the user's customized alerting policies prior to a seismic event. For example, if location signal(s) received via the GPS receiver of the user's device14has associated with it a customized alerting policy, the software application installed on the user's device14may download and cache alert data specific to that location of the user's device14.

Downloadable alert data may include for example, infrastructure information and geological data about the area, optimized travel routes to and from the area, and information on the presence of any of the user's family members in the area. In some embodiments, alerting server51may request a particular user's device14to send location signal(s) via the GPS of the user's device14for emergency response or emergency notification purposes. In the event a seismic event occurs, situational emergency measures19(such as, for example, the locations of emergency exits or the recommended locations to find safety inside a building) may be displayed on the user's device14. In some embodiments, any alert situational emergency measures19downloaded onto a user device14is not removed from such device14when the user leaves the particular location. In such case, the cached situational emergency measures19may be retained so that when the alerting server(s)51receives the same location signal from that particular device14in the future, situational emergency measures19may be rapidly made available to the user. The software application executed on device14may compare the cached copies of the situational emergency measures19against the current copies, and replaces the cached copies only if updates have been created.

In some embodiments, the software application installed on the user's device14may additionally include a database of customized alerting policies which may be available to system10. The database may include information such as the geographic boundaries in which particular alert policies apply. The software application running on device14may be configured to compare the device's current location (obtained via the GPS of each device14) with the database to determine whether the user has entered a geographic boundary in which a particular alerting policy applies. In some embodiments, the software application on each device14requests for updates to the database from alerting servers51at configurable time periods. In some embodiments, alerting servers51transmit to the software application on each device14any updates as they become available.

In some embodiments, the software application on each device14does not permit users to perform any administrative changes to the system. In such cases, the software application on each device14is intended to only comprise a display-only capability. In cases which operators wish to configure their own customized alerting policies, a separate software application may be used to allow operators to configure and test their customized alerting policies without delivering actual notifications to end users.

FIG. 9is a flow chart illustrating a method300of implementing situational emergency measures18,19according to a particular embodiment. Method300may be performed by any combination of DAUs16(specifically, microprocessor100of DAU16—seeFIG. 4), servers51,52, local devices17and/or user computing devices14. Method300may be used to perform block56(local situational emergency measures18) and/or block57(remote situational emergency measures19) of method50(FIG. 7). Method300may additionally or alternatively be used when situational emergency measures18,19are updated in block64(FIG. 7). For the purpose of explaining method300, it is assumed that the P-wave associated with a seismic event has been detected (see block53YES branch of method50(FIG. 7)) and that the expected characteristics of the S-wave associated with the seismic event have been predicted (see block58of method50(FIG. 7)). These estimated seismic event characteristics are represented inFIG. 9by estimated earthquake data302.

Method300involves using estimated earthquake data302to determine and implement local situational emergency measures18(in block304) and, optionally, remote situational emergency measures19(in block306). As discussed above, situational emergency measures18,19are specific to particular locations in which such situational emergency measures18,19are implemented and/or to specific conditions in existence at the locations where, and/or times when, such situational emergency measures18,19are implemented. Local situational emergency measures18implemented in block304may be locally implemented—e.g. using a hardwired configuration or a local area network configuration and without having to use the internet15or any other external wide area network. In some embodiments, situational information (e.g. the locations of devices17and/or the specific conditions in existence at the locations where, and/or times when, and/or as measured by associated additional sensors13where, location situational emergency measures are implemented) may be known to device(s)17(at which the situational emergency measures18are implemented), to DAUs16and/or to other local devices17. In such circumstances, some of the procedures of blocks318,320,322and/or324need not be performed for the local situational emergency measures18implemented in block304. In some circumstances or embodiments, this a priori knowledge may not be known and implementing local emergency measures18in block304may involve procedures similar to any of those of blocks318,320,322and/or324described in more detail below.

This a priori knowledge may not (and typically does not) exist in the case of the remote situational emergency measures19implemented in block306of method300. Block306may comprise transmitting the estimated earthquake data302to connected devices14(block308). The block308procedure may involve communicating with remote devices14which are programmed to operate with application software specific to system10(FIG. 3). In addition, in block310, the estimated earthquake data302may optionally be transmitted to remote DAUs16, which may in turn transmit the estimated earthquake data302to their connected devices14(in block312). The block312procedure may be similar to the block308procedure, except for block312may involve different DAUs16and different devices14. Still further, in block314, estimated earthquake data52may optionally be transmitted to one or more other external earthquake early warning system (EEWS) networks, which may then transmit this estimated earthquake information to additional connected devices14(block316). The devices14to which the estimated earthquake data52is sent in block316may comprise devices14that are not running application software specific to system10(although this is not necessary).

At the conclusion of blocks308,312,316, any device14receiving the estimated earthquake data302may become involved in implementing situational emergency measures19that are specific to the location of the particular device and/or to specific conditions in existence at the locations where, and/or times when, and/or as measured by associated additional sensors13where, such situational emergency measures19are implemented. This portion of block306may start in block318, where each device14checks for its location (if available, for example, via GPS receiver that forms part of the device) and, in some circumstances, checks for situational information. Such situational information may include any information related to specific conditions in existence at the locations where, and/or times when, and/or as measured by associated additional sensors13where, block318is performed. Situational information may comprise, for example, information accessible in databases of infrastructure information, customized alerting policies, alert data for various locations, such as infrastructure construction type, construction materials, building foundation type, building design parameters, building age, remote gas and/or electricity shut off locations, commuting patterns, locations where people accumulate (e.g. schools, arenas, etc.), optimized routes to nearby hospitals, information from associated sensors13and/or the like. By way of specific example, device14may comprise a computer associated with a piece of equipment, and the situational information ascertained in block318may comprise an operational state of the equipment, as measured by an associated sensor13. As another example, the location information associated with a device14may determine that the device is inside a particular building and situational information may include a seismic upgrade database that advises that this particular building has undergone recent seismic upgrades. As still another example, the situational information may ascertain that there is no parking on a particular roadway at a particular time and, consequently, it would be unwise to stop a vehicle. It will be appreciated that there are many examples of situational information that could be determined in association with a particular device14.

Method300then proceeds to block320which involves estimating local earthquake information at the location of device14. The block320local earthquake information may be based on device location information determined in block318(if available) and estimated earthquake information52that is transmitted to device14, via one of blocks308,312,316. If the specific location of a particular device is not known in block320(e.g. because a device14does not know or cannot ascertain its location), then block320may assume that device14is relatively close to the epicenter of the seismic event. Method300may then proceed to block322which may involve checking the block320local earthquake characteristic estimates against the block318location and situational information. Then, based on this block322comparison, specific situational emergency measures may be implemented in block324. For example, in some circumstances, the block318situational information may ascertain that a device14is located in a building with a seismic rating up to a particular threshold. The block320local information may determine that the estimated earthquake parameters at the location of device14may be above or below this threshold and the block324situational emergency measures19may depend on the block322comparison of the block320local earthquake estimates to the block318seismic thresholds.

Eventually, the seismic event60occurs. After the occurrence of seismic event60, system10generates actual (i.e. measured) earthquake data326in relation to the actual seismic event60. Method300may then proceed to block328which may implement block64of method50(FIG. 7) and may involve updating alerts and/or situational emergency measures18,19implemented in blocks304,306based on the updated earthquake data326associated with actual seismic event60. Block328may comprise block330which may update local situational emergency measures18and block332which may update remote situational emergency measures19. Blocks330,332may be respectively similar to blocks304,306described herein, except that blocks330,332may use actual earthquake data326in the place of estimated earthquake data302.

System10may be provided with a user-friendly graphical interface (e.g. operating on user computing devices14and/or on devices17and/or on DAUs16) which can be accessed via standard web-browsers from Internet-connected devices14,17and/or DAUs16or via applications on user computing devices14, devices17and/or DAUs16. Applications performed on user computing devices14may also allow for pre-programming emergency contacts that can be reached via device14and/or an associated communication device. Pre-programming of emergency contacts may permit high priority communication with relatives and friends, and emergency response teams through highly reliable data channels, which may be secured through prior agreements with cellular service providers, for example. In some embodiments, an administrator user interface (e.g. operating on one or more user computing devices14) may be provided to adjust various parameters or features of DAU16and/or other aspects of system10.

When operating on a personal internet device (PID)14, such as a mobile telephone or the like, the application software operating on device14may have access to the PID's sensors (which may embody additional sensors13) and/or network information, including, for example, GPS information, IP address and/or the like, which may in turn enable the application software to know the geographical location of PID14. Knowing the geographical location of PID14enables system10to remotely provide the individual associated with PID14with recommendations for remote situational emergency measures19. In addition, the application operating on device14may be able to access databases of infrastructure structural information, infrastructure type, geological information and/or the like to tailor the remote situational emergency measures19to the individual's location.

For example, system10may determine that an individual (and his/her PID14) are located at a particular geographic location and an infrastructure information database may indicate that the particular geographic location is associated with a multi-story brick building. The infrastructure information database may provide an indication that the corresponding building has been upgraded with earthquake proofing technology capable of withstanding earthquakes up to a particular magnitude. In such circumstances, system10may remotely provide user computing device14with remote situational emergency measures19which may depend on the level of the expected earthquake at the particular geographic location. For example, if the expected earthquake at the particular geographic location is less than the building's earthquake-proofness level, then a first remote situational emergency measure19may be recommended, but if the expected earthquake at the particular geographic location is greater than the building's earthquake-proofness level, then a second remote situational emergency measure19(different from the first remote situational emergency measure19) may be recommended. In addition, if the app associated with a particular PID14determines that the sensor data does not warrant an alarm, an all-clear message may be displayed on the device14.

System10can be set up with double or triple redundancy, minimizing the risk of false alarms This redundancy may be provided by having a redundant number of DAUs16and/or a redundant number of sensors12. As a non-limiting example, if two identical systems of DAUs16and sensors12are installed at a given location, the DAUs16can be interconnected such that the block53YES branch (FIG. 7) is only reached when both sensor/DAU systems detect a P-wave. If only one sensor/DAU system detects a P-wave, the event may be treated as a false positive and method50(FIG. 7) may exit block53via the NO branch. This redundancy may significantly improve the reliability of system10. DAU16may use the P-wave detection algorithm and S-wave prediction techniques associated with the ShakeAlarm® seismic detection products manufactured and sold by Weir-Jones Engineering of Vancouver, British Columbia, Canada.

In some embodiments, system10, which is already connected to the internet15and/or other communication networks, may act as a monitor and/or message relay (e.g. through a mobile application on user computing devices14). This creates a very efficient mesh network with multiple channels of communications between parties. Messages can easily be monitored by emergency response teams and services can be prioritized based on real information from the affected zone. The application may be configured to prioritize data based on readings from the local sensors on the device14. Local device14sensors include, for example, GPS sensor and accelerometers. Local device14sensors may be configured to measure the device's proximity to the epicenter. The priority level given to the particular data may depend on the proximity of the device14used to transmit that particular data. For example, if the device's GPS sensor indicates that the device14is very close to the epicenter, the message transmitted from that particular device14may be given a high priority. Another example is that if the signal from the device's accelerometer reads high levels of shaking and motion and that the device's GPS sensor indicates that the device is very close to the epicenter, the message transmitted from that particular device14may be given an even higher priority. To reduce the risk of false alarms, messages may be sent with accompanying information generated by the DAUs16and/or device14sensors. For example, if a user transmits a message which indicates that he/she is trapped under earthquake rubble, but his/her device14sensors indicate that the user is far away from the epicenter, then the message may be tagged as a low priority since it is likely a false alarm.

The application operating on devices14can be pre-programmed with an individual's emergency contact numbers. The device14can then inform the emergency contacts of the individual's condition and/or whereabouts through voice messaging, text messaging, email messaging, internet based instant messaging and/or the like. High priority and reliable data channels can be secured through prior agreements with network communication service providers, resulting in timely and efficient delivery of messages over highly congested networks.

As discussed above,FIG. 6schematically illustrates a non-limiting set of the software modules which are implemented processor100of DAU16according to an exemplary embodiment of the invention. The software modules illustrated inFIG. 6include:data input module154which receives data from sensors12, formats the received data and passes the data to the circular memory buffer156;circular memory buffer156which stores received data and when the buffer becomes full, the oldest data is overwritten;real-time network feed158which transfers the data from circular memory buffer156to other network servers (not shown inFIG. 6) for further analysis if a network connection exists. Real-time network feed158may also receive alerts and events (e.g. remote situational emergency measures19or alerts which may be used to generate such situational emergency measured) from other servers and DAUs16if a network connection exists and may forward this information to other software modules;file writer160which takes data from circular memory buffer156, reformats the data and passes the data to the file format writer162;file format writer162which writes the data received from file writer160to a file on a memory (e.g. memory104(FIG. 4)) that is part of or otherwise accessible to DAU16;analysis module164which analyzes data from circular memory buffer156to determine if an event (P-wave or S-wave event) has occurred and the characteristics of any such event. If an event has occurred, event characteristics generated by analysis module164may be sent to alerting module151, notification module152, local emergency measures module166and reporting module168;reporting module168which handles any reporting and logging functions which ma y be configured for DAU16;local emergency measures module166which may determine local situational emergency measures18(e.g. on the basis of characteristics of events determined by analysis module164and any local situational which may be programmed into, or otherwise available to local emergency measures module166) and/or execute any local emergency measures18that local emergency measures module166may be programmed to implement. As discussed above, such local emergency measures18may comprise a wide variety of actions, such, such as turning on alarms, sending out specific messages to specific staff, turning off certain utilities, and/or the like;notification module152which may communicates event and status notifications through various notification channels, such as “push notifications” for smartphones14or similar PIDs14, live connections to a government-run Emergency Alerting System (EAS) and/or the like;alerting module151which may communicates alerts to other notification servers51, as discussed above;remote access module170which enables secure login of a network computer or server into DAU16for diagnostic and maintenance purposes;configuration module172which performs validation of the system configuration on boot-up;local access module174which receives inputs from local input devices, such as keypads, switches and tap sensors, and makes these inputs know to the other modules;logger176which may comprise a text file logging module that can be invoked by any module to store operational parameters, such as process parameters, times and OS events, in the system log; andhealth monitor178which performs regular diagnostics on the system and reports back on the overall system health.

Although the present system10is described for use in EEWS applications, system10is not limited to EEWS applications. System10can additionally or alternatively be used for any disaster warning applications by using appropriate sensor(s)12and suitable modification of the sensor data analysis algorithms. Such disasters may include, without limitation, tsunamis, tornados, cyclones, hurricanes, and floods. In addition to disaster warning applications, system10can also be used in any application where damage prevention actions and/or recommendations for local and remote situational emergency measures18,19may be of benefit. Such applications include, but are not limited to remote security, pipeline monitoring, marine vehicle monitoring, bridge monitoring, rail monitoring, and mine geology monitoring.

Embodiments of the invention may be implemented using specifically designed hardware, configurable hardware, programmable data processors (e.g. processor100and/or any other processors described herein) configured by the provision of software (which may optionally comprise “firmware”) capable of executing on the data processors, special purpose computers or data processors that are specifically programmed, configured, or constructed to perform one or more steps in a method and/or to provide the functionality as explained in detail herein and/or combinations of two or more of these. Examples of specifically designed hardware are: logic circuits, application-specific integrated circuits (“ASICs”), large scale integrated circuits (“LSIs”), very large scale integrated circuits (“VLSIs”), and the like. Examples of configurable hardware are: one or more programmable logic devices such as programmable array logic (“PALs”), programmable logic arrays (“PLAs”), and field programmable gate arrays (“FPGAs”)). Examples of programmable data processors are: microprocessors, digital signal processors (“DSPs”), embedded processors, graphics processors, math co-processors, general purpose computers, server computers, cloud computers, mainframe computers, computer workstations, and the like. For example, one or more data processors in a control circuit for a device may implement methods and/or provide functionality as described herein by executing software instructions in a program memory accessible to the processors.

While processes or blocks of some methods are presented herein in a given order, alternative examples may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or sub-combinations. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed in parallel, or may be performed at different times. In addition, while elements are at times shown as being performed sequentially, they may instead be performed simultaneously or in different sequences. It is therefore intended that the following claims are interpreted to include all such variations as are within their intended scope.

Software and other modules may reside on servers, workstations, personal computers, tablet computers, image data encoders, image data decoders, PDAs, media players, PIDs and other devices suitable for the purposes described herein. Those skilled in the relevant art will appreciate that aspects of the system can be practiced with other communications, data processing, or computer system configurations, including: internet appliances, hand-held devices (including personal digital assistants (PDAs)), wearable computers, all manner of cellular or mobile phones, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, mini-computers, mainframe computers, and the like.

Specific examples of systems, methods and apparatus have been described herein for purposes of illustration. These are only examples. The technology provided herein can be applied to systems other than the example systems described above. While a number of exemplary aspects and embodiments have been discussed above, those of skill in the art will recognize certain modifications, permutations, additions and sub-combinations thereof. It is therefore intended that the following appended claims and claims hereafter introduced are interpreted to include all such modifications, permutations, additions and sub-combinations as are consistent with the broadest interpretation of the specification as a whole.