Systems Engineering Trends

Jede Woche Neuigkeiten aus der Welt des Systems Engineering

OMGStandards & Methoden

Panel zu SysML v2 (Teil 2): Wie können wir Konformität erreichen?

Dies ist der zweite Teil des Panels zur SysML-Konformität. Letzte Woche wurden die Panelisten vorgestellt (Teil 1). Weiterhin haben wir geklärt, worum es bei SysML-Konformität überhaupt geht und was der Scope der Konformität ist. Klar ist: Die Konformität von SysML v2 ist gefährdet. Daher geht es diesmal um die Vorschläge der Panelisten, wie wir Konformität erreichen können.

Hier nun der zweite Teil mit Andreas Pollom, Daniel Siegl, Robert Karban und Vince Molnár.

Wie können wir SysML v2 Konformität erreichen?

Grundsätzlich ist SysML v2 bezüglich Konformität auf einem guten Weg: Schließlich wurde Konformität von Anfang an über eine Anforderung im im SysML v2 RFP eingefordert. Interessierte können auf der OMG-Webseite die Aktivitäten der SysML v2 RFP Working Group verfolgen und sich auch beteiligen.

Die Panelisten untersuchten nun die Frage, warum trotzdem SysML v2 Konformität in Gefahr ist. Dabei suchten sie nach Inspiration von anderen Standards, wie BPMN oder ReqIF.

1.Wir müssen Test Suites für Werkzeughersteller und Anwender bereitstellen.

Die Panelisten waren sich alle einig, dass eine Test-Suite einen enormen Wert für SysML v2 Konformität haben würde. Der wichtigste Stakeholder für so eine Test-Suite wären die Werkzeughersteller. Idealerweise würden die Hersteller auf Tests zugreifen können, bevor diese überhaupt mit der Entwicklung beginnen. Etablierte Hersteller arbeiten bereits an Werkzeugen, doch für neue Unternehmen könnte dies extrem wertvoll sein.

Die Nutzer profitieren von einer Testsuite indirekt am meisten, da dadurch bessere Interoperabilität gewährleistet werden würde. Insofern hier noch einmal der Aufruf an die SysML-Nutzer, Druck auf die Hersteller auszuüben.

Konformität von was?

Doch worauf soll sich die Konformität überhaupt beziehen? Dazu hatten sich die Panelisten letzte Woche schon geäußert. Insbesondere kleine Hersteller werden alle Aspekte der SysML v2 abdecken können und nur wenige Nutzer werden alle Features von SysML v2 nutzen. Daher brauchen wir verschiedene Kategorien von Konformität und möglicherweise auch Stufen.

2.Wir brauchen Konformitätsbereiche und -stufen

So wären zum Beispiel API und Textnotation eigene Kategorien. Ebenso könnte es Abstufungen geben, zum Beispiel eine Testsuite für eine minimale Implementierung der API.

Verwertbare Ergebnisse erstellen

Es gibt bereits eine Testsuite für die Pilotimplementierung, die von Ed Seidewitz geschrieben wurde und diese stellt auch einen sinnvollen Startpunkt für Interessierte dar. Die Gruppe von Vince stellt bereits Überlegungen an, wie eine systematische Nutzung dieser Tests aussehen könnte. Darüberhinaus hat seine Gruppe Ideen, wie man Tests generieren könnte.

Die Anzahl der Fragen zu SysML v2, die Vince erhält, bestätigen das Interesse im Markt. Vince hat in seinem Umfeld auch viele Menschen, die bereit sind, loszulegen. Es fehlt an Mitgliedern des Kernteams, diese Aktivitäten zu koordinieren.

Damit wir Artefakte wie Test-Suiten überhaupt verwerten können, müssen wir diese erst schaffen. Daher noch mal der Aufruf zur Mitarbeit. Hier ist auch genug Material für Master- oder Doktorarbeiten.

Vince Molnár, 37:30

Gütesiegel oder Zertifizierung

Robert wies darauf hin, dass wir zwar SysML-Zertifizierungen für Anwender haben, jedoch nicht für die Sprache selbst!. Vince erklärte, dass die OMG in der Regel selbst keine Zertifizierungsprogramme für Werkzeughersteller aufsetzt. Allerdings muss so etwas ja nicht durch die OMG geschehen. Daniel schlug INCOSE als ein Organisation vor, die so ein Programm leiten könnte. Als weiteres Beispiel wurde auch der ReqIF-Standard erwähnt, für den ebenfalls eine externe Organisation (ProSTEP ivip) einen Implementations-Leitfaden erstellt hatte.

3.Eine Zertifizierung von Werkzeugen könnte drastisch die Interoperabilität erhöhen, aber nur, wenn die Hersteller sich darauf einlassen.

