Systems Engineering Trends

Donnerstags in 5 Minuten für Ingenieure und Entscheider: Systems Engineering ohne Hype, dafür mit Tiefgang

InterviewModellierung & MBSE

MBSE ist die Zukunft, aber die heutigen Werkzeuge sind zum Kotzen: Einblicke in MBSE von Pari Singh (Teil 2)

Letzte Woche veröffentlichte ich hier den ersten Teil des Interviews mit Pari Singh, in dem es um die Kritik an den derzeitigen Entwicklungswerkzeugen im Systems Engineering und die Notwendigkeit eines Paradigmenwechsels hin zu agileren und iterativeren Methoden ging.

Hier nun die Fortsetzung, in der Pari sich zur Bedeutung von Modellierung, SysML und der Eignung der verbreiteten Werkzeugen äußert.

In Teil 1 ist auch das Video des gesamten Interviews zu finden. Viel Spaß beim Lesen!

Ich möchte den Fokus auf ein eher technisches Thema lenken. Glaubst Du, dass Modellierung bei diesem Wandel eine Rolle spielt, und wenn ja, gehen wir in die richtige Richtung? Hast Du eine Meinung zu SysML v2? Befinden wir uns in einer Sackgasse? Sind wir auf dem richtigen Weg? Ist es ein Katalysator? Was hältst Du von der Idee, unsere Entwicklungsartefakte durch Modellierung digitaler zu machen?

Ich habe eine sehr starke Meinung zu diesem Thema. Ich werde wahrscheinlich viele Leute sehr wütend machen. Ich war vor ein paar Jahren auf einer INCOSE-Konferenz und habe meine Meinung zurückgehalten. Der erste Punkt hier ist, dass MBSE die Zukunft ist. Und meiner Meinung nach gibt es zwei große Teile von MBSE:

Da ist die modellbasierte Definition: Eine modellbasierte Sichtweise auf ein System und dann die Verwendung digitaler Modelle, Analysewerkzeuge und numerischer Modelle, um diese zu ergänzen und das Modell reicher und lebendiger zu machen. Auf dem Papier ist der Wechsel von einer dokumentenzentrierten Sichtweise zu einer modellzentrierten Sichtweise also eindeutig die Zukunft. Davon abgesehen sind wir der Meinung, dass MBSE-Tools völlig am Ziel vorbeigehen, wir finden MBSE-Tools zum Kotzen. Und wenn Du irgendjemandem in einer anderen Branche SysML v1 oder v2 zeigst und sagst, das sei die Zukunft des Engineerings, wird man Dich auslachen. Der Grund, warum es so katastrophal falsch ist, liegt darin, dass das Kernanliegen von MBSE darin besteht, ein einheitliches Modell zu erstellen, das alle Beteiligten im gesamten Unternehmen als Quelle der Wahrheit nutzen können. Das ist das Hauptziel von MBSE.

Aus diesem Grund wurde MBSE entwickelt, um ein einheitliches Modell zu schaffen, das jeder als Quelle der Wahrheit nutzen kann. SysML- und MBSE-Tools sind so schwierig zu bedienen, dass die Benutzer eine Menge Training benötigen, sie müssen über die Ontologie und die Struktur nachdenken. Und die Einzigen, die mit diesem Werkzeug umgehen können, sind ein paar sehr gut ausgebildete Systems Engineers, die dann alle Informationen in SysML v2 eingeben. Sie sitzen in einer Ecke und exportieren Dokumente, die sie an den Rest des Teams schicken, was bedeutet, dass der Rest des Teams nur Dokumente verwendet, was bedeutet, dass der ganze Sinn von MBSE nutzlos ist! Damit MBSE erfolgreich sein kann, muss es also das Systems Engineering demokratisieren.

