Configuring Simulations
Behavior Execution Engine identifies simulations by looking for InstanceSpecifications with the
Moxie-Base::Configuration::MoxieSimulation stereotype applied.
If you are using the template from Configuring a Project for Simulation, that template provides you with some examples of creating the most basic instances to run a simulation.
Figure 1: Simulation stereotype tag settings for Behavior Execution Engine
As of 2024R2, all dependencies and references to the No Magic SimulationProfile.mdzip have been removed and are no longer required to create simulation projects with Behavior Execution Engine. So, Cameo Simulation Toolkit is no longer required to create and execute Behavior Execution Engine simulations.
Simulation instance specification
For Behavior Execution Engine 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 spawn instances during a simulation, but you must use an existing instance specification to do so.
If you are using the template from Configuring a Project for Simulation, a
simulation instance specification called Simulation::simulation is already created for
you.
To inform Behavior Execution Engine which classifier behaviors to start, the
simulation instance specification must have the MoxieSimulation stereotype applied.
Then, the simulation will instantiate and run any other instance specifications referenced from the simulation instance's slots.
You can see an example of this in the Moxie-Base::Configuration::SimulationSpecification type. It provides a
simple classifier with a single property called "roots" that allows users to include anything into a simulation by populating the slots
with other systems of interest.
The roots slot in Figure 2 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, Behavior Execution Engine
will start the
Structure::System::System state machine.
Figure 2: A Simulation Instance Specification roots slot
Stereotypes
The analysis tools for the simulation are configured by applying stereotypes to the same instance as MoxieSimulation.
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.
MoxieSimulation
The Moxie-Base::Configuration::MoxieSimulation stereotype enables you to configure how a simulation will run.
The simulationStart and simulationStop times define 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-time string using ISO 8601 format using the UTC time zone (Z). Behavior Execution Engine does not support local
time offsets from UTC.
Figure 3 shows the MoxieSimulation stereotype applied to the simulation instance specification.
Figure 3: The MoxieSimulation configuration stereotype
MoxieDelegateModulePaths
The Moxie-Base::Configuration::MoxieDelegateModulePaths stereotype enables you to specify which delegate modules to
load instead of having Behavior Execution Engine 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:\Delegates\com.agi.moxie.sample. However, they may not be as portable when deploying across different machines. The two relative path options enable you to specify paths with respect to either the delegate module home directory or the directory containing the current SysML project file.
The home directory for delegates is the delegates directory in your Behavior Execution Engine installation directory.
This is the home directory for Behavior Execution Engine delegates on each system.
This is where you can 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 = ".\com.agi.moxie.project1", ".\com.agi.moxie.shared"
while another project specifies homeRelativePaths = ".\com.agi.moxie.project2", ".\com.agi.moxie.shared".
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 project file and the delegate
modules together.
STK stereotypes
STK-related features are only available if you acquired Behavior Execution Engine as part of STK Enterprise or otherwise have a valid license for STK. If you acquired Behavior Execution Engine as part of ModelCenter Enterprise but have access to a valid STK license, contact us for access to the STK-related features.
You can apply one of several stereotypes to the simulation instance specification to provide the
STK controller
with information on how to interact with STK or STK Engine, 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.
When running a simulation connected to an STK scenario, the scenario's start and stop times will constrain the interval of time that the
simulation will run through.
Figure 4 shows an example of specifying the configuration of an STK simulation.
Figure 4: Configuration stereotypes for an STK-based simulation
Moxie-STK::Configuration Stereotype
|
Description |
|---|---|
MoxieStkScenarioFromFile
|
This stereotype tells the
|
MoxieStkNewScenario
|
This stereotype tells the
|
MoxieStkExistingProcess
|
This stereotype tells the |
MoxieStkEngineScenarioFromFile
|
This stereotype tells the
|
MoxieStkEngineNewScenario
|
This stereotype tells the
|