CoABS Grid Component: MultiLevel Coordination Agent

advertisement
CoABS Grid Component:
MultiLevel Coordination Agent
Edmund H. Durfee (PI)
Brad Clement, Pradeep Pappachan,
and Jeff Cox (GSRAs)
University of Michigan
August 2000
The Problem
• Networked execution infrastructure permits
distributed, asynchronous initiation of tasks
• Tasks originating from different sources might
impose conflicting conditions on resources,
services, and states of the world
• Exactly which conditions matter might be decided
during execution, and change dynamically
• Identifying which (often few) conditions require
coordination (typically negotiation), when, and in
what (temporal) combinations is non-trivial
• Negotiating over everything “just in case” can be
wasteful, possibly myopic, and pose scaling
difficulties
Manifestation in Coalitions
• Joint Mission/Exercise with objectives/
responsibilities distributed among multiple
functional teams with their own human and
computational agents
• Operational choices by a functional team can
unintentionally (infrequently) affect what others
should or even can ultimately do (e.g., friendly fire)
• Grid service to ensure that these interactions are
efficiently predicted and effectively resolved
• Resulting joint plan should:
–
–
–
–
Support efficient (fast, parallel) execution
Preserve room for some local run-time improvisation
Avoid unnecessarily costly actions
Require realistic runtime messaging load
Example Coalition Scenario
Example Coalition Plan Libraries
LOGISTICS
MOVE CARGO (C1,C2)
AF -> DEST
LHQ ->AF
FLY C1->AF
FLY C1->AF
C1->P
C2->F
C2->F
C1->P
FLY C2->AF FLY C2->AF
G->F
RS->P
AF->RS
RS->P AF->G
CONSTRAINTS:
1. AF USAGE REQUIRES AF CLAIM
2. TD USAGE REQUIRES TD CLAIM
AF->G G->F AF->RS
Example Coalition Plan Libraries
AIRFORCE
FLY SORTIES (EHQ, E,C)
ARMYDIV2
OCCUPY EHQ
MOVE B->D
OCCUPY EHQ
MOVE D->EHQ
SORTIE E
SORTIE C SORTIE C
SORTIE E
MOVE D->E
MOVE E->EHQ
CONSTRAINTS:
ARMYDIV1
1. SORTIES REQUIRE AF CLAIM (AIRFORCE)
2. TD USAGE REQUIRES TD CLAIM (ARMYDIV1)
3. TRANSPORT OF TROOPS REQUIRES (ARMYDIV2)
3a. NO AIRFORCE ACTIVITY AT DEST
3b. ROAD FOR TRANSPORT USABLE
MOVE A->RS
MOVE TO P
MOVE RS->P
Example Coalition Coordination
• Given the initial situation, each of the functional
teams is able to formulate a successful plan
• But each of the plans can affect conditions faced
by other plans
• Some selections and timings of activities lead to
failure on the parts of some plans (e.g., shipment
moved by logistics blocks troop movements)
• Coordination invests appropriate effort to impose
just enough constraints on timings and activities to
ensure successful and efficient accomplishment
• Coordination spans:
– Complete sequentialization (turntaking) among teams
– Complex ballet of interleaved and overlapping activities
Main Solution Ideas
• Conditions to meet (on resource assignments,
environmental parameters, etc.) are typically
associated with plans that pursue tasks
• Plans can be represented hierarchically, where
abstract levels summarize the (alternative)
activities they encompass
• Abstract plan spaces can be searched more
efficiently (top-down) to discover potential
conflicts and to evaluate potential resolutions
• Choosing the right level for finding and
resolving conflicts can balance coordination
effort with the quality of concurrent activity and
plan robustness
Top-Down Coordination Search
• Agents model as little as they can about others
• Abstract resolutions obviate the need for deeper ones
• Abstract resolutions leave more room for improvisation
• Reasoning at abstract levels is supported by “summary
information” from the deeper “and/or” plan tree
• Interleaved coordination and execution postpones choices
until they must be made
blocked
temporal
constraints
Tradeoffs
crisper
coordination
lower cost
coordination
levels
more flexibility
Flexibility matters in environments where “plan-then-execute” won’t work
Coordination “crispness” matters when overall elapsed time is critical
Cost matters when bandwidth/computation are slow, expensive, shared
MCA Component Capabilities:
Prior to Planning/Coordination
Analysis of an agent’s library of possible plans:
• Accepts a plan library (HTN, PRS,…)
• Generates “summary information” (pre, in,
and post conditions that must or may hold)
• Generates a temporal constraint network
(permissible temporal relations between
primitive actions)
MCA Component Capabilities:
During Planning/Coordination
Detection/resolution of conflicts between plans:
• Accepts specific choices of plans from agents
• Works top-down to isolate potential conflicts
• Recommends constraints on agent choices (“or”
branches) and on timing (synchronization
messages) to eliminate conflicts
• Given more time, finds “crisper” solutions
corresponding to more complicated (overlapping)
temporal constraints
MCA Component Capabilities:
During Execution
Detection/resolution of conflicts between plans:
• Requests/accepts specific elaborations of plans at
execution (allows postponement until needed)
• Works top-down by “blocking” potentially
problematic abstract plan steps until details are
worked out
• Plan synchronization is accomplished by the
blocking and unblocking imposed by the MCA
• At the cost of increased centralization (among
interacting agent clusters), maximizes runtime
flexibility by adopting a least-commitment strategy
Demonstration
• MCA as applied to our example coalition
scenario (not militarily generated yet)
• Emphasis on coordination among functional
teams that could separately achieve goals
• MCA demonstrated with communication
through files rather than Grid
– MCA also up-and-running on Grid but…
– Combination of C++ MCA, BBN’s proxy code,
the Grid, and Linux is flaky
• Very simple visualization tools
Demonstration (1): Preplanning
• Four independently-planning team
commanders: Logistics, AirForce,
ArmyDivisions 1 and 2 form/hold plan
libraries of alternative SOPs
• MCA advertises coordination service and is
matched to agents who need coordination
• Team agents send libraries to MCA
• MCA sends each agent annotated SOPs
containing summary information
• MCA updates its temporal constraint
network capturing temporal relationships
allowed between plans’ actions
Demonstration (2): Planning
• Agents, having objectives, each select an
abstract plan (and thus hierarchy below)
• MCA receives agents’ plan choices
• MCA conducts top-down search, detecting
potential conflicts and constructing
candidate resolutions at increasingly
detailed levels
• Selection of a resolution performed
(possibly through interface to human
commander)
• Chosen coordinated plan is executed
Demonstration (3): Execution
• Planning interleaved with execution
• Agents send top-level plans to MCA
• MCA permits some to proceed, blocks those
which could cause interference, and can request
plan elaborations (selected by agents)
• Elaborations can be returned after some
execution, postponing choices (least-commit)
• Allows agents to avoid commitment to actions
(e.g., choices of routes) that turn out to be
undesirable as the situation unfolds
Conclusion
• MCA provides a service that will be of use to a
subset of Grid users
• Emphasizes issues of control in ABS where
activities are initiated from multiple sources
• Ongoing/future efforts include:
– Developing quantitative coordination measures
involving cost, flexibility, and crispness
– Introducing metric (non-boolean) conditions
– Extending to non-episodic coordination problems
– Characterizing how different hierarchical plan
structures impact coordination efficiency/quality
– Caching coordination decisions for reuse
– Formulating militarily-relevant test cases that
examine potential coalition process improvements
Download