In 1999, NASA lost the Mars Climate Orbiter because one team used pound-force-seconds and the other expected newton-seconds. Both numbers were correct. Neither carried its unit.

The spacecraft was never modeled in SysML, v1 didn't exist yet. But if it had been, v1 wouldn't have caught this either. In SysML v2, the unit lives in the type. Assign the wrong one and the parser rejects it before it ever ships.

Hi r/systems_engineering,

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

In our previous lessons, we covered how to wire up system topologies and model passive payloads using item def. Today, we are looking at how SysML v2 handles reuse—specifically, how to create a more specific model from a general one, and how to change an inherited feature without altering the original definition.

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

1. Moving Away from UML Property Strings

Engineering models rely heavily on reuse. You might define a generic Engine once, and then build more specific types from it (e.g., a V8 or an electric motor).  

In SysML v1, to make a local change to an inherited property, modelers had to use textual UML property strings like {redefines engine} or {subsets engine}. While effective, these were essentially string tags appended to visual properties. SysML v2 streamlines this by elevating these concepts to primary mathematicaloperators.  

2. The Three Core Operators

Confusing these operators can produce a model that looks plausible but hasthe wrong underlying semantics. Here is how they break down:  

• Feature Typing (:): Binds a usage to a definition, giving it its shape.  
  • Example:part myEngine : Engine means the part usage myEngine is typed by the Engine definition.

   

• Specialization / Subsetting (:>): Establishes a more specific relationship.  
  • Between definitions (Specialization): A V8Engine inherits the features and constraints of a general Engine.  
  • Between usages (Subsetting): A frontWheels feature can subset a general wheels feature, meaning its values are constrained to be a subset of the total wheels.

   

• Redefinition (:>>): Replaces an inherited feature locally while maintaining compatibility with what was inherited. It does not create an unrelated new feature.

3. A Practical Example: Redefining an Engine

Let's say you have a generic Engine definition with an inherited attribute for cylinderCount (typed as an Integer) and a rule that power > 0.  

When you create a specialized V8Engine :> Engine, you don't rewrite the whole definition. Instead, you redefine the specific feature for that context:  

Code snippet

part def V8Engine :> Engine {
    attribute redefines cylinderCount = 8;
}

(Note: In the textual notation, redefines is the keyword used to represent the :>> operator).  

4. Semantic Validation

Because redefinition is now a strict mathematical replacement rather than a freeform text tag, compliant tools can automatically validate your architecture.  

For instance, narrowing an inherited integer-valuedcylinderCount to 8 is mathematically compatible. But if a modeler accidentally tried to redefine that feature using a String (e.g., "Eight"), the tool would natively flag the semantic error because it breaks the original typing constraint.  

For the MBSE practitioners here: Do you feel that replacing UML property strings with strict mathematical operators will make it easier to validate and audit complex, deeply nested architectures? Let's discuss in the comments!  

Hi r/systems_engineering,

We are back with Lesson 12 of our deep dive into the SysML v2 standard. In Lesson 11, we covered how to wire up explicit topologies using connect and interface usages. But a connection only tells us where the system is connected—not what actually moves through it.

Today, we are looking at how to model the passive payloads that exist, flow, and are stored within those architectures using the new item def construct.

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

1. Separating Active from Passive Elements

In SysML v1, engineers often modeled exchanged payloads by typing a FlowProperty or an ItemFlow with a generic Block, ValueType, or Signal. This meant using the exact same generic block construct for a passive payload (like water or data) as you would for an active system component (like a pump or a processor).

SysML v2 fixes this semantic gap with item def—a dedicated construct for things that exist in space and time and can be acted upon, but don't necessarily perform actions themselves. A good rule of thumb in v2: use part for active structural elements and item for passive payloads.

2. Modeling Physical vs. Digital Payloads

Because item def is a definition, it natively owns its attributes and constraints. You can use it to explicitly define physical matter (like Fuel with a specific octane level and density) or information (like PaymentData with encryption keys and timestamps).

3. Dimensional Consistency and Constraints

When modeling physical items, SysML v2 enforces dimensional consistency using imported ISQ/SI libraries. You can add constraints directly to the item definition (e.g., constraint { density > 700[kg/m^3] }). Compliant tools can then reason about this to ensure units and quantities are mathematically compatible during flow and mass balance analysis.

