|
|
|
Updated 19-Sep-2005 |
![]()
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 In the Field: Task Reception and Feedback Reporting Selected Papers Command Center OperationsTwo 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 MapThe 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:
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
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 FieldWiglaf 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
|
|
© 2003-2005 Dependability Research Group |