A Mentor for Software Process, Business Process Re-engineering, Software Architecture, XML Schema Design, etc.
Archive for the ‘FEMA’ Category.
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
v/r
Mark A. Lucero
Chief, IPAWS Engineering
FEMA National Continuity Programs
What have we done to the Common Alerting Protocol (CAP)? In 2003, CAP 1.0 was released a simple, straightforward XML schema for alerting. It was, and is, a great idea and has achieved almost worldwide acceptance. As with any great idea, folks have discovered a need to tweak here and there and to impose their own rules for usage, security, etc. The great thing is that the basic structure remains in tact. The devil, however, remains in the details of implementation in systems throughout the world. We are on CAP 1.2. Europe has adopted CAP 1.1. Canada has published its own CAP Canadian Profile. We, in the U.S., also have the CAP IPAWS profile as an OASIS TC Committee specification and a requirement for broadcast of messages through FEMA’s Integrated Public Alert and Warning System (IPAWS).
I am currently trying to define a document to help CAP message origination software builders build an appropriate message for use in the world of FEMA’s IPAWS. This world includes both “regular CAP” and IPAWS Profile CAP, including its variations (EAS, NOAA NWEM, and CMAS). It is no small task. There are at least seven different documents that need to be “amalgamated” for the purpose (one of which has not even been formalized in writing yet):
My goal is to provide this document in iterations (think beta versions) to IPAWS-OPEN partners with completed MOAs. It will take some time, but, eventually, a formal version will also be published. Your input will be appreciated.
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.
A note to all of you who have been waiting since January (and before). We have been given authority. There is security paperwork to do, but the process is now in place.
Here are the details about the the IPAWS-OPEN Special Interest Group Meeting to be held at noon Eastern Time on wednesday where I will provide further detail :
Integrated Public Alert and Warning System (IPAWS)
Open Platform for Emergency Networks (OPEN) 2.0 Test Environment
Wednesday October 20, 12:00 Noon Eastern
During our next Webinar, System Architect Gary Ham will provide the latest information about access requirements for the IPAWS-OPEN 2.0 development test environment, including documentation and reporting requirements.
This program is intended primarily for system developers. Please make plans to join us via conference bridge and Live Meeting. As always, your questions and comments are welcome.
IMPORTANT: If you have not logged into Live Meeting before, check out the following connection instructions and participant guidelines prior to next week’s meeting:
http://www.fema.gov/about/programs/disastermanagement/archive/LiveMtgInstruct.pdf
(1) 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
(2) Call into the Conference Bridge number as follows: 1 (800) 366-7242 PIN 3647 6736#.
If you are unable to attend this month’s meeting due to other commitments, a recording will be accessible from the DM Web site.
As those who follow my infrequent updates about the transition from DM-OPEN 1.0 to IPAWS OPEN 2.0 know, IPAWS OPEN 2.0 will require a fairly significant increase in attention to security (even in the test environment). So I decided to dig out my old DM-OPEN “tweeter” test code and begin the process of transition to IPAWS-OPEN 2.0. It no longer works, even against DM-OPEN 1.0. Twitter has also increased its security requirement for applications that post. No more basic authentication. You now must use OAuth. So, in order to tweet from IPAWS, I will now have to use WS-Security with x509 signatures to connect to IPAWS-OPEN and OAuth to connect to Twitter. Ah! Life in the Middle! Nobody trusts the middleman. Nor should they, actually. But it sure is a pain in the rear. :-).
We used to advertise that DM-OPEN 2.0 would be released this summer and that its follow-on would be IPAWS-OPEN 3.0. We have changed our mind (with good reason). OPEN 2.0 will be IPAWS-OPEN 2.0. IPAWS takes full control of OPEN in mid September. Version 2.0 will be fully functional in terms of basic IPAWS architecture and will be used for IPAWS sponsored demonstrations, interoperability events, etc. OPEN version 3.0 will be needed for Cellular Mobile Alerting Services (CMAS), full compatibility with Common Alerting Protocol (CAP) version 1.2, and full compliance with the IPAWS Profile. Still, a lot of basic capabilities required for IPAWS can be done with OPEN 2.0. It can be used for text based Emergency Alert System (EAS) messages, National Weather Service Non-Weather Emergency Messages, and can be a basis for development by vendors of all types that wish to use a non-proprietary system and protocol for the exchange of messages that use Emergency Data Exchange Language Distribution Element (EDXL-DE) and/or CAP. (And do not forget that National Information Exchange Model (NIEM) Information Exchange Packages (IEP) make excellent content objects inside an EDXL-DE.)
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.
Spent April 10-15 in Las Vegas at the Annual National Association of Broadcasters (NAB) annual convention. What a huge event! And what a success for IPAWS! We showed that you can write CAP messages using a variety of input software and they can be auto-delivered by the IPAWS aggregator prototype (DM-OPEN) to an wide variety of Emergency Alert System (EAS) Broadcast devices, radios (to include NOAA weather radios), and specialized software of many kinds. I was even auto-tweeting the headlines of CAP messages retreived from the aggregator. It all works folks. Kudos to the whole team: IPAWS folks, vendors, and broadcasters. We are on our way.
