Grandpa Ham – Grandpa Can do IT!

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.