7.2 Action Types: Call Behavior, Send Signal & Accept Event

7.2 Action Types: Call Behavior, Send Signal & Accept Event

Quick Reference: While basic actions represent primitive operations, SysML defines specialized action geometries for modular execution and communication. A Call Behavior Action (rounded rectangle with a rake symbol Ψ) invokes an activity defined elsewhere for functional decomposition. A Send Signal Action (a convex pentagon with a pointed right edge) asynchronously dispatches a signal without waiting. An Accept Event Action (a concave pentagon with a notched left edge) blocks execution until a specific trigger arrives. An Accept Time Event Action (an hourglass symbol) triggers based on elapsed relative duration after(duration) or absolute time at(time).

---

Overview of Action Specializations in SysML

In SysML Activity Diagrams, an Action is the fundamental non-decomposable unit of behavioral execution. In early design phases, modelers frequently use generic opaque actions (simple rounded rectangles) to describe high-level operational tasks. However, as system architecture matures toward rigorous execution, simulation, and software/hardware realization, engineers must specify the exact interaction mechanics: invocation, asynchronous signaling, event handling, and temporal deadlines.

SysML adapts and extends UML action semantics to provide specialized action metaclasses, each distinguished by a standardized visual geometry:

1. Call Behavior Action:      2. Send Signal Action:        3. Accept Event Action:       4. Accept Time Event Action:
   +-----------------------+     +-------------------+>        +<------------------+             +-----------------------+
   | ComputeTrajectory     |     | TransmitTelemetry |         | ReceiveAckSignal  |             |  ⧗ after(500 ms)      |
   |                   [Ψ] |     +-------------------+>        +<------------------+             +-----------------------+
   +-----------------------+     (Convex Pentagon)             (Concave Pentagon)                (Hourglass Time Event)
   (Rake Symbol at Corner)

---

Call Behavior Action: Hierarchical Functional Decomposition

A Call Behavior Action invokes a behavior—most commonly an Activity—defined elsewhere in the model repository.

Graphical Notation

• Shape: A standard rectangle with rounded corners.
• Icon Decorator: A small rake or fork symbol (Ψ) placed in the lower-right corner of the action box.
• Text Label: The action name or the invoked behavior's name. SysML 1.2 also allows the colon form action name : behavior name (e.g., selfTest : ExecuteSelfTest) and lets stereotypes of the invoked behavior appear on the action (e.g., «activity» NavigateToWaypoint).

Execution Semantics and Parameter Mapping

• Synchronous Execution: By default, when a control token arrives at a Call Behavior Action (and required input pin tokens are present), the action invokes an instance of the referenced Activity.
• Suspension and Completion: The Call Behavior Action remains active while the invoked sub-activity runs. Only when the invoked activity reaches an Activity Final node or emits all required outputs does the Call Behavior Action complete, offering an outgoing control token to downstream nodes.
• Pin-to-Parameter Binding:
  • Input pins on the Call Behavior Action map directly to the Activity Parameter Nodes on the input boundary of the called activity.
  • Output pins on the Call Behavior Action receive object tokens delivered by the Activity Parameter Nodes on the output boundary of the called activity.

The Rake Symbol Exam Trap

Exam Trap: On certification exams, a frequent distractor asserts that the rake symbol (Ψ) represents a fork node, multi-threading, or parallel processing. This is completely false. The rake symbol strictly designates that the action is a call to another behavior (hierarchical activity decomposition). Concurrency is modeled exclusively by thick solid black bars (Fork Nodes).

---

Send Signal Action: Asynchronous Message Transmission

A Send Signal Action creates a signal instance from its inputs and transmits it to an external target entity or system environment.

Graphical Notation

• Shape: A convex pentagon—rendered as a rectangle with a pointed triangular edge on the right side (>), pointing in the direction of outgoing token flow.
• Labeling: Displays the name of the Signal classifier being transmitted (e.g., Send IgnitionCommand or EmergencyShutdownSignal).

The Asynchronous Non-Blocking Rule

The defining characteristic of a Send Signal Action is its non-blocking execution:

Core Execution Rule: A Send Signal Action is always asynchronous and non-blocking — it never waits for a reply or acknowledgment.

