Posted: December 1, 2013 in Uncategorized
I have been working on a few projects lately that involve providing redundant processes, particularly related to communications circuits. What I have been finding with a great deal of regularity is that in almost all cases the technology that has been implemented over the years has replaced technologies that are still practical and effective. In most cases, radio systems for example, low-band VHF radio systems provided noisy coverage that didn’t work from portable radios but was very reliable. These systems were replaced by modern trunked radio systems that are very robust, offer many talkpaths, perform well in buildings but depend on complex IP based infrastructure to function. While the upgrade path to these systems was cost effective and generally makes sense, sending hundreds or thousands of those old radios to a landfill may not be the best idea the first time you have a glitch in the new system.
Each time these issues come up someone always will say – “If only we had kept….”. Let this be the warning to each individual responsible for system lifecycles, always keep the previous generation of your networks in place and operational the greatest extent possible. Having a redundant layer is ALWAYS advisable.
Posted: May 28, 2013 in PublicWarning
Tags: pio, warnings
A post by Jim Garrow on his The Face of the Matter blog got me thinking about a simple lesson that all public safety personnel could learn from the National Weather Service and getting our heads out of our collective silos. Jim speaks about his severe disdain for the term “Shelter-in-Place”, a term likely foreign to 99% of the population prior to its use during the Boston manhunt. Jim makes some very valid points in his post that I will not rehash here as his post is really worth the time to read.
What I do want to hit on here is how the use of plain and honest language should be considered when communicating with the public but most importantly when communicating warning information. A significant deal of research has been applied to the area of warning language by the National Weather Service over the years. For anyone that isn’t familiar with this, you will find that in the last several years warning products have started to use terms like deadly and history of destruction. As the public became complacent about things like tornado warnings, it was critical for the NWS to provide some context to these warnings to differentiate a tornado on the ground that has just leveled towns from a vague tornado signature detected only on radar. As evident from the public response to local storms this is working.
Let’s take this one step further however and go just a bit beyond basic warning messages. People always use historical context when considering how they will respond to basic warnings messages. For example, I live and work in a community that is no stranger to riverine flooding. The community is hard and salty in this regard and very unlikely to evacuate in mass due to a familiarity with the threat. When the big storm comes it is important to provide perspective to them regarding flood depth of historic storms compared to the forecast as well as exactly what they should expect thus allowing them to make an informed decision. Mind you that I do not advocate sensationalism in any form but rather honesty. A great example of this is in the form of language used by one of my favorite NWS personnel during Sandy in his now somewhat infamous personal plea:
What is important here is to realize that Gary provides some degree of historical context, he appeals to emotion as well as logic and above all else he is honest. Think about this the next time that you must craft a warning or recommend a protective action. Do you want to throw out a term that few understand or do you want to show yourself as a person, be honest and potentially save far more lives.
Posted: May 27, 2013 in Uncategorized
Tags: CAP, CMAS, EAS, IPAWS, WEA
I have had many conversations lately with both application developers as well as public safety alert originators regarding IPAWS. In nearly every conversation one misconception shines through. Practitioners and developers alike are considering IPAWS to simply be a tool for launching Wireless Emergency Alerts (formally known as CMAS). While IPAWS certainly does provide the sole point of entry for WEA, it is so much more than that and is very much being undersold.
So, have you hesitated to implement IPAWS because you view it simply as a WEA tool and aren’t sure that you want to implement WEA yet? Here are some reasons to think otherwise:
- IPAWS provides the sole entry path into the National Weather Service’s NOAA Weather Radio for the issuance of Non-Weather Emergency Messages. While practitioners frequently push the value of these radios to the public for weather warnings, participating in IPAWS allows that agency’s emergency messages to also activate these tone alert radios.
- IPAWS provides an internet based path to broadcasters providing a redundant interface into the legacy Emergency Alert System. For some alert originators this connectivity could provide a more reliable and robust means of alerting than current practices however even those areas that have adopted robust and redundant systems such as Communications Laboratories’ EMnet system could benefit from the redundancy.
- The key to IPAWS is that it is a message broker for structured data. Many tools focus on creating messages to send to IPAWS however very few at this point leverage data from IPAWS to activate other warning systems. While nearly no one has has capitalized on this yet, it allows a single activation message to trigger multiple systems. For example a siren manufacturer could implement an encoder that monitors the IPAWS server to activate based on specific event codes within the geographic area of the siren. Similarly a telephone based emergency notification system could deliver an audio message attached to an IPAWS alert to the alert polygon defined within that IPAWS alert.
One thing is for sure about IPAWS, it still has a long way to go in terms of vendors realizing its capabilities and alerting authorities to require full compliance within their Alert & Notification System RFPs. Educating yourself on the full capability of IPAWS is something that both groups must do NOW.
Posted: January 24, 2013 in Uncategorized
Google Public Alerts is nothing new. Google.org has been working on the Public Alerts program for quite some time through this dedicated public alerts map that aggregated data from the USGS and NWS. Over time Google began to incorporate this data into the results for Google searches so that searching for “Tornado” within an area covered by a Tornado Watch or Tornado Warning would provide a link to that warning. This was one step closer to bringing alert information into the main stream.
Google has recently taken another major step with their Public Alerts project by making Public Alerts part of the Google Now application that is included within Android 4.1 and 4.2. With this functionality any phone that supports Google Now can receive notification of Public Alerts in their area. In reality, much like the concept of many commercial applications, this provides a Location Based Service for public warning. The great part is that all is required of an alerting authority is to publish alerts in an acceptable format that contains geospatial information (ideally using the Common Alerting Protocol) and then working with Google.org to allow them to fetch this data. If you didn’t catch the big point here, there is no cost to the agency (or taxpayer).
Here is a little taste of Google Public Alerts
In a follow-up to this post we will look at Google’s Crisis Map.