Grandpa Ham – Grandpa Can do IT!

I want to be sure that no one confuses my blogs and Twitter accounts that access the FEMA IPAWS Production Public Alert Feed as official FEMA outlets.  They are not.  I am not paid by FEMA to run them.   I do have an MOA with FEMA to access the production Public Alert Feed.  The blogs are my own separate work.   The posts are run from my non-government, personally owned, computer to a blog host that is also not run by, or contracted to, the U.S. Government.

One other note:   The example blogs are actually subject to downtime due to local power failure ( my UPS lasts about 2 hours).  I have a backup on a thumb drive, so I can restart it from any machine that I can get to with access to the internet. I have a laptop ready.  Not your classic active-active redundant operational capability, but the best I can do as a one man band.   If I were to set one of these blogs up for a customer, it would be up to that customer to determine both retrieval customization and  what level of resiliency they wish to have (and pay for).  All levels are possible.

Example Blogs:
1. All recent Tornado Warnings and Flash Flood Warnings in the U.S can be found at http://weatheralerts.alertblogger.com and/or follow @ipawsweather on Twitter.

2. All recent IPAWS Public Alerts affecting Virginia’s First Congressional District can be found at http://va1stipaws.alertblogger.com and/or follow @VA_1st_IPAWS.

3. All production non-weather IPAWS Public Alerts can be found at http://ipawsnonweather.alertblogger.com and/or follow @ipawsalerts.

I have a new offering for all who do alerting using the Common Alerting Protocol (CAP). I can create a combined blog, tweet and RSS functionality for your alerts as an IPAWS COG, or for any set of IPAWS Public Alerts. The capability works independently and also as an add-on to any IPAWS capable alert origination software. If you have an IPAWS COG, I can make it work without any special integration effort. If you have software that creates CAP alerts, I can build a connection to that software, depending on the interfaces it provides. If you have your own Facebook Page or Twitter Account, I can connect to that. If you have your own WordPress blog, I can use it for the connection. Or I can provide you with whatever you need. I can do it for messages you originate or, if you are an information consumer only, I can support that for any IPAWS Public alert. I can host the connection for you, or you can host and I will help you set up.

Examples:
1. All recent Tornado Warnings and Flash Flood Warnings in the U.S can be found at http://weatheralerts.alertblogger.com and/or follow @ipawsweather on Twitter.

2. All recent IPAWS Public Alerts affecting Virginia’s First Congressional District can be found at http://va1stipaws.alertblogger.com and/or follow @VA_1st_IPAWS.

3. All production non-weather IPAWS Alerts can be found at http://ipawsnonweather.alertblogger.com and/or follow @ipawsalerts.

Please note: This is a grandpaham.com offering and is separate from my support to IPAWS origination vendors. The IPAWS connection tech support is free (as I am paid for it by FEMA) to such vendors. This new capability will be priced according to the complexity of the solution to be provided. It can be inexpensive. Any time spent on customization will necessarily raise the price.

If you need appropriate definitions for NWEM event codes check this link:  http://www.srh.noaa.gov/lub/?n=nonweathercemdescriptions

A recent question from a Commercial Developer:

If I was a public safety or transit organization and wanted to connect to the IPAWS-OPEN for Alert origination and/or dissemination, what administrative (legal, financial, etc.) and technical (information assurance, qualification, etc.) gates would I have to pass?

The answer from the IPAWS Program Office Lead Engineer:

Administrative gates:
1) An MOA is required to connect to our Test Development Lab (TDL) where you can develop interfaces to our system and consume alerts for rebroadcast. The MOA process begins here (http://www.fema.gov/pdf/emergency/ipaws/moa_ipaws_open_app.pdf)
2) Once you have completed your development and have a working system, a separate MOA is required to consume alerts in the Production environment
3) There are no financial obligations by either party

Technical gates:
1) The method you will used to access FEMA systems to consume alerts is through https
2) The MOA contains a rules of behavior that will cover security at a high level
3) The IPAWS Program does not qualify or certify systems but there are a few options for you:
a. First, we have a lab at Indian Head, MD with several alert and warning tools that work with IPAWS. We use this lab to understand the state of the industry for alert and warning. We would welcome you to bring your capability to this lab.
b. Second, the Preparedness Technology Analysis and Coordination Center (P-TAC) performs testing and assessment of emergency management tools. This may be an appropriate avenue for you to have your solution analyzed for suitability for emergency management applications.”

