Information filtering and control for managing the information overload problem

G. Detsis, L. Dritsas, J. Kostaras

Intracom – Defence ProgramsMarkopoulo Ave., 190 02 Peania, Athens, Greece.

ABSTRACT:The scope of this paper is to present the research results of Euclid RTP 6.11.1 project, undertaken by the IFICS consortium.

The aim of the project is to present research results of an information filtering system which will help a C3I operator to cope with an overload situation. This system is located between a C3I system and the operator. The paper starts with a description of the overload problem and an analysis of the OODA cycle. The possible operator tasks are categorised as skill, rule and knowledge tasks. For the former 2, a particular structure (IFICS) has been developed to demonstrate means for protecting the user from information overload. The rest of the paper describes the components of the IFICS system.

List of topicsWorking under stress.Measuring human performance.

Key messageIt is possible to manage the information overload problem by means of monitoring the user’s reaction in order to drive an adaptive filtering mechanism.

1 IntroductionFuture C3IS face the problem of information overload. The reasons leading to this are mainly the foreseen stuff reduction and the increasing number of possible information providers that send data to a C3IS database. Undoubtedly, there is a need to protect the operators from information overload. This paper aims to demonstrate how this can be achieved by providing background information about the problem and offering an application that demonstrates some possible solutions. The IFICS project is concerned with the research on and the development of an Information Filtering and Control System (IFICS), to be used to demonstrate adaptive information filtering and control in order to reduce information overload problems within a C4I

organisation. To quote from the Problem Domain Analysis Report (PD1B, Section 8), the purpose of the project has been “[t]o study the ability to tune information load to the user of the system, taking into account the particular situation of the world, the abilities of the user and the specific demands that information may put on the user”.Information overload occurs mainly in the execution of rule and knowledge-based tasks within the orientation and the decision-making phases of the OODA loop (see fig. 1). Research shows that too much time is needed for gathering the required information and removing the non-relevant information from the total amount of information that is presented to the operator. The remaining time is not enough for operators to use the available information in a proper way in order to take the correct and original decisions for situation assessment and decision making tasks. Traditionally, an operator receives tactical information from a Combat Management System (CMS). IFICS is conceived as a mediating layer between the operator and the CMS, which filters ‘irrelevant’ information when it is detected that the operator is experiencing information overload, while at the same time presenting the operator with enough information to facilitate qualified decision making.

2 Description of the overload situation

Operators have to deal with different kinds of tasks during the completion of the C2I-cycle also known as OODA-cycle (See Figure 1). We could detect five processes (Observe, Orient-Assess, Plan, Decide and Act) in the C2 cycle that the decision-maker can visit by means of two different sequences. The cycle begins with the acquisition of sensory data about objects and events from the environment (Observe process). The decision-maker orients himself/herself within the acquired data and assesses the significance of the situation (Orient-Assess). From the results of this assessment, the decision-maker may progress directly to choose a suitable response to events (Decide) or to generate some plans for responding (Plan) before choosing one of them. Having chosen a response, the decision-maker puts it into effect (Act), usually by issuing a series of instructions to the units under his/her command. These instructions should cause changes to come about in the environment,

1

Observe Orient-Assess

Plan Decide Act

which can then be sensed in the Observe process, thus closing the loop.

Rasmussen [Rasmussen, 1983] distinguished three kinds of behaviours in controlling the decision making process: skill-/routine-, rule- and knowledge based behaviour (see Figure 2). Using this distinction it is possible to gain better understanding of human errors in running complex processes in an information rich environment and of how to reduce the likelihood of such errors with suitable information management support systems.

Figure 2 Rasmussen's 3-level model for decision making

At the skill-based level, the operator makes decisions by Stimulus-Response. Features are extracted out of incoming sensory input, and these features are directly coupled to automatic motor actions. There is no "thinking" needed at this level. Tasks that require skill behaviour could be easily automated in most of the cases. The information management support system could support the operator by gathering and presenting the required information in a more efficient manner.At the rule-based level, the operator associates certain states of the world with tasks that must be performed in those states. The difference between skill and rule based behaviour depends on the level of training and on the attention of the person. Decision-making is accomplished by applying rules based on previously acquired experience or formal training and performance is goal-oriented. The operator's thinking is limited to situation assessment and retrieval of predefined tactics. In military terms, one talks about doctrine. The information management support system should provide guidelines to the operator through the decision making process by presenting all relevant information, and the different options and proposed actions.

