The Scenario Configuration option provides two options. The first, Timing and Controls, permits the specification of scenario timing and control; the second, Ground Fighting Parameters, supports specification of generic ground combat factors. The timing options will permit the user to select the date and time in which the scenario is set, how fast the simulation should run both in reference to actual time and update intervals, and scenario aggregation information. Selection of the Timing and Controls option brings up the [[http://jforces.com/forces_doc/UserManual/images/32EditingScenarioConfigurat.jpg Editing Scenario Configuration Form]] . This form is used to :
Define targeting sets used by each side (Blue Target Configuration and Red Target Configuration). Clicking on a side will produce the [[http://jforces.com/forces_doc/UserManual/images/snapshot128.jpg Current Target Configuration]] form. From this form the user can choose to Delete Target, Create New Target, and Create New Configuration sets as well as create/edit/delete specific targets in the currently defined target set for either or both sides (Red and Blue). The Modify Target Sector Data bar brings up the [[http://jforces.com/forces_doc/UserManual/images/snapshot129.jpg Target Sectors Form]] that lists the sectors. Selection of a sector brings up the [[http://jforces.com/forces_doc/UserManual/images/snapshot130.jpg Edit Target Sector Form]] .
Define scenario timing. This includes the date and time of day (Zulu reference) to start the scenario, how long the scenario is to run ( Stop Time), and the fast forward time (Fast Forward Time).
The start date and time of day will affect climate, RF propagation (according to sunspot activity), and when day & night occur in the scenario. The fast forward time (Fast Forward Time) is used to "fast forward" a scenario the specified time by moving assets and groups during this fast forward time but not modeling sensor detections, thereby increasing run speed.
Define internal scenario clock parameters including time granularity (Time Granularity), time ratio (Real Time Ratio), and default minimum clock interval (Default Min. Clock Interval). Starting with the most commonly changed parameters, the time ratio affects the desired speed of scenario execution. An entry of "5" (as in the example) implies that the scenario should execute 5 times real time - i.e. a 5 hour scenario should execute in 1 hour. During runtime any white node can modify this initial execution speed as desired through the "System Controls->Clock Controls " interface. Note that as scenarios become large and/or slower machines are used, FORCES might not be able to achieve the desired speed. Indeed, this is one reason to reset the default aggregation level.
The Time Granularity affects the number of times the scenario module is executed versus how often is is executed. If this value is set to 3 sensor modules will be executed only on every 3rd call, thus a sensor with a 12 second scan rate will evaluate scans only once every 36 seconds. This is fine for sensor-rich environments, but not for marginal sensor environments. It also causes very poor tracking results when actual tracking algorithms (e.g. Those used to process sensors with JSS message formats or Detailed SBIRs sensors) are used. NOTE - For most purposes it is recommended that this value is kept as 1.
The minimum clock interval (Default Min. Clock Interval) specifies the minimum internal update used by the simulation. Scenarios will run faster when large update intervals are used, but at the expense of sensor and combat resolution. For example, if a 60000 millisecond update interval is used the detections of a sensor with a 10 second scan rate will be updated only every 60 seconds because this is the lowest clock interval. Typically this value is set to 30000+ milliseconds for larger campaigns, 1000-10000 milliseconds for missions and short vignettes (those under 1 day) and 10 - 1000 milliseconds for detailed scenario execution employing sensor focal plane emulations or hardware/software in the loop experiments. This value can be changed for specific runs by the user at scenario instantiation
Define default aggregation level (Default Aggregation Level ). This default is used when the scenario is started, thought the user can change to an alternative aggregation at runtime instantiation. For information on scenario aggregation click here .
The Minimum Truth Update Interval for Displays. This value is used as to determine the updates on displays and the maximum internal update on asset position updates (though internally the assets might be updated more often to support sensor or engagement functions). It is referred to as the minimum update interval because during runtime it is adjusted according the time granularity, also specified on this widget. The actual update is defined by this value times the time granularity with an update of the maximum truth update interval (defined on the next line). For example, if this value is set to 5 and the the current simulation time granularity is 1 and the maximum time granularity is 60 the sim will update the displays every 5 seconds. It the user changes the time granularity to 3 the sim will update the displays every 15 seconds. If the time granularity is set to 20 the max update limit will kick in and the sim will update the displays ever7y 60 seconds. Generally, this value is kept small (1 or 2 seconds) for scenarios ties to live feeds but is set high (5 or more) for scenarios being run without lie feeds and especially when the scenario is being run in a stand-alone analysis mode.
The Maximum Truth Update Interval for Displays. This value is used as to determine the maximum update for displays using the algorithm described above, under Minimum Truth Update Interval for Displays.
Define the starting random number seed (Starting Random No. Seed ). This is used to instantiate the random number generator to guarantee repeatable scenario executions while supporting the generation of statistical databases over defined multiple runs. To generate multirun databases the batch_run utility should be used.
The second Scenario Configuration option (Ground Fighting Parameters ). provides an interface to tailor the [[http://jforces.com/forces_doc/UserManual/images/2mGroundEngagementTables.jpg Ground Engagement Parameters]] for the scenario. These parameters support specification of generic ground combat factors. These factors address the direct-contact ground engagement algorithm and include the update rate for determining losses, the proximity between units before they automatically engagement, the basic kill rates of the Lanchester equations used for ground combat in the FORCES model, and so on. Selection brings up four Rules and PK Tables: Ground-Ground Engagement Rules; Defender PK Table; Attacker PK Table and Advance/Retreat Table . While the parameters are described below, it's useful to understand the algorithm; Click here for more information on the underlying algorithm.
Selection of the Ground - Ground Engagement Rules bar brings up the [[http://jforces.com/forces_doc/UserManual/images/snapshot131.jpg Ground Engagement Rules Form]] that presents a list of the Scenario Record to Edit.When a scenario is selected (e.g. Ft. Hood) a larger [[http://jforces.com/forces_doc/UserManual/images/snapshot131.jpg Ground Engagement Rules Form]] appears. On this form are six elements that the user can enter data:
The Attacker PK and Defender PK Tables are used to define "typical" losses that should be used for the attackers and defenders in this scenario. As covered in the [[http://jforces.com//programmer_doc/ground_engagement.html algorithm description]] , these losses are based upon an unprotected, unarmored truck and are modified according to terrain, environmental factors, armor, posture and so forth by additional computations external to these tables. The firepower is an independent input to this table and it's calculation is also addressed in the algorithm description.
When the Defender PK Table bar is selected the [[http://jforces.com/forces_doc/UserManual/images/2qTableDescription.jpg Table Description Form]] appears. The edit interface is the standard multidimensional table editing form; the generic procedures for editing this information is described here. Particular information that will help the user in populating this table is the parameter definitions. These are:
Computed Variable: Losses per update.
Independent Var. Values
Attacker Adjusted Gun Co
This is the firepower of the attacker. During the scenario execution it is calculated as the simple rollup of the firepower for each attacker based on the database prototype definition of the armament subsystems onboard each attacker as adjusted by range, weather, etc. An Edit button brings up the [[http://jforces.com/forces_doc/UserManual/images/2rIndependentVariables.jpg Independent Variables Form]] on which the user can Editing Values for: Defender PK baseline, Independent Variable: Attacker Adjusted Gun Co. AnAdd New Value bar allows the user to add a new value via the [[http://jforces.com/forces_doc/UserManual/images/2sNewIndValue.jpg New Ind. Value Form]] .
This is a simple count of the defenders in an engagement. During presimulation the analyst creates this table for a range of possibilities. During scenario execution the module computes the actual # of defenders in an area based on the situation. An Edit button brings up the [[http://jforces.com/forces_doc/UserManual/images/2rIndependentVariables.jpg Independent Variables Form]] on which the user can Editing Values for: Defender PK baseline, Independent Variable: # Defenders.
An Add New Value bar allows the user to add a new value via the [[http://jforces.com/forces_doc/UserManual/images/2sNewIndValue.jpg New Ind. Value Form]] .
Selection of the Attacker PK Table causes a very similar [[http://jforces.com/forces_doc/UserManual/images/2yTableDescription.jpg Table Description Form]] to appear, the only differences being that it's independent variable is the adjusted defender gun count and the result is the expected "typical" attacker losses. Naturally, the input variables and results can differ as desired between the attacker and defender PK tables.
Finally, note that these PK tables are optional. If not filled in the simulation will used default values.
This option permits the user to specify the effectiveness and time for deployment & removal for selected engineering barriers (e.g. Minefields, tank barriers, temporary bridges, etc). Selection of the Define Engineering Barriers causes the [[http://jforces.com/forces_doc/UserManual/images/3gEngineeringBarriers.jpg Engineering Barriers Form]] to appear with the option to choose the Scenario Record to Edit . The minefield representation currently used in JFORCES is a very simple representation that only addresses the region covered, the time to remove or emplace the minefield, and it's lethality. Better models are available upon request.
This is the master control form for specifying whether data is to be kept for scenario runs and, it so, what data will be saved for analysis. If you don't fill in this form you won't save data for analysis. Choosing this item causes the [[http://jforces.com/forces_doc/UserManual/images/3kDefineDataCollectSpecs.jpg Define Data Collection Specs Form]] to appear. Data specifications may be defined on the Define Data Collection Specifications window. Six factors must be identified/defined by the user:
Collect Data - On/Off button. If this is left off (the default) you won't collect data for the run.
Sampling Frequency - sliding scale 1-100. This is actually not a very important entry. This only affects how often data is collected for sensor detections when a sensor is detecting a target. Data on all key events, including sensor detection change status (including all changes from detected to non-detected or vice-versa and all changes in reasons for non-detection) are collected regardless of this setting. The only reason this option is presented is to fill in the sensor/target detection geometry over long detection periods for the " Detection Profile " option of Data Analysis. If you're not intending to use this interface for data analysis it's recommended that you set this value to a large number (e.g. 100). Otherwise you'll use up an extraordinary amount of disk space and slow down the processing of data significantly.
Collection File - Directs user to another form where the user can choose where to save the data for the run. In order to increase run speed and execution versatility the data for runs is saved in a flat file and loaded into the database only when commanded to. The means to do this are described here . But to load this data you must know where the data is stored. This specifies the file.
Message Set - allows user to select the desired message set from a list in the drop-down inset. The user can choose to limit the messages being saved to minimize disk space and improve data analysis performance at the expense of limited information. Very reasonable when you know that you're not going to evaluate data of a specific type. Generally the most demanding messages (those you might want to consider not saving) are: da_snsrdetect (sensor detections), da_bombdropevt (bomb drops), and da_sat_err_detect (satellite detection error analysis data). Also, not that the message set "allmsgson" is a reserved message set - data will be saved for all messages regardless of database settings when this set is selected.
Tailor Data Collection by Class? - Yes/No button. When this is set to Yes the next button will allow the user to specify the class collection set; when set to No the next button will allow the user to select the object collection set.
Object Set ( or Class Set when the button above is set to Yes) - allows user to select the desired object (or class) set from a list in the drop-down inset. The purpose to this interface is to specify the collection of data only on specified assets. Class collection will collect data for all assets of a type; the object select permits greater resolution in the assets you wish to collect data on. Note that the option "allclasseson" is a reserved collection set; when this option is selected data will be collected on all scenario assets regardless of any defined settings in this widget. Currently most users always use this option; it seems that this filtering option is a relic of earlier installations when disk space was always at a premium. Now that it's not many users prefer to collect data on all assets just so they can explore the resultant dataset more freely.
On the lower portion of the form are four bars:
Edit/Create Message Sets
As mentioned above, filters can be
applied to the messages recorded during runtime to limit disk usage.
Be aware the the disk utilization must be balanced against lost
data; after the scenario starts execution if a message was not selected
for collection it can not later be redeemed.
When this option is selected the [[http://jforces.com/forces_doc/UserManual/images/3lCreateEditMessageSets.jpg Create/Edit Message Sets Form]] appears. A list of Current Message Sets is presented each of which may be Reviewed, Edited, or Deleted. Note that the first many messages are written in a subdued color - this implies that the user can not choose to not select them. These are definitional messages and without these many of the data analysis reports would be unable to function correctly. Messages later in the list can be select for collection as the user wishes, though naturally this will affect the report options. For example, if DA_SNSRDETECT (sensor detections) is not selected no reports can be run to determine detection success.
The Create New Message Set bar allows the user to do that. When selected the [[http://jforces.com/forces_doc/UserManual/images/3mEditMessageSet.jpg Edit Message Set Form]] appears.
Edit/Create Class Collection Sets
Again, as mentioned above, filters based
on the class of asset performing an operation can be applied to the
messages recorded during runtime to limit disk usage. Be aware the
the disk utilization must be balanced against lost data; after the
scenario starts execution if data on a specific class of asset was not
selected for collection it can not later be redeemed.
When this option is selected the [[http://jforces.com/forces_doc/UserManual/images/3nEditClassCollectionSets.jpg Create/Edit Class Collection Sets Form]] appears. A list of Current Class Collection Sets is presented each of which may be Reviewed, Edited, or Deleted.
The Create New Class Collection Set bar allows the user to do that on the [[http://jforces.com/forces_doc/UserManual/images/3oEditClassDataCollectionSets.jpg Edit Class Data Collection Sets Form]] that appears. The Names of the classes are listed - each with an Off/On button. On the Class Collection Set line the name of the collection set is typed.
Edit/Create Object Collection Sets
Again, as mentioned above, filters based
specific assets performing an operation can be applied to the messages
recorded during runtime to limit disk usage. Be aware the the disk
utilization must be balanced against lost data; after the scenario
starts execution if data on a specific asset was not selected for
collection it can not later be redeemed.
The Create New Object Collection Set bar
allows the user to do that on the
[[http://jforces.com/forces_doc/UserManual/images/3qEditObjectDataCollectionSets.jpg Edit Object Data Collection Sets Form]] that appears. The Names
of the objects are listed - each with an Off/On button. On the Object
Specify Assets for Detailed Detection
This permits the user to specify the
assets for which detailed detection monitoring is maintained during
runtime. Only assets on this list (or subsequently specified
during the execution) will be shown on the umpire's "Detailed Detection
here for more info) or the runtime "Detailed Sensor Detection"
here for mode info). This interface lists the assets already
identified for detailed sensor monitoring and the option to change the
entries to this list. Selecting the "Add" button will result in
being presented a list of platform types currently in the scenario.
Picking one of these platform types will bring up a list of all
assets of that type in the scenario from which the uer can select one
or more for monitoring and then save his selections.
Double-clicking on any asset in the list will permit the user to
delete the asset from the monitoring list or change the "intent"
description. The "intent" description is free-format and has no
effect on the scenario execution; this field just provides reference
information displayed on the the umpire's "Detailed Detection Monitor".