February 27, 2009

A Standard of Practice for Public Warning

Filed under: Public Warning Policy — Art @ 6:29 pm

Public warnings are urgent communications issued from time to time by various entities in an attempt to reduce preventable injuries or deaths. The following principles are proposed as the basis of a professional standard of public warning practice:

1. When should a public warning be issued?

1.1. A warning should be issued whenever there is an imminent threat to life or health
of which an individual or community may be unaware. “Imminent” means that more routine means of communication would not be effective.

1.2. Generally, a warning should be issued as soon as an appropriate recommendation for protective action can be made. It is preferable to issue a preliminary warning message and then refine it later rather than to wait for perfect information that may arrive too late.

1.3. In situations where a delay is unlikely to substantially affect the outcome for people at risk, consideration may be given to delaying warnings during overnight hours (e.g., from 10 PM until 6 AM) or while the recommended protective action might conflict with immediate response activity.

1.4. A fear of public panic is NOT a sufficient reason for delaying a public warning. Panic results when social bonds are torn by an acute sense of individual competition for limited opportunities of escape from a dire threat. It rarely occurs as the result of a public warning. Timely warning with clear protective action recommendations can actually reduce the potential for panic.

1.5. By their nature public warnings can never be guaranteed to be timely, effective or accurate; the issuance of a public warning is a voluntary and discretionary act.

2. By whom should a public warning be issued?

2.1. A public warning may be issued by any individual or entity that is aware of an imminent threat to human life or health, particularly if that individual or entity believes that some or all of the target audience will not receive warning from another source.

2.2. A public warning is best issued by an individual or entity that is familiar to, and with, the receiving audience.

2.3. A public warning is best issued by an individual or entity with the capacity and authority to coordinate warning information and response activity among all the responsible actors (e.g., an Incident Commander or a senior elected official.)

3. To whom should a public warning be issued?

3.1. A public warning should be given to all individuals whose life or health is at risk.

3.2. A public warning may also be shared with individuals and agencies that may be able to provide necessary assistance to individuals at risk.

3.3. To the extent possible public warnings should NOT be distributed to individuals who are neither affected by nor in a position to provide assistance with a hazard.

4. What should be the content of a public warning?

4.1. A public warning message should indicate as specifically and precisely as possible which persons are at risk from a particular hazard, in terms of their location or some other distinguishing characteristic. In some cases it may also be useful to identify individuals or communities that are explicitly NOT at risk from that hazard.

4.2. A public warning message should describe the nature of the hazard in plain terms that are understandable by the target audience. If an emergency response to the hazard is planned or underway, that activity should be described as well.

4.3. A public warning message should describe one or more protective actions that individuals or groups can take on their own to improve the outcomes for themselves and their neighbors. Where more than one protective action is suggested, criteria should be offered by which individual recipients can select the best course for themselves.

4.4. A public warning message should provide information on when the hazard is expected to materialize (which may be “currently”) and, if possible, should include a forecast of how long the hazard will persist.

4.5. When possible a public warning message should provide recipients with an expectation of what is likely to happen next. In some cases this will simply be an estimate of when and how they will receive additional information.

5. How should public warnings be disseminated?

5.1. Whenever possible, public warnings should be transmitted to the public by multiple media simultaneously. Using more than one means of delivery increases audience reach and improves technical reliability, and also enhances warning effectiveness by confirming and reinforcing the warning message.

5.2. Delivery media for a particular warning should be chosen with an eye to balancing the need for wide and immediate attention with the need not to desensitize unaffected audiences with irrelevant warnings.

5.3. Wherever possible, warning message recipients should be encouraged to share the warning message with friends and neighbors, particularly those who may be isolated by physical or sensory disability, language ability or other factors.

5.4. Wherever possible, warning messages should be delivered in multiple formats to accommodate the special needs of recipients with physical or sensory disabilities, or who do not speak a particular language. However, delays in the conversion of a warning into multiple forms are NOT a valid reason for delaying release of a public warning in whatever form is most rapidly achievable.

6. How should uncertainty be expressed in public warnings?

6.1. Where facts surrounding a warning situation are uncertain, that uncertainty should be disclosed frankly in the warning message.

6.2. To avoid creating a false sense of precision, uncertainties and probabilities should be expressed in general, non-numeric terms (e.g., “observed” / “likely” / “possible” / “unlikely”) instead of percentages or other precise-sounding language.

6.3. Descriptions of uncertainty should address not only any uncertainty about the hazard itself, but also any uncertainty about its effects on the at-risk population.

