software agents for coalition forces

KSCO April 2002 Toulouse p. 1

Software Agents for Coalition Forces

Second International Conference on Knowledge Systems for Coalition Operations,

23rd and 24th April 2002 Toulouse, France

By Zakaria Maamar, Paul Labbé, and Wathiq Mansoor.

Presented by Paul Labbé, P. Eng., IEEE Senior

Defense R & D [email protected]

Tel.: +1 (418) 844-4000 x 4479

KSCO April 2002 Toulouse FranceThis presentation reflects the views of the authors and does not necessarily represent the plans and policies of the

Canadian Department of National Defence or of Zayed University


The distributed, heterogeneity, and dynamic nature of the coalition context has raised the need for new advanced

technologies. These technologies aim at managing the coalition informational infrastructure, in terms of autonomy, adaptability, and scalability. To achieve this support, Software Agents (SAs)

seem to be a promising approach. To develop this approach, different aspects of a coalition has to be identified. These aspects include the coalition structure; the roles and responsibilities held by people within the coalition; the flow of information within the

coalition; the capabilities required or available within the coalition; and the context in which the coalition operates. For

many of these aspects, SAs can be used; . For instance, the coalition structure can be associated with several SAs of different

types and with different roles.

Abstract


Allied warfare objective

The ultimate objective of Allied Warfare is to increase the overall Joint/Coalition Force mission and task success rate and geopolitical influence agreed by the driving Nations.

This objective imposes more difficult to meet requirements for demanding operations as in littoral warfare theater.

The generation of the necessary conditions to increase the speed and accuracy of Joint/Coalition command and control

include but are not limited to the material of this presentation.

Introduction


From live coalition exercises

• The Force Over the Horizon Track Coordinator (FOTC) data base resulted in many large inaccuracies and inconsistencies in the Global Command and Control System- Maritime (GCCS-M) picture (identity attribute of tracks (ID) jumping and time lateness)

• Operators believed picture to be accurate• Stale data used to make decisions (Blue Force was

successfully ambushed by Orange ships)• FOTC held correct ID on several Hostile Tracks while

LINK 11 reported them as Unknown for long periods• Orange ships came within weapons range of high value

blue units (Kittyhawk) without being reported for long periods of time

• Sanitization rules within Radiant Mercury strip vital data (e.g. source data)

Requirement Specification


How to deal with interoperability issues?

Interoperabilityenvironment

Users' needsissue- a -

Informationdisparity issue

- c -Distributionissue- b -

SAs

Dis. ObjectComputing

OntologyWFs

CodeMobility

Agent-based architecture


Three dimensions of interoperability issues:

physical interconnectivity, application integration, and command collaboration

Application level

Physical level

rely on

build on

Commandment level

Application level

Physical level

rely on

build on

Headquarter HeadquarterCollaboration

Integration

Interconnectivity

Coordinationspace

MAS 1 MAS i

Coalitionmission

Services Services

invoke

use

invoke

Network

Military Forces 1 Military Forces i

use

Commandment level

use


We propose a software agent architecture and structure to resolve some of these issues!

• Meeting infrastructure

• Information exchange control

• Multi-agent environment

• Security of execution and sharing

• Shared decision-making

• …..


A software agent definition

• An autonomous entity having the abilities to assist users when performing their operations, to collaborate with each other to jointly solve different problems, and to answer users' needs



A simplified CCIS model

• A structure and a set of functions and tasks

Planning Data fusion

Resources (software,hardware)

Communication

External environment

CCIS

Functions

Structure

Users



Architecture for interoperable CCISs

• Aspects to be dealt with

– Maintain the autonomy and independence of the CCISs

– Reduce the informational disparities of the interconnected

CCISs

– Protect the interconnected CCISs from the unauthorized

accesses

– Evaluate the communication channels performance,

particularly in low-bandwidth situations (QoS, CSNI)

– Help users satisfy their needs without worrying about the

characteristics of the CCISs



Interface-Agent 1 CCIS-Agent 1 Resolution-Agent 1

MAS 1

Control-Agent 1

Advertisement Infrastructure

SA-Supervisor


MAS 2

Control-Agent 2

Function 11 Function 1i

CCIS 1

Function 21 Function 2j

CCIS 2

Autonomy management

Remote interaction/Mobility

Low-bandwidth&unreliablenetwork



