8.3 Event Types & Run-to-Completion Semantics

8.3 Event Types & Run-to-Completion Semantics

Quick Reference: SysML classifies operational stimuli into four primary event kinds: Signal Events (asynchronous data packets), Call Events (synchronous operation calls), Time Events (after(duration) or at(time)), and Change Events (when(condition) on the rising edge). Under Run-to-Completion (RTC) semantics, an event is dequeued and completely processed to a stable state configuration before the next event is handled. Events that cannot be processed in the current state are discarded unless marked with the defer keyword.

---

Events versus Triggers in SysML

Before exploring event categories, it is vital to distinguish between an Event and a Trigger in SysML:

• Event: A notable occurrence in time and space that has significance for the system (e.g., an optical sensor detecting a barcode, an internal clock tick reaching 50 milliseconds, or a user depressing a physical button). An event occurs independently of whether any state machine is currently listening for it.
• Trigger: A state machine modeling element that references an event and binds it to a transition. The trigger acts as the "listener" or receptor on a transition path that checks whether a dispatched event matches its specification.

---

The Four Primary Event Kinds

SysML defines four core event types capable of triggering state transitions:

---

Deep-Dive into Event Syntax and Semantics

1. Signal Events

A Signal is a classifier representing an asynchronous communication package containing data attributes. When an entity sends a signal (e.g., via a SendSignalAction in an Activity Diagram), the signal is transmitted to the target entity's event pool.

• Syntax: SignalName or SignalName(param1, param2)
• Example: TelemetryPacket(packetID = 104, payloadSize = 256)
• Because signal communication is asynchronous, the sender immediately continues its own execution without waiting for the recipient to receive or process the signal.

2. Call Events

A Call Event represents a request to invoke an operation declared on the context Block. Unlike a signal, a call event is inherently synchronous.

• Syntax: OperationName or OperationName(arg1, arg2)
• Example: reboot(mode = Force)
• The caller initiates the operation call and halts execution (blocks) until the receiving state machine completes the transition or executes the operation behavior and returns control.

3. Time Events: Relative (after) versus Absolute (at)

Time events model temporal triggers without requiring explicit software timer objects.

• Relative Time Events (after):

  • Measures elapsed time starting from the exact instant the source state was entered.
  • Syntax: after(<duration>) where <duration> specifies an engineering time unit (e.g., after(50 ms), after(10 s), after(2 h)).
  • The Reset Invariant: If the source state is exited and subsequently re-entered, the relative timer is completely reset to zero! Time does not accumulate across separate visits.

• Absolute Time Events (at):

  • Measures against an absolute point in time.
  • Syntax: at(<point-in-time>) (e.g., at(2026-10-01 12:00:00 UTC), at(24:00)).
  • Commonly utilized for mission schedules, satellite eclipse entries, or automated overnight batch jobs.

4. Change Events: when(condition)

A Change Event occurs when a boolean expression transitions from false to true.

• Syntax: when(<boolean-expression>)
• Example: when(tankLevel > 95 [%]), when(cabinPressure < 70 [kPa])

Critical Exam Distinction: Change Event versus Guard Condition

Candidates frequently confuse a Change Event (when(...)) with a Guard Condition ([...]):

Transition A:   when(temperature > 100) / activateFan()
Transition B:   SensorPoll [temperature > 100] / activateFan()

• In Transition A (Change Event), the condition when(temperature > 100) is the trigger itself. The moment temperature crosses the threshold from ≤ 100 to > 100 (the rising edge), the event occurs autonomously and fires the transition. No external event is needed.
• In Transition B (Guard), the condition [temperature > 100] is NOT a trigger. It is a passive gatekeeper. The transition will only evaluate when the distinct trigger event SensorPoll arrives. If temperature reaches 200 degrees but no SensorPoll event occurs, Transition B never fires!
• Rising Edge Semantics: A Change Event fires only once upon transitioning from false to true. If the condition remains true continuously, the change event does not repeatedly fire. The condition must return to false and then become true again to generate a new change event.

---

Completion Events

A Completion Event is an implicit internal event generated automatically by the state machine when an active state finishes all internal processing:

1. In a simple state, when the internal do / <behavior> completes.
2. In a composite state, when all internal orthogonal regions reach their respective Final States.

Completion events enable anonymous transitions (transitions without explicit trigger labels). If multiple anonymous transitions depart a state, their guards determine which branch fires.

