Joint Analysis System

Manual Tpfdd - Bse (MTB) is the name for a new capability in JAS that allow users to 'move' bses by deactivating them and then reactivating them at a later time at a different location. These moves can occur at specific sim times or be triggered by knowledge base changes.

Currently MTB data is read from a csv file. The location of this file is specified by the MtBseData setting under the Manual Tpfdd heading in the jasS.ini file. The name of this file is user-specified. Future development will include a gui.

; File:     jasS.ini
; Title:    Settings file for JAS Simulation System
 
[Manual Tpfdd]
MtBseData=C:\Documents and Settings\DefaultUser\My Documents\JAS\bseChanges.csv

There are 15 data fields in the input file:

1. side - a string specifying any side defined in the scenario. Required.
2. isActive - one of (T)rue or (F)alse. Only the first character is considered. Not case-sensitive. Required.
3. deactivateTime - integer or float. Empty means nil.
4. deactivateFactValue - the value passed by the knowledge base action Process MTB. Empty means nil.
5. brigadeKey - a string specifying the name of the brigade that owns the bses.
6. bseId - a string specifying the name of the bse to be moved. Required.
7. appliesToSubordinates - one of I(mmediate), A(ll), or (N)one. Required.
8. activateFactValue - the value passed by the knowledge base action Process MTB. Empty means nil.
9. activateTimeStart - integer or float. The time, relative to deactivateTime or the time when deactivateFactValue occurs, that activation should start. Empty means nil.
10. activateTimeEnd - integer or float. The time, relative to deactivateTime or the time when deactivateFactValue occurs, that activation should end. Empty means nil.
11. commonNamedMapObject - the string name of a common named map object.
12. activationLat - the latitude of the activation location.
13. activationLng - the longitude of the activation location.
14. dispersionRadius - an integer or float value that defines a circle around the activation location into which the bse(s) wil be randomly dispersed. Empty means nil.
15. comments - optional

• A line that begins with a pound sign (#) is considered a comment. Comments are logged and ignored.
• An empty field means nil - no value.
• Side can be any side defined in the scenario. Side determines only which JtfC2 will process the moves.
• A line with isActive set to False will be logged and ignored.
• Neither deactivateTime nor activateTimeStart can be negative.
• DeactivateTime or deactivateFactValue is required.
• ActivateTimeStart or activateFactValue is required.
• A line with both deactivateTime and deactivateFactValue is an error, as is a line with both activateTimeStart and activateFactValue.
• The bse specified by bseId must exist in scenario data and be playing. It does not have to be active. The bse does not have to belong to the specified side.
• A line that has activateTimeEnd must have activateTimeStart.

During sim initialization, the JtfC2 object for each side reads the input file and selects the entries for its side. Each line in the file is checked for errors, the results are logged to the Jas message log, and each line that passes edit checks is stored in the JtfC2 of the specified side as a JwMtBseMove object. JwMtBseMove objects can be activated in two different ways:

• by time
• by the knowledge base

Once the simulation is through with initialization, the JtfC2 object for each side selects all the JwMtBseMoves that have an explicit deactivateTime value. These JwMtBseMoves are scheduled for execution at the time specified.

JwMtBseMoves that have a deactivateFactValue rather than an explicit deactivateTime are scheduled for immediate execution if and when the fact that references them turns true in the knowledge base, and the bse is still alive (not dead and not dissolved).

Deactivation will occur at the time specified by deactivateTime or when the fact specified by deactivateFactValue goes true.

If only reactivateTimeStart is specified, an event will be scheduled to activate the bse at the current sim time plus reactivateTimeStart.

If both reactivateTimeStart and reactivateTimeEnd exist, the difference between them will be calculated, a random number will be drawn, and the product of the difference multiplied by the random number will be added to the current sim time and then used as the time to schedule the reactivation event.

The bse will be reactivated at the location specified by the reactivationLocation or at the centerPoint of the specified common named map object. If dispersionRadius is specified, the reactivation location will be a random point in a circle having the original reactivationLocation as its center and a radius of dispersionRadius meters.

Entries with the same brigadeKey will be deactivated together at the time specified by deactivateTime or when deactivateFactValue becomes true. This time or factValue and all other information related to the 'move' will be the information contained in the first entry with the brigadeKey. All subsequent entries for this brigadeKey need have only the bseId and the isActive columns present. All three bses in the example below will be deactivated at sim time 10 and reactivated when activateFactValue moveBlueAir becomes true.

All the rules regarding randomization of spatial and temporal reactivation described above also apply to bse 'grouped' by brigadeKey.

To trigger resource changes from the knowledge base, first set up a fact that will eventually evaluate to true. This fact should logically be put on the JtfC2 knowledge base for the appropriate side. This example uses a ScheduledEvent that goes true at time = 4.0. On the ScheduledEvent, select Process MT Bses as the action.

Then enter a value in the Requested MT Value field that corresponds to the factValue of the JwMtBseMoves that you want to execute on this fact.

To do

There is currently no specific MT instrumentation. You can see the results of MTB processing in the JAS message log by turning on the MTDebug message category.

• Do we want to add a brigadeKey field to the Bse?
• Should deactivations without subsequent reactivatios, and vice versa, be allowed?

• Gui
• Instrumentation