Command and Control Modeling for Joint Synthetic Battlespaces

1. Command and Control Modeling for Joint Synthetic Battlespaces Randall W. Hill, Jr. Jonathan Gratch USC Information Sciences Institute

2. Outline • Synthetic Forces Problem • Hypothesis • Command and Decision Modeling • Supporting Technologies • Status of Work • Maturity of Work • Demonstration

3. Synthetic Forces Problem

4. Motivation • Need cost-effective C2 modeling • Replace / augment human controllers with automated C2 • Represent a wide range of organizations and situations • Need realistic C2 behavior • C2 models must make believable decisions • The outcomes of C2 operations need to be credible

5. Command Force Requirements • Continuous Planning • Understand evolving situations • Achieve goals despite unplanned events • Collaborative Planning • Understand behavior of other groups • friendly forces and opposing forces • Understand organizational constraints • communication, coordination, authority

6. Command Force Requirements • Intelligence (Situation Awareness) • Identify information requirements • Focus intelligence collection efforts • Model intelligence constraints on planning

7. Hypotheses

8. Hypotheses (1) • Realistic C2 models require flexible group behavior • The key to flexible behavior is handling situation interrupts • Understand the nature of the situation and adjust behavior appropriately • Achieve goals in spite of unexpected obstacles

9. Hypotheses (2) • Flexible group behavior requires continuous planning, whichinterleaves • Situation awareness: understand other groups • Planning: plan for groups against groups • Execution: coordinated plan execution • Flexible group behavior requires collaboration

10. Command and Decision Modeling

11. Mission Capabilities • Army Aviation Deep Attack • Battalion command agent • Company command agents • CSS command agent • AH64 Apache Rotary Wing Aircraft

12. CSS HA BP HA FLOT FARP

13. Soar-CFOR Planning Architecture • Support for continuous planning • Integrates planning, execution and repair • Enhances situation awareness • Support for collaborative planning • Reasons about plans of multiple groups • Plan sharing among entities • Explicit plan management activities • Military Decision Making Process (MDMP) • Organizational models • Communication protocols

14. Simulation Architecture Situation Report (understanding) Situation Report (understanding) Battalion Commander Operations Order (plan) …. Operations Order (plan) Operations Order (plan) Company A Commander Company X Commander Situation Report (understanding) Company A Company X …. Pilot Pilot Pilot Pilot Pilot Pilot Helicopter Helicopter Helicopter Helicopter Helicopter Helicopter Actions ModSAF Actions Percepts Percepts

15. Command Agent Architecture Plan Manager Plan Management Plans Management Model Continuous Planner Tactical Plans Tactical Model Situation Assessment

16. Architecture • Planner • Implements continuous planning capabilities • Situation Assessment • Fuses sensors, reports, and expectations • generates and updates current world view • Plan manager • Augments collaborative planning with: • Organizational reasoning • Military decision making process • Domain Theory • Maintains plan management and tactical knowledge

17. Supporting Technologies Continuous Planning

18. Continuous Planning • Implements basic planning functions • Generates plans • Controls execution & coordination of subordinates • Recognizes Situation Interrupts and makes repairs • INPUT: • Domain theory (tasks, plan fragments, assets) • Mission objectives, friendly/enemy plans (from OPORDER) • Existing plans • Current situation (from Situation Awareness)

19. Situation Assessment • Hide information gathering details from Planner • Derives consolidated picture of current situation from: • Radio reports (via 16 CCSIL message types) • OpOrders, SitReps, Status Reps, Replacement Reqs, Flight Advisory, BDA, Request Passage Coordination, etc... • Vehicle Sensors (via MITRE CFOR platform services) • Expectations • expected enemy contact (derived from OpOrder) • frequency of subordinate Status Reps • Rule-based reasoning • Can perform limited sensing actions • e.g.. Request situation reports

20. Situation Assessment Output • List of facts currently true in the world • 16B11 at holding_area ha11 • 16B14 presumed dead • Enemy ADA platoon threatening battle_position bp141 • Target in EA nelson has been attritted • I’ve communicated order76 to 16C11 • I’ve received new orders from my commander • Facts are echelon and unit type specific • Battalion tracks different information than company • CSS unit tracks different information than RWA unit • Determined by domain theory

21. What are Plans? • Hierarchically ordered sequences of tasks • Plans capture assumptions • Column movement assumes enemy contact unlikely • Plans capture task dependencies • Move_to_Holding_Area results in unit being at the HA, (precondition to moving to the Battle_Position) • OPFOR and Co must be at the Engage_area simultaneously

22. Planning Basics • Plan generation • Sketch basic structure via decomposition • Fill in details with causal-link planning • Plan execution • Explicitly initiate and terminate tasks • Initiate tasks whose preconditions unify with the current world • Terminate tasks whose effects unify with the current world

23. Plan Generation Example Current World Attack(A, Enemy) at(A,FARP) at(Enemy,EA) Destroyed(Enemy) Destroyed(Enemy) . . . Engage(A,Enemy) Move(A,BP) at(A,FARP) at(A,BP) at(A,BP) Destroyed(Enemy) init at(Enemy,EA)

24. Situation Interrupts Happen! Current World Attack(A, Enemy) at(A,FARP) at(Enemy,EA) destroyed(Enemy) destroyed(Enemy) active(A) Engage(A,Enemy) Move(A,BP) at(A,FARP) at(A,BP) at(A,BP) destroyed(Enemy) Start of OP active(A) active(A) ADA Attack

