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:
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.
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.
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.
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.
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.
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.
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.
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.
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:
The replay option is being changed and this method of replay is depreciated. Instead, use the "Replay" option described under the System Controls.
As described in the System Controls documentation, checkpointing is system-dependent. Verify that checkpointing has been installed on your computer.
For the above reasons, the readdb option (telling the system to just read the scenario database from the database and run it) is the most common choice.
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:
- The receiver and transmitter must have compatible communications suites
- Communications throughput limitations are observed.
- There must be line-of-sight were required (most RF links)
- While communications jamming is not explicitly modeled (used either GNET or STRATCOM for this) the umpire can command link restriction for specified times either as part of scenario definition or during the run to model communications jamming or environmental perturbations. These restrictions will limit reports available to forces players (limiting their perception) and will alter the communications received by modeled air engagement assets (e.g. They might not get vectoring instructions.
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.
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.
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.
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.
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.
The icon/entity map must be made for EACH scenario database you're using
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.
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.
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.
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
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 ImportFORCES 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 PrototypingThis is a key element of data population. Selection brings up a form with the user definable attributes of nine categories:
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:
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.
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:
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
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 .
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).
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.
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:
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.
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.
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:
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.
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)
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.
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.
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:
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.
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:
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:
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
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.
Passive ASW Sensor Representation Attributes
Homing and Warning System) Representation Attributes
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 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.
World Wide Terrain
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:
Defensive Value This is a multiplicative factor used in direct-combat ground engagement. "1" would indicate this terrain confers no defensive benefit; .5 would indicate that the defender would sustain only ½ the normal losses when in this terrain.
Maximum Speed (kts) Max speed for any ground asset in this terrain
Speed Reduction Indicates % reduction for movement from any asset's nominal max speed (defined in platform characteristics)
Prob. of Detection % reduction in probability of optical detection for ground and near-earth assets per nautical mile of foliage you are viewing the target through.
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:
The Member Flag . This is either Object or Group. If "Object" then the class entry references a platform definition. If "Group" then the class entry references a group that is assigned to this group (e.g. one or more platoons or a specific type assigned to a company). As can be seen from this, entire hierarchies of groups reporting to groups can be created through this interface. From the standpoint of runtime clarity it's recommended that you always have at least one object in every group. This is because during runtime the group icons are located where an object associated with that group is located. If there are no objects directly within that group the display algorithm will descend to the subgroups to find an asset that in some way is assigned to this group. The result is the group icons often don't show up where you expected when you haven't assigned an organic asset to this group. Also, from an operational standpoint, it's probably inappropriate to say there's a group that has no assets in it but has valid subgroups.
The Member Class (e.g. 122mm Gun). This is the name of the platform if the member flag is "Object" or of the subgroup if the member flag is "Group". Naturally, the organization of subgroups can be reviewed through this interface.
Quantity of this type of entity (either asset or group). A "2" in this field would indicate that whenever a new group of this type is created two entities of the member list will automatically also be created and assigned to this list.
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:
The organizational level (e,g, Group ) is listed at the top.
The Member Flag: line allows the user to select either Group or Object.
The Member Class line has a drop-down window with a list of either the Objects or Classes to chose from.
The Quantity: line lists the quantity desired.
Back on theGroup Class Form , the Create New Group-Class Type bar causes the Creating Group-Class Form to appear where:
Group name is typed-in.
Level selected from a drop-down list.
Type selected from an extensive drop-down list.
Side selected (Force A, Force B, or Force C)
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.
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.
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.
This option is important for two key reasons:
It allows the user to copy a version of the a platform or subsystem from one database to another. While this is the obvious employment it's amazing how often you start generating a scenario only to find out the platform you want to use resides in a different database than the one you started creating the scenario in.
The second option is more important for general data configuration and control. In addition to transferring definitions between databases, this interface also permits the user to transfer the definitions to (or from) a file. This clearly allows users in different areas to "sneaker net" definitions between geographically separated computers. But more important for data management, we dump platform definitions that we have found "good" to the $DTA_DIR/db_prototype directory. This directory is maintained under CVS (concurrent versioning system) control, allowing updates by authorized users and archive and backup of critical platforms and subsystems. This forms the basis of a manageable data library. Unfortunately, currently there are few entries in this library and there's no significant user group to evaluate new definitions. But the framework is in place when more contributers and evaluators become available.
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.