System Controls - DBA

DBA stands for Data Base Administration and provides GUI interfaces to key data-related activities. These include

1) Running data analysis on stored scenario results and loading data into the database for analysis. Also archiving and deleting run results that are no longer required on-line to keep the database small (thereby improving database performance)

2) Copying, deleting, archiving and restoring scenarios.

3) Importing scenario and configuration data from flat-files (usually from other simulations) into the FORCES database

4) Editing, creating and deleting classes of assets and groups for incorporation into scenarios. Here is where the user can define the performance characteristics for an F-14 (for example) that can then be deployed and employed in specific scenarios. Users are cautioned that changes to definitions (in this case the performance of the F-14) will apply to all instances of that class of asset in all scenarios in that database. While this is usually what is intended, occasionally this leads to unexpected results in other scenarios than the one the user was considering.

Key options are: Scenario Maintenance

Selection causes a menu to appear with the following options.

Delete Old Scenario

Select DB Form appears (Lists databases - one can be selected by choosing Accept). Multiple scenarios can be selected for deletion. You will be asked to confirm each selection. Use care - unless you've previously archived the scenario this is a non-reversible option.

Archive Scenario

Select DB Form appears (Lists databases - one can be selected by choosing Accept) . This function generates an output file in the $DTA_DIR/archive_db directory named scen_(scenario name) (e.g. scen_Fort Hood for the Fort Hood scenario) that includes all scenario-specific information required to reload this scenario into this database at a later time or transfer to another scenario. But it does not confirm that the scenario assets are correctly defined in the destination database - this is the user's responsibility. The reload script does check for the presence of asset definitions when reloading the scenario (e.g. If an A-10 is included in the scenario it checks whether an A-10 is defined). It will notify the user of any omissions, but if the user chooses to reload anyway none of the data related to an undefined asset type (e.g. an A-10 in this case) will be loaded. The asset and group classes must be defined before the data is loaded or the asset deployment and employment information will be lost.

Copy Scenario

Select DB Form appears (Lists databases - one can be selected by choosing Accept). This supports copying a scenario definition so that the copy can be modified to create a variant of the original while preserving the original. Note - this is an unusual interface in that you must first specify the new scenario name and only then can you select the source scenario.

Restore Scenario

Select DB Form appears (Lists databases - one can be selected by choosing Accept) , This is the flip side of the "archive scenario" function, described above. See uses and special notes under that description.

Relocate Scenario

The Relocate Scenario form appears. In it specify the scenario name, a reference point for the original scenario (this can be anywhere, but in practice is most useful if at an interesting point in the original scenario), a destination point, any "stretch" factors that you might desire, and any desired rotation. Given this information the system will move the original scenario by the difference between the original and final point and stretch and rotate the scenario around the final point.


    1. Generally it's best to first copy the original scenario to a new name (using the "Copy Scenario" option on this interface) and then relocate the copy of the scenario since this procedure destroys the original laydown in the selected scenario.

    2. Remember that when you stretch the scenario route timing will be off and may need adjustment. This might also apply to other range-dependent scenario aspects (e.g. ground combat ranges).

Combine Scenarios

The Combine Scenarios form appears, permitting the user to specify two scenario names to be combined and a final scenario name for the resultant combined scenario. The new scenario should not have any preexisting data. The original scenarios will not be modified. As indicated in this interface, there's logically a master and a slave scenario between the two source scenarios. The master scenario will be copied to the new location, intact and with no alterations. The asset, group and similar IDs that might cause conflict between the two scenarios will be modified in the slave scenario by this process.

Note the the wise: This procedure, while tested, is not tested to the rigor I would prefer for this complex of an operation. So try to always make the larger, better defined scenario the master scenario and the smaller scenario the slave (if possible). We've used it extensively, so there's no reason to avoid this operation, but we might find some ancillary tables (e.g. operational tasks) do not alter the slave IDs correctly in the future.

Plan Run

This is the master control specifications for how to run a scenario. It ties together the scenario specifications defined in the mission planner with the timing information (e.g. Default clock speed and update interval) to be used by the executive and the definition files to be used by specific applications (e.g. Recorded flight paths from FAA sources) into a single integrated run definition. This selection brings up the run configuration, software configuration, and utility configuration options. Of these the run configuration option is the most useful and the only one used by non-programming users. Under this option the resides the capability to integrate the simulation timing information, the scenario definition, and the external input files as described before. The other two options are usually disabled and left only as an interface for programmers integrating new software modules and external feeds during the development process. Because these two options are generally modified heavily by the programmers involved when invoked, and because their use is specific to those programmers, these latter two functions will not be described below. But the run configuration option is important for all users.

Run Configuration

Maintain Run Configuration

This is the master function to tie each of the run configuration elements (scenario, timing information and external file inputs) into a single scenario run. Selection brings up the Plan Run Configuration Form with A list of currently defined run configurations by name and specifies the last time the run configuration was used. The user can either select one of these to review/edit by double-clicking on it or select the "Create Run Configuration" option. If a new run configuration is selected the user will be prompted for a name. In either case the Editing Plan Run Form will appear. If an existing run configuration is being edited the data currently stored in the database will be presented, otherwise defaults are used. On the form are listed:

Database Name & Scenario Name - These fields provide the map from the run configuration to the database and scenario that are to be executed. Note that the run configuration name is independent of the scenario name, so the two can be named arbitrarily. This was intended to provide flexibility but has been abused and can cause confusion when the run configuration name matches another scenario. The scenario specified on this form will be used, not the one matching the run configuration name. PLEASE USE CAUTION AND COMMON SENSE. It's up to you, the user, to maintain a reasonably logical pattern that can be understood and maintained. If this button is selected a list of registered scenarios and databases is presented. Note - if you find that a scenario and or database that you know is available is not presented (this happens when the standard FORCES mission planner interfaces are not used and data is loaded through direct DBA techniques) you'll find that the data is missing in either the dblist or scenlist tables in the master control library (usually named adilib). If you know enough to cause and identify this problem you'll probably find these tables self-evident and simple. Also, if you've added a new database remember to modify your ODBC specification (usually in .odbc.ini); FORCES is ODBC compliant and the ODBC specification must be maintained when new data sources are made available.

User Name typed-in. This is not used by the system; it's intended to let user's identify their configurations in a multi-user environment.

DOD Classification typed-in and free format. Use as required to support your facility security requirements.

Utility Files Configuration bar with drop-down window listing all utility files. These are preprocessed files read in to support specific applications. These inputs specify the external flat files that are to be used in the run and are the utility configurations defined under the DBA->Plan Run->Run Configuration->Define Utility File Configuration option, described below. Frankly, only two applications are delivered with the baseline JFORCES that require these tables, and most users are not expected to need these applications, so this is not a key definition for most uses. The two applications that use this interface within the JFORCES baseline are a specialized FAA radar input stream (which has since been superseded by the RAP application), and the maximum usable frequency tables to support the Over-the-Horizon backscatter radar. However, be aware the if other models are incorporated into JFORCES for local requirements, this is a good method to define input files required to support these local needs.

