6.1 Activity Diagram Anatomy & Control Nodes

6.1 Activity Diagram Anatomy & Control Nodes

Quick Reference: SysML Activity Diagrams (act) capture system behavior as a network of actions connected by control flows and object flows. The execution model is governed by token flow semantics: discrete control tokens traverse directed paths to trigger action executions. When modeling termination, modelers must distinguish between an Activity Final Node (bullseye: halts the entire activity immediately and destroys all active tokens) and a Flow Final Node (circle with an 'X': halts only the arriving branch while leaving concurrent flows active).

---

Purpose and Scope of Activity Diagrams

Within the SysML behavioral pillar, the Activity Diagram (act) is the primary view used to model operational workflows, business processes, computational algorithms, and continuous system dynamics. While State Machine Diagrams model event-driven reactive state changes of a structural block, and Sequence Diagrams depict chronological message exchanges between lifelines, Activity Diagrams emphasize the procedural transformation of inputs into outputs and the ordering of executable steps.

In systems engineering, Activity Diagrams serve several critical functions:

• Functional Decomposition: Breaking down top-level system use cases into discrete, verifiable actions.
• Interface Definition: Exposing the exact data, physical items, and energy flows exchanged between operations.
• Concurrency and Synchronization: Modeling concurrent processing threads (e.g., simultaneous sensor polling and telemetry transmission) and synchronizing their execution baselines.
• Allocation to Architecture: Allocating individual actions to structural blocks or subsystems via «allocate» activity partitions (swimlanes), directly linking behavioral models to physical architecture.

---

Diagram Frame Syntax and Header Conventions

Like all SysML diagrams, an Activity Diagram must be enclosed within an outer rectangular boundary frame with a standardized header in the upper-left corner:

act [Activity] ActivityName [diagramName]

Header Field Breakdown

1. act (Diagram Kind): The mandatory lowercase three-letter mnemonic designating an Activity Diagram.
2. [Activity] (Context Metaclass): Enclosed in square brackets. In standard SysML, the enclosing classifier of an activity diagram is always an Activity.
3. ActivityName (Context Element Name): The simple name of the Activity classifier defined in the model repository whose internal execution flow is rendered in the diagram canvas.
4. [diagramName] (Optional View Title): An optional descriptive title enclosed in square brackets clarifying the view's specific operational context (e.g., [Nominal Flight Ignition Workflow]).

+-----------------------------------------------------------------------------------+
| act [Activity] DeploySolarArrays [Nominal Sequence]                               |
|                                                                                   |
|   ( * ) ----> [ Verify Orbit ] ----> [ Unlatch Arrays ] ----> ( O )              |
|                                                                                   |
+-----------------------------------------------------------------------------------+

---

Fundamental Execution Model: Token Flow Semantics

SysML activity execution is formally defined using token flow semantics, an execution model rooted in Petri nets. Understanding tokens is essential for interpreting SysML activity behavior on certification assessments:

• Tokens: Virtual markers that traverse edges between nodes. There are two distinct types of tokens:
  1. Control Tokens: Pure indicators of execution permission. They carry no data values and represent only the flow of control.
  2. Object Tokens: Packets that encapsulate data values, physical material, electrical energy, or signals traversing object flows.
• Token Offering and Acceptance: A node that finishes its processing offers tokens to its outgoing edges. An edge transfers the offered token to its downstream target node. However, a target node cannot accept the token until all of its own activation criteria are satisfied.
• Action Execution: An action is an executable node representing a fundamental unit of behavioral execution. In graphical notation, an action is rendered as a rectangle with rounded corners. When an action receives the required control and object tokens, it activates (fires), performs its specified computation or physical function, consumes the incoming tokens, and offers new tokens on its outgoing edges upon completion.

---

Control Flow Edges

A Control Flow is an edge that coordinates the sequencing of actions without transferring data.

