1. CoAX – Coalition TIE Technology Integration Experiment
DARPA
CoAX – Coalition TIE
Technology Integration Experiment
AFRL Rome, AIAI, Boeing, Dartmouth, DERA Malvern, Lockheed Martin ATL, Michigan, MIT Sloan, OBJS, USC/ISI, UWF/IHMC
Support from BBN, GITI, ISX, MITRE, Schafer, Stanford
Coalition Agents eXperiment (CoAX)
PLEASE SEE NOTES
UNDER SLIDES

2. Briefing Outline Aims and Scenario CoAX Components Demonstrations
9-Month Demonstration
Next Steps
Summary

3. CoAX Message Operational Message Technical Message
Interoperability of Systems
Agility and robustness
Coalition and “virtual” organizations
Technical Message
Agents as an appropriate paradigm to facilitate interoperability
Middleware of Grid is valuable for rapid configuration
Utility of domain management and task/process management services

4. Context Increasing military requirements for coalition operations
Belief that agent computational model is a good fit to meet coalition interoperability requirements
US and UK Agent Research Programmes
US DARPA Control of Agent Based Systems (CoABS)
UK DERA Agents Project
Need for “middleware” such as is provided by CoABS Grid Infrastructure
ED: Seems like having “interoperability” between applications and information services is a special case of what it sounds like the demonstration is to show. If the TIE is to demonstrate things like generic error handling services and incentive management services, for example, there will be more than interoperability shown. The sense I got was that the aim of the demonstrations is to show: agent-based management services and capabilities (associated with the CoABS Grid) that facilitate coordinated interoperation and information sharing among Coalition partners represented as a heterogeneous agent community in multiple distinct “domains.”

5. Aim of Coalition TIE
Aim is to address unique aspects of coalition operations through the development and evaluation of agent domain and task management services
Aim will be met through delivery of:
Phased technical demonstrations of increasing complexity
Development of generic Coalition-oriented grid services
Requirements:
Use of a wide variety of different agent systems
Use of existing military (non-agent) applications
ED: Seems like having “interoperability” between applications and information services is a special case of what it sounds like the demonstration is to show. If the TIE is to demonstrate things like generic error handling services and incentive management services, for example, there will be more than interoperability shown. The sense I got was that the aim of the demonstrations is to show: agent-based management services and capabilities (associated with the CoABS Grid) that facilitate coordinated interoperation and information sharing among Coalition partners represented as a heterogeneous agent community in multiple distinct “domains.”

6. Key Coalition Drivers Different cultures, doctrines, and languages:
Different doctrine, decision making, rules of engagement and, in general, mission “agendas”
Command authorities - agreement and transfers
Different interpretation of situational information
Incompatibility of respective national information systems:
Different technology skill and equipment levels
Lack of information systems resource sharing agreements
Variable reliability of components and infrastructures
Lack of compatible security architectures
Need for rapid configuration and reconfiguration by personnel with limited training
Limited models for coalition force operations
ED: Seems like scenario features would (ultimately) need to include different incentives (perhaps implied by “agendas” above?), and success criteria that would increasingly require sufficient sharing of relevant information and/or adaptive coordination of workflows/plans during execution?
Derived from LeRoy Pearce (Canadian MOD), 1999

7. Key Technical Drivers
Cannot assume interoperability, reliability or availability of different nations systems
Need for partial (secure) sharing and visualization of processes, data and facilities
Need to work with agents in multiple dynamically determined domains
Need for flexible inter-agent task and process management
Need for rapid formation, management and change of agent relationships
different nations systems:
E.g., functional capabilities, communications, security arrangements or information resources

8. Binni - Gateway to the Golden Bowl of Africa
Rathmell, R.A. (1999) A Coalition Force Scenario 'Binni - Gateway to the Golden Bowl of Africa', in
Proceedings of the International Workshop on Knowledge-Based Planning for Coalition Forces,
(ed. Tate, A.) pp , Edinburgh, Scotland, 10th-11th May 1999.

