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 Behavior Execution Engine 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. You may also want to install an Integrated Development Environment such as Eclipse, IntelliJ IDEA, or VS Code to make developing delegates and building with Gradle easier.
You will only be able to fully follow along in this tutorial if you acquired Behavior Execution Engine as part of STK Enterprise.
| 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 Behavior Execution Engine 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 Behavior Execution Engine, 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 Behavior Execution Engine 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: |
| 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, Behavior Execution 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:
|
| 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). Behavior Execution Engine makes both of these tasks more convenient by providing a built-in simulation logger. In this section, you will debug an exception using log messages. This section covers the following concepts:
|
| 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 Behavior Execution Engine 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:
|
| Connecting to STK from Delegates |
Behavior Execution 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 Behavior Execution Engine'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:
|
| 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 Behavior Execution Engine excels. Behavior Execution Engine 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:
|
| Detecting Events using Continuous Time |
Behavior Execution Engine 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. Behavior Execution 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:
|
| Debugging State Machines During Execution |
Similarly to Logging and Debugging, a big part of integrating STK and SysML together is understanding how the SysML behaviors are affecting the behaviors of objects inside the STK Scenario. Being able to pause a SysML model execution at critical decision points as it modifies the STK Objects and settings allows you to see how all the systems and sub-systems are interacting. While STK provides a time-dynamic 3D view of what is going on in the system environment, the state machines show details of the interactions with sub-systems that are not displayed directly in STK. This also provides an avenue to show the interaction between systems represented in different tools. While this example focuses on STK, the systems represented in SysML may be using many different tools to represent all the systems, sub-systems, and components. Seeing the behaviors will help provide a cohesive picture across all the tools. This section covers the following concepts: |
Start Tutorial!