SysML v2 is built on a different foundation than SysML v1. For engineering teams, that difference directly affects how models are defined, how behavior is specified, how tools integrate, and how teams collaborate. This article focuses on what actually changes for engineering teams when moving from SysML v1 to SysML v2. It includes modeling practices, interoperability, extensibility, and day-to-day workflows.
SysML v1 was built as an extension of UML. Over the years, teams were able to establish mature MBSE practices on v1. But inheriting UML’s metamodels also meant carrying some of UML’s architectural choices. Activities, states, and interactions were each based on different semantic models and, therefore, not well integrated. In practice, experienced teams have learned to work around it, but it has introduced room for interpretation gaps, particularly across teams and suppliers, or when onboarding new engineers on a program.
SysML v2 is built on KerML, a modeling language with formal semantics. States are now defined based on actions, and behavioral concepts share a unified foundation. As a result, the language provides greater consistency among the various modeling frameworks.
More predictable model behavior, fewer interpretation gapsModel behavior becomes more predictable across diagram types and engineering phases. In SyML v1, modeling methodologies such as IBM Harmony or MagicGrid rely on different behavioral diagrams at different stages: for example, starting with activity diagrams, then moving to sequence diagrams and state machines during logical designs. Reconciling these views can be challenging and often leads to interpretation gaps. With SysML v2, behavioral concepts share a unified semantic foundation, which reduces these inconsistencies and makes models easier to understand and validate across teams |
SysML v1 was designed around graphical notation, which made it accessible and widely adopted over the years. However, diagrams do not expose all aspects of the model. Important details are often stored in tool-specific property sheets, and behavioral logic, such as algorithms or action bodies, is typically expressed in text but not standardized across tools. As a result, models can be expressive, but not always fully machine-processable
SysML v2 introduces full textual syntax, from low-level expressions up to system architecture. This means that a V2 model can be represented and processed in a standardized textual form, exposing the complete model definition rather than only selected graphical views.
Diagrams remain available, but the textual notation provides a complete representation of the model, with no hidden properties. Structures, behaviors, and constraints are defined explicitly in text, while diagrams display selected elements of the model for a specific purpose.
Model-as-code approach: what changes for engineering teams?You can now write and edit models in a structured textual format, manage them in standard version control systems (e.g., Git), and run standard textual diff and merge tools on model files. Validation, consistency checks, and code generation become possible directly from the model. If engineering teams are familiar with software development workflows, they may find model-as-code practices and integration with version control systems relatively natural. However, SysML v2 does not replace graphical modeling. Teams can still author models primarily through diagrams, while textual syntax is mainly used for low-level expressions, calculations, or workflows that benefit from text-based editing and automation. Adopting a model-as-a-code approach, therefore, remains a choice rather than a requirement, although it opens the door to tighter integration with DevOps workflows and automation practices. |
In SysML v1, extending the language usually means using stereotypes. Yet stereotype implementation varies across tools, and extensions that work in one toolchain may not transfer cleanly to another. You end up with customizations that are hard to maintain and to share across programs or suppliers.
SysML v2 replaces stereotypes with metadata-based extensions defined in KerML. It also introduces a library mechanism allowing these extensions to be packaged and reused across models. For instance, a domain-specific extension defined once can be easily reused across projects, regardless of the tool used.
More consistency and supplier collaborationFor programs in regulated industries where traceability and consistency are non-negotiable, SysML v2 reduces the risks related to tool-specific customization mechanisms. In SysML v1, stereotypes can be exchanged, but extensions often rely on tool-specific APIs or implementation choices, which can make automation and cross-tool reuse difficult. SysML v2 improves this by enabling extensions to work through the standard API, making them easier to use consistently across compliant tools.
Supplier collaboration is also affected. In SysML v1, when a supplier uses a different tool, extensions or related automation may need to be adapted to that tool environment. In SysML v2, domain-specific extensions can be defined in a more standardized way and accessed through the standard API, reducing friction in multi-supplier programs.
Another important difference is behavioral logic. In SysML v1, action language was not largely standardized, and ALF (Action Language for Foundational UML) adoption remains limited. This made action code difficult to exchange reliably across tools. In SysML v2, textual syntax and definitions are part of the standard, improving portability of both model structure and behavioral intent. |
SysML v2 adds native support for several capabilities that teams typically handle through conventions or external tooling in SysML v1.
Variability modeling is now built into the language. In SysML v1, Product Line engineering (PLE) approaches were typically implemented through proprietary or ad hoc techniques, which limited interoperability across tools and organizations. In SysML v2, variation points and variants can be defined directly in the system model, with formal constraints controlling valid selections. Dedicated variability management tools such as pure::variants can also integrate with SysML v2 models in a more standardized way, leveraging native variation concepts rather than relying on proprietary integration mechanisms.
The concept of use cases has also been generalized into three types of cases:
This provides a more structured and standardized way to capture engineering intent directly in the model, including analysis and validation scenarios. As these concepts are now part of the language, they can be consistently interpreted across tools, contributing to a more mature model-based engineering value chain.
For example, enabling requirements to be evaluated and verified directly against the system model. A constraint can specify that the total weight of a subsystem must not exceed a defined threshold, and this condition can be assessed as part of the model itself.
Variability, analysis, and traceability in practiceProduct line engineering can now be supported directly within the system model using standardized concepts. While dedicated variability management tools still play a role, SysML v2 enables variability information to remain consistent and interoperable across models, tools, and teams, including when such tools are used. Trade studies and validation scenarios can be captured directly in the model and linked to the relevant system elements. As these concepts are now standardized, they can be consistently interpreted and reused across tools, contributing to a more mature model-based engineering value chain. Formal constraints create a tighter, more traceable connection between requirements and design, enabling requirements to be evaluated and verified directly against the system model. Requirements are no longer just textual specifications but become executable elements that can be assessed as part of the model. For teams achieving complex system analysis or managing multiple product configurations, there are more than just surface improvements. They help reduce the manual overhead of keeping models aligned with engineering decisions. |
In SysML v1, connecting a modeling tool to a requirements management tool, a PLM system, or other engineering platforms typically requires custom development. Integration is possible, but it depends on vendor-specific connectors or bespoke implementation effort that varies from one toolchain to another.
SysML v2 addresses this through three mechanisms defined in the specification itself:
From bespoke integrations to standardized, tool-agnostic integrationWith SysML v1, integrating modeling tools into a broader engineering ecosystem typically requires custom, tool-specific connectors. Each integration must be developed and maintained independently, which limits scalability and increases complexity. SysML v2 introduces a standardized approach to integration through its API and data exchange mechanisms. As a result, SysML v2 models can be connected to requirements, PLM, and testing tools consistently, regardless of the modeling tool used. Integrations are still needed, but they can now rely on a standardized SysML v2 API rather than tool-specific interfaces. This enables a more scalable and predictable integration strategy across the engineering toolchain. This standardization strengthens the role of system models within a digital thread, making them easier to integrate across domains and organizations, while reducing manual effort and the risk of inconsistencies across tools. |
️
➡️ At SodiusWillert, the SECollab platform supports this kind of integration, including traceability, reporting, and review across SysML v2 tools, requirements management systems, and testing tools, along with diagram-based reviews and cross-lifecycle reporting.
SysML v2 standardizes versioning concepts, including commits, branches, and baselines, directly in the API specification. In v1, versioning support varies significantly between tools. For instance, some tools offer built-in branching capabilities, while others rely entirely on external version systems or file-based exports.
In v2, any compliant tool implements the same versioning model, which makes configuration management more consistent and predictable across toolchains.
Parallel development and shared baselines across teamsFor distributed teams or programs involving multiple suppliers, this removes a recurring source of uncertainty. Teams can work on parallel branches, merge changes in a controlled way, and establish shared baselines at program milestones, all within a standardized framework rather than a tool-specific one. This also makes it easier to coordinate model updates across organizational boundaries: for example, when an integrator and a supplier need to work on overlapping parts of the same model without overwriting each other's changes. |
Even if SysML v2 brings many enhancements, it does not replace the need for a clear MBSE methodology, modeling guidelines, and governance. Indeed, the new capabilities and improvements introduced by SysML v2 do not mean that you’ll automatically produce better models. Teams that have struggled with consistency in SysML v1 will face the same challenges in v2 if the underlying process gaps are not properly addressed.
How well creating effective models still depends on the discipline and structure around it. Training, modeling, guidelines, and governance processes need to evolve alongside the tool transition. Without this foundation in place, even the most expressive language will not deliver its full potential. So, the transition to SysML v2 could be an opportunity to revisit those foundations.
SysML v1 will remain in use for years. Many programs have mature models, established toolchains, and stable processes around them. For those programs, the question is more about whether there is a clear engineering justification to start a transition to SysML v2. Where no clear benefit can be identified, preserving a stable and effective MBSE practice is the more reasonable choice.
On the other hand, SysML v2 introduces capabilities that are simply not available in v1, and the tooling ecosystem will continue to evolve around this new standard.
For organizations planning new programs or major system evolutions, starting with SysML v2 is worth serious consideration. Typical entry points include new system developments, major subsystem redesigns, and initiatives where a model-as-code approach would bring clear value.
And many organizations will run both versions in parallel for some time, applying SysML v2 where it brings the most value, while maintaining existing v1 investments.
In practice, the real challenge is not about evaluating whether you should adopt SysML v2, but more on how to introduce it with managed risk. The key is to adopt an incremental approach and ensure robust interoperability with existing engineering tools and processes.
Eran Gery, Technical Fellow at SodiusWillert
➡️ To learn more about these topics, read our practical guide to SysML v2 adoption, written by our technical fellow and MBSE expert, Eran Gery
➡️ And if your team is preparing for this transition, SodiusWillert provides SysML v2 training courses using IBM Rhapsody SE, available in English and in German.