OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: CAP for EAS


Friends, 

As I mentioned on our call last week, I think there are four legs to supporting the strong chair of alert and warning.  This is a concept that I would like to be prepared to present if asked during the FCC meeting on Monday.  Please provide me any comments on suggestions you have.

Definition of the Standard
The Common Alerting Protocol has been chosen as the Standard for alert and warning messaging.  The Standard was created by the OASIS Standards Development Organizations Emergency Management Technical Committee (EM-TC) and endorsed by the FCC.  This was a very good first step.  CAP has various optional fields that can be used by a product to pass data needed by a specific enterprise, e.g., duration for an EAS message.  In order to achieve interoperability among products in this enterprise, it must be agreed how these fields are to be used.

Agreement on use of terms/fields 
The definition of how these fields should be used in the EAS System should be defined by agreement between an industry group of product providers and those that will use EAS on a regular basis, the broadcast industry.  The Emergency Interoperability Consortium (EIC) is an established industry group that has worked with the development of CAP and other emergency standards for many years and has an MOA in place with DHS to facilitate this work.  The EIC also has a close working relationship with the OASIS Emergency Management Technical Committee.  We propose that representatives from the Society of Broadcast Engineers (SBE), the National Cable and Telecommunications Association (NCTA), the National Alliance of State Broadcasters Associations (NASBA) and the National Association of Broadcasters (NAB) work with the EIC and the FCC’s Public Safety & Homeland Security to develop a consensus for how CAP fields are to be used for EAS.  An agreement between the broadcast industry representatives and the EIC on how these terms should be used, endorsed by the FCC would go a long way to achieve interoperability among these systems.

Compliance testing
In order to assure interoperability, there must be some established and agreed to testing procedure.  DHS established the NIMS Support Center (NIMS SC) in 2005 – a program that operates under a Cooperative Agreement between the Federal Emergency Management Agency (FEMA) and the Justice and Safety Center/ Eastern Kentucky University (EKU). The NIMS SC provides direct support to the Incident Management Systems Division (IMSD) of FEMA’s National Integration Center (NIC).  The NIMS SC is designed to develop new first responder tools, enhance technology integration and evaluate and report on products and standards to improve incident management and information sharing throughout the first responder community.

The program provides products and services in the following areas: Compliance and Technical Assistance, Resource Management, Standards and Product Evaluations, Training and Exercises, Guidance Documents and Job Aids.   NIMS SC has been established and is in place for the purpose of testing vendor products for compliance to Standards.  They are set up and have already tested various products to the CAP Standard.  Once they have an authoritative source to determine how the optional fields should be used with EAS, their test facility could truly test to the interoperability of CAP based EAS systems.  This is the next logical step and could be achieved by the FCC endorsing the NIMS SC for compliance testing.

Migration
There is yet another piece that must be addressed.  That is the migration from the existing world of Part 11 ENDECs and various State EAS Plans to new or upgraded CAP compliant systems to support the mission of emergency alert and warning.  Where we agree that CAP is the Standard for interoperability, there is still a hardware component.  Much like Part 11, this component must be well defined and tested.  A corollary to the State EAS plan should also be drawn.  Currently, the State EAS plans define the distribution of audio messages within the State.  As EAS has matured and is being prepared for the emergency information hiway, the State EAS plan concept must also be considered and migrated.  We offer that the EDXL-DE (Emergency Data Exchange Language Distribution Element) be considered.  The EDXL-DE provides for the routing assertions for the enveloped emergency data (CAP).  In other words, to whom and under what circumstances that data is sent and/or received.  This Standard was published in May of 2006 and is also maturing and gaining wide acceptance.  The NIMS-SC is already testing vendor products for compliance with this Standard.  This will allow systems of systems to send and receive data in support of emergency functions.  Migration of the current EAS should consider this Standard as well for a complete EAS solution.

I hope to be sure and let folks know that CAP is good but not the only part of this equation.  However, I didn't want to get too technical.  Please post any edits or ideas you have.

Regards,
Elysa Jones, Chair
OASIS EM-TC
CTO/COO
Warning Systems, Inc.
256-880-8702 x102


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]