CISN label CGS | USGS | Caltech | CalEMA | UCB

NCSS - Functional Requirements and System Implementation






Doug Neuhauser, doug@seismo.berkeley.edu
Lind Gee, lind@seismo.berkeley.edu
DRAFT - 2001/10/15

NCSS Functional Requirements

  1. Automatically detect, locate, and determine parameters for earthquakes of magnitude M >= 2.0 (may vary geographically) within the entire state of CA in near real-time.

    1. Determine the following earthquake parameters:
      1. Location (hypocenter).
      2. Magnitude (multiple types).
      3. Mechanism, moment tensor.
      4. Ground motions.
      5. Faulting parameters.
      6. Other parameters (TBD in future).

    2. Hypocenter and at least one magnitude measure will be determined for all events within the specified region. The determination of other parameters may depend on the location and magnitude of the event.

  2. Produce the following discrete event products: (with estimates of latencies)
    1. Early warning - 3-5 seconds (to be evaluated in the future).
    2. Preliminary location - 30 seconds.
    3. Preliminary magnitude - 30 seconds (currently 2-3 minutes).
    4. Updated location - 2-3 minutes.
    5. Updated magnitude - 3 minutes.
    6. First motion mechanism - 3 minutes.
    7. Moment tensor and mag - 7-10 minutes.
    8. Ground motion values - 30 seconds after S wave
    9. Faulting parameters - 10-40 minutes.
    10. Shake Maps - 3-5 minutes.
    11. Recenteq maps - Series of maps.
    12. Waveform record sections - 5 minutes.
    13. Event waveform for analysis and archive - 30-600 seconds after the end of event trigger.

  3. Produce the following alarms:
    1. Early warning (FUTURE)
    2. Preliminary location and magnitude - 30 seconds after event origin.
    3. Updated location and magnitude - 3 minutes after event origin.
    4. Moment tensor, moment mag - 7-10 minutes after event origin.
    5. Ground motions - event based - ???
    6. Ground motions - threshold based - ???

  4. Produce the following continuous products:
    1. Heli-grams - Virtual helicorders. Produced from waveserver data.
    2. Amplitude maps - for emergency response purposes). Produced from waveserver data. (LOWER PRIORITY)
    3. Spectragrams - for volcano and tremor studies. Produced from waveserver data.
    4. Channel state-of-health - for both human and automated use. (LOWER PRIORITY) (For digital channels only, or analog channels also?)
    5. System state-of-health - for use by own seismic system and other seismic systems.
    6. Continuous waveforms (subset of stations and channels) for archive.

  5. Distribute earthquake notifications and information in near real-time to emergency response managers and public for earthquakes of magnitude M >= 2.0 (may vary geographically) over the region of NC normally, and statewide exceptionally.
    1. Distribution product and formats will be standardized within CA and within the ANSS.
    2. Distribution mechanism must be robust. The system should be designed to ensure that any instance of the real-time system can and should distribute information if cannot determine that the authoritative system is distributing information.
    3. The system should support multiple delivery methods and and multiple paths (where appropriate) for a delivery method.
    4. The system should track what alarms and info has been transmitted to what destination, and when it was transmitted.
    5. The system should be able to revise and/or retract alarms based on the info from the automated system or manual event review.
    6. The system should be able to support specialized region-specific notification criteria for notifications and products (eg, Parkfield, Mammoth, etc).
    7. The system shall support different reporting intervals or update intervals for different products.
    8. The system should be capable of dynamically determining the reporting region based on SOH info sources (eg internal, southern CA system).
    9. The system shall support a unified NCAL distribution list and notification procedures. (CISN issue)
    10. The system shall support a unified statewide distribution list and notification procedures with SCAL. (CISN issue)

  6. Provide facilities for rapid earthquake review.
    1. The system shall provide an analyst with the ability to review an event after the completion of each product.
    2. The system shall be designed to allow product review to be performed from a remote site. The remote site capabilities and requirements may vary from product to product.
    3. The analyst shall be able to perform rapid review of an event within 5-10 minutes of event.
    4. The analyst shall be able to create an event, delete an event, revise an event, re-analyze an event, and reissue or retract alarms for an event. within a single instance of the real-time system.

  7. Provide facilities for analyst review:
    1. The system shall allow the analyst to display, add, delete, and change phase picks,
    2. The system shall allow the analyst to relocate the event, and to produce all of the products created by the real-time system.
    3. The system shall allow the analyst to perform function such as form beams, cross-correlate, etc to aid in the production of the above products. (FUTURE)
    4. The system shall provide facilities for filtering and rotating waveforms to aid in the determination of the above products.
    5. The system shall allow the analyst to incorporate late arriving data in the production of the above products.
    6. The system shall keep all phase observations in the real-time system for a specified period of time. (?)
    7. The system shall allow the analyst to merge events determined by a single instance of the real-time system.
    8. The analyst shall be able to create an event, delete an event, revise an event, re-analyze an event, and reissue or retract alarms for an event.
    9. The system shall provide the analyst with the ability to prioritize event review by criteria such as magnitude or time order of events.
    10. The system shall track the status of all events. The analyst shall be provided with interface to easily prioritize and review events.
    11. The system shall provide the analyst with the ability to merge events that diverge significantly between instances of the real-time systems.
    12. The system shall be designed to allow analyst review to be performed from a remote site. The capabilities and functional requirements of the remote site may vary from product to product. (CISN IMPLICATION - SIMILAR ANALYST TOOLS.)
    13. The system shall allow multiple analysts to work on separate events simultaneously.
    14. Events shall be delivered to the archive by CISN rules.
    15. All events below magnitude ?? may not be reviewed.

  8. Provide parametric data for archive:
    1. The system shall deliver all earthquake parameters and products that are targeted for archiving and distribution by the data center to the data center in a timely fashion (CISN ISSUE - the exact timeframe TBD).
    2. The system shall be capable of delivering multiple versions (or refinements) of the earthquake parameters, which are determined over time, to the data center.
    3. The system shall track the modification history of each event, such as hypocenter (and related parameter) updates, and magnitude (and related parameter) updates. All updates shall include information about who (or what) was responsible for the update.

  9. Provide waveform data for archive:
    1. The system shall provide waveform snippets from selected data channels associated with an event to the archive system. The method of determining the channel selection, time windows, and deliver method to the archive is TBD. (Trinet real-time system pushes event waveform requests to the data center, and data center pulls the data from the appropriate wave server.)
    2. The system shall provide continuous waveforms from selected data channels to the archive system. The method of determining the channel selection and deliver method to the archive is TBD. (Trinet real-time system pushes continuous waveform requests to the data center, and data center pulls the data from the appropriate wave server.)
    3. The system shall provide software to ensure that the instrument responses for data channels in the real-time systems and at the archive are updated in a timely fashion and are consistent.
    4. The system shall maintain a waveform pool of all waveform data received by the system for a period of 7 days (or TBD) to support the real-time system, event review, and data archiving system.
    5. The system shall have to capability to deliver MiniSEED data to the data archive. If the original data is in MiniSEED format, the system must be able to deliver the data in its original data format.

  10. The system shall be reliable and robust. The system should tolerate the failure of any single component and still be able to perform reliable information (although perhaps at a higher magnitude threshold).

  11. The system should be capable of providing more reliable and accurate earthquake parameters over time. (Details of this are TBD).

  12. The system should be capable of handling "late data" (how late?). Late arriving real-time data should NOT cause the system to malfunction. Late arriving real-time waveforms should be incorporated (where appropriate) into an event archive. At a minimum, the system should not discard late waveforms, and late waveforms should be "findable" by the archive system. (Details of this are TBD).

  13. The system should be capable of prioritizing event processing in order to improve the system response time for significant events or for other configurable criteria.

  14. Software reconfiguration should not require a system reboot or complete software restart. As much as possible, software reconfiguration and software restart should cause no data loss within the system or loss of system capabilities.

  15. The system should be capable of associating events from multiple systems, either within the NCAL structure or from external sources.

  16. The system should be capable of recognizing divergence of results between the different redundant components of the NCAL system. The system should be capable of providing notification of these divergences.