Software Configuration Name bar with drop-down window listing all software configuration names and a "review current choice" option that will bring up details on the current software configuration. These inputs specify some of the optional software modules that are to be used in the run. They are the software configurations defined under the DBA->Plan Run->Run Configuration->Define Software Model Configuration option, described below. Note: Unlike the Utility file configuration, this configuration is very important for most users and definitely affects the scenario execution. Please be aware of the software configuration settings. These are described here.

Replay Configuration Record bar with drop-down window listing all replay configuration records. This allows the user to resume a scenario from a previously saved checkpoint or read in a set of commands issues from an operator workstation in a prior execution and inject these stored commands into this execution. These are the replay configurations defined under the DBA->Plan Run->Run Configuration->Simulation Replay Records option, described below. Notes:

Multi Run Config bar with drop-down window listing all multi Run configuration records. This option allows the user to define changes between multiple batch runs and how many subruns are to be made in each configuration to generate a statistical database. Currently the only available option is to modify the state of the space constellations to reflect the uncertainty of the start conditions, but alternative options can be added to this list as appropriate to the study being conducted. These are the multirun configurations defined under the DBA->Plan Run->Run Configuration->Simulation Replay Records option, described below. Note that this multirun configuration is unnecessary if your intent is to run an identical scenario multiple times with only a variation of the starting random number seed. In this case just use the "onerun" option and start a series of runs using the batch_run utility, described here.

Description typed-in. This is your chance to record the purpose to this run configuration for maintenance and organization.

Define Utility File Configuration

Selection brings up the Utility File Configurations Form with Select Configuration to Edit.This option permits the user to specify files containing radar returns from external sources in JSS format along with a file mapping the sensor IDs to the scenario elements for replay during scenario execution and input precomputed (or empirically derived) maximum usable frequency values for selected sensor sites, again to support scenario execution. Other external file inputs might be added to this list for specific study support needs by clicking on Create Utility File Record bar and typing the name on th e form that appears.

Define Software Model Configuration

This widget allows the user to select the some of the simulation modules to be employed in this run. The reason some is specified here is that many of the modules are automatically invoked (or not) according to the scenario specification. Thus, if no aerial refueling aircraft are in the scenario the aerial tanking module will automatically not be invoked. This lists only the optional modules organic to FORCES (external interfaces are not specified here) that are compiled into the simulation (there are compiler options for incorporating or eliminating software modules at link time).

Selection brings up the Software Configurations Form with Select Configuration to Edit.The configurations are listed by name and active models. Double-clicking on an entry will bring up a list of the modules so that they can be selected. Current options are:

C2 Module - This is the Automated Air Defense Module built upon the rules provided in 1990 by the 1 st Air Force air controllers and documented in the ADISC2 Programmers Manual from 1992.

C2 Tracker - This function is a subcomponent of the C2 Module that looks for multiple sensor returns in a line and postulates an air track accordingly. This function was built to automatically created air tracks from raw radar returns (e.g. JSS format messages). After instantiation the tracks are maintained through an alpha-beta tracker.

Detailed MW SBIRS Model - Invokes a detailed medium wave infrared sensor model appropriate to space surveillance. This module models infrared returns on the individual pixels of a focal plain. This model is best used either with an external software- or hardware-in-the-loop tracker or with the SBIRs tracker options (also on this list)

DTED LOS - this flag determines whether Digital Terrain Elevation Data (DTED) should be used in line of sight computations. If turned off the Earth will be modeled as a smooth sphere and only detection will be limited only by the horizon on this sphere. If turned on the best local data in the $DTED_DIR will be used (currently the baseline is limited to DTED 0, I and II).

GNET & STRATCOM (listed last on the this form) - These flags indicate that either the GTE communications network model or Stratcom communications model (very detailed link-level propagation calculations) will be used. If both are turned off the "perfect" communications model will be used. The perfect comm model will model the following limitations:

NWARS output - This option will generate MIDB, SIDB, event and TacElint reports for use by a confederated NWARS simulation. Note that to use this you'll also need to have a writable $DTA_DIR/NWARS directory and have populated the NWARS_amplification database table.

Onboard and Remote SBIRs Tracker - these are trackers that create and maintain angle-only tracks based upon hot-spots on Space Based Infrared Sensor focal planes. These models are usually tied to the detailed MW SBIR model, listed above, though the can be driven by externally-generated focal plane results if the experiment has this information.

Perfect SBIRS Threat Correlator - Basically, when this is turned on the missile defense tracker is bypassed and actual flight profile from the threat is displayed to the user and used by the NMD engagement module. Otherwise a detailed series of 2D trackers at every station and satellite and a 3D data fusion algorithm is used.

Printed Reports - This commands the automatic printing of engagement reports and periodic force SitReps. This is used to support staff and other live exercises.

Simplified A&MD Model - This invokes a simple air and missile defense model in which instead of discretely modeling each engagement results are looked up from data tables populated from other runs (currently EADSIM) to determine the probability of killing an attacker at key times including missile busing, cruise missile launch, and just prior to impact for all bombs, bombers, RVs, and cruise missiles.

Simplified Fuel Attrition Model - This just bypasses the fuel attrition model that normally kills any flying aircraft that runs out of fuel and instead simply immediately refuels the asset. This is useful when tanking operations are not considered essential to the study and nobody wants to plan for refueling.

Define Simulation Replay Records

