The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: August 20, 2009
XML and Emergency Management

Contents

Initiatives and Protocols

Several data exchange formats and message protocols related to emergency management and public alerts are being designed with support for XML notation. Some representative examples follow. A Google search may return additional references.

ComCARE Vehicular Emergency Data Set (VEDS) and ACN Initiative

The Vehicular Emergency Data Set (VEDS) is an XML standard for the transmission of telematics data to emergency response agencies... The VEDS data standard that determines useful and critical elements needed to prove an efficient emergency response to vehicular emergency incidents. The protocol identifies both crash and medical data elements. VEDS, however, is not a data transmission protocol/standard. How TSPs decide to send data, and how agencies collect data, transmit data, link it to voice, handle it within their various agencies, etc. are all critical issues, but not ones that were addressed in this effort. However, this common data set will enable multiple methods of data transfer and handling..."

Background: "Currently [2007], when Telematics Service Providers (TSPs), such as OnStar and ATX Technologies, receive location and/or automatic crash notification (ACN) data from a vehicle into their call centers, they must verbally relay the information to a single emergency response agency (i.e. 9-1-1, or police or EMS dispatch). The process today would typically involve a single phone call to a Public Safety Answering Point (PSAP), without any associated data. Emergency response agencies beyond the PSAP are generally not notified of the incident. However, a wealth of data exists at the TSP that can be very valuable if in the hands of the right emergency response agencies. The challenge is to be able to transmit the data from the TSP to these agencies. Current generation ACN is a very valuable service for emergency responders, often meaning the difference between life and death for vehicle occupants; advanced ACN (predictive crash data) is even more so. However, there is currently no system in daily use by TSPs for electronically forwarding that location and crash data from a TSP's internal data system to the multiple agencies for which it would have value. TSPs need to have the capability to transmit the data. Emergency Response agencies need to have the capability to receive the data..."

VEDS 1.0 was used by OnStar in a Department of Transportation sponsored test being conducted in Minnesota. It was also being tested in Orlando, FL where OnStar sent crash data directly into its 9-1-1 Computer Aided Dispatch (CAD) system. The VEDS working group met to discuss the harmonization of data elements with the Global Justice XML Data Model and will determine if VEDS should be incorporated into the EDXL process.

"In 2004, the ComCARE ACN Working Group released its draft version of the Vehicular Emergency Data Set (VEDS). The goals of the ACN Data Set Working Group were to: (1) Develop recommended XML-based data set for ACN/Mayday data; (2) Ensure input from all key affected stakeholders, public and private; (3) Widely publicize new data set to Medical/EMS and public safety communities, and to industry; (4) Discuss interface with and delivery of data to multiple destinations and utilize defined ACN data set in multiple simulations and field tests.

In March 2005, after circulating comments of the draft, the group discussed and approved a number of updates to the VEDS schema. The resulting data set, now called VEDS 2.0, expands the data collected about a crash. VEDS elements, including the rate of deceleration and direction of impact, will be used in OnStar's impending release of advanced ACN (AACN)-equipped vehicles and can now help responders determine the severity of the crash... Initially designed to transmit ACN crash data to an emergency agency, VEDS also serves as a data receptacle, collecting important bits of information as the response effort unfolds. The data set can contain data transmitted directly from the vehicle like vehicle speed, airbag deployment, direction of force and rollover as well as information from the telematics provider about the vehicle and its owner. Questions asked by a 9-1-1 operator about the age and gender of the occupants and data from responders and witnesses at the scene can also be added. When fed into URGENCY software, the likelihood of serious injury can be computed. The Urgency Algorithm is a complex set of mathematical equations developed by a multidisciplinary team of physicians, trauma surgeons, engineers and crash injury statisticians to predict the probability of a serious, potentially life-threatening injury, resulting from a crash. When in use, ACN, VEDS and URGENCY can positively impact the outcome of vehicle crashes. With electronic notification and injury detection, these technologies have the ability to reduce Emergency Medical Services (EMS) notification and response times while, at the same time, identifying specialized response needs such as air medical services and trauma center support before responders arrive on scene...

Earlier description: The ComCARE Alliance ACN Data Set Working Group published a draft XML-based ACN data standard for the "Vehicular Emergency Incident Data Exchange Format." It is not designed as a data transmission protocol, but as a recommended data exchange format. The draft standard is being developed in accordance with the recommendations of the National Mayday Readiness Initiative (NMRI)... Currently, when Telematics Service Providers (TSPs), such as OnStar and ATX Technologies, receive location and/or ACN data into their systems, they verbally relay the information to emergency responders. The goal of creating this standard is to provide TSPs a means to distribute data electronically to multiple responders. The draft ACN standard is the first step in a process to enable the electronic flow of information from a TSP to multiple public safety agencies, including 9-1-1 centers, hospitals, transportation agencies and emergency responders dispatched to an accident scene. A uniform standard is a critical element to allow for the introduction of electronic data into the emergency response system. In order to provide a complete picture of what elements were needed in this standard, ComCARE has coordinated a diverse committee from its member organizations, which includes: Acuo Technologies, the Association of Public-Safety Communications Officials International (APCO), ATX Technologies, the California Highway Patrol, Centurion Solutions, ESRI, Gannett Fleming, Intel Corporation, InterTrak Tracking Services, Medical Priority, the National Academies of Emergency Dispatch, the National Association of State EMS Directors, the National Emergency Number Association (NENA), OnStar, Response Services Center (AAA), Roadside Telematics Corporation, Televoke, Valley Health System, and the Virginia Division of Emergency Communications..."

Creation of the XML DTD/Schema: "The first phase of the process focused on developing a comprehensive list of data elements for the data set. The group formally published the initial list of data elements for comment and incorporated such comments into an XML DTD (document type definition) file. The XML dtd was a list of all elements within the data set, but it did not indicate specific formats and units of measurement that are required for each element. The next phase of the working group was to define specific data formats and relationships among the elements and move the document from a dtd file to an XML schema. To that end, the ACN Data Set Working Group formed three subcommittees to address particular sections of the data set. The subcommittees were as follows:

  • Incident Data Subcommittee: This group addressed general incident information, such as latitude and longitude, source information, and public safety agency information. Barb Thornburg, NENA Data Committee Chair, chaired this subcommittee.
  • Vehicle Data Subcommittee: This group addressed vehicle data of all types, including commercial vehicles, such as vehicle type, license number, airbag data, seatbelt data, etc. Jasmin Jijina, General Motors/OnStar Senior Engineering Associate, chaired this subcommittee.
  • Medical and Crash Data Subcommittee: This group addressed the medical and crash data elements of the data set, such as occupant breathing, occupant age, delta velocity, crash pulse, personal medical data, etc. Dr. Greg Mears, EMS Medical Director for the State of North Carolina and board member of the State EMS Directors chaired this subcommittee. [from the Overview]

"The ComCARE Alliance is a broad-based national coalition of more than 80 organizations that includes nurses, physicians, emergency medical technicians, 9-1-1 directors, wireless companies, public safety and health officials, law enforcement groups, automobile companies, consumer organizations, telematics suppliers, safety groups, and others who are working to encourage the deployment of life saving wireless communications networks and technologies that will more efficiently connect America's mobile public to emergency agencies. The goal of the ComCARE Alliance is to promote a comprehensive "end-to-end system" to enhance public safety. This system includes initiatives aimed at preventing motor vehicle fatalities, developing ubiquitous wireless enhanced 9-1-1 systems, automatically sending a wireless emergency call with enhanced data and information to the appropriate emergency personnel following a vehicle crash, and providing more timely, appropriate responses to crashes and other emergencies. This "chain of survival" includes linking existing technology - smart cars equipped with telematics, wireless telecommunications, intelligent transportation applications, and advanced emergency care - to respond to life threatening situations. This effort will save a significant number of lives each year and reduce the severity of injuries..."

Common Alerting Protocol (CAP)

Note: The CAP specification is now (2005-) being developed within the OASIS Emergency Management Technical Committee; see OASIS Emergency Management TC: CAP, EDXL-DE, EDXL-RM, HAVE.

The Common Alerting Protocol "is an open, non-proprietary standard data interchange format that can be used to collect all types of hazard warnings and reports locally, regionally and nationally, for input into a wide range of information-management and warning dissemination systems. The specification has been under development since 2001 through the efforts of an international ad-hoc Common Alerting Protocol Technical Working Group composed of technical and public safety experts. The developers have implemented the protocol in a number of prototype demonstrations. The chief benefits for public safety include (1) better coordination of warnings to the public across the wide range of available warning and notification systems; (2) reduction of workload on warning issuers, since a single warning message is compatible with all kinds of warning delivery systems; (3) enhanced situational awareness, since CAP will permit the aggregation of all kinds of warning messages from all sources for comparison and pattern recognition."

Common Intrusion Detection Signatures Standard (CIDSS)

"The purpose of the Common Intrusion Detection Signatures Standard (CIDSS) is to define a common data format for storing signatures from different intrusion detection systems. This Internet-Draft describes a common data format to represent information contained in signatures of intrusion detection systems, and explains the rationale for using this common format. The proposed format is a dialect of the Extensible Markup Language (XML). An XML Document Type Definition is developed, and examples are provided." [abstract from the Internet Draft]

The specification and IDS Signature Translator tool have been developed at the Polish-Japanese Institute of Information Technology under the direction of Adam Wierzbicki. As of 2004-11 "the translator was able to translate signatures of Snort and Dragon IDS into the common format; it has also been partially tested with Shoki, ISS RealSecure, and Cisco NetRanger."

Critical Infrastructure Protection Initiative (CIPI)

The Open GIS Consortium (OGC) Critical Infrastructure Protection Initiative (CIPI) "is an OGC Interoperability Initiative designed to test the application of interoperable technology to meet Critical Infrastructure Detection, Prevention, Planning, Response, and Recovery challenges... Timely, accurate geospatial information and geoprocessing services -- easily accessible and capable of being shared across federal, state, and local jurisdictions and multiple security levels -- are fundamental to Critical Infrastructure Protection. Homeland Security will be seriously hampered without the real-time ability to quickly visualize patterns of activity and understand the multi-layered, location-based context of emergency situations."

On January 09, 2003, Open GIS announced the successful kick-off meeting for Phase 2 of its Critical Infrastructure Protection Initiative (CIPI-2). "CIPI aims to test the application of interoperable technology to help national, state, provincial, and other local governments, commercial, and non-government organizations better manage emergency situations. The initiative does this by coordinating geospatial data and services to meet critical infrastructure protection needs. The Geography Division of the U.S. Census Bureau is sponsoring CIPI-2 and will use OGC's rapid-prototyping process to develop two prototype systems: an online system to update governmental unit boundary information for existing incorporated places, and a system based on OpenGIS Specifications for serving Topologically Integrated Geographic Encoding and Referencing (TIGER) data. Census will utilize the OGC Interoperability Program process to collaborate with industry participants Syncline, Galdos Systems, Northrop Grumman Information Technology, TASC, ESRI and Intergraph. Existing implementations of OpenGIS interface specifications, including Web Map Server (WMS), Styled Layer Descriptor (SLD), Web Feature Server (WFS), and Geography Markup Language (GML) will form the basis for the development of these two pilot applications. In addition, a collaborative Working Group, including Intergraph, ESRI, Galdos, Syncline and other OGC members will focus on developing aspects of a variety of OGC Interface Specifications to enhance the ability to create distributed GML Feature Collections. This work will be coordinated with the OGC Specification Program and will support development of shared features for Spatial Data Infrastructures. The resulting technology will be demonstrated in March 2003..."

EAS-CAP Industry Group

The EAS-CAP Industry Group (ECIG) was formed as a broad coalition of equipment, software and service providers in response to a July 2007 decision by the Federal Communications Commission (FCC) to maintain EAS and have all U.S. EAS participants adopt an ability to receive messages using the Common Alerting Protocol (CAP) within 180 days after FEMA formally adopts CAP version 1.1 as a standard for EAS.

On September 25, 2008, members of the EAS-CAP Industry Group (ECIG) announced the release of initial draft text for EAS-CAP Profile Recommendation EAS-CAP-0.1, together with an invititation for public comment.

The Profile references the CAP Standard and the FCC EAS Rules. ECIG is providing the profile "as a recommendation to U.S. governmental agencies and industry associations on the use of CAP for EAS purposes, including the FCC, FEMA, National Weather Service, and other organizations. Group members intend to rapidly implement the EAS-CAP profile within their own systems and equipment. The profile will be an important step towards improving interoperability across agencies, jurisdictions, systems, and vendors, helping to ensure that the public benefits from improved capabilities to communicate weather, civil, AMBER, and other alerts via broadcast media."

