Was bringt uns SysML v2? Interview mit Uwe Kaufmann

Wer sich mit Systems Engineering und MBSE und SysML in Deutschland auseinandersetzt, ist Uwe Kaufmann (➜LinkedIn) sicher schon begegnet. Uwe bringt sich aktiv bei der Gesellschaft für Systems Engineering (GfSE) ein. Insbesondere leitet er die Arbeitsgruppe PLM4MBSE und die Projektgruppe „SysML Industrialization“.

Im heutigen Interview geht es um die SysML v2, die nun schon mehrere Jahre in der Mache ist, und die einen Quantensprung, verglichen mit v1, darstellt.

Neben seinen ehrenamtlichen Tätigkeiten bei der GfSE ist Uwe Kaufmann Berater, um mit Modellierung in den Bereichen Software- und Produktentwicklung einen Mehrwert zu schaffen.

SysML macht einen Versionssprung von 1 auf 2. Es soll viele Änderungen geben, was ist denn das wichtigste?

Die wichtigste Anforderung an die SysML v2 ist m.E. die Forderung nach Interoperabilität, also dem Austausch von Modellen zwischen verschiedenen Autorensystemen und eine standardisierte Schnittstelle (API), um Anfragen an Autorenwerkzeuge stellen zu können.

Die SysML v2 wird über eine exakte und eindeutige Semantik verfügen.

Voraussetzung für die Interoperabilität ist das Metamodell der SysML v2, welches die Semantik sowie die abstrakte und konkrete Syntax der Sprache definiert. Die SysML v2 wird also im Gegensatz zur SysML v1 über eine exakte und eindeutige Semantik verfügen. Man kann gar nicht stark genug betonen, wie wichtig diese Anforderung ist. Sie wird leider von vielen Anwendern zu wenig wertgeschätzt. Aber wenn es nicht klappt mit dem Datenaustausch, dann liegt das sehr häufig an dieser fehlenden Exaktheit und Eindeutigkeit. Probleme beim Modellaustausch in SysML v1 gibt es nicht, weil irgendwas an dem XMI Standard nicht stimmt, sondern weil die Werkzeuge den SysML Standard unterschiedlich interpretieren und implementieren. Mal abgesehen vom fehlenden Diagrammaustausch, aber das ist noch einmal ein anderes Thema.

Es gibt ja auch andere Modellierungssprachen – warum ist SysML besser?

Ich würde hier nicht von besser oder schlechter sprechen. Jede dieser Sprachen hat ihre Vor- und Nachteile. Capella hat schon einige Defizite der SysML v1 beseitigt, die wir jetzt erst in SysML v2 lösen werden.

Capella hat schon einige Defizite der SysML v1 beseitigt

Der Unterschied ist doch, dass die SysML eine standardisierte Sprache ist, die von unterschiedlichen Anbietern implementiert wird. Die SysML 1.4.1 ist jetzt schon ein ISO Standard (ISO 19514:2017) und auf der SysML bauen weitere (ISO- und OMG-) Standards auf, wie das Unified Architecture Framework (UAF, ehemals UPDM – „Unified Profile for DoDAF and MODAF“ aka ISO 19513:2019).

Eine standardisierte Sprache benötigen wir bspw. für die Langzeitarchivierung von Produktwissen und die Dokumentation produktdefinierender Daten.

Eine wichtige Änderung ist die Einführung einer API. Was ist die Motivation, und wie wird diese genutzt werden?

Durch eine API (Application Programming Interface) wird die Offenheit und damit die Interoperabilität gewährleistet. Fehlender Modellaustausch war und ist eines der größten Probleme im Einsatz der SysML v1.

Fehlender Modellaustausch war und ist eines der größten Probleme im Einsatz der SysML v1

Beim Erstellen des Lastenhefts (RFP) für die SysML v2 haben deshalb die Anwender dieser Anforderung großes Gewicht gegeben, daraus ist ein separater RFP für die „SysML v2 API and Services“ geworden.

Die SysML v2 hat das Potential, in einem Produktentwicklungsprozess als „single source of truth“ zu fungieren. Die Systemarchitektur eines Produkts wird sich mit Hilfe der SysML v2 – angefangen bei den Anforderungen über die funktional-logische Architektur – abbilden lassen und kann so über den gesamten Produktlebenszyklus verfügbar gemacht werden. Rückkopplungen aus allen Phasen werden sich im Systemmodell erfassen lassen, weshalb wir seit geraumer Zeit intensiv über die Integration von (SysML-unterstützten) MBSE (Model-Based Systems Engineering) und PLM (Product Lifecycle Management) diskutieren, bspw. in der GfSE-Arbeitsgruppe PLM4MBSE und der GfSE-Projektgruppe „SysML Industrialization“.

