All features supporting the SysML v2 BETA specification are currently ALPHA and subject to change. The final SysML 2.0.0 specification is expected to be officially adopted in the second half of 2025. While there have been many questions during the finalization, we believe this implementation provides enough value for early adopters to start preparing to create and execute models using the new specification. We will be expanding support for the specification through finalization, into SysML v2.1, and beyond. There are a small number of remaining issues related to execution scheduled for revision in SysMLv2.1. We will be expanding and clarifying support for SysML v2.x throughout the upcoming language revision process. Consult the What's New and Modeling with SysML v2 pages for more information about what is currently supported.

Execution Heuristics

This page details the rules of thumb for building SysML v2 models that Behavior Execution Engine can successfully simulate. Behavior Execution Engine currently supports executing models with all the following SysML v2 offerings. If an offering is not listed below, Behavior Execution Engine may not support its intended functionality as specified.

Actions

Actions enable systems engineers to circumscribe a unit of behavior for another element within the architecture. Decomposing an action into other subActions allows simple behaviors to hide complex details of the operation of hierarchical systems. Behavior Execution Engine will finish executing automatically after finishing the execution of all the action's subActions. In other words, unless there are any events, constraints, or other behaviors causing an action to wait before it completes, it completes immediately without taking any simulation time. To ensure actions take an expected amount of time, consider modeling the duration of an action by including a delay in the form of a relative or absolute time trigger.

Successions

You can define successions to detail the relative time order of occurrences. This includes ordering actions to occur in a specific sequence. If an action is the target of any succession, then the source action implies a new performance of the target action. This is notably true of the 'startAction' which always occurs at the start of any action (or state). For information on creating "conditional successions" or modeling with decision actions, see Non-State Transitions.

Forks

In SysMLv2, successions leaving an action imply parallelism. However, using a fork action can make diagrams easier to understand by visualizing that parallelism explicitly.

Join

Behavior Execution Engine does not yet support join action functionality.

States

States are types of actions that represent stable configurations of a system. They can coordinate the performances of their owned subStates, connected by state transitions. You can define states with entry, do, and exit actions that will execute at specific times within the life of the state. The entry action always occurs after the start of a state. The do action occurs immediately after entry and can be interrupted by exiting the state. The exit action occurs just prior to the end of the life of the state.

