toward practical knowledge- based tools for battle planning and scheduling alexander kott larry...

24
Toward Practical Knowledge-Based Tools for Battle Planning and Scheduling Alexander Kott Larry Ground Ray Budd BBN Technologies Lakshmi Rebbapragada Army CECOM John Langston Austin Information Systems 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.

Upload: crystal-stokes

Post on 31-Dec-2015

216 views

Category:

Documents


0 download

TRANSCRIPT

Toward Practical Knowledge-Based Tools for Battle Planning and Scheduling

Alexander Kott

Larry Ground

Ray Budd

 BBN Technologies

Lakshmi Rebbapragada

Army CECOM

John Langston 

Austin Information Systems

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.

Outline

Problem The CADET System Key Engineering Decisions Challenges Ahead Other Domains

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

Example of a Battle Plan-Schedule – Synch. Matrix

Timeline (H-hours)

Classes of tasks

Tasks w/ time, place, resources

Example of an Order

Tasks w/ time, place, resources

Resources (units)

Terrain features, units, reference

lines

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

CADETCADET

The Function of CADET

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

How CADET is Used

CADET

COA Entry

Using COA Entry tool, officer enters

digitized operational concept: sketch and

statement

COA Entry sends digitizedCOA sketch and statement

to CADETCADET generates detailed,

synchronized plan and estimates

The staff reviews and modifies

CADET’s products

OPORD, OPLAN, FRAGOs are generated and

issued

Eng Co Update Movement plan

ADA Team B Provide coverage for area

Eng Co Reconnaissance for Movement to contact

Eng Co Move along route with Advanced Guard

Arty Btry A Re-position to provide continuous

DIVARTY Prep Fire for Attk

Arty Btry B Prep Fire for AttkDIVARTY Prep Fire for Attk

Arty Btry B Provide coverage for area

1-42 DESTROY3 MRP_C

1-44 Follow 1-42

1-42 Tactical March

1-42 Tactical March

1-42 Tactical March

1-42 Uncoil1-42 Cross PL PL SWORD

1-42 Cross PL PL RED

1-44 Cross PL PL SWORD

1-44 Tactical March

1-44 Tactical March

1-44 Tactical March

1-44 Cross PL PL SWORD

1-44 Cross PL PL RED

1-44 Cross PL PL CHICAGO

1-44 Tactical March

Div MI Bn Assess Enemy Force MRP_A

Locate MRP_B with vehicle 2 from UAV

Div MI Bn Assess Enemy Force MRP_B

Launch Sensor

UAV Move along route with Advanced Guard

Sensor Team A Re-position to provide continuous coverage

Sensor Team B Provide coverage for area

UAV PositionObserve And Report with UAV

UAV Position

POL

TOW BGM-71F120MM Mortar25MM shell

1-42 Consumption/Attrition CalculationsWeapons System

Personnel

POL

120MM HEAT-MP-T M830SABOT: 120MM APFSDS-T M829A1120MM Mortar

1-43 Consumption/Attrition CalculationsWeapons System

Personnel

POL

120MM HEAT-MP-T M830SABOT: 120MM APFSDS-T M829A1120MM Mortar

RES Consumption/Attrition CalculationsWeapons System

Personnel

POL

87% 86% 86% 85% 82% 79% 76% 73%

96% 96% 96% 96% 92% 87% 83% 79%96% 96% 96% 96% 92% 87% 83% 79%96% 96% 96% 96% 92% 87% 83% 79%

92% 92% 92% 92% 92% 88% 83% 78%

94% 94% 94% 94% 94% 90% 87% 83%

99% 98% 98% 98% 97% 94% 91% 88%

100% 100% 100% 100% 100% 96% 92% 87%

100% 100% 100% 100% 100% 96% 92% 87%

100% 100% 100% 100% 100% 96% 92% 87%

87% 85% 84% 83% 81% 80% 79% 77%

90% 89% 88% 87% 86% 85% 84% 83%

64% 61% 58% 55% 52% 49% 46% 42%

59% 55% 51% 47% 43% 39% 35% 31%

59% 55% 51% 47% 43% 39% 35% 31%

59% 55% 51% 47% 43% 39% 35% 31%

100% 100% 100% 100% 100% 100% 100% 100%

100% 100% 100% 100% 100% 100% 100% 100%

80% 78% 77% 76% 75% 73% 72% 71%

A Key Engineering Decision: Interleaving

Challenge: strong coupling of multiple problem aspectsplanning affects schedulingscheduling impacts suitability of activitiesboth impact routingrouting impacts the required activitiesattrition and consumption impact activities, timing

Significant: enemy acts as the key factor in this strong coupling

Interleaving: “plan a little, schedule a little…”

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

attrition

logistics

movements

planning

scheduling

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 approachesAdopted a known manual heuristic: A-R-CFor each Action (Friendly), estimate the likely Reaction (Enemy), then produce Counteraction (Friendly)Each Reaction or Counteraction may be complexNot the same as a 2-ply game!Further “plies” not valuableCADET extends A-R-C by parallel planning for both friendly and enemy forces

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

UI Independence

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

ASAS-L,

BCBL-L

BPV,Army

CECOM

COACreato

r

Challenges Ahead: Field Maintenance of Knowledge

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

Maneuver unit advance logic should be used to model the unit movement

The unit candidate criteria, and BOS are specified

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

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

Other Domains: Robot-Human Teams in Special Ops

16 units/teams•Robots•TacAir•Helos•Ground elements•Indirect fire sets

TF Falcon

TF Hawk

ISB

drop Team 1

drop Team 2 & 6

drop Team 3 & 4

drop Team 5

AA Whiskey

AA Sierra

TF Falcon

TF Hawk

ISB

AA Whiskey

AA Sierra

TF Snake

SF

RP 7

Other Domains: Disaster ResponseAt 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.

Conclusions

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

BACKUP SLIDES

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 wargamingHeuristics for focusing on most critical activities firstNot necessarily sequential to those already planning

End-User TaskModeling Tool

Synch MatrixInterface

Collab. Analyzer,Merger

In-ExecutionReplan Analyzer

Temporal Constraint Mgr

Route Calculator-fast -multi-var optimiz.

Expander/Scheduler-interleaved process

Attrition Calculator-Fast-Calibrated-Incl. Timing…

Task Models-expansion methods- timing, resources

XML Engine-translates in/out-Xerces, Xalan

existsTo be

Architecture for Interleaving