Integrating with STK to Create a Digital Mission Simulation

In the first and second tutorials, you modeled the subsystems of a UAV in SysML, and used Moxie to simulate various interactions between those subsystems. In this final tutorial, you will integrate a final version of that UAV system model with a physical environment modeled in STK to collectively model an entire digital mission. You will then run the digital mission simulation to see how well the UAV carries out its objective as it reacts to other objects in the environment.

In this tutorial, you will write Java delegates, build them with Gradle, and run STK. Please make sure you have installed all of the prerequisites before beginning.

Section	Description
Examining the Mission Components	Modeling a mission in SysML is essentially the same as modeling a system. You define the blocks, instance specifications, and state machines for the actors in the mission, and then you can use Moxie to execute the simulation. The difference is that mission simulations often require modeling high-fidelity, time-dynamic, physics-based aspects of the systems and environment. With Moxie, you can integrate analysis tools like Systems Tool Kit (STK) into your simulation and let them handle those physics complexities implicitly, without needing to explicitly build the physics into your SysML. In this section, you will examine a pre-made STK scenario of a UAV flying a mission, as well as a SysML model based on the previous tutorials but updated to include the important elements of the mission.
Creating a Delegate Module	A delegate is a Java interface or class that uses custom code to implement the properties and operations of its corresponding SysML block. A delegate module is just a JAR file containing a group of delegates for Moxie to use as it executes a simulation. In this section, you will configure a delegate module project template for your environment and then build and install a delegate module JAR file for the UAV mission. Since you will not have written any delegates, the JAR file will not do anything yet. You will simply have verified that you are set up to start writing custom delegates. This section covers the following concept: Building a delegate module
Streamlining Development with the Java Delegate Code Generator	Moxie provides a Java delegate code generator that can generate delegate interfaces for all of the blocks in a SysML model, class stubs for the blocks, and a delegate provider that registers the delegate module with the Moxie Engine at runtime. These generated files include everything that the Moxie Engine needs in order to connect the delegates to the SysML model, allowing you to focus on the methods that need custom implementations. In this section, you will generate delegates for the UAV mission and install them for Moxie to use. This section covers the following concepts: The Moxie delegate code generator Moxie delegate auto-implementation Moxie delegate providers Moxie delegate annotations Moxie delegate properties The Moxie delegate availability report
Handling Circular Dependencies with Delegate Wire-Up	SysML permits circular dependencies, and it can be very useful for two blocks to each have a reference to the other, but it can also cause instantiation problems in executable software. Fortunately, the Moxie Engine wires up the delegates in such a way that you can avoid these problems while retaining the usefulness of mutual references. In this section, you will use the delegate wire-up to safely establish the circular dependencies between the UAV, computer, and ground station delegates. This section covers the following concept: Moxie delegate wire-up
Logging Messages and Debugging Delegates	As when writing any custom code, when writing your delegates you will likely want to have them log messages and to debug them in your Integrated Development Environment (IDE). Moxie makes both of these tasks more convenient by providing a built-in simulation logger and by configuring your No Magic modeling tool for debugging for you. In this section, you will debug an exception using both log messages and your Java IDE's debugger. This section covers the following concepts: The Moxie SimulationLogger Delegate debugging
Coordinating State Machines with Signal Events	Similarly to call events, which you learned about in the previous tutorial, signal events enable state machines to interact with each other. Signal events, however, are less direct: they trigger in response to a signal from another state machine instead of being called directly by that state machine. Additionally, these signals can only be sent in a Moxie simulation from within the delegate code. In this section, you will replace the ground station's call to shutdown the UAV with a signal event. This section covers the following concepts: Signal events The Moxie StateMachineRemoteControl
Connecting to STK from Delegates	The Moxie Engine uses analysis tool controllers to communicate with external tools like STK. At the start of a simulation, an analysis tool controller instantiates all of the delegates associated with it, injecting dependencies from the external tool into the delegates for them to use. You can implement custom analysis tool controllers for other tools, but since the UAV mission only requires STK, you will just use Moxie's STK controller in this tutorial. In this section, you will set up the STK controller and its STK toolbox dependency, initialize the STK object data, and use a SysML stereotype to configure the simulation to start the STK scenario when the simulation starts. This section covers the following concepts: Moxie delegate module descriptors Moxie analysis tool controllers, especially the STK controller Moxie's STK toolbox Moxie's StkObjectSpatialEntity delegate Moxie simulation configuration with stereotypes, especially STK simulation configuration
Integrating with STK from Delegates	Integrating with external analysis tools like STK involves passing information back and forth to control all of the tools together as a single simulation. Timing information is especially important, and this is where Moxie excels. Moxie manages time continuously instead of requiring external tools to use discrete time steps, and it supports multiple time formats, including ISO8601, Gregorian, Julian, and STK's native representations. In this section, you will use the delegates to set (1) the UAV takeoff time in the STK scenario based on the SysML model, and (2) the flight duration in the SysML based on the route in the scenario. This section covers the following concepts: MoxieTime and the Moxie TimeProvider STK integration
Detecting Events using Continuous Time	Moxie allows external tools to perform complex analysis over time naturally, instead of forcing them to use shared discrete time steps. This is especially helpful for analytical calculations that do not require time steps at all. The Moxie Engine can then ingest this analysis as time-varying values and use those values for triggering change events. In this section, you will use STK Access to compute the BooleanValue for when the sensor should take a photo. You will also control the camera in the STK scenario to point at and actually take photos of the objects of interest. This section covers the following concepts: Continuous event detection Moxie's DataProviderExecutor

Start Tutorial!