9. N Binni - All Features W E S × Q LAYERS: 31E 36E 35E 34E 33E 32E 39E
BANDAR
Population centres ×
Military airfields
Gravel roads
Brongo
Ports Q
Civilian Airfields
Tracks
KEY
Tarmac roads
175
Heights (metres)
Railways W E N S
LAYERS:
31E
36E
35E
34E
33E
32E
39E
38E
37E
17N
16N
15N
20N
19N
18N
21N
WESTERN REGION
AGADEZ
Zingato
SIKASSO
COSTA DEL
MARIA
LAKI
BANDAR
UGWULU
UPPER REGION
NORTHERN REGION
CACA REGION
EASTERN REGION
CACA
REGION
ASHANTI REGION
CENTRAL REGION
GAO
Kwanabouri
Gambaga
268
Masembi
Gambaga Escarpment
Higgville
Libar
Zatu
To Cunmege
To Tifillo
Dinga
Anala
876
527
390
482
436
588
752
542
707
123
788
613
175
Akwapim-Gao Range
Kwahu Plateau
To Pample
To Segumbo
Kamongo
Jinja
Brongo
Laval
Biloo
Sagiba
Bave
Gamba
Kolla
Antok
Grandville
Hakkali
To Cecil
Dado
Minga
Kaso
Nanga
Caca Dam
Esuko
Blackman
Laponga
Zaribe
Bonrope
Tonka
775
Atewa
Ranga
Saltpond
Achobo
Adaido
Diplombo
Elmina
Wonka
Deanville
Sonara
Sandosta
Komenda
Gonobo
Grandvache
Polia
Jamestown
Slabo
Donga
Anguiba
Kutchi
Akimbo
Sago-
town
Wazilla
Suthertown
Bisa
Wampimba
Belucar
Salisbury
Bisha
St Andrews
Sellerham
Kingtown
To Petit Paris
To Escallope
Lissa
Libretto
Slafito
Langford
To Falo
Asoba
Nedalla
Epidurango
Aida
To Harra
Brongo
Ports Q
Civilian Airfields
Tracks ×
Setting
Geography
Cape
Vincent
Amstado
Caca
Kaso
Lagoon
Amisa
Jacal
Pra
Ankobra
Tana
Ofin
Afram
Daka
Black Caca
Kapowa
White Caca
Mawli
LAKE CACA
Transport
Water
Names
Lat / Long
Binni - All Features
Return

10. Forces separated by firestormW E N S
Cape
Vincent
Amstado
Caca
Kaso
Lagoon
Amisa
Jacal
Pra
Ankobra
Tana
Ofin
Afram
Daka
Black Caca
Kapowa
White Caca
Mawli
LAKE CACA
Gao
forces
Agadez
Firestorm
Forces separated by firestorm

11. Gao deception is intended to displace firestorm:W E N S
Gao deception is intended to displace firestorm:
separation fails.
Cape
Vincent
Amstado
Caca
Kaso
Lagoon
Amisa
Jacal
Pra
Ankobra
Tana
Ofin
Afram
Daka
Black Caca
Kapowa
White Caca
Mawli
LAKE CACA
Gao
forces
False
Gao
forces
Agadez
forces
Firestorm
False Agadez
forces

12. Briefing Outline Aims and Scenario CoAX Components Demonstrations
TTCP Demonstration
Next Steps
Summary

13. CoAX Components Agent Frameworks KAoS Agents (Boeing, IHMC)
NOMADS Mobile Agents (IHMC)
EMAA/CAST Agents (LM ATL)
D’Agents (Dartmouth)
eGents (OBJS)
Agents on the Grid
AODB Agent (LM ATL)
Observer Agents (Dartmouth)
eGents Agents (OBJS)
Malicious Agents (IHMC, Boeing)
Web Weather Agent (USC/ISI) …
DARPA
CoABS Grid
(GITI, ISX)
Agent Grid Services
Task and Process Management (AIAI)
Domain Management Services (Boeing, IHMC)
Asynchronous Wireless Connectivity (OBJS)
Plan Deconfliction (Michigan)
Exception Handling (MIT)
Military Systems
CAMPS (AFRL,GITI, BBN)
MBP (DERA) …

