4.1 Enclosing Blocks & Part Usages

4.1 Enclosing Blocks & Part Usages

Quick Summary: In Systems Modeling Language (SysML), while the Block Definition Diagram (BDD) defines blocks as reusable classifiers in the abstract, the Internal Block Diagram (IBD) captures how those blocks are instantiated and interconnected inside a specific context. An IBD always describes the internal structure of exactly one enclosing block. Within that enclosing block, part usages (solid-outline rectangles) represent owned components with bound lifecycles, while reference usages (dashed-outline rectangles) represent external non-owned entities.

Model-Based Systems Engineering (MBSE) requires modeling both the dictionary of available types and the actual topologies of systems composed of those types. On a BDD, you declare that an Automobile possesses Wheel parts. On an IBD, you model how four individual Wheel part usages—such as frontLeft, frontRight, rearLeft, and rearRight—are connected to specific axle assemblies, braking controllers, and suspension struts. Understanding the distinction between definition and usage is the core foundation of structural modeling in SysML.

---

The Purpose and Value of Internal Block Diagrams

A Block Definition Diagram (BDD) specifies what blocks exist, their structural features, their inheritance hierarchies, and their general associations. However, a BDD does not depict how parts interconnect inside a specific subsystem.

The Internal Block Diagram (IBD) fills this critical need by providing an internal "white-box" view of a block classifier:

• Contextual Topology: Shows how internal parts, ports, and connectors collaborate within an instantiated boundary.
• Encapsulation: Treats the outer block boundary as an interface firewall; external elements interact only through perimeter ports, while internal assembly connectors handle subsystem communication.
• Instantiation Reality: Demonstrates how reusable block definitions are multiplied, parameterized, and wired together to form functioning system architectures.

---

The Enclosing Block Concept

One of the most foundational principles tested on the OCSMP Model User exam is the enclosing block rule:

Fundamental Rule: An Internal Block Diagram can never exist without an enclosing block classifier. An IBD always depicts the internal features and connections of exactly one enclosing block.

Unlike a BDD—which can display dozens of independent blocks, packages, and value types side by side—an IBD has an explicit owner. The outer rectangular boundary of an IBD is not just a cosmetic diagram canvas; it is the diagram frame, and that frame directly represents the boundary of the enclosing block itself. You cannot create a valid IBD that shows arbitrary parts floating in space without an enclosing classifier.

---

Diagram Frame Header Syntax and Grammar

SysML diagrams utilize a standardized diagram frame header format located in the upper-left corner of the diagram canvas inside a small pentagonal header box. For an Internal Block Diagram, this header follows a strict grammar:

ibd [modelElementType] modelElementName [diagramName]

Anatomical Breakdown of the IBD Header

1. Diagram Kind (ibd): Always lowercase ibd. This designates the diagram kind as an Internal Block Diagram.
2. Model Element Type ([modelElementType]): Enclosed in square brackets. For an IBD, this is almost universally [Block], because an IBD specifies the internal structure of a block. (SysML 1.2 also lets an ibd frame designate a constraint block, which is itself a kind of block.)
3. Model Element Name (modelElementName): The identifier of the specific enclosing block classifier whose internals are being shown (e.g., SpacecraftBus, Automobile, FlightController).
4. Diagram Name ([diagramName]): An optional descriptive title in brackets chosen by the modeler to distinguish multiple views of the same block (e.g., [High-Voltage Interconnect View], [Propulsion White-Box]).

Frame Header Comparison: BDD vs. IBD

---

Part Usages vs. Block Definitions

A central distinction in SysML is between a definition (a classifier) and a usage (a feature typed by a classifier):

1. Block Definition (BDD)

• A reusable blueprint, type, or specification.
• Declared as a block rectangle with the «block» keyword.
• Lives in a package namespace and is available to be reused across the entire model.
• Example: TurbofanEngine defined as a block.

2. Part Usage (IBD)

• A structural property owned by the enclosing block via composite aggregation.
• Represents a constituent component that exists when the enclosing block is instantiated.
• Rendered on an IBD as a rectangle with a solid line border.
• Shares the lifecycle of the enclosing block: destroying the enclosing block destroys all its part usages.

Textual Syntax of a Part Usage Label

Inside a part rectangle on an IBD, the label adheres to the standard property syntax:

[/] [name] : Type [multiplicity]

• Slash (/): Optional prefix indicating that the property is derived.
• Name: The role name of the part within the enclosing block context (e.g., leftEngine, guidanceUnit).
• Colon (:): Separator between the property role name and its typing classifier.
• Type: The name of the block that defines this part's structural and behavioral properties (e.g., TurbofanEngine).
• Multiplicity: Enclosed in square brackets (e.g., [1], [2], [0..1]). If omitted entirely, the default multiplicity is strictly 1.

---

Reference Usages on the IBD

Not every element that an enclosing block interacts with is owned as a composite part. Systems frequently interact with external devices, environment entities, shared service providers, or operator consoles. On an IBD, these are modeled as reference usages.

Visual and Semantic Rules for Reference Usages

• Dashed Border Notation: A reference usage is rendered as a rectangle with a dashed line border (never solid).
• Property Source: Corresponds to a reference property defined on a BDD via an association without aggregation (aggregation = none) or a directed reference association.
• Independent Lifecycle: The enclosing block does not own the referenced instance. If the enclosing block instance is destroyed, the referenced instance continues to exist.
• Labeling Syntax: Follows the identical property syntax format: name : Type [multiplicity].

