Enhancing Your Simulation with Useful SysML Features

In the previous tutorial, you created a basic SysML model of a UAV. In this tutorial, you will learn about useful SysML features for simulation, and add them to that model, improving the subsystems' behavior and adding interactions between the subsystems. You will use an even further expanded version of this UAV system model in the final tutorial when you integrate it with STK to model an entire digital mission.

Section Description
Executing Multiple State Machines

Simulating behaviors at the mission level often requires multiple state machines. In this section, you will create a state machine for the UAV's onboard computer and a simulation dashboard that allows you to view the execution of both the computer and power system's state machines at the same time. You will also use the simulation state history log to help debug your simulation.

This section covers the following concepts:

Adding Execution Logic with Guards and Effects

State machine execution logic is defined by triggers, guards, and effects. A trigger is an event that indicates when a transition should be traversed (immediately, if unspecified); you will explore triggers in later sections. A guard specifies whether a transition may be traversed, and an effect specifies what happens if it is traversed. In this section, you will use an effect to turn on the power system and then a choice and guards to determine the power system's state.

This section covers the following concepts:

Identifying Errors with the Model Validation Report

Opaque expressions require precise syntax, but since they are manually typed into your modeling tool, they are prone to error. Even a single misspelled block property or operation in a transition effect will cause Moxie to throw an exception at simulation run time. Fortunately, Moxie provides a model validation report to assist you in identifying these errors before you run your simulation. In this section, you will intentionally introduce a couple of errors into your simulation and then use the model validation report and element locator to find the errors so that you can fix them.

This section covers the following concepts:

Coordinating State Machines with Call Events

In a complex mission simulation, the systems involved interact with one another as you carry out the mission objectives. So, in SysML, the state machines for those systems must interact with each other. You can achieve this in Moxie in two ways: call events and signal events. However, signal events in Moxie require using the delegate architecture, so you will not use them until the Signal Events section of the next tutorial. Call events enable state machines to invoke operations on their owning instance or on instances that their owning instance refers to. In this section, you will use a call event to have the computer turn on the power system instead of having the power system turn itself on at the start of the simulation.

This section covers the following concept:

Scheduling Transitions with Time Events

Most complex simulations require the execution of behaviors at specific times, which you can do with either absolute or relative time events. Absolute time events allow you to specify a precise moment in time to trigger a transition, while relative time events allow you to specify a time duration to wait before triggering a transition. In this section, you will use time events to specify the simulation time at which the computer should turn on the power system, and how long to wait before checking whether or not the power system successfully turned on.

This section covers the following concept:

Simulating Simultaneous Behaviors with Composite States

In order to simulate simultaneous behaviors within a state machine, you must use a composite state. A composite state is a single state divided into orthogonal regions, each of which contains substates that represent that region's behavior. The substates are only mutually exclusive within each region, not across regions, so that all of the regions can execute at the same time. In this section, you will use a composite state to simulate the computer interacting simultaneously with both the power system and the flight controller.

This section covers the following concepts:

Creating Reactive Transitions with Change Events

In addition to call events and time events, another way to initiate behaviors in a Moxie simulation is through change events. A change event evaluates a boolean expression over time and triggers its transition when the expression changes from false to true. In this section, you will use a change event to have the computer detect when the power is on and then instruct the flight controller to arm (unlock the safety on) the UAV's motors.

This section covers the following concept:

Handling Multiplicity in State Machines

Multiplicity defines the number of instances that can exist for a given part or reference property. For example, assume the UAV in this tutorial is a quadcopter with exactly four distinct motors: one to power each propeller. This translates to a multiplicity of 4..4 (minimum of 4 and maximum of 4) in SysML. In this section, you will use a repeating substate to have the flight controller arm each motor one by one.

This section covers the following concepts:

Start Tutorial!