• Graphical Notation: A solid line with an open (stick) arrowhead (--->). SysML 1.2 adds a presentation option: control flow "may be notated with a dashed line and stick arrowhead," which helps distinguish it from object flow.
• Semantics: Connects an upstream action or control node to a downstream action or control node. A control flow carries solely control tokens. When an upstream action finishes execution, it offers a control token across the control flow edge. Once the downstream action accepts that control token (and any required input object tokens), the downstream action starts.
• Implicit Concurrency: If an action has multiple outgoing control flows without an intervening decision or fork node, SysML specifies that a control token is offered along each outgoing edge concurrently, initiating parallel paths.

---

Control Nodes: Initial, Activity Final, and Flow Final

Control nodes are abstract nodes in an activity diagram used to manage the routing, initiation, and termination of tokens along flows. SysML defines three fundamental boundary control nodes:

1. Initial Node

• Graphical Notation: A solid filled black circle (●).
• Initiation Semantics: When the enclosing activity is invoked, each Initial Node immediately generates a control token and offers it along its outgoing edge to start execution.
• Structural Rule: An Initial Node can have zero incoming edges and one or more outgoing edges.
• Loopback Restriction: You can never route a control flow back into an Initial Node to form a loop. In SysML, looping control flows must connect to an explicit Merge Node.
• Multiple Initial Nodes: An activity can have multiple Initial Nodes. If an activity contains two or more Initial Nodes, all of them generate control tokens concurrently when the activity begins, launching multiple concurrent threads of execution.

2. Activity Final Node

• Graphical Notation: A solid black circle enclosed within a hollow outer concentric circle, commonly described as a bullseye (⦿).
• Global Termination Semantics: When a control or object token reaches an Activity Final Node, the entire activity terminates immediately.
• Catastrophic Token Destruction: The arrival of a token at an Activity Final node does not simply stop that single path. It destroys all active tokens across all concurrent branches within the activity instance. Any actions currently executing in parallel threads are abruptly aborted, any tokens waiting in buffers or queues are eradicated, and the activity completes immediately.

3. Flow Final Node

• Graphical Notation: A hollow circle enclosing an 'X' (⊗).
• Local Path Termination Semantics: A Flow Final Node terminates only the specific flow that enters it.
• Token Consumption: When a token reaches a Flow Final Node, the node destroys that specific arriving token and ends that individual branch of execution.
• Non-Interference with Concurrency: Crucially, a Flow Final Node has zero effect on other concurrent branches running elsewhere in the same activity. All other parallel flows continue to execute normally until they reach their own final nodes or completion criteria.

---

Activity Final vs. Flow Final: Detailed Scenarios & Exam Pitfalls

The behavioral distinction between ActivityFinal and FlowFinal is one of the most frequently tested concepts in SysML modeling. Consider two concrete engineering scenarios:

Scenario A: Redundant Sensor Processing (Flow Final Required)

A spacecraft guidance activity initiates two concurrent branches: Process Primary IMU and Process Backup IMU. If the primary IMU completes successfully, the backup IMU calculation is no longer needed.

• If the backup branch terminates into a Flow Final Node (⊗), only the backup calculation thread is ended. The primary thread proceeds unimpeded to steer the vehicle.
• If the backup branch was mistakenly connected to an Activity Final Node (⦿), the moment the backup calculation reached that node, it would instantly terminate the entire guidance activity, killing the primary steering action mid-execution and leaving the spacecraft unguided.

Scenario B: Emergency Fault Shutdown (Activity Final Required)

A nuclear reactor power management activity contains twelve parallel monitoring and regulation loops. One branch continuously checks cooling loop pressure via Verify Core Pressure. If pressure exceeds a critical threshold, the flow enters a fault-handling action Initiate Emergency SCRAM followed by an Activity Final Node (⦿).

• Reaching the Activity Final node is mandatory here: it terminates all other eleven operational loops immediately, ensuring no routine regulation commands are dispatched while the reactor is shutting down.

---

Control Node Summary Table

---

Exam Pitfalls & Misconceptions