SysML v1 vs SysML v2: The Most Important Changes Explained

Key Takeaways

• SysML v2 is not simply an update to SysML v1. It is a new, ground-up redesign of the language.
• SysML v1 is defined as a profile of UML, while SysML v2 has its own metamodel built on KerML.
• SysML v2 provides standardized graphical and textual notation for the same underlying model.
• The Definition and Usage pattern is applied systematically across the language.
• SysML v2 makes a clearer distinction between the semantic model and the Views used to present selected model information.
• A standardized Systems Modeling API and Services improves access to SysML models and interoperability with other engineering tools.
• SysML v1 knowledge remains valuable, but moving to SysML v2 involves learning a substantially different language.

Introduction

For almost two decades, SysML v1 has provided systems engineers with a standard language for modeling Requirements, Structure, Behavior, Interfaces, Constraints, and other important aspects of complex systems.

SysML v2 continues the same overall mission, but it is important to understand one thing from the beginning: SysML v2 is not simply the next incremental update to SysML v1.

It is tempting to think of it as something similar to moving from SysML 1.6 to SysML 1.7: a few new concepts, some corrections, and perhaps improved notation.

That is not what happened.

OMG describes SysML v2 as a ground-up redesign. SysML v1.7 is the final SysML v1 version before SysML v2, and OMG created a separate normative transformation specification to define how information represented using SysML v1 concepts can be translated into SysML v2 concepts.

The reason is architectural.

SysML v1 is based on UML and extends UML through a Profile. SysML v2 has a new metamodel, new concrete syntax, new semantics, and a new foundation called KerML. The official SysML v2 specification explicitly defines its textual and graphical syntax, abstract syntax, and semantics.

So although the two languages address many of the same systems-engineering problems, SysML v2 should be learned as a new language rather than as a collection of changes to SysML v1 syntax.

To make the differences easier to understand, we will use one simple example throughout this article: an Electric Vehicle.

Our vehicle contains:

• a Battery,
• two Electric Motors,
• a Charging Port,
• Requirements such as driving range,
• Behaviors such as charging and driving.

We will use this same model to see how the thinking changes from SysML v1 to SysML v2.

1. A New Language Foundation: From UML to KerML

The deepest difference between SysML v1 and SysML v2 is not visible on a diagram.

It is the architecture of the language itself.

SysML v1: Built on UML

SysML v1 is defined as a UML Profile.

This means that many SysML concepts are based on UML concepts and extended using stereotypes.

For example, an Electric Vehicle might be modeled using a SysML v1 Block:

• ElectricVehicle
• Battery
• ElectricMotor
• ChargingPort

Part Properties inside ElectricVehicle could then represent the Battery and Motors that compose the vehicle.

This approach allowed SysML to reuse a mature modeling language rather than building a completely new language from the beginning.

However, it also meant that SysML inherited much of UML's underlying architecture.

SysML v2: Built on KerML

SysML v2 takes a fundamentally different approach.

It is specified using its own metamodel, which extends the Kernel metamodel defined by the Kernel Modeling Language, or KerML.

KerML is an application-independent modeling language that provides the underlying concepts and semantics needed by SysML v2.

SysML v2 then adds systems-engineering-specific concepts such as:

• Parts,
• Requirements,
• Actions,
• States,
• Interfaces,
• Verification Cases,
• Use Cases,
• Views.

For most systems engineers, this does not mean that KerML needs to be learned before SysML v2.

A useful mental model is simply:

KerML provides the foundation. SysML v2 provides the systems-engineering language.

Electric Vehicle example

In SysML v1, we could define:

Block: ElectricVehicle

with Part Properties typed by Blocks such as:

• battery : Battery
• frontMotor : ElectricMotor
• rearMotor : ElectricMotor

In SysML v2, the same engineering idea can be expressed using a Part Definition and Part Usages:

This is not simply new notation for a SysML v1 Block.

The concepts belong to a different metamodel. In fact, the official SysML v1-to-v2 transformation specifies that a SysML v1 Block is mapped to a SysML v2 PartDefinition.

Why this matters

This is the reason you should avoid learning SysML v2 by asking: “What is the SysML v2 equivalent of every SysML v1 symbol?”

