JFORCES Architecture

FORCES has the following logical architectural components:

  1. Database (DB)

  2. Simulation (sim)

  3. Human-Machine Interface (HMI)

  4. Other Interfaces

These components are tied together in different ways depending upon the JFORCES mode. The three modes of operation are:


While these are logically sequential activities, in practice there's feedback and, especially in the case of the runtime and data analyis, concurrent execution is common.


During presimulation scenarios are defined. This includes:

  1. Defining assets in terms of their physical attributes, performance characteristics, and capabilities. See the Section 4.6.7 of the ADISC2 Programmer's Manual for more details.

  2. Optionally organizing the defined assets into prototypical organizational elements (i.e. building generic TO&Es). This step is useful in reducing the workload of creating new groups in individual scenarios.

  3. Defining the employment and deployment of assets and groups in specific scenarios.

  4. Defining environmental characteristics of the scenario

  5. Defining run specifications including length of run, scenario time, and modules to be employed.

  6. Specifying data collection characteristics. This can include the messages to be collected and the assets to collect data on.

  7. Specifying command authority and communications

  8. Populating automated rules.


The following applications can be useful in Presimulation:



How to Invoke from a Command Line


Mission Planner


Graphical scenario laydown tool

Type 'start' and then enter the Mission Planner mode in under System Controls


Scenario Generator / Database Prototyping (SG & DP)

Forms-based scenario definition interface and asset prototyping tool

Type 'start' -> DBA -> Scenario Maintenance -> Plan Scenario

Most of the scenario generator functions have been subsumed into the Mission Planner

Run Configurator (RC)

Forms-based run configuration tool

Type 'start' -> DBA -> Plan Run




Graphical tool for deploying satellites and evaluating their sensor coverage and communications capabilities.

type "start_plat"

Useful only for defining satellites


The "raw" way to insert, modify and change scenario data.

type sql (vnode)::(database name)

Most primitive method. The intent is to provide enough support the average user will never to do this.


These tools have the following relevance to the Presimulation tasks listed above








Defining Assets







Optionally organizing assets into prototypical organizationa







Deploying and employing elements





sats only


Defining Environment







Defining run specifications







Specifying data collection







Specifying command authority and communications







Populating automated rules.








In all cases (except SQL) the interface between these applications and the database is a very simple interface based upon the database's native API:



Runtime is the only mode in which the JFORCES simulation EXECutive is invoked. It also has the most complex architecture of the three modes.


This diagram is intended to show that the JFORCES Simulation can support multiple HMI interfaces and multiple other interfaces at local and remote sites. This diagram is not intended to indicate that any single box within this architecture is a single process or that any one is limited to a single machine.

The JFORCES system is a dynamic system, meaning that any of the HMI or other interface processes shown in this diagram can be added to an ongoing simulation EXECutive without requiring predefinition. They may also drop off at any time without stopping the simulation. Thus, if communications are lost to one site, the other sites can continue the run (if they wish) and that site can reattach to the run when communications are reestablished. This also reduces and often eliminates the problems of synchronizing with ongoing live exercises and other simulations.

This dynamic environment is supported by the JFORCES Simulation EXECutive. All of the process blocks shown on this diagram are controlled through the EXECutive, which has the ability to reconfigure communications when new processes "check in" with the master process and to reroute application-specific messages, as appropriate.

As already mentioned, the process blocks above are not intended to imply that any item is restricted to a single process or machine. For example, the HMI process block consists of the following subprocesses

 The dotted lines between the executive and the subprocess indicate that the subprocess is linked to the EXECutive. The subprocess provides API for the EXECutive to call upon:

    1. Initialization

    2. Receipt of a registered message

    3. Upon a standard time basis

    4. Upon a checkpoint request

    5. Upon notification that an application of a specified type is checking in from another node.



Description of EXEC communications processes

Interfaces with external processes


Simulation Subprocesses

Like the HMI, the simulation consists of a number of distinct modules, some of which can be run as separate processes on different machines. For contractual reasons, the simulation code is broken into the following functional elements:
1) C2 - all automated command and control code

2) comm - All communications code. Note that the actual progation code at the specific communication link does not reside in this directory but on one of the following directories (dependent upon the communications module selection):

$GNET_DIR - for the GTE GNET communications propagation code.

$STRAT_DIR - For the AFSAA STRACCOM propagation code. Usually regarded as our most detailed, accurate commincations module.

3) engment - All engagement code. This includes air-to-air, SAM, air-ground, artillery and close combat ground fighting

4) environ - All environmental code. This includes natural and human-created events (including those that are outside human control after being instigated). An example of the later noted case are effects of chaff drops. Chaff events are modeled as environmental effects because, after chaff is dropped, the metallic cloud affects both sides symetrically. Specific environmental effects modeled include:

5) FAA - Constructive simulation interfaces to live or historically recorded Civilian air-traffic sensor feeds and controller station displays & controls

6) Sensor - Repository for all sensor code including maintence, detection and tracking code.

7) Threat - repository for threat activies include jamming and bomb delivery. This has a lot of overlap with the engagement module.


