Grandpa Ham – Grandpa Can do IT!

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

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.

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

If you work with the National Information Exchange Model (NIEM) as well as with other standards, you often run into issues related to how your overall work should incorporate (or not incorporate) NIEM. The rules for NIEM allow you to use recognized external standards independently. FEMA’s Integrated Public Alert and Warning System (IPAWS) does this with it implementation of the Common Alerting Protocol (CAP). You can also use components from an external Standard within a NIEM conforming schema, but only if you use the formally defined NIEM “Adapter” approach. You can also use NIEM inside an externally defined standard wrapper as shown in the graphic below.

My talk at the NIEM National Training Event (NTE) in Philadelphia this August will discuss using an OASIS Emergency Data Exchange Language – Distribution Element (EDXL-DE) as a wrapper as shown, but it will go beyond that. It will show how NIEM conforming data structures can be used within the EDXL-DE wrapper itself as DE conforming metadata to describe the content and desired distribution of the Information Exchange Package (IEP). The goal is to show an innovative use of NIEM that is actually made possible by the (also) innovative structure designed into the EDXL-DE standard. The actual content of the IEP will be an IPAW Profile conforming CAP message. The wrapping DE will use NIEM conforming metadata to define IPAWS distribution and content identification needs.

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.

Rick Wimberly’s Emergency Management blog identifies the fact that I stated that IPAWS-OPEN could make international connections. BUT………
U.S. regulations make inter-nation connectivity fairly difficult, if not impossible, unless there are treaties and/or formal diplomatic agreements in place. So, it can work with Canada where we have both agreements in place and a real need for cross-border civilian population alerting. With other nations… not so much. Just a clarification.

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.

The Fiscal Year 2010 “Interoperable Communications Grant Program, Guidance and Application Toolkit” has just been published. My first question on seeing the grant language was, Did they mandate real interoperable data standards for software purchased using grant money?

They did. From Page 20:

Grant-funded systems, developmental activities, or services related to emergency response information sharing should conform as much as possible with the OASIS Emergency Data Exchange Language (EDXL) suite of data messaging standards and National Incident Management System (NIMS) guidelines. Additional information on data messaging standards and their applicability may be found at www.oasis-open.org. The NIMS Supporting Technology Evaluation Program (NIMS STEP) provides objective evaluations of commercial software and hardware products, and reports on product conformity to standards and NIMS guidelines. Findings from evaluations may be accessed through the Responder Knowledge Base (RKB) website to assist grantees in making purchases. More information on the NIMS STEP can be found at https://www.rkb.us/contentdetail.cfm?content_id=219711.

And Again from page 28 under Technology:

National Information Exchange Model (NIEM). FEMA requires all grantees to use the latest NIEM specifications and guidelines regarding the use of Extensible Markup Language (XML) for all grant awards. Further information about the required use of NIEM specifications and guidelines is available at http://www.niem.gov.

NIEM is XML. EDXL is XML. What gives? Who has precedence? Why is EDXL mentioned in the Funding Restrictions section and NIEM in the Administrative Requirements section?

In reality, you can ignore the apparent confusion. The requirements are valid and complimentary. For the most part, EDXL standards are accepted by NIEM as “approved external standards.” So you do not violate the NIEM requirements by using them, provided you use them as-is, in their entirety. If you use use individual elements (or a subset of elements) from an EDXL schema) in a way that does not validate against one of the schema standards, you are actually violating both EDXL and NIEM unless you document the use of those elements using the formal NIEM Information Exchange Package Documentation (IEPD) methodology as defined at niem.gov. So if you want to use a system that uses EDXL-Common Alerting Protocol (CAP), EDXL- Distribution Element (EDXL-DE), EDXL-Resource Messaging (EDXL-RM), and/or EDXL-Hospital Availability (EDXL-HAVE), go ahead. You are within the terms of the grant language. But if you modify (aka “improve”) the standards in any way, you must go through a formal IEPD process.

If, however you have requirements for information exchange that are not met by existing standards, NIEM offers you the opportunity to reuse existing NIEM IEPDs, build a new IEPD from existing NIEM data definition resources, or build an IEPD from a combination of data definition resources. It is a well-defined process that is designed to maximize reuse and minimize redundancy in data structure definitions supporting emergency management dat exchange requirements.

So, to summarize, if the software you are considering for purchase/development with your grant money reuses EDXL Exchange Standards and/or NIEM IEPDs, you are home free. If not, the system needs to define its exchanges with other systems following NIEM IEPD development rules as found at NIEM.gov

The link below is to a blog entry by Rick Wimberly concerning all of the alerting systems shown at the IAEM conference in Orlando this week.

http://www.emergencymgmt.com/emergency-blogs/alerts/The-Best-Notification-System.html

The basic premise is that there is no “best” alerting system and that the best alerting system is system of systems for alerting purposes that each have different traits and capabilities. I AGREE WHOLEHEARTEDLY. In fact, the activity where I currently work, FEMA’s Disaster Management Open Platform for Emergency Networks (DM-OPEN), is designed to allow communication between different alerting systems, such that they work together as a system of systems. At the IAEM conference, 10 different systems were using DM-OPEN to share the alerting function and it worked well because all were using the OASIS Common Alerting Protocol as a basis for exchange.

DM-OPEN also showed the ability of multiple systems to share OASIS Emergency Data Exchange Language Distribution Element (EDXL-DE) wrapped content. This content included NIEM IEPD Content (Amber Alerts) and OASIS Hospital Availability, but could also have included any defined data structure known to parties on at least two ends of the exchange. So, does this make DM-OPEN the best emergency information network? I might want to think so, but my thoughts are actually similar to Rick’s. I believe that no single network solution can legitimately call itself the best. Instead, it takes a constantly improving “network of networks” in combination to provide emergency managers with the best information available. In this arena, DM-OPEN does have a place. Because DM-OPEN connectivity is based on publicly available standards, it can connect network to network, as well as system to system as long as those systems are open to standards-based connectivity. So, DM-OPEN is not THE network or THE system. But if anyone else tells you theirs is THE solution, I would say they are blowing smoke, and that they need to learn to work with others.

Respectfully,
Gary “Grandpa” Ham