SysML v1 vs SysML v2: What Changed and Should You Switch?
Every MBSE team is now asking the same question: do we move to SysML v2, and if so, when? It is a fair thing to wrestle with — SysML v1 has two decades of tooling, training and existing models behind it, while SysML v2 is a clean-sheet redesign. The short answer: v2 is more precise, more interoperable, and built for systems engineering rather than borrowed from software — but the switch is a phased journey, not a flip of a switch. But before we weigh v1 against v2, it is worth being clear about what SysML is, where it came from, and why teams use it at all.
Table of Contents
First, What Is SysML?
SysML — the Systems Modeling Language — is a graphical modelling language for systems engineering. Where a document describes a system in prose, SysML describes it as a single connected model: the requirements it must meet, the parts it is built from, how those parts behave and interact, and how the whole is verified. One model, queryable and consistent, instead of a shelf of documents that drift apart. It is the notation at the heart of Model-Based Systems Engineering (MBSE).
Where Did SysML Come From?
By the early 2000s software teams had UML, the Unified Modeling Language, but systems engineers had no standard equivalent — they were modelling hardware, software, people and process with tools built for code. In 2003 the Object Management Group (OMG) and INCOSE issued a joint request for a systems modelling language. Rather than start from scratch, the response reused UML: SysML was defined as a profile of UML, subsetting the parts that fit systems work and adding what was missing, such as requirements and parametric constraints. The OMG adopted SysML v1.0 in 2007. It became the de facto standard for MBSE and was refined for nearly two decades — which is exactly why its UML roots, and their limits, matter so much to the v2 story below.
Why Use SysML?
The case for SysML is the case for MBSE itself: a model catches what documents miss. Because every requirement, component, behaviour and test lives in one connected model, a change ripples through traceably — you can see what a tweaked requirement affects instead of hoping a reviewer spots it. It gives teams a single source of truth, supports analysis and simulation rather than just description, scales to the complexity of safety- and mission-critical systems, and — being a vendor-neutral OMG standard — keeps models portable rather than locked to one tool. That is why aerospace, defence, automotive, rail and other regulated industries rely on it.
SysML v1 vs SysML v2: The Comparison
| Dimension | SysML v1 | SysML v2 |
|---|---|---|
| Foundation | A profile of UML (a software language) | A new formal metamodel, KerML |
| Notation | Diagrams only; limited text | Diagrams and a full textual notation |
| Semantics | Loose, inherited from UML | Precise and formal |
| Requirements | Modelled, but loosely tied in | Requirement definitions live inside the model |
| Verification | Largely separate | Verification cases part of the model |
| Tool interoperability | Lossy XMI export between tools | A standard API & Services spec |
| Released | v1.0 in 2007 | Final OMG adoption July 2025 |
| Best fit today | Mature tooling, existing model bases | New projects and the digital thread |
1. Foundation: UML Profile vs KerML
This is the difference everything else flows from. SysML v1 was a profile of UML — it extended a software modelling language to describe systems. That meant its meaning was defined by software semantics, with the looseness that came with them. SysML v2 is built fresh on the Kernel Modeling Language (KerML), a mathematically grounded metamodel, so every element has a precise, computable meaning. The payoff: models you can actually run analysis and verification against, not just look at.
2. Notation: Diagrams Only vs Diagrams Plus Text
In v1 you drew the model. In v2 you can also write it — a full textual notation sits alongside the diagrams, both views of the same model. A textual model diffs cleanly in version control and reviews like code, which is a genuine shift in how teams collaborate. Diagrams do not go away; they stay for the views where a picture wins. It is the difference between a drawing tool and a true model.
3. One Connected Model vs Scattered Concerns
SysML v2 unifies structure, behaviour, requirements and verification in a single model. In v1, requirements and verification often lived half-in, half-out — linked to the architecture but never truly part of it. Pulling them inside means a requirement, the part that satisfies it, and the test that proves it are traceably connected in one place.
4. Interoperability: Lossy Export vs a Standard API
Anyone who has tried to move a v1 model between tools knows the pain of XMI export. SysML v2 ships a standard API and Services specification, so tools speak a common language and the model becomes a queryable service. This is what makes a digital thread realistic and serious MBSE adoption practical at scale.
Should You Switch?
A simple rule of thumb:
| Your situation | Recommendation |
|---|---|
| Starting a new project | Begin in SysML v2 — it is where tools and skills are heading |
| Large existing v1 model base | Stay on v1 for now; pilot v2 in parallel and migrate in phases |
| Choosing or renewing tooling | Favour tools with a clear v2 roadmap |
| Training a team | Teach v2 fundamentals now; the concepts carry forward |
Whatever you decide, the direction of travel is settled. When you select tools, check the vendor roadmap for v2; the major players are all moving. For the full breakdown of what is new, see our guide to SysML v2.
Frequently Asked Questions
What is SysML?
SysML (Systems Modeling Language) is a standardised graphical modelling language for systems engineering, maintained by the OMG. It lets engineers capture a system’s requirements, structure, behaviour and verification in one connected model rather than scattered documents, and it is the core notation used in Model-Based Systems Engineering (MBSE).
What is the main difference between SysML v1 and v2?
SysML v1 is a profile of UML with diagram-only notation and loose semantics. SysML v2 is built on a new formal metamodel (KerML), adds a full textual notation, unifies structure, behaviour, requirements and verification in one model, and provides a standard API for tool interoperability.
Is SysML v2 backward compatible with v1?
Not directly — v2 is a redesign on a different metamodel, so it is not a drop-in upgrade. Vendors are providing migration tooling and paths, and the practical approach is to keep v1 for legacy models while adopting v2 on new work.
Should I learn SysML v1 or v2 in 2026?
Learn v2 if you are starting out — it is the future direction and where tools are heading. Understanding v1 still helps, since most existing models and much current tooling are v1, but new skills should centre on v2.
When was SysML v2 released?
The Object Management Group approved SysML v2 for final adoption in July 2025 and published the specification, along with KerML 1.0 and the Systems Modeling API, in September 2025.
Related guides
- SysML v2: what is new — the full breakdown
- Using SysML diagrams — the v1 diagram types
- What is MBSE? — the method behind both
- Selecting the right tools — choosing v2-ready tooling
