Tsunami Warning and Preparedness An Assessment of the U.S. Tsunami Program and the Nation's Preparedness Efforts (2011) / Chapter Skim
Currently Skimming:
5 Long-Term Reliability and Sustainability of Warning Center Operations
5 Long-Term Reliability and Sustainability of Warning Center Operations
Pages 163-192
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 163... ...
In addition, as discussed in detail in Chapter 3, inconsistencies in warning products issued by the two TWCs and the current division of AOR results in messages that have caused confusion and the potential to cause confusion in the future, making the products less effective in eliciting the appropriate response. The committee recommends that the National Oceanic and Atmospheric Administration's (NOAA's)
|
From page 164... ...
As detailed in the chapter, some of the steps to improve long-term operations recommended by the committee include the following: • NOAA/NWS should undertake a comprehensive, enterprise-wide, long-range planning effort for the TWCs. The goal of the planning effort would be to analyze TWC func tions and requirements; articulate the technological, human, physical, and intellectual infrastructure required to meet the TWC requirements; and integrate the technology, applications, tools, processes, networks, leadership, policies, organizational structures, and human capital required to provide long-term reliable and sustainable global TWC operations.
|
From page 165... ...
• If NOAA/NWS maintains the current organizational structure, then it should harmonize and standardize technologies, processes, and products between the two TWCs. • NOAA/NWS and the TWCs should undertake ongoing, joint, or NOAA-wide bench marking and continuous process improvement activities for their functional, techno logical, organizational, or human capital initiatives; report those activities internally and externally; and incentivize excellent performance as well as best practices.
|
From page 166... ...
occasioned by the 1960 Pacific-wide tsunami generated in Chile) • Indian Ocean countries (as an interim center for the Indian Ocean Tsunami Warning and Mitigation System [IOTWS]
|
From page 167... ...
. FIGURE 5.2 Key operational components of the tsunami warning centers.
|
From page 168... ...
Critical needs for this component include frequent and varied training for operational watchstanders (e.g., simulations, walk throughs, case studies, table-top exercises) ; organizationally sup ported interactions between watchstanders in the two warning centers; and ongoing and prioritized research and development to support operations and implement new technology.
|
From page 169... ...
Once sea level data are acquired, watchstanders reassess the threat, including scaling earlier, computed tsunami forecast scenarios to fit the sea level observations from the Deep-ocean Assessment and Reporting of Tsunamis (DART) systems; if needed (e.g., if sea level data are lacking)
|
From page 170... ...
workstations running Microsoft Windows and all seismic, sea level, geographic information system (GIS) , forecasting, and product-generation software run on a network of 10 operational PCs with complete hardware and communications redundancy.
|
From page 171... ...
The center disseminates the results of its analysis immediately to the public and to the user-community, including emergency response agencies. TABLE 5.1 Comparison of Tsunami Warning Center Technology and Management Products and Processes Technology Product, West Coast/Alaska Pacific Process Tsunami Warning Center Tsunami Warning Center Hardware Platforms Hardware Platforms 10 PC workstations and 7 Sun workstations servers with hardware and 2 PC workstations from PMEL to run communications redundancy SIFT Software Platforms Operating System Windows XP for EarlyBird SUN Solaris and Linux Applications • Seismic processing, Data acquisition: Earthworm and Data acquisition: Earthworm, Nanometrics for WC/ATWC network EdgeCWB, and Antelope for PTWC analysis data network data Data processing: standard Data processing: for non-Hawaii Earthworm architecture with events, standard Earthworm specialized tsunami analysis architecture with local developed modules known as EarlyBird user interfaces and some use of EarlyBird modules.
|
From page 172... ...
and developing with ESRI and Google Maps • Messaging software Written internally Aging -- software support difficult Watchstander previews are not supported Coded in C Coded in FORTRAN • Geographic EarthVu information system • Tsunami forecasting Use Alaska Tsunami Forecast Model (ATFM) through EarthVu GIS interface Use PMEL's SIFT server software and hardware systems Precomputed model database Developing forecast system capable WC/ATWC developing ATFM of producing international forecasts version 2, an upgrade to ATFM known as real-time inundation forecasting of tsunamis Will use ATFM version 2 once available • Product formats Standard NWS, HTML, RSS, CAP/ Standard NWS, RSS, CAP/XML, SMS XML, SMS • Configuration Subversion Configuration GIT Management System management tools Configuration Management Plan (CMP)
|
From page 173... ...
System Procurement Informal Processes Dated Inadequately budgeted System Maintenance Regularly performed Informal processes System Configuration No formal processes described No formal processes described Management Updates difficult IT support staff performing updates and installing changes impacted by unstable and aging software. Organizational Not observed Learning Processes, Process Improvements, Incorporation of Lessons Learned, Dissemination of Best Practices continued
|
From page 174... ...
also reported monthly Adherence to/ Not apparent Compliance with Software risks mitigated by use of legacy personnel performing timely International Process, repairs Product Standards SOURCE: Committee member.
|
From page 175... ...
the use of international hardware, software planning, development, operations, and maintenance product and process standards, including the Software Engineering Institute's Capability Maturity Model and the software development life cycle (Carnegie Mellon Software Engineering Institute, 2010)
|
From page 176... ...
As previously discussed, issuing messages with potentially conflicting or confusing content -- as would be the result from issuing a warning for Puerto Rico and an information statement for the remaining Caribbean Sea -- is counter to the science of effective warning messaging. Thus, harmonizing threshold criteria to yield consistent warning products for regions in close proximity would reduce a potential source of confusion.
|
From page 177... ...
or C programming languages, so the watchstander needs to recompile and regenerate the message if an error is detected. This inability to preview and edit a warning product has the potential to introduce delays in the initial warning phase, and the reliance on dated software technology deters easy interfacing with current network and mobile data structures.
|
From page 178... ...
have not been applied. In addition, the generation of two sets of warning products from the two TWCs can be a major source of confusion among the emergency management community and the public as illustrated by the June 14 case study (Appendix F)
|
From page 179... ...
Despite improvements after the June 14 event, there are still inconsistencies in warning products from the two TWCs; and the current division of AORs results in messages that do not clearly communicate who needs to take protective actions and who does not. Recommendation: NOAA/NWS should harmonize and standardize checklists, tsunami warning products, and decision support tools, and standard TWC software tools and applications should be used in the TWCs, following current software engineering practices and taking advantage of current programming language best practices.
|
From page 180... ...
Additionally, plan requirements were developed without consultation of TWC users, emergency managers, academia, the public, or other tsunami program stakeholders. The current software suites are tightly linked to their hardware platforms; migration to platform-independent architectures could offer the benefit of reduced system maintenance requirements and could enhance information sharing among the TWCs, universities, watchstanders, and the real-time software development community.
|
From page 181... ...
Conclusion: Despite the importance of technology to fulfilling the TWC mission, technology development, deployment, support, maintenance, back-up, recovery, and configuration management are collateral duties for most TWC staff members. Neither management nor staff members at the TWCs have formal training in technology, software engineering, design, maintenance, or IT support, yet almost all staff members have significant technology responsibilities.
|
From page 182... ...
Specifically, the committee recommends the following improvements: Senior IT leadership to guide the organization and ensure that the TWC technology archi tecture supports TWC operational requirements for reliability and sustainability; • A common set of functional, operational and organizational processes, including o Articulated technology development, procurement, deployment, maintenance, sup port, security, and configuration management processes; o Planning processes that are compliant with software engineering and computer science standard processes and lessons learned from other large-scale, mission critical systems, and which are effectively carried out by TWC IT management and staff personnel, IT support personnel, in regular consultation with TWC customers and emergency management personnel; o An enterprise-wide IT requirements development process that transparently identi fies all TWC requirements with a single planning process and a single enterprise wide IT architecture; and o IT development, deployment, maintenance, support, quality assurance, security, and configuration management processes that are adequately planned and budgeted,
|
From page 183... ...
Recommendation: NOAA/NWS and the TWCs should adopt national, and where applicable, international, standards, best practices, and lessons learned for all functions, technology, processes, and products. Specifically, the TWCs should develop platformindependent hardware and software architectures, applications, and interfaces; and employ international hardware and software planning, development, operations, and maintenance product and process standards, including the Software Engineering Institute's Capability Maturity Model and the software development life cycle (Carnegie Mellon Software Engineering Institute, 2010)
|
From page 184... ...
Each watchstander is responsible for checking all workstations every four hours to ensure functionality. Unless they need to respond to an event, watchstanders spend approximately six hours on software development and two for operational activities (Paul Whitmore, West Coast and Alaska Tsunami Warning Center, personal communication)
|
From page 185... ...
; frequent, regular, and organizationally supported interactions between watchstanders in distributed watch centers; and ongoing, funded, and prioritized research and development to support operations, which requires an explicit process for implementing new technology into operations. Recommendation: Because of the importance of technical and scientific expertise to the TWCs' functions, TWC human capital requirements and TWC recruiting, training, re training, development, mentoring, and professional exchange needs should be included, re-assessed, and updated as part of the NOAA/NWS enterprise-wide technology planning effort, and should be consistent with NOAA- and government-wide standards, so that
|
From page 186... ...
Such interactions might include drafting and implementing a formal plan for maintaining and increasing scientific currency; attendance at professional conferences; participation in seminars, workshops, or other structured learning opportunities; scientific and personnel exchanges and sabbaticals; study away opportunities at related scientific venues; and grants, fellowships, and stipends to further professional study. ORGANIZATIONAL STRUCTURES Tsunami detection and warning is currently undertaken by multiple, distributed members linked together to achieve a goal: management of and response to a tsunami disaster.
|
From page 187... ...
• The current geographic separation in the AOR is not intuitive and can result in difficul ties with regard to interpreting who is under a tsunami warning or not. • The current physical settings and the organizational structure within the NWS pro vides minimal integration with the tsunami and earthquake research community or other operational forecast and warning centers within NOAA (e.g., all other centers are managed by NCEP)
|
From page 188... ...
Conclusion: The current organizational model is problematic and reduces the ability of the TWCs to provide timely, accurate, and consistent warning products. The committee concludes that significant changes would need to occur in the management, operations, software and hardware architecture, and organizational culture for the two T WCs to become functionally redundant systems.
|
From page 189... ...
Recommendation: Organizational structures for the two TWCs should be evaluated and fully described as part of the enterprise-wise technology planning effort previously described. Whether there should be a single or multiple TWCs, or whether the TWC operations should be consolidated in a different location, should be addressed in the enterprise-wide, long-range planning effort.
|
From page 190... ...
Conclusion: An organizational culture change is needed within the NOAA/NWS Tsunami Program that supports and celebrates operational excellence; adopts national and international standards, processes, best practices, and lessons learned for all functions, technologies, processes, and products; and engages in ongoing, continuous process improvements. Conclusion: The committee found that the TWCs do not sufficiently engage in ongoing, joint or agency-wide, continuous process improvement activities for their functional, 0
|
From page 191... ...
Recommendation: NOAA/NWS and the TWCs should undertake ongoing, joint or NOAAwide, continuous process improvement activities for their functional, technological, organizational, and human capital initiatives, including the following: • eveloping measures of performance and benchmarking individual, organizational, and d technical performance against industry and agency metrics, • dentifying areas for improvement, i • etting short- and long-term performance goals, s • eveloping reward and incentive systems for such goals, and d • elebrating TWC and agency accomplishments as performance improves, in order to c raise the level of TWC performance to that expected of a high-reliability organization.
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.