Grandpa Ham – Grandpa Can do IT!

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.

Funny thing about the national test held on Wednesday 9 November. It was a test of the old stuff; not the new. IPAWS-OPEN and the Common Alerting Protocol (CAP) were not even part of the test. It worked – with glitches – but it worked. The glitches seemed to be mostly about garbled messages and misinterpreted tones; things that the text and Internet-based IPAWS-OPEN solution are designed to prevent. I am confident that the next test, when it happens, will go MUCH better from that standpoint.

The comments about the national test that were most amusing were the ones that connected the National test with an attempt by the federal Government to “take over the airwaves and the Internet.” The internet was not even used. I am not going to comment on whether the Government wants to regulate (or over-regulate) the Internet. That may, or may not be, depending on your personal political perspective. What I can say his that FEMA’s IPAWS program is absolutely not involved in that sort of activity. Input can come from the president, but it can also come from local authorities at all levels of government using alert origination tools provided mostly by private industry. Dissemination is the same. It is primarily voluntary; using a Government provided query architecture that allows local agencies and information providers to weed out unwanted material, making it the very opposite of a Government forced content push. Finally, the “last mile distribution” is almost completely through commercial providers and/or a very wide variety local government controlled software from the commercial sector. So, while IPAWS is designed to provide a way for the president to get an emergency alert to as many people as possible at one time, its architecture is actually built with local alerting and local control at its very core. Check it out for yourself. I will be at the annual International Association of Emergency Managers (IAEM) convention in Las Vegas next week. Drop by the IPAWS booth to say “hi” and to get a live demonstration. Good stuff.

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.

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.

I have been chosen to present a new twist on the reuse of data definitions at the National Information Exchange Model – National Training Event (NIEM NTE) in August. Data definition reuse questions that have been asked before include:
1. Is it OK to Use an External Standard without using NIEM?
2. How do I (or is it allowable to) encapsulate the use of an External Standard inside a NIEM conforming schema?
3. What is the best way to (or should I) bring concepts from external schemas into NIEM (to “NIEMify” them)?
These question have answers, although not everyone agrees on all of them.

My question is different. What if there was a way to reuse NIEM conforming structures inside an external standard? I plan to show an example of how it could work, using NIEM enumerated values (facets, codelists, and schema subsets if necessary) to populate EDXL-DE metadata around an IPAWS Profile CAP message and/or a NIEM IEPD for Amber alerting.

It ought to be an interesting discussion.

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