The controller provides the user with a GUI panel allowing to launch a simulator from a configuration file and control the simulation evolution.
The figure below presents the main functionalities of the controller GUI.
Controller GUI
The controller is a federate itself, connecting to the MSF federation. At startup, it reads a configuration file listing the others federates to launch for a particular simulation. Each federate listed could be required or optional. Once the controller is connected itself to the federation, it allows to launch the other federates using two methods: either all the federates listed are launched ("Start All") or only the federates selected in the GUI panel are launched ("Start Selected"). The required federates are selected by default.
The controller monitors the connection state of each federate. When it detects that all the required federates are connected to the simulation, it initiates a Synchronization Point READY_TO_RUN. When set set of federate present at this synchronization point announce are synchronized, the simulation is ready to run from time 0.
The controller is time regulating and time constrained. The GUI controls of the controller permit to control the time advance: Step-by-Step, Run and Stop. The controller also provide a delay parameter allowing to slow down the simulation by waiting the given delay between each time request.
The MSF controller uses the script startMsfFed.csh, located with all its included scripts (located in $MSF_HOME/scripts/ ). This means that the locations.csh script should be valid on all the machines where federates will run.
The MSF controller uses ssh to run remotely the federates if specified in the configuration file. This implies that that the user using the controller can log on all the listed computers using ssh, this without giving a password (adjust your authorized_keys2 accordingly).
To launch the controller, simply issue the following command:
SimController [-g] configuration_file
The "Start Sel" button is normally used to start all the required federates (which are selected by default in the federate list). Each federate will be started on the given host inside an xterm (for output display).
The -g option prints more information, and keep the xterm windows open after the federate quit, rather than starting them iconized in the non-debug mode.
The current controller reads a simple text file with tab delimited fields. The goal is to use a XML file later, and integrate it with the Robot XML, but we are not quite there...
Each line of the file describe a single federate. The example.sim file below shows and example of a simple configuration file.
#Type #Host #Directory #Command #Process #Options #arguments
CreateTracker localhost $MSF_HOME/SIM Linux/test_CreateTracker test_CreateTracker required K9 Rover
ListenTracker localhost $MSF_HOME/SIM Linux/test_ListenTracker test_ListenTracker required
H-LAB localhost PATH H-Lab_COMv2 H-Lab_COMv2 optional
The federate configuration fields are explained below:
- Type (first field)
- Describe the name of the federate (in strict HLA, this is the federate Type, multiple federate potentially having the same type). This name is the reference ID to identify the federates connecting to the federation, and thus monitoring when all the required federates are connected. The controller currently does not have the ability to force the federate it starts to have the given name (see "Current limitations" section), so it is very important that this name match the argument of the
setFederateName used in the federate startup code.
- Host (second field)
- Define the host on which the federate will be launch.
- Directory (third field)
- Define the location on the remote/local host from where the federate will be started. This should be an absolute path valid on the host filesystem. Two special keywords are available to avoid having to specify lengthy path:
- $MSF_HOME (this is a fake variable) will be replaced by the localhost $MSF_HOME.
- PATH simply means that the federate executable is located in one of the remote host path. Note that the startMsfFed.csh script add the
$MSF_HOME/host_platform/bin to the current path. Thus, as most MSF components are located is this directory, PATH will work for most of the scenarios with standard MSF components.
- Command (fourth field)
- This is the actual executable or script to launch to start the federate. The
startMsfFed.csh will differentiate executables and scripts and take the appropriate actions to start correctly the federate.
- Process (fifth field)
- This is the name of the federate process once launched. It can be different than the
Command field when the command is actually a script launching another executable. This field is used to kill the federate when something goes bad in the simulation. The controller currently use brutally the killall command, but we hope to improve the situation, and suppress this field altogether.
- Options (field 6)
- This is a list of options attached to this federate. Currently only one option per federate is allowed, and it can only have two values:
- required: the federate is required for initial synchronization
- optional: the federate is listed in the list of federate potentially launch-able, but the federate is not required to perform the initial synchronization.
- Arguments (optional field 7)
- These are arguments that can be passed to the federate at launch time. Leaving this field empty is valid if no argument is required. Any character is allowed (included white spaces and tabs) in this field. The controller will simply add everything that is between the sixth argument and the return line to the command used to launch the federate.
- The field
Type of the description file is used by the controller to monitor the federates connecting to the simulation. However, since most MSF federates do not accept the command line argument to define the federate name (-n, --federate_name=FED_NAME Optional federate name (type), there is no way to enforce for now that the started federate will actually have the correct name (it is most often hard coded inside the main program of the federate).
- All the hosts should share the same filesystem (NFS or AFS) or at least have the exact same directory structure. For example, the
MSF_HOME environment variable is used to located the startMsfFed.csh script. When starting a remote federate, the controller simply assume that the startMsfFed.csh script will be found in the same $MSF_HOME than the local host.
- The action of the controller is not well defined is several button are pressed before the sequences of actions of one button is finished. For example, after clicking on "Start Sel." one should wait that all the federates are connected before trying to click on a Federate button.
Generated on Thu Apr 7 18:21:15 2005 for MST API by
1.4.1