of 32 /32
CoAX Technology Contributions CoAX Technology Contributions AFRL Rome, AIAI, Boeing, Dartmouth, DERA Malvern, AFRL Rome, AIAI, Boeing, Dartmouth, DERA Malvern, Lockheed Martin ATL, Michigan, MIT Sloan, OBJS, Lockheed Martin ATL, Michigan, MIT Sloan, OBJS, USC/ISI, UWF/IHMC USC/ISI, UWF/IHMC Support from BBN, GITI, ISX, MITRE, Schafer, Stanford Support from BBN, GITI, ISX, MITRE, Schafer, Stanford Coalition Agents eXperiment (CoAX) Coalition Agents eXperiment (CoAX) http://www.aiai.ed.ac.uk/project/coax/ http://www.aiai.ed.ac.uk/project/coax/ DARPA

CoAX Technology Contributions

  • Author

  • View

  • Download

Embed Size (px)


DARPA. CoAX Technology Contributions 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) http://www.aiai.ed.ac.uk/project/coax/. - PowerPoint PPT Presentation

Text of CoAX Technology Contributions

Coalition Agents eXperiment - The Coalition TIECoAX /Tech Briefing - *
CoAX Technology Contributions
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)
CoAX /Tech Briefing - *
AIAI Process Panel - Task and Process Management
DERA Master Battle Planning
AFRL/BBN/GITI CAMPS - Air Logistics Support Tool
USC/ISI Ariadne - Open Information Access
UWF/IHMC - NOMADS safe and secure mobile agents
Stand alone demonstrations at 9 months:
MIT Robustness Services
Dartmouth Observer Agent
Michigan Coordination Planning Aid
Note that the term 'surrogate agents' is used to describe proxy agents which stand in for incomplete or unavailable agents.
CoAX /Tech Briefing - *
The CoABS/Infrastructure code provides a framework for integrating diverse agent-based systems, and provides additional common services.
The Grid allows agents to find services and other agents so that agent teams can be dynamically formed to solve context-based tasks.

