Automated Alternate Plans Invocation – Oct 2005


Introduction

This document is intended to be a quick-and-dirty guide to the JFORCES alternate plans invocation module. This module uses specific triggers to:

  1. Move units from one location to another base on perceived enemy actions

  2. Place targets and regions in the ATO generator (start bombing buildups)

  3. Advance or retreat friendly units based on health

  4. Initiate maritime patrols in response to perceived enemy actions

This document is being written before a presimulation GUI is developed. This is because past users have found it easiest to populate the triggers and responses using SQL queries against scenario generation data. When (if) the GUI is developed this document will be updated.


This document is broken into the following sections:


Algorithm Overview

JFORCES incorporates a alternative action algorithm based on perceived enemy activities and states as well as own-side states. The algorithms used are deterministic, but the data driven approach is general enough that this module has been found useful in a wide range of scenarios. The actions currently supported by this module include:

  1. Move units from one location to another base on perceived enemy actions

  2. Place targets and regions in the ATO generator (start bombing buildups)

  3. Advance or retreat friendly units based on health

  4. Initiate maritime patrols in response to perceived enemy actions


This module is a stimulus-response model of command and control operations. This module is limited to the high-level control and does not address detailed command and control issues, such as controlling F-16s in a air intercept. This level of control is handled within the JFORCES framework by tailored modules, such as the Air Defense C2 module for the aforementioned air intercept. The stimuli are simulated commander perception, be it of enemy deployment, activity, or of friendly heath, that causes the simulated commander to order certain responses. There are two major components to this module. The first component is the trigger set.


Triggers

Today, there are few triggers in this module, although JFORCES uses a myriad of triggers in the other control modules mentioned above (e.g. air defense command and control). The two major triggers are:

  1. A number of units (enemy or friendly) in a specified region, and

  2. my own unit’s health.

The number of units in a specified region is the more common trigger. It is useful in responding to enemy actions in an area or reinforcing friendly units. Today, the input is via the a;ternate_plans_criteria database table. Today, there’s no GUI, so I’ll describe the fields for reference since the algorithm’s probably obvious once these fields are understood. The fields are:


Each trigger is single-use; that is each one can only be invoked once in a scenario. No relations are defined between the triggers; they are independent. Thus two triggers can be created with the same criteria to initiate two actions based on the same response. But one action’s invocation can not alter the possible invocation of another action.


FYI, the check_response code in sim/initial/alternate_plans.c file is the master routine for the above triggers.


There’s an additional trigger type to invoke alternate plans based upon own-unit health. This simple trigger runs at preset scenario times and checks the current status of specified units and responds activates commands in accordance with this health. The controlling routine for this trigger is check_attack_continuation in ~/sim/initial/alternate_plans.c. The two database tables that define the trigger are alternate_movement_2 and alternate_movement_2_list. Alternate_movement_2 defines the plan at a top level using the following fields:



The second database table, alternate_movement_2_list, lists the group(s) whose health should be checked within the trigger. By storing this information in a second table the analyst has the option of specifying a group of units to check for a trigger instead of being limited to only one. The fields of this table are:


Responses

Currently responses include:

  1. Move units from one location to another base on perceived enemy actions

  2. Place targets and regions in the ATO generator (start bombing buildups)

  3. Advance or retreat friendly units based on health

  4. Initiate maritime patrols in response to perceived enemy actions

Again, despite the fact that all responses are data-driven, currently there is no GUI to define these operations. So I’ll describe the appropriate database tables.


The alternate_movement database table controls the movement of units from one location to another based on detections of the enemy or own-unit state in an area. In addition this table is used for defining maritime patrols, so the description of some fields will be deferred until discussing that option. This table is the only alternate-plans related table that needs to be populated to activate either 1) movement options based on detections of the enemy, 2) reinforcement to shore up weak defensive positions, or 3) generating maritime patrols based on perceived enemy activities. Note that this does not imply that the analyst does not have to populate the particulars including the route definition or maritime patrol staffing as appropriate. The table fields are:

posture | posturetype

---------+-----------------

1 | Admin. March

2 | Engagement

4 | Move to Contact

6 | OffRoad Travel

5 | Road Travel

7 | Static Defense

3 | Tactical March

8 | Withdrawal


Note that the analyst is responsible for both deploying the assets in the posture for each group type and defining the defensive factor.


The alternate_ato database table provides rules for when to activate an alternate ATO ruleset. In this case the ATO mission is defined the natural way, that is through the ATO GUI in scenario generation, and this table has only the following fields:


The final series of alternate plan responses relate to responses to a own-unit’s health. As described in the trigger section, the trigger for this response is separate from the other triggers and is contained in the alternate_movement_2 and alternate_movement_2_list tables. The response is for one of more groups to move. Multiple groups can be given different commands based on a single trigger, for example commanding a weakened unit to hold for a limited time and then withdraw while telling multiple reserve units to step up and take the first unit’s place. The database table defining the response is alternate_movement_routes. The table’s fields are:



Database Prototyping Interfaces

None


Scenario Generation Interfaces

As described above, there’s currently no presim GUI. The tables that need to be populated are fully described in the Algorithm section.


Runtime Interfaces

None


Applicable Data Analysis

While there are no data attributes tailored to track the invocation and success of alternate plans, some of the standard data collection options have been used to infer the success of alternate plans. These include:

Additional route information is found in da_route_override. This table records all commander overrides of the original plan, which might be used to adjust the success in accomplishing objectives by not counting failure in completing routes if the route was overridden by the commander.