Toward Practical Knowledge-Based Tools for Battle Planning and Scheduling

1. Toward Practical Knowledge-Based Tools for Battle Planning and Scheduling Lakshmi Rebbapragada Army CECOM John Langston Austin Information Systems Alexander Kott Larry Ground Ray Budd BBN Technologies Views expressed in this paper are those of the authors and do not necessarily reflect those of the U. S. Army or any agency of the U.S. government.

2. Outline • Problem • The CADET System • Key Engineering Decisions • Challenges Ahead • Other Domains

3. Problem • Building an operation (e.g., battle) plan for a large, complex, military force, e.g., US Army Brigade or Division • Performed by a planning cell • Trucks, tents, maps, acetate sheets • Begins w/ Cmdr sketch and statement • Follows Military Decision Making Process (MDMP) • Most time-consuming steps: COA development, analysis • Challenge: tasking, allocation, synchronization • Challenge: estimations of time-space, resources, consumption, attrition

4. Example of a Battle Plan-Schedule – Synch. Matrix Timeline (H-hours) Classes of tasks Tasks w/ time, place, resources

5. Example of an Order Resources (units) Tasks w/ time, place, resources Terrain features, units, reference lines

6. The Function of CADET CADET • Key Inputs: • COA Statement (object-represented, 5-10 main activities) • Friendly assets, strength, location • Enemy COA, assets, strengths, location • Environment (terrain, etc.) • Key Outputs: • Detailed Plan • 200-500 activities • all BOS’s • timing, synchronization • assets allocated • Estimates • attrition • consumption Application domains: US Army Div, Bde operations, intel ops… Intended users: Bde planning staff officers Role: COA analysis/ wargaming of the US Army MDMP Tool sponsors: Army CECOM, BCBLs, DARPA

7. How CADET is Used OPORD, OPLAN, FRAGOs are generated and issued Using COA Entry tool, officer enters digitized operational concept: sketch and statement The staff reviews and modifies CADET’s products COA Entry COA Entry sends digitized COA sketch and statement to CADET CADET CADET generates detailed, synchronized plan and estimates

11. A Key Engineering Decision: Interleaving Challenge: strong coupling of multiple problem aspects • planning affects scheduling • scheduling impacts suitability of activities • both impact routing • routing impacts the required activities • attrition and consumption impact activities, timing Significant: enemy acts as the key factor in this strong coupling

12. Interleaving: “plan a little, schedule a little…” planning • interleaved increments of planning, routing, time estimating, scheduling, estimates of attrition / consumption • small increments rely on assumptions based on prior decisions • size of an increment: larger is less informed, smaller – less optimal • experimental compromise: 10-20 activities, also convenient for user’s review scheduling movements attrition logistics

13. A Key Engineering Decision: Action-Reaction-Counteraction Challenge: enemy has a critical vote in every decision; movements and action of enemy units impact all aspects of the problem Our approach: • Decided against game-theoretic approaches • Adopted a known manual heuristic: A-R-C • For each Action (Friendly), estimate the likely Reaction (Enemy), then produce Counteraction (Friendly) • Each Reaction or Counteraction may be complex • Not the same as a 2-ply game! • Further “plies” not valuable • CADET extends A-R-C by parallel planning for both friendly and enemy forces

14. A Key Engineering Decision: UI Independence • On one hand: • A decision-support system is 80% about UI • You need UI for a good demo and to get $$ • On the other hand: • Too many people building similar-looking UIs • Good UI leaves no money for good AI • A deployment environment would have its own UI • Can conventional UI concepts apply to this problem (time, stress, representation)? Need new concepts

15. UI Independence ASAS-L, BCBL-L • Bare-bones UI for developers and demos • Rigorous avoidance of UI assumptions • XML-based, flexible engine for inexpensive integration w/ UI • Integration w/ a number of systems with different UIs BPV, Army CECOM COA Creator

16. Extreme demands on KB maintenance: In the field By non-programmers A partial answer: Simple templates No provisions for programming A 70% solution? A route should be selected so that the unit moves through the destination area An objective area is required The unit candidate criteria, and BOS are specified Maneuver unit advance logic should be used to model the unit movement Given that the seize is supported, the domain expert assesses that the unit performing this task will receive only 90% of the attrition of a normal engagement Challenges Ahead: Field Maintenance of Knowledge

17. Challenges Ahead: Distributed Collaboration • Must provide for: • Multiple users – integrated plans • Partial plans by coalition members • Capture, resolve inconsistencies • Asynchronous • Geographically dispersed • No, it’s not about a better electronic white board

18. Challenges Ahead: Dynamic Continuous Replanning • Once execution starts, the battle plan immediately deviates from reality • Ideally, commanders and staff would like to perform rapid replanning within execution • Performance of algorithms is not critical • Manual input of commander intent, concept is critical • Understanding of execution stability is critical

19. AA Whiskey AA Whiskey TF Snake SF ISB ISB RP 7 drop Team 2 & 6 drop Team 1 TF Hawk TF Hawk drop Team 5 drop Team 3 & 4 AA Sierra AA Sierra TF Falcon TF Falcon Other Domains: Robot-Human Teams in Special Ops • 16 units/teams • Robots • TacAir • Helos • Ground elements • Indirect fire sets

20. Other Domains: Disaster Response At the City-County Emergency Operations Center, the staff monitor and visualize the situation: multiple coordinated terrorist attacks in the City The system produces recommendations as a detailed schedule of tasks: resources and supplies; temporal dependencies; need for resupply and rest; safety of the respondents; balances immediate response vs. downstream needs the system considers routes and movements of the units “juggled” from site to site, accounting to availability of roads and bridges, flows of refugees, etc.

21. An instructive example of a (common) real-world, non-decomposable problem Interleaving can be an effective practical approach to such problems A-R-C heuristic is useful for adversarial problems and may have strong theoretical justification UI is not always a good investment Key remaining challenges: distributed collaboration and dynamic, stable replanning Intriguing possibilities in other problem domains Conclusions

22. BACKUP SLIDES

23. Interleaving and Backtracking Minimal or no backtracking: • Infeasibilities are best resolved by the user, and only after he sees “the whole” • Often accepted and even expected • Clean resolution often calls for change in sketch-and-statement Look-ahead and non-sequential expansion: • Unlike simulation or wargaming • Heuristics for focusing on most critical activities first • Not necessarily sequential to those already planning

24. Architecture for Interleaving exists XML Engine -translates in/out -Xerces, Xalan To be Collab. Analyzer, Merger In-Execution Replan Analyzer • Expander/Scheduler • interleaved process Synch Matrix Interface Temporal Constraint Mgr End-User Task Modeling Tool Task Models -expansion methods - timing, resources Route Calculator -fast -multi-var optimiz. • Attrition Calculator • Fast • Calibrated • Incl. Timing…