MBSE muss Nicht-Systems Engineers die gleiche Sichtweise wie Systems Engineers ermöglichen, und es muss Systems Engineers die Möglichkeit geben, von der Dokumentationsarbeit zu einer ganzheitlicheren Betrachtung des Systems überzugehen und Maschinenbau-, Elektro- und Softwareingenieuren zu helfen, die gleiche Sichtweise einzunehmen. Das größte Manko der SysML- und MBSE-Tools ist also die Benutzerfreundlichkeit. Wir müssen diese Werkzeuge auch für Nicht-Systems Engineers ansprechend und benutzbar machen.

Ingenieure, die keine Systems Engineers sind, sollten in der Lage sein, ein MBSE-Tool in die Hand zu nehmen und einfach zu sagen: „Oh, hey, ich verstehe Stufe eins und Stufe zwei und das Innere von Stufe zwei. Ich lebe im Motorenteam. Ich klicke mich also in das Motorenteam und sehe dann die drei oder vier Schnittstellen zu den anderen Systemen, mit denen ich kommunizieren muss, und sehe die neuesten Versionen dieser Schnittstellenanforderungen mit den Schnittstellenwerten“, und werde so zu einem einheitlichen Modell für das gesamte Team. Die Leute, die ich in der Systems-Engineering-Community sehe, die mit MBSE am weitesten fortgeschritten sind, haben meistens eine riesige Wand, drucken ein Modell aus und hängen es an die Wand, damit jeder es benutzen kann.

Ein Miro- oder draw.io-Diagramm auszudrucken und an die Wand zu hängen, eignet sich eigentlich besser für ein MBSE als einige der vorhandenen Tools oder SysML v2. Ich denke, die Absicht hinter diesen Tools ist beeindruckend, aber ich glaube nicht, dass die Tools für Nicht-Systems Engineers geeignet sind.

Die Werkzeuge sind sicherlich ein Thema, aber die Modellierungssprache ist ein anderes. Die Befürworter von SysML v2 sagen, dass die Vereinfachung, die Textnotation und die API die Sprache viel besser für die von Dir beschriebene Vision geeignet macht. Was ist mit der Modellierungssprache? Und ist SysML v2 die Zukunft oder ist es eine weitere Sackgasse?

Zur eigentlichen Modellierungssprache selbst habe ich keine starke Meinung. Ich denke, dass alle Werkzeuge Stärken und Schwächen haben, aber ich habe festgestellt, dass viele Systems Engineers zu viel Wert auf Ontologie legen. Die Ontologie ist wirklich sehr wichtig, und sie begeistert mich, weil ich damit beginnen kann, in Schichten und Philosophien zu denken und Strukturen zu schaffen. Ich kann damit beginnen, Objekte und Klassen zu erstellen.

Aber ich denke, das ist wahrscheinlich der falsche Ansatz für den Anfang. Irgendwann müssen wir natürlich dahin kommen. Aber wenn man damit anfängt, schreckt das viele Leute ab, und es schafft Struktur und zwingt Struktur auf, wo man sie nicht unbedingt braucht. Und genau das ist der springende Punkt. Wenn ich auf eine Sache hinweisen müsste, in der ich mir wünschte, dass unsere Gemeinschaft besser wäre, dann wäre es das Verständnis für den Unterschied zwischen einem guten Prozess und der tatsächlichen Lieferung eines Produkts.

Viele Systems Engineers, insbesondere junge Systems Engineers, lesen das NASA Systems Engineering Handbook und das INCOSE Handbook. Und sie sagen, wenn ich nur alle Tausend dieser Schritte auf 200 dieser Seiten buchstabengetreu befolge, dann bekomme ich garantiert ein gutes Produkt. Und dann, zehn Jahre später, befolgen sie jeden einzelnen Schritt und jede einzelne Richtlinie, und sie schreiben leere Statements und schaffen leider kein gutes Produkt.