14. Briefing Outline Aims and Scenario CoAX Components Demonstrations
9-Month Demonstration
Next Steps
Summary

15. Demonstration Schedule
1-month demo at kick-off in February 2000 showing direct connection between DERA MBP and LM ATL AODB
6-month integration milestone in July 2000 showing initial integration of selected CoAX components for 9-month demo
9-month demo in October 2000:
Brief the CoAX TIE and Binni scenario
Show full integration of selected CoAX components
Show that selected components interoperate in a Binni-based scenario
Tell a relevant “story” about agents for information gathering
Additional stand-alone demos of other components
18-month demo in July 2001 showing full integration of all CoAX components in a rich coalition scenario:
Expanding scope to cover planning and execution
30-month demo in July 2002 showing dynamic aspects of domain management and tasking
Note that the term 'surrogate agents' is used to describe proxy agents which stand in for incomplete or unavailable agents.

16. Master Battle Planner v2.1
Month 1 - Initial Demo
Demonstration involved AFRL Rome, DERA Malvern and LM ATL and was a first (risk reduction) step toward CoAX
Demo showed legacy applications can be usefully integrated into an agent framework
CoABS Grid
Master Battle Planner v2.1
(DERA, UK)
EMAA / CAST
Agents
(LM ATL, US)
AODB
EMAA - Extendable Mobile Agent Architecture
CAST - Cooperating Agents for Specific Tasks

17. 6-Month (July 2000) Milestone Report
Eleven agents in three separate agent domains representing coalition functional units (JTF HQ, JFAC HQ, Gao Intel)
Binni scenario information used to drive storyboard
Tasking and control across coalition functional units
Visualization of coalition C2 process via a simple process model
Simple policy administration tool for selective information sharing and communication blocking
Note that the term 'surrogate agents' is used to describe proxy agents which stand in for incomplete or unavailable agents.

18. 6-Month (July 2000) Milestone Structure
JTF HQ
JFAC HQ
Gao Intel
Dbii
PP'
Domain-aware conversational grid agents
Dbi
MBP
Intel1
Intel2
DM2
MM2
DM3
MM3
DM1
MM1
Non-domain-aware message-based grid agents
AODB
LM-ATL
Aim:
To get the agents that will form the core of the 9 month demo working together in a simple Binni-related scenario on the grid, using some basic KAoS agent domain and conversation facilities. For the 6-month demo each agent will belong to only one domain at a time and there will be a single Air Command demo 'thread.’
Agents and Domains:
AIAI Process Panel in JTFHQ domain monitors DERA MBP’s activities.
MBP in JFAC HQ domain generates Coalition Air Operations Plan and visualisation based on the following information:
Dbi in the JFAC HQ domain, information source for the Theatre, assets (friendly and opponent) and their capabilities;
AODB information provided by the LM-ATL EMMA/CAST “come-as-you-are” agent.
Dbii in the Gao domain, which represents a 'private' intelligence source.
Boeing KAoS Domain Managers (DM) and Match Makers (MM) are present in each domain:
DM’s coordinate agent registration, policy administration and enforcement
MM’s federate to provide information about local and remote agent services
Storyboard:
0. JFAC HQ is awaiting orders from JTF HQ. MBP in JFAC HQ begins with an empty scenario showing Binni. JTFHQ Process Panel finds MBP using referral of local KAoS matchmaker tp matchmaker in remote JFAC HQ domain.
1.PP sends UNWAFB Mission Document and Joint Cmdr's Mission Directive to MBP and MBP acknowledges.
2. JFAC HQ begins to assemble information and intelligence. MBP agent at JFAC HQ communicates with non-domain-aware LM-ATL agent to get AODB information. MBP uses local and remote KAoS matchmakers to find domain-aware intel agents. These agent are queried and may provide occasional updates. In cases where redundant information is received from JFAC HQ’s Intel1 and Gao’s Intel2, Gao’s information is preferred as being more up-to-date.
3. JFAC HQ begins air planning. Planner outlines proposed reconnaissance and firestorm areas, and sorties.
4. Analyst at JFAC HQ discovers Gao’s Intel2 agent is deliberately providing misinformation. JFAC HQ domain administrator uses Domain Administration Tool on the Web to block any further communication with Intel2 and other Gao agents. MBP henceforth only relies on less-frequently-updated but more reliable information from local Intel2 agent.
5. Replanning occurs in the light of the newly corrected intelligence information. The reconnaissance and firestorm areas are revised. Other air sorties may be revised.
6. End of demonstration. Planning process would continue until a draft estimate is provided.