Architecture main characteristics

• Interface-Agent

• CCIS-Agent/Function-Agent

• Resolution-Agent

• Control-Agent

• Supervisor-Agent

• Advertisment infrastructure



Interface-Agent

• It assists users in formulating needs, maps needs into requests, forwards requests to the CCIS-Agent in order to be processed, and provides users with answers obtained from the CCIS-Agent.


Formulationmodule

Requests

AnswersAnswersCCIS-AgentUser

Needs

Communication layer


CCIS-Agent

• It processes user requests received from the Interface-Agent, but only if these requests require the involvement of the CCIS of this particular CCIS-Agent. In the proposed architecture, a CCIS-Agent has the ability to advertise its services by posting notes on the Bulletin Board of the Advertisement Infrastructure. To do so, the CCIS-Agent can either send a remote request to the Supervisor-Agent or can migrate to this infrastructure; the choice is based on the network status. In both cases, i.e., remote request or soft-mobility, a security level associated with the CCIS-Agent is used to identify the services this CCIS-Agent is authorized to advertise.



Turning CCISs into agents of MAS• Purpose: making a CCIS to behave like a SA

– Build a SA on top of the CCIS


Function-Agent 11 Function-Agent 1i

CCIS 1

CCIS-Agent 1

MAS 1

Function 11 Function 1i

Requests/Results Functions initiation

Other MASs

Requests/Answers forwards


Pre-processing

moduleAnswers

CCIScapabilities

Interface-AgentRequests

Communication layer

Definitionmodule

Processingmodule

Monitoringmodule

Answers

Requests

Updates

ServicesSupervisor-Agent

CCIS functions

Communication layer

Resolution-Agent AdminsitratorServices

RequestsSub-answers

AnswersSub-requests

CCIS-Agent and Function-Agent modules


Resolution-Agent


Pre-processing

moduleAnswers

CCIS-AgentRequests

Communication layer

Slavemodule

Adv. Infra.

Transfer(Help-Agent)Creation

Browsingmodule

Communication layer

Queries

CCISs

Bulletin BoardCCISs

Queries

Performancemodule

Answers

Route

CCIS-AgentsSub-queries

Sub-answers

Communication layer

Creation(Help-Agent)

Creation(Route-Agent)

Sub-queries

Sub-answers


Control-Agent



Supervisor-Agent




• In an interoperating environment, CCISs are generally spread across networks and rely on low capacity and unreliable channels for communication. Moreover, a military user may use his Combat Net Radio to send and request information or may rely on mobile devices, such as portable computers, that are only intermittently connected to networks. In the proposed architecture, to avoid overloading the network, CCIS-Agents and Resolution-Agents migrate to the Advertisement Infrastructure in which CCIS-Agents advertise their services by posting notes on the Bulletin Board, whereas Resolution-Agents consult the Bulletin Board to identify the CCISs that are required to satisfy user needs.





CCIS-Agent


Bulletin Board

Repositoryof ActiveAgents

Supervisor-Agent

note 1note i

1. Remote request

2. Security check

3. Registration

4. Posting

5. Acknowledgment


In actions


Initialization MaintenanceAdvertisement Operation

Users

Administrator

Resolution-Agent


Repositoryof ActiveAgents

Supervisor-Agent

1. Help-Agent creation

Service-Agent

2. Transfer

6. Acknowledgment

3. Security check

4. Registration5.Installation

Help


Satisfying a userAgent-based architecture

User

Function-Agent 11 Function-Agent 1i

CCIS 1Function 11 Function 1i


MAS 1

2. CCISs identification

3.a data/4.a results

CCIS-Agent 2

MAS 2

CCIS-Agent 3

MAS 3

9.b/13.b Mobility

10.b Local computing(Route-Agent 1)

11.b Remote computing(Route-Agent)12.b Answers


Bulletin Board

Service-Agent

4.b Queries6.b CCISs

0. Needs

6.a/16.b Answers

1. Request

5.a/15.bAnswers

3.b Request

14.b Answers

7.b Route design8.b Route-Agent

creation

5.b

Not

es


Preliminary analysis• What information is to be managed, and what are the properties of

this information?– Identify and categorize information items– Specify source, destination, size, update period, comm paths,

security

• Under what circumstances will the information be used and managed?– Define: Context = Goal Stable Conditions Dynamic Conditions

