Posted: January 19, 2015 in Uncategorized
As IPAWS and the Common Alerting Protocol continue to grow in terms of alert originator adoption, we are still a long way from the promise of a streamlined system that was once promised. In theory the IPAWS OPEN server should act as a message broker between all alert and warning products as well as distribution paths. Many manufacturers has implemented the ability to format and produce a CAP compliant alert message to originate into the IPAWS OPEN server over the last several years. Most of these manufacturers focus on the delivery of short text based messages for the Wireless Emergency Alert (WEA/CMAS) space.
Where the market continues to have a vacuum and the public ultimately continues to lack the alert recipient paths it could benefit from is in terms of unified message origination that focuses on all available distribution paths and the willingness of distribution channel partners to embrace the IPAWS OPEN platform. To provide some perspective to this issue let us look at two of the most commonly relied upon distribution channels for critical warnings; telephone notification services and NOAA Weather Radio. Note that these both have prominent roles in the IPAWS Architecture since its beginning.
Notice that Emergency Telephone Notification Systems are shown as a key design feature of IPAWS integration. In theory, a properly developed warning message delivered into the IPAWS domain includes detailed written and verbal (text and audio) instructions as well as links for more information, short text, etc. Political subdivisions spend great sums of money for the maintenance of these systems to be able to directly reach into someones home by telephone. The only problem? At the time of this writing, there is not a single mass market Emergency Telephone Notification service that offers the ability to automatically deliver telephone based notifications based on an emergency message from IPAWS. While several ETN services give the ability to originate IPAWS messages, they do not have the ability to ingest and deliver those messages.
Similarly and perhaps even more shocking is that the National Weather Service continues to require their own authorization and registration process for the distribution of Non-Weather Emergency Messages. This is important because as Emergency Managers have made the case for many years for business and households to invest in “NOAA All Hazards Radio” most emergency mangers still lack the ability to directly activate those devices when they issue warnings. Those jurisdictions that have signed up for IPAWS need to be aware that a separate registration process is required in order to be able to activate NOAA Weather Radio.
As part of my full-time employment I am currently working on replacing an aging proprietary trunked radio system with a new P25 system. P25 (APCO Project 25) is the modern standard for a communications system that supports an open multi-vendor environment. In the course of speaking with vendors and discussing requirements for interoperability many vendors are shocked to learn my demands for continuing to support “legacy” analog communication paths ranging from VHF Low Band to 800MHz when discussing a modern “interoperable” trunked radio system. The fact is that there is nothing more “interoperable” than analog conventional radio system.
MESIN Interoperability Site
As we are in a time when many regions are spending significant funding to move toward 800MHz P25 system in the name of interoperability, many people forget the basics of meeting such a goal. In my home state of Maryland two employees from the Department of Budget and Management authored a paper many years ago titled “TAC Stack — Or No Band Left Behind” nearly 15 years ago that has all but disappeared from the internet these days. Their concept was quite simple – what if we could use existing nationally designated interoperability channels in each frequency band and bridge them together? What if we could do this on incident, regional and statewide scales?
In the days of significant funding for interoperability from the federal government many such regional projects were developed. In the case of the Maryland Eastern Shore Interoperability Network (MESIN) a system was deployed to provide for portable on street coverage along Maryland’s Eastern Shore bridging available interoperability frequencies on VHF, UHF and 800MHz public safety spectrum. The beauty of such a system is that it considers the question of interoperability at a fundamental level. While many areas built similar interoperability infrastructure they did so generally on only one frequency band, the one used by them and their direct neighbor. Such a deployment however ignores the case for when such systems are needed most – the day that help comes from hundreds of miles away.
Consider for a moment the amount of out of region and out of state support a jurisdiction may require when responding to a large or catastrophic event such as a hurricane, earthquake or major tornado outbreak. When you request support that arrived by EMAC do you know what kind of radios they will be bringing? In a catastrophic scenario do you have enough cache radios to give each responder and the personnel to train them in their operation? The answer to each of these questions, if answered honestly, will be no. With that in mind, take the time and effort to ensure that your radio system design makes use effectively of the national interoperability channels for all frequency bands and is able to support the monitoring and patching of those channels into your system(s). The good news is that analog convention equipment is rather inexpensive and easy to integrate into radio system upgrade projects. The bad news is that if your luck is much like mine, you may find sales staff looking at you like you have three heads when you ask for it.
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.