Common Alerting Protocol

Art Botterell

President, Incident.com

So we've got our e-mail and our EAS and our NWR.  We've got our reverse 9-1-1.  We've got our freeway signs, "Batman" has his spotlight in the sky.  We have flashers and shakers and various sorts of noise makers.  

How can we ever make any sense out of all of this?  Well, that's what I would like to talk about briefly.

Historically in the construction of warning systems, the construction has started with some technology.  We've got e-mail now, or we've got the ability to make really loud noises, or to flash lights really brightly.  And from that technology we work backwards and we build a system for collecting the messages that are going to be flashed or beeped or whatever is going to happen to them.

And this leads to two problems.  First, and this is what Cheryl mentioned before, there is no interoperability, and there is no redundancy.  Each of those systems works for itself, but as technology changes it becomes very difficult to manage that change.

I should correct myself, though.  There is one redundancy, and that redundancy occurs to the poor emergency manager who has to activate all of these different systems.  What actually tends to happen is that they have to triage the available technologies and pick which ones they have time to implement in a particular emergency which is usually not their best day to begin with. 

And regrettably, guess which systems tend to fall off the bottom of that list? 

So one of the key tasks that faces us is to separate the process of message collection from the process of message delivery.  We talk about this in terms of infrastructure and user interface.  One of the things that I've always found easiest in working with sensory disability communities, is that I think that you have a much more intuitive grasp of that distinction than most people for whom it is just kind of all comes together.  And they confuse the outward and visible sign, whether it's a pager or a siren or something happening on television from all of the mechanics in the back room.

So what I would like to do is take you to the back room for just a couple of moments.  This may seem a little bit abstract, but I hope you will agree that it's really important. 

First off, what are we trying to do?  We talk about alerting or warning as if we have defined those terms.  In fact, we haven't, and they're really hard to nail down.  But I will suggest that emergency public information has three essential components, and those are alerting, informing, and reassuring.  And working in government, of course, I had to have an acronym, and pneumonic, so we called this the AIR model.  Now, the important thing about this model is that every act of communication comprises all three of these activities sometimes to different proportions.  But no communicative act is without a degree of attention management, a degree of information transfer, and an affective or emotional payload as well.

One of the ways that we get in trouble is when we start thinking that the business we're in is merely attention management, or merely information transfer.  In fact, certainly politically when we get in trouble it's usually because we neglected that third critical reassuring component.

So it’s about obtaining information, sharing the knowledge, and then reducing the emotional obstacles to learning and acting.  Again, we're not typically speaking to people under optimal conditions.  We're speaking to them when they're either under stress or about to be under stress, and so we have to deal with sort of the ergonomics of disaster.

Very briefly, the process model that we use for emergency public information has three steps.  The first is to validate the experience, particularly post-impact.  People need to be reassured that they're not imagining things.  That they can, in fact, believe the evidence of their own eyes, ears, senses.  Even when what they're getting from those inputs is quite extraordinary and perhaps unexplained.  So first we have to confirm that people are, in fact, functioning well. 

Then we have to re-establish a bond between the victims and their own competence as actors in the world, and their connection to a community and an emergency response system.  Basically, we have to persuade people that they're better off staying in the community than slinking off to lick their own wounds which is sort of our primal impulse when injured.  And I am afraid that we saw quite a lot of that latter behavior in New Orleans where we were unable to re-establish the social bonds, and so people actually sort of opted out of society for a while.

And then we begin to convert people from victims to survivors.  How do we do this?  Well, we begin to call them to action.  We give them small things that they can do enable themselves.  This is actually sort of the symbolic value of FEMA’s only too familiar 800 number that gets published after every disaster.  Yes, it's a bureaucratic necessity.  But it's also moving people from the passive victim on whom an unfriendly universe is acting into a capable actor in that person's own world who is making a difference for themselves.  Once you begin that process, you can bring them on through greater and greater levels of self-actualization until eventually what you need to do is just get the heck out of their way.

It's not unlike raising a teenager. 

We have many of these warning tools, and all of them have value.  But we also know from the social sciences that people tend to mistrust a message that they get from a single source, if it’s incongruous.  Why is this?  Well, everybody has had the experience of a false alarm.  Nobody wants to look like they're easily panicked.  So as a result it's a pro-survival trait.  We tend to be a little conservative.