---

The Run-to-Completion (RTC) Execution Model

The fundamental semantic foundation of all SysML state machines is the Run-to-Completion (RTC) processing model. RTC ensures deterministic, race-free state transitions.

+---------------------------------------------------------------+
|                     Event Pool (FIFO Queue)                   |
|  [ Event 3 ] ---> [ Event 2 ] ---> [ Event 1 (Next) ]         |
+---------------------------------------------------------------+
                               | (Dequeue Event 1)
                               v
+---------------------------------------------------------------+
|                    Run-to-Completion Step                     |
|                                                               |
|  1. Match Triggers in Active State Configuration             |
|  2. Evaluate Guards [guard == true]                           |
|  3. Abort source 'do' activity                                |
|  4. Execute source 'exit' behavior                            |
|  5. Execute transition 'effect'                               |
|  6. Execute target 'entry' behavior                           |
|  7. Reach Stable Target State Configuration                   |
+---------------------------------------------------------------+
                               | (RTC Step Complete)
                               v
                   Ready for Next Dequeued Event

The RTC Processing Lifecycle

1. Event Pool Ingestion: Events arriving from external blocks, signals, timers, or operations are placed into the context Block's Event Pool (a message queue). UML leaves the dequeuing order as a semantic variation point, so first-in-first-out is a common implementation choice rather than a language rule.
2. Dispatch: The state machine dequeues a single event from the pool.
3. Evaluation: The state machine inspects all transitions departing the currently active state configuration to find triggers matching the dispatched event whose guards evaluate to true.
4. Execution: The enabled transition fires. Source exit behaviors, transition effects, and target entry behaviors execute in strict order.
5. Stable Configuration: Execution proceeds until a stable state configuration is reached (a set of true states with no enabled triggerless transitions).
6. Step Finalization: Only after the stable configuration is fully established does the current RTC step complete. The state machine is now ready to dequeue the next event from the event pool.

Invariant of the RTC Step

During an active Run-to-Completion step, no other event from the pool can be processed. The execution of transition effects, exit behaviors, and entry behaviors is strictly atomic and non-preemptive with respect to external events.

However, note the critical distinction regarding do activities: ongoing do activities execute outside the atomic RTC step. An incoming event can interrupt a do activity, initiating a new RTC step.

---

Deferred Events: The defer Keyword

In standard state machine execution, if an event is dispatched but the current active state has no transition matching that event (or all guards evaluate to false), the event is silently consumed and discarded.

However, in real-world systems, an event may arrive when the system is temporarily unable to handle it, but discarding the event would cause data loss or system failure (e.g., a CalibratePayloadCmd arriving while the system is still in InitializingHardware).

Semantics of defer

SysML provides the defer reserved keyword to handle this scenario. A deferred event is specified in the internal behaviors compartment of a state:

+---------------------------------------+
|         InitializingHardware          |
+---------------------------------------+
| entry / runSelfTests()                |
| do / loadFirmware()                   |
| exit / enableBuses()                  |
+---------------------------------------+
| CalibratePayloadCmd / defer           |
| DataUploadReq / defer                 |
+---------------------------------------+

• Holding Mechanism: When CalibratePayloadCmd arrives while in InitializingHardware, the state machine recognizes the defer directive. Instead of discarding the event, the event is retained in the event pool.
• Deferred Recall: When the state machine subsequently transitions into a new state (e.g., Operational) that does not defer CalibratePayloadCmd and has an enabled transition matching it, the deferred event is immediately dispatched and processed.

---

Conflict Resolution and Transition Priority

When an event is dispatched, multiple transitions might theoretically be enabled simultaneously, creating potential conflicts.

1. Hierarchical Priority (Innermost Wins)

If a composite state and one of its nested sub-states both define transitions triggered by the exact same event, the innermost (most deeply nested) transition takes precedence over the outer transition.

• Rationale: The nested sub-state represents a more specialized operational context; its local response overrides the generalized response of the parent composite state.

2. Sibling Conflicts and Non-Determinism

If two transitions originating from the exact same state specify the same trigger and both guards evaluate to true, the SysML specification defines the behavior as non-deterministic. The model does not specify which transition fires. In safety-critical systems engineering, non-deterministic guards are considered a severe design flaw that must be eliminated with mutually exclusive guard conditions (e.g., [speed < 50] vs. [speed >= 50]).

---

Exam Pitfalls & Misconceptions