4. Exchange vs. Storage

The definition-usage pattern applies cleanly here depending on the context:

• Exchange: Declaring an out item inside a port defines the system's ability to send that item type across an interface.
• Storage: Nesting an item usage inside a part (e.g., a Fuel item inside a FuelTank part) represents the payload physically retained within that structural boundary.

For the community: How much value do you see in having this strict semantic separation between active parts and passive items compared to the v1 generic Block approach? Let's discuss in the comments!

Hi r/systems_engineering,

We are back with Lesson 11 of our technical deep dive into the new standard.

In our previous lesson, we analyzed how interface def acts as a connection blueprint that can natively hold its own physical properties. Today, we are shifting our focus to how we actually use those blueprints to wire up a concrete system topology.

1. Moving Beyond Visual-Only Topologies

When analyzing a system architecture, managing and reviewing its connectivity purely through tracing lines on an Internal Block Diagram can make topology difficult to search, version-control, or programmatically validate.

SysML v2 addresses this by making system topology explicit within the model text itself. A connection can be declared natively, allowing the architecture to be read, searched, and inspected directly without depending solely on a graphical diagram.

2. Navigating Nested Endpoints: Feature Chains

To establish a connection textually when ports are nested deep inside part definitions, SysML v2 utilizes dot notation—formally known as a feature chain.

For example, if you have a Charger part usage containing a plug port, you reference that specific endpoint using: Charger.plug

This allows you to explicitly state exactly which internal interfaces are hooking up to one another from a local system context block.

3. Connect Usages vs. Interface Usages

Depending on how detailed your system model needs to be, you have two primary ways to declare connectivity in the text:

• The Simple connect Shorthand: Useful when all you need to assert is basic structural connectivity between parts or items.
• Typed Interface Usages: When a connection strictly links ports together and needs to carry engineering data, you use an interface usage typed by an interface def.

Example:

Code snippet

interface usage charging_session: ChargingCable {
    end charger_side = Charger.plug;
    end vehicle_side = MyCar.socket;
}