Further Questions? I can help you get started.

I will be explaining the contents of the new IPAWS-OPEN Developer’s Guide tomorrow. It will soon be added to downloads from the FEMA IPAWS-OPEN web site.
details are per the following:

Integrated Public Alert and Warning System (IPAWS) Developer Webinar
Open Platform for Emergency Networks (OPEN)
Introduction to the New IPAWS-OPEN Developer’s Guide
Wednesday January 18, 2012 12:00 Noon Eastern

IPAWS-OPEN enables the interoperable sharing of emergency alerts and incident-related data between systems that comply with non-proprietary information standards, and serves as the alert aggregator for the Integrated Public Alert and Warning System.

During our next Webinar, System Architect Gary Ham will provide an introduction and overview of the new IPAWS-OPEN Developer’s Guide. The purpose of the guide is to help developers successfully write IPAWS-OPEN interoperable code.

This program is intended primarily for third party IPAWS-OPEN developers and testers. 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

If you are unable to attend this month’s program due to other commitments, a recording will be accessible from the FEMA Library.

FEMA has announced its new course for Alerting Authorities. Alert Origination Software developers/vendors may also find the course useful to understand the context of alerting via IPAWS-OPEN to EAS, CMAS, and NOAA Radio. The course is required for alerting authorities as a pre-requisite for getting Alerting Authority for IPAWS push dissemination, but it also provides info for developers as they define requirements for the software they build. Here is the notification that I received:

The FEMA Integrated Public Alert and Warning System (IPAWS) program office has worked with FEMA’s Emergency Management Institute (EMI) and subject matter experts to create a course that provides alert and warning training. This course (IS-247) is now available at no cost on-line. See http://training.fema.gov/EMIWeb/IS/is247.asp

IS-247 provides basic information on the Integrated Public Alert and Warning System (IPAWS). The goal of this course is to provide public safety officials with: increased awareness of the benefits of using IPAWS for effective public warnings; skills to draft more appropriate, effective, and accessible warning messages; and best practices in the effective use of Common Alerting Protocol (CAP) to reach all members of their communities. The course is expected to take 2 hours to complete and includes a final exam.

Regional, State and Local alerting authorities must successfully complete this course prior to being authorized to use IPAWS OPEN to send alerts via EAS, mobile devices, and other communications pathways. Although the course is designed primarily for emergency management, law enforcement, fire services, dispatch, and other public safety personnel, anyone wishing to learn more about IPAWS may take the course.

IPAWS announced its CAP 1.2 Interface last Friday (30 September 2011).

The CAP 1.2 schema from OASIS imposes a pattern on date formats that forces the pattern to be exactly YYYY-MM-DDThh:mm:ss-hh:mm as specified in the CAP 1.2 schema. The last six could also be +hh:mm and represents the offset of the local time in the time string from GMT.

WSDL generated code from the IPAWS-OPEN WSDL may use a standard utility for converting a Java Calendar (or its equivalent in .Net) to a String for its XML writer that is in the form YYYY-MM-DDThh:mm:ss.nnn-hh:mm where the “.nnn” is in milliseconds. This will break the schema. In fact, it resulted in runtime errors in some code I generated from the CAP 1.2 WSDL for IPAWS-OPEN using Java axis2. My solution (credit to Prafash Kumar from Alerting Solutions who gave me his example) was to edit the stub code wherever there was a Calendar to string conversion to substring out the milliseconds from the conversion. There may be a better way, but my solution was successful. Here is a snippet I used in one of those conversion situations:

Original: xmlWriter.writeCharacters(org.apache.axis2.databinding.utils.ConverterUtil.convertToString(localEffective_type0));
Replacement: xmlWriter.writeCharacters(org.apache.axis2.databinding.utils.ConverterUtil.convertToString(localEffective_type0).replaceFirst(“.000”, “”));

I can get away with the “.000” string match because an incoming message to IPAWS-OPEN is also validated for a structure that contains no milliseconds, so the outgoing conversion will be a .000 if it is there at all.

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. 🙂 )