Was wir in anderen Bereichen gesehen haben, ist vielleicht ein zu extremer Ansatz, also ohne Prozess, ohne Schritte, ohne Anforderungen einfach etwas zu bauen und auszuliefern. Und dieses Vorgehen liefert tatsächlich ein großartiges Produkt, aber ist es auch sicher und zuverlässig? Wir müssen einen guten Mittelweg finden. Wir müssen also einen Mittelweg finden, bei dem wir Nicht-Systems Engineers befähigen, eine systemische Denkweise zu entwickeln, indem wir den Leuten helfen, in den Anforderungsprozess und in den MBSE-Prozess einzusteigen. Und wir machen aus einem Silo etwas, das im Herzen des Teams sitzt und ein lebendiges Modell ist. Um das zu erreichen, muss ein Systems Engineer in der Lage sein, ein wenig Kontrolle über sein Team abzugeben, damit die Teams, die nicht aus Systems Engineers bestehen, besser mit ihm zusammenarbeiten können.

Ich komme aus der Frühzeit der Softwareentwicklung. Ich erinnere mich, dass in den 90er Jahren viel über Softwarekomponenten und Wiederverwendbarkeit diskutiert wurde. Es kommt mir so vor, als würden wir wiederholen, was damals geschah, denn heute haben wir das. Man muss nur die richtige Architektur für ein Softwareprojekt auswählen, und alle Teile fallen an den richtigen Platz und man kann anfangen, produktiv funktionierende Software zu erstellen.

Das ist ein wichtiger PUnkt. UML wurde von der Softwareentwicklungsbranche abgelehnt, nicht wahr? Sie haben es ausprobiert, es war eine großartige Idee, aber sie fanden sie nicht nützlich, und sie wurde abgelehnt. Und dann haben wir das Vorgehen geklont: Wir haben UML in SysML umgewandelt, wir haben einige Funktionen hinzugefügt und wir denken, dass es für unseren Anwendungsfall funktionieren könnte. Ich stimme mit der Philosophie und der Absicht hinter MBSE überein, aber ich denke, dass wir bei der konkreten Umsetzung das Ziel verfehlt haben könnten.

Welche Rolle spielt die Traceability bei dieser Transformation, und kannst Du auch etwas zu Flow Engineering sagen und wie Du dieses System-Engineering-Problem in Deinem Unternehmen zu lösen gedenkst?

Gerne. Zunächst einmal ist die Nachverfolgbarkeit eines der wichtigsten Dinge, die ein Systems Engineering-Team richtig machen muss. Sie ist der Grund für die Existenz des Systems Engineering. Sie soll dabei helfen, all diese verschiedenen Funktionen miteinander zu verbinden, um zu verstehen, wenn eine Änderung an einer Stelle stattfindet, welche Auswirkungen diese Änderung hat, und um sicherzustellen, dass wir über einen wirklich guten Prozess verfügen, um damit umzugehen. Im traditionellen Systems Engineering werden nur die Anforderungen verfolgt, und zwar nur auf der Ebene des Missionssystems und vielleicht der Subsysteme, aber das ist auch schon alles. Es gehen also zwei wirklich wichtige Teile der Nachverfolgbarkeit verloren. Der erste Teil sind die Anforderungen auf der tieferen Ebene des Domain Engineering.

Wie zerlegen wir also eine System- oder Teilsystemanforderung in spezifische Anforderungen auf niedriger Ebene, die ein Ingenieur in seiner V&V liefern kann? Und zweitens geht dabei die Nachverfolgbarkeit zum Design verloren. Wir haben also all diese tollen Anforderungen, die besagen, dass wir Folgendes tun müssen. Dann haben wir keinerlei Nachverfolgbarkeit, außer dass wir eine Verbindung dazu herstellen, z. B. durch ein Video oder ein Foto des Flugzeugs, um zu beweisen, dass es tatsächlich funktioniert. Und wir stellen fest, dass ein echter Bedarf an detaillierterer Nachverfolgbarkeit besteht, da unsere Systeme immer komplexer und funktionsübergreifender werden.

