Getting to Know Moxie

This document provides a high-level overview of the different components that make up Moxie, as shown in Figure 1.

Figure 1: What does Moxie include?

Moxie plugin for No Magic modeling tools

The Moxie plugin for No Magic Modeling Tools contains the Moxie Engine, Java libraries, reports, and utilities.

The Moxie Engine

The Moxie Engine ingests, interprets, and instantiates your formal models, and embeds them into a simulated physical environment, modeled by STK and other analysis tools. It uses patented AGI technology to coordinate time across all objects in the simulation as events take place. The Moxie Engine overrides the default execution engine in Cameo Simulation Toolkit (CST) to orchestrate every transition of every state machine in your simulation. It does not use the simulation clock provided by CST. Instead, it uses its own clock that safely coordinates the advancement of time at specific moments across all systems in the physical environment. In other words, a discrete timestep is not used to move the simulation forward. This is different from the default CST built-in clock, which uses the CPU clock to measure time elapsed since the start of the simulation. To learn more about how the Moxie Engine coordinates time, take a look at the introductory section of the Events help topic.

The Moxie Engine replaces the default engine used by CST. To ensure the Moxie Engine will be used for simulations by default, you should set it as the highest priority engine in your No Magic modeling tool, which you can do in Options > Environment > Simulation > Engines Priority. Keep in mind that individual Simulation Configurations may override this default.

Analysis tool integration

Analysis tools such as STK, finite element tools, and proprietary system response software excel at modeling complex physics environments precisely. Moxie leverages these tools to model the time-dynamics of simulated systems. As the Moxie Engine coordinates events between state machines, it manages the exchange of data with your custom Java delegates, which in turn interact with your analysis tools. Delegates are the key component of Moxie's dependency injection architecture, allowing you to inject custom code to be executed in conjunction with time events, change events, and guards.

This integration of responsibilities and customizable execution allows you to focus on system design without the burden of modeling the physics environment. For example, you can simulate the interaction of systems modeled at different time scales, using different analysis methods, without requiring them all to participate in the same numerical integration. Furthermore, you can correlate these events to the associated analysis tools' output (reports, visualizations, etc.), highlighting key behaviors warranting further investigation.

Debugging with Cameo Simulation Toolkit (CST)

Moxie uses CST's animation feature to depict the active states and transitions of your simulation as it executes. Moxie also leverages CST's debugging features, giving you the ability to set breakpoints, pause and resume the simulation, and step into and over state transitions. Furthermore, Moxie complements CST's debugging capabilities and allows you to debug the custom code in your delegates as well. You can take advantage of these features to conduct further analyses at key decision points, with the system paused in an accurate "view of the world" at any point in your simulation.

Delegates and delegate modules

A delegate is a Java interface or class that represents a one-to-one correspondence between itself and a block in your model. A class delegate contains custom code which implements the properties and operations of a block. This code is executed when the opaque expressions in state machines are evaluated at simulation runtime. Though any arbitrary Java code may exist inside a delegate, you reap the true benefit of Moxie when you use delegates to integrate the analytical rigor of physics-based analysis tools to precisely drive state machine transitions in a simulation.

Collectively, all delegates used for a particular analysis tool are referred to as a Delegate Module.

Moxie also allows you to have multiple delegate implementations for any given block. Depending on the application, these implementations may contain entirely different logic or even use different analysis tools. You may then specify which implementation to use for each Instance Specification by applying the appropriate stereotype. For more information, see the Stereotypes help topic.

The delegate availability report is an excellent way to see which delegates are available based on the currently loaded delegate modules.

For a comprehensive guide to developing delegates and using them in your simulations, see Developing Delegates.

Reports and utilities

You can find the Moxie reports and utilities in the Moxie menu in your No Magic modeling tool:

Figure 2: Moxie menu providing access to reports and utilities

Model validation report

The model validation report runs a validation process against your state machines and the model elements referenced within them. This checks whether the opaque expressions that reference properties and operations are in agreement with their corresponding blocks and delegates, and that they are compatible with the Moxie Engine. The validation process looks for naming inconsistencies, invalid access usages, incorrect return types, and many other issues.

When the process is finished, it presents you with a list of detected errors and warnings in your default text editor. Each error and warning in the report is paired with the ID and qualified name of the offending element in your model. Use this tool early and often when developing your simulations to identify issues all at once, so you can correct them prior to execution. You can find the model validation report in the Moxie menu.

The model validation report will not always catch everything that could go wrong with your simulation. Sometimes there may be a configuration error or a bug in the delegate code that causes your simulation to fail at runtime. In this case, the best place to look is in the simulation log file.

For more details, see the Model Validation help topic.

Element locator

The element locator utility is a perfect companion to the model validation report. Since the model validation report specifies the IDs of the elements that have issues, you can use the element locator to easily find those elements in your No Magic modeling tool's Containment Tree. It will even select the referenced element in the tree for you. You can find the element locator in the Moxie menu.

Sometimes the model validation report will list elements that do not show up in the Containment Tree. The element locator will ask you if you would like to make those elements visible before selecting them.

Delegate availability report

The delegate availability report shows the canonical Java class names of the delegates and delegate modules that the current simulation will load. This report helps to verify that the delegate modules have been deployed correctly and do not conflict with each other when multiple modules are loaded together. In addition, it shows the qualified name of the block each Java class represents. You can find the delegate availability report in the Moxie menu.

Block usage report

The block usage report report lists all properties and operations currently in use by the state machines defined within your simulation. With this information, you can identify missing state machine elements or determine whether or not an element is referenced incorrectly. You can find the block usage report in the Moxie menu.

Delegate code generator

The delegate code generator utility generates Java interfaces and classes based on your model that are compatible with the Moxie delegate architecture. You can find the delegate code generator in the Moxie menu.

For more details, see the Delegate Code Generation help topic.

Runtime code generation

As your simulation executes, Moxie automatically generates default delegate implementations for model types that do not require custom implementation.

Build, install, and debugging support

Moxie includes custom scripts that allow you to build your delegate modules, install them in the appropriate location, and debug them with ease. You can set breakpoints and step through your code in your preferred IDE at simulation time. In addition, Moxie's hot code reloading capability allows you to rebuild your delegates and overwrite previous versions at the same time. Best of all, the updated code is ingested and loaded automatically when you rerun your simulation, without requiring you to restart your No Magic modeling tool.

For more details, see the Delegate Modules help topic.

Moxie model libraries

Moxie includes several model libraries, both core models that you should use as the basis for all of your model's blocks, and some specific models for analysis tools like STK.

For more details, see the Moxie Model Libraries help topic.

Balloon Ride reference application

The Moxie installation includes a sample reference application depicting a simplified one-dimensional hot air balloon ride. This sample will help you understand how the pieces of Moxie fit together without having to deal with complicated physics or to integrate external tools. You can find the SysML project and the associated delegate source code in the \samples\balloonRide directory of the installation.

Tutorials

The Moxie tutorials will guide you through applying the above concepts to create and utilize a complete Moxie simulation from the ground up. The tutorials are broken up to give you the flexibility to practice individual concepts without having to step through everything from the very beginning.

For more details, see the Tutorials.