CoABS Grid Component: MultiLevel Coordination Agent

1. CoABS Grid Component:MultiLevel Coordination Agent Edmund H. Durfee (PI) Brad Clement, Pradeep Pappachan, and Jeff Cox (GSRAs) University of Michigan August 2000

2. 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

3. 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

4. Example Coalition Scenario

5. 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 AF->G G->F AF->RS CONSTRAINTS: 1. AF USAGE REQUIRES AF CLAIM 2. TD USAGE REQUIRES TD CLAIM Example Coalition Plan Libraries

6. AIRFORCE ARMYDIV2 FLY SORTIES (EHQ, E,C) 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: 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 ARMYDIV1 MOVE TO P MOVE A->RS MOVE RS->P Example Coalition Plan Libraries

7. 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

8. 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

9. blocked temporalconstraints 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

10. crisper coordination lower cost coordination levels more flexibility Tradeoffs 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

11. 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)

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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