This 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 over distance.
 
 

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

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

The 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.CoRaven’s 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.CoRaven’s functions and implementation are described in additional detail in [Jones, et al, 2000].
 
 

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

In 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 system.Because constructing 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 analysis’s engaged in analysis and monitoring tasks. 
 

For 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 intelligence messages.
 

We 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 CoRaven’s analysis.Furthermore, specifications of data to be viewed in each of CoRaven’s 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 schedules.Observations 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.

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

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

Whiteboards 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 CoRaven’s perspective displays (the map, the schedule or the Bayesian belief network).
 

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

The 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 Mike’s tool palette.
 
 

Talking 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 collaborative application.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.
 
 

Communication 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 particular user.Once 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 workbench’s message-passing scheme.Additionally, the workbench must have an understanding of all user actions, application specific or not, that may change the users’ display.

Although 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 4^th 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.