Giving a talk on the ways to use CAP using the new IPAWS CAP 1.2 interface at noon tomorrow (15 Feb 2012). Details:
Integrated Public Alert and Warning System (IPAWS) Joint Developer/Practitioner Webinar
Using the Open Platform for Emergency Networks (OPEN) for Public and Private Alerting
Wednesday February 15, 2012 12:00 Noon Eastern
In addition to its role as message aggregator for public alerting, IPAWS-OPEN enables the interoperable sharing of emergency alerts and incident-related data between incident management systems that comply with non-proprietary information standards.
During our next Webinar, System Architect Gary Ham will describe how IPAWS-OPEN provides support for exchanging alerts within a single response organization, between one or more response organizations, with all response organizations, and/or with the public. He will also explain how the Common Alerting Protocol (CAP) scope element is implemented by IPAWS-OPEN for public and private alerting.
This program is intended primarily for IPAWS-OPEN developers and testers; however, emergency management practitioners who are interested in learning more about IPAWS incident management-related capabilities are also encouraged to participate. Please make plans to join us via Live Meeting. As always, your questions and comments are welcome.
IMPORTANT: The audio portion of the program will be delivered via your computer speakers. The Live Meeting client must be used in order to receive the audio. Please review the instructions available from: http://www.fema.gov/pdf/emergency/ipaws/livemtginstruct.pdf prior to the program.
Login to MS Live Meeting for visuals: The following login link can only be used 30 minutes prior to the scheduled meeting time: https://www.livemeeting.com/cc/eiip/join?id=DMprogram&role=attend
Funny thing about the national test held on Wednesday 9 November. It was a test of the old stuff; not the new. IPAWS-OPEN and the Common Alerting Protocol (CAP) were not even part of the test. It worked – with glitches – but it worked. The glitches seemed to be mostly about garbled messages and misinterpreted tones; things that the text and Internet-based IPAWS-OPEN solution are designed to prevent. I am confident that the next test, when it happens, will go MUCH better from that standpoint.
The comments about the national test that were most amusing were the ones that connected the National test with an attempt by the federal Government to “take over the airwaves and the Internet.” The internet was not even used. I am not going to comment on whether the Government wants to regulate (or over-regulate) the Internet. That may, or may not be, depending on your personal political perspective. What I can say his that FEMA’s IPAWS program is absolutely not involved in that sort of activity. Input can come from the president, but it can also come from local authorities at all levels of government using alert origination tools provided mostly by private industry. Dissemination is the same. It is primarily voluntary; using a Government provided query architecture that allows local agencies and information providers to weed out unwanted material, making it the very opposite of a Government forced content push. Finally, the “last mile distribution” is almost completely through commercial providers and/or a very wide variety local government controlled software from the commercial sector. So, while IPAWS is designed to provide a way for the president to get an emergency alert to as many people as possible at one time, its architecture is actually built with local alerting and local control at its very core. Check it out for yourself. I will be at the annual International Association of Emergency Managers (IAEM) convention in Las Vegas next week. Drop by the IPAWS booth to say “hi” and to get a live demonstration. Good stuff.
The real blessing of standards is that they can make interoperability between lots of different systems possible. IPAWS-OPEN uses EDXL-CAP, and EDXL-DE in a standard SOAP Web Services environment with WS-Security. So far we have developers who have proven their interoperability using .NET, Java (Axis2 with Rampart), Java (Spring Framework), Ruby On Rails, and, as of yesterday, PHP. So, they will all be able to share vital alerting information with each other, and with the public via EAS, CMAS, and NOAA Radio. It is not easy, but it is coming together.
Still looking for the C, C++, and/or Objective C client application. 🙂
I have been chosen to present a new twist on the reuse of data definitions at the National Information Exchange Model – National Training Event (NIEM NTE) in August. Data definition reuse questions that have been asked before include:
1. Is it OK to Use an External Standard without using NIEM?
2. How do I (or is it allowable to) encapsulate the use of an External Standard inside a NIEM conforming schema?
3. What is the best way to (or should I) bring concepts from external schemas into NIEM (to “NIEMify” them)?
These question have answers, although not everyone agrees on all of them.
My question is different. What if there was a way to reuse NIEM conforming structures inside an external standard? I plan to show an example of how it could work, using NIEM enumerated values (facets, codelists, and schema subsets if necessary) to populate EDXL-DE metadata around an IPAWS Profile CAP message and/or a NIEM IEPD for Amber alerting.
It ought to be an interesting discussion.
The new guidance is out. It includes Emergency Data Exchange Language (EDXL) Standards including the Common Alerting Protocol (CAP). This may be an option for agencies trying to buy an IPAWS connected alert origination tool. In order to actually connect to IPAWS, the tool must conform to CAP and the IPAWS profile of CAP in particular. See Section 5.3 on page 30 of the following document. Happy hunting!
Text of E-Mail released today:
The primary mission of FEMA’s Integrated Public Alerts and Warning System (IPAWS) program is to provide integrated services and capabilities to local, state, and federal authorities that enable them to alert and warn their respective communities via multiple communications methods. The federal mandate is to develop, deploy, and maintain the infrastructure for aggregating emergency messages originated by federal, state, local, and tribal officials and routing them to public dissemination systems including the Emergency Alert System (EAS), the Commercial Mobile Alert System (CMAS), and others. FEMA is committed to achieving this mission.
The IPAWS Open Platform for Emergency Networks (IPAWS-OPEN) will serve not only as the IPAWS Aggregator for Common Alerting Protocol (CAP) emergency messages, but also enable the interoperable exchange of other standards-compliant messaging between commercial systems. Currently, over 40 private sector companies are in various stages of developing and testing interoperable software applications compatible with IPAWS-OPEN. Many of these applications are expected to come to market over the next several months and further information about these products will be available from the Responder Knowledge Base (RKB) Website. In addition, FEMA is investigating a viable solution for an Open Source CAP authoring tool and will provide updates via the IPAWS Website.
IPAWS-OPEN will supersede the existing DM-OPEN which is scheduled for decommissioning on June 30, 2011. Concurrently, the Disaster Management Interoperability Services (DMIS) Toolset system will also be retired. All software currently connecting to the legacy DM-OPEN application must be migrated to IPAWS-OPEN 2.0 by June 30, 2011. After that time, legacy DM-OPEN will no longer be available and IPAWS-OPEN 2.0 must be utilized.
In order to focus more fully on its primary mission and make the most effective use of its resources, the IPAWS Program Office has recently completed a re-evaluation of its priorities. As a result, the decision has been made to cancel the release of the Framework incident management support tools originally planned to replace the DMIS Tools. A number of Web-based incident management systems are now widely available and emergency management practitioners are encouraged to assess their requirements and apply for grant funding assistance to meet their needs. For further information see the Interoperable Emergency Communications Grant Program (IECGP) or the Homeland Security Grant Program (HSGP).
We regret any inconvenience resulting from this decision. In the long-term, FEMA believes this is in the best interest of the public safety. For further information, please contact Mark Lucero at FEMA-DMIS@DHS.GOV
Mark A. Lucero
Chief, IPAWS Engineering
FEMA National Continuity Programs
It has finally happened. The process for getting access to the IPAWS-OPEN 2.0 Test capability is in place. You must fill out a request questionnaire first. This questionnaire will soon be available on the FEMA IPAWS web site. Until it is available, makers/developer/program managers of emergency management software and Alert dissemination systems can send email to “open AT eyestreet.com” requesting the questionnaire. We will use that information to construct a Memorandum of Agreement that you will sign and return to me. I will obtain a valid Government signature and return the MOA to you along with a programmers Manual, valid system endpoint for the IPAWS 2.0 web services, and an x509 signature to be used in accessing those end points. Please be patient. There is some pent-up demand and it will take a while before everyone is taken care of. We will be giving priority to current OPEN operational systems and to EAS dissemination systems that need to help broadcasters meet the infamous “180 day clock.” But we will get to you.
Marck Lucero (FEMA) and I made a presentation to attendees at the World Conference on Disaster Management in Toronto in June about how IPAWS will be able to play in cross-border alerting and how we can use IPAWS-OPEN to connect to Canadian alerting infrastructure in a way that allows resilient connectivity between local authorities on both sides of the border. It is a 17 minute presentation in Quick Time format.