Simulation Configuration

Moxie requires a Simulation Configuration with the following properties:

Execution Target must be set to a simulation instance specification, which informs Moxie which classifier behaviors to start.
Engines Priority must list Moxie Engine first, otherwise the Moxie Engine will not be used. Instead, the simulation will run using the default engine.
Silent should be set to false if you would like to see the behavior diagrams and simulation dashboard animate as the simulation executes.

Figure 1: Simulation configuration properties for Moxie

You should not set the values in the Timing section of the Simulation Configuration, as Moxie will ignore them. Moxie utilizes its own clock, which safely coordinates the advancement of time at specific moments across all systems in the physical environment. This is much different from the default clock used by Cameo Simulation Toolkit, which uses the CPU clock to measure time elapsed since the start of the simulation.

If you are using the Moxie Simulation Project template, all of these properties are already set correctly for you.

Simulation configuration diagram

Figure 2 shows a Simulation Configuration Diagram, a convenient alternative to viewing and updating the simulation configuration from its specification window. Additionally, it provides a context menu that enables you to perform useful functions, such as executing the simulation. You can access this context menu by right-clicking on the Simulation Configuration in the Containment Tree.

Figure 2: A typical Simulation configuration diagram

Simulation instance specification

In order for Moxie to instantiate runtime objects from the blocks you have defined in your model, you should first create their corresponding instance specifications in SysML. You can create instances during a simulation, but they must be created by already existing instance specifications.

In particular, a simulation instance specification must be present in order to run a Moxie simulation. It is what serves as the simulation configuration Execution Target, informing Moxie which Classifier Behaviors (i.e., state machines) to execute when the simulation starts. Its classifier must be Moxie-Base::Simulation::SimulationSpecification, which resides in Moxie-Base.mdzip.

If you are using the Moxie Simulation Project template, a simulation instance specification called Simulation::simulation is already created for you.

In order to inform the Moxie Engine which classifier behaviors to start, the simulation instance specification must contain one or more instance specifications in its roots slot. These instance specifications must have classifiers that own the classifier behaviors to be started by Moxie. Moxie will not only instantiate the instance specifications in the roots slot, but it will also instantiate any other instance specifications that those root instance specifications reference as well.

The roots slot in Figure 3 contains an entry for system, which has a classifier of Structure::System. Assuming that Structure::System is the block shown in Blocks, it owns a Classifier Behavior named Structure::System::System. When the simulation begins, Moxie will start the Structure::System::System state machine.

Figure 3: A Simulation Instance Specification roots slot

Stereotypes

The analysis tools for the simulation are configured by applying stereotypes to the execution target, the simulation instance specification. Applying stereotypes to the simulation instance specification enables you to tag it with additional data, such as the analysis start and stop times or tool-specific information like the path to an STK scenario file to load.

Figure 4 shows the application of a stereotype to the simulation instance specification to indicate the simulation-level settings.

Figure 4: A configuration stereotype for a simulation

MoxieSimulation

The Moxie-Base::Configuration::MoxieSimulation stereotype enables you to configure how a simulation will run. The simulation will use the simulationStart and simulationStop times in conjunction with the STK scenario start and stop times to create the interval of time the simulation will run through. For a new scenario, the scenario analysis start and stop times will be set to these values. Specify the date string using ISO 8601 format using the UTC time zone (Z). Moxie does not support local time offsets from UTC.

STK stereotypes

You can apply several stereotypes to the simulation instance specification to provide the STK controller with information on how to interact with STK, such as the epoch time and whether to spawn a new instance of STK prior to the simulation start, create a new scenario, or load an existing scenario. Stereotypes are not required. If you do not apply any stereotypes, the StkController will attach to the running instance of STK and use its loaded scenario's start and stop times. In this case, you will want to ensure only one instance of STK is running. Otherwise, your simulation will not connect.

Figure 5 shows an example of specifying the configuration of an STK simulation.

Figure 5: Configuration stereotypes for an STK-based simulation

STK Stereotype Description