At the same time people are confused and irritated by inconsistencies in the messages.  And people are definitely annoyed by irrelevant messages.  There is a danger of them just beginning to tune out.  This is the effect that's usually labeled the "cry wolf syndrome.”  I am not fond of that particular label because I think that it has some implications that aren't exactly accurate.  But there is a danger if you bombard people with too many irrelevant warnings that they will be desensitized. 

Finally as I mentioned, the warning issuers are busy during an emergency.  What is the single most common mode of warning system failure?  Failure of anyone to activate the warning system in the first place.  Technology is very rarely the problem.  It's the decision-making process upstream that tends to break.  So one of our priorities has to be to make it easier for people to originate these warning messages that we want in the form that we want them.

We have some opportunities; the social scientists have discovered quite a lot about what makes warning messages work.  We have, of course, a heightened awareness post-9/11 of the critical role of public information in Homeland Security and also in the management of natural disasters. 

We have a new generation of warning systems almost all of which are computer controlled, and that's a huge help because that means that they can, in fact, be taught new tricks by software, which is very difficult to do when you've just got a big red switch on the wall that turns on a siren.

We have Internet and other technical standards that are making connections between different systems possible.  And we have the growing ubiquity and affordability of location information, particularly portable information devices.  So this creates a whole new realm of possibility for increasing the relevance of the warning messages that any individual receives.  We simply haven't had that before.

The missing piece?  Well, in 2000 the Office of Science and Technology Policy came out with a report called "Effective Disaster Warnings.”  It was largely a production of social science research.  But one of their findings was that a standard method should be developed to relay instantaneously and automatically all types of hazard warning and reports, locally, regionally, and nationally, for input into a wide variety of dissemination systems.

So, there is our problem statement.  The Common Alerting Protocol is an attempt to solve that.  It is an open, non-proprietary content standard expressed in XML notation, but not absolutely married, in fact, to XML, although most of the implementations that you will see will be in the XML data language.  If you don't know what that means, then don't worry about it because the point is that it doesn't really matter.  It is a content standard, okay?

It shares alerts and warnings among different technologies.  Remember how I spoke about warning messages locked into a particular dissemination channel and, therefore, they didn't really fit through a different pipe?  Well, what we tried to do with CAP was really create or identify sort of the platonic ideal of a warning, a warning in the abstract, completely independent of any particular delivery technology on the theory that then we could run that through the various filters that are applied by various technologies.

At the same time, we do have a rich technological and procedural legacy, and so we had to make sure that we had backward compatibility with the emergency alert system, with NOAA Weather Radio, sirens, telephones, et cetera, et cetera, et cetera.  We're not going to make any friends by telling people that the system that they just bought is obsolete.  And fortunately we don't have to. 

Flexible geographic targeting of alerts: Very important in improving the relevance of those messages.  We'll talk a little more about that in a moment.

