Working Toward a New ALERT Protocol

Today’s technology offers the possibility of improving Automated Local Evaluation in Real Time (ALERT) without compromising the principles of simplicity, cost, and efficiency upon which it is based. Recognizing this possibility, the National Hydrologic Warning Council (NHWC) formed a subcommittee of users, equipment vendors, maintenance personnel, and software designers in 1999 to study the ALERT data protocol. The protocol subcommittee attempted to quantify the advantages and limitations of the data format, and suggested some possible remedies for its shortcomings. Much of this effort has been refined and published in the ALERT Transmission, and has been presented in NHWC and regional user conferences and discussions. In May 2000 Don Van Wie of Diad, Incorporated and R. Chris Roark of Pacific Systems Consulting performed follow-up work to demonstrate the feasibility of higher data rates for ALERT. Their studies also pointed out that competitive pressures make it difficult for vendors to fund this process and keep it non-proprietary. They suggested that if work on a new ALERT protocol is to continue, the ALERT user community must demonstrate a commitment to the use of the technology if it is developed, and must help to define the form and content of the new protocol around users needs.

Both the NHWC and the National Weather Service (NWS) recognize the importance of ALERT data, and the need to continue efforts to improve ALERT. During the May 2001 NHWC meeting in Columbus, Ohio, the NWS pledged to support the effort by participating in the process to define user requirements, share costs, and incorporate agreed-upon protocol improvements in gages used within the Federally supported Integrated Flood Observing and Warning System program (IFLOWS). The next step will be for the NHWC to issue a Request for Proposals and Statement of Qualifications (RFP). The RFP will ask for technical assistance in assessing user requirements, developing an improved protocol for ALERT and IFLOWS telemetry, and developing a plan for integrating new protocols into existing ALERT and IFLOWS networks. Before the RFP is issued, however, ALERT users need to answer a fundamental question: What are our requirements?. Bob Burnash, considered by many as the founder of ALERT, observed in a Winter 2000 article in the Alert Transmission that changing the ALERT protocol may also move us away from the original premises and intent of ALERT, and could disenfranchise existing users. In effect, Bob has challenged the ALERT community to reaffirm ALERT’s requirements. This challenge is harder than it seems, because we all have a natural tendency to propose solutions, rather than focusing on the requirements themselves. In other words, before we apply today’s technology to fix protocol problems, we need to ask ourselves why the problems we are trying to solve exist in the first place. Only by distilling our needs to why can we expect to receive sound choices on how it can be done.

Fortunately, embedded within The ALERT acronym are words which give us clues to why ALERT exists. Automated, because automation establishes standards for measurement and availability. Local evaluation because the knowledge is needed and processed at the community level. Real time because the information is needed now, not later. These ideas form the core requirements of ALERT. But within each of these core requirements are considerations that are less definitive. Automated traditionally has meant sensor measurements of rainfall, water level, temperature, wind speed and direction, atmospheric pressure, and humidity. Are these the only parameters ALERT should measure? How much range and resolution should each parameter be capable of providing? How often will messages occur? How many messages will occur? How many errors or lost reports are we willing to tolerate? Local evaluation traditionally has meant direct data acquisition and use. Even though ALERT continues to be many small stand-alone systems, each system’s data are increasingly sought by others. How should data be distributed beyond the local system? Who, where, and how many external data users are there? Who is responsible for managing data configurations? How much intelligence do we want to maintain at field sites versus user sites? Real time traditionally has meant as it happens. But, should all data be sent in real time, or should certain types of data have priority over others? Are there instances when periodic data is preferred over event-driven? Do we want data on demand?

Discussions related to these and other questions will help to form a consensus that sharpens the focus of ALERT user requirements. Todd Mendell of the NWS California Nevada River Forecast Center has graciously volunteered to be the focal point for the collection of comments, ideas, and discussions. Please e-mail your comments directly to him at todd.mendell@noaa.gov, or express them in an open forum on the ALERT protocol discussion board at http://message.rainfall.net:8181/~info . A draft proposal and reference material, which includes articles from the Summer 1999, Fall 2000, and Winter 2000 editions of the Alert Transmission will also be posted at www.afws.net/reference. A target date of December 14, 2001 has been established for open comments. After the comments have been provided, a final RFP is targeted for completion by February 1, 2002 A one month comment period will follow, with the anticipated date for award occurring by April 15, 2002.

As Don van Wie and Chris Roark have demonstrated, there are many possible solutions and technologies that can address shortcomings in the existing ALERT protocols. The challenge is to find the best fit for the needs of an extremely diverse community of users. In the upcoming year, the ALERT community must persevere in defining its requirements, and working with whoever is selected to provide assistance. If we do a good job, we will assure ourselves that the next 25 years of ALERT will be as successful as the previous.