Members of EAS-CAP Industry Group believe "the integration of this EAS-CAP profile into existing and planned systems will lay a foundation for migration to an upcoming FEMA CAP profile. Prior to the formation of the EAS-CAP Industry Group, numerous progressive companies were already involved in CAP messaging for EAS. However, each vendor used its own method for transporting the EAS parameters within a CAP message, raising the potential challenge of various EAS equipment and systems not being able to communicate with each other. The advent of this EAS-CAP profile will provide the basis for interoperability both among next generation EAS equipment and services, as well as between the EAS community and other communications channels."

References:

Emergency Data Exchange Language (EDXL)

While the OASIS Emergency Management TC progresses the CAP specification toward a version 2.0, its Members are working with other organizations to develop the first components of the Emergency Data Exchange Language (EDXL). The EDXL standards activity is coordinated with DHS/FEMA (as part of the Disaster Management eGov Initiative) and with the Emergency Interoperability Consortium (EIC); hosting services are provided by the Comcare Alliance. Background information on EDXL is presented in a January 2005 Memorandum of Agreement (MOA) which "establishes an alliance between the Department of Homeland Security (DHS) and the Emergency Interoperability Consortium (EIC) to promote the design, development, release and use of XML schema-based standards or other standards, tools, and processes that will help solve data sharing problems..." According to the accompanying announcement, "The next generation of data sharing standards, being developed with the leadership of emergency response organizations, is called Emergency Data Exchange Language (EDXL). It goes beyond alerting to address the routing and substance of a wide variety of interagency emergency messaging..."

According to a report from EIC ("Creating an Emergency Data Exchange Language"):

EDXL was proposed as a "cooperative effort to define a NIMS-compliant family of shared data exchange specifications encompassing: Incident Notification and Situation Reports; Status Reporting; Resource Requests and Dispatch; Analytical Data; Geospatial Information; Identification and Authentication.

The first design principle for EDXL will be collaboration and transparency; the second will be adopting, promoting and spreading the work that has already been done to other professions (particularly with the very extensive GJXDM dictionary), i.e. no re-inventing of wheels; the third principle will be speed to deployment. The Disaster Management eGov Initiative (managed by DHS' Disaster Management Program) is providing organizational resources and technical support. The involvement of all emergency practitioner groups is encouraged. The ComCARE Alliance has been tasked by DHS to facilitate these groups' participation...

EDXL is intended to "comprise three layers of data exchange standards utilizing XML data syntax and services:

  • EDXL Vocabulary: Specified data elements and taxonomies to apply common terminology to data sharing regarding emergency incidents, conditions, resources, activities and outcomes. This will draw heavily on current common-vocabulary efforts (Justice Data Dictionary, FEMA resource typing, NIMS, etc) and the XML standards cited above. This project will support emergency organizations reviewing the XML and taxonomy work product of other professions to find commonalities (the 'common terms' project).
  • EDXL Messages: We will develop formats for messages (XML documents) using the EDXL Vocabulary to implement routing of emergency messages (a draft 'header' has been produced, trialed and submitted for standards approval) and business processes such as emergency response resources reports, queries, updates, cancellations and error-handling. The current focus is on resource messages.
  • EDXL Interfaces: Technical protocols and formats for routing of EDXL messages over various kinds of data networks and systems, based on SOAP and web-services standards, but generalized for use in a wide variety of communications environments. Our goal is to make it simple and straightforward for vendors to write interfaces from their products to EDXL."

EDXL Initiative Overview from the Comcare Alliance:

"The goal of the EDXL initiative is to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. The effort focuses on standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession is involved. Once standardized, any technology vendor or organization can easily develop their XML-based messaging interface.

The EDXL Practitioners group drives priorities and requirements for specific EDXL messages sets and messaging components. The objective is to rapidly deliver implementable standard messages in an incremental fashion directly to emergency response agencies in the trenches, providing seamless communication and coordination supporting each particular process. The effort first addresses the most urgent needs and proceeds to subsequent message sets in a prioritized fashion. The goal is to incrementally develop and deliver standards...

The EDXL initiative is a national effort including a diverse and representative group of local, state and federal emergency response organizations and professionals, following a multi-step process. A group of practitioners from leading emergency response organizations prioritize specific message sets and define base requirements...

Standard Message Sets: [Several] EDXL components and message sets [have been] identified to date for standardization activity. It is important to distinguish between the 'Distribution Element' vs. the other message sets; 'Distribution Element' may be thought of as a container which facilitates the routing of message sets (any properly formatted XML emergency message) to recipients. The message sets (e.g., Alerts, Resource Management) are carried as payloads that are routed by the Distribution Element...

  • Distribution Element: An EDXL 'Distribution Element' has been developed [and] the OASIS Emergency Management Technical Committee is reviewing it to make it a public standard... The Distribution Element carries and routes 'payload' message sets (such as Alerts or Resource Management), by specifying key routing information such as incident type and affected geography, as well as basic information such as incident ID, message type and sending agency. A series of demonstrations starting in October 2004 verified application of the Distribution Element by demonstrating generation, receipt and update of common message sets across different emergency technology tools owned by a diversity of government jurisdictions and emergency response agencies. A growing number of emergency technology vendors are using the Distribution Element in ongoing demonstrations and are prepared to incorporate it into their production systems when it becomes an official standard...

  • Alert Message Set: The Common Alerting Protocol (CAP) was developed by many of the same parties and processes as EDXL. It was originally sponsored by the Partnership for Public Warning and became an official OASIS standard in 2004. It has been adopted as a payload within EDXL messages, due to the flexibility of the EDXL 'open container model'. CAP messages facilitate the exchanging of hazard emergency alerts and public warnings. Any other accepted standard XML format can also be the payload carried and routed by the EDXL distribution element.

  • Resource Message Set: The initial EDXL practitioner group said last fall [2004] that its next priority was message sets regarding Resource Messaging (RM). They asked for messages to request (or respond to requests) for persons and things required in emergencies. A draft document addressing a Resource Message has been developed and is being considered by the Standards Working Group. A number of detailed scenarios are being analyzed to determine the wide range of specific interagency and inter-profession resource messages.

  • Geographic Information Systems (GIS): Following Resource Management Messaging, the next priority is to provide message sets addressing GIS information. The GIS message set addresses the need to identify, track, trend, or forecast events and resources. This message set also addresses the need to establish the geospatial context; to communicate about geographic features and things through standard symbols and associated information. For example, a GIS message may assist an emergency responder to assess the geographic scope of an event, to locate a required resource, to pinpoint where a resource needs to report, or to assess other geographic considerations related to an event. The symbology for this message will be 'consumed' from efforts led by FEMA, FGDC and other applicable efforts developing common mapping symbols.

  • Situation Status: Situation status is a report providing the overall status of an event and the subsequent emergency response.

  • Other specific message sets: Additional message needs will be addressed as the Practitioners raise the need for them..." [adapted from the document "Emergency Data Exchange Language (EDXL) Overview and Phased Approach" (Evolution Technologies)]

  • "OASIS Standardizes Emergency Data Exchange Language (EDXL) Specifications."

  • [June 20, 2006] "Emergency Data Exchange Language (EDXL) Distribution Element Ratified as OASIS Standard." In June 2006, OASIS anounced that the membership had "approved the Emergency Data Exchange Language Distribution Element (EDXL-DE) version 1.0 as an OASIS Standard, a status that signifies the highest level of ratification. Developed by the OASIS Emergency Management Technical Committee, EDXL-DE facilitates emergency information sharing and data exchange across local, regional, tribal, national, and international organizations in the public and private sectors...EDXL began in 2004 as a project of the Disaster Management eGov Initiative of the DHS as a means to enhance inter-agency emergency data communications. DHS partnered with industry members of the Emergency Interoperability Consortium to bring the work to OASIS for advancement and standardization..."

References:

Emergency XML (EM-XML) Consortium

Note: See now the OASIS Emergency Management Technical Committee. This section retained for historical reference.

The formation of the Emergency XML (EM-XML) Consortium [alternately: EMXML] was announced in October 2002. Founding members included: AlertTech, BizCom USA, Blue292, ESRI, E Team, Inc., International Analytics (Division of Ship Analytics), NC4, SAIC, Visual Risk, WebEOC. "The Consortium wishes to promote and establish commercial interoperability standards for companies providing software solutions to emergency management personnel, particularly first responders...Recognizing the urgent need to provide first responders and others involved in preparing for, responding to and recovering from emergencies of all kinds with the support they need, the companies have committed to creating an open XML-based standard for emergency management data exchange. This will ensure that first responders, emergency and event managers, public health agency officials and executive management in both the public and private sectors can create and immediately share critical information during an emergency or major event..."

What is the EM-XML Consortium? A parent organization, for which the OASIS Emergency Management TC is one constituent part. "Since the announcement of the EM-XML Consortium in October 2002, the group has attracted the attention of numerous public and private companies, individuals, and agencies. Currently totaling a representation in excess of 40 institutions, this effort is focused on researching, designing, developing, deploying, and evangelizing standards in the world of incident and emergency management. The Consortium's rapid growth and exposure has not only allowed it to help begin defining future of incident and emergency management standards, but it also began to impact them today. To accommodate the growth and further focus the work [of the Consortium], an Executive Committee (EC) and a Technical Committee (TC) have been formed. This provides a more well-defined and efficient structure, with each committee serving its own unique functions. The EM-XML EC is chaired by Matt Walton, Founder and Vice Chairman of E Team, and focuses on the public and Federal outreach and education of the efforts of the TC, as well as incident and emergency management issues in general. This group provides guidance and direction for development of interoperability standards focused on incident and emergency management. Currently, the group meets quarterly and membership is free. Additional information about the EM-XML EC can be requested by sending email to Matt (mwalton@eteam.com). R. Allen Wyke, CIO of Blue292, chairs the TC. It focuses on the design and creation of XML-based standards to support incident and emergency management interoperability. This group, formally known as the Emergency Management Technical Committee (EM TC), is housed within OASIS, 'a not-for-profit, global consortium that drives the development, convergence and adoption of e-business standards.' Additional information about the EM TC, which has weekly calls and requires membership in OASIS, can be obtained from the Website or by sending email to R. Allen Wyke." From "Understanding the EM-XML Consortium," a document describing the EM-XML Consortium and its relation to the OASIS Emergency Management TC, 2003-04-22.

IEEE Incident Management Working Group (IMWG)

The WG was formed to "research, compile, analyze, and consolidate information leading to the publication of a standards message set for Incident management; this scope initially will be limited to address message sets from Emergency Management Center (EMC) to the Traffic Management Center (TMC) and Emergency Telephone System (ETS)... Message sets for Incident Management include all message sets generated and transmitted between the emergency management subsystem to all other subsystems. and providers. These include, the Emergency Telephone System, Fleet and Freight Management, Information Service Provider, other Emergency Management Centers, Planning Subsystem, Traffic Management, and Transit Management. Therefore a standard message set will reduce the duplication of messages among the various subsystems and a common set of message will help providers or services to interact more effectively..."

IEEE 1512-2000, Standard for Common Incident Management Message Sets for use by Emergency Management Centers, is the base standard for incident management message sets. Providing incident management message sets common to traffic management, public safety and hazardous materials incident response activities, it supports communications among Multi-Modal Transportation Management Centers, Public Safety Agencies, Fleet and Freight Management Centers, Information Service Providers, Traffic Management Centers. Companion volumes are being developed in four areas: (1) Traffic Management: Traffic management message sets for use by transportation and public safety agencies in transportation incident management. (2) Public Safety: Message sets for interagency coordina - tion, dispatching and asset management for use by transportation and public safety agencies in transportation incident management. (3) Hazardous Materials: Message sets for communications dealing with management of hazardous materials during a transportation incident. (4) Data Dictionary: A data dictionary of the data elements and structures used in the 1512 family of standards..." See the IEEE Std 1512 - 2000 Fact Sheet.

2003 Revision of IEEE Std 1512-2000 to include XML: "The base standard (IEEE Std 1512-2000) was published in 2000 under the leadership of Chester Chandler, who was the IMWG Chair. This standard covers center identification, where centers can go off-line or on-line, as well as ways to describe the incident, such as numbering, splitting, or merging them, etc. Most importantly, it contains an incident description that can continue to expand as more centers add to or update the information. It also includes messages relating to emergency response plans. This standard was demonstrated by operating a prototype messaging system between the Florida SunGuide and Lockheed-Martin exhibit booths at ITS America's 11th Annual Meeting and Exposition in Miami in 2000. A revision to this standard is expected to be published in 2003. This revision will add sections for CORBA and Extensible Markup Language (XML) implementation, as well as adding some minor new data elements..." [From "Incident Management Message Sets," in Florida Department of Transportation (FDOT) SunGuide, November 2002]

Standard for Hazardous Material Incident Management Message Sets for Use by Emergency Management Centers. In October 2002, the volume for exchange data concerning Hazardous Materials (HazMat) was officially published (IEEE Std 1512.3 TM-2002). [It] ... provides a common framework for communication to online databases about the materials involved in transportation emergencies. The standard addresses data collection on hazardous and non-hazardous substances from databases maintained by shippers, carriers, fleet and freight management centers, and other parties. This information concerns such topics as toxicity, explosive danger, flammability, environmental damage, set-backs and evacuation areas. IEEE 1512.3 also sets a uniform format for transmissions from emergency sites to government agencies and other parties to eliminate confusion in how the data is interpreted...] This standard was developed under the leadership of Michael Ritchie of the Minnesota Department of Transportation (MinnDOT), the HazMat Sub-Committee Chair. The standard includes sections on CORBA and XML, as well as the required Abstract Syntax Notation One (ASN.1)..." [also from SunGuide 2002-11]

