Coordination Artifacts in MultiAgent Systems

1
Coordination Artifacts in Multi-Agent Systems

• April 19, 2005
• IEEE KIMAS 2005
• Sarah Siracuse, John Zinky, Richard Shapiro
• Ssiracus_at_bbn.com, jzinky_at_bbn.com,
  rshapiro_at_bbn.com

2
Agenda

• Motivation for Coordination Artifacts in MAS
• Coordination Artifacts Designs Benefits
• Separation of Function Coordination logic vs.
  Domain logic
• Implementation of Coordination Artifacts using
  Cougaar
• Works well in Tightly-coupled Systems
• Performance Analysis QoS Opportunity
• Conclusions

3
Motivation for Coordination Artifactsin MAS

• Coordination observations
• MAS application
• Cougaar agent architecture
• 1000 agents on 100 hosts
• Many different kinds of implicit coordination in
  heterogeneous systems
• Coordination implementation
• Mixed in with domain logic
• Spans lots of places in the code

• Coordination Artifact
• Separates coordination implementation from domain
  logic
• Distinguishes between various kinds of
  coordinations
• Has state

4
CAs Separate Coordination Activityfrom Domain
Processing
Agent

• Objective Coordination (Outside Agent)
• Coordination encapsulated
• Outside domain logic
• Environment-based
• Mediated communication
• e.g. Ant trails

Agent
Agent
Agent
Agent
CAs

• Subjective Coordination (Inside Agent)
• Coordination mixed in with domain logic
• Dialog-based
• Direct Messaging
• e.g. TCP/IP, Instant Messaging,FIPA Agent
  Communication Language

5
CAs are First Class Entitiesthat coordinate
Interaction between Agents
Defines roles
Coordination Artifact (CA)
Agent
Agent
Role-players
Shared state
Agent
Agent

• Coordination Artifacts CAs
• Are first-class entities in MAS
• Define explicit roles for role-players
• Offer shared state between the role-player the
  CA
• Coordinate behavior among role-players
• Have distributed implementation

6
CAs Unify Agent-to-Agent andAgent-to-Environment
Communication
Persisted Storage
Other Agents
Physical Environment
Agent
Sensor Coordination
Inter-Agent Coordination
Server CA
Client CA
Non-Agent Systems
7
Agenda

• Motivation for Coordination Artifacts in MAS
• Coordination Artifacts Designs Benefits
• Separation of Function Coordination logic vs.
  Domain logic
• Implementation of Coordination Artifacts using
  Cougaar
• Works well in Tightly-coupled Systems
• Performance Analysis QoS Opportunity
• Conclusions

8
Cougaar Components ImplementAd-hoc Coordination
Remote Agents
Agent
Net
Physical Environment
Agent Domain Logic
Inter-agent Messaging Components
Sensor Comp
Agent Blackboard
Sensor Plugin
Comm Plugin
Client Plugin
Server Plugin
Client Libraries
Server Libraries
Non-Agent Systems
9
Distributed Coordination ArtifactsLayered Over
Cougaar Components
CA
Agent B
Agent A
Rule Engine
Rule Engine
Fact Base
Fact Base
Fact
Fact
Black- board
Black- board
Relay
Relay
Logic Provider
Message Transport
Logic Provider
Message Transport
RMI
Host A
Host B
10
Coordination Artifacts work bestin
Tightly-Coupled Systems

• Tightly coupled (Ideal CA applications)
• Long Term Relationships
• Group relationships
• Push meta-data in anticipation of need
• E.g. Cougaar with Coordination Artifacts

• Loosely coupled (Bad fit for CAs)
• Transient Relationships
• Pair relationships
• Pull meta-data when needed
• E.g. Web-Services

11
Coordination Performance Depends onUnderlying
Topology and Resources
12
Coordination Performance Depends onUnderlying
Topology and Resources
13
Coordination Performance Depends onUnderlying
Topology and Resources
14
Coordination Performance Depends onUnderlying
Topology and Resources
Tick Sync Coordination
S
15
Coordination Performance Depends onUnderlying
Topology and Resources
16
QoS Adaptation via CAs
CAs can dynamically change the topology as the
network and/or the roles change.
17
Conclusions

• CAs present a formal model for coordinated
  communication
• Blackboard-based, not FIPA message-based
• Ease use of blackboard-based MAS
• Unify Blackboard interfaces, including Web
  Services
• Correlate multiple changes to blackboard objects
• Partition the blackboard for domain and system
  reasons
• Separation of Coordination and Domain processing
• Make the intermediary a first-class entity
• Place to add QoS-adaptation
• Future Work
• Might facilitate reuse or composability of
  coordinations
• Might examine them in off-line analysis
• Might support code generation