SysML v2

SysML v2 (Systems Modeling Language v2) ist der von der OMG (Object Management Group) standardisierte Nachfolger von SysML v1. Es handelt sich um einen bewussten Neuanfang, nicht um ein inkrementelles Update: v2 basiert auf einem eigenen Metamodell (KerML) statt auf einem UML-Profil, stellt eine textuelle Notation gleichberechtigt neben die grafische und definiert eine standardisierte API für den werkzeugübergreifenden Modellzugriff.

Kein UML-Profil mehr: KerML

SysML v1 hat sein Fundament von der UML 2 geerbt, und mit ihm viele softwarespezifische Konzepte und Behelfslösungen, die zum Systems Engineering nie richtig passten. SysML v2 legt dieses Erbe ab. Die Sprache baut auf KerML (Kernel Modeling Language) auf, einer eigens entworfenen Basissprache mit formaler Semantik. Die praktische Konsequenz: Modellelemente haben eine präzise, maschinell interpretierbare Bedeutung. Das macht Modelle deutlich besser zugänglich für automatisierte Analysen, Konsistenzprüfungen und Werkzeug-Interoperabilität als ihre v1-Gegenstücke.

Das Definition/Usage-Prinzip

Die gesamte v2-Sprache ruht auf einem Muster: Definitionen beschreiben wiederverwendbare Konzepte (part def Engine), Verwendungen (Usages) beschreiben ihr Vorkommen in einem konkreten Kontext (part engine : Engine). Dieses eine Muster gilt einheitlich für Struktur, Verhalten, Anforderungen und Constraints. Es ersetzt eine Reihe impliziter Unterscheidungen, die v1-Modellierer fallweise lernen mussten, etwa den Unterschied zwischen einem Block und einer Part Property. Wer Definitionen und Verwendungen verstanden hat, versteht das Konstruktionsprinzip der ganzen Sprache.

Textuelle und grafische Notation

In v1 war die grafische Notation die Sprache; der Modellaustausch lief über XMI-Exporte von schwankender Qualität. In v2 steht eine textuelle Notation gleichberechtigt neben der grafischen. Modelle lassen sich wie Quellcode versionieren, diffen und reviewen. Damit halten etablierte Praktiken der Softwareentwicklung (Versionskontrolle, Merge Requests, Code Review) Einzug in Systemmodelle. Diagramme werden zu Sichten auf das Modell statt das Modell selbst zu sein.

Standardisierte API

SysML v2 spezifiziert eine standardisierte API für den Modellzugriff. Werkzeuge, Skripte und Analyse-Pipelines können Modelle lesen und ändern, ohne über eine herstellerspezifische Schnittstelle zu gehen. Das ist ein wesentlicher Schritt gegen Vendor-Lock-in und für die herstellerunabhängige Toolchain-Integration. Zugleich senkt die API die Einstiegshürde für Automatisierung und KI-Unterstützung im MBSE.

Was sich gegenüber v1 ändert

SysML v1	SysML v2
Block	Part Definition (`part def`)
Part Property	Part Usage (`part`)
Vier historisch angesammelte Port-Varianten (Standard-Port, FlowPort, ProxyPort, FullPort)	Ein vereinheitlichter Port-Mechanismus
Anforderungen als annotierte Modellelemente	Anforderungen als überprüfbare Constraints
Praktisch nur binäre Konnektoren	Verbindungen, einschließlich n-ärer Verbindungen zwischen mehr als zwei Enden
Grafische Notation plus XMI-Austausch	Textuelle und grafische Notation, standardisierte API

Migration von v1 zu v2

Die Migration ist eine konzeptionelle Übersetzung, keine mechanische Element-Abbildung. Manche v1-Konstrukte lassen sich sauber übertragen, andere (etwa die vier Port-Typen) gehen in einem einzigen v2-Mechanismus auf, und manche v2-Konzepte haben gar kein v1-Gegenstück. Für neue Programme gilt SysML v2 als die strategisch richtige Wahl. Teams mit substanziellem v1-Modellbestand planen besser einen Übergang mit Koexistenzphase statt eines harten Schnitts: Bestehende v1-Modelle bleiben gültig und lassen sich schrittweise migrieren, sobald Zielmethodik und Tooling geklärt sind.

Häufige Fragen

Was ist der Unterschied zwischen SysML v1 und SysML v2?

SysML v2 ist kein inkrementelles Update, sondern ein bewusster Neuanfang. Die Sprache ersetzt das UML-Profil von v1 durch ein eigenes Metamodell (KerML), baut vollständig auf einem Muster auf (Definitionen und Verwendungen), stellt eine textuelle Notation gleichberechtigt neben die grafische und definiert eine standardisierte API für den werkzeugübergreifenden Modellzugriff. Mehrere v1-Konstrukte, etwa die vier historisch angesammelten Port-Varianten, sind in v2 zu je einem Mechanismus vereinheitlicht.

Lassen sich bestehende SysML-v1-Modelle nach SysML v2 migrieren?

Ja, aber nicht als mechanische Eins-zu-eins-Abbildung. Weil v2 Kernkonzepte neu strukturiert, ist die Migration eine konzeptionelle Übersetzung: Blöcke werden zu Part Definitions, die vier v1-Port-Typen gehen in einem vereinheitlichten Port-Mechanismus auf, und manche v2-Konzepte wie n-äre Verbindungen haben gar kein v1-Gegenstück. Teams sollten eine Übergangsphase einplanen, in der v1- und v2-Modelle koexistieren.

Sollten neue Projekte mit SysML v1 oder SysML v2 starten?

Für neue Programme gilt SysML v2 als die strategisch richtige Wahl: Die Sprache räumt bekannte v1-Schwächen aus, und die standardisierte API reduziert Vendor-Lock-in. Teams mit großem v1-Modellbestand und etablierter Werkzeugkette müssen nichts überstürzen; ein geplanter Übergang mit Koexistenzphase ist meist wirtschaftlicher als ein harter Schnitt.

Was ist KerML?

KerML (Kernel Modeling Language) ist die formale Basissprache, auf der SysML v2 aufbaut. Sie definiert die Kernkonzepte und die formale Semantik, die SysML v2 für das Systems Engineering wiederverwendet und spezialisiert. Weil KerML eigens dafür entworfen wurde statt von der UML geerbt zu sein, haben SysML-v2-Modelle eine präzise, maschinell interpretierbare Bedeutung.

Fachlich geprüft von Benjamin Alders, Principal Systems Engineer am 14. August 2026