This widget permits the user to specify methods for restarting or running a scenario. Usually scenarios are run based upon the data currently in the database. But this is not always desired. FORCES permits users to create "checkpoints", that is memory images of the scenario in mid-run, so that later runs can start from this point for alternative action analysis. Restarting from a save checkpoint is referred to as "hot start". Additionally, FORCES allows users to restart the scenario from the database but inject a saved list of commands from one or more operator workstations as though the operators are at their stations without requiring their presence. In this case the umpire has a control to dynamically turn off these canned commands in subsequent runs whenever this original actions are deemed inappropriate. It should be mentioned that replaying presaved command scripts is only likely to be valid when the database is identical between the initial and subsequent run. Selection brings up the Replay Configurations Form with Select Configuration to Edit.Selection of a replay configuration permits the user to specify data sources (or where to save the data if the commands are to be saved or a checkpoint file is to be created at a specified time. In addition to predetermining when a checkpoint file is to be saved, the umpire has the ability to dynamically save one or multiple checkpoints throughout an interactive execution. Be aware, though, that disk space might be an issue; each checkpoint required 100MB+ of space. Other replay records may be added to this list for specific study support needs by clicking on Create Replay Record button and typing the name an the form that appears.

Click here for more information about replay and hotstart options.

Define Multiple Run Configurations

This option allows the user to define changes between multiple batch runs and how many subruns are to be made in each configuration to generate a statistical database. Currently the only available option is to modify the state of the space constellations to reflect the uncertainty of the start conditions, but alternative options can be added to this list as appropriate to the study being conducted. Selection brings up the Multi-Simulation Run Configurations Form with Select Configuration to Edit. The configurations are listed by name and total number of iterations. Selecting on one brings up the Editing Multi-Run Record(s) form that permits the user to specify the parameter to change, how much it should be changed between each collection cell (minimum and maximum values), and the number of runs to make per cell to generate a statistical database. Be aware some users make multiple runs for statistical analysis by bypassing this function (always specifying "onerun") and using scripts based on the "batch_run" utility described here .Other external file inputs might be added to this list for specific study support needs by clicking on Create Multi Run Record button and typing the name on the form.

Run Results Maintenance

This option permits users to delete, archive and restore runs. The runs referred to are the collections of data saved for analysis either during or after a run. These three options are provided because after users save the data from a few runs the list of on-lines runs often becomes tedious and confusing to sort through to find a specific run of interest. Additionally, the database performance will improve be archiving and deleting runs no longer of immediate interest - they can always be restored later.

Delete Runs

Select DB Form . Initially a database list is presented. Subsequently a list of runs currently on line in the database are presented. The user can select run(s) to delete by clicking on each run to be deleted. Note - if you think you will later want to restore any of these runs archive the run make sure you archive the run BEFORE deleting it. When a database is selected, the DB Maintenance - Clean out old runs form appears with the ID, Scenario and Description listed.

Archive Runs

Select Database Form . Initially a database list is presented. Subsequently a list of runs currently on line in the database are presented. The user can select run(s) to archive by clicking on chosen run. Note - if you think you will later want to restore any of these runs archive the run make sure you archive the run BEFORE deleting it. A file of named in the form "run_(run ID)" will be created in the $ARCHIVESCEN_DIR directory, this directory defaults to /data/archivedb. This file can then be backed up as desired or copied to other machines for reloading via the restore function.When a run is selected, the DB Maintenance - Archive Runs form appears with the ID, Scenario and Description listed.

Restore Runs

Select Database Form. This is the means to restore an archived database into the on-line databases. Initially a database list is presented. This specifies the database the run is to be reloaded into (note that this need not be the same database as the run was archived from) Subsequently a list of runs currently stored ARCHIVESCEN_DIR directory (this directory defaults to /data/archivedb) is presented. If there are no runs in this directory an error dialog will appear. Otherwise the user will be allowed to specify runs to be restored by double-clocking on them. When a database is selected, the DB Maintenance - Restore Database form appears.

Edit Icons

FORCES is a heavily data-driven model. This extends even to permitting the user to specify the icons to be displayed for every asset, group or target type (also called a class). This interface permits the user to specify the bitmap to be displayed, the bitmap's size, and whether the icon should be rotated to indicate the simulated entity's orientation. Many users find it easier to create the bitmap in another tool (e.g. "gimp", which is provided with every FORCES Linux load) and map the icon files to the entities directly in the database. For those who wish to do this, they can skip this interface and modify the contents of the "icon_map" database table directly.

Note that

  1. The icon/entity map must be made for EACH scenario database you're using

  2. If no icon is attached to an entity (either asset, group or target class) the entity WILL NOT appear during the execution. This is a common problem when new platform types, etc are created.

  3. If you choose to rotate an icon the orientation will be set with the top of the icon map as the the front of the icon. Therefore draw the icon however you it to look when heading due North.

  4. The icon drawing routine "squares" the icon bitmap. This means that, unless you're planning on the icon being drawn distorted from what you see, always draw square icon files. Also, due to memory limitations you'll want to draw small icon files - about 32x32 pixels is usually sufficient.

  5. Currently icon maps are drawn as GIF files and really only uses two colors. White is replaced by the side color (red, blue or white) and black is transparent.

Icon Editor Form lists the Icons by:

- Name This is the name of the Asset Class, Group Class, or Target Class

- Type This can be Asset, Group or Target. In each case class is understood.

- Icon This is the filename associated with the icon. These files are stored in the $BITMAP_DIR, By default during installation this is the /data/bitmaps directory.

Highlighting an icon causes the Icon Editor Form to expand with further options available.

Near the bottom of this form the user may click on the Edit Icon Bitmap bar.
Clicking on this option causes a bitmap Form to appear. On this form the user may restructure the designated icon or create a new one. Clicking on "Create New Bitmap" causes a bitmap Form to appear. On this form the user may create a new icon.

Data Import

FORCES can read input data from external source. Then Data Import Form lists the data in ten categories:

Selecting one of the categories (e.g. Targets) brings up a Select (Target) Defn Source File Form where the Filename and Directory may be identified by the user. Because the interface is modified for different source specifics won't be discussed here.

DB Prototyping

This is a key element of data population. Selection brings up a form with the user definable attributes of nine categories:
  1. Platform Class Definitions - including Display All Platforms and Platforms by Category.
  2. Subsystem Definitions - including: Armament, Avionics, Boosters, Comm Jammer, Comm Suite, FC Radar, Guidance, Sensors, Sensor Jammers. Tankers, Trackers, Transponders, and Warheads.
  3. World Wide Terrain Definitions - include rivers. This does not include elevation data, which is automatically used regardless of these inputs whenever the " DTED LOS " model is selected in the Mission Planner and the DTED data is provided in the $DTED_DIR directory (this defaults to /data/DTED).
  4. Edit Target Classes
  5. Clutter Type Definitions
  6. Group Class Definitions
  7. Generic Performance & Signature Tables
  8. Operational Readiness
  9. Plan Air Packages
  10. Copy Between DBs

Specific options are described below.

Platform Class Definitions

This is the key entry for creating new asset classes (a.k.a. platforms types). This is the interface for defining platform type characteristics, including signatures, performance characteristics, and nominal loadouts and significant subsystems. This interface provides the user with two platform selection options; Display All Platforms - to select the platform from a list of all platforms and Platforms By Category - to select the platform from a list of platforms listed by platform type. An option is also available to create a new platform type by clicking on the Create New Platform bar of either options and typing the name and selecting the category on the Creating Platform form that appears. The option to delete a platform type is provided in the platform-specific edit from, described in the next paragraph.

Note - This interface does not currently support definition of the icon file to be used with a new platform type. Instead, this should be defined in the Icon Editor . Until this mapping is made any defined platforms of this type will not be displayed.

Once a platform is selected the Editing Platform Form appears. The top top level characteristics are highlighted in yellow along the top of the interface. These include:

If these are not accurate, it's usually easiest to delete the platform class and redefine it as a new platform, but for those who are more adventurous the data can also be edited in the "typechar" scenario database table. There are a lot of caveats to editing the data directly in the database, so use this only at extreme need. Describing how to modify the data directly in the database is outside the scope of this document ( that's why we created the GUI).