– Specify the Importance (I) of each Context

• What a priori assessments can be made about the value of the different types of information in specific circumstances?– Potential (P): relevance of information for a Context– Quality (Q): how accurate information should be for a Context– Timeliness (T): how recent information should be for a Context

Improving Information Sharing


Prioritization rule set


OBJECTIVE: Optimize use of system resources (e.g., BW), and ensure most valuable information is processed first

i = information item = contextI = Importance of w, wP, wQ, wT = weighting factors

Pi = Potential of i for Qi = Quality of i for Ti = Timeliness of i for X = accounts for other factors

(e.g., dynamic conditions)

For example:

qi = measured quality of i i = actual timeliness of i

Priority(i,) = w I · ( wP Pi + wQ Qi + wT Ti + X )

X = f ( Qi , qi , Ti , i )


Quality assignment rule setOBJECTIVE: Assess the information attributes found in

Coalition databases with the aim of integrating different data sources

• Maintain separate track position and ID quality measures• Account for intrinsic sensor limitations (e.g., range,

environmental conditions) --> the best sensor does not always have the best data

• Provide a systematic and consistent statistical definition of error

• Allow degradation in position quality during DR• Problem: For security reasons, information is often sanitized

or partially stripped (e.g., source) before dissemination, making quality assessment difficult



Impact of changes on mission

model-based measures

N

H

N

F

CSIHIH-PHFNU

- commander’s ship- intended hostile target- IH predicted position- hostile- friend- neutral- unknown

CS

FH

F

F

N

NN

N

N

actualtarget

IH

N

HH

N

H H

U

H

IH

N

N

with prediction

without prediction

IH-PIH-P


Cost of time to discover, deliberate/fuse

0 10 20 30 40 50 60

0

4

8

12

16

20

-0.50

-0.30

-0.10

0.10

0.30

0.50

Ave

rag

e V

alu

e

Delay (min)

CUA radius (km)

FOTC - Pertinence of engagement (POE)0.3-0.5

0.1-0.3

-0.1-0.1

-0.3--0.1

-0.5--0.3

This axis can be interpreted as a

combination of positional inaccuracies of surface

hostile contacts reported.

Value of the information presented to a commander in hypothetical OTH –T for the surface hostile

contacts reported.

This axis shows the age or delay since sensor time of surface hostile contacts

reported after processing and deliberation.

1 time to discovery

cost


Discovery/fusion gain (recipe)

0 10 20 30 40 50 60

0

4

8

12

16

20

-0.50

-0.30

-0.10

0.10

0.30

0.50

Ave

rag

e V

alu

e

Delay (min)

CUA radius (km)


0.1-0.3

-0.1-0.1

-0.3--0.1

-0.5--0.3

2 gain from

discovery

1 time to discovery

cost


Gain in applying recipe to updates

0 10 20 30 40 50 60

0

4

8

12

16

20

-0.50

-0.30

-0.10

0.10

0.30

0.50

Ave

rag

e V

alu

e

Delay (min)

CUA radius (km)


0.1-0.3

-0.1-0.1

-0.3--0.1

-0.5--0.3

2 gain from

discovery

1 time to discovery

cost 3 gain with

updates


Loss in sharing the result

0 10 20 30 40 50 60

0

4

8

12

16

20

-0.50

-0.30

-0.10

0.10

0.30

0.50

Ave

rag

e V

alu

e

Delay (min)

CUA radius (km)


0.1-0.3

-0.1-0.1

-0.3--0.1

-0.5--0.3

2 gain from

discovery

1 time to discovery

cost 3 gain with

updates

4 cost for sharing


Sharing recipe preserve gain + capacity

0 10 20 30 40 50 60

0

4

8

12

16

20

-0.50

-0.30

-0.10

0.10

0.30

0.50

Ave

rag

e V

alu

e

Delay (min)

CUA radius (km)


0.1-0.3

-0.1-0.1

-0.3--0.1

-0.5--0.3

2 gain from

discovery

1 time to discovery

cost3 gain with

updates

4 cost for sharing

5 improvement by sharing recipe instead of fusion results


Improving interoperability + sharing

• Must be able to measure value of local discovery or fusion.• When a discovery or fusion improves own picture above the

