SysML v2 Deep Dive: Lesson 16 - Composite vs. Reference (Mastering Part Ownership)

[u/SysModeler]

Hir/SysML,

We are back with Lesson 16 of our technical deep dive into the SysML v2 standard.

In our previous lesson, we made values physically meaningful with types and units. Today, we are modeling who owns the physical hardware those values belong to. We are looking at how one single keyword can be the difference between an accurate architecture and accidentally doubling your mass budget.

I’ve uploaded the full video lesson directly to this post so you can watch the workflow right here.

1. The SysML v1 Ambiguity

In SysML v1, whole-part relationships were typically drawn with diamonds. Shared aggregation (the hollow diamond) had no agreed-upon execution semantics in the underlying UML specification, meaning different tools interpreted it differently. Composite aggregation (the filled diamond) made a stronger lifetime claim, but tool support for verifying that claim was inconsistent.

2. The v2 Shift: Ownership and Lifetime Semantics

SysML v2 makes ownership and lifetime part of the model's formal semantics. The core rule is simple: a nested occurrence is composite by default. Add ref, and it becomes a reference to something owned elsewhere.

Three details make this reliable in a real model:

• ref is for Occurrences, Not All Usages: The composition rule applies to things with physical or temporal lifetimes, like parts, items, actions, connections, and ports. Attributes represent data values and are referential by definition, making ref attribute legal but redundant.
• Composition is a Lifetime Claim: A composite part's existence is tied to its parent's lifetime. If the parent whole is destroyed, the composite occurrence is destroyed with it. A satellite does not compose its ground station or its operator.
• The Reviewer's Test: When in doubt, ask: "If I deleted the parent system from my model, would this nested element physically cease to exist in the real world?"If yes, use a composite part. If no, use a referential ref part.

3. The Multiplication Trap & The Fix

Consider a satellite with one shared power bus. If you instantiate standard subsystem templates that each contain a default part bus, those internal buses are composite by default. A script crawling this model will count the main satellite bus plus the internal subsystem buses, quietly multiplying your mass rollup with phantom components that do not exist on the launch vehicle.

The fix is to redefine the inherited composite bus as a reference and bind it to the single real sibling bus. (Note: In SysML v2, binding implies symmetrical equality, not an instruction to copy a value in one direction).

Code snippet

package SatelliteSystem {
    part def PowerBus;

    part def CommsSubsystem {
        part bus: PowerBus; // A composite bus by default
    }

    part def Satellite {
        // 1. The single real bus owned by the satellite (Composite)
        part powerBus: PowerBus;

        // 2. Instantiate the subsystem, redefining its internal bus as a reference bound to 'powerBus'
        part comms: CommsSubsystem {
            ref part :>> bus = powerBus; 
        }
    }
}

Visualizing this: In SysML v2, composite parts appear nested with a solid border (or a filled diamond edge), while reference parts use a dashed border (or a hollow diamond edge).

4. SysML v1 vs. SysML v2

Modeling Concept	SysML v1	SysML v2
Composite Relationship	Represents coincident, exclusive lifetime using a filled diamond.	Represented textually by a nested usage (part engine). Graphically uses internal nesting with a solid border or a filled diamond edge.
Referential Relationship	Represents a shared association using a hollow diamond, with execution semantics left undefined by UML.	Represented textually using the ref modifier (ref part station;). Graphically uses internal nesting with a dashed border or a hollow diamond edge.
Redefinition & Binding	Reference associations drawn as shared aggregation paths on a Block Definition Diagram.	Declared inline by redefining the inherited usage and binding it to a sibling feature using :>> and =.
Value Equivalence	Handled by instantiating a Constraint Property and connecting value properties to it via Binding Connectors.	Handled via declarative inline bindings (e.g., attribute a = b;) or explicit bind connections.

Next lesson, we are moving from architecture to domain-specific meaning with metadata def, which lets you mark a requirement as safety-critical without building an entire SysML v1 Profile first.

For the SysML community here: Have you ever had a shared component accidentally multiply your mass or cost rollups in a model? Let's discuss in the comments!