19. 9-Month (October 2000) Demonstration Report
Focus on information-gathering phase
First interoperation of agent-wrapped legacy US and UK systems
New agents and domains
Three additional agent domains (6 domains and ~25 agents)
Incorporation of domain-aware CAMPS airlift planning system
Ariadne agent providing publicly available weather information
More powerful Process Panel
New domain management functionality
Malicious observer agent thwarted by domain management and NOMADS resource control mechanisms
KAoS Policy Administration Tool (KPAT) administering communication, registration, and resource policies
New stand-alone demonstrations:
MIT exception handling
U. Michigan plan deconfliction
Dartmouth ‘observer agents’
Note that the term 'surrogate agents' is used to describe proxy agents which stand in for incomplete or unavailable agents.

20. 9-Month (October 2000) Demonstration Structure
JFAC HQ
Gao Intel US
JTF HQ
Observers
(Intel)
Dbii
Dbi
MBP
Intel1
Intel2
DM2
MM2
DM1
MM1
DM4
MM4
AODB
PP'
DM3
MM3
DM5
MM5
DGO
DAO
GAO
DM6
MM6
Weather
Viz
AL Plan
AODB
LM-ATL
Weather
Ariadne
CAMPS
ALDB
Some tentatively proposed new features (not all of these will necessarily be ready in September):
New “observer” domain containing “surrogate” Dartmouth Gao Observer (DGO) and Dartmouth Agadez Observer (DAO) agents. Gao requests to put one of their agents (Gao Agadez Observer, GAO) on the sensor that is hosting DAO, so that they can observe Agadez movements independently. Because there is some mistrust of Gao, permission is granted, but GAO is required to join a special subdomain (Gao Observer, G.O.) of the Observer domain, which is “safer” than the standard observer domain because it uses the IHMC Aroma VM (part of NOMADS). After the Gao Intel domain is cut off (as in the 6-month scenario), Gaointends to venge itself by launching a denial of service attack (e.g., writing continuously to hard disk or network) by its GAO agent within the G.O. domain. Using the combination of KAoS domain management and NOMADS facilities, the denial-of-service attack is stopped by imposing resource rate limits on the agent and DAO’s ability to continue observing is unimpaired. In this case, we could consider using an event-driven policy change (triggered by an agent automatically noticing the pattern of attack) rather than relying on the user to make the changes using the domain management tool.
Communication and access management: hiding inaccessible matchmaker services
Event-driven policy changes
Policy consistency-management for agents in hierarchically-structured domains
Registration management: selective registration and assignment to subdomain
Use of grid authentication services?
JAAS (policy management by individual agent identity rather than code base)
Domain-enabled CAMPS agent (DERA)
Resource management: fine-grained control to block denial-of-service by rogue agent (IHMC), auction-based allocation of resources? (Stanford--this may be a stretch)
Use of come-as-you-are (open source) agent (Ariadne)
Persistent policies at domain, VM, and agent levels
Gao Obs.
Sub-domain of “Observers”

21. Briefing Outline Aims and Scenario CoAX Components Demonstrations
9-Month Demonstration
Next Steps
Summary

22. CoAX
PLEASE SEE NOTES
UNDER SLIDES

23. Briefing Outline Aims and Scenario CoAX Components Demonstrations
9-Month Demonstration
Next Steps
Summary

24. 18-Month (July 2001) Demonstration Plan
More realism in coalition structures
All CoAX members integrated (9 domains and ~35 agents)
Coalition agents playing multiple roles in different domains
New policies add additional robustness and security
Added functionality in process and task management
Increased scope of Binni scenario demonstration
Richer information gathering phase
Extend scope to execution phases with agent systems responding dynamically to events
Incorporating coalition functionality becomes easier
Packaging capabilities as pluggable grid services
Note that the term 'surrogate agents' is used to describe proxy agents which stand in for incomplete or unavailable agents.

