JFORCES architecture

JFORCES Architecture

FORCES has the following logical architectural components:

Database (DB)
Simulation (sim)
Human-Machine Interface (HMI)
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.

Presimulation

During presimulation scenarios are defined. This includes:

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.
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.
Defining the employment and deployment of assets and groups in specific scenarios.
Defining environmental characteristics of the scenario
Defining run specifications including length of run, scenario time, and modules to be employed.
Specifying data collection characteristics. This can include the messages to be collected and the assets to collect data on.
Specifying command authority and communications
Populating automated rules.

The following applications can be useful in Presimulation:

Process	Description	How to Invoke from a Command Line	Comments
Mission Planner (MP)	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
Platter (Plat)	Graphical tool for deploying satellites and evaluating their sensor coverage and communications capabilities.	type "start_plat"	Useful only for defining satellites
SQL	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

Task	MP	SG	DP	RC	Plat	SQL
Defining Assets			X			(Backup)
Optionally organizing assets into prototypical organizationa	X		X			(Backup)
Deploying and employing elements	X	X			sats only	(Backup)
Defining Environment		X				(Backup)
Defining run specifications				X		(Backup)
Specifying data collection	X	X				(Backup)
Specifying command authority and communications	X	X				(Backup)
Populating automated rules.	X	X				(Backup)

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

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:

Initialization
Receipt of a registered message
Upon a standard time basis
Upon a checkpoint request
Upon notification that an application of a specified type is checking in from another node.

TBD -

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):

$PCOMM_DIR - for "perfect Communications" code. This code only checks for media matches, frequency overlaps, and where appropriate, line of sight.

$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:

Nuclear, chemical and conventional bursts & aftereffects (note that the actions involved in delivering the munitions are usually incorporated in the JFORCES Threat module)
Weather and weather-front movement
Receipt and distribution of Intel messages from sources external to the elements modeled in the scenario
Terrain effects
Auroral, F-layer stimulation and other atmospheric calculations
Minefield effects (the actions involved in deploying and eliminating minefields are incorporated in the engagement module)
Day/night calculations
Maintenance of dust and smoke data for use in determining detectability

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:

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.
Initial - contains all code for reading data from the database and initializing the simulation runtime environment.
Maintenance - A repository for stand-alone maintenance routines. Currently this module includes routines to:

Extract pseudocode from FORTRAN for documentation support
Prepare sensor scan data for execution (not generally used anymore)
Prepare tables of auroral, line-of-sight and atmospheric data to streamline runtime loads.

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.
Reports - code to support generic data-driven runtime reports. Has not been verified recently and is probably out of date. Not generally used anymore.
Utilities - Repository for stand-alone applications that have proven useful in supporting analysis. Current routines:

Provide coverage reports for data collected from simulation runs (details unknown)
Provide a decimal to degree/minutes/seconds convertor to support scenario generation.

This results in the following simulation directories:

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

Module	Programmer's Manual	Comments
C2	XIV	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.
Comm	XI-1	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).
Engment	X-1	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.
Environ	XII-1	Reasonable description of the Environment module. Certainly better than nothing
Faa	XII-1	There's only a brief mention of the FAA functions in the environment write up. Still, it certainly helps explain what is there.
Initial	VII-1	OK for concept, but particulars of initialization are being changed as code is converted from embedded QUEL to SQL
Maintenance		Undocumented
Objutil	XIII-1	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.
Sensor	IX-1	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
Threat	VIII-1	Good, however the threat module is not very complex so this manual might not be very useful.
Utilities		Undocumented
Zmain	Vols VII-XIV	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.