Date
4 December 2025
Category
Blog, Collaborative Engineering, Concurrent Design, Engineering, MBSE
No comments
In the first article of this series we introduced SysML v2, its context and why it is increasingly considered as the future of model-based system engineering (MBSE). Here, we put the focus on practical implementation of this new standard, how it differs from SysML v1, the main improvements and the key concepts needed when beginning to work with it.
This post is for you if you are familiar with the main MBSE concepts but have not yet had hands-on experience with SysML. The objective is to offer a clear and concise overview to help you understand what has changed in SysML v2 and why it is important to be aware of it.
By Paloma Maestro Redondo, System Engineer and Project Manager
A good foundation for modern system engineering
MBSE provides several advantages over traditional block diagrams used in system engineering activities. In traditional practices, diagrams are created in isolation from the rest of the system and stored in specific tools or documents, making it impossible to connect multiple system views or to maintain traceability throughout the life cycle. In that context, it’s difficult to have a clear component hierarchy or to properly define interfaces.
MBSE addresses all these limitations. Now, SysML v2 aims to further improve the effectiveness of MBSE and increase its adoption.
SysML v2 is not a simple continuation of SysML v1: it’s a substantial redesign. While SysML v1 was built on top of Unified Modeling Language (UML) through a profile and several stereotypes, SysML v2 is based on a purpose-built metamodel known as Kernel Modelling Language (KerML). This new foundation allows SysML v2 to provide clearer semantics, higher consistency and stronger support for automation.
The new standard has been adapted and extended for system engineering, including a specific terminology and libraries of generally used concepts. Additionally, in the context of space system engineering, the new SysML v2 semantics can be easily mapped to the modelling concepts being used in the European space community: ECSS-E-TM-10-23 and ECSS-E-TM-10-25 standards, and CDP4-COMET or Capella models.
SysML v2 has been designed to support today’s digital engineering landscape, which demands precision, traceability and scalable model collaboration. The key objectives for the redesign have been:
- Reduce ambiguity and tool-specific behaviour
- Improve automation and enabling scriptable workflows
- Support reuse across product lines and variants
- Enable deeper integration with simulation and life cycle tools
- Make MBSE more accessible and maintainable for engineering teams.
SysML v1 vs SysML v2: what are the differences?
Several of the improvements in SysML v2 have a direct impact on modelling activities and processes: changes that engineering teams and MBSE practitioners need to be aware of.
New metamodel (KerML)
SysML v2 abandons the UML-based foundation of SysML v1 and introduces a dedicated metamodel, KerML.
Unlike v1, which relied on UML profiles and stereotypes to adapt UML for system engineering, KerML is grounded in formal semantics designed specifically for MBSE. This ensures that models are semantically precise and consistent across tools, reducing the ambiguities that often arose in v1. The new metamodel also enables a more rigorous definition of system structures, behaviour, requirements and constraints, making the language better suited for complex and safety-critical systems.

Textual and graphical notation
One of the most notable changes in SysML v2 is the addition of a standard textual modelling syntax alongside the graphical notation. While SysML v1 relied primarily on diagrams, v2 allows engineers to define models using text, which can be version-controlled, merged and diffed more effectively.
The textual syntax facilitates automation, code generation and scripting, enabling engineers to build and maintain models more efficiently. Graphical diagrams remain available for communication and documentation, but they are now aligned with the textual representation, providing a consistent view of the model across both notations.

Clearer separation of definition and usage
In SysML v1, the distinction between types (blocks) and instances was sometimes ambiguous, particularly in large models. SysML v2 introduces a clear separation between definitions (which describe the type of a component) and usages (which represent how instances of that type appear within a system). For example, a “wheel” can be defined as a part definition, while a vehicle can have four instances of that part.
The distinction between definition and usage, which is consistently applied in SysML v2, improves clarity, leads to more consistent models and makes it easier to understand complex system architectures.

4D modelling and occurrences
SysML v2 also introduces 4D modelling of the life of an object and its spatial extent. This is done with occurrences, which have a lifetime, and specifying time slices and snapshots. It is now also possible to define individuals, unique occurrences of definitions with a lifetime, that can be used for serial-numbered items, digital twins or analysis executions. Therefore, part usages should not be confused with individuals. We will explain these in more detail in future posts dedicated to cover more advanced functionalities.
Support for reuse, libraries and variants
SysML v2 introduces native support for libraries, packages and variant management. The new version is extensible by design; it includes a package import mechanism that is built into the language. This allows engineers to define reusable components, architectural patterns and model parts that can be leveraged across multiple projects or system configurations.
In this way, SysML v2 provides a more structured and reliable approach for reuse, which is especially beneficial for platform architectures or multi-variant systems. In their models, engineers are able to represent different product configurations or design alternatives, which are then considered for the trade-off analysis.
Standardised API for improved interoperability
SysML v2 includes a formal application programming interface (API) and services specification, enabling better interoperability with other tools and workflows. Models can now interact seamlessly with simulation and product line management (PLM) tools, as well as with requirements management environments, supporting automated analyses and digital engineering pipelines.
This standardisation significantly enhances interoperability, allowing organisations to implement model-driven engineering processes more effectively than was possible with SysML v1.
For further documentation on the metamodel, the language specification and formal description of the semantic translation from SysML v1 to SysML v2, you can refer to the official documentation of the latest release.
Getting ready for SysML v2
Once the core concepts are understood, starting a model in SysML v2 becomes considerably easier. Unlike SysML v1, the language encourages a more methodical approach, guiding engineers from initial scoping to detailed structural and behavioural definitions in a clear manner. Nevertheless, adopting SysML v2 requires more than just learning a new notation; it involves adapting tools, processes and team practices to make the most out of the new functionalities and improvements.
It is important to establish clear adoption and migration roadmaps to cover all necessary processes and workflows and ensure that your teams can gradually gain experience with it. These are the key points to check and assess for ensuring a smooth and effective adoption of SysML v2 for MBSE activities in organisations:
- Tooling and ecosystem readiness
- Training and capability development
- Process alignment and methodology implementation
- Integration with existing engineering workflows
- Change management and adoption plan.
Summary
SysML v2 provides meaningful improvements to MBSE, offering clearer semantics, stronger modelling constructs and better support for interoperability and integration with modern engineering workflows. By combining its dedicated metamodel, KerML, with both textual and graphical notations, it provides a more consistent and scalable foundation than SysML v1. For these reasons, the transition towards SysML v2 brings several benefits for system engineering activities and we need to ensure that the MBSE community is ready for this change.
For teams and organisations, moving to SysML v2 involves more than adopting a new syntax; it requires aligning modelling methodologies and workflows with the capabilities of the new standard. It is therefore very important to define clear roadmaps, select the right tools and offer teams the necessary training.
In future articles, we will explore additional technical aspects of SysML v2 and provide practical examples to help engineers apply these concepts effectively in real projects. To facilitate its understanding for CDP4-COMET users and system engineers involved in concurrent design activities, we will explain in these examples how the CDP4-COMET modelling elements can be transformed to the SysML v2 notation.
Do you want to learn more?
If your team or organisation is interested in MBSE, if you would like to learn more about SysML v2 to implement it in your projects, or if you simply work on the space sector and want to stay up to date with the latest digital developments that will set the course for future missions, follow Starion on LinkedIn to be updated with the new posts in this series. You can also subscribe to our SysML v2 and MBSE newsletter.
Now is the perfect time to start exploring SysML v2, test out new tools and define transition plans to adopt the new version in your modelling activities.
You can also reach out to our team for guidance and support at any time.