SysML v2 marks a significant evolution in MBSE, designed from the ground up with greater precision, rigor, and a strong focus on interoperability and ecosystem enablement. Rather than a simple update to SysML v1, it introduces a fundamentally different architecture and modeling approach, which creates challenges for organizations with existing SysML v1 investments.
This article explores practical adoption strategies, emphasizing incremental approaches and the coexistence of SysML v1 and SysML v2 rather than encouraging a wholesale migration.
SysML v2 was designed to address the fundamental limitations of SysML v1. It provides a systems engineering native language rather than a UML retrofit, establishes a precise and coherent semantic foundation, significantly improves interoperability, and enables robust extensibility for domainspecific applications.
SysML v2 introduces foundational concepts that reshape the modeling paradigm familiar to SysML v1 users. The definition–usage approach promotes reuse and semantic consistency, while a unified behavioral framework replaces the fragmented treatment of activities, states, and interactions. Combined with tighter integration of structural and behavioral concepts and consistent application of specialization, these changes require organizations to evolve both their modeling practices and engineering skill sets.
SysML v2 introduces full textual syntax, covering everything from mathematical expressions to system architecture. This enables computationally complete models and supports a “model-as-code” approach. As a result, modelers must also master the expression language, extending their skill set beyond traditional SysML v1 modeling.
SysML v2 replaces UML stereotypes with metadata-based extensions defined in the KerML layer. Combined with libraries, these extensions provide a semantically sound, robust, and scalable foundation for defining domain-specific languages.
SysML v2 also introduces new capabilities such as variability modeling, analysis cases, and test cases. These features address longstanding systems engineering gaps identified by the SysML v1 community.
Taken together, these changes make SysML v2 adoption complex for SysML v1 users and programs, requiring substantial investment in upskilling engineers and careful migration of existing v1 models.
➡️ Read our article introducing SysML v2
SysML v2 has been designed with a strong focus on interoperability and lifecycle integration. The key interoperability use cases include:
→ Reliable model exchange across the supply chain
→ Enabling digital threads across toolchains
→ Collaborative modeling based on standard model versioning
These needs are primarily addressed through the SysML v2 API and service specifications, which form the foundation for tool integration and ultimately for defining a scalable and sustainable adoption strategy.
SysML v1 relied on UML’s XMI-based interchange, which introduced complexity and reliability issues. SysML v2 provides simpler and more resilient model exchange mechanisms based on JSON. It also enables textual interchange using the SysML v2 textual syntax, though it is less suited for round-trip scenarios due to the absence of element identifiers. To fully benefit from the SysML v2 ecosystem, tools should support both JSON-based and textual interchange.
SysML v2 brings major advancements through the standardization of the model API. It is language-agnostic and HTTP/JSON-based, enabling seamless integration of SysML v2 tools into vendor-independent digital engineering ecosystems. As a result, API compliance becomes key to enabling a toolchain ecosystem.
The SysML v2 API incorporates versioning concepts such as commits and branches, supporting consistent transactions, baselining, and parallel development. This requires SysML v2 tools to provide an underlying versioning system aligned with the API.
The SysML v2 specification also includes an OSLC-compliant API that represents model data using RDF. This supports cross-tool linking within OSLC-enabled ecosystems and enables integration with ontology-based reasoning tools.
These interoperability capabilities underpin key digital engineering scenarios, including:
→ Model exchange along the design chain
→ Lifecycle automation and data exchange via the standard API
→ Integration with analysis, verification, and code generation tools
→ Cross-tool traceability across lifecycle domains using OSLC
However, achieving these outcomes depends on how SysML V2 tools are implemented within the toolchain. Organizations must evaluate tool support for REST API integration, model interchange mechanisms, and, where relevant, OSLC-based traceability to ensure consistency across the digital thread.
Many organizations with established MBSE practices are heavily invested in SysML V1. Their ability to maintain and evolve systems depends not only on existing models but also on the surrounding MBSE methodologies, tool automations, and lifecycle integrations that enable digital threads.
As a result, introducing SysML v2 has significant implications. And defining the right adoption strategy remains the key challenge, starting with the decision to introduce SysML V2 at all or continue relying on SysML v1.
There are several use cases where introducing SysML v2 makes sense, without necessarily migrating all program assets from SysML v1. In such cases, SysML v2 can be applied selectively to areas where it provides clear value.
Here are a few examples:
New system generations: When developing a new generation of systems, consider leveraging designs from a previous generation.
Major subsystem redesigns: Needed for subsystems that require significant architectural or behavioral changes.
Model-as-code adoption: Shifting to a model-as-code paradigm using SysML v2 textual syntax to enable DevOps workflows for system models. This approach should be driven by system changes and justified by clear ROI.
Advanced analysis and simulation: Applicable to activities such as formal verification or advanced simulation, where the precise semantics of SysML v2 provide clear benefits, typically in response to design changes and supported by sufficient ROI.
Once a program is identified as a good candidate for SysML v2 introduction, careful planning is required to define scope, approach, and risks.
Although SysML v2 is intended to succeed SysML v1, it introduces a significant set of adoption considerations. And this impacts the entire SysML V1 MBSE practice across multiple dimensions. In addition, such migration always entails a risk that requires appropriate measures.
To address these risks, the DoD and INCOSE have published a set of recommendations for SysML V2 adoption1, highlighting the following key considerations:
Source: mbse:sysml_v2_transition [MBSE Wiki]
While these DoD recommendations primarily focus on migration scenarios, organizations also need to define the scope and approach for SysML v2 usage across their program based on the value it brings. This can range from targeted use in new subsystems to broader adoption across the program.
Transforming a SysML v1 model into a SysML v2 model is not a push-button process. The DoD and INCOSE guidelines outline four key steps:
It's important to note that transforming from SysML v1 to v2 typically requires significant effort and carries inherent risk.
When considering SysML V2 adoption, migrating a whole program from SysML v1 to SysML v2 requires a high level of risk tolerance.
As described earlier, migrating a v1 model to v2 can be a complex and resource-intensive process. Taking a large SysML v1 model through the entire process without partitioning does not seem scalable.
An incremental approach addresses this by maintaining part of the model in SysML v1 while transitioning selected subsets to SysML v2. This results in a hybrid setup where SysML v1 and SysML v2 models coexist within the same program.
This strategy focuses on enabling the reuse of existing SysML v1 assets alongside SysML v2 models, typically for new subsystems or components undergoing significant updates or enhancements. We refer to these as “hybrid SysML V1/V2 environments”.
Typical use cases can include:
Implementing a hybrid workflow requires careful planning across several aspects, including:
Hybrid SysML v1/v2 workflows can be implemented either within a single tool supporting both versions or across separate v1 and v2 tools. While both approaches are viable, single-tool environments supporting both versions can simplify coordination and hybrid workflows, and reduce integration overhead.
Clear boundaries between SysML v2 and legacy SysML v1 models must be defined. These can be component-based (e.g., an upgraded component modeled in v2) or layer-based (e.g., functional design in v2 and detailed software design in v1).
For model partitions selected for modernization, model migration practices discussed earlier should be applied. Large partitions can be migrated incrementally. In such cases, migration should follow a module dependency analysis, ensuring that partitions are migrated only after their dependent partitions are ready.
Interfaces must be aligned between v1 and v2 where components interact. For a new system component to be modeled in v2, the corresponding interfaces specified in v1 need to be transformed. Traceability links should be established and maintained across interface representations to ensure consistency.
Maintaining traceability across v1 and v2 models is essential. For example, when partitioning is defined across layers, cross-layer traceability is preserved within the hybrid model. This can be achieved using established cross-model traceability patterns, such as Open Services Lifecycle Collaboration (OSLC) standards, link management tools, or element proxies.
Hybrid models may require joint simulation of v1 and v2 components. This can be supported using the FMI standard, provided both tools support FMU export and execution.
When both v1 and v2 models evolve in parallel, coordinated configuration management is required to maintain consistent baselines. A single-tool environment can simplify this by managing configurations within one unified system.
Selecting a SysML v2 tool requires evaluating several key aspects to ensure alignment with your engineering workflows and interoperability requirements. It includes:
SodiusWillert focuses on interoperability solutions for MBSE and systems engineering, with a strong emphasis on digital continuity, traceability, and cross-domain integration.
SodiusWillert SECollab platform enables traceability, reporting, and review across system engineering artifacts from a wide range of lifecycle tools, including requirements management, MBSE, issue tracking, and testing tools.
Support has been recently extended to SysML v2 tools, enabling traceability with other MBSE and lifecycle tools, participating in cross-lifecycle reporting, and cross-domain reviews.
In addition to model data, SECollab also supports graphical data from various SysML v2 tools, such as IBM Rhapsody SE, Ansys System Architect, and Dassault Cameo. This enables diagram-based reviews, including annotations and the integration of visual content into lifecycle reports.
SodiusWillert OSLC connectors enable standard-based linking and traceability by exposing OSLC services to connected tools. Key tools such as Atlassian Jira, Confluence, and PTC Windchill can be connected to MBSE tools that support OSLC, including SysML v2, and tools such as IBM Rhapsody SE.
To make it easier for you to get started with SysML v2 and model-based systems engineering, we offer a wide range of training courses and consulting services. For our MBSE training course using SysML v2, we use IBM Rhapsody SE. And for MBSE using SysML, we use tools such as IBM Rhapsody or Cameo in our training courses, and you can book both courses with us in German or English.
Would you like to get an idea of whether SysML v2 is the better solution for your projects? We have a number of tools available for you free of charge via our website.
For a first overview and as a reference guide, we recommend our 📝 SysML v2 Cheat Sheet.
For a quick start to the practical application of SysML v2 using IBM Rhapsody SE, please use our 💻 Quick Start Guide. Everything you need to know for your first steps with the tool is presented here in a short and concise overview.
SysML v2 introduces significant advances in systems modeling, including improved expressiveness, precision, extensibility, and interoperability. And these capabilities create a strong incentive for adoption.
However, for organizations invested in SysML v1, adoption is not straightforward due to the fundamentally different language architecture. A successful transition requires careful planning, an incremental or hybrid adoption strategy, and thoughtful selection of modeling tools and ecosystem integrations.
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.