Generic characteristics are addressed in the top half of the interface. These characteristics are divided into sections. By clicking the tabs with the section name (e.g. Physical) attributes particular to that class of attribute is displayed for editing. For example, in this diagram the user clicked on the "Planning" tab, instead of the "Physical" tab originally selected for this platform type. It probably sounds confusing to describe this interface in this manner, but the attribute types listed in this interface and the specific parameters that the user can edit depend upon the type of platform being edited. The platform provided in the example was selected because all attribute classes are represented. The comprehensive list of attribute classes and typical parameters for each are as follows:

Physical - These attributes are related to the physical characteristics of the platform (e.g. size and weight). Typical parameters include:

Survivability - These attributes are related to an asset's ability to withstand damage. The two standard inputs are overpressure hardness, measured in pounds per square inch equivalent, and armor rating.

Timing - These are timing parameters related both to movement and shutdown. They also include reliability values (this is because the reliability values originally snuck in as time-until-available estimates). Typical values include:

Planning - These are simple planning estimates including typical and maximum sustainable movement (flight) conditions, and fuel information. Information in these blocks is used both by the automated mission generator and by the threat evaluation module. That is, the information is used by both the friendly and threat sides. Note: Swim speed is also definable for mobile ground vehicles, and is used for amphibious vehicles only. Naval vessels use the cruise and max speeds instead.

Other - the catch-all. Often the only information here is fuel load (in pounds). But for ground vehicles there's also an input for cluster size. This is a shorthand way to create a group of x vehicles in one location that will fight (and lose members ) as though there are x of them instead of 1. The vehicles will all be treated as one for movement and sensor detection calculations, thus potentially saving a lot of processing time. The scenario aggregation option also provides a similar means to "roll-up" assets from individual entities to aggregate clusters, but this method results in faster initialization. But it can lead to confusion (e.g. If you want 300 tanks and this value is set to 10 you should deploy 30 assets, not 300), so care must be used if this option is employed.

The "Show Text of Data Source" button allows the user to specify the source from which the data was taken on a space that appears when the button is selected. This example shows the type of data that can be maintained to describe platform definitions. There's lots of room - this interface can maintain pages of references at need. It is highly recommended that data be put in this table when possible. Even when the reality is that the platform definition was a guesstimate, future users often need to know this instead of wondering about the validity of the data. Also be aware that many of the subsystem definitions incorporate similar datasource references that can be maintained separately from the platform.

Note that the sample is a typical form. Data required on this form changes according to the requirements of the category of platform being defined. Thus the format will differ between an aircraft definition and a non-mobile sensor site.

On the lower portion there are two major sections of the form:

Subsystems Onboard for Configuration:

In the white section you will see displayed the name of the current loadout option. When you select the current loadout option a list of all current defined loadout options will be presented as well as an option to create a new subsystem loadout configuration for this platform class. If a current loadout is selected, the subsystem list will change as defined by this loadout. This section lists the subsystems by type and name on the platform (e.g. Armament and 120mm Mortar ) and the Quantity of each. The quantity number may be changed by clicking on the subsystem name- at which time the Edit Quantity Form appears and a revised number is typed in the form. Be aware that in the case of some subsystems (e.g. sensors) you can also specify the orientation of the subsystem with respect to the platform. In this case an orientation of 0 implies the subsystem is oriented along the centerline of the platform, looking forward. An orientation of 90 degrees implies the subsystem is oriented looking out the right side of the platform. The subsystem's actual orientation during a scenario execution will change in accordance with the asset's maneuvers.

The Add Another Subsystem bar causes the Adding SubSystem Form to appear where the Type,Name, and Quantity are entered.

To add a subsystem type that is not currently defined in the database first define it in the subsystem definition portion of database prototyping.

Pointers to Performance Tables

This section lists the performance tables used for the platform. Examples:

Fuel Utilization
Infrared Signature
Performance Envelope
Radar Cross Sections

Each of the tables is listed by:

Table Type (e.g. Fuel Utilization ) and
Subtable ID (e.g. m48a5 )

Clicking on a performance table causes a drop-down window form to appear with choices of the types of performance tables. On the form the user may select one of the subtables listed, edit (Edit/Review Table) and/or create a new subtable (New Table ).

Subsystems Definitions
Currently lists the following subsystem categories:


Armament subsystems include any engagement subsystems that are modeled as direct-attack weapons against a specific asset. This means that these can kill only other assets (not strategic targets) and kill on a 1-versus-1 case (collateral damage is not modeled). Selecting this category brings up the armament Form which lists all Armament by Name and Type. Clicking on one type of armament brings up the Editing Armament Form .

The Name and Type of armament selected appears at the top of the form. Engagement Medium offers the following options:

In general the armament can only be used against assets in the specified medium. When an armament is to be used against multiple mediums (e.g. A SAM like the Patriot good against both air and space threats) the armament must be defined twice - once for each medium. And both versions of the armament must be loaded on any platform that is to user it.

The user specifies the following attributes:

On the armament Form the Create New Armament Type bar allows the user to type in the Name and select the Type from an expanded list of types (SAM, AAM, etc) on the small Creating Armament form.


This class of subsystems represents the on-board avionics suites used by warfighters. In general, the detections from these suites will not be displayed at operator screen, nor go directly into the C4ISR database, but is used to conduct engagements. Selecting this category brings up the Select Avionics Subsystem to Edit and a list of all Avionics by Name (APG-63). Clicking on one type of armament brings up the Editing Avionics Subsystem Form with the Name and other attributes listed:

On the Select Avionics Subsystem to Edit Form the Create New Avionics Type bar brings up the Creating Avionics Subsystem Form which allows the user to type in the Name of the new avionics subsystem.


This class of subsystems represents the booster that actually makes a missile fly. It is required to define one of these subsystems on any ballistic missile because the flyout data (the downrange distance versus flighttime, the altitude versus flighttime, and so forth) are defined as part of this subsystem. It is also required on any hypersonic glide vehicle; again the data in the subsystem table is required to define the vehicle flight. It is not required to put a subsystem of this type on a cruise missile or an armament (e.g. a sparrow missile). The flyout characteristics of these non-ballistic missiles are handled differently.

Selecting this category brings up the boost Form with Select Booster to Edit and a list of all Boosters by Name and the type (Ballistic missile or Hypersonic Glide Vehicle).

Clicking on one type of booster brings up the Rocket Booster Subsystem Characteristics Form with the Name (e.g. Taepo Dong 2) and other attributes listed. The attributes listed depend upon the type of missile. For ballistic missiles the attributes are:

Note: Take care to verify the contents of these tables. The original ballistic missile module was removed from the JFORCES baseline long ago in preference to using these tables (which at that time were data-coupled to a creditable model). Since that time some scenario errors have been traced to bad data in these tables. For example, if the altitude table says the missile hits the ground before the flyout table says the missile has flown far enough to hit the target, the missile will be unable to hit the target.