At the knowledge-based level, (where no predefined-rules exist) the operator must identify the problem, select a task to work on based on his/her goals, and then generate a plan for dealing with it. Plan generation thinking requires deeper understanding of the nature of the situation and explicit consideration of objectives and options. At this level of functional reasoning, information is processed as symbols, which are used to construct a ‘mental model’ of the causal and functional relationships in the environment. This also means that the situation is novel and requires deeper understanding because the information isn’t enough to determine the required information need in advance. The system could support the operator in the information gathering process and identification of the information need that has to be interpreted to reach a particular goal.

Given a particular set of sensory input, the operator makes decisions by first trying to apply skill-based reasoning. If there is no match of features to motor actions, the operator resorts to rule-based reasoning. If there are no predefined rules for the current situation, then the operator must resort to knowledge-based reasoning.

The Rasmussen model can be mapped onto the OODA-cycle [Maas 2000]. Observe corresponds to

2

Figure 1 The OODA or C2I-cycle: (a) Observe; (b) Orient-Assess; (c) Plan; (d) Decide (e) Act

the acquisition of the sensory input, the three processes of the left column of Rasmussen’s model correspond to Assess-Orient, decision of task and planning a procedure at the Knowledge-based level correspond to Plan, the Rule-based processes of associating the state with a task and retrieving the appropriate rules, together with automating the motor actions at the Skill-based level, all correspond to Decide. Finally, actions correspond to act. The use of schemas and frames of references seems to be the main problem within knowledge based behaviour.

IFICS attempts to help an operator in an overload situation by applying an adaptive filtering mechanism to user reactions [Maas, 2000]. The whole operational scenario has been split into specific tasks (e.g. operational tasks) that the system handles. Each one of these tasks contains timing information about when the task started, when it is to be terminated etc. A planning algorithm handles these tasks and checks whether a deadline has passed. If this is the case, then this is an indication that the user faces an overload situation and thus the system has to deal with it. The IFICS system adapts to user overload by helping him/her in three ways:

by changing the presentation forms of the tasks that cause overload (e.g. render tracks that are of not much concern to the operator as dimmed);

by dropping some information needs that are not important;

by applying rescheduling of a task (i.e. it will reallocate the task to a backup user who is able to deal with the task).

By applying any or all of the above ways the filtering system attempts to help the user in his/her decision-making process by filtering out any superfluous information that is not of primary importance to the user thus taking the user out of the overload situation s/he may be.

3 IFICS architecture

Technologies involvedModern tools and technologies have been used for the IFICS demonstrator. In the initial stage of the system an agent-driven methodology [Knapik & Johnson] has been used. In the next phase of analysis and

design the Unified Modeling Language has been used in order to produce an Object-Oriented architecture. Design patterns have been used where necessary to help in developing an easily expandable system. The Java programming language was used for its object-oriented benefits and platform-independence with CORBA implementation (i.e. RMI) for the communication of the various agents. Other up-to date technologies include an object-oriented database and Extensible Markup Language files to store system’s data. An expert system is used for the various scenarios that are loaded in the demonstrator. Finally, the Human-Computer Interface consisted of a Geographic Information System to display information about tracks etc.

System ArchitectureThe system comprises of 5 main agents and 2 peripheral agents. The main agents are those that perform the main functions of IFICS and constitute the core of the system. The peripheral agents are not actually part of IFICS; instead they are meant to support the system’s functionality.

More specifically, the 7 IFICS agents are:

Main agents: Task Monitoring and Management (TMM)

It recognizes events and according to those it manages a system-wide schedule of operational tasks.

Tactical Situation Monitoring (TacSit)It detects changes in the tactical situation and generates relevant events.

Information Need Definition (IND)It accesses a pool of task profiles and retrieves information regarding the quantitative and qualitative characteristics of specific tasks.

FilteringAccording to the characteristics of the tasks running in the system, it filters the information directed to the user.

User Monitoring (UM)It monitors the actions of the user and forms a model of him. Based on this model, it attempts to adjust (in co-operation with the rest of the system) the quantity and/or quality of the information directed to the user.

Peripheral agents: Human Computer Interaction (HCI)

It displays on screen the information directed to the user and captures user-related events (e.g.

3

mouse clicks). It also holds and displays geographic information (e.g. maps) (see fig. 3).