Solche Aktivitäten sind nicht immer im Sinne der Werkzeughersteller, die sich zumindest in der Vergangenheit gegen Interoperabilität gewehrt hatten, bspw. bezüglich PLM-Interoperabilität.

Spaß mit SysML v2 Konformität haben

Ein zumindest für mich neue Idee kam von Daniel von der BPMN-Welt: Die BPMN Model Interchange Working Group (BPMN MIWG) hat es geschafft, eine aktive Gemeinschaft aufzubauen, in der auch die Werkzeughersteller sehr aktiv sind. Auf der Webseite der Gruppe befindet sich unter anderem eine Tabelle mit dem Teststatus der verschiedenen Werkzeuge.

4.Eine aktive Gemeinschaft mit den wichtigen Stakeholdern sorgt für gute Kommunikation und freundlichen Wettbewerb.

Die Gruppe trifft sich regelmäßig online zu Interoperabilität-Demos mit guter Stimmung und viel Engagement.

Transformation von SysML v1 nach v2 erst später

Wir müssen sehr vorsichtig sein, unsere SysML v2-Welt nicht durch „dreckige“ Daten aus der SysML v1-Welt zu „verschmutzen“

Daniel Siegl, 42:12

Robert wies darauf hin, dass die Transformation von SysML v1 nach v2 ebenfalls großes Potential für das Thema Konformität haben könnte. Sowohl Vince als auch Daniel rieten hier zur Vorsicht: Zwar können wir die Validität von transformiertem SysML v2 überprüfen und sollten das auch tun. Aber zum einen fehlen hier realistische Beispiele, zum anderen sollten wir auf keinen Fall mit einer Transformation beginnen, bevor wir nicht die Möglichkeit haben, das Ergebnis wirklich ordentlich zu validieren.

5.Transformation von Modellen sollte erst dann in Erwägung gezogen werden, wenn die Validierung des Ergebnisses gewährleistet werden kann.

Enabler für offene Modellbibliothek

Erfolg bei SysML-Konformität würde viele positive Auswirkungen haben und insbesondere zur Verbreitung von SysML und MBSE beitragen. Eine Idee hatte die Gruppe jedoch etwas ausführlicher diskutiert. Konformität wäre ein Wegbereiter für Bibliotheken von Modellkomponenten, so wie wir es auch schon aus der Softwareentwicklung kennen.

Robert sprach das Thema an im Kontext von Konfigurationsmanagement mit Branching und Merging, wie es in Softwarerepositories (git, Subversion, etc.) ja schon seit Jahrzehnten praktiziert wird. Da Daniel’s Unternehmen LieberLieber eine Lösung für Modell-Versionierung entwickelt hat, könnte er hier eine Menge beitragen.

Insbesondere wünschten sich alle Panelisten ein Ecosystem von „Stock“-Models, auf das Modellierer zurückgreifen können, so wie wir es aus der Softwareentwicklung gewohnt sind.

Paketmanager mit semantischer Versionierung sind in der Softwareentwicklung weit verbreitet (atp für Linux-Anwendungen, npm für Javascript, gem für Ruby…) und wären auch in der Modellierungswelt wünschenswert.

Daniel hatte den Wunsch nach so einer Bibliothek bereits vor 15 Jahren von Rockwell Collins vernommen und Vince schlug die OMG als das perfekte Zuhause für so eine Initiative vor. Schließlich seine 80 Unternehmen bereits Teil der OMG Systems Modeling Community, von denen sich sicher viele an so einem Projekt beteiligen würden.

So eine Modellbibliothek werden wir aber nur erschaffen können, wenn wir SysML-Konformität garantieren können. Womit wir wieder beim Thema wären.

Was passiert, wenn wir es nicht schaffen?

Die größte Gefahr ist, dass sich nichts ändern wird, verglichen mit SysML v1. Wenn wir keine Konformität haben und dadurch mit v2 dieselben Probleme, die wir auch vorher schon hatten, dann haben wir damit eine riesige Chance vertan. Die Leidtragenden würden die Anwender sein und die Geschwindigkeit, mit der sich SysML und MBSE verbreiten, wird nicht zunehmen.

Eine weitere Gefahr ist, dass die hohen Erwartungen an SysML v2 nicht erfüllt werden, was zu einem Tal der Enttäuschungen führen könnte. Wenn wir Pech haben, ist der Zug irgendwann abgefahren.

Fazit

An dieser Stelle kann ich nur wiederholen, was ich bereits letzte Woche geschrieben habe: Wir brauchen Menschen, die sich engagieren. Möchtest Du SysML v2-Aktivitäten unterstützen? Hier noch einmal die Liste, was es zu tun gibt:

  • 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.

Michael Jastram

Creator and Author of SE-Trends