If a hypersonic Glide Vehicle missile type is selected, the listed attributes are:

Note: In general, if you know that you need need a booster and aren't sure which type to define, use the ballistic missile if you're intending to kill things either on the ground (e.g. surface-to-surface or sub-to-surface missiles) or in space (ASATs). The current JFORCES Hypersonic Glide Vehicle (or HGV) representation is limited to a long-distance air intercept concept (i.e. long range SAM).

Comm Jammer

Selecting this category brings up the jam Form with Select Jammer Subsystem to Edit and a list of all the jammer subsystems by name. The user may edit any one of the subsystems by clinking on it (e.g. Tactical Jammer). This causes the Editing Jammer Subsystem Form to appear with the Name and a list of all the characteristics of that jammer subsystem. This information includes:

Create New Jammer Type brings up the Creating Jammer Subsystem Form that allows the user to type in the Name of the new guidance.

IMPORTANT: This information is only used when either the Stratcom or GNET communications modules are used and the manuals for those models should be referenced for more information. The "Perfect Comm" communications model normally used for non-comm related studies doesn't use these models and communications can only be degraded on a scenario and location specific basis in the Mission Planner.

Comm Suite

Selecting this category brings up the csuite Form with Select Comm Suite to Edit and a list of all the comm suites by name. The user may edit any one of the subsystems by clicking on it (e.g. 20 foot UHF). This causes the Editing Comm Suite Form to appear with the Name and a list of the three categories of characteristics of that specific comm suite.

First off, this is based upon the requirements for the embedded Stratcom communications model and all field definitions can be found in that model's documentation. When using the "Perfect Communications" model (which seems to be the most popular for non-comm studies) the only entries you need are:

  1. A Name
  2. Comm Suite Type (RF, laser or telephone), and
  3. Operating frequencies (not used for telephone)

The perfect comm model just verifies both the transmitter and receiver have comm suites of the same type and overlapping frequencies. It also verifies that line of sight exists unless the communication are by telephone or some RF frequencies (e.g. HF).

Everything else here is applicable to Stratcom or GNET communications modules use only and the manuals for those applications should be referenced for information. The characteristics definable for these more detailed modules include:

As always, Create New Comm Suite brings up the Creating Comm Suite Form that allows the user to type in the name of a new comm suite.

Fire Control

This is the fire control system used for air engagements. This system is not identical to the avionics, and generally both an avionics and a fire control subsystem need to be added to a platform to make it engage air targets successfully. Think of the avionics as an acquisition system and the Fire Control as the Tracking system. The engagement module uses data from the Fire Control suite for engagement. The one exception to this is if the Armament subsystem does not require any signature to engage. In this case the avionics data is used if available, if no on-board avionics data is available then general surveillance data is used (this data need not be on-board).

Selecting this category brings up a form with Select Fire Control Radar to Edit and a list of all the Fire Control Radars by name. The user may edit any one of the subsystems by clicking on it (e.g. APG-65). This causes the Editing Fire Control Radar Definition Form to appear with the Name and a list of categories of characteristics of that specific fire control radar subsystem.

Selecting the Show ECM Susceptibility List highlighted bar presents the list of Jammers and their PD. The New ECM Suscep. button brings up the Creating ECM Form that allows the user to create a new Jammer and PD .

Data Source - allow identification of the source of the documentation.


The generic use of the guidance subsystem is very simplistic; the detailed guidance model was not released for general distribution. Therefore the only actual use of the guidance subsystem is a binary flag in the conventional warhead detonation effects model that reduced the CEP if the carrier has a guidance subsystem onboard. More detailed models can be reinserted as required for specific studies.

Selecting this category brings up the guidance Form with Select Guidance Definition to Edit and a list of all guidances by Name (e.g. FLIR). Clicking on one type of guidance brings up the Editing Guidance Definition Form with the Name(e.g. FLIR) listed.
EMP Hardiness is typed-in. This is used to determine the subsystem's susceptibility to electromagnetic events (e.g. after nuclear bursts).
Data Source section for text.

Create New Guidance Def. brings up the Creating Guidance Definition Form that allows the user to type in the Name of the new guidance.


Selection of this subsystem brings up the Select IFFN to Edit Form with a list of names. Clicking on a name causes the Editing IFFN Form to appear. The Create New IFFN bar presents the Creating IFFN form where the new name is typed.

If detailed models are not available, the IFFN (Identification Friend/Foe/Neutral) can be modeled by a Monte Carlo draw based on the "Probability ID Table" for the IFFN subsystem onboard. The effect of IFFN is that aircraft and SAMs can fire at airborne threats identified by IFFN - increasing weapons release range when forces are allowed only to fire on confirmed hostiles. This weapons mode is determined by the Rules of engagement specified when a track is assigned to an interceptor or SAM site.


In JFORCES sensors are surveillance sensors that provide data to the C4ISR system (unlike avionics suites, which are modeled as only providing information to the asset they're associated with). Selecting this category brings up the Select Sensor Form with Select Sensor to Edit lists of sensors by name and type of each. The user may edit any one of the sensors by clicking on it (e.g. 3-D Radar ). This causes a larger form, the Editing Sensor Form , to appear which lists all characteristics of that specific sensor. The form is labeled by Name (e.g. 3-D Radar) and Type (e.g. LOS Radar). This table is broken into two parts. The top part includes information applicable to all sensors. The bottom part (starting with the white line labeled "Line of Sight Radar Characteristics in this example) allows the user to input data specific to the sensor class. The general FORCES distribution currently supports 17 different sensor phenomenon, more have been developed for specific study needs.

The general attributes of the sensor are divided into the following categories:
Scan - scan rate and limitations
Accuracy - Resolution, discrimination and NIIRs data
Reporting - message types, reporting delays
ECM - Tables for smart jamming success
Survivability - EMP susceptibility
Other - The catch-all and overrides for specific cases. E.G. catching transient sounds at cruise missile launches.
Source - The source references for later review and to establish a sensor's credentials.

Below this area for generic sensor attributes is an area for defining attributes specific to the sensor type. Click here to jump directly to the the class-specific attribute documentation.

While the generic attributes for each of these vary a bit for sensor type, here's a typical list:

Scan attributes

Accuracy Attributes

Reporting Attributes

Reporting Delays - This consists of two delays, one for reporting to the C4ISR (or MMI) module, the second for cross-cuing sensors. Both are mean values and the actual value will be drawn from distribution using this mean (so there is variability). The second delay is used only when the JFORCES cross-sensor-cuing option is selected, as defined by data being populated in this scenario in the sensor_cuing database table.

ECM Attributes

This list is a simple probability reduction on sensor success for smart jamming. Note that this table should not include any noise jammers or chaff; the effect of these jammers is modeled directly in the radar equations. Likewise, there's no need to populate these tables if the actual tracking algorithm is employed with realistic alterations to the raw detections. But typically this is not the case, do a this interface provides a simple table look-up for the effect of a jammer versus a sensor. A drop-down menu with a choice of types of sensor jammers with similar or same ECM susceptibility. The inputs to this are addressed in the the ecm_sus Form and have the following two elements for each jammer type that affects this sensor: 1) the Jammer Name can be selected from a drop-down list of currently defined sensor jammers, and 2) a Modifier to PD (sensor's core probability of detection) factor can be specified via a slider bar (0.00-1.0)

