7.1 Activity Partitions (Swimlanes) & Structural Allocation

7.1 Activity Partitions (Swimlanes) & Structural Allocation

Quick Reference: In SysML Activity Diagrams (act), Activity Partitions (popularly known as swimlanes) visually assign behavioral actions to the structural elements responsible for executing them. A plain partition follows UML semantics: the element it represents is responsible for performing the actions inside it. A partition whose label carries the keyword «allocate» is a SysML AllocateActivityPartition: each action inside it is the client of an «allocate» dependency whose supplier is the partition's element. Control flows and object flows that cross partition boundaries represent structural interfaces (connectors and item flows) between system components.

---

Purpose and Concept of Activity Partitions

In systems engineering, behavior and structure represent two complementary pillars of architecture. Behavior defines what the system does (the sequence of functional transformations, inputs, and outputs), while structure defines what performs that behavior (the hardware, software, human operators, and physical enclosures).

While an unpartitioned Activity Diagram models pure procedural logic, real-world systems engineering requires assigning functional steps to specific architectural assets. SysML fulfills this requirement through Activity Partitions:

• Responsibility and Allocation: Partitions associate actions with the structural entities that perform them. «allocate» partitions go further and record formal allocations, bridging activity models and block models (Block Definition Diagrams and Internal Block Diagrams).
• Responsibility Demarcation: In multidisciplinary teams, partitions clarify organizational, hardware, or software boundaries, identifying which subsystem or vendor is responsible for each operational step.
• Interface Discovery: Tracking tokens as they traverse across partition boundaries allows systems engineers to systematically identify, verify, and specify all inter-subsystem communication interfaces and physical connectors.

---

Visual Notation and Layout Schemes

Activity partitions are drawn as parallel lanes bounded by solid lines dividing the activity diagram canvas. SysML provides three standard spatial arrangements:

1. Vertical Partitions (Columns)

• Partitions are drawn as vertical columns spanning the top-to-bottom height of the diagram canvas.
• The partition label appears in a distinct header compartment at the top of each column.
• Best suited for processes where temporal sequencing primarily moves vertically from top to bottom.

2. Horizontal Partitions (Rows)

• Partitions are drawn as horizontal lanes spanning the left-to-right width of the diagram canvas.
• The partition label appears in a header compartment at the far left of each row.
• Best suited for timeline-oriented workflows and control architectures where causality flows from left to right.

3. Two-Dimensional (Multidimensional) Grids

• SysML explicitly permits partitioning along two or more orthogonal dimensions simultaneously, forming a 2D matrix or grid of cells.
• Example: Columns represent Structural Subsystems (:NavigationComputer, :PropulsionUnit, :GroundStation), while horizontal rows represent Operational Locations / Flight Phases (PreLaunch, AtmosphericAscent, OrbitInsertion).
• An action placed in cell (PropulsionUnit, AtmosphericAscent) lies in both partitions at once: the propulsion subsystem's lane and the ascent phase's lane. It is an allocation only if those partitions are marked «allocate».

+-----------------------------------------------------------------------------------+
| act [Activity] VehicleGuidanceWorkflow                                            |
|                                                                                   |
|  +--------------------+---------------------+----------------------------------+  |
|  | :SensorSubsystem   | :GuidanceController | :ThrustVectorActuator            |  |
|  +--------------------+---------------------+----------------------------------+  |
|  |                    |                     |                                  |  |
|  |  ( * )             |                     |                                  |  |
|  |    |               |                     |                                  |  |
|  |    v               |                     |                                  |  |
|  |  [ Acquire Gyro ]  |                     |                                  |  |
|  |        |           |                     |                                  |  |
|  |        +-----------------> [ Calculate ] |                                  |  |
|  |     (Crossing)     |       [ Trajectory] |                                  |  |
|  |                    |             |       |                                  |  |
|  |                    |             +------------------> [ Gimbal Nozzle ]     |  |
|  |                    |                  (Crossing)              |             |  |
|  |                    |                     |                    v             |  |
|  |                    |                     |                  ( O )           |  |
|  +--------------------+---------------------+----------------------------------+  |
+-----------------------------------------------------------------------------------+

---

Partition Header Syntax and Classifier Representation

The label in an activity partition header defines the structural entity or classification dimension represented by that partition. SysML supports several header naming styles:

1. Classifier Alone (Block Typing):
   • Identifies the type of block responsible for the actions.
   • Syntax: BlockName (a simple name with no colon)
   • Example: RadarSensor or FlightControlComputer
2. Part Property / Structural Usage (Instance Role):
   • Identifies a specific part property within an enclosing block context.
   • Syntax: partName : BlockName or simply :BlockName (anonymous part)
   • Example: primaryGuidance : FlightComputer or :BrakeActuator
3. Actor / External Entity:
   • Identifies an external human user or interacting external system.
   • Syntax: «actor» Pilot or :GroundOperator
4. Organizational Unit or Organizational Role (user-defined stereotype):
   • Represents an engineering team, enterprise department, or service provider.
   • Example: «organization» FlightDynamicsTeam
5. Multidimensional Dimension Headers:
   • When using 2D grids, the outer header names the dimension (e.g., Subsystem) and each inner header names one element of it (e.g., :PowerSupply).