(Note: There is also a compact, one-line shorthand form available when the end mappings are obvious and don't need explicit block declarations).

Because this interface usage points directly to your reusable connection definition, it inherits all specified semantic constraints and attributes (such as cable resistance or data latency) directly within that local context topology.

4. Semantic Validation Benefits

Because connections are explicitly declared and typed by an interface definition in the text, compliant tools have the semantic information necessary to automatically validate your model. The tool can check if the referencing ends actually conform to the expected port types, natively flagging errors if someone accidentally tries to connect incompatible ports in a design loop.

Hi r/systems_engineering,

We are back with Lesson 10 of our technical deep dive into SysML v2.

In our previous lesson, we looked at conjugation (~) and how it mathematically reverses an endpoint's directed features. Today, we are shifting our focus from the endpoints to the connection itself. I’ve uploaded the full video lesson directly here so you don’t have to leave Reddit.

1. The Problem with Connections in V1

When modeling a physical connection—like a charging cable, a data bus, or a fluid pipe—the connection is rarely just a decorative line on a diagram. It has its own physical properties like length, resistance, latency, and thermal limits.

In SysML v1, if you wanted a connection to have its own physical properties or internal structure, you usually had to type the connector with a specialized construct known as an Association Block. Because this felt cumbersome, many modelers just left connections as visual lines and hid the physical properties in comments or external spreadsheets.

2. The Solution: Interfaces as Specialized Parts

SysML v2 makes the physical nature of connections native to the language using interface def.

According to the v2 specification, an interface def is a connection definition specifically restricted to connecting ports. But here is the most important part: mathematically, an interface definition is a specialized part def. Because it is structurally a part under the hood, the connection itself can natively hold its own values, physical properties, and internal components over its lifetime. It turns the "wire" into a first-class engineered component in your model.

3. Typed Ends and Automated Validation

An interface definition acts as a reusable blueprint. Inside the interface, you define the compatible port ends.

For example, a ChargingInterface might require the "charger" side to be typed by a normal ChargingPort, and the "vehicle" side to be typed by a conjugated ~ChargingPort.

Because the interface explicitly declares its compatible ends, the model becomes mathematically rigorous. If someone tries to use this interface to connect two vehicle sockets or two charger plugs, a compliant v2 tool can automatically reject or warn about the invalid pairing.

4. V1 vs. V2 Interface Definitions Cheat Sheet

Hi r/systems_engineering,

We are back with Lesson 9 of our technical deep dive into the new standard.

In our previous lesson, we established the difference between connection endpoints (port def) and connection blueprints (interface def). Today, we are tackling one of the most useful structural features in SysML v2: Conjugation.

I’ve uploaded the full video lesson directly here so you don’t have to leave Reddit. 👇

1. The "Mirrored Interface" Problem in V1

If you’ve modeled physical or logical connections in SysML v1, you know the headache of representing two sides of the same interaction. If a charger outputs power and receives data, the vehicle on the other end must input power and send data.

In V1, modelers usually handled this by manually creating duplicate, mirrored Interface Blocks (e.g., an "In" and an "Out" version), or by toggling an isConjugated=true property that was buried in a properties menu and incredibly easy to miss.

2. The Solution: Define Once, Flip Once

SysML v2 natively solves this duplication issue with the conjugation operator ( ~ ).

You define the port once from a chosen perspective. Then, when the opposing part uses that same port, you simply prepend the tilde.

Example:

• The Charger: You define a ChargingPort where power goes out and payment data comes in. The Supercharger block uses this port exactly as defined: port plug: ChargingPort;
• The Vehicle: The EV block uses the exact same definition, but conjugated: port socket: ~ChargingPort;

By adding the ~, SysML v2 mathematically reverses the direction of all nested directed features inside that port. We didn't create a second "Consumer" port definition; we used one definition from two complementary perspectives.

3. Why It Actually Matters (Semantics > Visuals)

Conjugation in v2 isn't just a visual shorthand for the diagram—it changes the underlying model semantics.

If someone accidentally tries to connect two unconjugated ChargingPort usages, both sides will try to output electricity and receive data. Because the directed features don't complement each other, a compliant v2 tool can natively flag that connection as mathematically invalid. It catches the integration error in the model before it ever reaches physical hardware.

4. V1 vs. V2 Conjugation Cheat Sheet

Hi r/systems_engineering,

We are back with Lesson 8 of our technical deep dive into the new standard.

In our previous lessons, we built a Parts Tree hierarchy. Today, we are tackling another major practical pain point from V1: modeling interfaces and connection endpoints without the headache of redundant definitions.

I’ve uploaded the full video lesson directly here so you don’t have to leave Reddit. 👇

1. The "Interface" Problem in V1

In SysML v1, modeling interfaces was often a struggle. You had to carefully choose between "Proxy Ports" typed by Interface Blocks and "Full Ports" typed by Block types. On top of that, you had to manually manage "Flow Properties" and keep explicit track of direction management across opposing sides of a connection.

2. The Solution: The Definition-Usage Pattern

SysML v2 standardizes ports and interfaces by using the exact same Definition-Usage pattern used throughout the rest of the language. It strictly separates the endpoint from the connection rules:

• port def (The Endpoint): Think of this as the physical shape of a pin or a socket. It specifies interaction features, such as the capacity to receive items using the in keyword, or send them using out.
• interface def (The Protocol): This is the blueprint of the connection itself. It defines the structure of the "wire" or protocol that links two ports together (what a valid connection looks like).

3. The "Aha!" Moment: The Conjugation Operator (~)

This is the feature that eliminates redundant modeling. In v1, you often had to build a mirrored port definition from scratch just to connect a plug to a socket.

In v2, you define a port definition once. When you need the opposing side (e.g., a refueling nozzle connecting to a fuel tank), you simply use the conjugation operator: the tilde (~). Using ~FuelingPort mathematically flips the direction of the interaction features. An in instantly becomes an out, and vice versa, creating immediate mathematical compatibility.

4. V1 vs. V2 Syntax Cheat Sheet

We’d love to hear your thoughts: Do you think native mathematical conjugation will finally make interface modeling less tedious, or is it just a different flavor of syntax to learn?

Let me know what you think in the comments!

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?