|
Everything we do is CAP CAP Cookbook -- Created by Art Botterell, considerd by many to be the "father" of the Common Alerting Protocol, this site is itself a collection of useful CAP resources. |
The Common Alerting Protocol Explained
The Common Alerting Protocol does four important things:
CAP was created by the emergency management community and is available free-of-charge to both public and private sectors. Hardware and software vendors have begun using CAP for a variety of warning-related purposes. Before the Common Alerting Protocol was invented, every warning technology had to be dealt with individually. These disparate technologies include the Emergency Alert System, NOAA Weather Radio, warning sirens, reverse 911 telephone dialing systems, email, local newswire services, law enforcement networks, statewide warning systems, pagers, electronic highway signs, low-power AM radio, and many others.
For all their differences, these technologies had something in common: Each required a specifically-formatted warning message. Issuing a warning via nine different technologies would require nine versions of the same warning message, each subtly or greatly different from the others.
This requirement for multiple messages had the effect of limiting the numbers of warnings actually issued and hampering their distribution. There was also a steep learning curve for the emergency manager seeking to use the available warning tools to protect the public.
CAP provides a single message format that unifies both current and future warning systems. It allows an emergency manager to write a single message that can be used by a variety of warning technologies. CAP makes warning systems do what they are supposed to do — including deciding whether they are supposed to do anything at all.
Precision Warning CAP allows a warning to be described with great precision, both as to the nature of the emergency and the area that needs to be warned.
Simply put, a location-aware “smart” device such as a cellular handset can “look” at a CAP message that includes lat/long information to determine whether or not the device is within or near the warning area. Hormann America's AlertNET warning creation software lets users draw a warning area on a map and then generates a set of lat/long points describing the area (in this case a circle and radius).If it is, the device responds by alerting the user.
CAP-enabled warning sirens and strobe lights can decide whether to activate based on their location relative to the warning area. Other alerting devices, such as radio and television sets, personal computers, can all be programmed to respond to CAP messages directed at their location. Likewise, the lat/long information in a CAP message can work with GIS systems, including triggering a reverse 911 system to begin making calls to telephone numbers within the specified area.
As for precision warning descriptions, besides the usual text description, CAP also requires warnings to be described as to type of emergency, the urgency of the situation, its severity, how likely the emergency is to occur, and what the recipient of the message is being asked to do in response to the warning.
This is discussed in greater detail later in this white paper, but it’s easy to see how precision descriptions combined with a precision location allow CAP messages to create highly effective warning messages.
What is the Common Alerting Protocol? The Common Alerting Protocol is an XML-based data format for exchanging public warnings and emergency messages between various alerting technologies3. The standard is maintained by the Organization of the Advancement of Structured Information Systems (OASIS), an American standards organization. (www.oasis-open.org)
The Extensible Markup Language (XML) is a specification for creating markup languages. A markup language combines text and additional descriptive information about the text. (Web pages are created in a markup language called HTML).
A markup language might describe an address as: <address>124 Main Street</address>. The extra information allows the text to be properly “understood” in a variety of applications. CAP is one example of a markup language created in XML. There are many others.
CAP allows a single warning message to be disseminated simultaneously over a wide variety of warning systems that understand and can process CAP-formatted messages. Because it is a “write-once, use everywhere” format, CAP can dramatically increase warning effectiveness even as it simplifies the task of creating and distributing the warnings messages.
The standardized alerts produced using CAP can be used by a wide range of software applications and devices, each capable of processing the message and responding appropriately. Thus, a single CAP message that appears in one person’s email inbox as text might also be converted into speech and transmitted over NOAA Weather Radio.
That same message could appear on the cellular handsets of people traveling into or through the warning area, trigger the pagers of first responders, appear as text on electronic highway signs, trigger the proper warning sirens to sound, and tell a “reverse 911” system to call residents of a precise geographic area.
As CAP becomes a global standard, emergency agencies around the world will send their messages in a common format, regardless of language. Indeed, CAP messages can be made largely language-independent, at least in terms of warning recipients that something is about to (or has already) happened.
By standardizing alert messages across all threats, jurisdictions and warning systems, CAP also can be used to detect trends and patterns in warning activity, such as those that might indicate an undetected hazard or hostile act. From a procedural perspective, CAP reinforces a research-based template for effective warning message content and structure.
CAP separates the content of a message from how the message is presented. This allows the same message to be used in many different ways.
Where did CAP originate? The National Science and Technology Council (NSTC) report “Effective Disaster Warnings” (November, 2000) recommended that “a standard method should be developed to collect and relay instantaneously and automatically all types of hazard warnings and reports locally, regionally and nationally for input into a wide variety of dissemination systems.”
In 2001 an international, independent group of over 120 emergency managers began specifying and prototyping the Common Alerting Protocol’s data structure based on the recommendations of the NSTC report. The project was embraced by the non-profit Partnership for Public Warning and a number of international warning system vendors. A series of field trials and long-term demonstration projects during 2002-2003 led to the submission of a draft CAP specification to the OASIS standards process for formalization.
The CAP 1.0 specification was approved by OASIS in April, 2004. Based on experience with CAP 1.0, the OASIS Emergency Management Technical Committee adopted an updated CAP 1.1 specification in October 2005. At a meeting in Geneva in October, 2006 the CAP 1.1 specification was taken under consideration by the International Telecommunications Union for adoption as an ITU recommendation. It was formally accepted as ITU Recommendation X.1303 in November, 2007.
CAP applications can be divided into three major classes, based on the sender and recipient of the message. Most obvious are messages sent by humans that are intended to be received by other humans. CAP also allows a message created by a human to control a device or machine.
Machines can also create CAP messages in response to some condition or in response to other messages. These machine-created messages can be sent to other devices or to human users for action.
An example of such an automatically-generated message might be alerting based on a measured condition—such as a radiation release at the nuclear power plant that, when detected, triggers a warning message to be transmitted by the sensor.
Machines can also create and distribute a CAP message to indicate receipt of a message and completion of a particular automated task. |
CAP features include:
What can CAP talk to?
|
|
|