Figure 3 IFICS Human Computer Interface

Combat Management System Simulator (CMS)It stores data related to various aspects of a Combat Management System. These data are retrieved, utilized and updated by the rest of the system.

Functionality

Figure 4 Architectural view of the system IFICS demonstrator

The communication channels between the agents can be seen as arrows and the data exchanged can be seen as small captions along these arrows. As the number of communication channels indicates, there is a substantial degree of complexity in the system.

We will describe the functionality of IFICS agent-by-agent. Task Monitoring and Management

TMM receives and recognizes tactical events from TacSit and user-initiated events from UM. It might also receive requests from UM to adjust the multiplicity of tasks. All cases result in TMM initiating or terminating operational tasks. The schedule of tasks (maintained inside TMM) is adjusted accordingly and it is forwarded to the IND agent.

Tactical Situation MonitoringTacSit detects changes in the tactical situation by inspecting the status and contents of the database maintained by the CMS agent. It then forms relevant tactical events, which are forwarded to TMM.

Information Need DefinitionIND receives the schedule of tasks formed inside TMM. It then accesses the TaskProfiles database, which contains information about operational tasks. From that database it retrieves the quantitative and qualitative characteristics of the tasks, which are part of the task-schedule, received from TMM and forwards this information to the Filtering agent.IND might also receive requests from UM to adjust the characteristics of the tasks. If IND is not able to fulfil this request then it contacts TMM requesting the reduction of the multitude of the tasks.

FilteringFiltering receives a list of quantitative and qualitative characteristics of the tasks. It matches those characteristics against the data stored in the database of the CMS agent in order to come up with a list of graphical attributes. This list is forwarded to the HCI.

User MonitoringUM receives from TMM some measurements regarding the effect of the multitude of the tasks to the user (work load) and from Filtering some measurements regarding the effect of the quantitative characteristics of the tasks to the user (information load). Based on these measurements and the status of the user (monitored via the HCI), UM might decide to adjust the information directed to the user. If the adjustment has to do with the multitude of the tasks then TMM is conducted, otherwise if the adjustment has to do with the characteristics of the tasks then IND is conducted.

Peripheral agents: Human Computer Interaction

4

HCI receives a list of graphical attributes from Filtering. Based on these it draws on screen the tactical situation: the map zoomed in the area of interest, symbols representing military and civilian contacts, dialog-boxes for the user to interact with, etc. HCI also reacts on user actions and notifies UM of them (e.g. speed of reaction to stimulus, selections in drop-down lists).

Combat Management System SimulatorCMS has no complex functionality. It provides Filtering, TacSit and UM with methods for accessing and modifying its data.

4 ConclusionsThe IFICS project has demonstrated that it is possible to protect the C3IS operator, as regards to skill and rule based tasks, from potential overload problems by using structures similar to those used in IFICS. Predefined user templates that continuously monitor the user’s performance and feedback this information to the system have been proved very successful.

5 AcknowledgementsThe IFICS consortiumIFICS (Information Filtering and Control System) is the name of a European research programme that is carried out as part of the EUCLID (European Co-operation for the Long-Term in Defence) RTP 6.11.1 programme. The IFICS consortium consists of five different companies from four countries::

TNO-FEL, Holland SIGNAAL, Holland DATAMAT, Italy TERMA, Denmark INTRACOM, Greece

who have all contributed in the successful accomplishment of the project.

Intracom – Defence ProgramsMany thanks also go to Intracom’s Defence Programs Department for kindly providing us with the valuable time to produce this paper.

6 References[Rasmussen, 1983] J. Rasmussen, ‘Skills, Rules and Knowledge; Signals, Signs and Symbols and Other Distinctions in Human Performance Models’, IEEE

Transactions on Systems, Man and Cybernetics, SMC-13 (3), p. 257-267.

[Maas et al, 2000] Maas, Stavnem, Wynia, Houtsma,, ‘An Information Filtering and Control System To Improve the Decision Making Process Within Future Command Information Centres’, NATO symposium proceedings, Istanbul

[PD1B] EUCLID RTP 6.11.1 – IFICS ‘Problem Domain Analysis’

[Knapik & Johnson] M. Knapik & J. Johnson, ‘Developing Intelligent Agents for Distributed Systems’, McGraw-Hill, 1998.

5