A state will exit when one of the following conditions becomes true:

  • A state transition leaving the state observes a triggering event and its guard is true (or no guard is defined).
  • The following conditions are all met:
    • There are no active subStates and no active owned actions.
    • A state transition without a trigger has this state as its source.
    • The guard on at least one of the transitions with no trigger is true. (If more than one transition is valid, Behavior Execution Engine selects from the valid transitions at random.)
  • The state owning this one will exit (and thereby interrupts this state's doAction and any unexecuted transitions).

Transitions

State Transitions

You can define state transitions to detail when one state will exit and execution will proceed. State transitions have triggers that can fire in response to certain conditions during simulation, causing Behavior Execution Engine to evaluate any guard expression defined on the transition. If the guard expression evaluates to true, the source state will exit, any effect on the transition will execute, and execution will proceed to the target state.

Guard expressions are only evaluated in response to triggering events. This means that a guard expression must evaluate to true at the exact time the transition's triggering event occurs, or the transition will not be traversed.

States and the state transitions that connect them execute in a specific order. Triggers of transitions only start observing the triggering events after finishing the entry action of the source state. This means that no transition can interrupt a source state during the entry action.

When a state transition's triggering event occurs, Behavior Execution Engine forces the source state to exit, it interrupts any currently executing subOccurrences, and then the state is done executing. After the source state is done executing, the transition executes its effect action and traverses to the target behavior.

Additionally, only one transition leaving a state can be traversed, even if multiple transitions leaving the state are valid for traversal. Only transitions that have either no guard or a guard expression evaluating to true will be valid for traversal. Transitions with triggers that are still awaiting triggering events are not valid for traversal. Once Behavior Execution Engine chooses a valid state transition, it will then terminate all other transitions leaving that state.

Non-State Transitions

Non-state transitions refer to transitions that have actions, rather than states, as their source features. Unlike state transitions, these transitions do not have triggers. They are effectively "conditional successions" that check a boolean expression to guard whether the underlying succession is valid at the end of the source action. If there are more than one such transition, only the transitions with guards evaluating to true will occur after the end of the source action unless the source action is a "decision action". In which case, Behavior Execution Engine will select up to one of those transitions at random that has a guard evaluating to true. Otherwise, for source actions not representing decisions, the successions will occur in parallel. See also Forks.

Flows

You can define flows to transfer information from one occurrence to another, depending on the type of flow.

Succession Flow

You can use a succession flow to capture the value of the sourceOutput at the end of a source occurrence to transfer to the targetInput of the target occurrence. The payload then flows from the source feature to the target feature before starting the target occurrence.

Defining a succession flow between two actions will naturally create a succession between them, only with the added functionality of transferring a payload to the target.

Streaming Flow

Streaming flows enable you to exchange information between two occurrences that execute concurrently. Streaming flows start transferring payload information after both the source and the target occurrences start executing. Conversely, streaming flows cease streaming when either the source or the target reach the end of their execution. Therefore, streaming flows only stream information during the overlap of the execution lifetimes of the source and target occurrences. Reading the value of the flow's target feature outside this window of simulation time will cause a critical error and stop the simulation.

If your model intends to read the value of a flow-receiving feature, you can ensure the flow is active when Behavior Execution Engine reaches that logic by strategically inserting accept actions. For example, inserting accept actions into the source and target occurrences of the flow that trigger at the same simulation time ensures that their execution lifetimes will overlap, and a flow will stream. You must additionally model accept actions that trigger after the flow target reading to ensure the execution lifetimes of the flow source and target occurrences overlap at the exact moment the read occurs.

Items and Parts

While items, parts, and other SysML v2 objects do not appear in the execution trace log during simulation, Behavior Execution Engine will create them as it would any other occurrence at runtime. Therefore, Behavior Execution Engine will also execute any subOccurrences owned by these objects.

Units

Behavior Execution Engine enables you to use any units available for use in the System Architecture Modeler, while also supporting any custom-defined units you may define in a model library. Listed below are a few examples of creating custom units in a textual model that you can import as a model library:

When using custom units to create a ScalarQuantityValue attribute, you must ensure to type the attribute by a matching ScalarQuantityValue with a matching Dimension. Also, since creating a custom unit inherently involves using existing units as building blocks, you'll likely need to import the "SI" and "MeasurementReferences" packages.

To create a custom unit successfully, please ensure that the custom units you create have MeasurementReferences::MeasurementUnit as a supertype.

It is important to bear in mind that operations involving one or more ScalarQuantityValues may imply a conversion of one of the ScalarQuantityValue operands to the unit type of the other. As a rule of thumb, when two ScalarQuantityValues with comparable units must be converted to the same unit type to operate correctly, Behavior Execution Engine will convert the ScalarQuantityValue to the right side of the operator to conform to the units of the ScalarQuantityValue on the left side of the operator.

Creating a Custom Unit from an Operation (Textual)

attribute speedByOperation: MeasurementUnit := meter / second;

Creating a Custom Unit from a ConversionByPrefix (Textual)

attribute kilogramByPrefix : DerivedUnit {
    :>> unitConversion: ConversionByPrefix [1] {
        :>> prefix = kilo;
        :>> referenceUnit = gram;
    }
}

Creating a Custom Unit from a ConversionByConvention (Textual)

attribute gramByConvention : DerivedUnit {
    :>> unitConversion: ConversionByConvention [1] {
        :>> referenceUnit = kilogram;
        :>> conversionFactor = 1.0e-3;
    }
}