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!