Survivability Attributes

Currently, the only survivability attribute is EMP hardness, which is used to determine whether the sensor is "burned out" by an electromagnetic pulse (EMP as a result of a nuclear explosion.

Other Attributes

This is the catch-all for top-level attributes not found elsewhere. Currently there are only two types of attributes on this form.


This window maintains user input information on the sensor source and anything else deemed interesting. Again, very useful for tracking the source and quality of data in a study.

Sensor-Type Specific Attributes
The lower part of the screen provides an interface for attributed specific to a sensor type. For example, if a Line of Sight radar using the standard radar range equation is edited (as in this example ) the Line of Sight Radar Characteristics section lists the following characteristics particular for that sensor type. The currently defined sensor types are:

  1. LOS Radar - Standard radar representation where adequate data is available
  2. OTH Radar - Over-the Horizon Backscatter Radar
  3. Passive Sonar - Passive sonar sensor
  4. SB Radar - space-based radar
  5. Generic Radar - Standard radar representation when the available data is inadequate for the LOS radar representation.
  6. Bistatic Radar - Bi-static radar (transmitter and receiver not collocate)
  7. ASW Localize - ASW Localization gear (e.g. sonobouys)
  8. ESM Gear - Electronic Surveillance Measures sensor (radio receiver with SIGINT capabilities)
  9. IR Sensor - InfraRed sensor
  10. Optical - Optical sensor, ranging from satellites with EO capabilities to human eyeballs
  11. E-3 Radar - special interface for a ESC-provided AWACS model
  12. Active Sonar - Active sonar systems for naval vessels (surface and submarine)
  13. Mobile Passive - mobile passive sonar systems for naval vessels (surface and submarine)
  14. Passive ASW - Other passive Anti-Submarine warfare models (e.g. SOSUS)
  15. Gen. grnd de - generic ground surveillance sensor
  16. Fire Finder - Artillery fire finding radar
  17. SB IR - Specialized detailed space-based infrared sensor capable of emulating on-board focal plane
  18. RHAWS - Radar homing and warning system. Also used for tactical ESM Infrarometer.

Note that the descriptions provided below are not intended to be exhaustive, just informative overviews. More detailed descriptions are provided in the ADISC2 Programmers Manual, parts of which are available elsewhere on this website.

LOS Radar Representation Attributes
This is the standard radar representation for air-defense type of radars (and similar radars). It is based on the radar range equation.The algorithm uses the generic attributes of the scan (range, azimuthal and elevation limits) to define the radar search volume. The presented target signature (based on the targets RCS table, search frequency, and geometry) is then factored in. The background RF noise level is determined and then adjusted for any jamming (both by the target and by other sources, both on-and off- main lobe) and any nuclear events. A LOS calculation employing DTED data is then used to prevent obscured detections (assuming the DTED data is selected in the run configuration, otherwise only an Earth-limb limitation is used). As such it does a creditable job of representing noise jammers, presented RCS, weather ducting, and so forth. Generally this would be the recommended model for these types of radars, but if you find you don't have adequate data to support this model go to the "Generic Radar" model instead. Attributes include:

OTH (Over-the-Horizon Backscatter) Radar Representation Attributes

This model is Bill Fischer's model from NORAD (as it existed in 1989). This algorithm divides up the fan into 7.5 degree segments 100 NM wide and determines the maximum usable frequency (MUF) for each segment to determine whether the sensor can operate in this segment currently. This MUF calculation incorporates the 11 year sunspot cycle, time of day and some minor factors. It also determines whether the segment is blocked by the auroral cap. Given the sensor can operate in the band the threat is in it performs a signal to noise calculation specific to this sensor. If this result is in excess of the threshold signal-to-noise input by the user the system determines a probability of detection (hardcoded into the original model) and Monte Carlos against this computed PD. If all of this passes the system declares a hit and starts tracking the threat. Parameters are:

Passive Sonar Representation Attributes

The only required attributes for this model are Excess Signal required (in DB) and antenna gain (DB).

Space Based Radar Representation Attributes

This is a very simple algorithm that basically treats the space based radar as a 4th root scaling radar algorithm with detection limitations (Earth limb and nadir representation) as defined by the generic sensor attributes. As such. the only sensor-class specific attribute required are:

Generic Radar Representation Attributes
This is a simple 4th-root scaling algorithm for radar detections that has proven useful for describing many radar systems when the additional data required to support the LOS radar algorithm was unavailable. The algorithm uses the generic attributes of the scan (range, azimuthal and elevation limits) to define the radar search volume. The presented target signature (based on the targets RCS table, search frequency, and geometry) is then factored in versus the user-provided characteristic detection range. The LOS calculation employing DTED data is then used to prevent obscured detections (assuming the DTED data is selected in the run configuration, otherwise only an Earth-limb limitation is used). Some adjustments are made to the detection range based on threat jamming and the environment, and then detection success is Monte-Carloed versus the computed PD. Required attributes are:

Bistatic Radar Representation Attributes

To make this description short, the fact is that this representation is based on an adjusted standard radar range equation as described in the LOS radar section. The same attributes apply (naturally the transmitter and receiver representations are maintained separately in this algorithm, but that's invisible to the user). The following adjustments are made to the basic radar range equation:

      1. Separate line of sight calculations are made for the transmitter and receiver
      2. The attenuation due to range is computed separately for he transmission range versus the return range
      3. The target's presented RCS is based on the mean angle of incidence
      4. There are additional attributes defining the grazing angle limitations for the transmitter and receiver
      5. There are limits on the allowable minimum and maximum separation angles between the transmitter and receiver.

ASW (AntiSubmarine Warfare) Localization Representation Attributes

This is a simple representation of an ASW system employing a table look-up of detection probability versus target range, signature (which is based on type and speed) and target depth. The source for this model is the NOSC Regional ASW Model for ADISC2, Published under contract # N66001-89-D-0004-014.

ESM (Electronic Surveillance Media) Gear Representation Attributes

To make this description short, the fact is that this representation is based on an adjusted standard radar range equation as described in the LOS radar section. The same reception attributes apply, the transmission power depends upon the target's emissions in the search frequencies. The signal attenuation is 1/2 the standard radar model (nominally this means that this equation uses square-root scaling instead of 4th root scaling, but the actual scaling is adjusted for atmospheric conditions).

IR (InfraRed) Sensor Representation Attributes

This is a simple square-root scaling of the presented target signature (in watts/steradian) versus the characteristic sensor case. This calculation is done after the target is determined to be within the search volume defined by the generic attributes and within line-of-sight. Specific attributes are:

Optical Sensor Representation Attributes

This representation determines whether a target is seen based upon it's clear-state detection and identification ranges (defined by for the target platform) and as adjusted by any applicable smoke, night, weather, terrain clutter and optical power adjustments. The smoke, night and power values are sensor attributes. The terrain and weather effects on visibility are defined in the Mission Planner and the DataBase Prototyping for environmental elements, described below.

E-3 Radar Representation Attributes
This representation of the E3 radar comes from ESC. I'm not sure the representation is great, this just started as a result of a statement that we made that we could incorporate an entirely new sensor representation into JFORCES in a day. We were asked to put up or shut up. We succeeded (with time to spare). This model is still kept, but seldom used.

Active ASW Sonar Representation Attributes
The source for this model is the NOSC Regional ASW Model for ADISC2, Published under contract # N66001-89-D-0004-014. The inputs are:

Mobile Passive ASW Sensor Representation Attributes

The source for this model is the NOSC Regional ASW Model for ADISC2, Published under contract # N66001-89-D-0004-014. The inputs are:
Passive ASW Sensor Representation Attributes
The source for this model is the NOSC Regional ASW Model for ADISC2, Published under contract # N66001-89-D-0004-014. The class-specific attributes for this sensor type is a list of detection frequencies with associated elliptic detection data.

Generic Ground Detection Sensor Representation Attributes
This is a VERY simple generic detection model for detecting ground elements. Like the majority of other sensors, it uses the generic attributes to determine whether a target is within the search volume. It also determines whether the line-of-sight exists using DTED data (when DTED is specified in the run configuration). Beyond this the system only checks whether the target is moving enough to have an adequate closing (or separating) velocity to be detectable and whether the system reliability is satisfied (this is a Monte-Carlo draw). Beyond this the system can confuse two targets if they are both within the discrimination criteria for the sensor. It also can attempt to identify the target through a Monte-Carlo draw.

Artillery Fire Finder Radar Representation Attributes
This is a 4th-root scaling radar algorithm called whenever enemy artillery is fired. Note that this is the one case of a sensor that will not periodically report. The algorithm is only called in the case of enemy fire. The attributes that need to be defined are:
Space Based Infrared Sensor Representation Attributes
This InfraRed model differs from the earlier IR model by maintaining adequate detail to support a focal-plane emulation of detections. Attributes include:

RHAWS (Radar Homing and Warning System) Representation Attributes

This model differs from the ESM model because 1) it models system errors more specifically, and 2) it does not attempt to identify the source internally (we have an ancillary analysis package to do that). The reason this sensor has these characteristics is we used the results from this system to test the HFI RHAW threat geolocator before the empirical data from the Hornet and Longbow flights was received. Required attributes include:
Sensor Jammers
This is a list of jammers that can affect different types of sensors. The basic jammer types are 1) Noise, 2) Smart, and 3) Smart. These are defined separately and each has it's own uses and attributes.

