CoAX Stand-alone Contributions Dartmouth College, UMichigan, MIT Sloan, OBJS

1. DARPA CoAX Stand-alone Contributions Dartmouth College, UMichigan, MIT Sloan, OBJS Coalition Agents eXperiment (CoAX) http://www.aiai.ed.ac.uk/project/coax/

2. Stand-alone Contributions • Dartmouth Field Observation Agent • MIT Robustness Service • Michigan Coordination Planning Aid • OBJS eGents Communicating via E-mail

3. Field Observations (Dartmouth) • ActComm Project • Dartmouth, Harvard, RPI, Illinois, ALPHATECH, Lockheed Martin • Department of Defense Multidisciplinary University Research Initiative • Developing a system to provide network access to soldiers in the field • CoAX Goal • Demonstrate the ease with which the large ActComm “legacy” system can be integrated with the rest of CoAX via the DARPA CoABS Grid

4. Field Observations (Dartmouth) • Team of soldiers • PDA’s • Ad-hoc wireless networking • Soldiers make observations. • Ground and air traffic • Personnel and equipment • Buildings and other structures • Observations fed into battle-planning systems (e.g., MBP) through the CoABS Grid. • In the demo, a team of CoAX soldiers will make observations to correct Gao misinformation.

5. D’Agents API Observation Agent Grid API Field Observations (Dartmouth) I see a tank! Query/ Response Observation Viewer (9-month demo - standalone) Registration/ Update Stream Observations MBP (18-month demo - integrated)

6. Field Observations (Dartmouth) 29-SEP-2012 13:47.56 OBSERVATION 0018 VEHICLE Observer : 16.35 N, 35.28 E, Elevation 530 m Sightline: 270 deg, 0 deg down, 2000 m Vehicle : Gao, flatbed truck, 3 axles, heading: 180, speed: 60 km/h Note : 12 soldiers in flatbed

7. The Challenge: Robust Agent Coalitions • Coalitions are open systems • Dynamic membership, often novel partners • Agents in open systems will be unreliable • Intermittent bugs (3 per 1000 lines in the best crafted code) as well as the possibility of malice • Infrastructures can be unreliable • Current failure tolerance approaches are insufficient • Assume closed systems (e.g. mirroring) • Full rollbacks are unnecessarily inefficient for agents

8. The MIT Robustness Service • Monitors agent ‘health’ via polling • Responds to agent failure via intelligent task cancellation & task re-announcement • Maintains reliability information (for failure avoidance) • Designed for open systems - makes minimal assumptions about agents

9. Robustness Service EH API Message Log A Working Grid Service • Transparently infers commitment structures • Assumes (some) agents support (some of ) EH API • Polling (backup: existing Grid is-alive? method) • Task re-announce • Cancel-task

11. Benefits Validated Empirically • Up to 3x speedup and 8x reduced variability vs. standard timeout-retry approach • Benefits increase with task complexity (decomposition tree height) and with level of EH API support • http://ccs.mit.edu/klein/papers/ASES-WP-2000-05.ps

12. Michigan Multilevel Coordinator Agent • Analyses the alternative plan spaces of coalition functional teams that plan independently and act asynchronously • Works top-down with plans chosen by teams to predict unintended interactions (resource contentions; friendly fire). • Identifies candidate resolutions (timing or action constraints). • Notifies process panel of possible plan conflicts and computed workarounds. • Operationalizes/enforces coordination decisions selected. • Given more time, isolates and resolves conflicts more precisely and efficiently. • Allows planning and coordination decisions to be postponed until runtime conditions become better known. • Packaged as a Grid-aware component that will be proactively executing and will be utilized by the AIAI Process Panel.