In addition to these directed modules, it has proven expeditious to incorporate the following modules into the simulation for code maintenance:

  1. Exec - EXECutive interface functions for the simulation. These routines allow the simulation to perform basic control functions including fast forwarding to designated times and preparing the execution of limited subscenarios of a larger scenario.

  2. Initial - contains all code for reading data from the database and initializing the simulation runtime environment.

  3. Maintenance - A repository for stand-alone maintenance routines. Currently this module includes routines to:

  1. Objutil - repository for all asset maintenance routines. This has turned into the largest module in the simulation. Among other items, this module incorporates the routines that would be considered private to any asset in an object-oriented implementation. This is a a major component of the approach that has allowed JFORCES to implement an object-oriented design in non-object oriented languages.

  2. Reports - code to support generic data-driven runtime reports. Has not been verified recently and is probably out of date. Not generally used anymore.

  3. Utilities - Repository for stand-alone applications that have proven useful in supporting analysis. Current routines:


This results in the following simulation directories:


The following ADISC2 Programmer's Manuals describe the functions of these modules







Good and up to date on the automated air defense. This is a very complex module and I recommend that anybody interested in building automatic AD C2 rules review this document. However, there is no documentation on newly added C2 functions including ATO's, Artillery tasking and dynaminc sensor routes.



Largely a waste of paper. Good only to review the concepts used in communications links and routes. This module does not, and did not intend to, reflect the differences in the three communications modules (perfect comm, GTE Net, and STRACCAM).



Good and accurate documentation of the air-to-air, surface-to-air, and antisubmarine warfare representations. The ground fighting routines were written after this manual was completed, so none of the details are presented here.



Reasonable description of the Environment module. Certainly better than nothing



There's only a brief mention of the FAA functions in the environment write up. Still, it certainly helps explain what is there.



OK for concept, but particulars of initialization are being changed as code is converted from embedded QUEL to SQL






A must read for anybody involved in JFORCES! Covers our object orientation adequately to explain how assets are defined and tasked in the database. There is currently nothing in this documentation to explain clustered assets or higher-level organizations (i.e. TO&Es) outside of squadrons, but still an understanding of what is in this document is very valuable.



Very good, but covers only sensor types used in air defense. However, since the basic processing streams are identical for hew sensor types this is still a good reference. In addition, the detection algorithms are covered in detail in this manual, making it a starting point for the analyst's manual



Good, however the threat module is not very complex so this manual might not be very useful.






This is just the location of the simulation's main program. As such all of the documentation of the simulation applies.


FORCES Modules -

These are the current JFORCES modules

Autogen - This includes applications for automated code-generation of JFORCES C, Fortran, TCL and SQL functions based upon specifications included in the definitional tables, EXCEPT for the data analysis tables, formats and constants. The definitional tables are always stored in the adilib database and are c_for_structs, c_for_declarations, da_table_master, da_table_fields, icd_master. The results produced by these procedure are a series of header files defining constants and structures in each of the target languages.

common - This includes all "common" definitions in the JFORCES system, including both those elements public to all languages and generated by the autogen procedures as well as those specific to one language. Essentially, this is a directory of header files available for inclusion into specific procedures.

cshrc - Includes all system setup files that do not need to be modified for specific installations. Note that items that are modified for each installation are in the the user's home directory in his .cshrc file. The user's .cshrc automatically sources the .cshrc_core file in this directory at log-in and it will source all other required files to create a comprehensive JFORCES environment

dataanal - Contains code for generating the data-analysis incorporated code and SQL scripts for JFORCES Fortran and SQL files based upon specifications in the da_table_master and da_table_fields tables of the adilib database. Note the logical overlap between this directory and the Autogen directory; in the future this module will probably be incorporated under Autogen.

exec - This is the JFORCES simulation EXECutive. This EXECutive provides platform-independent interprocess communications and timeing services. It thereby supports distributed simulations, real-time exercises, and interfaces to live systems.

gnet - The GTE-developed "G-Net" RF communications propagation code.

interfaces - Interfaces to external systems. Specific interfaces are stored under this module as subdirectories. Currently, interfaces include AFATDS, Tomahawk simulator, CCS, GCCS, OTH and PCDS. There is also an entry for an evolving DIS interface.

libraries - Generic utility libraries for functions like: C/Fortran string manipulation, database access, and list maintenance in C.

map_stubs - Graphics stubs for running the HMI on systems not supporting GPHIGS. Used only for debugging and not considered part of the JFORCES core.

menus - Dead code.

mmi_graphics - Contains code for the Map process.

pcomm - Contains "Perfect Communications" comm code. This is a communications simulation that does not computs the probability of correct message reception (PCMR) along specific links but instead just checks routing data, comm gear interoperability, and (where approprriate) Line of sight restrictions. This tends to be the most used of the three current communications simulation options.

platter - The presimulation interface for defining and evaluating satellite constellations.

presim - Contains code to permit the asset and scenario definition through Ingres forms.

rcvr - Contains code for the rcvr process - this being the communications buffer process linking the user-visible menus and maps with the simulation.

scripts - Contains all JFORCES scripts. Click here for details.

sim - The JFORCES simulation code.

stratcam - Contains the AFSAA STRACCAM code for link level propagation of simulated messages.

tcl_stuff - contains TCL code. Most notably contains all TCL menus for the simulation runtime, for the Mission Planner, and for the platter.

tools - Should contain generic JFORCES tools, but currently the only important entry is newmake. The newmake process is used to generate the Makefiles in almost all JFORCES applications based upon the specifications found in the Make.config file in affected directories.

wn - Contains the menus interface support code for the FORCES runtime and Mission Planner.