Grandpa Ham – Grandpa Can do IT!

IPAWS has published the list of current MOA holders. This list is for development and does not indicate that any of them actually have a completed product. It does indicate interest, however, and a willingness to explore connectivity. See: http://www.fema.gov/emergency/ipaws/projects.shtm#3

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

There is a lot of talk lately about CAP compliance (and/or conformance) in alerting products.  At it is there.  It is, in fact, happening but there is compliance and then there is compliance with a wink. For example, IPAWS-OPEN 2.0 itself is only CAP 1.1 compliant and not IPAWS Profile compliant (yet). March is the goal at this point for CAP 1.2 and IPAWS Profile. Typical of any Government Program, we are trying to catch up with ourselves. But at least we are succeeding. (Note: we also have to be completely compliant. Compliance with a wink does not work very well in middleware.)

Also CAP 1.2 Compliance can be defined at many levels. (How many vendor products can actually digitally sign CAP 1.2 messages in accordance with the spec? I know it is optional, but compliance at one level means doing all the mandatory. At another level, it is also being able to do all of the optional.)

How about CAP IPAWS Profile compliance? The profile specifies Message Conformance, Message Producer Conformance and Message Consumer conformance. The rules for each are in the spec. Again is it all or just what is mandatory? (Hint: vendors will need to be able to do a LOT of the optional to be functional for their user base.)

Finally, there is the ability to send and/or receive messages from FEMA’s IPAWS aggregator. You will need to be able to do that. Particularly for CMAS which is scheduled to be operational in 2012 (Testing with the carriers begins very soon.) I can help with the last one. Many companies have signed up to begin development and test. Some have not. Give me a call or send e-mail. I can help.

How can testing begin even without 1.2 in place at IPAWS-OPEN? It can. The functional interface will be virtually unchanged for CAP 1.2 and most CAP 1.2 messages will also validate as CAP 1.1. The only difference is a couple of responseType values and the way the optional digital signature is configured on the message. (So those will not work with us until March. 🙂 )

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):

• The first is the actual CAP Standard; now version 1.2 (OASIS Common Alerting Protocol, Version 1.2, OASIS Standard, 01 July2010).
• This is modified by the CAP IPAWS profile specification (Common Alerting Protocol, v.1.2 USA Integrated Public Alert and Warning System Profile Version 1.0, Committee Specification 01, 13 October 2009).
• For messages bound for Emergency Alert System (EAS) disseminators there is the CAP ECIG recommendation (ECIG Recommendations for a CAP EAS Implementation Guide, EAS CAP Industry Group – ECIG, EAS-CAP Implementation Guide SubCommittee, Version 1.0, 17 May2010).
• For messages bound for broadcast via NOAA Radio, there are additional rules (National Weather Service Instruction 10-1701, Text Product Formats and Codes, February 12, 2003).
• For messages bound for cell phone broadcast there are rules requires to implement the ATIS/TIA Standard (Joint ATIS/TIA CMAS Federal Alert Gateway to CMSP Gateway Interface Specification, October 2009)
• Originators will also need the documentation for connection to IPAWS-OPEN itself (Federal Emergency Management Agency (FEMA), Integrated Public Alert and Warning System (IPAWS) Open Platform for Emergency Networks (IPAWS-OPEN v2) Web-Service Interface Design Guidance Version 1.2, November 12, 2010).  Note: the document is provided to external vendors and programs upon completion of MOA documentation.
• Finally there will be formal rules on originator approval; NWEM and EAS Alert Originator Approval and Permission Procedures for IPAWS COGs (to be published).

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.

I sent out the first 8 sets of credentials to independent interoperable systems this week.  The test environment can now actually be used.  Those of you who are familiar with FEMA procedures know what it took.  Whew!!!!

For those who may not be totally familiar with IPAWS-OPEN, Check my permanent page on IPAWS.

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.