IETF Authority to Citizen Alert (ATOCA) Working Group

On August 17, 2010, the IESG formally announced the formation of ATOCA: "A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Working Group: Authority to Citizen Alert (ATOCA). Earlier: provisional charter.

From the ATOCA Working Group Charter:

There are a variety of mechanisms that authorities have available to notify citizens and visitors during emergency events. Traditionally, they have done so with broadcast networks (radio and television). For commercial mobile devices, broadcasting services such as the Public Warning System (PWS), the Earthquake and Tsunami Warning System (ETWS), and the Commercial Mobile Alert System (CMAS) are standardized and are in various stages of deployment. The Internet provides another way for authority-to-citizen alerts to be sent, but it also presents new challenges. While there are some existing layer 2 mechanisms for delivering alerts, the work in this group focuses on delivering alerts to IP endpoints only.

The general message pattern that this group is intended to address is the sending of alerts from a set of pre-authorized agents (e.g., governmental agencies) to a large population without undue impacts on the networks serving that population. In particular, the message pattern specified should avoid congestion and other denials of service.

The goal of this group is not to specify how originators of alerts obtain authorization, but rather how an ATOCA system can verify authorization and deliver messages to the intended recipients. A critical element of the work are the mechanisms that assure that only those pre-authorized agents can send alerts via ATOCA, through an interface to authorized alert distribution networks (e.g., iPAWS/DM-Open in the U.S.).

The ATOCA effort is differentiated from and is not intended to replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the recipients of ATOCA alerts are the wide range of devices connected to the Internet and various private IP networks, which humans may have "at hand" to get such events, as well as automatons who may take action based on the alerts. This implies that the content of the alert contains some information, which is intended to be consumed by humans, and some which is intended to be consumed by automatons.

Ideally, the alerts would contain, or refer to media other than text media (e.g., audio and/or video). The initial work in the group is focused on small messages, which may be mechanically rendered by the device in other forms (text to speech for example). Future work in the group may investigate rich media.

In situations of a major emergency there could be scenarios where there are multiple alerts generated that may require that a priority mechanism (defined by alert originator policy) has to be used. The work on a resource priority mechanism is out of scope of the initial charter, but may be revisited at a later date.

Which devices should get alerts is primarily driven by location. The first set of recipients that must be catered for are those within the area identified by the alert originator to be affected by the emergency event. In many jurisdictions, there are regulations that define whether recipients/devices within the affected area have opt-in or opt-out capability, but the protocols ATOCA will define will include both opt-in and opt-out mechanisms. The group will explore how to support both opt-in and opt-out at the level of communication protocols and/or device behavior.

Another class of recipients that are in scope of the work are explicit opt-in subscriptions which ask for alerts for a specified location, not necessarily the physical location of the device itself. An example of such a subscription would be 'send me alerts for location x' (previously determined as the location of interest). This work may build on existing IETF GEOPRIV location work.

There are efforts in other fora on early warning, which will be considered in this effort. For example, we expect to make use of the OASIS Common Alerting Protocol (CAP) for the encoding of alerts. OGC, ATIS, TIA, ITU-T, ETSI and 3GPP also have alert efforts underway, and consultation with these efforts will be undertaken to avoid unnecessary duplication of effort and also to avoid unintentional negative impacts on the networks. Of course, existing protocols for delivering messages (e.g., SIP, XMPP, or SMTP) will be the basis for the message delivery system of this working group. Any service discovery mechanisms defined by the group are expected to reuse existing discovery frameworks.

The security implications of mechanisms that can send alerts to billions of devices are profound, but the utility of the mechanism encourages us to face the problems and solve them. In addition, the potential performance and congestion impacts to networks resulting from sending alert information to billions of devices must be considered and solved if such a service is implementable. To avoid manual configuration of servers distributing alerts a discovery mechanism will be specified..."

Early ATOCA Working Group Drafts:

References:

IETF Emergency Context Resolution with Internet Technologies (ECRIT)

Background: "The public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (commonly one that is short and easily memorized) as a call for emergency services. These numbers (e.g. 911, 112) relate to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained context of service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires both an association of the physical location of the originator with an appropriate emergency service center and call routing to deliver the call to the center... Calls placed using Internet technologies do not use the same systems to achieve those goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting them more challenging. There are, however, Internet technologies available to describe location and to manage call routing.

The Emergency Context Resolution with Internet Technologies (ECRIT) working group was chartered to describe when internet technologies for call routing "may be appropriate and how they may be used. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used in this document, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services."

RFC 5069 "Security Threats and Requirements for Emergency Call Marking and Mapping" reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the identified threats, RFC 5069 establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. Informational RFC 5012 "Requirements for Emergency Context Resolution with Internet Technologies" defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end to end.

ECRIT is part of the IETF Real-time Applications and Infrastructure Area, together with Geographic Location/Privacy, Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), and other working groups.

References:

IETF Incident Object Description and Exchange Format (IODEF)

"... the free exchange of incident information and statistics among involved parties and the responsible Computer Security Incident Response Teams (CSIRTs) is crucial for both reactionary analysis of current intruder activity and proactive identification of trends that can lead to incident prevention. The purpose of the Incident Handling working group is to define data formats for communication between (a) a CSIRT and its constituency (e.g., users, customers, trusted reporters) which reports system misuse; (b) a CSIRT and parties involved in an incident investigation (e.g., law enforcement, attacking site); and (c) collaborating CSIRTs sharing information. This format will support the now largely human-intensive dimension of the incident handling process. It will represent the product of various incremental data gathering and analysis operations performed by a CSIRT from the time when the system misuse was initially reported (perhaps by an automated system) till ultimate resolution..."

IETF Intrusion Detection Exchange Format (IDMEF)

"Security incidents are becoming more common and more serious, and intrusion detection systems are becoming of increasing commercial importance. Numerous intrusion detection systems are important in the market and different sites will select different vendors. Since incidents are often distributed over multiple sites, it is likely that different aspects of a single incident will be visible to different systems. Thus it would be advantageous for diverse intrusion detection systems to be able to share data on attacks in progress. The purpose of the Intrusion Detection Working Group is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to management systems which may need to interact with them. The Intrusion Detection Working Group will coordinate its efforts with other IETF Working Groups..."

NIEM (National Information Exchange Model) Emergency Management

NIEM [2.0] is the U.S. National Information Exchange Model. "This is an interagency initiative to provide the foundation and building blocks for national-level interoperable information sharing and data exchange. The NIEM project was initiated on 28-February-2005 as a joint venture between the U.S. Department of Homeland Security (DHS) and the U.S. Department of Justice (DOJ) with outreach to other Government departments and agencies. The NIEM leverages both the Global Justice XML Data Model (GJXDM) reference model and the GJXDM XML-based framework and support infrastructure.

The model incorporates NIEM reference schemas (Core, code lists, domains, wrappers for external standards, as well as the schemas for those standards, or profiles of, or adaptations of.) It also contains a cumulative change log and the spreadsheet. NIEM provides practitioners and developers with a baseline set of XML Schema components for building Information Exchange Package Documentation (IEPDs). Among the NIEM 2.0 XML Schemas is a 'NIEM Domain Schema' for Emergency Management.

Also among the NIEM 2.0 Conformant Schemas (code lists and adaptations of external standards) are:

  • edxl: Emergency Data Exchange Language [cache]
  • edxl-cap: Common Alerting Protocol [cache]
  • edxl-de: Distribution Element [cache]
  • have: EDXL Hospital AVailability Exchange (HAVE) [cache]
  • geospatial: Defines NIEM adapter types for external geospatial components defined by OGC, LIF, LandXML, IAI, and ANSI. Note for schema readers: The XML/Schema specification does not require processing implementations to transitively import definitions from imported schemas. To assure that all required definitions are available, a schema must re-import the schemas that are imported by the schemas it imports. Such re-imports are noted in the documentation. [cache]

References:

OASIS Emergency Interoperability (EI) Member Section

"The OASIS Emergency Interoperability (EI) Member Section accelerates the development, adoption, application, and implementation of emergency interoperability and communications standards and related work. EI endeavors to represent and serve the needs of all constituents, from practitioners to technology providers and national, international and multinational oversight agencies.

The EI Member Section intends to drive development and adoption of Emergency Communications Standards through the full standards lifecycle, from requirements capture to standard creation and adoption services, in alignment with market needs. As the standards in this area mature, EI is committed to support needs that may evolve, including developing interoperability testing guidelines for self-testing or certification and supporting such testing. This is in response to the clearly expressed need by the wide variety of emergency response agencies and organizations to be able to share information across professional and jurisdictional lines, whatever specific application they may have in their office."

References:

OASIS Emergency Management TC: CAP, EDXL-DE, EDXL-RM, HAVE

The OASIS Emergency Management TC supports development and adoption of several standards relating to public safety and emergency management, including (1) alerting, warning, and informing responders and the public (2) incident reporting and tracking; (3) resource identification, tasking and tracking.

  • CAP (Common Alerting Protocol)
  • HAVE (Emergency Data Exchange Language Hospital AVailability Exchange - HAVE)
  • EDXL-DE (Emergency Data Exchange Language Distribution Element)
  • EDXL-RM (Emergency Data Exchange Language Resource Messaging)

In November 2005, OASIS announced that the Common Alerting Protocol (CAP) version 1.1 had been approved as an OASIS Standard. "CAP v1.1 enhancements include flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions; multilingual and multi-audience messaging; phased and delayed effective times and expirations; enhanced message update and cancellation features; template support for framing complete and effective warning messages; compatibility with digital encryption and signature; and a facility for digital images and audio. The OASIS TC seeks input from those in the international community to advance CAP in alignment with other specifications in its Emergency Data Exchange Language (EDXL) suite."

On April 01, 2004 OASIS announced that the Common Alerting Protocol Committee Draft version 1.0 of February 10, 2004 approved by the TC and balloted to the OASIS membership had resulted in this Committee Draft being approved as an OASIS Standard. A new "CAP 1.0 Fact Sheet" has also been released. See additional details in the press release of 2004-05-05: "Common Alerting Protocol (CAP) Ratified as OASIS Standard."

[February 26, 2004]   Common Alerting Protocol Version 1.0 Approved by OASIS Emergency Management TC.    Members of the OASIS Emergency Management Technical Committee have approved a Committee Draft specification for the Common Alerting Protocol Version 1.0 and have recommended its advancement for approval by OASIS as an OASIS standard. The Common Alerting Protocol (CAP) is "a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task. CAP also facilitates the detection of emerging patterns in local warnings of various kinds, such as might indicate an undetected hazard or hostile act. And CAP provides a template for effective warning messages based on best practices identified in academic research and real-world experience." The TC was chartered to "design, develop, and release XML Schema-based standards that begin to solve the real-world problems of incident preparedness, response, and emergency management; these standards are not only to provide a framework for data exchange, but also for functionality and service accessibility, all with the common goal of seamless application and data interoperability. The Emergency Management TC's scope includes: unified incident identification; emergency GIS data accessibility and usage; notifications methods and messages; situational reporting; source tasking; asset and resources management; monitoring and data acquisition systems; staff, personnel and organizational management."

