8.2 Transitions, Trigger-Guard-Effect Syntax & State Behaviors

8.2 Transitions, Trigger-Guard-Effect Syntax & State Behaviors

Quick Reference: Transitions dictate how a system moves between states. The canonical transition string adheres to trigger [guard] / effect. Triggers are events that stimulate evaluation; guards are boolean expressions in square brackets [...] evaluated at dispatch time; and effects are atomic, non-interruptible actions executed during traversal. States possess internal behaviors: entry / (runs upon entry), exit / (runs upon exit), and do / (interruptible ongoing activity). An internal transition executes an effect inside the state without firing exit or entry behaviors.

---

Anatomy of a State Transition

A Transition is a directed relationship between a source state (or pseudostate) and a target state (or pseudostate). It signifies that when specific conditions are met, the system departs the source vertex and enters the target vertex, changing the active state configuration.

Graphically, a transition is rendered as a solid line with an open arrowhead pointing from the source vertex to the target vertex. The transition line is annotated with a text label adhering to a strict SysML/UML grammar.

---

The Canonical Transition Syntax: trigger [guard] / effect

The text string associated with a transition adheres to the formal OMG specification grammar:

trigger [guard] / effect

Each component governs a precise phase of transition traversal:

1. The Trigger (trigger)

• Specifies the event that stimulates the transition evaluation (e.g., EngineStartCmd, TimerExpired, SensorThresholdExceeded).
• Can include parameters passed by the event: CommandRcvd(commandID: Integer, param: Real).
• A transition can specify multiple triggers separated by commas: Trigger1, Trigger2 [guard] / effect. In this case, the occurrence of either event will trigger the transition evaluation.

2. The Guard ([guard])

• A boolean expression enclosed in square brackets [...] (e.g., [voltage >= 12.0 && fuelLevel > 15]).
• Evaluation Timing: Evaluated at the exact instant the trigger event is dispatched from the event pool. It is not a continuous polling monitor. If the guard evaluates to false, the transition cannot fire, and the event is consumed and discarded (unless another transition is enabled or the event is deferred).
• A guard must be side-effect free; evaluating the guard condition cannot modify system property values.

3. The Effect (/ effect)

• An optional behavioral action preceded by a forward slash (/).
• Specifies an atomic, non-interruptible behavior executed during transition traversal (e.g., / logModeChange(); setThrottle(50)).
• Can invoke operations, send signals, or assign values to structural block properties.

Optionality and Completion Transitions

All three components of the transition string are optional:

• No Trigger (Anonymous / Completion Transition): An unlabeled transition or a transition containing only [guard] / effect. It fires automatically as soon as the source state finishes all internal behaviors (its do activity completes or all nested regions reach final states), provided the guard evaluates to true.
• No Guard: If the guard is omitted, the transition fires unconditionally whenever the trigger event occurs.
• No Effect: If the effect is omitted, the state machine transitions from source to target without executing an action during the traversal.

---

State Body Internal Behaviors: entry, exit, and do

States in SysML are not passive labels; they specify internal behavioral lifecycles. Inside the internal behaviors compartment of a state, three standardized keywords specify execution timing:

+---------------------------------------+
|              Monitoring               |
+---------------------------------------+
| entry / initializeSensors()           |
| do / continuousPressureSampling()     |
| exit / archiveBuffer()                |
+---------------------------------------+

1. entry / <behavior>

• Executes immediately upon entering the state, directly after the incoming transition effect completes.
• Non-interruptible: Runs to completion. The state machine will not process any new events or initiate outgoing transitions until the entry behavior finishes.
• Used for initialization, asserting invariants, engaging hardware interlocks, or logging state arrival.

2. exit / <behavior>

• Executes immediately when departing the state via an external transition, before the transition effect executes.
• Non-interruptible: Runs to completion.
• Used for cleanup, releasing shared resources, saving volatile data, or disabling actuators.

3. do / <ongoing-behavior>

• Specifies an ongoing activity that commences execution only after the entry behavior has completed.
• Executes concurrently while the system resides in the state.
• Crucially Interruptible: Unlike entry and exit, a do behavior can be interrupted at any moment. If an external transition fires while the do activity is running, the do activity is aborted immediately prior to running the exit behavior.
• If the do behavior runs to normal completion without interruption, the state machine posts an internal completion event, which enables any outgoing anonymous completion transitions.

---

External Transitions versus Internal Transitions

A critical distinction on the OCSMP Model User exam is the difference between an External Transition, an External Self-Transition, and an Internal Transition.

Deep-Dive: Internal Transitions

An Internal Transition is written directly inside the text compartment of the state without any arrow departing the state boundary:

+---------------------------------------+
|              Operational              |
+---------------------------------------+
| entry / powerUpSubsystems()           |
| do / processWorkload()                |
| exit / powerDownSubsystems()          |
+---------------------------------------+
| PingQuery / sendHeartbeat()           |
+---------------------------------------+

When the PingQuery event occurs:

1. The transition effect sendHeartbeat() executes.
2. The system does NOT exit Operational.
3. The exit / powerDownSubsystems() behavior is NOT invoked.
4. The entry / powerUpSubsystems() behavior is NOT invoked.
5. The ongoing do / processWorkload() behavior is NOT interrupted.

If PingQuery had been drawn as an external self-transition (an arrow looping from Operational back to Operational), the system would have aborted processWorkload(), executed powerDownSubsystems(), executed sendHeartbeat(), executed powerUpSubsystems(), and restarted processWorkload(). Using internal transitions avoids this destructive cycling.

---

Strict Chronological Execution Ordering

When an external transition fires between two states, SysML defines a strictly deterministic, non-overlapping execution sequence:

Source Exit ────> Transition Effect ────> Target Entry

Comprehensive Worked Example

Consider a spacecraft propulsion controller transitioning from State A (Primed) to State B (Firing):

• State A (Primed):
  • entry / openFuelValve()
  • do / monitorPressure()
  • exit / closeFuelValve()
• Transition: IgnitionCmd [pressure > 50] / igniteThruster()
• State B (Firing):
  • entry / logBurnStart()
  • do / executeBurnProfile()
  • exit / logBurnComplete()

When the IgnitionCmd event is dispatched and the guard [pressure > 50] evaluates to true, the state machine executes the following chronological steps:

1. Abort Ongoing Behavior: The ongoing do / monitorPressure() activity in State A is immediately terminated.
2. Execute Source Exit: The exit / closeFuelValve() behavior of State A executes to completion.
3. Execute Transition Effect: The transition effect / igniteThruster() executes to completion.
4. Execute Target Entry: The entry / logBurnStart() behavior of State B executes to completion.
5. Initiate Target Do Activity: The ongoing do / executeBurnProfile() activity in State B begins running.

Exam Warning: Questions frequently test whether the transition effect executes before or after the source state's exit behavior. Always remember: Exit comes first! You must exit the source state before you can traverse the transition effect, and you must traverse the transition effect before you enter the target state.

---

Comparison: State Behaviors versus Transition Effects

---

Exam Pitfalls & Misconceptions