As chairman of Alabama’s State Emergency Communications Committee, I thought I might add a comment or two in the debate about whether to allow software-based EAS in the United States.
The Emergency Alerting System was designed to allow broadcasters to serve their listeners and viewers by issuing alerts of impending conditions that could affect life or loss of property.
This includes alerts on a national level that would involve the entire country, such as attacks from outsiders. On the state and local area, alerts that would affect a specific area could include hazmat situations, missing children (Amber Alerts), nuclear reactor problems, etc. Of course, weather alerts from the National Weather Service are extremely important in the event of tornados, hurricanes and severe thunderstorms.
EAS is not designed to be a revenue-generating source for broadcasters but it is a extremely important service to the public.
The current Emergency Alerting System, even with its shortcomings, has served broadcasters and the country quite well. That said, I believe in looking forward; things can always be improved.
Moving to a software- rather than hardware-based operation is not a bad idea. However, a lot of research, development and testing needs to be done so a new software approach doesn’t undermine the purpose of the EAS system. In addition to receiving and relaying required alerts, compliance with the proper operation on the station level is crucial.
As readers are well aware, FCC rules require each station to create and maintain a “station log” that includes the proper operation of their EAS device. Several years ago, the Alabama SECC developed an EAS monitoring service to aid stations in maintaining compliance. This is a free service offered by the committee, but stations are reminded they still must maintain their own station log. If our database indicates a station is missing tests from a source, a courtesy email is sent to the engineer.
Any EAS software must incorporate a way to continually monitor and certify the proper operation of EAS.
Last, supporters of the software approach have cited the successful integration of other embedded functions such as processors and Nielsen’s PPM encoding. But the failure of one of these functions would not affect the life or property of the public, while the failure of EAS software could.
Bottom line, developers should not “rush” to make this happen by a certain date, nor should the FCC. To use a line from the pro audio folks, let’s get it right at the source.
Comment on this or any article. Email [email protected] with “Letter to the Editor” in the subject field.
