Common Alerting Protocol: Difference between revisions

Revision as of 05:14, 11 June 2005

Latest revision as of 03:40, 13 July 2025

(207 intermediate revisions by more than 100 users not shown)

Line 1:

{{Short description|XML-based markup language}}

The '''Common Alerting Protocol''' (CAP) is a simple but general format for exchanging all-hazard emergency [[AMBER Alert|alerts]] and [[Emergency population warning|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 '''Common Alerting Protocol''' ('''CAP''') is an [[XML]]-based data format for exchanging [[emergency population warning|public warnings]] and emergencies between alerting technologies. CAP allows a warning message to be consistently disseminated simultaneously over many warning systems to many applications, such as [[Google Public Alerts]] and [[Cell Broadcast]]. CAP increases warning effectiveness and simplifies the task of activating a warning for responsible officials.

Standardized alerts can be received from many sources and configure their applications to process and respond to the alerts as desired. Alerts from the [[Department of Homeland Security]], the [[Department of the Interior]]'s [[United States Geological Survey]], and the [[United States Department of Commerce]]'s [[National Oceanic and Atmospheric Administration]] (NOAA), and state and local government agencies can all be received in the same format by the same application. That application can, for example, sound different alarms, based on the information received.

Advances in technology, and higher expectations by the public have significantly complicated alert and warning procedures. There is a vast array of systems and equipment being fielded by a multitude of agencies. Unfortunately, these systems and technologies are generally developed without regard for how other related systems and equipment function. As a result, emergency managers and decision makers are faced with the task of operating several different warning systems nearly simultaneously. The alert message is generated separately in each system, often by different people or agencies. This results in the community receiving, at minimum, inconsistently worded messages and in the worst case, conflicting warning messages. The Common Alerting Protocol was defined as a basic protocol for all warning systems. This is the first step in developing a truly integrated and seamless alert and warning system.

By normalizing alert data across threats, jurisdictions, and warning systems, CAP also can be used to detect trends and patterns in warning activity, such as trends 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.

== A Call to Action ==

The CAP data structure is backward-compatible with existing alert formats including the [[Specific Area Message Encoding]] (SAME) used in [[NOAA Weather Radio]] and the broadcast [[Emergency Alert System]] as well as new technology such as the [[Wireless Emergency Alerts]] (WEA), while adding capabilities such as the following:

The [[National Science and Technology Council]] (NSTC) report on “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 systems4.”

*Flexible geographic targeting by using latitude/longitude “boxes” 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

*Digital encryption and signature capability

*Facility for digital images, audio, and video.

==Background==

The NSTC’s recommendation is reinforced by the results of a survey conducted by Pew Internet and American Life in association with Federal Computer Week magazine about emergencies and the internet5. The report states "Everything we've seen in our research suggests that Americans want every channel of communication fired up when there are emergencies," says Lee Rainie, director of the Pew Internet & American Life Project. "They want horns sounding, radios blaring, TV screens alight with the latest information, pagers buzzing, emails sent, and Web pages updated on the fly. They don't want to have to rely on just one communications method and they don't want one channel to have special privileges over others. They want each one of them used when all hell is breaking loose." (Italics added)

The US [[National Science and Technology Council]] (NSTC) November 2000 report on "Effective Disaster Warnings" recommended that "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."<ref>{{cite web |url=http://www.sdr.gov/NDIS_rev_Oct27.pdf |title=Archived copy |access-date=2006-05-03 |url-status=dead |archive-url=https://web.archive.org/web/20060513144112/http://www.sdr.gov/NDIS_rev_Oct27.pdf |archive-date=2006-05-13 }}</ref>

In 2001, an international independent group of over 120 emergency managers that was convened online by California emergency telecommunications expert Art Botterell began specifying and prototyping the Common Alerting Protocol 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.<ref>{{Cite web|url=https://ppw.us/|archiveurl=https://web.archive.org/web/20020928072102/http://www.ppw.us/|url-status=usurped|title=Partnership for Public Warning|archive-date=28 September 2002|website=ppw.us}}</ref> A series of field trials and long-term demonstration projects during 2002-03 led to the submission of a draft CAP specification to the OASIS standards process for formalization.

== Establishing the roadmap for improvement ==

The CAP&nbsp;1.0 specification was approved by [[OASIS (organization)|OASIS]] in April 2004. Based on experience with CAP&nbsp;1.0, the OASIS Emergency Management Technical Committee adopted an updated CAP&nbsp;1.1 specification in October 2005.<ref>{{cite web |url=http://www.oasis-open.org/committees/emergency |url-status=dead |archive-url=https://web.archive.org/web/20030207195408/http://www.oasis-open.org/committees/emergency/ |archive-date=2003-02-07 |title=OASIS - Committees - OASIS Emergency Management TC}}</ref><ref>[http://www.oasis-open.org/committees/download.php/14759/emergency-CAPv1.1.pdf Common Alerting Protocol, v. 1.1] oasis-open.org</ref> At a meeting in Geneva in October 2006 the CAP&nbsp;1.1 specification was taken under consideration by the [[International Telecommunication Union]]'s [[ITU-T|Standardization Sector]] for adoption as an ITU-T recommendation. CAP was subsequently adopted as Recommendation X.1303.<ref>{{cite web |title=X.1303 : Common alerting protocol (CAP 1.1) |url=https://www.itu.int/rec/T-REC-X.1303/en |publisher=International Telecommunication Union |access-date=2019-04-30}}</ref>

The “Baby Boomer” generation grew up listening to routine tests of attack warning sirens. The use of electro-mechanical sirens was the primary mean of warning the public of a nuclear attack against the nation. In some jurisdictions, the systems were also used to issue warnings of severe weather (tornados, floods, etc.). As radio and television systems coverage grew, people immediately tuned to their local stations for more information. In order to take advantage of this mass media system, the federal government developed the [[Emergency Broadcast System]] (EBS). As digital systems were developed and fielded, it provided an opportunity to code warnings to specific states and counties. In order to take advantage of this capability, a new national warning system was developed. The [[Emergency Alert System]] (EAS) replaced EBS and provided a significant improvement in warning. We continue to see almost explosive development of technologies that can be used to broadcast emergency warnings. Sirens activated via digital signals transmitted via radio. Telephone notification systems designed call all phones in a specific area. Cellular telephones, wireless digital devices, text-based pagers are in use everywhere.

CAP specification version 1.2 has been available since July 2010 at the OASIS website.<ref>[http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf Common Alerting Protocol Version 1.2] oasis-open.org</ref>

Emergency management officials are being asked to send alert and warning messages over multiple systems, most of which use different coding schemes and activation methods. This often results in the end user receiving different messages based on what type of system is being used. It also significantly increases the workload on the individual(s) activating the various systems. As a result, at the one point in an emergency when speed and accuracy are critical, the system is designed to create multiple failure opportunities. How then, do we simplify the alert and warning tasks for emergency response officials and ensure that each recipient receives the same warning message? We develop and implement a Common Alerting Protocol (CAP).

==Implementation==

== What is the Common Alerting Protocol? ==

===Worldwide===

In 2007, the International Telecommunication Union, Telecommunication Standardization Sector (ITU-T) adopted the Common Alerting Protocol as Recommendation X.1303.<ref>{{cite web|url=http://www.itu.int/ITU-T/|title=ITU Telecommunication Standardization Sector|work=ITU}}</ref><ref>{{cite web|url=http://www.itu.int/rec/T-REC-X.1303-200709-I/en|title=X.1303&nbsp;:&nbsp;Common alerting protocol (CAP 1.1)|author=tsbmail|work=itu.int}}</ref> The recommendation annex contains an authoritative [[ASN.1]] module translation of the CAP XML schema that may be useful for some implementations. Rec. X.1303 is within the remit of ITU‑T Study Group 17 (Security), Rapporteur Group on Cybersecurity (Q.4/17) for purposes of further evolution of the standard.<ref>{{cite web|url=http://www.itu.int/ITU-T/studygroups/com17/index.asp|title=ITU-T Study Group 17 (Study Period 2013-2016)|work=itu.int}}</ref>

===Australia===

In its simplest form, CAP is an open, non-proprietary digital format for all types of alert and notifications. It’s written in [[Extensible Markup Language]] (XML) which is compatible across all operating systems. The CAP format is fully compatible with existing formats including the Specific Area Message Encoding (SAME) used for NOAA Weather Radio and the Emergency Alert System, while offering enhanced capabilities that include:

The Australian Government Standard for Common Alerting Protocol (CAP-AU-STD, 2012) was developed by a CAP-AU-STD stakeholder group comprising federal agencies [[Emergency Management Australia]], the [[Bureau of Meteorology]], [[Geoscience Australia|GeoScience Australia]], [[Department of Agriculture and Water Resources|Department of Agriculture, Fisheries and Forestry]] and the [[Department of Health (Australia)|Department of Health]] as well as a number of State Government authorities and emergency services agencies. The project was co-ordinated by the Australian Government Attorney-General's Department (Australian Emergency Management).<ref>{{cite web|url=https://www.ag.gov.au/EmergencyManagement/Emergency-management-capability/Pages/default.aspx|title=Emergency Management Capabilities - Attorney General's Department|work=ag.gov.au|access-date=2018-01-15|archive-url=https://web.archive.org/web/20180115184416/https://www.ag.gov.au/EmergencyManagement/Emergency-management-capability/Pages/default.aspx|archive-date=2018-01-15|url-status=dead}}</ref><ref>{{cite web|url=https://data.gov.au/dataset/cap-au-std|title=Common Alerting Protocol – Australia (CAP-AU-STD) - Data.gov.au|work=data.gov.au}}</ref>

===Canada===

* Flexible geographic targeting using latitude/longitude “boxes” and other geospatial representations in three dimensions;

In Canada, a working group composed of public alerting practitioners and government agencies has developed a CAP Canadian Profile (CAP-CP) based on CAP but specialized to address the needs of Canadian public alerting stakeholders, such as bilingualism, geocoding for Canada, managed lists of locations and events, etc. The Canadian government has adopted CAP-CP for its [[National Public Alerting System]] (NPAS) project. The CAP‑CP working group, along with stakeholders and projects such as the [[Canadian Public Safety Operations Organization]] (CanOps) and Netalerts' Sarnia Lambton trial, are now working with and refining CAP‑CP for national application in Canada.{{citation needed|date=June 2015}}

* 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;

* Digital encryption and signature capability; and,

* Facility for digital images, audio and video.

CAP has been implemented for a small-scale, grassroots hazard information system in [[Sri Lanka]] following the [[2004 Indian Ocean Tsunami]]. This implementation was part of the "HazInfo Project", funded by Canada's [[International Development Research Centre]].<ref>{{cite web|url=http://www.lirneasia.net/projects/current-projects/evaluating-last-mile-hazard-information-dissemination-hazinfo/|title=Evaluating Last-Mile Hazard Information Dissemination (HazInfo)|work=lirneasia.net|access-date=2007-01-31|archive-url=https://web.archive.org/web/20070709060448/http://www.lirneasia.net/projects/current-projects/evaluating-last-mile-hazard-information-dissemination-hazinfo/|archive-date=2007-07-09|url-status=dead}}</ref>

== Why CAP? ==

The province of [[Alberta]] adopted CAP as part of its [[Alberta Emergency Alert]] system. In March 2015, [[Alert Ready]], a national public warning system based upon CAP-CP, was officially launched. Participation in the system by all broadcasters and television providers is mandated by the [[Canadian Radio-television and Telecommunications Commission]].<ref>{{cite web|title=Public Alerting Bulletin to Last Mile Distributors|url=https://alerts.pelmorex.com/download/public/Broadcaster%20Bulletin%202015-03-27.pdf|publisher=Pelmorex|access-date=9 June 2015|archive-url=https://web.archive.org/web/20150506000827/https://alerts.pelmorex.com/download/public/Broadcaster%20Bulletin%202015-03-27.pdf|archive-date=6 May 2015|url-status=dead}}</ref><ref>{{cite web|title=Alberta emergency system goes digital|url=http://www.cbc.ca/news/canada/calgary/alberta-emergency-system-goes-digital-1.993701|website=CBC News|access-date=9 June 2015}}</ref><ref name=cbc-aeavoice>{{cite web|title=Digital alert system hard to decipher: critics|url=http://www.cbc.ca/news/canada/calgary/digital-alert-system-hard-to-decipher-critics-1.1032381|website=CBC News|access-date=9 June 2015}}</ref>

Warning systems in the [[United States]] today are a chaotic patchwork of technologies and procedures. Not only is there no coordination, there's no mechanism for coordination.

===Germany===

Existing nationwide systems are limited in scope both by their technological legacies and by the organizational mandates and priorities of their sponsoring agencies. In particular, none of the existing national systems are entirely suited to the needs of state, local and private emergency-information programs. As a result, dozens of different technical and operational warning systems have sprouted, seemingly at random, throughout the nation6. As we previously stated, the public expects rapid and accurate emergency warning, and they want all the various information technologies to be used to broadcast the warning. The chief benefit of CAP will be reduction of costs and operational complexity by eliminating the need for multiple custom software interfaces to the many warning sources and dissemination systems involved in all-hazard warning. The CAP message format can be converted to and from the “native” formats of all kinds of sensor and alerting technologies, forming a basis for a technology-independent national and international “warning internet.”

The Federal Office for Citizen Protection and Disaster Support (''Bundesamt für Bevölkerungsschutz und Katastrophenhilf''e, BBK) is working on an implementation based on CAP 1.2, which will allow for Internet-based access to data provided by the nation's modular warning system MoWaS.<ref>{{cite web | url = http://www.bbk.bund.de/DE/AufgabenundAusstattung/Krisenmanagement/WarnungderBevoelkerung/Warnmultiplikatoren/Warnmultiplikatoren_node.html | title = Bundesamt für Bevölkerungsschutz und Katastrophenhilfe - Warnmultiplikatoren }}</ref> The development of MoWaS is based on the satellite-based warning system SatWaS from 2001, which only provides information to less than 150 state and media entities. In case no broadcast receiver, like a radio or television, is running nearby, the resulting warning effect of SatWaS would be severely limited, because many state-run emergency sirens have been left unmaintained or were dismantled altogether. The use of CAP support in MoWaS should alleviate this problem.

===Italy===

In addition to pushing emergency data to its various warning devices, the protocol also creates a capability that allows sensors of various types (water levels, chemical detectors, wind sensors) to feed data to decision makers in a format that can be easily displayed on a computer-based situation map. An example of this capability is the Emergency Digital Information System (EDIS) used in California. An independent developer has deployed an EDIS Alert Monitoring software application that displays the various EDIS messages on a state map. Based upon the geographic information and type of warning message issued, the software draws a polygon on the map showing the affected area. By feeding information from CAP based sensors into the system, emergency manager can obtain near-real-time data and have it automatically displayed on the situation map. An example might be capturing the river level data from the California Data Exchange Center and, when river levels reach a specific level of concern, an icon appears on the map. By clicking on this icon, you’re able to read the data message from the sensor.

The Department of Firefighters, Public Rescue and Civil Defence ([http://www.vigilfuoco.it/aspx/home.aspx Dipartimento dei Vigili del Fuoco, del Soccorso Pubblico e della Difesa Civile] ) of the [[Ministry of Interior (Italy)|Italian Ministry of the Interior]] adopted the CAP protocol with two Ministerial Decrees in [http://www.vigilfuoco.it/aspx/ReturnDocument.aspx?IdDocumento=4859 2008] and [http://www.vigilfuoco.it/aspx/ReturnDocument.aspx?IdDocumento=4855 2011.] Since then, its 100 provincial control rooms, 18 regional control rooms and the national control centre exchange a daily average of 25,000 CAP private messages concerning rescue operations in real time. As per the decrees, any emergency stakeholder in Italy which wants to exchange or share data with the Fire Corps in the course of large scale emergency or rescue operations has to adopt the CAP protocol.

The first use of CAP protocol in a civil protection activity in Italy was recorded in 2009, in the aftermath of the [[Central Italy Earthquake]], when the Fire Corps exchanged data with the Ministry for Cultural Heritage to coordinate their efforts in designing and implementing provisional measures for monuments and historical buildings.

== Where are we now? ==

On April 5, 2017, an [http://www.vigilfuoco.it/aspx/download_file.aspx?id=22636 agreement] between the "Corpo Nazionale dei Vigili del Fuoco" and the "Arma dei Carabinieri" has been signed to improve the forest fire fighting activities. The interoperability of data exchange that the agreement allows is based on the use of the CAP protocol.

=== Standards Development ===

===United States===

The CAP 1.0 specification was approved by OASIS in April, 2004. The [http://www.oasis-open.org Organization for the Advancement of Structured Information Standards (OASIS)] is a not-for-profit, international consortium that drives the development, convergence and adoption of e-business standards. Members themselves set the OASIS technical agenda, using a lightweight, open process expressly designed to promote industry consensus and unite disparate efforts. OASIS produces worldwide standards for security, web services, conformance, business transactions, supply chain, public sector, and interoperability within and between marketplaces.

On September 30, 2010, the [[Federal Emergency Management Agency]] (FEMA) officially adopted CAP as the protocol for its new [[Integrated Public Alert and Warning System]] (IPAWS), which is designed to disseminate emergency messages via various platforms, including broadcast media ([[Emergency Alert System]]), wireless devices ([[Wireless Emergency Alerts]]), and other platforms.<ref name=":3">{{Cite web|url=https://www.lexology.com/library/detail.aspx?g=385a5fb7-aa83-431d-80a1-3aa45296e3db|title=FCC revises emergency alert system rules; reminds participants of June 30, 2012 CAP compliance deadline|last1=Oxenford|first1=Davis Wright Tremaine LLP-David D.|last2=Tol|first2=Jennifer|website=Lexology.com|language=en|access-date=2019-08-24|last3=Frewer|date=10 February 2012}}</ref><ref>{{Cite web|url=https://www.broadcastlawblog.com/2010/09/articles/fema-adopts-digital-message-format-for-eas-cap-standard-triggering-180-day-clock-for-compliance/|title=FEMA Adopts Digital Message Format for EAS CAP Standard, Triggering 180-Day Clock for Compliance|date=2010-09-30|website=Broadcast Law Blog|language=en-US|access-date=2019-08-24}}</ref>

== See also ==

Based on experience with CAP 1.0, the OASIS [http://www.oasis-open.org/committees/emergency Emergency Management Technical Committee] has drafted a [http://www.oasis-open.org/committees/download.php/12649/CAPv1-1.pdf CAP 1.1 specification], which was released for public comment in May, 2005.

* [[1seg]]

* [[Broadcast Markup Language]]

== References ==

=== Current Implementations ===

{{Reflist}}

==External links==

According to a "CAP 1.0 Fact Sheet," CAP implementations have been demonstrated by agencies and companies including: [[United States Department of Homeland Security]]; [[National Weather Service]]; [[United States Geological Survey]]; California Office of Emergency Services; Virginia Department of Transportation; GeoDecisions, Inc.; E Team; Blue292; Warning Systems, Inc.; Comlabs, Inc.; mobileFoundations; Ship Analytics; MyStateUSA; IEM, Inc.; Hormann America, Inc.; Oregon RAINS. Below are the details from some of the implementations:

*[https://web.archive.org/web/20160611053603/https://botterell.net/CAP/ The CAP Cookbook: Archive of early CAP documents]

*[https://web.archive.org/web/20061001162846/http://www.fema.gov/pdf/media/2006/deas_fact_sheet.pdf DEAS and Department of Homeland Security]

*[https://web.archive.org/web/20080908043938/http://www.fema.gov/pdf/emergency/ipaws/IPAWS_factsheet.pdf U.S. Federal Emergency Management Agency "Integrated Public Alert and Warning System" (IPAWS) fact sheet.]

*[http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html OASIS documentation on CAP v1.2]

*[http://docs.oasis-open.org/emergency/edxl-cap-logo/v1.0/edxl-cap-logo-v1.0.html official CAP Logos]

*[https://github.com/AT-backbone/Cap-PHP-library Cap PHP Library]

{{OASIS Standards}}

The National Weather Service (US Dept of Commerce, National Oceanic and Atmospheric Administration)"has an experimental feed of all its watches, warnings and advisories in CAP format,". See the document [http://www.nws.noaa.gov/alerts "Experimental Listings of Watches, Warnings, and Advisories,"] which "provides access to NWS watches, warnings and advisors, listed by state in three different formats. Select a state name to view a list of active alerts in your web browser. These files are updated about every two minutes. Select a state name to see the list for a state. RSS and CAP/XML lists are provided to aid the automated dissemination of this information. More information on RSS and CAP/XML formats/feeds... NWS Alert CAP messages contain the county FIPS code information for the affected county in the cap:geocode tags. Additional cross references to NWS forecast zones is available..."

[[Category:Data interchange standards]]

The State of California, Governor's Office of Emergency Services, Emergency Digital Information Service (EDIS) "delivers official information about emergencies and disasters to the public and the news media in California." EDIS has public feed for EDIS bulletins in CAP format at http://www.edis.ca.gov/cap_1.0.

[[Category:Emergency communication]]

[[Category:XML-based standards]]

[http://www.hormannamerica.com HormannAmerica, Inc.] - A specialist in warning systems, current maintainer and developer of the Contra Costa County, California Community Warning System. HormannAmerica is developing a pilot CAP Server to support the dissemination of County related Hazards CAP alerts across the county. Additionally HormannAmerica is developing a "BAMBox solution" to create alert popups on user PCs that are connected to the CAPServer networks.

[[Category:Emergency management software]]

During early 2005 the U.S. Department of Homeland Security (DHS), in partnership with the Association of Public Television Stations, demonstrated "digital EAS" broadcasts over public television digital TV transmitters and satellite links in the Washington, D.C. area and nationwide.

CAP has been selected as a foundation technology for the proposed "Integrated Public Alert and Warning System," an all-hazard, all-media national warning architecture being developed by DHS, the National Weather Service and the Federal Communications Commission. CAP is also being studied as an integrating technology for an enhanced [[Tsunami warning system]] and is cited in the [[Internet Society]]'s 2005 [[http://www.isoc.org/challenge/ "Public Warning Network Challenge"]].

== Where are we going and how can users get involved? ==

As emergency managers and responders, we need to recognize situations where a CAP application will improve warning, response, and recovery. We need to specify the inclusion of CAP capability in new and upgraded equipment. Using the open architecture of the CAP program will ensure that a consistent message is sent to the public via all available communications capabilities. It also means that officials with notifications tasks only have to send the message once.

The second task is to get the public involved. Their input and demand for the capabilities that a CAP system provides will have a bigger impact on manufactures than anything local government can do. We need to take advantage of every opportunity to educate the residents in our jurisdictions on the capabilities and advantages of an integrated, CAP based public alerting system. A clear and consistent message, sent across all available media systems will reduce the confusion that typically occurs during major emergencies.

== Summary ==

We have experienced an almost unbelievable leap in technology over the last 10 years. The public has become accustomed to receiving news and information updates virtually instantaneously. As a result, they have a difficult time understanding why it takes so long to get critical life-safety information to them accurately and in a timely manner. One of the most significant contributing factors is the fact that independent systems and technologies have been deployed without considering how, or if, these various capabilities should talk to each other. Any effort to develop a common alerting capability, must take into consideration the fact that a lot of major companies have invested huge sums of money in their own technologies. The Common Alerting Protocol’s open architecture scheme can be easily added to existing systems and incorporated into every manufactures product line. The two-way communications capability of the CAP process provides decision makers with near-real-time data. And the message “template” provided by CAP helps ensure complete and effective warning messages, even under fast-changing conditions.

Better data means better decisions. As emergency managers, we need to push for implementation of the CAP capability at every level. We also need to take every opportunity to get the public involved and demanding that a CAP capability be included in all future consumer electronics products. By requiring current and new systems to be CAP compliant, we reduce the learning curve for Emergency Responders and minimize chances of errors and reduce the amount of misinformation sent to the public.

[[Category: Emergency services]]

[[Category: Public safety]]

[[Category: Mass media]]

[[Category: Computer and Telecommunication Standards]]

[[Category: Disaster preparation]]