received picture by a given threshold – display this result locally– send own data used in recipe– send recipe with list of ingredients (track# used)– responsible for sending own data for this recipe until found

inadequate locally or remotely.• Eliminate data incest and does not require the sharing of source

identity (avoid loss of information required for appropriate MSDF) but provide an improved confidence in shared information. Provide “track pedigree”.

• First steps in developing agreed information quality schemes.• Important unit and force effectiveness gain for various missions.


Cost of time to discover, deliberate/fuse

0 10 20 30 40 50 60

0

4

8

12

16

20

-0.50

-0.30

-0.10

0.10

0.30

0.50

Ave

rag

e V

alu

e

Delay (min)

CUA radius (km)


0.1-0.3

-0.1-0.1

-0.3--0.1

-0.5--0.3

This axis can be interpreted as a

combination of positional inaccuracies of surface

hostile contacts reported.

Value of the information presented to a commander in hypothetical OTH –T for the surface hostile

contacts reported.

This axis shows the age or delay since sensor time of surface hostile contacts

reported after processing and deliberation.

1 time to discovery

cost


Discovery/fusion gain (recipe)

0 10 20 30 40 50 60

0

4

8

12

16

20

-0.50

-0.30

-0.10

0.10

0.30

0.50

Ave

rag

e V

alu

e

Delay (min)

CUA radius (km)


0.1-0.3

-0.1-0.1

-0.3--0.1

-0.5--0.3

2 gain from

discovery

1 time to discovery

cost


Gain in applying recipe to updates

0 10 20 30 40 50 60

0

4

8

12

16

20

-0.50

-0.30

-0.10

0.10

0.30

0.50

Ave

rag

e V

alu

e

Delay (min)

CUA radius (km)


0.1-0.3

-0.1-0.1

-0.3--0.1

-0.5--0.3

2 gain from

discovery

1 time to discovery

cost 3 gain with

updates


Loss in sharing the result

0 10 20 30 40 50 60

0

4

8

12

16

20

-0.50

-0.30

-0.10

0.10

0.30

0.50

Ave

rag

e V

alu

e

Delay (min)

CUA radius (km)


0.1-0.3

-0.1-0.1

-0.3--0.1

-0.5--0.3

2 gain from

discovery

1 time to discovery

cost 3 gain with

updates

4 cost for sharing


Sharing recipe preserve gain + capacity

0 10 20 30 40 50 60

0

4

8

12

16

20

-0.50

-0.30

-0.10

0.10

0.30

0.50

Ave

rag

e V

alu

e

Delay (min)

CUA radius (km)


0.1-0.3

-0.1-0.1

-0.3--0.1

-0.5--0.3

2 gain from

discovery

1 time to discovery

cost3 gain with

updates

4 cost for sharing

5 improvement by sharing recipe instead of fusion results


Improving interoperability + sharing

• Must be able to measure value of local discovery or fusion.• When a discovery or fusion improves own picture above the

received picture by a given threshold – display this result locally– send own data used in recipe– send recipe with list of ingredients (track# used)– responsible for sending own data for this recipe until found

inadequate locally or remotely.• Eliminate data incest and does not require the sharing of source

identity (avoid loss of information required for appropriate MSDF) but provide an improved confidence in shared information. Provide “track pedigree”.

• First steps in developing agreed information quality schemes.• Important unit and force effectiveness gain for various missions.


•The impact on mission effectiveness of adopting a meeting infrastructure exploiting agent-based architectures for CCISs need to be considered and be accurately assessed.•Presented major characteristics of the MAS interoperability approach and the design of collaborative environments for distributed and heterogeneous CCISs. •Eight types of SAs exist in the architecture proposed for coalition support (Interface-Agent, CCIS-Agent, Resolution-Agent, Control-Agent, Function-Agent, Supervisor-Agent, Help-Agent, Route-Agent) while four stages describe this architecture operating (Initialization, Advertisement, Operation, Maintenance). •Further works need to be done for demonstrating the value of the coalition embedded characteristics of the proposed infrastructure.

Conclusions and recommendations


Using information value for optimizing end users’ shared awareness is not simple but the potential gains outweigh the effort required, by delivering

increases in mission precision and success rate that guarantee long term benefits and would increase

public support.

An agent-based architecture would also provide cost effective capabilities for future improvements,

measurability, maintainability and support for training and simulation.

Conclusions and recommendations (cont’d)

software agents for coalition forces

Documents