u/SysModeler

Hey everyone. I have been putting together some visual breakdowns on the transition to SysML v2, and I wanted to share a look at how the new standard handles the Parts Tree.

In SysML v1, showing that a system owned a part meant drawing a composite association, which was a line with a solid black diamond on the parent side. Doing this at scale often turns block definition diagrams into unreadable spiderwebs.

SysML v2 preserves the graphical notation, but it introduces a perfectly equivalent textual notation where ownership is established simply by nesting elements inside curly braces. When an element is declared within the body of a namespace, it automatically establishes an owning membership relationship.

Here is a quick look at how you define a specialized vehicle configuration. Notice the strict distinction between subclassification (a definition inheriting from a definition) and subsetting (a usage inheriting and restricting a usage):

Code snippet

package VehicleHierarchy {
    part def Engine;
    part def V8_Engine :> Engine;
    part def Wheel;

    abstract part def Vehicle {
        abstract part engines: Engine [1..*];
        abstract part wheels: Wheel [2..*];
    }

    part def SportsCar :> Vehicle {
        part carWheels: Wheel [4] subsets wheels;
        part mainEngine: V8_Engine subsets engines;
    }
}

By using the subsets keyword, we are asserting that mainEngine is a specific subset of the inherited engines collection. This narrows its allowed type to V8_Engine while still obeying the structural rules of the abstract base.

When loaded into a compliant v2 tool, this text code directly generates the visual Tree View, meaning your code structure and your model structure are the exact same thing.

I have attached the video explanation above for those interested in the visual breakdown. For those already experimenting with the v2 pilot, do you prefer this text-first nesting approach over manually routing composite lines?

Hey everyone,

One of the biggest headaches our team has always faced with MBSE is dealing with locked files, version control nightmares, and merge conflicts when multiple engineers need to touch the same architecture.

With SysML v2 transitioning to a textual-visual hybrid, we wanted to see if we could build a true IDE experience. We just got real-time co-editing working in our engine (SysModeler).

As you can see in the video, it syncs both the textual notation and the graphical canvas instantly across different users, complete with live cursors. No more waiting for someone to close out of a model before you can make an update.

We are still refining it for our mid-2026 release, but I wanted to share this milestone. For those of you managing large system models, how are you currently handling multi-user version control? Are you still relying on traditional check-in/check-out systems?

In theory, SysML v1 always supported separating definitions from usages. A Block provided the definition, while a Part Property provided the usage.

In practice, however, the Block became the universal hammer. Hardware? Block. Software? Block. Abstract concept? Block. As systems scaled, engineers relied heavily on drawing graphical composition lines (solid black diamonds) on Block Definition Diagrams (BDDs). When an architecture grew from 10 blocks to 10,000 blocks, these BDDs predictably turned into unmanageable spiderwebs of crossing lines.

The SysML v2 Solution: part def vs. part SysML v2 solves this by introducing a formally standardized textual syntax that explicitly forces you to separate the blueprint from the physical instantiation.

• Part Definition (part def): This is your reusable blueprint. It does not represent a specific physical object sitting on a lab bench; it represents the design of that object. It acts as a black box (defining external ports/connections) and defines the internal structure.
• Part Usage (part): This is the instantiation.

A great analogy is Object-Oriented Programming. The part def is the Java Class. The part is the specific variable instantiated from that class. A CAD file of a wheel is the part def, but when you build a car, you pull from that blueprint to instantiate four specific physical wheels (parts).

Textual Hierarchies over Graphical Spiderwebs Instead of manually drawing composition lines on a canvas to establish a hierarchy, SysML v2 allows you to establish composite ownership directly in the code. You simply declare a part inside the curly braces of its parent part def. When rendered, the tool auto-generates a clean hierarchical tree, significantly reducing graphical clutter.

Physics and System Laws SysML v2 also upgrades how we handle properties and constraints within these definitions:

• Attributes: V1 "value properties" are replaced by the attribute keyword. By using this, you can leverage the International System of Quantities (ISQ) standard library. The system actually understands the physics (e.g., that a value is a "mass" quantity) rather than just reading a raw number.
• Asserting Constraints: You can write simple Boolean math expressions directly inside your part definition (e.g., assert payload.mass < total_mass). If a payload's mass ever exceeds that limit, the system architecture is flagged as mathematically invalid right at the code level.

For those of you already digging into SysML v2, how do you feel about shifting from drawing graphical composition lines to defining nested hierarchies textually?

In theory, SysML v1 always supported separating definitions from usages. A Block provided the definition, while a Part Property provided the usage.

In practice, however, the Block became the universal hammer. Hardware? Block. Software? Block. Abstract concept? Block. As systems scaled, engineers relied heavily on drawing graphical composition lines (solid black diamonds) on Block Definition Diagrams (BDDs). When an architecture grew from 10 blocks to 10,000 blocks, these BDDs predictably turned into unmanageable spiderwebs of crossing lines.

The SysML v2 Solution: part def vs. part SysML v2 solves this by introducing a formally standardized textual syntax that explicitly forces you to separate the blueprint from the physical instantiation.

• Part Definition (part def): This is your reusable blueprint. It does not represent a specific physical object sitting on a lab bench; it represents the design of that object. It acts as a black box (defining external ports/connections) and defines the internal structure.
• Part Usage (part): This is the instantiation.

A great analogy is Object-Oriented Programming. The part def is the Java Class. The part is the specific variable instantiated from that class. A CAD file of a wheel is the part def, but when you build a car, you pull from that blueprint to instantiate four specific physical wheels (parts).

Textual Hierarchies over Graphical Spiderwebs Instead of manually drawing composition lines on a canvas to establish a hierarchy, SysML v2 allows you to establish composite ownership directly in the code. You simply declare a part inside the curly braces of its parent part def. When rendered, the tool auto-generates a clean hierarchical tree, significantly reducing graphical clutter.

Physics and System Laws SysML v2 also upgrades how we handle properties and constraints within these definitions:

• Attributes: V1 "value properties" are replaced by the attribute keyword. By using this, you can leverage the International System of Quantities (ISQ) standard library. The system actually understands the physics (e.g., that a value is a "mass" quantity) rather than just reading a raw number.
• Asserting Constraints: You can write simple Boolean math expressions directly inside your part definition (e.g., assert payload.mass < total_mass). If a payload's mass ever exceeds that limit, the system architecture is flagged as mathematically invalid right at the code level.

For those of you already digging into SysML v2, how do you feel about shifting from drawing graphical composition lines to defining nested hierarchies textually?