Was bedeutet die Trennung von SysML und UML für den Anwender? Da es ja eine Übergangslösung gibt, wird sich die eigenständige SysML überhaupt durchsetzen?

Konkret heißt das erst einmal, dass der Anwender von den Hemmschwellen der Softwaremodellierung befreit wird. Die Trennung von abstrakter und konkreter Syntax in der SysML v2 bedeutet unter anderem, dass die neue Systemmodellierungssprache dem Nutzer über eine komplett andere Benutzungsoberfläche als bisher angeboten werden kann.

Im Sinne der Spracharchitektur der SysML v2 heißt die Trennung von UML aber auch, dass hier etwas vom Kopf auf die Füße gestellt wird. Eine (neue) UML könnte und müsste eine domänenspezifische Sprache der SysML werden.

Es wird eine Option zur Rückwärtskompatibilität zur SysML v1 geben

Bevor jetzt Befürchtungen aufkommen, dass mit der SysML v2 alles anders und neu wird, sei hier noch angemerkt, dass es auch eine Anforderung zur Rückwärtskompatibilität zur SysML v1 gibt. Das bedeutet, für die SysML v2 wird es parallel zum eigenen Metamodell auch wieder ein UML Profil geben. Die Unterstützung der Migration von SysML v1 zu v2 wird gewissermaßen schon jetzt in der SysML v1.7 vorgenommen, indem ein nicht-normativer Annex für die präzise Semantik der SysML in die Spezifikation aufgenommen wird.

Was wird die wichtigste Anwendung der SysML v2 sein? Welche Anwendungen wären mit der SysML 1.x nicht möglich?

Die „Killer-App“ im Produktlebenszyklus ist die Komplexität (hier zu sehen im Sinne der Anzahl der Subsysteme und deren Verbindungen und Abhängigkeiten untereinander). Diese Komplexität lässt sich nur beherrschen, wenn wir unsere „Produktsysteme“ modellbasiert beschreiben, also in einer Form, die sie durch Computer interpretierbar und simulierbar machen.

Die „Killer-App“ der SysML v2 ist die Beherrschung der Komplexität

Die Komplexität im Lebenszyklus beherrschbar machen heißt aber auch, dass wir die Modelle und deren Elemente über den Lebenszyklus versionierbar und konfigurierbar einem Änderungsmanagement unterwerfen müssen. Das war mit der SysML v1 nur eingeschränkt möglich, wird aber in der v2 zum Sprachumfang im Standard gehören.

Wo finden unsere Leser weiterführende Informationen?

Im Rahmen der von mir geleiteten GfSE-Projektgruppe „SysML Industrialization“ arbeiten wir direkt im OMG Team (SST – SysML v2 Submission Team) zur Spezifikation der SysML v2 mit. Aktuell hat das SST einen ersten „Public Incremental Release“ veröffentlicht, wo man neben der Sprachspezifikation auch erste Implementierungen findet. Kommentare und Anregungen können über die Projektgruppe bzw. mich direkt kommuniziert werden. Für weiterreichende Einflussnahme nimmt die Projektgruppe gerne Use-Cases für die „Validation & Verification“ der SysML v2 auf, für weiterführende Fragen dazu stehe ich gerne zur Verfügung.

Hier geht’s zum Google Drive mit dem aktuellen Entwicklungsstand

Interessant ist sicher auch der Werdegang der SysML v2, der im OMG Wiki der RFP Working Group gut dokumentiert ist. Und nicht zuletzt geben die Lastenhefte der SysML v2 (RFP) einen fundierten Einblick in das, was wir von der zukünftigen Systemmodellierungssprache erwarten können.

Weiterführende Links:

1. SysML v2 API and Services RFP:
   http://doc.omg.org/ad/2018-6-3
2. Systems Modeling Language (SysML) v2 RFP:
   http://doc.omg.org/ad/2017-12-2
3. 2019-09 OMG SST Public incremental release of SysML v2:
   http://openmbee.org/sysml-v2-release/2019-09
4. Tim Weilkiens Blog NextGenSysML:
   https://mbse4u.com/blog/
5. SysML v2 RFP Working Group:
   http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group
6. GfSE PLM4MBSE AG – Positionspapier zur PLM und MBSE:
   http://www.gfse.de/Dokumente_Mitglieder/ag_ergebnisse/PLM4MBSE/PLM4MBSE_Position_paper_V_1_1.pdf