Systems Engineering Trends

Jede Woche Neuigkeiten aus der Welt des Systems Engineering

OMGStandards & Methoden

Panel zu SysML v2 (Teil 1): Ohne Konformität werden die Nutzer am meisten leiden

Vergangene Woche moderierte ich ein Panel mit vier bekannten Experten aus der SysML-Welt: Andreas Pollom, Daniel Siegl, Robert Karban und Vince Molnár erklärten, warum SysML-Konformität wichtig ist, wie wir sie erreichen können, was wir davon haben und wer am meisten leidet, wenn wir Konformität nicht schnell sicherstellen. Im Folgenden eine Zusammenfassung auf Deutsch. Der Artikel enthält auch die einstündige englischsprachige Aufzeichnung der Diskussion.

Entstanden ist die Idee zu diesem Thema beim TdSE 2023, wo insbesondere Daniel Siegl und ich das Thema schon intensiv bearbeitet hatten. Dank Rüdiger Maier von LieberLieber, der nicht locker gelassen hat, haben wir dann am 15. Februar 2024 dieses Panel online abhalten können.

In diesem Panel gingen wir davon aus, dass die Zuhörer bereits mit SysML v1 vertraut sind und wissen, was sich bei der SysML v2 ändern wird. Hier bei SE-Trends gibt es bereits eine Menge Material zu SysML.

Werdet Aktivisten!

Gleich Vorweg: wir haben dieses Panel veranstaltet, weil SysML v2 Konformität zur Zeit akut gefährdet ist. Falls wir nicht zeitnah eine Lösung zu diesem Problem finden, dann könnte dies zu einem großen Rückschlag für SysML im speziellen, aber auch MBSE im allgemeinen darstellen. Die Leidtragenden werden die Nutzer sein, die erwarten, dass ihre Arbeitsergebnisse interoperabel sind.

Die Leidtragenden fehlender SysML v2 Konformität werden die Nutzer sein!

Daniel Siegl (00:49:03)

Daher der Appell der Panelisten an die Leser (wer aktiv werden möchte, kann mich oder die verlinkten Panelisten über LinkedIn kontaktieren):

  • Werkzeughersteller: Konformität wird Euch Zeit und Geld sparen. Daher beteiligt Euch mit Geld, oder besser mit Personal, zum Beispiel beim Aufbau einer Test-Suite.
  • Anwender: Hofft auf das Beste, aber bereitet Euch vor auf das Schlimmste! Insbesondere: Standardisiert Eure Modellierung schon heute, verzichtet so weit wie möglich auf Anpassungen und Profiling.
  • Anwender: Fragt bei Euren Werkzeugherstellern explizit nach Konformität. Macht klar, dass das Thema für Euch einen hohen Stellenwert hat.
  • Anwender in großen Konzernen: Konformität kann sogar innerhalb derselben Organisation zum Problem werden. Konzerne wie ESA, Mercedes, thyssenkrupp können allein schon durch interne Interoperabilität von Konformität profitieren. Daher gibt es für solche Unternehmen einen Business Case und wir helfen Euch gern, diesen zu entwickeln.
  • Studierende und Lehrende: Hier ist viel Potential für interessante Master- oder Doktorarbeiten.
  • Alle Leser: Selbst kleine Geldbeträge (für Unternehmen) helfen, die Arbeit an der Konformität zu finanzieren. Ist Euer Unternehmen in der Lage, etwas beizutragen? Aktive Mitarbeit von kompetenten Personen hilft oft noch mehr als Geld.

Die Panelisten

Andreas Pollom kam 2015 als studentische Hilfskraft beim Lehrstuhl für Virtuelle Produktentwicklung (VPE) der RPTU zum ersten mal mit SysML in Berührung. Seit 2019 arbeitet er am Fraunhofer Institut für Experimentelles Software Engineering IESE an MBSE in Verbindung mit Variantenmanagement. Er hat Erfahrung in vielen Industrien gesammelt und einen eigenen Ansatz zur Integration von System Engineering entwickelt.

Robert Karban arbeitet seit langem im Bereich MBSE und seit 2007 mit SysML. Aus seiner damaligen Arbeit heraus ist vieles in den SysML v1 Standard eingeflossen, zum Beispiel Proxy Ports. Er war ebenfalls Teil des SysML Tool Submission Teams. Er ist Co-founder von OpenMBEE und arbeitete in der Vergangenheit für das NASA Jet Propulsion Laboratory und tritt in diesem Panel selbstständig auf.

Vince Molnár ist Assistenzprofessor an der Technischen Universität Budapest. Er gibt seit 2015 Schulungen zu MBSE und zu seinem Forschungsgebieten gehören auch formale Methoden, insbesondere formale Verifikation. Das macht für Ihn SysML v2 so interessant, da er die vielen Herausforderungen der SysML v1 diesbezüglich aus erster Hand kennt. Er hat direkt mit dem SysML v2 Submission Team und der Execution Working Group gearbeitet, wodurch er auch Co-Autor des Standards wurde.