Mappings can certainly help during migration, but SysML v2 has its own conceptual structure.

Understanding that structure is much more useful than trying to treat SysML v2 as SysML v1 with renamed elements.

Image 1: SysML v1 = UML Profile, SysML v2 = Metamodel extending KerML

2. Textual Notation Becomes Part of the Standard

SysML has traditionally been strongly associated with graphical diagrams. SysML v2 changes this considerably.

The SysML v2 specification defines both a graphical notation and a textual notation as concrete syntaxes of the language.

Consider our Electric Vehicle again.

The structural information can be represented textually:

A modeling tool can also present information from this model graphically.

The important point is: The text is not one model and the diagram another model. Both are ways of representing information from the same underlying semantic model.

This is an important conceptual change for anyone accustomed to thinking primarily in terms of SysML diagrams.

Does this mean diagrams are disappearing?

No.

Graphical modeling remains an important part of SysML v2. The standard contains extensive graphical notation alongside its textual notation. Text and graphics serve different purposes.

Text can be convenient when:

• creating or editing larger amounts of model content,
• comparing changes,
• generating model elements automatically,
• integrating modeling into text-oriented engineering workflows.

Graphics remain extremely effective when:

• communicating architecture,
• explaining relationships,
• reviewing behavior,
• presenting information to stakeholders.

The real change is therefore not: Diagrams → Text

It is: Diagrams only → Graphical + Textual ways of working with the model

Image 2: One Electric Vehicle Model, Two Representations

3. Definition and Usage Becomes a Consistent Pattern

The next important change is the systematic distinction between Definitions and Usages. The idea itself will not be completely unfamiliar to experienced SysML v1 users.

For example, SysML v1 distinguishes between:

• a Block such as ElectricMotor,
• and a Part Property such frontMotor : ElectricMotor.

There is already an informal idea of defining something and then using it. The problem is that this pattern is not applied consistently across the entire SysML v1 language.

SysML v2 makes Definition and Usage a fundamental and systematic language pattern. OMG's SysML v2 material explicitly identifies this as a major difference from SysML v1.

Definition

A Definition describes a reusable kind of thing.

For our vehicle:

defines what an ElectricMotor is.

Usage

A Usage describes how something is used in a particular context.

Inside the Electric Vehicle we can write:

Both are Usages of the same Definition.

The official specification uses this Definition/Usage pattern throughout the language and provides corresponding graphical and textual notation.

You will find:

• Part Definitions and Part Usages,
• Action Definitions and Action Usages,
• State Definitions and State Usages,
• Requirement Definitions and Requirement Usages,
• Interface Definitions and Interface Usages,
• Use Case Definitions and Use Case Usages,
• View Definitions and View Usages.

Why this matters

This creates a much more consistent modeling language.

Instead of learning a different conceptual pattern for every part of SysML, modelers repeatedly ask two questions: What kind of thing am I defining? and How is that thing being used in this context?

For the Electric Vehicle, ElectricMotor can be defined once and used as both the front and rear motor.

The same principle can later be applied to a reusable Requirement Definition, Action Definition, State Definition, or Interface Definition.

Image 3: SysML v2 systematically distinguishes reusable Definitions from their Usages in specific contexts.

4. The Model Is More Clearly Separated from Its Views

Another important change is how SysML v2 treats Views and model presentation.

SysML v1 already includes the concepts of View and Viewpoint, so the idea itself is not completely new. SysML v2, however, makes the relationship between the semantic model and its presentations much more systematic.

The language defines:

• View Definitions,
• View Usages,
• Viewpoint Definitions,
• Viewpoint Usages,
• Rendering Definitions,
• Rendering Usages.

It also explicitly treats Diagrams as View Usages.

This reinforces an important MBSE principle: The model is not the diagram. A model contains engineering information. A View selects and presents information from that model for a particular purpose.

Electric Vehicle example

Imagine that our Electric Vehicle model contains:

• Parts,
• Requirements,
• Actions,
• Interfaces,
• States,
• Verification Cases.

A mechanical engineer may want to see the physical Structure:

• ElectricVehicle
• Battery
• Electric Motors
• Charging Port

A requirements engineer may want to see:

• Driving Range Requirement
• Charging Time Requirement
• the Electric Vehicle as the Requirement Subject

A behavior engineer may want to see:

• Start Charging
• Charge Battery
• Stop Charging

These are not three separate Electric Vehicle models. They are different Views that present selected information from the same underlying model.

Why this matters

This encourages engineers to separate two questions: What information belongs in the model? from: How should that information be presented to this stakeholder?

The distinction becomes increasingly important as models grow. Trying to place everything into one diagram produces unreadable models. Creating disconnected copies for different stakeholders creates inconsistency.

Views provide a better approach: select the information that matters and present it appropriately while retaining one semantic model underneath.

Image 4: Different Views present selected information from the same underlying Electric Vehicle model.

5. A Standard API Opens the Model to Other Engineering Tools

The final change is not primarily about modeling notation. It is about what other tools can do with the model.

SysML v2 was developed alongside the Systems Modeling API and Services standard.

The API provides standardized services to access, navigate, and operate on KerML-based models, particularly SysML models. OMG states that these services are intended to facilitate interoperability both between SysML modeling environments and between SysML environments and other engineering tools and enterprise services.

The specification includes platform-specific models for technologies including REST/HTTP and OSLC. This is a significant development.

A SysML model no longer needs to be treated primarily as information locked inside one modeling application. Standardized services make it possible for other applications to access model information through defined interfaces.

Electric Vehicle example

Our Electric Vehicle model could contain:

• vehicle architecture,
• Requirements,
• behaviors,
• parameters,
• verification information.

Different engineering applications may need different pieces of that information.

For example:

• Requirements management may need access to the Driving Range Requirement.
• Simulation may need Battery capacity, vehicle mass, or motor parameters.
• Verification tools may need Requirements and Verification Cases.
• Automation scripts may query model elements and generate reports.
• Lifecycle-management tools may need relationships between engineering model elements and other product information.

The Systems Modeling API provides a standard foundation for creating these kinds of integrations. It does not mean that every tool automatically integrates with every other tool, but it provides standardized mechanisms on which integrations can be built.

Why this matters

This supports a broader shift in MBSE.

The SysML model can become part of a wider digital engineering environment, rather than functioning as an isolated set of diagrams.

Image 5: Standardized API services allow SysML v2 model information to participate in a broader engineering toolchain.

SysML v1 vs SysML v2: Quick Comparison

What Has Not Changed?

After emphasizing the differences, it is equally important not to create the wrong impression. SysML v2 is a new language, but systems engineering did not start again from zero.

Our Electric Vehicle still needs:

• Requirements,
• Structure,
• Behavior,
• Interfaces,
• States,
• Constraints,
• Verification.

An engineer still needs to understand questions such as:

• What must the vehicle achieve?
• What Parts compose it?
• How do those Parts interact?
• How does charging work?
• Which States can the vehicle enter?
• How do we verify that the driving-range Requirement is satisfied?

Many systems-engineering ideas therefore transfer naturally from SysML v1 to SysML v2. What changes significantly is the language used to express them. That distinction is important.

An experienced SysML v1 modeler has valuable systems-modeling knowledge, but still needs to learn the architecture, concepts, semantics, and notation of SysML v2.

Is SysML v2 Backward Compatible with SysML v1?

It is better not to think about the relationship in the same way we might think about a software update that simply opens an older file and continues working.

OMG provides a dedicated SysML v1 to SysML v2 Transformation specification. Its purpose is to define a semantic translation from SysML v1.7 models into SysML v2 models and provide rules on which automated conversion can be developed. This is another indication of how significant the redesign is.

For example, the transformation defines how a SysML v1 Block maps to a SysML v2 Part Definition. Many other SysML v1 and UML concepts require their own mappings.

Migration should therefore be understood as model transformation, not simply opening a SysML v1 model in a newer version of the same language.

Should You Still Learn SysML v1?

Yes, particularly if you work with existing projects.

OMG states that SysML v1 is expected to continue to be used for several years while industry, academia, and government transition to SysML v2.

Many organizations have significant investments in:

• SysML v1 models,
• modeling methodologies,
• tools,
• integrations,
• training,
• project documentation.

Those investments will not disappear overnight.