6.4. Uncertainty is NOT a valid reason for delaying a public warning. It is preferable to cancel or amend a warning as better information becomes available than to risk preventable injuries or deaths by delaying the initial warning message.

June 6, 2008

What is IPAWS anyway?

Filed under: Common Alerting Protocol, Emergency Response — Art @ 5:48 pm

A reporter asked me today to clarify whether FEMA’s “Integrated Public Alert and Warning System” (IPAWS) was a product or an architecture or what?

Originally, IPAWS was a program to bring all kinds of different warning systems together to form a coherent sort of “warning Internet” based on the CAP standard; a single CAP message from an official would be delivered simultaneously through whatever systems happened to be available locally, thus ensuring maximum reach, consistency and effectiveness of the warnings. So it was an architecture in the sense that it would enable competitive vendors to offer an interoperable interface to their products, allowing them to be mixed, matched and shared among local, state and federal buyers.

But when a policy push came down to do a pilot project along the Gulf Coast in time for the Katrina anniversary, FEMA cobbled together a handful of particular products under the leadership of Sandia Labs and started referring to that as IPAWS. By the time the money for that pilot ran out (and both Sandia and the FEMA project manager had been shuffled off to other projects) the focus within FEMA’s National Continuity Programs Directorate had narrowed to deploying “Digital EAS” by way of PBS satellites and the PEP stations for the singular purpose of enabling the President to address the nation.

That more restricted vision was reflected in FEMA’s filing back in January in the FCC’s cellular alerting proceeding, wherein they floated the theory that FEMA lacked authority to get involved in state or local warnings. That got shot down in both House and Senate oversight hearings, and in a news release last week FEMA Assistant Administrator Martha Rainville recanted and said they could do it after all.

Still, it’s not clear whether the current program managers and their contractors over at FEMA have any real idea of how to proceed. At a congressional hearing on Wednesday of this week D.C. Delegate Eleanor Holmes Norton told Rainville straight out, “We don’t think you know what you’re talking about, frankly.” She demanded that FEMA open up its decision making process on IPAWS to forums involving broadcasters, state and local officials and other experts in the field of public warning.

So I’m afraid there’s great confusion, especially within FEMA, as to whether IPAWS is a national design for integrating all our warning assets (most of which are state, local or private property) or merely another federal procurement program. State and local government and most broadcasters need the former, but many of us fear the FEMA staff involved are so far out of their depth that their contractors have taken over yet again.

We can only pray FEMA will accept the help it’s being offered.

May 8, 2008

The “User Experience” of Warnings in EAS

Filed under: Common Alerting Protocol, Public Warning Policy — Art @ 6:16 pm

In the runup to the May 19th EAS Showdow… um… Summit in Washington, DC, most of the discussion has focused on the nuts and bolts of moving the nation’s broadcast alerts across digital networks based on CAP.

But CAP only defines the information “payload” of a warning. It doesn’t specify how that information should be presented over HD radio, digital TV, computers, PDAs, digital signage or any of our various other windows into the infosphere.

This is going to become a crucial question in the very near future, I think. As digitization drives “broadcast” content onto ever more diverse platforms we’re going to need to give these presentation/user interface issues as much attention as we have to transport/relay-network design.

We may want to develop some common elements… consistent visual, aural, even tactile (e.g., portable device vibrator cadences) cues that one might almost call “branding elements”… to ensure that emergency alerts have a degree of consistency across all media. Otherwise we risk letting diversity deteriorate into confusion.

The Australians have made an interesting foray in that direction with their Standard Emergency Warning Signal (SEWS)… basically a standard “sounder” that can be used consistently over broadcast, wireless, wireline and even acoustical (siren and public address) delivery systems. However they haven’t tried yet to set a comparable standard in the visual or other domains.

Last year the FCC’s cellular alerting advisory committee (the CMSAAC) took a few first steps toward designing a consistent user experience for a basic text-messaging interface.

But as we start talking about digital television and HD radio and the things that lie beyond them, we’re going to need to bring some real world-class user-interface expertise to bear alongside our enormous pool of transmission engineering experience.

The Common Alerting Protocol (CAP) provides a rich standard data payload that can be presented… hopefully consistently… over all media, broadcast and otherwise. But the details of how best to present that richer message are still to be determined and require immediate skilled attention.

April 27, 2008

Creating CAP Applications - An Online Outline

Filed under: Common Alerting Protocol — Art @ 6:39 pm