Registration and advertisement of capabilities.
Discovery of relevant participants, and flexible run-time communications.
Current Grid services include: Logging, Visualization, Security, Instrumentation, Communication, Registration, and Event Services.
Java Platform: RMI, Jini™
An agent domain consists of one or more agents registered with a common Domain Manager which provides for common administration and enforcement of domain-wide, platform-specific, and agent-specific policies.
Broadens typical distributed security concerns to include:
Communication and access management: Who can communicate with whom for what services?
Registration management: Who can join the domain under what circumstances?
Resource management: Who can have which kind and how much of a given computing resource?
Mobility management: Who can move where under what circumstances?
Conversation management: What constraints govern interaction between conversing agents?
Obligation management: Who is not meeting commitments?
Initial capability shown in six-month demo
Initial capability slated for nine-month demo
Initial capability slated for 2001-2002 demos
CoAX /Tech Briefing - *
1. Abstract, mechanism-
neutral representation/XML syntax
Event-driven policy changes
CoAX /Tech Briefing - *
AIAI I-X Process Panel
Initially maintains an overview of the current status the coalition C2 processes in accessible shared military terms.
Later adds the ability to monitor, plan and control the coalition C2 processes.
Can take on and address “issues” in the C2 process.
Links to and assists with domain management, authority, exception management and other Grid management services.
To be packaged as generic task and process management facilities that can be made available to other Grid applications.
CoAX /Tech Briefing - *
Map-based graphical user interface - operator builds scenario and air missions using simple dialogs and “point and click” techniques.
Analyzes plans (identifying over-tasking, GANTT charts, animated flyout facility)
Obtains data on targets and assets from other agents.
Integrates air missions (e.g. air transport) and weather forecasts from other agents into the air visualisation.
Informs AIAI’s Process Panel of current planning status.
CoAX /Tech Briefing - *
CAMPS Mission Planner
Develops schedules for aircraft to pick up and deliver cargo within specified time windows.
Takes into account a large number of constraints (aircraft & port capabilities, crew availability, work schedule rules)
Can be tasked by other agents.
Domain-aware agent obtains scheduled air transport flights and forwards them to Master Battle Planner for integration into the air visualisation.
CoAX /Tech Briefing - *
Provides access to AODB via XML formatted Grid messages.
Supports different kinds of queries: one shot, update, and persistent.
Will be evolving EMAA/CAST technology to create a deliverable generic Grid-aware core agent engine to other end users. This technology will be configurable and is intended to easily allow access to alternative sources.
CoAX /Tech Briefing - *
1. Client sends the Query via a Grid Data Message.
2. Agent Engine receives the Query on it’s Message Queue.
3. Agent Engine processes the Query.
4. Agent Engine creates a Controller Agent.
5. Controller Agent spawns other agents to retrieve data from each of the JDBC sources.
6. Controller Agent generates response message and sends it via the Grid to the Client.
7. Client receives response for processing.
CoAX /Tech Briefing - *
Tools for learning wrappers to extract data for semi-structured sources
Agents learn the structure of data to support:
Source verification
automatically detect when the source no longer provides correct data (possibly because the source has changed)
Source reinduction
automatically revise wrapper when site change
The contributions of our paper are a flexible data representation scheme, and an efficient algorithm that allows us to learn the structure of many common data types using this representation. We use this information for two different wrapper maintenance applications.
The first application, wrapper verification, detects when the wrapper is not extracting data correctly from a Web site, possibly because the layout of the site has changed in a way that breaks the extraction rules learned by wrapper induction system.
The next task is to automatically revise the wrapper, that is learn the new extraction rules, when the site changes.
Although we focus on Web applications, the learning technique can be used to learn about data fields in general. We believe that it is a step towards interoperability among information agent, where agents can exchange data without the need for a pre-specified protocol.
CoAX /Tech Briefing - *
CoAX /Tech Briefing - *
Dynamic and fine-grained resource control
NOMADS enforces security policies specified by the KAoS domain manager
Security policies include limits on CPU, disk, and network resource usage
Resource consumption monitoring
NOMADS Guard constantly monitors the resource consumption of the GAO agent
When the guard detects a potential denial of service, the guard reduces the resource limits available to the GAO agent
CoAX /Tech Briefing - *
Aroma VM
Buildings and other structures
Observations are 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 mis-information.
CoAX /Tech Briefing - *
This slide is just a review of the scenario. I show a vehicle rather than a soldier as the gateway, since in real life, the long-range or satellite hardware is likely to be in a vehicle. There would also be more than one gateway. As noted before, however, the single gateway in our trial run was just a soldier with a second 802.11 card.
CoAX /Tech Briefing - *
MIT Robustness Service
Open systems (like coalitions) include unreliable agents (bugs, malice) and infrastructures
The MIT Robustness Service
Tracks inter-agent commitments
Maintains reliability information (failure avoidance)
Informs registry of hung agents
CoAX /Tech Briefing - *
CoAX /Tech Briefing - *
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 can be proactively executing and utilized by the AIAI Process Panel.
CoAX /Tech Briefing - *
Michigan Multilevel Coordinator Agent
This is a screen dump from our August 2000 demonstration. The scenario is abstractly depicted in the upper right: there are four agents, army-division-1 (AD1), army-division-2 (AD2), logistics delivering cargo C1 and C2, and Airforce. Each is given tasks to complete, and each constructs plans that, if it were alone in the world, would be successful. Because the are unintended conflicts among plans, the plans need to be coordinated. In the lower right is a partially obscured window from the pre-execution phase, where the MCA identified possible conflicts and iteratively developed and proposed possible resolutions. The resolution chosen, leading to changed plans, is partially shown in this window. Once selected, the separate agents receive modified plans (upper left windows correspond to the agents). During execution, particular plan refinements are chosen; depending on refinement choices and the coordination strategy committed to, plans get executed or might be blocked while other agents complete particular plan steps. This runtime process is illustrated in the window in the lower left.
CoAX /Tech Briefing - *
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.
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.
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.
CoAX /Tech Briefing - *
Miami demo: standalone - 18 month demo: integrated w Process Panel & MBP
OBJS eGents:
eGentGridAgent proxy is used to connect (wireless) eGents in the field to grid-accessible agents on a LAN
Demo scenario
PSMs on troops updated with latest status information (geographic, health, threat, …)
other parties (PSM clients like command post or medevac) subscribe and receive inform messages in response to changes
PSM Server is displayed in one Java window
DOS windows show activity of the eGentGridAgent proxy and Grid's log agent
PSM Grid Client is displayed in another Java window
Netscape Messenger shows the log of eGent messages
Demo step-through shows
registering the PSM Server eGent with the eGentGridAgent proxy which then registers it with the Grid
switching to the PSM Client agent, which subscribes to the PSM Server by sending a lookup message to the Grid Registry, which finds the proxy, which the client thinks is the PSM Server, and then sends a subscribe grid message to the proxy, which passes it along to the PSM Server
then PSM Server sends back an inform message containing the subscribed values (and sends updates later if any values change)
the messages thread their way back through the system to eventually be displayed on the client.
If you modify a value on the server, you can watch the update propagated back to the client