This section provides guidelines for modeling states to ensure correct execution during simulation.

A state defines the dynamic behavior of a system by specifying the states, transitions, and actions that occur in response to events or conditions. When modeling states for simulation, it is essential to structure the model so that the simulation engine can correctly evaluate:

  • State activation - which states are currently active
  • Transition triggers - events or conditions that cause state changes
  • Guard conditions - logical rules that enable or block transitions
  • Behavioral actions - activities performed within states or during transitions
  • Payload (signal) communication - how data or events are passed between elements

The following sections describe the key modeling elements required to create executable states and ensure accurate simulation results.

Initial state

An initial state represents the starting point of a state. It defines which state becomes active when execution begins.

An initial state does not represent an actual system condition. Instead, it is used to determine the first active state when the simulation starts.

The initial state is determined by either:

  • the start node, or
  • a state with no incoming transitions

If multiple states satisfy this condition, the simulation engine selects the first one based on model order.

Example

exhibit state Operating_STM {

        state Off;
        state Starting;
        state Running;

        transition first start then Off;
        transition first Off then Starting;
        transition first Starting then Running;
    }

In the above example, the simulation starts at start, the transition leads to Off, and Off becomes the first active state.

Entry, do, and exit actions

States can define behaviors that are executed during different phases of state activation.

Entry, do, and exit actions allow the model to describe:

  • Entry - initialization logic executed when entering a state.
  • Do - behavior executed while the state remains active.
  • Exit - cleanup or signaling executed when leaving a state
Example

state Off {
   entry {
      assign level := 1;
   }
   do {
      send new StatusUpdate()
   }
   exit {
      send new Stop()
   }
}

Simulation behavior in the example above:

  1. When Off becomes active, the entry action runs.
  2. While Off is active, the do action runs.
  3. When leaving Off, the exit action runs.

Only the following action types are currently supported:

  • Assignment action
  • Send action
  • Composite actions (multiple actions executed sequentially)
    Example

    entry {
       level := 1
       send new Start()
    }

Sending payloads using the send action

Payloads (signals) can be sent using the send action. Several optional parameters may be defined when sending a payload.

Sending a payload without attributes, a sender, or receiver

A payload can be sent without specifying attributes, sender, or receiver. In this case, the payload is sent to the state itself. If the item definition includes attributes with default values, these defaults are included in the payload when it is sent.

Example

item def Start;

state Off{
            entry send new Start();
        }

Sending a payload with attributes

Payloads may contain attributes. Attribute values can be provided when sending the payload.

Limitation

Attributes can only be defined for primitive and enumeration types.
Example

item def DataSignal
{ attribute reading : Real;
attribute isUrgent : Boolean
}

state Off{
        entry send new DataSignal(reading = 150, isUrgent = false);
}

Sending a payload via the sender

A payload can be sent through a port usage (sender). If multiple Connections or interface usages exist, the payload is delivered to all connected receivers, unless a specific receiver is defined.

Example

Item def Start;

state Off{
        entry send new Start() via buttonPort;
}

Sending a payload to the receiver

A payload can be sent to a part usage (receiver).

Example

Item def Start;

state Off{
        entry send new Start() to Button;
}

Sending a payload via the sender to the receiver

A payload can also be sent via a port usage (sender) to a part usage (receiver). In this scenario, the payload is transmitted from the specified sender port to the defined receiver part. This approach is useful when you want to limit delivery to specific receivers connected to that port.

Example

Item def Start;

state Off{
        entry send new Start() via buttonPort to Button;
}

Triggers on transitions

A trigger specifies the event that causes a transition to become eligible for execution. Without triggers, transitions would occur immediately whenever their source state is active. Triggers ensure transitions occur only when specific events happen.

A transition is executed when:

  • Its trigger occurs.
  • Any guard condition evaluates to true.

Types of supported triggers

Payload (signal) trigger

A payload trigger is triggered when a specific payload (signal) is received.

Examples:

transition first Off accept Start then Starting;

transition first Off accept Start via outPort then Starting;

The transition fires when the Start signal is received. If a port is defined, the payload will only be received if it arrives through the specified port.

Payloads can be defined using:

  • Item definition
  • Item usage

Change trigger

A change trigger is triggered when a Boolean expression changes from false to true, or when it evaluates to true during its first evaluation.

Example

transition first Idle accept when engine.temperature > 100 then Active;

The transition fires when the expression becomes true.

Time trigger

A time trigger is triggered based on the simulation time.

Two types of time triggers are supported:

  • Absolute time
    Example

    transition first Off accept at 5 [s] then Starting;

    The transition fires when the simulation time reaches 5 seconds.
  • Relative time
    Example

    transition first Off accept after 10 [s] then Starting;

    The transition fires when the simulation time reaches 10 seconds.
  • Expressions referencing model values are supported.
    Example

    transition first Off accept after targetTime [s] then Starting;

  • The simulation engine does not interpret time units. All time values are executed in seconds by default.

Using guards on transitions

A guard is a Boolean expression that must evaluate to true for a transition to occur. They add an additional condition that must be satisfied after the trigger is received. Therefore, guards allow modeling decision logic within a state.

Guards are commonly used to:

  • Check system parameters
  • Filter incoming events
  • Ensure transitions occur only in valid conditions

Without guards, transitions would be triggered whenever their events occur.

Example

transition first Off accept Start if level > 1 then Starting;

Simulation behavior in the example above:

  1. A Start signal is received.
  2. The guard level > 1 is evaluated.
  3. The transition executes only if the guard evaluates to true.

Using effects on transitions

A transition effect is an action that is executed when a transition occurs. Effects define behavior that happens during the transition between two states.

Effects allow the model to perform operations that logically belong to the transition itself, such as:

  • Sending payloads
  • Updating variables

This helps separate the state behavior from the transition behavior.

Execution order

When a transition occurs, execution proceeds in the following order:

  1. Exit action of the source state
  2. Transition effect
  3. Entry action of the target state
Example

transition first Off accept Start do send new Start() then Starting;

Simulation behavior in the above example:

  1. The exit action of Off executes.
  2. The transition effect sends Start.
  3. The entry action of Starting executes.
Effects may include multiple actions. These actions are executed in the order defined.
Example

transition first Off accept Start do
  send new Start();
  assign level;
then Starting;