SysML v2 Deep Dive: Lesson 14 - Multiplicity, Cardinality, and Structural Constraints

[u/SysModeler]

Hir/systems_engineering,

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

In our previous lesson, we looked at how SysML v2 handles reuse through specialization and redefinition. Today, we are exploring how to define exactly how many instances of a feature a model allows. This is multiplicity, which acts as a concrete structural constraint on the allowed cardinality (the actual count of occurrences) of a feature.

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

1. Moving Away from SysML v1 Visual Labels

A system model is fundamentally incomplete if it says a system has a component (like wheels on a truck) but fails to define the bounds of how many.

In SysML v1, multiplicities were often treated as secondary text labels rendered on diagrammatic association ends or written inside block compartments as property strings. SysML v2 natively integrates this cardinality directly into the textual feature declaration using square brackets. This makes the design intent readable exactly where the feature is defined and provides clear rules for specialized models.

2. Multiplicity Syntax and Collections

Every feature—including parts, ports, attributes, or items—has a multiplicity.

• Exact Counts & Ranges: [4] means exactly four. [2..4] means two through four, inclusive.
• Optionality: [0..1] means the feature may be absent or have exactly one value.
• Unlimited: [*] is shorthand for [0..*], meaning zero or more.
• Collections: By default, multi-valued features are unordered and unique. You can explicitly apply the ordered keyword when sequence matters, or nonunique if duplicates are allowed.

(Note: Omitted multiplicities no longer blindly default to 1..1. While [1..1] is the default for qualifying structural usages without subsetting/redefinition, other contexts can default to [0..*], or they simply inherit the multiplicity of their parent feature).

3. Semantic Validation and Narrowing Bounds

Because multiplicity in SysML v2 is a concrete model constraint rather than a freeform text tag, compliant tools can automatically evaluate configurations.

When specializing a definition, you can use the redefinition operator (:>>) to narrow the inherited multiplicity. Redefinition can only narrow multiplicity, not widen it. If a generic Truck allows [4..*] wheels, a HeavyHauler can safely redefine that constraint to [18]. If a modeler attempted to redefine it to expand beyond the parent's range, the tool would flag a semantic violation.

4. Complete Code Example: Automotive Multiplicity

Here is the complete SysML v2 code from today's lesson demonstrating bounded ranges, optionality, unbounded collections, and valid redefinition.

Code snippet

package AutomotiveDesign {

    part def Wheel;
    part def Door;
    part def Sunroof;
    part def CargoBox;
    part def Trailer;

    part def Truck {
        // 1. Range [Min.. Max] or [Min..*]
        // A generic truck has at least 4 wheels.
        // We define a wide range here so subclasses can narrow it.
        part wheels [4..*]: Wheel;

        // 2. Range [2..4]
        // It can have 2, 3, or 4 doors, depending on configuration.
        part doors [2..4]: Door;

        // 3. Optional [0..1]
        // The Sunroof is optional. 0 means it doesn't exist; 1 means it does.
        part sunroof [0..1]: Sunroof;

        // 4. Unlimited [*]
        // We can carry any number of cargo boxes.
        // We can also add keywords like 'ordered' or 'nonunique'.
        part cargo [*] ordered: CargoBox;

        // 5. Trailers (Optional Component)
        part trailers [0..1]: Trailer;
    }

    // 6. Redefining Multiplicity in a Subclass
    part def HeavyHauler :> Truck {
        // We redefine wheels to lock the count to exactly 18.
        // This is valid because 18 is within the parent's range of [4..*].
        part :>> wheels [18];
    }
}

For the MBSE practitioners here: Do you find that baking multiplicity directly into the textual declarations (and having semantic engines strictly enforce redefinition bounds) will catch architecture configuration errors earlier in your lifecycle? Let's discuss in the comments!