1. Signal Dispatch: When an incoming control token arrives, the action instantiates the typed Signal, populates any payload attributes via attached input pins, and sends the signal instance to the target receiver.
2. Immediate Token Emission: The instant the signal is dispatched, the Send Signal Action completes immediately and emits an outgoing control token across its outgoing edge.
3. Decoupled Processing: It does not wait for the signal to reach the receiver, does not wait for the receiver to accept it, and does not wait for the receiver to perform any actions in response.

---

Accept Event Action: Blocking Event Reception

An Accept Event Action waits for the occurrence of a specified trigger event or the receipt of a matching signal instance.

Graphical Notation

• Shape: A concave pentagon—rendered as a rectangle with an indented or notched triangular edge on the left side (<|), resembling a socket ready to receive an incoming triangular signal arrow.
• Labeling: Displays the trigger event or Signal name it is waiting to receive (e.g., Accept Acknowledgment or Trigger AbortSignal).

Blocking Wait Semantics

In direct contrast to Send Signal, an Accept Event Action is fundamentally blocking:

Core Waiting Rule: An Accept Event Action is blocking and reactive — it halts execution indefinitely until a matching trigger event occurs.

1. Enabling the Action: When an incoming control token arrives at an Accept Event Action, the action becomes enabled and enters a waiting state.
2. Indefinite Hold: Execution along that branch is suspended. The action holds the incoming token and will not emit any outgoing tokens until the qualifying event or signal arrives.
3. Event Consumption: When a matching signal is delivered to the enclosing classifier context, the Accept Event Action consumes the event, populates its output pins with the signal's payload attributes, completes execution, and offers a control token to its outgoing edge.
4. Deadlock Hazard: If the expected event never occurs, the action waits indefinitely, halting all downstream execution on that flow.

Unsolicited vs. Solicited Events

• Solicited Event: An Accept Event Action placed downstream of an upstream Send Signal Action (e.g., Send Request to Accept Response).
• Unsolicited Event: An Accept Event Action placed with no incoming control flows. When the activity begins, the action is automatically enabled at activity startup, waiting continuously in the background to handle asynchronous interruptions, user inputs, or emergency signals.

---

Accept Time Event Action: Hourglass Symbol & Temporal Triggers

An Accept Time Event Action is a specialized variant of an Accept Event Action that responds to temporal events generated by the passage of time.

Graphical Notation

• Shape: A stylized hourglass symbol (⧗) (two opposing triangles meeting at a vertex).

Relative vs. Absolute Time Syntax

UML, whose actions and events SysML 1.2 reuses, defines two time expressions:

1. Relative Time Trigger (after(duration)):
   • Syntax: after(expression)
   • Example: after(5 s), after(250 ms), after(3 hours)
   • Semantics: The timer begins measuring elapsed duration the exact instant the control token arrives at the hourglass node. When the specified duration expires, the action triggers and offers an outgoing control token.
2. Absolute Time Trigger (at(time)):
   • Syntax: at(expression)
   • Example: at(00:00:00 UTC), at(LiftoffTime + 120 s)
   • Semantics: The action evaluates against the system clock and fires when the clock reaches the specified absolute temporal threshold.

---

Architectural Pattern: Asynchronous Handshake with Timeout

In aerospace, defense, and automotive systems, combining Send Signal, Accept Event, and Accept Time Event actions is a common pattern for modeling a request with a timeout:

 [ Send PingCommand ]>        (send signal: dispatches, completes at once)
          |
          v
   ===== Fork =====
     |          |
     v          v
>[ Accept PingAck ]      [ ⧗ after(500 ms) ]
     |                        |
     v                        v
[ Process Response ]     [ Raise Timeout Fault ]
     |                        |
     v                        v
   ( ◉ ) Activity Final     ( ◉ ) Activity Final

Execution Walkthrough

1. Send First: Send PingCommand dispatches the ping and completes immediately; it never waits for a reply.
2. Fork Two Waits: A fork then enables two concurrent waiting actions: Accept PingAck and the time event after(500 ms), whose timer starts when that action is enabled.
3. Race Resolution: Each branch ends at its own Activity Final node. If the acknowledgment arrives first, the nominal branch reaches its final node and terminates the whole activity, cancelling the still-waiting timer. If 500 ms pass first, the timeout branch reaches its final node and terminates the activity, cancelling the still-waiting accept.
4. Why Not a Join? A join waits for a token on every incoming edge. Joining the two branches would make the activity wait the full 500 ms even after a fast reply, and it would wait forever if the reply never came.

---

Specialized Action Types Comparison Table

---

Exam Pitfalls & Misconceptions