Every disaster and every false-warning incident is a learning opportunity. We have done these kinds of assessments after many disasters and false warnings sometimes at great length, as in the case of the 2004 Indian Ocean tsunami, and sometimes simply through a blog post. Our focus has been on naturally occurring hazards, but the recent false warning in Hawai’i was about an incoming ballistic missile. But since it was communicated over the Wireless Emergency Alert system or cell broadcasting, which we have been writing about since 2008 at least.
The New York Times said: “The false alert was a stark reminder of what happens when the old realities of the nuclear age collide with the speed — and the potential for error — inherent in the internet age.”
The report shows that even tourists (who are very present in Hawai’i) received the warning. One does not have to be registered in a database to receive the warning. Your presence within the defined cells is enough, as long as your mobile is capable of receiving the alert. So it’s very clear the system works. The technical problems that everyone will be focused on are the approval of the issuance of the alert (something that the Sahana Common Alert Protocol broker has already built in, as described below) and the delay in the issuance of a cancellation message.
False warnings may result from human error in the technical system for issuing warnings, as it did in Hawai’i, and also in the decision making phase prior to the technical system being activated. It is important to constantly examine the workings of both phases and minimize false warnings, as Nalaka Gunawardene and I said back in 2013: “Too many false alarms and evacuation orders can erode public trust, a vital element in disaster response.”
On the specific problem in Hawai’i, our disaster warning expert Senior Research Fellow Nuwan Waidyanatha said:
In Sahana CAP Broker we have separated the alert-author (editor) from the alert-approver to prevent such. The approval can be done over a mobile from anywhere but needs a data connection (later we’ll add a SMS channel).
CAP also has a msgType = “Cancel” flag. When used, along with other attributes, the accompanying message cancels the previous message. I’m surprised this happened because the IPAWS (FEMA) folks know this feature.
On the WEA side, the current debate is on the handset issues and multiple casting of the same message. Because messages don’t linger in the air for you to receive the message when you enter the zone, the current practice is to recast same message every 5 minutes. There’s no way to determine whether a handset had received the same message to prevent over casting. There’s no common consensus on a message sequencing protocol for apps to distinguish messages. One would think it’s a simple technical numbering thing that can be easily resolved but when you think all-hazard all-media and all-agencies it become complex.
Comments are closed.