13. Michigan Coalition Coordination Example Forces begin at aircraft carrier AC Airforce sorties to C, E, & Q for Total Exclusion Zone (TEZ) Logistics delivers humanitarian aid to refugees at F and R ArmyDiv1 occupies X to prevent Agadez forces from reaching and inciting refugees at R ArmyDiv2 crosses TEZ to occupy Y to monitor for Gao crossings Potential plan conflicts include friendly fire in TEZ on ArmyDiv2, destruction of roads through E that ArmyDiv2 might need, and contention for sea and rail transport among army divisions and logistics.

14. Logistics P P Move C1  R, C2  F Airforce Fly sorties Army Div 1 Move to X Army Div 2 Move to Y Logistics Time = 5000.38 cpu sec. Time = 6500.02 cpu sec. Time = 4256.04 cpu sec. P P Move C1  R, C2  F Airforce Fly sorties Army Div 1 ACP P  Z Z  X Army Div 2 Move to Y Logistics P P Move C1  R Move C2  F Airforce Fly sorties Army Div 1 ACP P  Z Z  X Army Div 2 Move to Y Coordinated Plans Hierarchical plan coordination incrementally recommends coordinated plans that are increasingly detailed and parallelized

15. Michigan Multilevel Coordinator Agent

16. eGents Inside Command Post Evacuees Medevac Liaison Family Member In one eGents application, each evacuees are given a Personal Status Monitor, which measures location, vital signs, etc. The PSM contains an eGent which intermittently communicates to subscribing entities using email protocols. OBJS eGents: Agents over Email Problem CoAX Impact • Dynamic military situations are often disconnected and asynchronous. Need a scalable way to deliver agent messages to 1000’s of (wireless) platforms. • Agent systems are often closed and require a lot of specialized agent technology. Email is a common denominator in coalition situations. • By 2012 imagine free eGents attached to sensors, actuators, people, equipment, & locations as pervasive observers & actors • Anyone with email can create an agent service that anyone else can use. New eGent apps can be downloaded to the field as situations change. Approach • Thesis: Integration of agent technology with pervasive Web-ORB-Email backplanes is a route to making agent technology open, pervasive and robust. • eGents are agents which communicate over email. eGents leverages pervasive, robust email infrastructure, inherits support for disconnected operations, message queueing, mobile users, firewalls, filtering, logging, and security. eGents use FIPA or KQML Agent Communication Language (ACL) encoded in XML. No ACL parser needed. Status: Prototype, NEO demo, gridified, on wireless Palm. Spec submitted to FIPA. In progress: packaging and numerous extensions.

17. OBJS eGents: Agents over Email • eGents enabled Digital Assistants • PDAs and ADAs (autonomous DAs) including sensors, actuators, cameras, recorders, range finders, … • are connected by wireless networking (cellular, radio) and • associated with soldiers, observers, NGOs, ... vehicles, weapon systems, …, bridges, buildings, ... • to report status, make observations, take simple actions • can dynamically accept new or revised tasks • In the demo, eGents-enabled CoAX observers and equipment will <exact vignette TBD … monitor status of troops, observers, equipment, avoid unseen threats> • Observations fed into battle-planning systems (e.g., process panel & MBP) through the CoABS Grid and orders & information fed back to the field.

18. OBJS eGents: Agents over Email orders & recommendations observations & subscriptions Need fuel! I see a tank! Any threats?

19. eGents interoperating with each other and with an eGent-grid proxy Might be on machine 2 or anywhere on LAN or on grid-connected LAN PSM client grid agent Machine 2 perhaps installed at command post Machine 3 perhaps installed at medevac unit Machine 1 installed on evacuee subscribe inform eGent grid agent proxy PSM server eGent PSM client eGent other eGents other eGents other eGents Grid eGents platform** eGents platform* eGents platform inform inform subscribe inform subscribe subscribe * Java-based ** KVM-based - runs on Palm uses J2ME CLDC 1.0 FCS (KVM), that is, Java for devices runs on a "wireless" palm over the CDPD digital cellular network Email Server All eGents can share one Email server or they can each have their own or anything in between

20. OBJS eGents: Agents over Email Miami demo: standalone - 18 month demo: integrated w Process Panel & MBP