NCAL Seismic - System Implementation

  1. Input data.
    1. The system will receive as input all applicable data channels from the NCSN and BDSN networks in real time.
    2. The system will receive as input a subset of the TriNet data channels in real-time.
    3. The system will receive and utilize non-real-time strong motion parameters and waveforms from CDMG and NSMP.
    4. The system will be designed to receive and process data (either continuous waveforms, triggered waveforms, or parametric data) from other networks or stations where appropriate, either as a real-time data feed or as non-real-time data.

  2. Redundancy.
    1. For reliability, the NCSS shall be implemented with multiple (at least two) fully redundant copies of the hardware and software system at different sites. Each site shall have complete system functionality with the following exceptions:
      1. Due to limitations in telemetry systems, each site may not receive waveforms directly from all stations.
      2. Due to possible bandwidth limitation among the redundant systems, each site may not receive all waveforms from the combined NCAL network.
    2. All components of a single NCSS sysstem (with the exception of some initial data collection) will all be located within a site. The system will have at least two sites - one at UCB and one at USGS/MP.
    3. The system will exchange parametric full phase pick data among the sites. (This may require that the current association algorithm be modified to handle duplicate (or near duplicate) phase picks.
    4. All sites shall have the ability to query, request, and retrieve waveforms from either their own wavepools or wavepools of the other sites.

  3. System Software.
    1. Each site within the NCAL Seismic System will use the same software algorithms in order to achieve similar results. We should strive for the same software programs and structure.

  4. Joint administration.
    1. The sites comprising the NCAL Seismic System will be jointly administered by UCB and USGS/MP. Both organizations shall have the ability to monitor, configure and control all sites.

  5. System should have the capability of journaling or archiving the following:
    1. Software configuration.
    2. Software changes.
    3. Hardware configuration.
    4. Site visits/Station information.
    5. State of health
    6. System Operation logs

  6. System components:
    The NCSS shall be implemented with the following functional components. These components may be implemented on a single computer system or on multiple computer systems.

    1. Waveform acquisition:
      The waveform acquisition component is responsible for acquiring data from the seismic stations. For analog stations, it will digitize the analog signals. For digital stations, it will implement the (reliable) telemetry protocol between the stations and the processing system. For exchanged waveform data, it will implement the waveform exchange from the remote system.

    2. Phase detection:
      The phase detection component will perform phase detection on all applicable waveforms received by the system. It will provide the phase detection to the rest of the real-time processing system, and will transmit the phase detections to other redundant system(s).

    3. Real-Time Processing:
      The Real-Time Processing component will perform event detection through one or more methods:
      1. Event association of phases.
      2. Subnet triggers
      3. Other waveform methods (TBD).
      The Real-Time Processing component will produce the event-oriented products of the system (with the possible exception of the event waveform archive set). This component will also be responsible for generating and distributing (or queuing) the real-time notifications. The Real-Time Processing component will communicate with the Real-Time Processing components of the redundant system(s) in order to determine whether it should exceptionally distribute event notifications. The Real-Time component will be integrated with a database to store and retrieve:
      1. event parametric data and automated processing history.
      2. event notification rules and notification history.
      3. system configuration information.

    4. Event Collator:
      The Event Collator component will receive event information from the Real-Time Processing component as well as from the Event Collator from the other redundant system(s). The Event Collator functions are:
      1. Provide rapid event review.
      2. Provide analyst event review and processing.
      3. Perform notification for event changes or deletions.
      4. Perform divergence assessment of events from this system as compared to events from the redundant system(s).
      5. Transmit event information to the network archive.
      The Event Collator component will be integrated with a database to store and retrieve:
      1. event parametric data and selected automated processing history.
      2. event notification rules and notification history.
      3. system configuration information.
      4. non-real-time analyst event processing state information.

    5. NCEDC Archive:
      The NCEDC Archive is responsible for archiving and non-real-time data distribution of event information and waveforms. The event data from the NCAL Seismic System will be pushed to the NCEDC Archive in near-real-time. The NCEDC Archive will acquire both event and continuous waveforms from the NCAL Seismic System by methods TBD. The NCEDC will store:
      1. event parametric data and selected processing history.
      2. non-real-time analyst event processing state information.
      3. event-associated waveforms.
      4. continuous waveforms.
      5. waveform instrument responses.

Valid HTML 4.01!

California Integrated Seismic Network
www@cisn.org

Part of the Advanced National Seismic System

ANSS logo

Last modified: Mon Jul 25 14:18:51 PDT 2011

CGS USGS OES Caltech UC Berkeley