There are different options under the System Controls tab depending upon the current operational mode. The three core modes are:
Runtime - this is the mode in which the GUI is connected to an ongoing simulation
Mission Planning - this is a dedicated mode in which the GUI is tailored to defining a scenario.
The System Control options available in each of these modes is discussed below
Initial System Controls
When FORCES initially starts the following options are provided under the System Controls ( Click here to review the interface):
Click on any option of interest for more information.
Start HFI Interface
This is a method for changing from a standard JFORCES application to the passive system geolocator developed under the Horizontal Fusion Initiative. This interface reads in data from either an F/A-18 Super Hornet's RHAW or an AH-64D Longbow's Inframeter, filters the data according to platform-specific algorithms, catalogs persistent results, categorizes the information versus a threat library, and (based upon user-approved passive tracks) geolocates threat emitters and turns out XML threat reports compatible with the MARS SIPRNET Intel server. The interfaces requires either recorded or live information from these source. A quick overview of its use is provided here. Please contact the JFORCES team for additional details.
This is the main interface for starting a simulation execution. The execution can be started either in batch mode or in interactive mode. The batch mode runs the simulation in background and does not change the FORCES interface to provide runtime controls. The user can, however, connect to a simulation started this way by later selecting the "Connect" option also shown on this interface. The interactive option start the simulation in the same way but will also reconfigure the FORCES interface to control a simulation execution. Despite the fact that the interface has been changed it will not be permitted to connect to the simulation to monitor or control progress until the simulation has completed initialization. The time required to initialize the simulation can vary from under 30 seconds to much longer (possibly an hour or more in a very taxing environment). This depends on:
Selecting the Start Sim Run Form allows the user to designate a variety of aspects of the simulation that are desired for a particular run. These options include:
Run Configuration .
This drop down menu lists all runs available. The user may choose one and double-click on it. Note that FORCES doesn't actually execute scenarios but instead it executes run configurations which in turn point to the scenario and database (as well as other required data). For information on creating and modifying run configurations click here .
Sim Host .
This drop down menu listing the available hosts appear from which the user may choose one by double-clicking on it. This list is created from the hosts listed in the /etc/hosts file. If the host you want is not on this list you can type the simulation host (by either name or IP address) into this entry. It's a wise idea to open a terminal window and verify you can ping the desired host before trying to execute the simulation; if you can't ping the host FORCES will not be able to execute a simulation on that host. Additionally, you'll need to make certain that you're not restricted from running the simulation on the desired host (even if it's localhost). Click here for help on setting up security.
Use Default Port Yes/No. The establishes the port(s) that this simulation will use for communications with external processes. A port is a Unix communications channel. By default the simulation uses port 3000 as the base port if it doesn't detect another simulation already using that port. If it detects another simulation using that port it will increment by 10 (to 3010) and try again. It will continue this process until it finds an open port and then use that port.
The value of the selected base port will be echoed to the user when he hits the "Execute" button. This is echoed so that the user can connect to the simulation from other platforms.
We refer to this value as the "base port" because in reality the simulation will open not one but a series of ports based upon this value. It will open:
Base port &
base port + 1 - for MMI communications
Base port+2 & Base port+3 - for external applications and data feeds (e.g. ACMI feeds)
Base port+4 & Base port+5 - for external applications and data feeds (e.g. ACMI feeds)
Base port+6 & Base port+7 - for external applications and data feeds (e.g. ACMI feeds)
FORCES opens ports in pairs to eliminate the possibility of communications deadlock by establishing separate input and output communications channels. The reason so many ports are opened is that only one external application from a single machine may communicate to that port, though it's legal to have different applications on separate machines communicating with the same channel on that machine. Thus several (at least 16) MMIs can hook up to the same simulation execution on port 3000 if they're running on separate machines, but only one MMI can hook up to the simulation from any one machine (the machine/port pairs must be unique). Four sets of ports are penned by the FORCES simulation so that four separate application gateways (e.g. An MMI, an AFATDS interface, an ACMI interface, and a VIT interface) can be penned on any one machine. Since FORCES easily spans multiple machines there's never been a reason to use more than 4.
If the user clicks on the "Yes" option, the interface will change to display the Select Simulation Port Form sliding bar. This will allow the user to select a numbered port between 2000 - 4000.
Use caution - if the same port is used as is used by another simulation run the simulation will die when it tries to open the channel (this happens right after initialization).
Change Clock Interval
When selected the sim_start_interval Form appears with a sliding scale of 1000-61000. This permits the user to change the minimum time update between simulation time steps in milliseconds. Larger time steps will execute faster, but can lead to lost resolution, for example if the 60000 is used (60,000 milliseconds) then only 1 in 6 sensor scans will be modeled if the sensor's scan rate is 10 seconds.
Run Options -
User may choose between Batch or Interactive, as described in the overview to this section.
Also, user may choose one Side: White, Red, or Blue to activate. The white selection will set the user up as a simulation umpire. In this case he can view and control all scenario elements in truth (actual positions, not sensor reports), though he can view the scenario from the red or blue perceptions at his discretion. If red or blue is picked only assets reporting to that side will be shown or can be displayed and sensor reports from sensors reporting to his side. In addition, read and blue players will not be provided with may of the system controls available to the umpire. E.G. The red or blue players will not have access to the simulation clock control.
Scenario Aggregation -
Allows the user to select one level for simulation aggregation. The options range from individual aggregation to Corps level aggregation. Aggregation will "Roll Up" elements and belong to ground organizations (e.g. Brigades) below this level to the designated level with the following exceptions:
1) If a group does not have a parent and is below this level (e.g. An unattached company) this group will be rolled up to that level and show up independently, in this case as a company.
2) If the user specified that the group was always to be modeled explicitly when defining the group in the Mission Planner, the group will not be rolled up into a higher level but instead will remain available for individual scenario control This allows the user to specify that selected units (e.g. Recon platoons) are always modeled explicitly and can be individually controlled even when most units are aggregated to a higher level.
The method for roll up is that a list of all assets by type and number in the TO&E of the units (including subunits) is collected. Then one asset of each type is created and the count attribute is set to the total number. Thus it will fight (and die) as a number of assets but for movement and sensor computation purposes it is treated as a single assets (although some sensor reports, notably recon and other intel-type reports, report the current count).
Process Monitors -
May choose Sim Output or Receiver . Selection of these choices will create the same interface as can be displayed after the interface changes to runtime mode by selecting "System Controls->Monitor Execution->Sim (or Rcvr) Monitor". Note that the simulation monitor generally does not work right unless the simulation is running on the local machine (that is the same computer as the interface is running on.)
Replay Configuration -
This permits the user to replay a previously run version of this scenario. This prior run will contain all simulation external information that was sent to the simulation during a prior run. This includes GUI inputs from all human interfaces, live sensor reports, data from testbed interfaces, and so forth. This option will only become active after a run configuration is selected. When selected the user will be able to specify the file to be replayed and the channels to be replayed. Using this latter capability the user can choose to disregard to data from one or more sources when replaying the event (e.g. filter out the inputs from a erroneous sensors). Additional data sources (including GUIs) can be hooked up to the simulation during the replay to either replace or augment the inputs made during the original run.
This executes the options selected above. First a dialog specifying the port that will be used is presented. This is provided to connect to the simulation later either from this machine or a remote machine. SELECT OK! The simulation won't actually start until you respond to this dialog. If you selected an interactive connection the interface will reconfigure for scenario controls. As mentioned in the overview to this section, the simulation won't respond until it has completed its initialization.
Selection of this option will reconfigure the interface to the Simulation runtime mode. Click here for more information.
Connect to Sim Run Form .
This is used to connect to an ongoing simulation either on a remote or local machine. The controls are very similar to the start commands, so while they'll be briefly described here checkout the information under " Start Scenario " for more depth.
This option causes five options to appear:
Sim Host- A drop down menu listing the available hosts appear from which the user may choose one by double-clicking on it.
Select Port - When chosen, a drop down menu listing the available ports appear from which the user may choose one by double-clicking on it.
Monitor Receiver - An On/Off button is provided.
Node Type - From this section chose whether this workstations is either a white, blue or red player. The differences are described above.
Execute - Executes the options selected. Unlike the "Start Scenario" execute button this time no dialog box displaying the selected port number is presented. This is because you had to specify the port number so this dialog would be redundant. The interface will reconfigure itself for runtime scenario controls.
Selection of this option will reconfigure the interface to the simulation runtime Mode.
The Mission Planner is the interface for setting up FORCES scenarios. In this mode the user can deploy scenario elements (assets, groups, targets, environmental elements, terrain and so forth) and give them preplanned missions. Inputs for higher-level planning tools including the automated air defense rules, ATO rules and SIOP planning.
Choosing this tool brings-up the Select Scenario Form . The Select Database and Scenario section of the form presents a list of scenario files and corresponding databases (e.g. tactical - Fort Hood) on a drop down menu. One of these may be accepted or a new scenario may be entered by clicking on New Scenario bar. A new_scen Form appears on which the user may enter the database name. On a second line the name of the new scenario is presented.
Selection of this option will reconfigure the interface to the Mission Planner Mode. See appropriate documentation within the Users Manual.
This is an interface to quickly create a batch job to make a number of runs, identical in every way except the random number seed. It will make these runs and save them in the database when done. The GUI will not attach to the runs, though you can attach to an ongoing batch run manually using the System Controls->Connect option at a later time. This is actually a streamlined interface to the $SCRIPT_DIR/batch_run script, described both on this website under "useful scripts" and internally (just look at the file; the use is described at the top). The script is a much more robust tool than the GUI interface and it's recommended for anybody interested in make batch runs. But the GUI is adequate for occasional use.
Change to RAP Interface
Both the initial setup and the JFORCES runtime can change to RAP interfaces. RAP stands for Radar Analysis Program and is used to maintain a single integrated air picture between the FAA radars, the CCS exercise control systems, SADL and JTIDS equipped aircraft, and a simulation. The description for RAP is found here. Note that it's often very useful to start the scenario first (through the simulation interface) and then transition to RAP using this toggle. You can return from RAP to JFORCES through a similar toggle on the RAP side.
This is used to shut down the GUI (a.k.a Man-Machine Interface, or MMI). If you choose to shut down the interface you'll then be asked if you'd also like to shut down any ongoing simulations. Moreover, if you're in the simulation runtime mode, you'll be asked whether you want to save the data for post processing prior to shutdown.
Review Info Log
The Info log contains all of the messages that have been posted in the blue area. It's most useful if you've missed a posted message when it was updated by a subsequent message. This option will display the messages and the time they were posted.
This encompasses a range Data Base Administration functions, including scenario and run maintenance and database prototyping. There are too many options to provide a meaningful description in this document, so Click here for more information.
This option allows the user to either:
A run is a single scenario execution, or in the case of a Monte Carlo run (generated though the System Controls GUI or the batch_run script) a collection of repeated scenarios, identical except for the random number seed.
The method of loading the data depends on the run mode. When in the initial or Mission Planner Mode, the system requires an input file name. When loading during a run the system just requires a confirmation and automatically looks up the input data file associated with the current scenario. Be aware that loading data for analysis can take a several minutes, and takes longer if sensor detection data is being collected since this data is copious.
For details on running data analysis click here.
These are basically options to save either snapshot or movie images of the screen. These provide interfaces to the standard X utilities to do this. The options are:
Start Movie Maker - The option forks an xvidcap process. By default (if you haven't tailored ~/.xvidcap.scf) this process will save a series of .xwd screen images. But you can also generate an MPEG of image of the screen action. Follow this link for more information. Additional configuration options can be specified; see www.xvidcap.org for more details.
Save screen in File /tmp/ScreenShot.jpg - this saves a JPEG of the screen in the designated area. Frankly, this option is no longer necessary on Linux since the "print Screen" button is usually functional, but this option predates Linux's incorporation of this feature.
Save Screen to Custom File - Like above, but you are permitted to specify a filename. The output is always JPEG format. Again, this option is no longer necessary under Linux since the "Print Screen" button is now functional, but is kept around for alternate installations.
These are both true debug options and programmer references. It also includes access to the icon editor function. Click here for more details.
System Controls (Runtime Mode)
Once the GUI has been put into the runtime mode, either by choosing "Start Scenario" or "Connect" from the initial mode, the system control options change. First, the mode selection options (Start Scenario, Connect, and Mission Planner) are removed from the interface. Addition run-time specific options are added. The new list is:
Allows the operator to monitor several aspects of a particular simulation via five options.
This will result in the message "CHECKING SIM" being displayed in the FORCES Master Controls Message Area (the blue area). If the simulation is working and done with initialization this will change to "Sim Responding". To test whether the simulation is still responding click the "Sim Monitor" (next option) and see if anything scrolls past - indicating the simulation is still initializing. By the way, if you see a message "Sim Terminating - End of Time Reached " the simulation has stopped in a normal mode because it reached the end-of-scenario time defined in the Mission Planning mode. If neither of these cases seem to apply the standard method of checking for whether the sim is running is to open a new terminal window and typing "psg sim" and seeing if the simulation process shows up. This assumes the simulation is running on the local machine; if not repeat the process on the machine hosting the simulation execution (the "Verify Connection" option should work even if the simulation is being run remotely).
The sim must be running to activate the Simulation Monitor Form that presents a running tabulation of the simulation. While this output will scroll over time remember that it will not scroll if the simulation is either not running (e.g. It's already terminated because the end-of-scenario time defined in the Mission Planning mode has been reached) or the simulation is paused. Use the "Resume" .
NOTE: This log simply outputs the tail of the simulation standard output. As such, it will work only on the computer running the simulation, not on remote clients. Also, should you want to review this monitor at your leisure (or use it check for errors - a very good idea with new scenarios) it can be found at /tmp/log.sim(hostname)(port#), e.g. /tmp/log.simlightning3000. It is rewritten with every new simulation run.
The sim must be running activate the Receiver Monitor Form that presents a running tabulation of the receiver portion of the simulation. Like the simulation log described above, this monitor is just a running tail on the standard output of the rcvr process. In this case it works fine on client computers. While this output is not generally as important for scenario debugging as the simulation log, you might want to review it at your leisure. In this case the output can be found at /tmp/log.rcvr(hostname)(port#), e.g. /tmp/log.rcvrlightning3000. Like the simulation output, it is rewritten every new run.
This selection activates a check of the simulation running health. Because it uses ssh commands to check the simulation and receiver functions, this process might seem a bit sluggish. Upon successful conclusion the Check Process Status Form will be displayed. This confirms:
The simulation is still running on the appropriate port, and
The receiver (the invisible GUI application responsible for passing messaged between the GUI and the simulation) is running correctly
If there was a failure you'll see a message stating "Simulation Check Permission Granted/Denied by Host". This might not indicate a real problem with the simulation, sometimes security firewalls that are properly configured to permit JFORCES runs prevent the checks done by this interface to complete successfully. In this case alternate checks might be required to evaluate the system health.
Starts the simulation run initially. Once begun, the Start button converts to a Resume button that may be used to resume the simulation once it is paused (next).
Once the run is begun, the Pause button pauses the simulation (stops the simulation clock). This temporarily stops the execution of all simulation based event updates, although realtime-based events (caused by asynchronous real-time sources, e.g. live sensor feeds) will continue to be processed as received.
This provides GUIs for runtime gateways from FORCES to specific other processes. Currently GUIs are provided for CCS (the interface used for ACMI pod links to live aircraft at some test ranges), VIT(the Virtual Interactive Target simulation), the SADL/EPLARs radio, Jvan JTIDS links, GCCS, USMTF sources/sinks on the LAN, OTH_GOLD (Output Only) and the THAWK (a NAWCAD Tomahawk model). In a few cases (notably AFATDS) critical interfaces were tailored for site-specific needs, so while the functionality is intact the interface is known to require tailoring for generic applications. Information on these interfaces is provided here. In the meantime, the startup interfaces are generally similar in construction, so the CCS startup interface is described here as a typical example.
Connect to CCS
The ccs_connect Form appears and allows the user to:
Specify Interface particulars. In this to case the specification particular is the range that is employed (e.g. Volk Field). The interface will fix the reference lat/long based upon the user's selection.
Specify rendering particulars. In this case the user can specify the desired update rate. Typically the update rate is set to 200 milliseconds (5 Hz), but the use can choose to alter this for his particular needs. In this case the higher update rate will provide "smooth" looking aircraft flights, but if the update rate is set too high the maps might have problems rendering in a timely manner.
Specify execution type- In this case there's a button provided to specify where this is a live execution. Should the user click this button he will be permitted to change to a replay of an archived run. While interface methods differ on on other interfaces, most of our live, 2-way interfaces have some sort of archive and replay capability.
Reporting tailoring - In this case the user can choose to start an interface to the PCDS (PC Debriefing System) concurrently with the CCS interface. In this case the PCDS will provide an alternate view into the exercise. But in general many of the JFORCES interfaces permit "ganged" interface activation to support a range of related capabilities simultaneously.
Start - in this case the option is titled "Execute". This will start up the interface. These interfaces are remote applications that can generally be shut down and restarted at need during a JFORCES execution. Should they appear to "lock up", but the simulation clock continue to update the graphics, the user is restart these applications.
The Clock Controls Form allows the user to set or change the speed and granularity at which the simulation runs. Note that this form changes if the "Lock to Wall Clock" option is selected. Specifically the user may choose:
This sets the execution speed of the simulation versus wall clock (real time). A value of 20 (shown in the example) indicates that the simulation should run 20 times faster than real time, so it should simulate 1 hour of events in 3 minutes. Clearly, at some point the simulation can't keep up. Before this point, however, you might find that your graphics are behaving erratically. In particular you might notice a lack of responsiveness or "jumps" in the asset motion displayed on the maps. In either of these cases you might want to pause the simulation (if not restricted by exercise constraints), wait for the simulation to catch up, and then change the clock speed.
In addition, to increase simulation execution speed you might want to consider running the simulation and the human interface on two separate machines. This will split the processing load. Click here for details.
This changes the scale bar on the time ratio (described above) from an upper limit of 60 to an upper limit of 600. Useful for quick-running small scenarios that are not process limited.
Lock to Wall Clock (On/Off).
When on this permits the simulation to be locked to realtime, either running in realtime or ratios of realtime. When off the simulation runs as fast as it can. Note that your graphical interface might not be able to keep up to the simulation. You'll notice that as either poor interface response and/or "jumps" in asset movement or simulation clock (see the top of the map). In either case if you want to watch the scenario in a more understandable mode, pause the simulation to let the graphics catch up, then lock to the wall clock and change the clock speed to whatever value gives the best results.
In Fast Forward Mode (On/Off)
"Fast Forwards: the simulation by running only the asset/group motion but not running the detection model until the end of the fast forward time. Useful for moving assets quickly to a prescheduled point as long as you weren't relying on any interaction occur during this time.
This presents a scale bar (1-5) on the clock controls. Using this, it is possible for FORCES to "skip" selected sensor scans to improve runtime performance. Setting this to 5 tells the simulation to actually model only the fifth sensor sweep for every sensor; 2 tells it to model every other sweep. The default is "1" and tells the simulation to model every sensor sweep. While occasionally useful you should bear in mind the following:
Any operational workstations (e.g. A radar scope) will be affected by sparse data. In some cases (e.g. GCCS) this might not be a problem; for others it is. Consider your situation
If you're running any actual tracker software (including the Detailed SBIRS model or any sensors outputting JSS raw radar reports to a tracker) the trackers performance will be degraded. On the other hand, the performance of sensors that include "assumed" trackers, and this is all standard sensor models other than these two, will perform adequately. Though detection reports will necessarily "jump" between updates.
Assets might pass right by each other in the ground fighting or air engagement models because the sensor reports are not frequent enough for the simulated assets to keep track of the enemy. This is only a problem when they're in close proximity. Thus you might modify the granularity until the forces close and then change the granularity to 1.
Specific Clock Setting Packages
These are a list of prepackaged clock settings that have been found useful in the past. Some options include:
High Frequency Realtime Input - Runs at real time, 5hz. Good for realtime simulations connected to live subjects
Medium Frequency Realtime Input - Runs at realtime, ½ Hz (1 update every 2 seconds). Good for large simulation confederations
Casual simulation - Run 10x realtime, at least one graphics update every 6 simulated seconds (about twice a second). Good for general checkout over short time periods.
High Speed Simulation - Attempts 200x realtime, with at least one graphics update every 60 simulated second (about 3 times a second in realtime). Good for quick overview.
Checkpointing saves a memory image of the simulation executable so that the simulation can re restarted from exactly this point at a later time. This requires the installation of a separate checkpointing application (typically echkpt on Linux) to save and rerun the file. Because there are so many system-specific installation options this is no longer done as part of the standard JFORCES installation, but JFORCES will support this capability if the user installs an appropriate checkpointing process manually.
When checkpointing is installed this option sets a checkpoint from which the simulation may be started and/or rerun from. Selecting Checkpoint causes the Specify Checkpoint Filename Form to appear which provides the user with a Directory from which a specific file may be selected if the user wishes to recall a previous checkpoint. Or the operator may type the file name at the bottom of the form.
If checkpointing is not installed a message stating "CHECKPOINT ERROR! Checkpointing Not Installed!" will be displayed in the Message Area.
Stop Auto Replay
This option will stop the re-execution of an ongoing replay (Note - A replay is re-injecting messages to the simulation in accordance with an earlier run. These messages could have been from one or more attached MMIs, live sensors, or confederated simulations available during the earlier run). The reason for stopping the replay is that new events or commands generated in the rerun make the original file inappropriate.
Perception Mode (Available only to the Umpire, or White, node)
This option permits the umpire to display the sensor reports available to the blue or red players. Options are:
Displayed Force Type
The operator is provided with options concerning which type of units may be viewed on the screen. One or multiple type(s) of units may be selected at any time during the simulation run. Note that this filter uses the force flag set per asset during presimulation, not the medium the asset is in. So ground vehicles assigned to the Airforce will be shown when "Airforce" shown.
Sensor Type (Currently Disabled)
This control allows the operator to choose Sensor Types to be graphically displayed on the screen by choosing the category and activating/deactivating each or all.
System Controls (Mission Planner)
Once the GUI has been put into the Mission Planner mode by choosing "Mission Planner" from the initial mode, the system control options change. First, the mode selection options (Start Scenario, Connect, and Mission Planner) are removed from the interface. Addition run-time specific options are added. The only new option added to the interface is:
Start Scenario Preview
This option attempts to shut down the Mission Planner and start the current scenario in a runtime mode. Note that to do that not only must a scenario be generated but a matching run configuration must exist. For more information on what a run configuration is and how to set it up click here.