Phased and delayed effective times and expirations: Frequently you want to evacuate the first three blocks by the river first, and then start another group.  (Or under some philosophies it's the other way around.)  But anyway, you may have a plan.  So you need to be able to deal with the variations in time.

Oh, here is an important one:  This was a shock to all of us, but we discovered that people occasionally screw up.  And once we got over our initial dismay, we say, well, if people do, in fact, occasionally screw up, then we better provide some mechanism for dealing with it when that happens.  So we added a capability for updating and canceling messages that have already gone out.  Anybody pay any attention to the recent evacuation of the State of Connecticut?  Well, the reality is hardly anybody else did which goes back to the weakness of single-source warnings.  We spoke about that.  It turns out that the public is not nearly as fragile as we tend to think they are.  It actually takes as fair amount to get people to move. 

And, of course, a facility for dealing with rich media.  Digital images, audio, time text, SML files, all of the rich technology.  We've got to be able to bring it all in; otherwise we've simply created the next-generation stovepipe.

The timeline:  I talked about the effective disaster warnings report in 2000.  In 2001 a group from around the world began talking about what the makeup of this should be.  There was also a non-profit organization that formed around these issues.  In 2002-03, we started doing field trials.  In 2003, CAP was rolled into the Global Justice XML Dictionary which was an incredibly important issue in Washington and probably mattered very little elsewhere except that it was a milestone bureaucratically.  In 2004, CAP 1.0 was adopted by the worldwide OASIS standards process.  In 2005 it was used in the DHS digital EAS trial and some other deployments, and based on experience some updates were added, and CAP 1.1 was actually formalized in October of this year.

It is a research-based template, provides consistent delivery, multi-lingual and special audiences, compatibility, flexible geographic and time frame targeting, and a write-it-once method for warning officials.  Let's face it, this is pretty cool! 

I want to take you through the CAP information model because this is the payload of my briefing.  Each CAP message consists of an alert block, and this identifies the sender, the message number, the time sent.  Someone had the question about can you actually converge messages from multiple sources and filter them out to reduce the repetition?  Yes, you can, if you can identify all of those as being the same message.  So this is actually, among other things, an attempt to approach that issue.

Then it contains one or more blocks of information.  The information block, or blocks, are the real payload of the CAP message.  This is where you get the who, what, when, where, why, and so what of the warning message.  It's all specified and broken out so that pieces can be cherry-picked to be fed into text warning systems, or scrolled so that you don't just get that foolish “there is a civil emergency near you,” -- tremble.

Multiple information blocks can be in a single message for a couple of reasons.  One reason is to be able to supply the message block in multiple languages.  This is, after all, an international standard so we had to look at the internationalization aspects.  Also so that you can issue a whole time-series of messages to be time-released --little time capsules of information. 

It also has the effective and expiration time.  We talked about the language designator, hazard details, contact information.  Ken Putkovich spoke about the importance of the credibility of the source, and it's very important to say who is saying all of this.

Additional technical data:  If there are parameters, the Richter magnitude, the number of kilometers under the ground, et cetera, you can put those in there.

And then you can embed two subsidiary blocks.  The first is called the resource.  This is roughly equivalent to including an attachment in an e-mail.  Any form of data can be attached to a CAP message.  Depending on the network, it can be either directly attached and moved with the CAP message, or it can simply be referred to by way of a URL so that you can retrieve those assets that are of interest to you.  If you are visually impaired, you are probably not nearly as interested in the JPEG image file as you may be in the MP3 descriptive message.  So you can actually pick the pieces that are suited to you.  

The other block is the area block, and this is where we begin to tunnel into very specific geographic notations.  Historically we’ve had to use pre-designated zones to target messages, FIPS Codes which are used in the weather emergency and radios.  You can see here on my graphic that the polygon is data from a hazardous material model from a plume of toxic chemicals.  But the irregular polygons behind it are the pre-designated alerting zones that this facility has had in place for 30 years, and it's in their regulations, and they still have to deal with it.

So the point is that we can target geographically either in terms of some explicit polygon shape if we have that, or we can refer to geo-codes, alerting zones, whatever is handy.

Applications of CAP:  There are a lot of them.  The National Weather Service has been working with CAP for something over a year.  USGS is posting their seismic data in this format.  California's state warning system is based on it.  A number of the vendors that you will find out in the lobby have implemented CAP interfaces.  The Digital Emergency Alert System is based on the Common Alerting Protocol.  

Known CAP implementers: This is another one of those eye-chart graphics.  Basically there are a bunch of them.  And what good would a slide be without a bunch of URLs?  For this audience, I would say that one that is probably most important is WWW.OASIS-OPEN.ORG.  That's the international OASIS standards body.  And on their home page there's actually a link to the CAP standard.  

Also, if you go to WWW.Incident.Com and click on CAP, you will find out all of the thrashings and working documents that we went through in the couple of years that it took to put this standard together.  

Audience member:  My concern is time lag in making decisions.  The evaluation of information, the deliberation of the information, the advice in that area.  You don't even have five minutes.  You might have one minute to find a safe place.  

So what is the time lag with this system from the time you make a decision?  

ART BOTTERELL:  That depends on the transport technology, strictly speaking.  So if it's something like e-mail that can have significant time delays, then those are the time delays.  Inherently we're talking about computer speed, fractions of seconds.  But you put your finger on where the real delay is, and that's not in the distribution of the warning but in the origination of the warning.  

Let me say two things about that, if I may.  The first is that we hope to improve that by providing people with a template -- providing emergency managers with a reliable template for what the pieces of the warning message are so that when they make the decision they can proceed with confidence without also agonizing on how they should phrase the warning.  

The other is a deeper problem.  In engineering you never get rid of the bottleneck.  You just sort of move it around from place to place.  I think that what is going to tend to happen is that as the warning technologies become more capable, it's going to move the bottleneck and the responsibility back on to emergency managers who can no longer and say, "Hey, the technology wouldn't let me do it."  At that point, the problem becomes, dare I say it, political.  But that's where people’s expectations will rise.  And we'll have to support the process further upstream then in order to meet those public expectations.  

Al Gilman:  I wanted to talk to the upstream and give you an acronym, IPTC.  These people do NewsML because I think that they're getting your metadata pushed into their metadata, in terms that they very often -- we saw from Katrina that the best information, best intelligence was off of the commercially-operated news networks.  So the question is, can we get information about -- that is to say, stuff that in terms of the platonic ideal is emergency information, get that so classed in the newswire so that it moves to the desk of the authority to make emergency notification swifter.  You know, we don't lose time, and it's the usual problem with things like all text and so on is that you need to get it at this source, you didn't realize that you needed it until you got three steps downstream.  Anyway, end of speech.  

ART BOTTERELL:  I spent 2001 commuting back and forth to Singapore doing a job for the Ministry of Home Affair there, on an integrated public information system.  The concern that I came away from -- and they wanted to do exactly the sort of integration that we're talking about -- was that there was not a common data format for talking about warnings.  And we actually looked at NewsML specifically.  Unfortunately there was too much extraneous stuff, and the way that some of the issues were framed were more appropriate to the news application than to the warning application, strictly speaking.

So that's the only reason we didn't just use NewsML in the first place, was it just wasn't a close enough fit, and that had as much to do with training and industry uptake issue as it did with data content.

To get from CAP to News ML should be, you know, am XML transfer.  That should be lossless.  Transforming down from News ML to CAP, probably a little lossy because we didn't spend as much time on things like who has got the copyright to the photo.  So there might be loss there.  Fundamentally, yes, it can and should be glued together.  But frankly the news industry was not the people whose problem we were trying to solve.  The news industry was the people whose solution we were trying to copy.  

JANINA SAJKA:  I am a little interested in this bottleneck issue, because I think that there are accessibility implications there when people make decisions that perhaps are not the best informed, and I think that when you said MP3 you were really thinking in terms of an example that you can attach another resource, but if you will allow me I am going To pick on that example a little bit because you know, I can see the value of sending a photo.  I can see a value of sending a map.  I don't see the value of sending resource intensive audio file when probably the person that needs that has the ability to do that transformation locally off of data which is far more likely to get through on a congested network.  So if I take this correctly, you've got a protocol here, a specification for terse alerting, notification, well-defined.  But then it seems like there's this ability to extend it in ways that I am unclear on how you make sure that it's appropriate and situation appropriate?  

ART BOTTERELL:  Well, appropriateness, of course is a matter of interpretation.  It's sort of in the eye of the beholder.  

There are emergency managers that I have talked to who absolutely insisted that if their CAP message was ultimately to go out over EAS, it was to go out over EAS in their own voice, and, therefore, the ability to do something like the MP3 file was an operational requirement of theirs.

From a systems engineering point of view I would obviously much prefer that text-to-speech be done as far downstream as possible, and probably in the not too distant future that will become the norm.

There are issues that arise particularly in the mass media, the Weather Service of course has worked a number of years to get text-to-speech to work properly, and local pronunciations, place names, have been particularly problematic.  So I think that the state of practice is lagging the state of the art there.  Other than that, and concerns that some networking people have raised about the size of the payload, we just approached extensibility as a way of future-proofing the standard.  We didn't make a rule one way or the other.  

We did address network capacity by specifying that the actual enclosure of large files is only permissible on high-capacity broadcast networks where you can't provide a URL and let people retrieve it if they want it because there's no return path.

In reality, I think that's probably going to be fairly transient concern as you point out.  The speech technology is coming along just fine.  I would expect that in five years it won't occur to anybody to attach a MP3 file to a message.  But as a transitional technology we actually found some people who right/wrong had the requirements to do it.  So we tried to support them.  Because we're here to support everybody.  

The RERC on Telecommunications Access is a joint project of the Trace Center, University of Wisconsin, and the Technology Access Program, Gallaudet University. The RERC is funded by the National Institute on Disability and Rehabilitation Research in the U.S. Department of Education, under grant number H133E040013.  However, the opinions and content are those of the grantees and do not necessarily represent the policy of the U.S. Department of Education.

Back to home page