“We must resist the temptation to standardize what we don’t yet understand.” I don’t recall who said that, but I remember it vividly from the early(er) days of the Internet. Some of you have heard me recite it… some of you more than once, I’m afraid.

Ever since the CAP 1.0 specification was first adopted there’s been a recurrent cry for some sort of FAQ or collection of “best practices” for applying CAP. That’s been a problem, because for the first couple of years we hadn’t really had enough time for most questions to be asked more than occasionally, or enough experience to rate any particular practices as “best.” So I didn’t attempt anything major on that project, nor it seems did anybody else.

But now I think we may have come far enough to be able to look back and see a few patterns forming. So I’ve taken a first whack at a document on the “CAP Cookbook” wiki to lay out some of the larger architectural issues and point out a few productive directions and blind alleys we’ve discovered.

As ever, your participation in this document is solicited. It’s online now at http://www.incident.com/cookbook/index.php/Creating_CAP_Applications.

November 23, 2007

CAP is now X.1303, too

Filed under: Common Alerting Protocol, Emergency Info Systems — Art @ 5:24 pm

It’s been in the works for awhile, so I almost missed the formal announcement that the International Telecommunications Union (ITU) has adopted CAP as its recommendation X.1303:

Publication as an ITU-T Recommendation (X.1303) will help ensure that CAP is deployed worldwide giving technical compatibility for users across all countries. The goal of public warning is to reduce the damage and loss of life caused by a natural or man-made hazard event.

In the course of adopting CAP, the ITU added an important feature by specifying a bandwidth-efficient binary representation of CAP messages using the ASN.1 packed encoding. This alternate representation of the CAP data structure has been cross-adopted by OASIS, where the CAP standard originated.

November 17, 2007

Oil Spill Experience Bodes Ill for Terrorism Response

Filed under: Emergency Response — Art @ 11:11 am

As many folks are aware, over the past week the San Francisco Bay Area has been coping with a relatively small, and yet surprisingly damaging, oil spill. A freighter ran into the Bay Bridge in the fog and leaked an estimated 58,000 gallons of bunker oil into the bay.

I was slightly involved in the response, and what I saw troubled me deeply. (And here I’ll note for form’s sake that these words reflect a personal perspective and not any official position of the agency I work for currently.)

Most disasters begin in local jurisdiction and then roll up to the regional, state and, if necessary, federal levels of assistance to the locals. But this one was “born federal”… in the jurisdiction of the Coast Guard… and operated in a procedural “stovepipe” of specialized oil-spill planning triggered after the catastrophic Exxon Valdez spill in Alaska in 1989.

As an unintended consequence, local officials around the bay were relegated to a peripheral “liaison” role and excluded from the line functions of incident command. The state’s involvement was managed by a specialized Oil Spill Prevention and Response unit in the Department of Fish and Game, a unit that has minimal relationships with local agencies. And the organization generally responsible for linking local jurisdictions to the state and federal level… the Governor’s Office of Emergency Services… adopted a passive, seemingly almost impotent stance toward the whole operation.

Many of the problems associated with this operation… a wholesale loss of confidence in the information provided by the Coast Guard, frustrated citizens, infuriated local elected officials… strike me as having been either caused or exacerbated by that peculiar arms-length relationship between the federal response and the folks responsible for local resources, safety and health.

Which might be shrugged off as meaning only that our oil-spill response plans need to be fine-tuned… but that would be to miss the really crucial point. Since 9/11 we have created another class of catastrophic-event-stimulated stovepipe organizations and procedures for terrorism events that I fear could come to grief in the same way.

Amidst all the finger-pointing and posturing that inevitably follows such a high-profile mishap, I hope our officials and our media will take a careful look at the processes for connecting federal-driven responses, of all kinds, with local agencies and jurisdictions.

Our traditional interfaces have been in large part bypassed by specialized plans and reorganizations, and it seems clear from a number of recent incidents (not excluding Katrina) that those “missing links” need to be either restored or replaced.

Google Phone Changes The World

Filed under: Life the Universe and Everything, Net Craft — Art @ 10:31 am

Which is a pretty good trick for something that physically doesn’t even exist yet, don’t you think?

But the “gPhone”… aka the Android platform… is a world changer nonetheless. It’s fundamentally (and I suspect permanently) reversed the historic roles of hardware and software. Instead of software being implemented atop a pre-existing hardware platform, the Android project is defining functions… applications… in software and then telling hardware makers, “Here, support THIS.”

It’s the concept of a “software defined radio” carried to its logical limit, really. Until now SDRs have been hardware devices that can be programmed to behave in various ways… within the constraints of the hardware, of course. With Android, though, Google has cut out the mechanical middleman. The desired capabilities are defined in software first, and then its up to the hardware to adapt.

