1 / 15

Progress Report TIC Working Group E Evolutionary System Architecture

Progress Report TIC Working Group E Evolutionary System Architecture. Walter Arabasz & David Oppenheimer. November 19, 2004. Working Group Members. Walter Arabasz, Chair (Univ. of Utah, NIC & TIC) Glenn Biasi ( Univ of Nevada, Reno & NIC ) Ray Buland (USGS Golden & NEIC)

donagh
Download Presentation

Progress Report TIC Working Group E Evolutionary System Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Progress Report TIC Working Group E Evolutionary System Architecture Walter Arabasz & David Oppenheimer November 19, 2004

  2. Working Group Members... • Walter Arabasz, Chair (Univ. of Utah, NIC & TIC) • Glenn Biasi (Univ of Nevada, Reno & NIC) • Ray Buland (USGS Golden & NEIC) • Art Lerner-Lam (Lamont-Doherty Earth Observatory & IRIS) • Phil Maechling (Univ. of Southern California & SCEC) • Tom Murray (USGS Anchorage & AVO) • David Oppenheimer (USGS Menlo Park, NIC & CISN) • Rick Schult (Air Force Research Lab, Hanscomb AFB) • Tony Shakal (California Geological Survey/Strong-Motion Instrumentation Program & CISN) • Mitch Withers (Univ of Memphis & NIC)

  3. Charge • Define an evolutionary path for transforming existing elements of ANSS into a functional nationwide system—with emphasis on steps that can be taken in the near term (1-3 yrs), based on realistic ANSS funding projections • Clarify key system performance goals [relevant to system design] and characterize “where we are now” • Account for geopolitical realities as well as abstract ideals in designing an ANSS system architecture

  4. Some Key Issues • ANSS not fully funded; OFR02-92 vision unrealistic • Status quo unacceptable — patchwork, not a system • New vision needed with evolutionary steps

  5. Some Guiding Principles • Adoption of guidance from NIST’s Baldrige National Quality Program — a systems approach to Performance Excellence • Desired Outcome — effective system with standardized products; operated with a high degree of professionalism by dedicated well-trained staff • EQ reporting depends on a three-legged stool of (1) sensors, (2) processing, and (3) scientific knowledge; ANSS architecture must explicitly address these elements

  6. Baldrige National Quality Program — 7 Criteria (Assessment,self-improvement and/or Planning tools) • Leadership • Strategic Planning • Customer (and Market) Focus • Measurement, Analysis, and Knowledge • Human Resource Focus • Process Management • Organizational Performance Results

  7. Road Map for Partnership How do we reconcile state/local ownership, investment in, and ongoing support of significant infrastructure for seismic monitoring with the prescriptions of ANSS decision makers?

  8. What we’ve done to date • Clarified key system performance goals • Characterized “where we are now” • Canvassed views on “centralization” • Developed consensus on system architecture • Explored evolutionary steps

  9. Some problems with status quo • Standardization of algorithms lacking • Need for reconciliation of multiple reports of earthquakes • No centralized waveform archiving • No standardized error estimates • Inadequate metadata • Uneven exchange of waveform data between networks

  10. Problems (continued) • No on-site 7X24 response • Limited access to data by research community in RT • Software and system complexity is daunting • Code not “open source” • Duplication of software development • RSN’s located in high seismic areas

  11. Integrated Processing Service WEB EQalert OFR 02-92 Nomenclature Archive IPS Info outlet Data processing Concentrator waveforms products EOC OES FEMA, NOAA… RSNs NEIC WEB Stations EQalert

  12. So, what’s different? • ≥ 7 RPCs • NEIC is • backup • RPCs • exchange • data

  13. Features of anIntegrated Processing Service • Standardized product algorithms • Facilitates more rapid and cost-effective response because of dedicated 7X24 • All products go into a central DBMS • Continuous waveform archive • Distribution of concentrated RT waveforms to R&D groups • Single connection for Earthscope USArray and PBO data streams • All ANSS partners have access to this DBMS • Regional networks backup IPS

  14. WG-E Recommendations • IPS concept • Undertake evolutionary steps • Do an evaluation – is this realistic? how expensive? Identify unproven technologies • Write system specifications for standardized processing • Undertake a pilot project; do no harm • Connect regions • Parallel operation, evaluation, and testing • Distribute standardized software to RSNs

  15. Recommendations continued • Develop ANSS commitment to transparent process for software development • Identify and pursue joint funding of software development to enable USArray/PBO/ANSS waveform integration • Develop a good process for ANSS development (framework, best practices, principles, feedback) based on Baldrige approach • Identify dedicated manager and provide budget (~$300K/yr) for software development

More Related