Selecting this category brings up the sensor jammer Form with Select Sensor Jammer to Edit lists of sensor jammers by name and type of each. The user may edit any one of the sensor jammers by clicking on it (e.g. chaff ). This causes a larger form, the Editing Sensor Jammer Form , to appear which lists characteristics of that specific sensor jammer. In this case the jammer is a chaff dispenser, so the associated attributes are:
A chaff dispenser is only effective against radars reporting raw data (i.e. reporting JSS search data) and the trackers using this data. Click here to see an example of the operator perception in an area with a chaff-dispensing threat. The red cells are areas in which the tracker is reporting overload.

The attributes for a Noise jammer are:
The frequency list is used to differentiate between narrow and broad band jammers. This type of jamming is effective against most of the radar models, but is most accurately depicted in the LOS radar model. In this case main, side and backlobe jamming are all evaluated. In simpler radar models (e.g. the 4th root scaling radar models) only mainlobe jamming is considered. This is because the simpler radar models do not incorporate enough antenna information to determine where the other lobes would be.

The last type of jammer is a catch-all category called "smart". In the baseline the only data required for these jammers is the EMP susceptibility. The jammer's effect on sensors is determined by the probability of detection reduction tables associated with the sensor.
The Create New Sensor Jammer bar brings up the Creating Sensor Jammer Form where the Name is typed and JammerType is chosen from three options: Cont. Wave, Spoofer/Other and Chaff Dispenser.


These are the tanking bladders used in air refueling and defines fuel capacity and speed of the tanker (e.g. A KC 135). Selecting this category brings up a tank Form which lists all tankers by name. A tanker can be edited by clicking on the name. This causes the Editing Tanker Form to appear with the Name of tanker and two fuel related entries:

The Create New Tanker Type bar brings up the Creating Tanker Form where the name of the new tanker can be typed.


Trackers are used for following persistent, moving detections over time. To that extent the JFORCES baseline includes a GUI and automated incorporation on two types of trackers: 1) angle-only trackers and 2) position trackers. Angle-only trackers are used for maintaining a track from a position where distance is unknown, e.g a space-based infrared sensor. In this case the tracks are reported as azimuth and elevation angles and movement rates from the the sensor and luminescence. The position tracker fuses these sensor-centric angular tracks into 3D position estimates and tracks the resultant estimates. It should be mentioned that there are several other tracker options available in JFORCES but not addressed in this GUI. For more information on the other tracker options in JFORCES click here. The most robust tracker incorporated into JFORCES is the one employed in RAP. The inputs for this tracker have not been built into a GUI but the system can still be used. Click here for more information on that tracker and on alpha-beta trackers in general.

The rest of this description will be limited to the two types of trackers definable through the GUI. The inputs for these two types of trackers differs. Reviewing the tracker subsystems brings up the Tracker Form and Select Tracker to Edit which lists all the trackers by name. A tracker can be edited by clicking on the name. Data for the angle-only tracker includes the following attributes:
Position trackers have different set of attributes, as indicated by this Editing Tracker Form. Attributes include:

The Create New Tracker Type bar brings up the Creating Tracker Form where the name of the new tracker can be typed.
Again, remember that there are other trackers in JFORCES, the data just is not maintained via this GUI. Go here and here for more information.


Having one of these on an aircraft make it more likely friendlies will be correctly identified and make fratricide less likely. Selecting this category brings up a transponder Form with the Select Transponder to Edit which lists all the transponders by Name and EMP_Hard . A transponder can be edited by clicking on the name. This causes the Editing Transponder Form to appear with the Name of tanker and the EMP Hardness .

The Data Source section shows the source of the data entered.

The Create New Transponder bar brings up the Creating Transponder Form where the name of the new transponder can be typed.