25. Reacting to Situation Interrupt • Situations evolve unexpectedly • Goals change, actions fail, intelligence incorrect • Planner detects if change affects plan • Invalidate assumptions? • Violate dependency constraints? • Repair plans in response to ramifications • Retract tasks invalidated by change • Add new tasks • Re-compute dependencies

26. Supporting Technologies Collaborative Planning

27. Collaborative Planning • Reason about plans of other entities • Friendly forces, OPFOR • Reason about interactions between plans • Reason about protocols for resolving conflicts • Reason about my role in the organization

28. Interaction Example Move(A,BP) Engage(A,Y) at(A,BP) at(A,BP) at(A,FAA) Dead(Y) at(gas,FAA) Attack Helicopter Company Plan Operation Begins Move(CSS,HQ) at(gas,HQ) at(gas,FAA) at(CSS,HQ) resupplied(HQ) at(CSS,FAA) Combat Service Support Plan

29. Planning Stances • Authoritative • Order subordinate to alter his plans • Tell CSS to abandon re-supply operation • Deferential • Change my plans to de-conflict with superior • Find a way to work around re-supply activity • Adversarial • Try to introduce conflict in other agent’s plan

30. Plan Management • Must model when to use different stances • Involves organizational issues Where do I fit in the organization • Stances may need to change over time During COA Analysis, adopt an adversarial stance towards ones own plans • Must model how stances influence planning • How do we alter COA generation

31. When to Use a Stance • Model the collaborative planning process • Includes management tasks that modulate the generation of tactical plans • Tasks refer to specific tactical plans • Specify preconditions on changing stance • Includes knowledge of one’s organizational role • Planner constructs management plans • Use same mechanisms as tactical planning

32. Example Management Plan • Explicitly modeling Military Decision Making Process Tasks Stances COA Development Authoritative towards subordinates Deferential towards superiors Adversarial towards OPFOR COA Analysis Authoritative towards OPFOR Adversarial towards self (war gaming)

33. Implementing Stances • Implemented as search control on planner • Plan manager: Takes executing management tasks Generates search control recommendations • Example: Deferential Stance • When giving orders to subordinates Indicate subset of plan is fixed (defer to this) Indicate rest of plan is flexible • Plan manager enforces these restrictions

34. Interaction Example Deferential towards Make CSS Planner defer to Company A’s Plan Move(A,BP) at(A,BP) at(A,FAA) at(gas,FAA) Manager Retract Initial State Move(CSS,HQ) Retract Planner at(gas,HQ) at(gas,FAA) at(CSS,HQ) at(CSS,FAA) Combat Service Support Plan

35. Approach • Encode theory of organizational interaction • Represent stances, authority relationships • Processed by plan manager Management Theory domain independent Plan Manager Management Plans Tactical Domain Theory Tactical Plans general purpose Reasoner (Planner)

36. Supporting Technologies Intelligence Modeling

37. Motivation • Largely ignored intelligence issues e.g. STOW program did model Sensor platforms like JSTARS Information networks like CGS Intelligence system Did not model How information transformed into intelligence Collection management

38. Intelligence critical for realistic C2 • Close interplay between intelligence and COA Development • Intelligence guides COA development • COA development drives intelligence needs • Intelligence availability constrains actions • Some COA must be abandoned if one can’t gather adequate intelligence

39. Intelligence critical for realistic C2 • Intelligence constrains pace of battle • When can a satellite observe? • How long to insert surveillance (LRSU)? • How long before I must commit to COA?

40. Intelligence critical for realistic C2 • Intelligence collection must be focused • Commanders must: • Prioritize their intelligence needs • Understand higher-level intelligence priorities • Provide intelligence guidance to subordinates e.g. Simulation Information Filtering Tool [Stone et. al]

41. Priority Intelligence Requirements • Focus on specification and use of PIR Information that directly feeds the key decisions that will determine the success or failure of the mission • Key component of Army mission planning • Specified in CCIR section of Operation Orders • Specifies what Cdr wants to know about OPFOR • Drives position of sensors and observation posts

42. Brigade Planning (simplified) • Attack 2nd echelon tank division (TD) AA Lincoln • Identify Engagement Area (EA Pad) Should canalize OPFOR and restrict movement • Identify launch time Require 2-hour notice EA Pad

43. PL ECHO Brigade PIR AA Lincoln • When will TD leave AA Lincoln? Verifies enemy intent • When will TD reach PL Echo? Satisfies the need for 2-hour notice Further verifies enemy intent Location of PL Echo driven by PIR 2hrs EA Pad

44. PL ECHO Intelligence Plan Assembly Area LRSU Trigger attack: TD 2hrs from EA Pad SLAR Monitor movement from assembly area EA Pad

45. Final Brigade Plan Decision Point H H-8 H+3 H-10 H+2 SLAR monitor AA Insert LRSU LRSU monitor PL Echo Deep Attack Execute Mission Arrive at EA Break Contact

46. Automating PIR • Identify PIR in my own plans • Find preconditions, assumptions, and triggering conditions that are dependent on OPFOR behavior • Extract PIR from higher echelon orders • Specialize as appropriate for my areas of operation • Derive tasks for satisfying PIR • Sensor placement • Ensure consistency of augmented plans

48. Summary • Realistic, cost-effective C2 modeling • Automate C2 processes • Need flexible, multi-agent planning • Continuous Planning • Integrates situation awareness, planning, execution, and repair • Collaborative Planning • Reason about others’ plans, plan interactions • Represent wide range of organizational interactions using planning stances

49. Status of Work

50. Status • C2 Agent Work To Be Done • Augment temporal • Finish PIR prototype • Sit assessment augmentation • Supporting Documentation • Evaluation • Abstract specification of planner • More work on stances as time avails