STK Stereotype	Description
`Moxie-STK::Configuration::MoxieStkExistingProcess`	If you apply this, the `StkController` will attach to an existing process of STK and use the scenario that is currently loaded. In this case, you will want to ensure only one instance of STK is running. Otherwise, your simulation will not connect.
`Moxie-STK::Configuration::MoxieStkNewScenario`	If you apply this, the `StkController` will spawn a new instance of STK and create a new scenario prior to simulation. If you would like to keep STK from popping up during your simulation, set the `isVisible` tag to `false`. If the `shutdownAfterSimulation` tag is set to `false`, the new instance of STK that is spawned will remain running after the simulation ends. If you would like the new instance of STK to close after the simulation ends, set `shutdownAfterSimulation` to `true`.
`Moxie-STK::Configuration::MoxieStkScenarioFromFile`	If you apply this, the `StkController` will spawn a new instance of STK and will load a scenario from the .sc or .vdf file specified in the `scenarioFilePath` tag. You can use an absolute path or a relative path. The relative path is relative to the directory where the No Magic project file (.mdzip or .mdxml) is located. If you would like to keep STK from popping up during your simulation, set the `isVisible` tag to `false`. If the `shutdownAfterSimulation` tag is set to `false`, the new instance of STK that is spawned will remain running after the simulation ends. If you would like the new instance of STK to close after the simulation ends, set `shutdownAfterSimulation` to `true`.

Moxie-STK::Configuration::MoxieStkExistingProcess

If you apply this, the StkController will attach to an existing process of STK and use the scenario that is currently loaded. In this case, you will want to ensure only one instance of STK is running. Otherwise, your simulation will not connect.

Moxie-STK::Configuration::MoxieStkNewScenario

If you apply this, the StkController will spawn a new instance of STK and create a new scenario prior to simulation.

If you would like to keep STK from popping up during your simulation, set the isVisible tag to false.

If the shutdownAfterSimulation tag is set to false, the new instance of STK that is spawned will remain running after the simulation ends. If you would like the new instance of STK to close after the simulation ends, set shutdownAfterSimulation to true.

Moxie-STK::Configuration::MoxieStkScenarioFromFile

If you apply this, the StkController will spawn a new instance of STK and will load a scenario from the .sc or .vdf file specified in the scenarioFilePath tag.

You can use an absolute path or a relative path. The relative path is relative to the directory where the No Magic project file (.mdzip or .mdxml) is located.

If you would like to keep STK from popping up during your simulation, set the isVisible tag to false.

MoxieDelegateModulePaths

The Moxie-Base::Configuration::MoxieDelegateModulePaths stereotype enables you to specify which delegate modules to load instead of having Moxie load all of the modules in your delegate module home directory.

There are three tags on this stereotype: absolutePaths, homeRelativePaths, and projectRelativePaths. Each enables you to specify delegate module directories to load. A delegate module is a directory containing the JAR files needed for loading a DelegateProvider and its delegate classes prior to running a simulation. They are usually folders named after the package name of the delegate module project, such as com.agi.moxie.tutorial.uavmission.

Absolute paths enable you to specify a set of full paths to where delegate modules are stored on the current system, for example, C:\Moxie\Delegates\com.acme.module5. However, they may not be as portable when deploying across different machines. The two relative path options allow you to specify paths with respect to either the delegate module home directory or the directory containing the current .mdzip or .mdxml project file.

You can configure the home directory in your No Magic modeling tool in Options > Environment > Moxie > DelegateModuleHomePath. This enables you to specify a home directory for Moxie delegates on each system and then deploy updated modules with the same relative paths across different systems. This also enables a per-simulation way to distinguish between different versions or different implementations of dependencies for a specific project. So for example, one simulation may specify homeRelativePaths = ".\projectONE\com.acme.moduleOne", ".\shared\com.acme.baseDomainModels" while another project specifies homeRelativePaths = ".\projectTWO\com.acme.moduleTwo", ".\shared\com.acme.baseDomainModels". In this case, both projects will load the shared module, but each will only load its specific project module while ignoring the other's project module.

The projectRelativePaths tag works much the same way as homeRelativePaths, but it uses the location of the active SysML project to determine the root path. This allows distribution of both the .mdzip project file and the delegate modules together.