At the same time, anyone planning the future of MBSE should now become familiar with SysML v2.

A useful strategy is: Keep using SysML v1 where your projects require it, but start learning SysML v2 as a new modeling language rather than waiting for a future migration project.

Common Misconceptions About SysML v2

“SysML v2 is just the next update to SysML v1.”

No.

This is probably the most important misconception to correct.

OMG describes SysML v2 as a ground-up redesign, and the language specification confirms the architectural break: SysML v1 is a UML Profile, while SysML v2 is specified as a metamodel extending KerML.

“SysML v2 is only textual.”

No.

SysML v2 specifies both textual and graphical notation.

“The textual notation is the real model.”

No.

Textual and graphical notation are concrete representations of the underlying SysML v2 model. The semantic model should be distinguished from its presentation.

“All SysML v1 concepts disappeared.”

No.

Many familiar systems-engineering concepts continue, but they may be expressed through different language constructs.

Our Electric Vehicle still has Requirements, Parts, Actions, States, and Interfaces even though the SysML language architecture used to model them has changed substantially.

“SysML v1 is obsolete now.”

No.

The transition will take time, and OMG explicitly anticipates continued SysML v1 use for several years.

Frequently Asked Questions

Is SysML v2 a new language?

Yes. It is more accurate to describe SysML v2 as a new generation and ground-up redesign of SysML rather than an incremental update to SysML v1. It has its own metamodel extending KerML, as well as newly specified textual and graphical syntax and semantics.

Is SysML v2 based on UML?

No.

SysML v1 is defined as a UML Profile. SysML v2 instead has a metamodel extending KerML.

What is KerML?

KerML, or Kernel Modeling Language, is an application-independent modeling language that provides the modeling and semantic foundation used by SysML v2.

Does SysML v2 still use diagrams?

Yes.

Graphical notation remains part of the SysML v2 specification. Diagrams are modeled as View Usages.

Can SysML v1 models be migrated to SysML v2?

OMG provides a normative transformation specification describing semantic translation from SysML v1.7 to SysML v2 and rules that can be used to develop automated transformations.

Real project migration may still require decisions about modeling conventions, tool-specific information, extensions, and organizational practices.

Should I learn SysML v1 or SysML v2?

If your current projects use SysML v1, SysML v1 knowledge remains important.

If you are preparing for future MBSE work, SysML v2 should now be part of your learning path. OMG calls it the next-generation Systems Modeling Language, while also expecting SysML v1 to remain in use during the transition.

Final Thoughts

The most important thing to understand about SysML v2 is not a new keyword, diagram, or notation.

It is that SysML v2 represents a new language architecture for systems modeling.

SysML v1 evolved from UML and served systems engineering successfully for many years.

SysML v2 starts from a different foundation.

It introduces KerML, a new metamodel, standardized textual notation alongside graphical notation, a systematic Definition and Usage pattern, a stronger separation between the semantic model and its Views, and standardized API services for accessing model information.

Our Electric Vehicle did not fundamentally change.

It still has a Battery, Motors, Requirements, Behaviors, Interfaces, and Verification needs.

What changed is the language infrastructure we use to describe that vehicle and connect its engineering information.

That is why the transition from SysML v1 to SysML v2 should not be approached as: “I already know SysML. I only need to learn the new syntax.”

A better approach is: “I already understand systems modeling. Now I need to learn how SysML v2 expresses it.”

That distinction makes the transition much easier to understand.

Why Trust This Article?

This article was written by Filip Stachecki, an experienced modeling trainer specializing in SysML, UML, BPMN, and Model-Based Systems Engineering.

The explanations in this article are based on the official OMG specifications for OMG SysML v2.0 Language Specification, KerML Specification, SysML v1 to SysML v2 Transformation Specification, and Systems Modeling API and Services Specification.

The objective is to explain the most important differences in clear language while remaining faithful to the semantics defined by the standards.

About eduMAX

eduMAX® provides practical, standards-based learning resources for SysML, UML, BPMN, and Model-Based Systems Engineering.

Our training materials, technical articles, and certification resources focus not only on modeling notation, but also on understanding why modeling concepts exist, how they relate, and how to apply them in real engineering projects.