---

Plain Partitions vs. «allocate» Partitions

SysML 1.2 distinguishes two kinds of partition, and the MU100 coverage map names the second one ("allocate activity partitions") explicitly:

The specification states the rule directly: "An Action appearing in an 'AllocateActivityPartition' will be the /client (from) end of an 'allocate' dependency. The element that represents the 'AllocateActivityPartition' will be the /supplier (to) end of the same 'allocate' dependency." It adds that an allocate partition keeps the constraints, "but not the semantics," of a UML partition: the element it represents has no direct responsibility for invoking the behavior.

Core Rule: Look for the «allocate» keyword in the partition label before concluding that an action is allocated.

When an action sits in an «allocate» partition labeled :TelemetryTransceiver:

• Client (Allocated Element): The action.
• Supplier (Target Element): The element the partition represents. A label with a colon (part_name:Block_Name or :Block_Name) designates a property (a part); a simple name without a colon designates a classifier (a block).
• Repository Invariance: The allocation exists in the model, not merely on the drawing. It remains visible in allocation tables and in the derived allocatedTo / allocatedFrom properties.
• Allocated Compartments: On a BDD, the receiving block can show an allocatedFrom compartment listing what was allocated to it (e.g., «action» TransmitTelemetryPacket).

---

System Boundaries: Internal vs. External Partitions

Activity partitions provide a visual framework for delineating the System Under Consideration (SUC) from its operational environment:

• External Partitions: Represent external actors, environmental phenomena, or third-party external systems outside the design boundary of the SUC.
  • Actions placed within external partitions (e.g., Depress Accelerator Pedal inside the :Driver partition, or Generate Crosswind Gust inside :Atmosphere) represent external stimulations or operational inputs.
• Internal Partitions: Represent internal hardware components, software modules, or sub-blocks owned by the system.
  • Actions placed within internal partitions represent the internal functional decomposition of the system.
• Boundary Crossings: When an edge transitions from an external partition to an internal partition, it depicts an external system input across the system boundary. When an edge transitions from an internal partition to an external partition, it depicts an external system output.

---

Flows Crossing Partition Boundaries: Architectural Interfaces

In standard activity modeling, control flows and object flows are freely routed across partition boundaries. These boundary crossings are significant in architectural design:

1. Interface Identification: Every time a control flow or object flow crosses a partition boundary between Partition A (:SubsystemA) and Partition B (:SubsystemB), it indicates that Subsystem A must communicate with Subsystem B.
2. Mapping to Internal Block Diagrams (IBDs):
   • An object flow crossing a partition boundary directly justifies and maps to an Item Flow flowing across a Connector between structural Ports on an IBD.
   • If an activity diagram shows an object flow of attitudeQuaternion traversing from :InertialNavigation to :AttitudeController, the corresponding IBD must feature a connector linking those two parts, with matching ports typed to exchange attitudeQuaternion.
3. Interface Mismatches: If an activity diagram shows flows crossing between two partitions whose corresponding blocks have no physical or logical connection on the IBD, the systems model contains an architectural inconsistency that must be resolved.

---

Hierarchical (Nested) Partitions

Just as system structure is organized hierarchically through composite aggregation (blocks containing parts, which in turn contain sub-parts), SysML activity partitions can be nested hierarchically:

• Parent Partition: Represents a top-level subsystem (e.g., AvionicsBay).
• Child Partitions: Nested inside the parent partition to represent internal constituent parts (e.g., primaryFlightComputer : SBC and backupFlightComputer : SBC).
• Nesting Semantics: An action placed in a child partition lies within that child partition, which is itself nested in the parent. For «allocate» partitions, the supplier of the allocation is the element the child partition represents.

---

Real-World Engineering Example: Autonomous Emergency Braking (AEB)

Consider the operational workflow of an Autonomous Emergency Braking system modeled across three activity partitions:

1. Partition 1 (:PerceptionRadar):
   • Action Acquire Target Reflection outputs radar pulse returns.
   • Action Compute Target Distance & Rate processes the pulse data and outputs an object token obstacleData : ObstacleTrack.
2. Boundary Crossing 1 (:PerceptionRadar to :BrakingECU):
   • The object flow carrying obstacleData crosses the partition line from :PerceptionRadar into :BrakingECU.
   • Architectural Mapping: This crossing corresponds to a high-speed CAN or Ethernet connector between the radar sensor port and the braking controller input port.
3. Partition 2 (:BrakingECU):
   • Action Assess Time-To-Collision (TTC) evaluates collision hazard.
   • Decision node checks [TTC < 1.2 s].
   • Action Calculate Deceleration Pressure generates an object token brakeCmd : HydraulicCommand.
4. Boundary Crossing 2 (:BrakingECU to :HydraulicActuator):
   • The object flow carrying brakeCmd crosses from :BrakingECU into :HydraulicActuator.
   • Architectural Mapping: Corresponds to a hardwired PWM control line or hydraulic valve control interface.
5. Partition 3 (:HydraulicActuator):
   • Action Pressurize Brake Calipers physically modulates hydraulic line pressure.
   • Action Clamp Brake Discs brings the vehicle safely to a halt.

---

Partition Syntax & Allocation Summary Table

---

Exam Pitfalls & Misconceptions