[January 10, 2003]   OASIS Members Form Emergency Management Technical Committee.    Affiliates of seven OASIS member companies (Blue292, Inc., E Team, Inc., SunGard Planning Solutions, DMI-S, NC4, Wells Fargo N.A., Ship Analytics) have created a new Emergency Management Technical Committee to "advance the fields of incident preparedness and response in addition to emergency management." Blue292, Inc. intends to contribute a notification specification and form data collection specification to the technical committee at its first meeting for consideration as the basis for work. The TC members will "design, develop, and release XML Schema-based standards that begin to solve associated 'real-world' problems of data communication and technology interoperability. These standards will not only provide a framework for data exchange, but also for functionality and service accessibility, all with the common goal of seamless application and data interoperability. The TC's scope of activity is to include: unified incident identification; emergency GIS data accessibility and usage; notifications methods and messages; situational reporting; source tasking; asset and resources management; monitoring and data acquisition systems; staff, personnel and organizational management." The TC Chairs include Allen Wyke (Blue292, Chair) and Rick Carlton (E Team, Inc., Vice Chair).

[October 30, 2003]   OASIS Emergency Management TC Approves Common Alerting Protocol (CAP) Draft.    A Committee Draft for the Common Alerting Protocol Version 1.0 has been approved by members of the OASIS Emergency Management Technical Committee and has been released for 30-day public review. The Common Alerting Protocol is "a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task. CAP also facilitates the detection of emerging patterns in local warnings of various kinds, such as might indicate an undetected hazard or hostile act. And CAP provides a template for effective warning messages based on best practices identified in academic research and real-world experience." The OASIS TC was chartered to "advance the fields of incident and emergency preparedness and response, to be accomplished by designing, developing, and releasing XML Schema-based core and metadata standards to help facilitate and improve the real-world interoperability problems around incident and emergency management." Public review of the CAP Version 1.0 CD and comments are invited through November 30, 2003.

OpenSec Advisory and Notification Markup Language (ANML)

The Open Security Organization is developing an Advisory and Notification Markup Language (ANML). First in a planned suite of related standards, the Advisory and Notification Markup Language (ANML) "is an XML-based specification for describing advisories and other types of notifications. ANML intends to solve the inconsistent use of terminology by software vendors in their advisories and make it easy for applications to read these advisories. This will make way for the necessary tools to automatically update systems. Although ANML will have its biggest impact for security advisories, it can be used for any type of notification. Some examples include bug-fixes, feature enhancement, upgrade availability, and many more." The developers solicit involvement from interested parties. Other standards planned for development include: (1) System Information Markup Language (SIML) -- an XML-based specification for describing a system's properties and providing a detailed inventory of software, hardware, and configuration information; (2) Software Description Markup Language (SDML) -- an XML-based specification for describing the properties of software and its environment. ANML, SIML, and SDML are designed to form the core of the OpenSec Framework. The OpenSec Framework is a set of guidelines on how to use these technologies to aid system management. The OpenSec goal is to be able to send an SDML file to a web service that will respond with an ANML file. A system manager will compare elements of the ANML file to elements of the SIML file to assess the system and install the necessary updates."

SAFE: Tsunami Warning Markup Language (TWML) and Cyclone Warning Markup Language (CWML)

"Tsunami and cyclone warnings are currently most commonly disseminated in textual formats that are not amenable to machine processing. To address this, SAFE Information researchers have been investigating the use of structured semantic data models for representing warnings, and have developed the Tsunami Warning Markup Language (TWML) and the Cyclone Warning Markup Language (CWML). The goal of these languages is to facilitate various kinds of automated processing, such as rapid dissemination to people in affected areas, aggregation of warning information, and interoperability with geospatial systems through the use of Geography Markup Language (GML) elements. The languages are also designed to be used in conjunction with OASIS standards such as the Emergency Data eXchange Language Distribution Element (EDXL-DE) and the Common Alerting Protocol (CAP)."

References:

W3C Emergency Information Interoperability Framework (EIIF) Incubator Group

"The mission of the Emergency Information Interoperability Framework (EIIF) Incubator Group, part of the Incubator Activity, is to review and analyse the current state-of-the-art in vocabularies used in emergency management functions and to investigate the path forward via an emergency management systems information interoperability framework. These activities will lay the groundwork for a more comprehensive approach to ontology management and semantic information interoperability leading to a proposal for future longer-term W3C Working Group activity."

Initiating Members of the EIIF Incubator Group included National ICT Australia (NICTA) Ltd, Google, Swedish Institute of Computer Science (SICS), and IBM Corporation.

References:

News, Articles, Papers, Reports, Drafts

  • [March 11, 2009] "Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)." Edited by Brian Rosen (NeuStar, Inc), Henning Schulzrinne (Columbia University, Department of Computer Science), and Hannes Tschofenig [WWW] (Nokia Siemens Networks). IETF SIPPING Working Group, Standards Track Internet Draft: 'draft-rosen-sipping-cap-03.txt'. March 7, 2009, expires September 8, 2009. 13 pages. Prepared by members of the IETF Session Initiation Proposal Investigation (SIPPING) Working Group. IETF I-D Tracker. HTML version, and Diff with version -02. See also the document announcement by Hannes Tschofenig. Excerpt: "The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. This document allows CAP documents to be distributed via the event notification mechanism available with the Session Initiation Protocol (SIP). Additionally, a MIME object is registered to allow CAP documents to be exchanged in other SIP documents. The 'common-alerting-protocol' Event Package: RFC 3265 (Session Initiation Protocol (SIP)-Specific Event Notification) defines a SIP extension for subscribing to remote nodes and receiving notifications of changes (events) in their states. It leaves the definition of many aspects of these events to concrete extensions, known as event packages. This document defines such an event package, and fills in the information required for all event packages by RFC 3265. Additionally, RFC 3903 (Session Initiation Protocol (SIP) Extension for Event State Publication) defines an extension that allows SIP User Agents to publish event state. According to RFC 3903, any event package intended to be used in conjunction with the SIP PUBLISH method has to include a considerations section. This section also fills the information for all event packages to be used with PUBLISH requests. This document defines a new 'common-alerting-protocol' event package. Event Publication Agents (EPA) use PUBLISH requests to inform an Event State Compositor (ESC) of changes in the common-alerting-protocol event package. Acting as a notifier, the ESC notifies subscribers about emergency alerts and public warnings. SUBSCRIBE Bodies: The SUBSCRIBE body is is [now] allowed to carry location information — in civic and geodetic location format. This information can be used to filter warning messages to a specific region. RFC 3265 allows a SUBSCRIBE request to contain a body. This document allows the body to contain civic and geodetic location information to be carried. The 2D location shapes listed in GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations, e.g., 'Point' 'Polygon', 'Circle', 'Ellipse', 'ArcBand', and a 'civicAddress' element, defined in RFC 5139 (Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)), in the body of the message. The recipient of the SUBSCRIBE message should use this information to restrict the warning messages that are being delivered [where information about the type of alerts that shall be received may need to be indicated as well.]... In this -03 version, text is supplied for Section 5 'Security Considerations', including description of threat and countermeasures for: Man-in-the-Middle Attacks, Forgery, Replay Attack, and Unauthorized Distribution.

  • [February 15, 2009] Common Alerting Protocol, v. 1.1 USA Integrated Public Alert and Warning System Profile. Working Draft 05. February 12, 2009. 71 pages. Edited by Art Botterell (Contra Costa County Community Warning System), Rex Brooks, and Sukumar Dwarkanath (SRA International). Produced by members of the OASIS Emergency Management Technical Committee (through the EM CAP Profiles Subcommittee). Status: This is the version reported out to the TC for consideration as a candidate for for Committee Draft and Public Review. Summary: "This profile of the XML-based Common Alerting Protocol (CAP) describes an interpretation of the OASIS CAP v1.1 standard necessary to meet the needs of the Integrated Public Alert and Warning System (IPAWS), a public alerting "system of systems" created by the U.S. Federal Emergency Management Agency." From the document Introduction: "In order to meet the needs of the devices intended to receive alerts from the United States Integrated Public Alert and Warning System (IPAWS) System of Systems (SoS), this CAP v1.1 IPAWS Profile constrains the CAP v1.1 standard for receipt and translation with and among IPAWS exchange partners. The use of this profile is not necessarily limited to the initial IPAWS Exchange Partners. It is available to all who might want to use the particular concepts defined in this specification. The Common Alerting Protocol (CAP) provides an open, non-proprietary digital message format for all types of alerts and notifications. It does not address any particular application or telecommunications method. The CAP format is compatible with emerging techniques, such as Web services, as well as existing formats including the Specific Area Message Encoding (SAME) used for the United States' National Oceanic and Atmospheric Administration (NOAA) Weather Radio and the Emergency Alert System (EAS), while offering enhanced capabilities that include: flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions; multilingual and multi-audience messaging; enhanced message update and cancellation features; template support for framing complete and effective warning messages; compatible with digital encryption and signature capability; facility for digital images and audio... The Common Alerting Protocol (CAP) v1.0 and v1.1 were approved as OASIS standards before the Emergency Data Exchange Language (EDXL) project was developed. However, this profile specification shares the goal of the EDXL project to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. Several exchange partner alerting systems of the IPAWS SoS are identified by this profile for specific accommodation. However, the CAP v1.1-IPAWS Profile is not limited to systems. It is structured to allow inclusion of other alerting systems as deemed appropriate or necessary. In addition to the definition of the term Profile in Section 1.2 Terminology, this profile is responsive to the requirements articulated by the FEMA IPAWS Program Management Office... Process: This Profile was developed primarily by integrating requirements related to three federal warning-delivery systems: (1) the broadcast Emergency Alert System (EAS) as recommended by the EAS-CAP Industry Working Group; (2) the NOAA Non-Weather Emergency Message (NWEM) "HazCollect" program for weather radio and other delivery systems as derived from technical documentation; and, (3) the Commercial Mobile Alerting Service (CMAS) for cellular telephones as described in the recommendations of the Commercial Mobile Service Alert Advisory Committee (CMSAAC). Additional guidance was drawn from subject matter experts familiar with the design and implementation of those and other public warning systems. See the reference page and the posting "Call for Review of IPAWS CAP 1.1 Profile Committee Draft" sent by Elysa Jones to the OASIS Emergency management Technical Committee list. [source .DOC]

  • [January 27, 2009] "Emergency and Crisis Management (ECM) Domain Special Interest Group (DSIG)." Updated Proposed Object Management Group (OMG) Charter. Organizing Chairs: Michael Abramson (Advanced Systems Management Group - ASMG) and W. Craig Campbell (Department of National Defence, Canada). "Recent reports and surveys have underlined the need for all levels of government, civil agencies and supporting military units to share information more efficiently when working together during emergency and risis response operations. The ECM will undertake an overarching initiative to develop a framework and new approaches to facilitate such critical informaton exchange across separate and distinct domains. Current thinking in this area encourages the use of standards-based interfaces and common models (e.g., NEIM, CAP and JC3IEDM) to enable successful information exchange — and ultimately provide decision makers with quality (ACCURATE, RELEVANT, TIMELY, USABLE, COMPLETE, BRIEF, SECURE) information tailored to the varying stages and severity of an incident. Given that crisis situations are inherently unpredictable and dynamic, any proposed solution must also demonstrate the ability to adapt to changing conditions and the impact they will have on polic and regulations for information protection across the many organizations that interact with emergency management functions. The SIG will seek to exploit emerging community, consortium and international standards and their ability to deliver controlled and adaptive information sharing as required tosupport the diversity of emergency management operations at varying stages of an incident. Where necessary, the SIG will prepare RFIs and RFPs for specifications that augment current and evolving capability... The primary mission of the EM PTF is to create framework through which Emergency and Crisis Management community leverage evolvng open specifications and standards from multiple organizations and consortium such as: OMG, Open Group, OASIS, IETF, NENA, ISO, W3C, ORCHESTRA, SANY, GMES, GEOSS, GOOB, and ITCM. The SIG will provide guidance on the use and integration of these specifications to provide interoperability to the broader ommunity. The framework will be used to identify where additional standards efforts will be required to enhance ECM system interoperabiity..." See also: C4I DTF, "a Domain Task Force of the Object Management Group (OMG) that operates under the Domain Technical Committee and is focused on systems that support crisis response, Search and Rescue (SAR), and military operations." Citation source: from an announcement posted by Juergen Boldt, January 26, 2009: "An updated proposed charter for a Emergency and Crisis Management DSIG has been posted to the OMG server as dtc/2009-01-02... this document takes OGC comments into account. I have added the charter to the preliminary Washington, DC, DTC agenda..." [cache/archive]

  • [January 21, 2009] CAP v1.1 Federal Emergency Management Agency (FEMA) Integrated Public Alert and Warning System (IPAWS) Public Review Profile. [Revised] Draft, submitted by the OASIS EM CAP Profiles Subcommittee to the OASIS Emergency Management Technical Committee (EM TC) for review. Posted to the EM CAP Profiles SC List by Rex Brooks on January 16, 2009. [Note: This '30729' document is the same as CAP-v1.1-IPAWS-Public-Review-Profile-1.0.doc, except that each sentence in the tables is now represented as numbered paragraph. The second Table the entry in the EAS column for parameter needed some reworking for the numbering to make sense, but no change was made in the requirement]. "Work on the Profile began following a request from the US FEMA IPAWS Program through the US DHS Science and Technology (S&T) to evaluate and standardize a CAP profile from requirements developed from their requirements. This will enable interoperability with other IPAWS partner systems (EAS, HazCollect, and CMAS). The request was accompanied with the FEMA IPAWS CAP v1.1 Profile Requirements Draft version 2.4 (December 10, 2008), submitted on 12 Dec 2008" — see Federal Emergency Management Agency (FEMA) / Integrated Public Alert & Warning System (IPAWS) Common Alerting Protocol (CAP) v1.1 Profile Requirements, Draft Version 2.4 and the DHS-EMTC letter of December 12, 2008 (Subject: "Integrated Public Alert and Warning System Common Alerting Protocol for the Emergency Alert System") [...] The OASIS Subcommittee began its work with an analysis of the constraints of multiple partner systems to identify any limitations to create a single profile specification that can satisfy all three systems. Following its analysis the subcommittee concluded that a single profile can accommodate the common needs and constraints of these three systems. The document that is provided for public review is a draft of the CAP Profiles subcommittee results thus far. With EM-TC approval, the subcommittee desires to release this preliminary comparison for public review. This will allow the many stakeholders in these systems to be able to comment on the work to date. It is desired that the comment period run for seven (7) days. Once comments are received and consensus arrived at their disposition, the subcommittee will continue to formalize this profile into a Committee Draft that will be submitted for public review..." See details in the memo sent to the EM TC by EM CAP Profiles SC Co-Chairs (Sukumar Dwarkanath and Tom Ferrentino). [Sources: SC draft K-30729 source .DOC; source .DOC for FEMA/IPAWS v2.4 and 2008-12-12 letter to EMTC]

  • [November 11, 2008] "A Uniform Resource Name (URN) for Early Warning Emergency Services and Location-to-Service Translation (LoST) Protocol Usage." IETF Standards Track Internet Draft. October 26, 2008, expires April 29, 2009. Edited by Brian Rosen (NeuStar, Inc) Henning Schulzrinne (Columbia University, Department of Computer Science), and Hannes Tschofenig (Nokia Siemens Networks). Produced by members of the IETF Session Initiation Proposal Investigation (SIPPING) Working Group. The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. Different organizations issue alerts for specific geographical regions. The Location-to-Service Translation (LoST) protocol provides a way to discover servers that distribute these alerts for a geographical region. This document defines the Service Uniform Resource Names (URN)s for warnings in the same way as they have been defined with RFC 5031 for citizen-to-authority emergency services. Additionally, this document suggests to use LoST for the discovery of servers distributing alerts. This document makes use of RFC 5222 ("LoST: A Location-to-Service Translation Protocol"). However, instead of performing a translation from location information and a Service URN to a PSAP URI (plus supplementary information), as used with "Best Current Practice for Communications Services in support of Emergency Calling", for the citizen-to-authority emergency services use case, the LoST client asks the LoST server for a URI to receive further information on how to obtain warning alerts. In a response the URIs in the 'uri' element MUST be from the following format: sip, xmpp or http. The SIP URI MUST subsequently be used with "Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)". An XMPP URI MUST be used as described in "Common Alerting Protocol (CAP) Over XMPP". An HTTP URI MUST be used with GeoRSS. In a LoST response the optional 'serviceNumber' element is not used by this specification. In mapping citizen-to-authority services, receiving multiple mappings is an exception. However, since many organizations may provide warnings for the same area, this is likely to be more common for alerts. As such, the extensions defined in "Location-to-Service Translation Protocol (LoST) Extensions" (e.g., the ability to limit the number of returned mappings) are useful in this context...

  • [August 21, 2008] Requirements for Authority-to-Individuals Communication for Emergency Situations. IETF Internet Draft. Produced by members of the IETF Emergency Context Resolution with Internet Technologies (ECRIT) Working Group. By Steve Norreys, Hannes Tschofenig, and Henning Schulzrinne. July 12, 2008, expires January 13, 2009. "During large-scale emergencies, public safety authorities need to reliably communicate with citizens in the affected areas, to provide warnings, indicate whether citizens should evacuate and how, and to dispel misinformation. Accurate information can reduce the impact of such emergencies. Traditionally, emergency alerting has used church bells, sirens, loudspeakers, radio and television to warn citizens and to provide information. However, techniques such as sirens and bells provide limited information content; loud speakers cover only very small areas and are often hard to understand, even for those not hearing impaired or fluent in the local language. Radio and television offer larger information volume, but are hard to target geographically and do not work well to address the 'walking wounded' or other pedestrians. Both are not suitable for warnings, as many of those needing the information will not be listening or watching at any given time, particularly during work/school and sleep hours. This problem has recently been illustrated by the London underground bombing on July 7, 2006, as described in a government report. The UK authorities could only use broadcast media and could not, for example, easily announce to the 'walking wounded' where to assemble. This document summarizes key requirements for IP-based protocols to enhance and complement existing authority-to-citizen warning systems. These protocols may either directly reach the citizen or may be used to trigger more traditional alerts, such as, among many others, displays in subway stations, electronic bill boards, or SMS... This document reuses requirements captured outside the IETF, namely: (1) ETSI TS 102 182, V1.2.1 (2006-12), Technical Specification, Emergency Communications (EMTEL); Requirements for communications from authorities/ organizations to individuals, groups or the general public during emergencies", December 2006. (2) "3GPP TR 22.968, V1.0.0 (2007-04), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study for requirements for a Public Warning System (PWS) Service (Release 8)", December 2006.

  • [August 18, 2008] "Data Technology Keeps in Step with NIMS STEP." From Interoperability Technology Today: A Resource for the Emergency Response Community. Summer Edition 2008, page 5. Published by DHS Science and Technology Directorate's 'Command, Control and Interoperability Division' (CID). Available through SAFECOM, a communications program of the Department of Homeland Security. "Emergency managers are steps closer to ensuring that technologies supporting response operations adhere to the Common Alerting Protocol (CAP) and the Emergency Data Exchange Language (EDXL) suite of standards. These data messaging standards enable emergency responders to share critical data — such as a map, a situational report, or an alert — seamlessly across disparate software applications, devices, and systems. The effective exchange of this type of data is essential during emergency response operations. To evaluate product adherence to data messaging EDXL standards, U.S. Department of Homeland Security (DHS) Command, Control and Interoperability Division (CID) is partnering with the DHS Federal Emergency Management Agency's (FEMA) Incident Management Systems Integration (IMSI) program. The initiative, known as the National Incident Management System Supporting Technology Evaluation Program (NIMS STEP), provides an independent, objective evaluation of commercial and government hardware and software products related to incident management. Participation in the voluntary program does not constitute certification of NIMS compliance or an official DHS endorsement of the product. FEMA IMSI Program Specialist David Larimer: "NIMS STEP meets an unmet need by focusing on data exchange interoperability and by providing a testing venue for vendors to demonstrate consistency with CAP, EDXL-Distribution Element (DE), and NIMS concepts and principles." Evaluation activities are also designed to help create a uniform level of compliance and expand technology solutions. NIMS STEP supports NIMS, which identifies the requirements for ensuring interoperability and compatibility among multiple response agencies. NIMS efforts provide a consistent, nationwide approach for agencies at all levels of government to effectively and efficiently manage response operations... In support of these NIMS criteria, NIMS technical standards CAP and EDXL are linked to IMSI testing and evaluation activities. The CAP standard enables practitioners to exchange all-hazard emergency alerts, notifications, and public warnings. Such data can be disseminated simultaneously over many different warning systems, e.g., computers, wireless, alarms, television, and radio. The EDXL suite of standards includes the DE standard, which enables responders to distribute data messages by recipient, geographic area, or other specifications such as discipline type. The EDXL suite also will include the Resource Messaging (RM) and Hospital AVailability Exchange (HAVE) standards, which are expected to be ratified by the Organization for the Advancement of Structured Information Standards later this year. The RM standard will enable responders to exchange resource data such as personnel and equipment. The HAVE standard will enable responders to exchange information about a hospital's capacity and bed availability with medical and health organizations..." [source PDF]

  • [August 18, 2008] OIC Data Messaging Standards Guide for Requests for Proposals (RFPs). From U.S. Department of Homeland Security Office for Interoperability and Compatibility (OIC). Prepared by the OIC Practitioner Steering Group. Announced in the 'Summer 2008' edition of Interoperability Technology Today. 13 pages. Latest version is available from SAFECOM, a communications program of the Department of Homeland Security (DHS). Summary from SAFECOM announcement: "Developed with practitioner input, this guide is intended to assist procurement officials who develop RFPs for emergency response information technology systems. The language provided in the guide requires manufacturers to incorporate Emergency Data Exchange Language (EDXL) messaging standards into their products. EDXL standards enable emergency responders to share critical data — such as a map, a situational report, or an alert — seamlessly across disparate software applications, devices, and systems. Effective exchange of this type of data is essential during emergency response operations." This document provides an overview of the EDXL messaging standards to give technical staff a more detailed summary of the standards. OIC partners with industry to encourage the implementation of standards into software and systems. Industry will be more active in implementing standards into its systems if procurement officers include specific language in RFPs — language that requires systems to use data messaging standards. This increased implementation of data messaging standards will in turn enhance the ability of emergency responders to seamlessly share information across jurisdictions and disciplines... The goal of the EDXL standards is to facilitate information sharing and data exchange across local, tribal, state, Federal, and non-governmental organizations of different disciplines that provide emergency response and management services. EDXL accomplishes this goal by focusing on the standardization of specific Extensible Markup Language (XML) messages that are exchanged between two or more systems to facilitate emergency communication and coordination. EDXL is a suite of emergency data messaging standards which include but are not limited to the following functions: alerting, resource queries and requests, situation status, hospital and resource availability, and message routing. EDXL focuses on crossdisciplinary, cross-jurisdictional information exchange related to emergency response. Described below are the currently approved and adopted standards — the Common Alerting Protocol (CAP) and Distribution Element (DE). In addition, an overview of two standards pending approval, the Hospital Availability Exchange (HAVE) and Resource Messaging (RM), are also described, along with the functions they support, for your future procurement planning purposes. The implementation of EDXL data messaging standards will result in a system or application that will help responders respond to and manage incidents more effectively and will help save lives..." [source PDF]

  • [July 31, 2008] CAP Implementers Workshop at World Meteorological Organization (WMO). Announcement from Eliot Christian, (WIS Senior Scientific Officer, World Meteorological Organization - WMO). "I am writing to organizations that may be interested to participate in a two-day CAP Implementers Workshop... The Common Alerting Protocol (CAP), an OASIS standard adopted as ITU Recommendation X.1303, is the foundation standard for all-media public warning. Designed as an all-hazards alert format, CAP is being implemented worldwide for earthquakes, public health, and many other emergencies, in addition to weather events... This Workshop is planned for 9-10 December 2008 at the WMO (World Meteorological Organization) in Geneva, in cooperation with OASIS and ITU. It will be primarily a forum for discussions among CAP implementers and ICT or emergency management organizations on topics requiring coordination. These topics may include, among others: having an internationally agreed list of authorities for common types of CAP alerts; disseminating, aggregating, and authenticating CAP alerts; making globally unique identifiers for CAP alerts; and, best practices for text in the CAP "description" and "instruction" elements. You may be aware that this Workshop follows on the October 2006 'Workshop and Demonstration of Advances in ICT Standards for Public Warning' held at ITU in Geneva. Since that 2006 Workshop, there have been notable developments" [in the advance of the CAP Standard and related work of the OASIS TC...]

  • [July 30, 2008] "FEMA Announces Intention to Adopt Common Alerting Protocol 1.1." Announcement July 30, 2008. "The Department of Homeland Security's Federal Emergency Management Agency (FEMA) has announced its intention to adopt during the first quarter of calendar year 2009, an alerting protocol in line with Common Alerting Protocol (CAP) 1.1 as the standard for the Integrated Public Alert and Warnings System (IPAWS). IPAWS is a network of alert systems through which FEMA is upgrading the existing Emergency Alert System (EAS). CAP 1.1 is a format for exchanging emergency alerts allowing a consistent warning message to be disseminated simultaneously over many different warning systems. Participants in the EAS, including broadcasters and state and local emergency managers, will be required to be in compliance with CAP 1.1 standard within 180 days of its formal adoption by FEMA. "Arriving at standards and protocols that work for everyone is a complex process," said Martha Rainville, assistant administrator of FEMA's National Continuity Programs Directorate. "But FEMA intends to formally adopt and publish a profile in line with CAP 1.1 early next year. We are working closely with partners across the government, private sector and non-profit community to develop a CAP profile that ensures the interoperability needed to deliver alerts and warnings to more people in more locations through more paths." FEMA's partners in developing CAP profiles include the National Weather Service, Federal Communications Commission, the DHS/Science and Technology Directorate's Command, Control and Interoperability Division; Emergency Interoperability Consortium; Organization for the Advancement of Structured Information Standards; and the International Association of Emergency Managers..." See also the news story "OASIS/ITU-T Common Alerting Protocol (CAP) Receives Support from FEMA and WMO".

  • [July 22, 2008] Comments of the Society of Broadcast Engineers (SBE) Before the Federal Communications Commission. On Licensing of the 700 MHz Band D Block Spectrum and Creation of a Nationwide, Broadband, Interoperable Public Safety Network. WT Docket No. 06-150, PS Docket No. 06-229, DA 08-1194. Signed by: Barry Thomas (President) and Christopher D. Imlay (General Counsel). Comments Submitted by Society of Broadcast Engineers (SBE) on June 18, 2008.

    Excerpt: "The interest of SBE in this proceeding is with respect to the improvement and enhancement of the Emergency Alert System in the United States... While the EAS system has served us well over the last 12 years, the Commission, in its Second Report and Order and Further Notice of Proposed Rule Making, 22 FCC Rcd. 13275 (2007) in EB Docket No. 04-296, established the basis for a new and improved Emergency Alert System taking advantage of the recently developed Common Alert Protocol (CAP) as a method of providing better emergency information quickly and reliably through all warning systems. The Commission's rules on the implementation of CAP into the EAS system are dependent on work by the Federal Emergency Management Agency (FEMA). FEMA was tasked to define and adapt CAP 1.1 and CAP Protocols and how they will be used to improve the President's ability to reach all American citizens. The goal as SBE perceives it is to enhance EAS, so that it can be an effective public warning system to complement and integrate with a growing number of other warning systems...

    In the original EAS system, short data codes for events, locations, and times of emergency, etc. had to be compressed in the 512-baud FSK protocol and transmitted in seconds as a relay from station to station. While that relay system has performed well, it will not support the data throughput required for CAP-Enhanced EAS. For example, an EAS message for an AMBER alert (event code CAE) indicates that an AMBER alert has been issued in a particular area for a particular time. The current EAS data burst does not contain any information about the description (or photo) of the abducted child, possible routes of travel, vehicles of interest, etc... With a CAP-Enhanced EAS, it will be possible to transmit messages with much more detail and specificity, not only for AMBER alerts, but also for severe weather situations and local emergencies where people at risk need timely details so they can take proper protective action. A CAP message may contain hundreds or thousands of characters of information. At the 512 baud FSK data rate, transmitting such messages over the main channel of radio TV and cable facilities will take minutes, and will necessitate the airing of highly annoying data bursts. These transmissions can and do drive away listeners and disrupt the station's ability to quickly send audio alerts regarding the emergency at the exact time these services are most needed. It is therefore imperative that CAP messages from the emergency activation centers, be they federal, state or local, get to the broadcasters via a back channel multipoint distribution system instead of being relayed station-to-station as is now the case... The challenge for an Enhanced EAS is to distribute these CAP messages from the emergency activation points at the federal, state or local level to the broadcasters and cable operators and finally to the public...

    The Society of Broadcast Engineers respectfully requests that the Commission set aside a total of just 100 kHz in the D block spectrum; i.e., 50 kHz from the D block spectrum in the lower band, and 50 kHz from the D block spectrum in the upper band, exclusively for the Emergency Alert System nationwide... Further, SBE suggests that setting aside this limited amount of EAS support spectrum is quite obviously in the public interest, as it will enable the rapid and proficient deployment of CAP on a nationwide basis and improve the efficiency and performance of the EAS..." archive/cache version]

  • [July 22, 2008] Society of Broadcast Engineers (SBE) Strategy for Impementing CAP EAS. May 2008. Referenced from the SBE web site document "SBE and EAS Issues." Contact: Clay Freinwald (SBE EAS Committee Chairman). "To aid implementation of CAP technology for a revised Emergency Alert System (EAS), the Society of Broadcast Engineers (SBE) has prepared for consideration a suggested working groups outline with possible tasks to be assigned. The SBE will offer its volunteer member services as appropriate on relevant working groups that relate to the interests of our members... [This document describes a proposed] EAS CAP Profile Working Group to develop the EAS CAP Profile to be mandated by FEMA for use in every state, regardless of distribution means, to ensure interoperability among states and devices. The WG: (1) Designates where each EAS parameter goes in EAS CAP message; (2) Decides - should EAS parameters be sent as discrete values rather than decoder interpolating value? (3) If DEAS has already addressed EAS parameter assignment, look at that; (4) Designates how the Governor's message will be identified; (5) Designates how the Governor's geo-targeted local alerts will be formatted; (6) Develops authentication and security features for EAS CAP messaging; (7) Analyzes whether data inserted into required CAP fields must be standardized; (8) Analyzes whether other CAP features, such as Exercise, Test, Update, Cancel, and Language, can be implemented in EAS CAP; (9) Strives for compatibility with the HazCollect CAP Profile; (1) Coordinates with NWS to ensure that any new EAS CAP Profile can be accepted at NWS for use in generating ongoing NWR SAME alerts to the current generation of NOAA Weather Radios now in use by the public..." Other Working Groups identified: EAS CAP FCC Rules/FEMA Directives Study WG; EAS CAP Equipment WG; EAS CAP Training WG; EAS CAP On-Air Presentation WG; EAS CAP Distribution Network WG. [cache/archive: PDF and canonical .doc]

  • [July 02, 2008] "Will the EAS House Be Put in Order? Questions Persist About Funding and Timing of a Next-Generation System." By Randy J. Stine. From (July 02, 2008). "Moving too slowly for some but not wanting to rush, Federal Emergency Management Agency officials believe the process to develop the next generation of the Emergency Alert System is on track. They expect to announce a position on adopting the Common Alerting Protocol by the end of July [2008]. Many broadcasters and those in the emergency management arena are pushing FEMA to adopt CAP formally as the official data protocol for creating and sending emergency messages. The Federal Communications Commission has given its provisional endorsement of CAP. However, the commission's 2007 Second Report and Order on EAS stipulated that broadcasters would have 180 days to adopt whatever EAS protocol FEMA develops... Experts say CAP is just one of several concepts being considered by FEMA, but the most likely to be chosen... Monumental changes are coming to EAS, and FEMA officials say they are doing their best to assemble the multiple layers and parts, including cellular alerts via the Commercial Mobile Alert System, which also features FEMA in the prime development role... Despite the size of the undertaking, some in broadcasting say it is imperative that FEMA takes definitive steps this year towards CAP implementation. 'FEMA needs to lead or get out of the way,' said Art Botterell, an architect of CAP Version 1.1, which is already being used by some states for emergency warning. Bollerell is recommending that FEMA implement CAP in two phases. A simple introduction of CAP-based messaging using the current EAS Specific Area Message Encoder (SAME) infrastructure should come first... FEMA says it is moving slowly so as to accommodate all elements of the new system and because it wants to develop an approach that really works. The goal is an inclusive, interoperable system, they say. The Society of Broadcast Engineers has offered FEMA help, saying it is willing, if asked, to form working groups to develop a strategy to implement CAP... FEMA, which has yet to release CAP-to-EAS specs, was designated as the lead federal agency by President Bush to develop new methodology for public warning in this country. Specifically, FEMA's Integrated Public Alert and Warning System is viewed as the integration vehicle to bring disparate warning systems under one protocol..."

  • [June 18, 2008] SBE Files Comments on 700 MHz D Block Spectrum Regarding EAS "On June 18, 2008, the Society of Broadcast Engineers submitted comments to the FCC relating to the Commission's pending proceeding regarding the re-auction and licensing of the 700 MHz D Block spectrum and creation of a nationwide, broadband, interoperable public safety network. The interest of SBE in this proceeding is with respect to the improvement and enhancement of the Emergency Alert System (EAS) in the United States. SBE's comments were written by members of the Society's FCC Liaison and EAS committees and the positions reflected in the comments were approved by the Society's board of directors. If you have questions or comments regarding SBE comments, please direct them to Chris Imlay, SBE General Counsel and interim chairperson of the FCC Liaison Committee, or to Clay Freinwald, chairperson of the SBE EAS Committee. See details in the separate entry.

  • [May 23, 2008] SBE Offers Plan to Help FEMA Move on CAP." "Frustrated by the lack of progress by FEMA, the Society of Broadcast Engineers offered a preliminary strategy to help move CAP (Common Alerting Protocol) from FEMA's offices to broadcast stations and emergency operations centers. SBE EAS Committee Chair Clay Freinwald and other SBE members offered the plan at the FCC EAS Summit Tuesday, where some panelists blasted FEMA for dragging its feet in mandating CAP, leaving broadcasters, vendors, and public safety officials hanging. An FCC order last May gave broadcasters a 180-day timetable to comply with an alerting protocol as soon as FEMA decides on the spec. Most of the EAS community leans toward CAP Version 1.1, a spec already in use in some state networks. The CAP spec would then be central to a next-generation multiplatform nationwide system of emergency notification networks to replace the current patchwork system of alerts. The SBE proposes an advisory committee, working groups, the establishment of goals and timelines, and a final report to the FCC and FEMA. The strategy includes setting up working groups. One group would develop the CAP Profile that FEMA would mandate for use in every state. That mission would include development of security and authentication features and coordination with the HazCollect CAP Profile, the National Weather Service and the National Oceanographic and Atmospheric Administration. Other working groups would tackle distribution networks; on-air presentation; training; equipment; and on FCC and FEMA rules and directives... Art Botterell, an architect of CAP now managing the community warning system for the Sheriff of Contra Costa County (Calif.), and others called on FEMA to hurry up already with the CAP declaration so states and local authorities can move forward with their local emergency notification plans and broadcasters and governments can make the necessary technology investments. Botterell said California emergency operators already have a network with a CAP-based architecture, with connections to multiple sources of information and the flexibility to localize messages over cable and telephone landlines. Several other states also have working emergency notification plans that use CAP..."

  • [January 22, 2008] CAP EAS/NWR Profile. Reference document from The CAP Cookbook — a collection of application notes, supporting documents and commentaries about the Common Alerting Protocol. "A key characteristic of the Common Alerting Protocol (CAP) is that it can be used to include and extend existing warning technologies as part of a larger integrated public alert and warning system. The two most widely deployed public alerting systems in the U.S. at present are the broadcast-based Emergency Alert System (EAS) and the VHF National Weather Radio (NWR) network operated by NOAA. Both of these systems use the Specific Area Message Encoding (SAME) data format for automatic triggering of audio broadcasts. [SAME is the protocol used to encode the Emergency Alert System in the U.S. for broadcast stations. It was originally created for NOAA Weather Radio by the National Weather Service, and was later adopted by the FCC for regular broadcasters on radio, television, and cable, as well as by Environment Canada for its weather radio service.] While CAP is not limited to the very low-speed transmission scheme used in SAME, and therefore can provide even more precise targeting and more detailed description of alerts, it frequently is useful to include the data from a SAME "data header" within a CAP XML message. There are several possible approaches to including the SAME data within the CAP message structure. One obvious method is to include the entire SAME data string within a 'parameter' structure. This method is simple, but has the disadvantage of not putting geospatial and topical information in the appropriate sections of the CAP message. This dislocation can lead to ambiguities and lost information, especially in more complex (e.g., multi-targeted or multi-phased) CAP messages..."

  • [May 08, 2008] "Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)." IETF Internet Draft 'draft-rosen-sipping-cap-01.txt'. May 7, 2008; expires November 8, 2008. 12 pages. Edited by Brian Rosen (NeuStar, Inc), Henning Schulzrinne (Columbia University, Department of Computer Science), and Hannes Tschofenig (Nokia Siemens Networks). Produced by members of the IETF Session Initiation Proposal Investigation (SIPPING) Working Group, part of the IETF Real-time Applications and Infrastructure Area. "The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. This document allows CAP documents to be distributed via the event notification mechanism available with the Session Initiation Protocol (SIP). RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification defines a SIP extension for subscribing to remote nodes and receiving notifications of changes (events) in their states. It leaves the definition of many aspects of these events to concrete extensions, known as event packages. This document defines such an event package: 'common-alerting-protocol'. Additionally, RFC 3903 Session Initiation Protocol (SIP) Extension for Event State Publication defines an extension that allows SIP User Agents to publish event state. According to RFC 3903, any event package intended to be used in conjunction with the SIP PUBLISH method has to include a considerations section... We define a new 'common-alerting-protocol' event package. Event Publication Agents (EPA) use PUBLISH requests to inform an Event State Compositor (ESC) of changes in the common-alerting-protocol event package. Acting as a notifier, the ESC notifies subscribers about emergency alerts and public warnings... All subscribers and notifiers of the 'common-alerting-protocol' event package must support the 'application/common-alerting-protocol+xml' data format. The SUBSCRIBE request may contain an Accept header field. If no such header field is present, it has a default value of 'application/common-alerting-protocol+xml' (assuming that the Event header field contains a value of 'common-alerting-protocol'). If the Accept header field is present, it MUST include 'application/ common-alerting-protocol+xml'... This memo also therefore registers the 'application/common-alerting-protocol+xml' MIME type..." [source]

  • [May 01, 2008] "Review of Emergency Management Information Standards." Draft Version 01. Edited by Sai Sun (NICTA) and Renato Iannella (NICTA). 2-May-2008. Renato Iannella (National ICT Australia - NICTA and co-chair of the W3C Emergency Information Interoperability Framework Incubator Group) announced the availability of an early draft review of five EM standards (CAP, EDXL-*, C/TWML). The idea is to review the common aspects of these specifications and the various mechanisms used to express similar semantics. "This document is a first attempt to review and analyse the current state-of-the-art in vocabularies used in emergency management information standards. It will facilitate emergency information sharing and interoperability across different systems, organizations and countries. The standards reviewed by this document [include] Common Alerting Protocol (CAP), Emergency Data Exchange Language — Distribution Element (EDXL-DE), Emergency Data Exchange Language — Resource Messaging (EDXL-RM), Emergency Data Exchange Language — Hospital Availability Exchange (EDXL-HAVE), Cyclone Warning Markup Language (CWML), and Tsunami Warning Markup Language (TWML). These standards aim to build on XML-based standard messages for emergency information systems. However, because of diverse intentions and application areas, the standards support overlapping semantics and different structures... Among the standards, EDXL-DE focuses on the information to distribute and route the emergency messages, rather than the semantics of the message itself. Contrarily, the other standards pay more attention to 'content' of the message, such as the emergency hazard, the community situation or the system response. Thus, EDXL-DE may be thought of as a 'container' for emergency messages. It provides the information to route 'payload' message sets (ie the other standards), by including key routing information such as distribution type, geography, incident, and sender/recipient IDs. CAP, CWML and TWML are all standards to describe emergency alerts or advisories. CAP is intended to provide a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. Whereas, CWML is specially designed for describing cyclone warnings and TWML is for tsunami bulletins. CWML and TWML have common similarities as they where developed in close cooperation. EDXL-RM defines separate and specific message types supporting the major communication requirements for allocation of resources across the emergency incident life-cycle. EDXL-HAVE is an XML specification that allows the communication of the status of a hospital, its services, and its resources (e.g., beds). Both EDXL-RM and EDXL-HAVE belong to the category of emergency response messages." The chartered mission of the Emergency Information Interoperability Framework Incubator Group, part of the W3C Incubator Activity, is to review and analyse the current state-of-the-art in vocabularies used in emergency management functions and to investigate the path forward via an emergency management systems information interoperability framework. These activities will lay the groundwork for a more comprehensive approach to ontology management and semantic information interoperability leading to a proposal for future longer-term W3C Working Group activity. See the EIIF Wiki for more incormation. [cache, version 01]

  • [January 17, 2008] "U.S. National Weather Service Starts Multi-Phase CAP Improvement Project." By Herb White. NOAA National Weather Service (NWS) Aware Report. This article was published in the 2008/Volume 1 NOAA NWS Aware Report by Herb White, NWS Dissemination Services Manager. [An earlier article] "described the proposed addition of Instruction Field 'markers' into NWS WMO-formatted text Watch/Warning/Advisory/Statements (W/W/A/S). The proposal is not intended to make W/W/A/S products into Common Alerting Protocol (CAP) formatted messages or even move in that direction. Rather, it is needed to improve NWS production of the separate suite of CAP messages by early 2009 to include distinct event 'Description' and 'Instruction' elements. Without a marker, there is no reliable way to parse the CAP Instruction element from existing WMO-formatted text products and create a separate CAP Instruction element. This proposal is the only change to existing NWS products enabling CAP message production. NWS has an experimental Webpage that provides reformatted W/W/A/S products in Extensible Markup Language (XML) for various feeds and displays. These CAP messages have not been satisfactorily formatted. World Meteorological Organization (WMO) formatted products do not provide information needed to populate certain CAP fields. To aggressively respond to the urgent need for standardized CAP compliant message format for NWS W/W/A events, NWS has started a multi-phased project with some tasks progressing in parallel. NWS will request public review and comment on proposed improvements shortly. NWS will improve the experimental CAP-formatted messages and continue to make them available online. At the same time, NWS will develop the Next Generation Warning Tool (NGWT) that will generate CAP messages in native format. NGWT will deliver AWIPS W/W/A applications through a more standardized approach than currently used. NGWT will modularize the applications. This will allow warning applications to be flexible enough to respond to changing technologies and user requirements. Products issued using the new NGWT will be formatted for transmission on NOAAPort, the NWWS, and NWS Webpage... This CAP solution will provide numerous benefits [including]: (1) Partners will have XML/Keyhole Markup Language formats to enable use of NWS products in better ways, such as with Geographic Information System applications. In addition XML reduces the cost of entry for NWS partners to parse and use NWS local products; for example, rip currents alerts will be available in standard national formats. (2) CAP will enhance government's "situational awareness" at the state, regional and national levels by providing a continual real time database of all warnings, even local ones. Local warnings in CAP, unavailable to state and local officials at present, could be crucial to the timely evaluation of certain threats, like biological terrorist attacks, which are most readily identified by detecting patterns in local responses... A future Aware article will describe how NWS CAP initiatives relate to other CAP initiatives in and outside the federal government..."

  • [January 10, 2008] FEMA NIMS Recommended Standard List. January 2008. "A fundamental responsibility of the FEMA Incident Management Systems Integration (IMSI) Division is to identify guidelines, protocols, and standards that will help emergency managers and responders from all levels of the public and private sectors organize effective responses to emergency incidents and planned events. In support of that mandate, IMSI produces an annual Recommended Standards List (RSL) that describes voluntary consensus standards that support the implementation of the National Incident Management System (NIMS). The listing includes [i] Preparedness and Incident Management Standards and [ii] Communications and Information Management Standards. In the latter category: (1) American National Standards Institute (ANSI) INCITS 398-2005 Information Technology — Common Biometric Exchange Formats Framework (CBEFF) — "The Common Biometric Exchange Formats Framework (CBEFF) describes a set of data elements necessary to support biometric technologies in a common way. These data elements can be placed in a single file used to exchange biometric information between different system components or between systems themselves." (2) Institute of Electrical and Electronics Engineers (IEEE) 1512-2006: Standard for Common Incident Management Message Sets for Use by Emergency Management Centers — "This family of standards addresses the exchange of data on transportation-related incidents above the field level for Emergency Operations Centers (EOCs) and other Multi-Agency Coordination Systems (MACS) components. These standards utilize message sets that are described using Abstract Syntax Notation One ('ASN.1') Syntax or XML formats. (3) National Fire Protection Association (NFPA) 1221: Standard for Installation, Maintenance, and Use of Emergency Services Communications Systems (4) Organization for the Advancement of Structured Information Standards (OASIS) Common Alerting Protocol v1.1 (5) Organization for the Advancement of Structured Information Standards (OASIS) Emergency Data Exchange Language (EDXL) Distribution Element v1.0... See the source and reference document.

  • [November 27, 2007] "Common Alerting Protocol (CAP): The Content Standard of Alerts and Notifications in Disasters and Emergencies. [Alternate Title: Common Alerting Protocol for Hydrometeorological.] Presented byEliot Christian (Consultant to WMO, Volunteer with the U.S. Geological Survey).NMHSs' Participation in Disaster Risk Reduction Coordination Mechanisms and Early Warning Systems Geneva, Switzerland. Conference ITEM 7: NMHSs and Other Stakeholders' Role in Early Warning Systems with Multi-Hazard Approach. WMO Disaster Risk Reduction (DRR) Programme. 26-28 November 2007. WMO Headquarters, Geneva, Switzerland. "People who are properly alerted can reduce damage and loss of life. But, warnings must be timely; they must be clear; they must be communicated effectively. When data shows a volcano threatening a dangerous eruption, emergency managers must quickly warn the public — disseminating alerts and crucial data. Given today's amazing information and communications technologies, our challenge is to improve public warning— so that a clear and timely warning reaches everyone who needs it, and such a warning only goes to those who actually need it. CAP defines the structure of alert messages with the elements essential for public warning. For instance, CAP uses coded values for: date/time, area, urgency, severity, and certainty. CAP uses text for a short headline, an event description, and instructions on what to do. These free-text elements can be carried in as many languages as needed. The CAP standard format addresses the crazy patchwork we have today: different message formats for each kind of event, and different message formats for different media as well. Weather alerts on television are different from earthquake alerts on pagers; both are different from traffic alerts on highway signs. And, volcano alerts were not only different than other events — volcano experts had different formats for different volcanoes around the world... Early Warning focuses on predicting or detecting a hazard event before it becomes an immediate threat. Public Warning focuses on communicating to people about a hazard event that is an immediate threat. In hazard detection or prediction, different techniques are needed for different events--typhoon, tsunami, volcano, etc. But, after an alerting authority makes the decision to warn, the communications issues are much the same across types of events. This is where standardization can be so effective: Public warning systems carry all kinds of alert messages, and CAP should be the standard format for all of them. The CAP standard (1) Is compatible with legacy as well as newer transports — WMO messages, news wires, digital TV, Web Services... (2) Includes flexible geographic targeting; (3) Defines phased and delayed effective times, including expiration time; (4) Has message update and cancellation features; (5) Includes the option for inline digital images and audio. CAP has had significant uptake, with many implementations already. Early CAP adopters include private companies as well as government agencies. Even hotel chains have an interest in public warning. WorldSpace, a commercial satellite service provider, markets a CAP-based product specifically designed for hotels. Microsoft's 'MSN Direct' delivers data to radios, home appliances, and in-car navigation devices, using 250 FM towers in the US and Canada. This data includes gas station prices, movie times, sports, and stock quotes, as well as CAP alerts for weather, traffic, and public safety... Cautions about Public Warning: Emergency management processes should provide for human judgment between detection of a threat and issuing public alerts. Where alerting involves existing operational systems, pilot implementations should be in parallel with current operations, to minimize confusion and service disruption. For instance, the U.S. National Weather Service continues to transmits traditional messages although their CAP alerts are now the greatest share of downloads. Recently, the Weather Channel wrote to the National Weather Service insisting that official weather messages be in CAP format. Authentication of senders and targeted receivers is essential. Authorities should have their messages 'digitally signed', using PKI or equivalent technology. Also, alerting systems can become targets for deliberate misinformation or denial-of-service attacks. For these reasons, alerting authorities should look at high-performance, high-reliability Web hosting with full authentication. Any official source worldwide can now take advantage of commercial offers to mount copies of authoritative, authenticated, public alerts in CAP format on the Internet, at no charge. For example, the Google Earth network provider makes this offer, and they support the most powerful and reliable Web services in the world. For developing nations especially, such free hosting offers remove a major barrier to effective public warning..." [archive/cache]

  • [October 2006] "Information Standards for Disaster Response and Recovery." Karen Robinson and Renato Iannella (National ICT Australia - NICTA, Queensland Research Laboratory). Presented at the Seventh Australian Tropical Cyclone Coastal Impacts Program Workshop, Cairns, October 2006. Related references may be found in Iannella's CV. "Effective communication and information management are key aspects of disaster response and recovery, and are prime candidates for ICT support in the form of software such as Crisis Information Management Systems (CIMS). However, such systems are not yet in use today in most of the emergency sector, and uniform adoption of a single CIMS across the many organisations involved in disaster response and recovery is unlikely. Therefore, standards that formalise the semantics of the information, facilitate its exchange between various information systems, and support transformations between one format/presentation to another, are crucial. In this abstract, we provide a brief overview of work on standards for information modelling and exchange in the emergency sector... The development of structured information formats — such as EDXL-RM, TWML and CWML — provides crucial underpinnings for future software tools such as CIMS. Although some software solutions for emergency management do already exist, such as WebEOC, this software lacks open, standardised information formats that support interoperability. Therefore, these solutions break down unless they are uniformly adopted across all organisations in the emergency sector. In addition to our work on standards, we are developing an architecture (CAIRNS) for more flexible management and exchange of information for disaster response and recovery..." [archive copy]

  • [July 25, 2006] Tsunami Warning Markup Language (TWML). A Standards-based language for Tsunami Bulletins. By Renato Iannella (Principal Scientist & Program Leader, National ICT Australia - NICTA) and Karen Robinson (National ICT Australia - NICTA). Version 1.0. 52 pages. Posted to the mailing list of the OASIS Emergency Management Technical Committee. Currently, the tsunami warning centres [Hawaii PTWC; Alaska WC/ATWC; Japan (NWPTAC] issue tsunami bulletins in a textual format. There are some variations in the content and format of the bulletins issued by the three centres. For example, the WC/ATWC issues separate public and standard tsunami bulletins, unlike the PTWC and NWPTAC, while the NWPTAC provides more detailed wave activity predictions than the PTWC and WC/ATWC. The bulletins are currently disseminated using a heterogenous set of communications services, including dedicated data and voice lines, satellite broadcast, email, fax and telex. The recipients of the bulletins include meteorological service offices and weather forecast offices, airfield facilities, weather forecast subscribers, emergency service agencies, government agencies and academic institutions. This document seeks to establish structured semantic data models for tsunami bulletins. The benefits of structured semantic data models include: (1) less ambiguity of tsunami bulletin contents than with purely textual bulletins, as elements of structured documents can have well-defined semantics; (2) improved consistency of bulletins across the different tsunami warning centres; (3) improved opportunities for machine processing of bulletins, allowing bulletins to be generated, checked/validated, disseminated, combined/aggregated with related information, and mapped to visual (or other) presentations suitable for decision makers and the public in a more efficient manner, allowing crucial information to reach the affected public faster. The draft illustrates the use of EDXL-DE (Emergency Data Exchange Language (EDXL) Distribution Element) as an example distribution mechanism. The authors anticipate that the language will be used with EDXL-DE and and the OASIS Common Alerting Protocol (CAP) Standard. In this draft, selected concepts are also used from the Open Geospatial Consortium's Geography Markup Language specification such as GML Points for describing locations, to facilitate integration with mapping and geospatial systems (so that, for example, the observations and predictions contained in a bulletin can be automatically plotted on a map). The TWML XML schema imports the namespace [RDDL namespace document] for GML — the Geography Markup Language, and the editor notes that addtional use of GML is planned for the next release of TWML. [source PDF]

  • [August 30, 2005] "Justice Issues Fusion Center Guidelines." By Alice Lipowicz. From Washington Technology (August 30, 2005) "The US Justice Department has released its first Fusion Center Guidelines making recommendations about the centers' law enforcement role, governance, connectivity standards, databases and security. The 125-page document, released August 23, 2005 was developed by the Office of Justice Program's Intelligence Fusion Center Focus Group, with representation from Justice, Homeland Security and FBI, and from state and local agencies. Additional fusion center guidance is expected in the coming weeks for public safety agencies and the private sector. Related to IT needs, the report specifically recommends use of the Global Justice Extensible Markup Language (XML) data model [GJXDM]. DHS this year adopted the Global Justice standard as the basis of its forthcoming National Information Exchange Model, expected in 2006. In addition, the report recommends the Common Alerting Protocol (CAP) standard for messaging ratified by the Organization for the Advancement of Structured Information Standards (OASIS), a standards organization. The Common Alerting Protocol provides a common standard for writing messages pertaining to emergency events and disasters. It was developed by a working group of emergency managers and industry IT experts, and has been endorsed by the Federal Emergency Management Agency..." See also the document.

  • [June 07, 2005] "Agencies Move to Fine-Tune Emergency XML." By Alice Lipowicz. From Washington Technology (June 07, 2005). "A group of emergency management agencies and IT industry representatives, including the Federal Emergency Management Agency, are moving to refine their XML protocol for emergency public warnings. The Common Alerting Protocol (CAP) is a standard message format for emergency alerts and notifications. It is interoperable with many types of messaging software, making it easier to send a single message to a variety of recipients quickly. The Emergency Interoperability Consortium, composed of government and industry emergency management groups as well as FEMA, wrote the protocol in 2003. It was adopted in 2004 by OASIS and is being implemented by numerous federal, state and local disaster management agencies. The alerting protocol now has been updated to Version 1.1, and IT companies that support homeland security and public warning systems are invited to submit comments by July 15, 2005. In related developments, FEMA in January signed a memorandum of understanding with the consortium to develop additional Emergency Data Exchange Language (EDXL), a suite of XML standards that covers a broad variety of communications needs for emergency managers. The Common Alerting Protocol is viewed as a component of EDXL."

  • [November 15, 2004] "First Responders Seek Common Lingo: XML Serves as Base of New Language." By Diane Frank. In Federal Computer Week (November 15, 2004). "Interoperability is a hot topic in homeland security discussions, where it affects voice and data communications among first responders. Recognizing the problem, officials in the Homeland Security Department's Disaster Management e-Government Initiative Office are working with members of the Emergency Interoperability Consortium to develop an interoperability language known as Emergency Data Exchange Language (EDXL). The consortium is made up of federal, state and local agency officials and information technology industry leaders. EDXL, standards experts say, should allow emergency response officials to share information more broadly. The Emergency Interoperability Consortium is developing EDXL standards for several areas defined by the emergency response community. They include: Incident notification and situation reports; Status reporting; Resource requests and dispatches; Analytical data; Geospatial information; Identification and authentication. The EDXL standard itself is the next step in the evolution of the Common Alerting Protocol (CAP), an open standard for exchanging hazard warnings and reports..."

  • [February 2003] "A [US] National Strategy for Integrated Public Warning Policy and Capability." From Partnership for Public Warning (PPW). February 2003. Reference: PPW Report 2003-01. 45 pages. Send comments to stratplan@partnershipforpublicwarning.org by April 18, 2003. Address: Partnership for Public Warning, National Strategy, 7515 Colshire Drive, MS N655, McLean, VA 22102, USA. "PPW sponsored a workshop that was held during December 4 - 8, 2002, at the Emergency Management Institute in Emmitsburg, MD, to develop the first draft of a National Strategy. In attendance were knowledgeable representatives of many of the stakeholder groups concerned with public warning... The National Weather Service issues the majority of public warnings in the United States and has developed sophisticated warning procedures and systems. The National Oceanic and Atmospheric Administration (NOAA) Weather Wire System operated by the Weather Service and the National Warning System operated by the Federal Emergency Management Agency (FEMA) provide ways to collect and distribute warning information to emergency managers and other key personnel nationwide. The Emergency Alert System and NOAA Weather Radio provide ways to deliver warnings to some of the people at risk. A wide variety of other warning systems reach people at risk around critical facilities such as dams, chemical plants, oil refineries, and nuclear facilities. Many private businesses will deliver warnings to subscribers through telephones, wireless devices, and email. A basic problem with current public warning systems is that they do not reach enough of the people at risk and often reach many people not at risk. Few local emergency managers or first responders have effective ways to input information and warnings into these systems. Warnings from different sources are rarely available to all warning systems in a given region. Many of the systems are not interoperable. There are very few standards, protocols, or procedures for developing and issuing warnings. Warnings from different sources use different terminology to express the same issues of risk and recommended action. Even the national Emergency Alert System has increasing inconsistencies and potential points of failure due to decreased funding and failure to develop state and local plans for proper utilization. All stakeholders involved in public warning should be represented in developing an effective national public warning capability. The Federal government needs to provide leadership, but cannot do it alone. Working together in partnership, the stakeholders should assess current warning capability, carry out appropriate research, and develop the following: (1) A common terminology for natural and man-made hazards; (2) A standard message protocol; (3) National metrics and standards; (4) National backbone systems for securely collecting and disseminating warnings from all available sources; (5) Pilot projects to test concepts and approaches; (6) Training programs; (7) A national multi-media education and outreach campaign..." [cache]

  • [November 26, 2002] "Group Calls For New Disaster Warnings." By Robert Lemos. In CNET News.com (November 26, 2002). "The diffuse emergency warning systems in the United States need a revamp, which should include a mandated messaging standard, a panel of emergency-response experts concluded in a report... The panel -- formed of experts in disaster response from the government, the academic and the private sectors -- maintained that the current hodgepodge of warning systems, including the Emergency Alert System and the NOAA Weather Radio, don't work well. 'While many federal agencies are responsible for warnings, there is no single federal agency that has clear responsibility to see that a national, all-hazard, public warning system is developed and utilized effectively,' stated the Partnership for Public Warning in the report, which called for the newly formed Department for Homeland Security to take charge... The new system must be able to communicate with a variety of devices, including computers, cell phones, pagers and any new electronic gizmo, stated the report. For that reason, the report highlights XML (Extensible Markup Language), as a likely candidate, but other protocols might be desirable for noncomputing platforms. In addition, the report says messages must be able to have a unique identifier, a way to specify geographic regions for different levels of warning, and encryption methods for validating the sender of the message. The panel also called for additional research into the efficacy of such warnings, into the extent of trust that can be placed in the public as a source of information about disasters, and into the effect of a great number of false warnings on the public. Currently, a variety of alerts can be sent out using several different systems. The National Weather Service warns of dangerous weather patterns and incidents in specific areas of the country, while the U.S. Geological Survey alerts affected parts of the country of earthquakes, volcanic eruptions and landslides. The Department of Justice issues notice of criminal activities, and the Environmental Protection Agency sends out warnings concerning air and water quality..."

  • [November 25, 2002] "Developing A Unified All-Hazard Public Warning System." A Report by The Workshop on Effective Hazard Warnings. Emmitsburg, Maryland, USA. From The Partnership for Public Warning (PPW). November 25, 2002. Reference: PPW Report 2002-02. 47 pages. "The purpose of this report is to propose a national all-hazard public warning architecture and to outline some of the issues that will need to be addressed in creating such an architecture." Note: Appendix 2 'Comments On The Common Alerting Protocol' provides a review of CAP version 0.5.

  • [November 22, 2002 ] "Outdated Technology Hampers Emergency Management." By Eric Adolphe. In Washington Business Journal (November 22, 2002). "In the wake of increased security and safety concerns, the emergency management sector has suddenly found itself in the spotlight..."

  • [February 17, 2002] APCO Project 36: Statement of User Requirements. Draft for Discussion. February 17, 2002. Version 1.4. Contact: Lt. Mark T. Neebe (Boston Emergency Medical Services). APCO [Association of Public-Safety Communications Officials] Project 36, Project InterCAD: To create a standard method for CAD to CAD communications." This document provides a description of the User Requirements for Computer Aided Dispatch (CAD) to CAD system interfaces. It is intended to communicate end-user CAD interface requirements to the APCO Project 36 Technical Committee for further analysis and development of system architectures and technical interface standards. Therefore, this document takes an operational and functional perspective and does not presume a particular technical solution or architecture..."

  • [November 2000] Effective Disaster Warnings. Report by the Working Group on Natural Disaster Information Systems. Subcommittee on Natural Disaster Reduction, National Science and Technology Council, Committee on Environment and Natural Resources. November 2000. 56 pages.
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/emergencyManagement.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org