Home
Earthquake Info
News & Updates
Products & Services
Who We Are
Calendar
Links & Resources
Contact Us
|
Doug Neuhauser, doug@seismo.berkeley.edu
Lind Gee, lind@seismo.berkeley.edu
DRAFT - 2001/10/15
NCSS Functional Requirements
- 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.
- Determine the following earthquake parameters:
- Location (hypocenter).
- Magnitude (multiple types).
- Mechanism, moment tensor.
- Ground motions.
- Faulting parameters.
- Other parameters (TBD in future).
- 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.
- Produce the following discrete event products: (with estimates of latencies)
- Early warning - 3-5 seconds (to be evaluated in the future).
- Preliminary location - 30 seconds.
- Preliminary magnitude - 30 seconds (currently 2-3 minutes).
- Updated location - 2-3 minutes.
- Updated magnitude - 3 minutes.
- First motion mechanism - 3 minutes.
- Moment tensor and mag - 7-10 minutes.
- Ground motion values - 30 seconds after S wave
- Faulting parameters - 10-40 minutes.
- Shake Maps - 3-5 minutes.
- Recenteq maps - Series of maps.
- Waveform record sections - 5 minutes.
- Event waveform for analysis and archive - 30-600 seconds after the end of event trigger.
- Produce the following alarms:
- Early warning (FUTURE)
- Preliminary location and magnitude - 30 seconds after event origin.
- Updated location and magnitude - 3 minutes after event origin.
- Moment tensor, moment mag - 7-10 minutes after event origin.
- Ground motions - event based - ???
- Ground motions - threshold based - ???
- Produce the following continuous products:
- Heli-grams - Virtual helicorders. Produced from waveserver data.
- Amplitude maps - for emergency response purposes). Produced from waveserver data. (LOWER PRIORITY)
- Spectragrams - for volcano and tremor studies. Produced from waveserver data.
- Channel state-of-health - for both human and automated use. (LOWER PRIORITY)
(For digital channels only, or analog channels also?)
- System state-of-health - for use by own seismic system and other seismic systems.
- Continuous waveforms (subset of stations and channels) for archive.
- 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.
- Distribution product and formats will be standardized within
CA and within the ANSS.
- 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.
- The system should support multiple delivery methods and and multiple
paths (where appropriate) for a delivery method.
- The system should track what alarms and info has been transmitted to
what destination, and when it was transmitted.
- The system should be able to revise and/or retract alarms based on
the info from the automated system or manual event review.
- The system should be able to support specialized region-specific
notification criteria for notifications and products (eg, Parkfield, Mammoth,
etc).
- The system shall support different reporting intervals or update intervals for
different products.
- The system should be capable of dynamically determining the reporting
region based on SOH info sources (eg internal, southern CA system).
- The system shall support a unified NCAL distribution list and notification
procedures. (CISN issue)
- The system shall support a unified statewide distribution list and
notification procedures with SCAL. (CISN issue)
- Provide facilities for rapid earthquake review.
- The system shall provide an analyst with the ability to review an
event after the completion of each product.
- 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.
- The analyst shall be able to perform rapid review of an event within 5-10
minutes of event.
- 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.
- Provide facilities for analyst review:
- The system shall allow the analyst to display, add, delete,
and change phase picks,
- The system shall allow the analyst to relocate the event, and to produce
all of the products created by the real-time system.
- 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)
- The system shall provide facilities for filtering and rotating waveforms
to aid in the determination of the above products.
- The system shall allow the analyst to incorporate late arriving data
in the production of the above products.
- The system shall keep all phase observations in the real-time system for
a specified period of time. (?)
- The system shall allow the analyst to merge events determined by a single
instance of the real-time system.
- 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.
- The system shall provide the analyst with the ability to prioritize
event review by criteria such as magnitude or time order of events.
- The system shall track the status of all events. The analyst shall be
provided with interface to easily prioritize and review events.
- The system shall provide the analyst with the ability to merge events
that diverge significantly between instances of the real-time systems.
- 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.)
- The system shall allow multiple analysts to work on separate events simultaneously.
- Events shall be delivered to the archive by CISN rules.
- All events below magnitude ?? may not be reviewed.
- Provide parametric data for archive:
- 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).
- The system shall be capable of delivering multiple versions
(or refinements) of the earthquake parameters, which are determined over
time, to the data center.
- 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.
- Provide waveform data for archive:
- 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.)
- 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.)
- 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.
- 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.
- 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.
- 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).
- The system should be capable of providing more reliable and accurate
earthquake parameters over time. (Details of this are TBD).
- 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).
- 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.
- 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.
- The system should be capable of associating events from multiple
systems, either within the NCAL structure or from external sources.
- 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
- Input data.
- The system will receive as input all applicable data channels
from the NCSN and BDSN networks in real time.
- The system will receive as input a subset of the TriNet data channels
in real-time.
- The system will receive and utilize non-real-time strong motion
parameters and waveforms from CDMG and NSMP.
- 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.
- Redundancy.
- 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:
-
Due to limitations in telemetry systems, each site may
not receive waveforms directly from all stations.
-
Due to possible bandwidth limitation among the redundant systems,
each site may not receive all waveforms from the combined NCAL network.
-
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.
-
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.
-
All sites shall have the ability to query, request, and retrieve
waveforms from either their own wavepools or wavepools of the other sites.
- System Software.
- 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.
- Joint administration.
-
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.
- System should have the capability of journaling or archiving the following:
- Software configuration.
- Software changes.
- Hardware configuration.
- Site visits/Station information.
- State of health
- System Operation logs
- 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.
- 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.
- 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).
- Real-Time Processing:
The Real-Time Processing component will perform event detection through
one or more methods:
- Event association of phases.
- Subnet triggers
- 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:
- event parametric data and automated processing history.
- event notification rules and notification history.
- system configuration information.
- 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:
- Provide rapid event review.
- Provide analyst event review and processing.
- Perform notification for event changes or deletions.
- Perform divergence assessment of events from this system
as compared to events from the redundant system(s).
- Transmit event information to the network archive.
The Event Collator component will be integrated with a database to store and
retrieve:
- event parametric data and selected automated processing history.
- event notification rules and notification history.
- system configuration information.
- non-real-time analyst event processing state information.
- 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:
- event parametric data and selected processing history.
- non-real-time analyst event processing state information.
- event-associated waveforms.
- continuous waveforms.
- waveform instrument responses.
|