From Dependability
Jump to: navigation, search
Error creating thumbnail: Unable to save thumbnail to destination


The recent demonstrations of the vulnerability of domestic targets to acts of terrorism has necessitated a critical look at the effectiveness of emergency response plans and capabilities. A large part of this refinement focuses on communication for response coordination. The Arlington After-Action report on response to the Pentagon attacks recommends the incorporation of computer-based communications that would allow for "automated notification". The McKinsey Lessons Learned report on the World Trade Center attacks cited one area as "improving the Department's ability to receive and disseminate critical information about incidents." Solutions to implement these recommendations can significantly enhance the ability of a department to respond to complex, high-impact incidents in resource-scarce environments.

In the event of an attack or disaster, the effectiveness of communication will have great impact on effectiveness of response. Information, such as what areas have been affected and the level of damage, must be quickly distributed to the people and systems who will then use it to formulate effective response. All individuals that will enact this response must then be notified quickly that the event has occurred and directed as to the action (or inaction) they must take. Feedback is then collected from the responders to assess the implementation of response. This type of control loop is currently difficult to enact even within a single jurisdiction, and nearly infeasible at the regional or national scale.

The intent of our System for Terrorism Intervention and Large-scale Teamwork (STILT) is to provide a mechanism for enacting such a control loop. The system is primarily focused around detecting and responding to geographically-distributed, coordinated terrorist attacks. However, the system is general enough that it can be applied to any emergency response situation. Our central premise is that a system that can correlate distributed attacks and precisely target response commands and information to relevant parties will help prevent subsequent attacks, decrease the impact of successful subsequent attacks, and increase response effectiveness.

The notitification targeting capabilities in STILT are flexible such that the same interfaces can be used for both national or regional-level detection and response and for "on-scene" command and coordination of large groups of responders. The detection mechanism is specifically tailored to mitigate the dispersed nature of the attacks. The response mechanism allows precise targeting of messages based on sender qualification, message attributes, and receiver attributes, rather than simple unicast or broadcast. STILT utilizes the same technologies and core implementation of our work on the Willow system for scalable management mechanisms for providing non-local fault tolerance in critical infrastructure systems. The high-level abstractions in these two systems are identical and thereby allow easy application.

Command Center Operations

Two tools have been developed for use in command. First, the Operational Area Map gives a picture of the situation in a given area. Using insight gained from this map, commands and informationcan then be targeted to individuals in the field using Lucca.

The Operational Area Map

The Operational Area Map (OAM) interface is meant to give decision makers a picture of a particular operational area and the events occurring at a given time. These events might include both the events submitted by users in the field (with Wiglaf) and automated sensor events. The interface can be used in conjunction with Lucca, so that after a situation is analyzed an appropriate response can be projected.

The primary OAM interface components are:

  • A map rendered using Microsoft MapPoint Web Services
  • A "find" area that allows the user to enter a city or zip code for which a new map will be rendered
  • A legend displaying a list of event types which might be received and the corresponding icon which will be placed on the map to represent the event
  • A "Send to Lucca" area which allows the user to select an area on the map and then send the coordinates to Lucca for use in receiver selection.

Note that the OAM interface is adaptable. The events and corresponding icons are contained in a simple configuration file. In addition, a user may filter the events by their properties so that only relevent events are displayed.

The OAM interface contains a "Send to Lucca" feature. At any time, a commander may select a map area by dragging the mouse over the map. This action draws a rectangle on the map. The range of selected latitude and longitude coordinates are displayed, and the user may send these coordinates to Lucca. This feature is useful when a task or constraint must be targeted to a specific area in order to respond to an event or events.


Lucca is an interface for command injection. It allows a decision maker to compose tasks, constraints, messages, and complex workflows. Additionally, users can submit their composed workflows to the STILT system and then monitor the command's progress.

The Lucca Task Creator interface allows a user to create workflows. First, the user must enter basic information, such as the workflow name, type, intention, and reason. Furthermore, the workflow may contain receiver selection constraints for use with Selective Notification when the workflow is delivered. Lastly, the user may set the child tasks of a workflow. Thus, Lucca allows the user to specify and modify very complex workflows. Many of the user choices, such as intention, reason, and receiver selection options, are taken from STILT formal specifications. The resulting interface is powerful and formal, rather than complex and prepared in an ad-hoc manner.