Basically, these are things that blow up. They differ from armament in having area effects (they can kill multiple things) and the possible destruction of targets as well as simulation assets is considered. Also, sometimes the armament and warhead subsystems are mixed. For example, to work properly an artillery piece requires both armament and warheads. The armament reflects the tube itself, and key information (like the max range) is derived from this subsystem. But the artillery piece also requires warheads to shoot - the warheads are what is actually shot and damage calculations are based on the warhead characteristics. Note that ballistic and cruise missiles require one (or more) warheads to be loaded in order to be effective, again the damage calculations when these missile impact is based on the warhead characteristics. Bombs, including air dropped and hand-carried, are also warhead subsystems.

There are three types of warhead:

Each with it's own attributes. Attributes common to all warheads are:

Additional attributes for nuclear bombs are:
The nuclear bomb algorithm incorporated into JFORCES is based on a Government Printing Office document entitled "The Effects of Nuclear Weapons". Please refer to this document for how this information is used.

Additional attributes for chemical munitions are:
Additional attributes for conventional munitions are: Guidance Options - This is the warhead's terminal guidance options. There are five options:

World Wide Terrain Definitions
Oddly, a variety world-wide definition data has passed into and then out of this GUI over the years. For the most part the data has been pulled out because it was found more efficient to employ public databases (e.g. the NIMA VMAP data and the US Dept of Commerce's TIGER database). The result is that only river definitions are still in the GUI. Picking the "River" option brings up a River Terrain Form where each type of river is listed and may be edited. Clicking on any type causes the Editing River Points Form with the Name and Lat/Long of the river to appear. This form lists the specific location of that specific river.

The user may also choose to Create River Record and a small Creating River form appears where the name of the new river may be entered.

Edit Target Classes

This list is the list of strategic target types that can be created within the Mission Planner. Selection produces the Target Types menu with the currently defined types of targets listed. The description of each type target may be edited by clicking on its name, No attributes are specified here; all target attributes are defined for each target.By choosing the icon the Icon Editor form appears with a list of all icons. Clicking on an icon causes the Icon Viewer section of the form to reflect its Class Name, Type, and Icon file name. The Change Icon File button opens a form with Directory can be chosen and File name typed in. Icon scale may also be modified with a sliding scale bar under Set Scale. An Off/On button is available to activate the Rotate and Range/Bearing of the icon. Each icon may be edited (Edit Icon Bitmap ) that brings up two windows with the tools to edit or modify the icon. A new icon may be created by selecting the Create New Bitmap bar.

Clutter Type Definitions

The purpose to this interface is to specify the class characteristics of various clutter types. Clutter is defined in terms of Defensive Value, effect on the maximum and typical ground speeds, and limitations on visibility against ground targets. Selection causes the Clutter Type Descriptions Form to appear with the Select Description to Edit. The Description, Code, Def. VAl., and Obscure (PD/NM) of each clutter type is listed. On the form is a list of the types of clutter (e.g. Rolling Hills ).

When one type is selected an Editing Clutter Description Form appears with the title of the type (e.g. Clutter Description: Rolling Hills Clutter Code: 3 ) and the following data and options:

The Create Description Record bar causes the Creating Clutter Type Form to appear where a Description and Type is typed.

Group Class Definitions

This is where you define the groups that can be deployed in scenarios through the Mission Planner. As such this is critical to generating scenarios, but somehow this gets a lot less attention than the platform definition interface. Selection causes the Group-Class Form to appear with the Select Group-Class. On the form is a list of the Group-Classes with the Group class name(e.g. AAA Bde), organizational Level (e.g. Regiment), group Type (e.g. Air Defense) and the force Side (e.g. Force B)listed for each. When one is selected an Editing Group Class Form appears with the following data specifying the prototype TO&E along with the following options:

The selected Group Class Name, Organizational Level, Side and Group Type on the top of the form.
A list of the members of this group (both assets directly assigned to the group and subgroups). This list includes:

It's important to note that this list specifies the initial conditions for new groups created of this type. Modifying any of the member fields (e.g. changing the quantity from "1" to "2" in the sample form) will not change the member lists of any currently defined groups of this type. This is because the user can tailor the group members in the Mission Planner and there's no way for the system to know whether the change in group prototype was intended to reflect specific tailored groups or not. So if the number of members is wrong its the user's responsibility to either create the new subgroups and assign them in the "Mission Planner" specific groups interface or delete the old groups and recreate them with new specifications.

The Add New Member bar causes the Adding New Member Form to appear. It allows the user to add groups or assets to the current group. Specific inputs are:

Back on theGroup Class Form , the Create New Group-Class Type bar causes the Creating Group-Class Form to appear where:

Originally the group is created empty. Edit it by picking on it through the Group Class Definition interface and add members though the above described "Add Members" button.

Operational Readiness

This interface allows users to define the target readiness of airbases at different alert levels. That is the intended numbers of aircraft at various types to be held at various readiness levels. This is under reconstruction, in the meantime users need to load the appropriate database tables manually if they wish to model realistic airbase operations. The good news is that few users have expressed a desire to descend to this detailed readiness level and if this data isn't filled in aircraft availability is limited to aircraft at the bases and restricted according to the aircraft type turn around defined in its platform definition. For those who want to use the detailed model, please call the JFORCES team for information on loading the appropriate database tables until the GUI is resurrected.

Plan Air Package

This interface permits the user to define packages to perform an integrated air mission. This interface permits air packages to be deployed as groups of aircraft. The actual invocation of these packages is done either through Mission Planner specifications or the interpretation of an ATO read in USMTF format. The packages are defined as groups of different types of aircraft. Each type of aircraft has tailorable specifications including:

Selection brings up the Air Packages Form with the Currently Defined Packages that lists the names of the current assigned packages. Each may be edited with mouse action which brings up the Package Elements Form with a listing of the air elements by name along with the attributes of each. The elements are: #, Name, Essential, Mission, Role, Duration at Site (Hr) and Param 1). Each element may be edited or deleted via the Edit/Delete? buttons. A new element may be added by selecting the Add bar that causes the EDIT Form to appear. This form lists the Package Name and allows the user to choose the AC (Aircraft)Type from a drop down menu; the Number (of aircraft); the degree of Essentiallity (Yes/No); the type of Mission (e. g. Strike); the Role (Primary or Support); and Duration at site (Hr). A completely new package may be defined by selecting the Define New Package bar on the AIR PACKAGES Form causing the AIR PACKAGES where the name of the new package is typed.

Copy Between DB

This option is important for two key reasons:

Selection brings up two option bars: Platform Types and Subsystem Types. Selection of the first produces the PLATFORM COPY SPECS Form with: Source DB; Destination DB; and Platform bars. Selection of theSubsystem Types bar brings up the SUBSYSTEMS COPY SPECS Form with : Source DB; Destination DB; Subsystem Type; and Subsystem Name bars. Once the databases are selected and the types/names are designated the data is copied into the destination DB.