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.

Simulation Events

States are inherently event oriented since transitions depend on events to determine when to proceed from one state to another. When executing states, Behavior Execution Engine checks which transitions have triggers observing events that determine the time when a source state might exit. This allows Behavior Execution Engine to advance simulation time forward precisely from event to event instead of having to advance the simulation in explicit time steps. This means you can model behavior without having to worry about inaccuracies introduced by numerical computation. In particular, using precise moments in continuous time allows for more natural and accurate use of change triggers. Behavior Execution Engine also enables you to delegate the detection of threshold satisfaction intervals to analysis tools like the Ansys Systems Tool Kit^® (STK^®) application. This means you can let the analysis tools handle event detection based on the broader environment or context of your system (e.g., gravity, relative location, etc.) while you focus on modeling the behavior of your system.

Behavior Execution Engine supports the following triggers:

Relative time triggers - Fire an event when the simulation time reaches the event's specified relative time.
Absolute time triggers - Fire an event when the simulation time reaches the event's specified absolute time.
Change triggers - Fire an event whenever its boolean expression changes from false to true.
Accept triggers (triggered by an incoming message) are not yet supported.

Relative time triggers

A relative time trigger fires its event after waiting a specific amount of time. Behavior Execution Engine requires relative time triggers' expression to evaluate to a ISQBase::TimeDuration, which is measured from the time that the source state was entered or the preceding non-state action ends. For instance, specifying a ScalarQuantityValues using units of [SI::s] to denote seconds enables modeling simple delays.

Absolute time triggers

An absolute time trigger fires an event when the simulation time reaches the trigger's specified absolute time. Behavior Execution Engine requires absolute time triggers' expressions to evaluate to a Time::Iso8601DateTime. While the specification allows Time::TimeInstantValue, there are still open questions around the time and clock system in the language. Behavior Execution Engine requires an explicit ISO-8601 date to avoid ambiguity regarding the reference epoch. Behavior Execution Engine enables you to specify absolute time values as attributes defined by Iso8601DateTime that have the val property redefined to an ISO-8601 formatted string.

Specifying Absolute Time Example:

attribute myAbsoluteTime : Time::Iso8601DateTime[1] {
    :>> val = "2000-01-01T00:00:00Z";
}
                            

Change triggers

A change trigger fires an event whenever its boolean expression changes from false to true. Change triggers are especially useful for detecting when a physical value meets a threshold. Behavior Execution Engine requires change trigger expressions to be specified as boolean expressions (evaluating to ScalarValues::Boolean).

For more information about how to take advantage of the power of change events, see Delegating for a scalar threshold comparison.