SysML v2: What’s New and Why It Matters
For twenty years, model-based systems engineering ran on SysML v1 — a language that was, honestly, a profile bolted onto UML: a software notation pressed into service for whole systems. It worked, but it creaked. SysML v2 is the ground-up rebuild — a systems modelling language with its own formal foundation, a first-class textual notation alongside the diagrams, and a standard API — finally designed for systems engineering rather than borrowed from software.
This is not a point release. The Object Management Group gave SysML v2 final adoption in July 2025 and published it that September. If you do model-based systems engineering, this is the biggest change to your toolkit in two decades. Here is what actually changed — with the detail that matters.
Table of Contents
SysML v2 at a Glance: The Key Things to Know
| Element | What you need to know |
|---|---|
| Foundation | Built on a new formal metamodel, KerML — not UML. Meaning is defined precisely, not inherited from software. |
| Notation | Graphical and textual. For the first time, text is a first-class way to author a model, not just a side note. |
| Four pillars | Structure, behaviour, requirements and verification are unified in one model, not separate tools. |
| Standard API | A built-in API & Services standard so tools interoperate — the backbone of a real digital thread. |
| Precision | Formal semantics mean far less ambiguity; a model means one thing, not several. |
| Status | OMG final adoption July 2025, published September 2025, with KerML 1.0 and the Systems Modeling API. |
Why SysML v1 Had to Go
SysML v1 was a UML profile, and that carried a hidden tax. Because its meaning was borrowed from a software language, two engineers — or two tools — could read the same model slightly differently. Models were painful to exchange between tools, the notation was diagram-only, and the semantics were loose enough that “valid SysML” did not always mean “unambiguous”. As the digital thread became the goal, those cracks turned into real friction.
Built on KerML, Not UML
The heart of SysML v2 is the Kernel Modeling Language (KerML) — a new, mathematically grounded metamodel that SysML v2 sits on top of. In plain terms, the language now has a precise definition of what every element means, instead of inheriting fuzzy software semantics. That precision is what makes a model trustworthy enough to drive analysis, simulation, and verification automatically — the model is not just a picture, it is computable.
The Four Pillars: One Model, Not Four Tools
SysML v2 organises a system model around four concerns that used to live in separate places:
| Pillar | What it captures |
|---|---|
| Structure | Parts, ports and connections — the system architecture |
| Behaviour | Actions, states and flows — what the system does over time |
| Requirements | Requirement definitions linked directly into the model, closing the gap requirements tools and models used to leave open |
| Verification | Analysis and verification cases that check the model against those requirements |
Pulling requirements and verification inside the model is the quiet headline here: it means a requirement, the part that satisfies it, and the test that proves it are all traceably linked in one place, not stitched together across tools.
Models You Can Write: The Textual Notation
In v1 you drew the model. In v2 you can also write it. Here is a vehicle’s structure expressed in SysML v2 text:
part def Vehicle {
part wheels : Wheel[4];
part sensors : ObstacleSensor[2..*];
part cargo : CargoBay[0..1];
}That reads almost like plain engineering. A Vehicle has exactly four wheels, two or more obstacle sensors, and at most one cargo bay — the [4] and [2..*] are multiplicities. Note the split between a definition (part def, the blueprint) and a usage (the parts you instantiate inside it) — the definition-versus-usage pattern is the spine of the whole language.
Why does text matter? A textual model diffs cleanly in version control, reviews like code in a pull request, and lets engineers move fast without wrestling a diagram editor — while diagrams stay for the views where a picture genuinely wins. It is “systems as code”, and it changes how teams collaborate.
The API: SysML v2 and the Digital Thread
The deepest change is the standard API and Services specification. In v1, getting a model out of one tool and into another was a lossy export. In v2, tools speak a common API, so the model becomes a queryable service other tools connect to. That is exactly what a digital-thread approach needs: one authoritative model that requirements, simulation, traceability and verification all reach into, instead of a heap of disconnected files. It is also what makes serious MBSE adoption finally practical at scale.
What It Means for You: Migration
If you are starting fresh, learn v2 — it is where the tools, jobs and skills are heading. If you already have a body of v1 models, the sensible path is phased: audit your existing assets, run training and a pilot project, then transition gradually while keeping v1 artefacts for legacy systems. When you choose tools, favour ones with a clear v2 roadmap — PTC, Siemens and the Cameo lineage are all moving. The direction is set: the next decade of MBSE — including methods like OOSEM and Harmony — is being rebuilt on SysML v2.
Frequently Asked Questions
What is SysML v2?
SysML v2 is the next-generation Systems Modeling Language for model-based systems engineering. Unlike v1, which was a profile of UML, v2 is built on a new formal metamodel (KerML), offers both textual and graphical notation, unifies structure, behaviour, requirements and verification in one model, and includes a standard API. OMG approved it for final adoption in July 2025.
What is the difference between SysML v1 and v2?
SysML v1 is a UML profile with diagram-only notation and loose semantics; SysML v2 is built on the precise KerML metamodel, adds a first-class textual notation, unifies the four modelling pillars, and provides a standard API so tools interoperate. v2 is more precise, more interoperable, and designed for systems engineering rather than borrowed from software.
Does SysML v2 have a textual notation?
Yes. SysML v2 introduces a full textual notation alongside diagrams, so a model can be written as text (for example, a part def with nested parts and multiplicities) as well as drawn. Both are views of the same underlying model, and the text can be version-controlled and reviewed like code.
Is SysML v2 released, and should I migrate?
Yes — OMG approved final adoption in July 2025 and published the specification that September. You do not need to migrate overnight: learn v2 for new projects and move existing v1 models across in a phased way as vendor tooling and migration paths mature.
Related guides
- Using SysML diagrams — the nine v1 diagram types
- What is MBSE? — the method SysML serves
- Digital twins & the digital thread — where the model connects
- The systems engineering V-model — the lifecycle you model
- Selecting the right tools — choosing v2-capable tooling
