JSIMS / ASTT Workshop 14 May 1999 Command and Control Modeling for Joint Synthetic Battlespaces Randall W. Hill, Jr. Jonathan Gratch USC Information Sciences

JSIMS / ASTT Workshop14 May 1999

Command and Control Modeling for

Joint Synthetic Battlespaces

Randall W. Hill, Jr.

Jonathan GratchUSC Information Sciences Institute


Outline

• Synthetic Forces Problem

• Hypothesis

• Command and Decision Modeling

• Supporting Technologies

• Status of Work

• Maturity of Work

• Demonstration


Synthetic Forces Problem


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


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


Command Force Requirements

• Intelligence (Situation Awareness)– Identify information requirements– Focus intelligence collection efforts– Model intelligence constraints on planning


Hypotheses


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


Hypotheses (2)

• Flexible group behavior requires continuous planning, which interleaves– Situation awareness: understand other groups– Planning: plan for groups against groups– Execution: coordinated plan execution

• Flexible group behavior requires collaboration


Command and Decision Modeling


Mission Capabilities

• Army Aviation Deep Attack– Battalion command agent– Company command agents– CSS command agent– AH64 Apache Rotary Wing Aircraft

BP

FARPCSS

HA

HA

FLOT


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


Simulation Architecture

Battalion Commander

Company ACommander

Company XCommander

Company A

PilotHelicopter

PilotHelicopter

PilotHelicopter

ModSAF

Company X

PilotHelicopter

PilotHelicopter

PilotHelicopter

….

….

Operations Order(plan)



Situation Report(understanding)



PerceptsActions PerceptsActions


Command Agent Architecture

Plan Management

Plans

TacticalPlans

TacticalModel

ManagementModel

PlanManager

SituationAssessment

ContinuousPlanner


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


Supporting Technologies

Continuous Planning


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)


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


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


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


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


Plan Generation Example

Destroyed(Enemy)

Attack(A, Enemy)

Move(A,BP) Engage(A,Enemy)

at(A,BP)at(A,FARP)

at(Enemy,EA)

at(A,BP) Destroyed(Enemy)

Destroyed(Enemy)

at(A,FARP)

at(Enemy,EA)

Current World

. . .

init


Situation Interrupts Happen!

destroyed(Enemy)

Attack(A, Enemy)

Move(A,BP) Engage(A,Enemy)

at(A,BP)at(A,FARP) at(A,BP) destroyed(Enemy)

destroyed(Enemy)

at(A,FARP)

at(Enemy,EA)

Current World

active(A)

Star

t of

OP

ADA

Attack

active(A)active(A)


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



Collaborative Planning


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


Interaction Example

Move(A,BP) Engage(A,Y)

Dead(Y)

Move(CSS,HQ)

at(CSS,HQ)at(CSS,FAA)

at(gas,FAA) at(gas,HQ)

at(A,BP)at(A,FAA) at(A,BP)

at(gas,FAA)

Op e

rati

on B

egin

s

Combat Service Support Plan

Attack Helicopter Company Plan

resupplied(HQ)


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


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 timeDuring COA Analysis, adopt an adversarial stance towards ones own plans

• Must model how stances influence planning– How do we alter COA generation


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


Example Management Plan

• Explicitly modeling Military Decision Making Process

COADevelopment

Authoritative towards subordinatesDeferential towards superiorsAdversarial towards OPFOR

COAAnalysis

Authoritative towards OPFORAdversarial towards self (war gaming)

Tasks Stances


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


Interaction Example

Move(A,BP)

Move(CSS,HQ)

at(CSS,HQ)at(CSS,FAA)

at(gas,FAA) at(gas,HQ)

at(A,BP)at(A,FAA)

at(gas,FAA)

Init

ial S

tate

PlannerRetract

Retract

Deferential towards

Combat Service Support Plan

Make CSS Planner defer to Company A’s Plan

Manager


Approach

• Encode theory of organizational interaction– Represent stances, authority relationships

• Processed by plan manager

general purposeReasoner(Planner)

Plan Manager Management

Plans

Management Plans

Tactical PlansTactical Plans

ManagementTheory

domain independent

ManagementTheory

domain independent

Tactical Domain Theory

Tactical Domain Theory



Intelligence Modeling


Motivation

• Largely ignored intelligence issuese.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


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



• Intelligence constrains pace of battle

• When can a satellite observe?

• How long to insert surveillance (LRSU)?

• How long before I must commit to COA?



• 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]


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


Brigade Planning (simplified)

– Identify Engagement Area (EA Pad)Should canalize OPFOR and restrict movement

– Identify launch time

Require 2-hour notice EA Pad

AALincoln

• Attack 2nd echelon tank division (TD)


PL ECHO

Brigade PIR

– 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 PIREA Pad

AALincoln

2hrs


EA Pad

PL ECHO

Intelligence Plan

SLAR Monitor movement from assembly area

LRSU Trigger attack: TD 2hrs from EA Pad

Assembly Area


Final Brigade Plan

Execute Mission

Arrive at EA

Break Contact

DecisionPoint

H H+2 H+3H-8H-10

Insert LRSU LRSU monitor PL Echo

Deep Attack

SLAR monitor AA


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



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


Status of Work


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


C2 Knowledge Base

• C2 knowledge base (KB)– Domain theory for Attack Helicopter Battalion /

Company– Domain-independent planning and collaboration KB


RWA Soar Agents

• Intelligent Synthetic Forces– RWA-Soar pilots capable of taking direction from

C2 agent


Maturity of Work


Maturity

• Conceptually mature (algorithmic)– continuous planning mature

• weak link is search control issues

– collaboration approaching maturity

• Needs work before transition to operational status– robustification– KA issues tools– Are there issues in modeling other platforms?


Demonstration


Demonstration Scenario

• Attack Helicopter Battalion (AH-64)– Battalion Commander– 3 Helicopter Companies

• Company Commanders

• Apache Pilots

– 1 Combat Service Support Commander

• Deep Attack Mission Scenario– Companies move from Assembly Area to Holding Area– Situation interrupt: unexpected enemy forces in Holding

Area– Dynamically re-plan and execute mission

Company A plan

Company B plan CSSplan

Move Move Move

Move Move Move Move

Engage EngageReturn ReturnMove

OPFOR Plan

Move Move

Move

Battalion Tactical Plans

CoDeep Attack

CoDeep Attack

FARPOperations

Documents

JSIMS / ASTT Workshop 14 May 1999 Command and Control Modeling for Joint Synthetic Battlespaces Randall W. Hill, Jr. Jonathan Gratch USC Information Sciences