25. 18-Month (July 2001) Demo Structure
Dbii
Dbi
MBP
Intel1
Intel2
DM2
MM2
DM1
MM1
DM4
MM4
AODB
DM8
MM8
DM5
MM5
DGO
DAO
GAO
DM6
MM6
AL Plan
Intel1a
Intel3
DM7
MM7
Dbiii
DM3
MM3
Weather
Viz
DM9
MM9 PP
JFAC HQ
Gao Intel US
Observers
(Intel) UK
Shared
Met.
Coalition
Gao Obs.
AODB
LM-ATL
Weather
Ariadne
CAMPS
ALDB
Some tentatively proposed new features (not all of these will necessarily be ready in September):
New “observer” domain containing “surrogate” Dartmouth Gao Observer (DGO) and Dartmouth Agadez Observer (DAO) agents. Gao requests to put one of their agents (Gao Agadez Observer, GAO) on the sensor that is hosting DAO, so that they can observe Agadez movements independently. Because there is some mistrust of Gao, permission is granted, but GAO is required to join a special subdomain (Gao Observer, G.O.) of the Observer domain, which is “safer” than the standard observer domain because it uses the IHMC Aroma VM (part of NOMADS). After the Gao Intel domain is cut off (as in the 6-month scenario), Gaointends to venge itself by launching a denial of service attack (e.g., writing continuously to hard disk or network) by its GAO agent within the G.O. domain. Using the combination of KAoS domain management and NOMADS facilities, the denial-of-service attack is stopped by imposing resource rate limits on the agent and DAO’s ability to continue observing is unimpaired. In this case, we could consider using an event-driven policy change (triggered by an agent automatically noticing the pattern of attack) rather than relying on the user to make the changes using the domain management tool.
Communication and access management: hiding inaccessible matchmaker services
Event-driven policy changes
Policy consistency-management for agents in hierarchically-structured domains
Registration management: selective registration and assignment to subdomain
Use of grid authentication services?
JAAS (policy management by individual agent identity rather than code base)
Domain-enabled CAMPS agent (DERA)
Resource management: fine-grained control to block denial-of-service by rogue agent (IHMC), auction-based allocation of resources? (Stanford--this may be a stretch)
Use of come-as-you-are (open source) agent (Ariadne)
Persistent policies at domain, VM, and agent levels EH IM
Plan Dec.

26. 30-Month (July 2002) Demonstration Plan
Dynamic “come as you are” coalition formation
Dynamic creation of ‘virtual coalition organization’
Agents and domains added to coalition structure ‘on-the-fly’
Dynamic coalition tasks and processes
Tailored visualizations
High-level tools usable without specialized training
Generic task, process, and domain management tools
Note that the term 'surrogate agents' is used to describe proxy agents which stand in for incomplete or unavailable agents.

27. Briefing Outline Aims and Scenario CoAX Components Demonstrations
9-Month Demonstration
Next Steps
Summary

28. Status and Next Steps
1-month, 6-month and 9-month demo milestones successfully completed
100+ page ‘living document’ describing CoAX contributions and Binni ‘FLASH’ scenario delivered
Ongoing work with GITI on design for packaging of agent domain and process management services for the grid
Extended demonstration ready for CoABS workshop in January 2001
Integrated demonstration
4 Stand-alone demonstrations
Links to Joint Battlespace Infosphere, Joint Battlespace Digitisation

29. Summary
Coalition operations is a matter of high concern for the military and a great proving ground for agent research
Binni provides mature rich source of realistic scenario data
Actual military tools used in true cross-national collaboration—hope to expand to additional nations in the future
Seventeen partners cooperating in phased technical integration demonstrators
CoABS Grid provided necessary interoperability
Significant new research issues being addressed of both theoretical and practical significance

30. Further Information and Involvement
CoAX and Binni documentation available
We encourage further participation…
In addressing key coalition and technical drivers
In seeking operational opportunities
In seeking inter-program links
In future demonstrations

31. The End