Detailed Comparison: Part Usage vs. Reference Usage

---

Multiple Part Usages of the Same Block Type

A single block definition can be reused repeatedly across a system architecture. When an enclosing block requires multiple components with identical characteristics, it creates multiple part usages typed by the same block classifier.

Practical Example: Electric Vehicle Powertrain

Consider an enclosing block named AllWheelDrivePowertrain. It requires four traction motors. A system engineer defines a single block on a BDD:

+-----------------------+
|        «block»        |
|     TractionMotor     |
+-----------------------+

On the IBD of AllWheelDrivePowertrain, four distinct solid rectangles appear, each typed by TractionMotor:

1. frontLeftMotor : TractionMotor [1]
2. frontRightMotor : TractionMotor [1]
3. rearLeftMotor : TractionMotor [1]
4. rearRightMotor : TractionMotor [1]

Why This Matters on the Exam

• Distinct Instances: Each part usage represents a separate, uniquely addressable component instance in the instantiated system.
• Independent State: frontLeftMotor can have different operating speeds, temperatures, and fault states than rearRightMotor.
• Unique Wiring: Each part usage connects to its own independent inverter port and half-shaft mechanical connector.
• Common Error Distractor: Exam questions often attempt to trick candidates into thinking that multiple parts of the same type require defining four separate blocks (FrontLeftTractionMotor, FrontRightTractionMotor, etc.). Reusing a single block definition across multiple part usages is the canonical, modular MBSE approach.

---

Nested Parts, Encapsulation, and Deep Path Notation

Complex systems exhibit hierarchical depth. A part may itself have internal parts, forming a tree of nested components. SysML supports viewing these sub-components directly within an IBD through nested parts.

Visual Representation of Nested Parts

On an IBD, a modeler can draw a part rectangle inside another part rectangle (a white-box view of that part). For instance, inside the part rectangle avionicsBay : AvionicsSubsystem, the modeler can place an internal part rectangle flightComputer : ProcessingUnit.

+-------------------------------------------------------------------------+
| ibd [Block] AutonomousDrone [DroneDecomposition]                        |
|                                                                         |
|  +-------------------------------------------------------------------+  |
|  | flightController : AvionicsSubsystem [1]                          |  |
|  |                                                                   |  |
|  |   +---------------------------------+                             |  |
|  |   | navCore : NavigationComputer [1] |                            |  |
|  |   +---------------------------------+                             |  |
|  +-------------------------------------------------------------------+  |
+-------------------------------------------------------------------------+

Deep Path Notation (Property Path)

When referencing nested features without drawing all intermediate visual containers, SysML uses dot-separated deep path notation (property paths):

flightController.navCore.gpsReceiver

This notation traces the structural hierarchy from the context of the enclosing block down to the specific leaf feature. Connectors can bridge across nested boundaries using property paths, though SysML encapsulation best practices encourage routing connections through perimeter ports.

---

Worked Engineering Scenario: Autonomous Delivery Drone Architecture

To see all these concepts integrated in an authentic MBSE setting, consider an autonomous package delivery drone:

1. Enclosing Block: DeliveryDrone

   • Header: ibd [Block] DeliveryDrone [Internal Architecture]
   • The diagram frame constitutes the outer structural shell of the drone.

2. Part Usages (Solid Rectangles):

   • flightController : AvionicsUnit [1]: The primary embedded computing platform.
   • batteryPack : LiPoBattery [1]: The internal chemical power storage unit.
   • frontLeftMotor : BrushlessMotor [1]: First propulsion motor.
   • frontRightMotor : BrushlessMotor [1]: Second propulsion motor.
   • rearLeftMotor : BrushlessMotor [1]: Third propulsion motor.
   • rearRightMotor : BrushlessMotor [1]: Fourth propulsion motor.

3. Nested Parts:

   • Inside flightController: primaryCPU : CoreProcessor [1] and inertialSensor : IMU [1] are rendered as nested solid rectangles.

4. Reference Usages (Dashed Rectangles):

   • groundHub : DeliveryDispatchStation [0..1]: Rendered with a dashed border. The drone communicates with the dispatch station during flight operations, but the dispatch station is an external facility that is not physically owned or lifecycle-bound by the drone.

---

Common Exam Traps & Pitfalls

• Trap 1: Confusing Diagram Frames (BDD vs. IBD): If a question shows a diagram framed as bdd [Package] PropulsionSystem, it is a Block Definition Diagram, not an IBD. An IBD header must begin with ibd and almost always specifies [Block] as the element type.
• Trap 2: Believing an IBD Can Depict Unenclosed Blocks: An IBD can never display floating, uncontained block definitions. Every element inside the IBD frame is an internal feature (part, port, reference, connector) of the single enclosing block.
• Trap 3: Border Inversion (Solid vs. Dashed): A solid line rectangle is a part usage (composite ownership). A dashed line rectangle is a reference usage (non-owning reference). Conflating the two is one of the most common distractors.
• Trap 4: Duplicate Definitions vs. Multiple Usages: When seeing four identical motors on an IBD, do not select answers claiming that four motor blocks were defined. Exactly one block definition (BrushlessMotor) was defined, and four part usages were instantiated.
• Trap 5: Default Multiplicity on Part Labels: When a part label reads sensorPod : SensorUnit with no brackets, its multiplicity is strictly 1 (or 1..1), never 0..1 or *.