paper describes recent advances made which enhance the effectiveness
of the CoRaven decision support tool. CoRaven is a tool
developed to assist intelligence analysts in interpreting large
quantities of battlefield intelligence messages and monitoring
changes in the battlefield situation. The specific advances
include 1) broadening of the initially planned functions of CoRaven
to include functions to support intelligence planning in addition
to the functions supporting intelligence analysis and 2) the addition
of a collaborative workbench to which can support groups of analysts
in collaborating via the computer even though the individual users
may be at very different geographic locations. The need
for a workbench to support collaboration arose because intelligence
analysis (and many other army reasoning tasks) is most often performed
through the collaborative efforts of a team. Thus CoRaven
must not only support the individual analyst, but it must also
help groups of users to work more effectively with each other
is a prototype decision support system designed to assist Army
intelligence analysts in monitoring and interpreting battlefield
messages. Until this year CoRaven has focused on analysis support
for a single user. In this paper we focus on our new work in which
we have broadened the scope of activities supported by CoRaven
to include intelligence requirements tasks, and have created a
generic collaboration architecture so that CoRaven can support
multiple users cooperating to produce an analysis.
assists analysts in several ways.First,
it provides several data visualization mechanisms that allow users
to view intelligence data (observations of events on the battlefield)
from several task-relevant perspectives.Second,
it provides an inferencing mechanism using Bayesian belief networks
to draw likely conclusions from the data.
The three primary data perspectives
provided are a spatial view, which allows users to see the locations
of each observation, a temporal perspective, which shows when
each observations was made, and what observations are scheduled
for the future, and a logical view showing what conclusions each
observation will be used to support.For example, an observation of
enemy tanks moving in the north might be used to support the conclusion
that the enemy plans to use the northern route to attack.
inferencing mechanism uses the logical structure in the form of
a Bayesian belief network (which is viewed in the logical perspective)
to generate the current likely conclusions that can be drawn from
the data.The likelihood of the various
conclusions changes as the additional new intelligence data comes
in.CoRavens intended function
is not to interpret the data for the user, but to provide a second
opinion to which the analyst can compare against his or
her own interpretation.CoRavens functions and
implementation are described in additional detail in [Jones, et
initial goal of CoRaven was to support analysis and monitoring
of incoming intelligence messages.We
made a design assumption that the task of monitoring and interpreting
messages could be separated from requirements planning: the setup
task of deciding what intelligence questions to ask (e.g. will
the enemy attack from the north or the south?) and planning what
information to gather in order to answer those questions.
the first prototype implementation of CoRaven, it was assumed
that a belief network would be created for the each new scenario,
and that network would be provided as an input to the CoRaven
new belief networks was a difficult and time consuming process,
from a pragmatic standpoint this assumption made it difficult
to adapt CoRaven rapidly to new scenarios.However, once created, CoRaven could use the network
to provide conclusions about various battlefield hypotheses to
analysiss engaged in analysis and monitoring tasks.
software evaluation purposes, we created a belief network for
a specific scenario and then asked analysts to use CoRaven to
assist them in analyzing and monitoring a stream of simulated
found that users reported that it was awkward to use CoRaven for
analysis, when they had not created the logic (the belief network)
driving the analysis themselves.Possible
reasons include that they did not agree with the logic in the
network, or the questions posed were not the ones they wished
to ask themselves.We concluded that it was necessary to add decision
support and editing functions to also support requirements planning
activities (i.e. creation of the intelligence questions to be
asked, specification of the information that would allow these
questions to be answered.)Furthermore, because intelligence
analysis is typically performed by a team of interacting analysts,
it was also important to provide support for collaborative activities
among multiple users.
The main challenge in developing functions
to support requirements planning was not simply in developing
editors, which could be used in specifying locations at which
intelligence observations could be made, belief networks, or other
information.It was in making
these functions interoperable with CoRaven, and in integrating
the three perspective views of the data as they were created.
Changes in user created requirements
data structures had to automatically result in changes in CoRavens
analysis.Furthermore, specifications of
data to be viewed in each of CoRavens three perspectives
are not independent tasks. For example, it does not make sense
to add an observation to the belief net (the logical perspective)
with out also updating the schedule (temporal) and map (spatial)
perspectives. Each observation added to the belief net logic has
to be made at some time and at some place. Thus, an editor created
for specifying belief net logic needed to be tightly intertwined
with the schedule and the map functions as well.
Towards this goal, we developed the
Dynamic Intelligence Operations (DIO) architecture to assist in
requirements specification [Ergan, 2000].Specifically,
DIO assists users in constructing requirements for collection
added to the schedule are simultaneously added to the map.Providing
support for entering new belief networks, and linking the observations
in the network to the map and schedule perspectives is the ongoing
goal of the CoRaven completion project.
To support collaborative interactions within a group of analysts jointly using CoRaven, we created the collaborative workbench.The overall concept is quite generic and may be applicable for making many different types of applications collaborative.The paradigm on which the workbench is based assumes that multiple users log into a synchronous session and view a shared display.
shared display allows all participants to jointly interact in
a "community space" consisting of a chat board, application
displays, virtual acetates which have been overlaid
on top of the application displays and on which users can write,
a user list indicating who is virtually present in the community
space, and a talking stick (to determine which user gets to drive
at present), and a set of talking stick controls.
One person at a time controls the floor by taking possession of the talking stick.For example, that person may scroll display pages or write annotations on top of existing interface images.These changes to the display are shared among all other users.
Acetates.Many collaborative applications use shared whiteboards
or clearboards.In a whiteboard
application, each user views a paint program running on their
machine.All collaborating users
paint programs are connected via the Internet such that they all
see the same picture.For example, if users Mike and
Linda are using a collaborative whiteboard, Mike sees what Linda
draws and vice versa.Clearboards
are similar to whiteboards, except that they allow collaborating
users to draw on top of a shared picture as if they were using
an acetate overlay.
and clearboards can be thought of as a chat programs for the artistically
minded.We wanted to use
a clear board to allow users to draw on top of any and all of
CoRavens perspective displays (the map, the schedule or
the Bayesian belief network).
implemented this concept using Java glassPane, which allows for
graphics to be displayed on top of anything in a Jframe, and have
called it virtual acetate.If a program has multiple
windows (as CoRaven does, one for each perspective view) virtual
acetates can be added to each window.When a virtual acetate is added to a program, a Tool
Palette is created to allow the user to turn the overlay on/off,
change the paint color and brush size, etc.
Tool Palette can be thought of as the single paintbrush used to
paint on all users canvases.In
a collaborative application, the tool palette has a single state,
which is seen by all users.Thus,
if user Linda changes her paint color, the same paint color will
be shown in Mikes tool palette.
Stick.In order to support the idea of a single "speaker
who controls the floor" (or holds the paintbrush) we have
created tools that allow a group of users to manage a Talking
Stick.The person that holds the Talking Stick controls the
workbench has a window showing who has the talking stick, who
has asked for the talking stick, and buttons to allow users to
request/relinquish the talking stick.
Scheme.We are using JSDT (Java Shared
Data Toolkit) to handle the communication issues of collaboration.Once a JSDT server is running, a programmer can set
up "channels" that can be used for communication.One can send any java object
over these channels, as long as the object implements the serializable
interface.When data is put on the channel,
it can be sent to all users (including the originator),
all other users (omitting the originator), or to just one
the message reaches the targeted users, it is decoded and the
appropriate action is taken to update their interfaces.
Applying the collaborative workbench. To enable a given application, such as CoRaven, to make use of the collaborative workbench, the application must be modified to use the workbenchs message-passing scheme.Additionally, the workbench must have an understanding of all user actions, application specific or not, that may change the users display.
users share a common interface, there is currently no "central
representation" shared by all users.We
currently enable all users to see the same view by passing messages,
and changing all users interfaces incrementally.This approach works as long as all users enter the
collaboration at the same time.However,
a new user attempting to enter the session while it is in progress
would have a difficult time ascertaining the current state of
the user interface.Two possible solutions are (a)
have a dummy application running at a known location, which maintains
he global state, or (b) have a mechanism whereby the new user
can query an existing user for the current state.A
second limitation is that allowing only one user to perform actions
at a time may be limiting for some applications.We
would like to explore other control mechanisms in future work.A third limitation is that overlays are not currently
persistant.In other words,
saved or loaded, nor can the computer directly process concepts
that may be represented on the overlays.
Jones, P. M; D. C. Wilkins, R. Bargar, J. Sniezek, P. Asaro, N. Danner, J. Eychaner, S. Chernyshenko, G. Suchrah, C. C. Hayes, N. Tu, H. Ergan, L. Lu, CoRaven: Knowledge-Based Support for Intelligence Analysis,ARL Federated Laboratory 4th Annual Symposium, Advanced Displays and Interactive Displays Consortium, pp. 89 94, College Park, MD, March, 2000.
Ergan, Hakan, Design ofA Decision Support System for Army Intelligence Collection Resource Scheduling, Masters Thesis, Department of Mechanical Engineering, University of Minnesota, May, 2000.