Which actually is a backhanded complement to the hardware folks. They’ve reached a level of mastery where hardware CAN be tailored to very specific requirements. Technical “artifacts” can be minimized to the point that almost anything is possible. One need only decide.

But what a fundamental powershift results! The design of physical gPhones, when they start to deploy, will answer as much to an open-source community of independent users and developers as it will to specialist engineers and corporate designers. And the refinement… evolution, even… of their functionality will be a continuous emergent process that the marketeers will have to chase instead of directing.

Damn but this is an exciting time to be a geek!

(And a shout out to my old disaster buddy John McDermott for slapping me upside the head to pay attention to this…)

October 17, 2007

Toward CAP 2.0

Filed under: Common Alerting Protocol — Art @ 7:53 pm

Friends -

Now that we have a bit of actual experience with CAP… and now that CAP has been adopted as a core technology for broadcast and cellular alerting in the U.S… it’s may be time to start talking about what we’ve learned that might make the next version of the CAP standard even better.

One of the factors to which I attribute the success of CAP is that so much of its design was accomplished in an open, informal and very international context prior to subjecting it to the constraints and rigors of a formal standards process. That’s no criticism of the need for formalities and structure, just a suggestion that the best results may come neither from pure freedom nor from pure structure, but from a thoughtful balance of the two.

Which is why I’d like to suggest that we on this list… the folks who got the ball rolling in the first place… should take a first stab at some recommendations for the next revision of the OASIS/ITU CAP specification.

We did pretty well using email the last time around, but not everyone prefers email for online collaboration. So I’ve taken the liberty of adding a new topic to the online CAP Forum at:

http://www.incident.com/capforum/viewforum.php?f=8

(It’ll be interesting to see how that works compared to the traditional email approach. I don’t see any reason we can’t use either or both as each of us prefers, at least until it becomes clear that one way is significantly better.)

Anyway, I’ve gone ahead and launched a handful of topics on the Forum based on some ideas I’ve jotted down recently:

  • responseType: New values needed?
  • area: How to describe motion?
  • area: Harmonizing the geometries
  • info: Need for unique identifiers?
  • Mandatory and optional elements
  • U.S. SAME Compatibility

Please feel free to debate these topics and to propose your own. I’ll do my best to keep the dialog civil and productive, and to hold the spammers at bay. Obviously all opinions expressed will be the writers’ own, and I’ll be taking neither responsibility nor ownership… in the argot of the venerable online community The WELL: “You own your own words.”

Thanks, and good luck to us all!

- Art

August 23, 2007

CAP Alerts On Your VoIP Phone?

Filed under: Common Alerting Protocol — Art @ 4:32 am

The irreplaceable Robin Cover reports on an interesting draft specification from the Internet Engineering Task Force (IETF) for using the Session Initiation Protocol to deliver Common Alerting Protocol (CAP) alerts:

SIP is an application-layer control (signaling) protocol for
creating, modifying, and terminating sessions with one or more
participants. These sessions include Internet telephone calls,
multimedia distribution, and multimedia conferences.

SIP is a key standard in the Voice-over-IP telephone world and it will be interesting to see how this might be applied. (If it offers any clues, the authors of the Internet Draft hail from Nokia Siemens, NeuStar and Columbia University.)

May 10, 2007

More Praise for Forgetfulness

Filed under: Life the Universe and Everything — Art @ 6:22 am

Last fall I offered a brief item on why sometimes it’s important to forget. Now Professor Viktor Mayer-Schönberger of Harvard’s Kennedy School of Government has expanded on that theme considerably in a paper entitled “Useful Void: The Art of Forgetting in the Age of Ubiquitous Computing“:

For millennia remembering was hard, and forgetting easy. By default, we would forget. Digital technology has inverted this. Today, with affordable storage, effortless retrieval and global access remembering has become the default, for us individually and for society as a whole…Google saves every search query, and millions of video surveillance cameras retain our movements.

In this article I analyze this shift and link it to technological innovation and information economics. Then I suggest why we may want to worry about the shift, and call for what I term data ecology. In contrast to others I do not call for comprehensive new laws or constitutional adjudication. Instead I propose a simple rule that reinstates the default of forgetting our societies have experienced for millennia, and I show how a combination of law and technology can achieve this shift.

Thanks to Ars Technica and the ubiquitous SlashDot for catching this.

Older Posts »

Powered by WordPress