Archive for the ‘CMAS’ Category.

Wireless Emergency Alerts (WEA) as a Disaster Recovery Tip

WEA is alive and operational in a big way. The big carriers are fully up and running, as are many of the smaller ones. Currently working with some folks in Puerto Rico. Just finished with some folks serving Mississippi. Both will be ready for hurricanes this summer.

I also saw a nice description of WEA as a Disaster Recovery Tip on the Agility Recovery Web site. Check out:

http://blog.agilityrecovery.com/bid/96992/Disaster-Recovery-Tip-23-What-you-never-knew-you-had

Non Weather Emergency Message (NWEM) Event Code Definitions

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

What Gates are Involved in Developing Applications that use IPAWS?

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.

Webinar on CAP Use Cases from an IPAWS Perspective

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

Presenting the IPAWS-OPEN Developer’s Guide

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.

IPAWS Alerting Course for Alerting Authorities Now Available

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.

Upcoming NIEM NTE Presentation – Using NIEM Metadata in an EDXL-DE wrapper to Support IPAWS

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. NIEM_In_Wrapper_Graphic-300x175

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.

FY2011 SAFECOM Guidance on Emergency Communications Grants

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!

IPAWS-OPEN Live Demonstration (XML Geeks only)

The notice below is an invitation to view IPAWS-OPEN 2.0 live via a SOAP UI connection.  It will be of value to people who read XML and wish to see the capabilities of IPAWS-OPEN 2.0 as it works today.  There are no “regular user” gui interfaces.  Just Raw XML.  But, it will be a live demonstration and will cover all of the current capabilities of IPAWS-OPEN 2.0.  So, if you read XML, please join us.  You will be able to see an unvarnished, live demonstration of IPAWS-OPEN 2.0 message exchange.
If you want a pretty GUI for the exchange, you will not see it here.  But YOU CAN BUILD IT for your customers.  And what you see can be a foundation.

Live Demonstration, XML Messages To and From
The Integrated Public Alert and Warning System (IPAWS)
Open Platform for Emergency Networks (OPEN) 2.0
Wednesday February 16, 12:00 Noon Eastern

Please note: The audio set up for this program has changed per below.  In order to check your audio set up, staff member Amy Sebring will be logged in by 11:30 AM Eastern to provide assistance.

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 message aggregator for the Integrated Public Alert and Warning System.  During our next Webinar, System Architect Gary Ham will demonstrate a live soapUI view into IPAWS-OPEN 2.0 to show XML messages being transmitted to and from the system.

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 format of our Live Meeting has changed.  The audio portion will be delivered via your computer speakers and no telephone bridge will be provided for attendees.  The primary reason for this is to eliminate audio quality problems associated with using a bridge. The Live Meeting client must be used in order to receive the audio. Prior to the program, all attendees are urged to review the revised instructions available from:
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

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

What does Common Alerting Protocol (CAP) Compliance Really Mean?

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