SysML v2
SysML v2 (Systems Modeling Language v2) is the successor to SysML v1 standardised by the OMG (Object Management Group). It is a deliberate clean break rather than an incremental update: v2 is based on its own metamodel (KerML) instead of a UML profile, places a textual notation on equal footing with the graphical one, and defines a standardised API for cross-tool model access.
No longer a UML profile: KerML
SysML v1 inherited its foundation from UML 2, and with it many software-specific concepts and workarounds that never quite fit systems engineering. SysML v2 removes this inheritance. It is built on KerML (Kernel Modeling Language), a purpose-built foundation language with formal semantics. The practical consequence: model elements have a precise, machine-interpretable meaning, which makes models more amenable to automated analysis, consistency checking and tool interoperability than their v1 counterparts.
The definition/usage principle
The entire v2 language rests on one pattern: definitions describe reusable concepts (part def Engine), usages describe their occurrence in a concrete context (part engine : Engine). This single pattern applies uniformly to structure, behaviour, requirements and constraints. It replaces a series of implicit distinctions that v1 modellers had to learn case by case, such as the difference between a block and a part property. Those who understand definitions and usages understand the construction principle of the whole language.
Textual and graphical notation
In v1, the graphical notation was the language; model interchange relied on XMI exports of varying fidelity. In v2, a textual notation stands on equal footing with the graphical one. Models can be versioned, diffed and reviewed like source code, which brings established software engineering practices (version control, merge requests, code review) to systems models. Diagrams become views on the model rather than the model itself.
Standardised API
SysML v2 specifies a standardised API for model access. Tools, scripts and analysis pipelines can read and modify models without going through a vendor-specific interface. This is a substantial step against vendor lock-in and towards vendor-independent toolchain integration, and it is one reason SysML v2 lowers the entry barrier for automation and AI assistance in MBSE.
What changes compared to v1
| SysML v1 | SysML v2 |
|---|---|
| Block | Part definition (part def) |
| Part property | Part usage (part) |
| Four historically accumulated port variants (standard port, FlowPort, ProxyPort, FullPort) | One unified port mechanism |
| Requirements as annotated model elements | Requirements as verifiable constraints |
| Binary connectors only in practice | Connections, including n-ary connections between more than two ends |
| Graphical notation plus XMI interchange | Textual and graphical notation, standardised API |
Migration from v1 to v2
Migration is a conceptual translation, not a mechanical element mapping. Some v1 constructs map cleanly, others (such as the four port types) collapse into one v2 mechanism, and some v2 concepts have no v1 equivalent at all. For new programmes, SysML v2 is considered the strategically right choice. Teams with a substantial v1 model base should plan a transition with a coexistence phase instead of a hard cut: existing v1 models remain valid and can be migrated step by step once the target method and tooling are settled.