incident.blog

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.

“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.

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.

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.

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…)

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

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.)

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.

Jonas Landgren’s blog takes a sharp look at the much-bandied notion of a Common Operational Picture:

The common operating picture is not in the map, but in the interactions where some form of common understanding is interpreted and negotiated.

It happened that I was back in D.C. last week, where I spent some time chatting with a GIS-oriented colleague about this very question. It’s closely related to another buzz-term we toss around with more vigor than rigor: “situational awareness.”

In both cases I’m afraid what used to be technical terms have been absorbed into marketing- and proposal-speak and have lost much of their actual meaning. (For folks interested in understanding what’s actually known about situational awareness… what it comprises, how it’s achieved and what it’s good for… I’ll recommend the writings of Dr. Mica Endsley, especially her book “Designing for Situational Awareness.” Turns out there’s a lot more to it than just projecting maps on a large screen.)

Underlying these particular bits of jargon is an error that’s bedeviled emergency management for many years, even before the current post-9/11 American militarismo: A tendency to confuse our tactics with our goals, our means with our ends.

Both “situational awareness” (SA) and “common operational picture” (COP) have become objects of this ends/means inversion. Neither SA nor a COP is an end in itself. What we’re really hoping to achieve is better decisions. The implicit assumption in much of the current homeland-security / emergency-management literature is that map-based COPs are the key to making improved decisions. But as Jonas’ article reminds us, that’s only an assumption.

The problem with the map-centered approach is that a lot of interesting parameters of use in the detection and management of emergencies aren’t geographic in dimensions. Many of them are much more appropriately charted against time, or proportionally, or against demographic or economic parameters, and so on.

For example, one of the most useful displays I saw on the giant video screens of Florida’s state EOC last year was a very simple line graph showing the volume of auto traffic crossing a single freeway sensor loop. It showed vividly the onset, peak and diminishment of evacuation traffic. In a glance it showed that, at the point I saw it, the majority of folks who were going to move had already done so. It would also have been useful to see that particular sensing location plotted on a map, but even without any geospatial information at all, it was highly meaningful in a way that a map depiction of current traffic at a particular point wouldn’t be.

My narrow point isn’t that maps are bad, but only that they aren’t the answer to every question. My broader point is that we need to resist the temptation to let particular solutions become ends in themselves and lose focus on our actual goals.

(And for folks interested in the wide range of ways visual presentations can support decisionmaking… including but going far beyond just maps… I’ll recommend the books of Edward Tufte, especially “The Visual Display of Quantative Information.” For a quick read-in on how life-safety critical this stuff can be, take a look at Tufte’s analysis of how a poorly-crafted PowerPoint presentation obscured critical information that might have prevented the Challenger space shuttle disaster.)

An item on physorg.com reports on some fascinating research at Rutgers-Camden:

The findings could have numerous applications – most obviously in treating hearing loss by artificially increasing the amount of noise in the cochlea of the inner ear, perhaps by an implanted device.

That resonates with a long-time speculation of mine about emergency public information systems: that while it’s useful up to a point to coordinate the messages sent to the public during an emergency, overdoing it can be counterproductive.

There’s a fairly obvious mechanical argument for this, having to do with the cost-of-perfect-information problem. At what point does the delay required to implement excessive message control become more harmful than the marginal errors or variances those measures might (or might not) prevent?

But the Rutgers work suggest a more subtle limit on the effectiveness of message discipline. Is it possible that at some point too much lock-step consistency… too little “noise”… actually can reduce message effectiveness?

My personal experience, including some time spent in relatively high-control cultures, suggests that there’s a point at which excessive consistency starts to suggest that the fix is in. At some point what purports to be corroboration among multiple sources begins to smell like an orchestrated campaign of propaganda. And when that happens, suspicion can undermine the whole process.

People understand noise. People don’t expect perfect consistency, and they don’t trust it when they see it. Nature isn’t made up of straight lines; it’s a complex of fractal curves. Like the visual symmetry in a Kubrick movie, perfect consistency imparts a meaning of its own: it suggests artificiality, immobility, death. A little bit of chaos is natural and healthy. Noise is the secret of life.

If I’m right about this, we may we need to temper our enthusiasm for Joint Information Systems and the elaborate message approval rituals so beloved of bureaucracies. It’s not that accuracy and consistency aren’t important. It’s just that anything carried to excess can become self-defeating.

- Art