Daniel Siegl ist zuständig für Business Development für LieberLieber, einem kleinen Unternehmen, das Werkzeuge zur Unterstützung von MBSE entwickelt. Er war auch Co-Vorsitzender einer SysML-Gruppe, die an einem Stanard für den Modellaustausch auf Basis von SysML v1 für die Automobilindustrie zu etablieren. Er kennt daher aus erster Hand die Notwendigkeit und Herausforderungen bezüglich Konformität. Auch aus der Sicht eines kleinen Werkzeugherstellers versteht er die Bedeutung von Konformität. Er ist weiterhin stellvertretender Direktor für Standards bei INCOSE.

SysML v2 Konformität: Jetzt anschauen

Die Diskussion dauerte ca. eine Stunde und ist hier in voller Länge verfügbar. Wie immer bei SE-Trends weiter unten eine Zusammenfassung der wichtigsten Erkenntnisse.

Was ist SysML v2 Konformität? (6:37)

Vince gab einen Überblick über die Ursprünge der SysML v2 Konformität, die bereits im SysML v2 RFP mit einer entsprechenden Anforderung eingefordert wurde. Daher musste Standard von Anfang an Konformitätskriterien definieren, die in fünf Bereiche fallen:

  • Abstrakte Syntax
  • Konkrete Syntax
  • Semantische Conformance
  • Modeling Exchange
  • Domain Library

Das Team von Vince hat noch weitere Kriterien gesammelt, die über diese fünf Bereiche hinausgehen.

SysML v1 hat es nicht geschafft, Konformität in der Interoperabilität zu realisieren. Test-Suiten würden helfen, dies von Anfang an für SysML v2 zu realisieren.

Robert Karban

Robert ergänzte dies mit der Perspektive eines Anwenders, der bereits 20 Jahre Erfahrung mit SysML v1 Konformität gesammelt hat. Eines der größten Probleme mit SysML v1 war Interoperabilität, daher würde er sich dort auch den größten Nutzen erhoffen. Robert wünschte sich Test-Suiten, wie es die OMG teilweise bei anderen Standards macht.

Aus Anwendersicht sieht er mehrere Dimensionen. Insbesondere wies er darauf hin, dass Anwender den Standard in der Regel nicht voll ausschöpfen und daher eine Partitionierung sinnvoll ist. Auch Werkzeughersteller implementieren nicht immer den vollen Standard (insbesondere kleine Hersteller). Daher ist für den Anwender die Konformität der konkret genutzten Teilmenge des Standards relevant. Gerade für kleine Werkzeughersteller wäre es hilfreich, wenn es verschiedene Subsets des Standards geben würde, die sich an den Nutzungsszenarios orientieren. Zum Beispiel ist Variabilität ein Aspekt, den nicht unbedingt alle Anwender brauchen. Robert machte ein paar konkrete Vorschläge:

  • Verhalten und Struktur in der textuellen und grafischen Notation
  • Variabilität
  • API

Robert wies auch darauf hin, dass wir bei SysML v1 die Interoperabilität der Diagramme sowieso gleich vergessen können. Das ist noch mal eine ganz andere Baustelle, die wir bei der SysML v1 sicher nicht mehr lösen werden.

Manche Hersteller behaupten, sie hätten Interoperabilität, nur weil die SysML v2 Syntaxhervorhebung funktioniert. Das ist noch keine SysML v2 Konformität, das ist lediglich ein Teil bezüglich der textuellen Repräsentation!

Daniel Siegl

Daniel Siegl gab das konkrete Beispiel, dass manche Hersteller ein Werkzeug mit Syntax-Highlighting bereits als „konform“ bezeichnen. Das ist natürlich keine Konformität des SysML v2 Standards. Dieses konkrete Beispiel zeigt, wie wichtig es ist, mehrere Konformitäts-Level zu haben.

Andreas unterstrich die Dringlichkeit von Interoperabilität, indem er Teams zitierte, die noch nicht mal innerhalb der eigenen Organisation in der Lage waren, Modelle untereinander auszutauschen. Dabei ging es natürlich noch nicht um SysML v2. Daniel bestätigte dies. Er wies darauf hin, dass Profiling die Interoperabilität auch zwischen denselben Werkzeugen zerstören kann.

Methodik oder Sprache—Was ist das Problem?

An dieser Stelle kam die Frage auf, ob Interoperabilität durch die SysML selbst verursacht wird oder durch die verwendete Methodik. Andreas sah hier einen 50:50-Split. Hinzu kommt auch noch, dass viele Werkzeuge kein formal korrektes SysML-Modell einfordern. Das kann dazu führen, dass Teams, bewusst oder unbewusst, mit nicht standardkonformen Modellen arbeiten.

Auch das bedeutet, dass eine klare Abgrenzung zwischen Sprache und Methodik notwendig ist, um die Konformität sicherzustellen.

Nächste Woche: Wie kommen wir zur Konformität und was passiert, wenn wir es nicht schaffen?

Nachdem wir nun von den Panelisten gehört haben, was wir mit SysML v2 Konformität meinen, werden wir uns nächste Woche der eigentlichen Frage widmen: Was bedeutet SysML v2 Konformität (oder deren Fehlen) für die Anwender? Wie haben andere Standards Konformität geschaffen? Und was können wir von den Standards, die Konformitäts-Probleme haben, lernen?

Wer es jetzt schon wissen möchte, kann sich die Aufnahme des Panels heute schon anschauen. Alle anderen: Den Artikel nächste Woche nicht verpassen!

Michael Jastram

Creator and Author of SE-Trends