Besides creating workflows, the user may use the Lucca Task Creator to specify relationships among tasks. For example, a decision maker may specify "Task 1 before Task 2." The tasks in a relationship may be added as children to a workflow.

In realistic use, there may be many tasks which are common and would require frequent regeneration. Therefore, the Lucca Task Creator includes an option for loading Action Objects. Action Objects are prewritten classes, each which run a workflow. These Action Objects can be generated from specifications written in A Workflow Language (AWOL). AWOL is a formal specification language for describing hierarchic selective workflows.

Once workflows are created and/or Action Objects are loaded, the workflows can be submitted to the STILT system. The status of the workflow is displayed in the Lucca Results panel.

In the Field

Wiglaf is an interface for command reception and event generation. Wiglaf graphical user interfaces are meant to be used by a wide variety of individuals, so that they may carry out tasks and report events in their vicinity.

The central design principal behind the Wiglaf interface is that it must be simple to use. This is necessary for three reasons. First, the interfaces must function effectively in the high-stress, critical environment of a disaster. Second, they are primarily meant for secondary use. STILT devices, for instance, should not distract an EMT from her primary responsibilities, such as treating patients, etc. Third, the interfaces may be used in devices with limited display capabilities; therefore, components must be kept to a minimum. Wiglaf interfaces are additionally designed to be extremely flexible, because they could potentially be used by a wide variety of individuals, such as first responders, hospital workers, government officials, and airport workers. To accommodate this diversity, Wiglaf is designed as a very general, yet flexible interface that can be personalized. Information for personalization is contained both in a configuration file and in the STILT formal specifications.

There are currently two classes of Wiglaf interfaces, tablet and PDA. The tablet interface, displayed above, is designed to be run on a tablet, laptop, desktop computer, or mobile data terminal. The PDA interface, shown on the left, is designed to be compact for display on a PDA. It, however, is not currently run on actual PDAs due to technological limitations. The primary difficulty is that only early versions of Java are presently available on PDAs, and Wiglaf requires Java 1.4. (It should be noted that another STILT interface, not developed for this project, is available on PDAs through a web browser.) Tablet interfaces will most likely be used by responders in the field with mobile PCs or by responders who are managing others, while PDAs will probably be used by responders in the field who are performing actionable tasks.

Using Wiglaf, individuals may receive either commands or messages. When a command is received, the user must report her status in completing it. Specifically, the user must indicate when the command has been started, paused, completed successfully, or completed unsuccessfully.

Commands in STILT are transmitted using Willow's selective notification mechanism. Therefore, commands may reach an individual based on attributes of the receiver, sender, and message. Wiglaf users are responsible for setting their attributes and setting "sender qualification" attributes. For example, an Emergency Medical Technician might set her name as "Jane Doe" and her branch as "EMT." She might indicate that she has a defibrillator, and she can set her location using coordinates found with a GPS receiver. She might also specify that individuals sending her commands must be EMT of higher rank. Note that these attribute settings remain distributed and are not stored in any central repository. In addition, these settings will eventually include some enforcement of correctness by an unimplemented Willow trust mediation component. Individuals will not be able to set all attributes at will. Jane, for instance, cannot declare herself to be the division chief.

Wiglaf allows users to act as "human sensors" in the STILT instantiation of Willow. Included in the interface is an "Event Injection" panel. Using this panel, users may report events from their environment. These events and the typical event attributes are predefined in formal specifications. The events reported can be viewed using the Operational Area Map.

Selected Papers

  • Rowanhill, Jonathan C., Philip E. Varner, and John C. Knight
Efficient Hierarchic Management For Reconfiguration of Networked Information Systems
Accepted to DSN 2004 (PDF)
  • Varner, Philip E., John C. Knight
An Information System for Emergency Response
Technical Report, University of Virginia, Department of Computer Science (May 2004) (PDF)
  • Stotler, Lori
Graphical Interfaces for a Large-scale Human Command in Emergency Response
Master's Project Report, University of Virginia, Department of Computer Science (May 2004) (PDF)
  • Users Manuals
Operational Area Map