Und das spiegelt sich auch in den Qualitätskontrollstandards wider, die es gibt. Ein Beispiel, das ich sehr gut kenne, ist die Kerntechnik. In der Nuklearindustrie verlangen neue Vorschriften wie NQA-1 jetzt eine vollständige Nachverfolgbarkeit, und zwar nicht nur in Bezug auf die Anforderungen, sondern auch auf spezifische Deesignannahmen und spezifische Entwurfsparameter, die die verschiedenen Elemente des Systems steuern. Wir halten die Nachverfolgbarkeit für großartig, aber wenn man nur auf der Ebene der Systemmissionen und Subsysteme zurückverfolgt, verliert man 80 % des Entwurfs und 80 % des Wertes, der sich aus der Nachverfolgbarkeit ergibt. Wir brauchen also mehr Nachverfolgbarkeit, das ist mein Fazit.

Wie passt Flow Engineering in dieses Konzept? Flow entwickelt ein modernes, agiles Anforderungswerkzeug der nächsten Generation. Wir bauen die Plattform, von der Systems Engineers schon immer geträumt haben. Ich würde sagen, es ist das erste moderne System-Engineering-Tool, das aussieht, als wäre es in den 2020er Jahren entwickelt worden und nicht in den 1990er Jahren. Unser Kernpunkt ist, dass wir den Systems Engineers dabei helfen, die Anforderungen von der Mission bis hinunter zur Komponentenebene aufzuschlüsseln und dann eine Live-Rückverfolgbarkeit und Live-Integration mit Nicht-Systems Engineering-Teams zu ermöglichen.

Die andere große Philosophie im Systems Engineering, die seit einiger Zeit propagiert wird, ist die kontinuierliche Integration und die kontinuierliche Überprüfung. Diese Philosophie wurde von der Softwareindustrie übernommen und hat sich bewährt: Wir haben Anforderungen, die eigentlich Tests sind. Können wir diese Tests mit unserem Design verknüpfen? Und in dem Moment, in dem in einem Team eine Designänderung vorgenommen wird, die sich auf ein anderes Team auswirkt, die sich auf ein drittes Team auswirkt, ist meine Anforderung hinfällig. Anstatt drei oder vier Monate zu warten, um diese Information herauszufinden, kann ich sie sofort herausfinden. Und anstatt den Faden zu verlieren, kann ich den Computer nutzen, um die gesamte V&V-Arbeit zu automatisieren und mir schneller Informationen darüber zu verschaffen, welche Anforderungen vorhanden sind und welche nicht.

Das ist es, was Flow macht. Flow entwickelt ein Anforderungswerkzeug der nächsten Generation, das die Systemtechnik und die Anforderungen mit dem Design verknüpft und eine kontinuierliche Integration und Verifizierung im gesamten Team und nicht nur in einem Team ermöglicht. Wir arbeiten jetzt mit einigen der besten Ingenieurunternehmen der Welt zusammen.

Wir arbeiten mit einigen der größten und anspruchsvollsten Raumfahrtunternehmen zusammen, aber auch mit Unternehmen aus der Automobilbranche, der Nuklearindustrie, der Medizintechnik. Und wir arbeiten wahrscheinlich mit den schnellsten und besten Teams da draußen zusammen. Ich würde sagen, wir sind der Marktführer im Bereich der modernen Anforderungswerkzeuge, der sich schnell zu einem hart umkämpften Markt entwickelt. Aber wir haben wahrscheinlich in jeder einzelnen Dimension die Nase vorn, und unsere Magie ist unser Produkt. Wer mehr erfahren möchte, kann sich flowengineering.com anschauen, und sich schnell ein Bild von unseren MBSE-Fähigkeiten oder unseren Anforderungs- und Integrationsfähigkeiten machen.

Pari, vielen Dank für Deine Zeit und Deine Einblicke.

Michael Jastram

Creator and Author of SE-Trends