Warum Engineering Tools eine Überholung brauchen: Einblicke in MBSE von Pari Singh

Systems Engineering, wie es heute praktiziert wird, ist kaputt - zumindest nach Ansicht von Pari Singh. Er ist der Meinung, dass die Engineering-Tools im “dunklen Zeitalter” feststecken und ist entschlossen, dies zu ändern. Und er ist mit seinem Unternehmen Flow Engineering auf einem guten Weg, dies zu ändern.

Pari Singh hat eine Ausbildung als Maschinenbauingenieur und wurde 2019 in die Forbes 30 under 30 Liste aufgenommen. Mit seinem 2019 gegründeten Unternehmen Flow Engineering will er die Produktentwicklung revolutionieren.

Ich hatte das Vergnügen, am 21. Juni 2024 mit Pari Singh über Systems Engineering im Allgemeinen und MBSE im Besonderen zu sprechen. Lesen Sie das Transkript oder sehen Sie sich die Aufzeichnung des Gesprächs an.

Ankündigung: Am 1. August wird Michael Jastram ein Webinar über die KI-Erweiterung von Raiqon für Codebeamer in der Automobilforschung und -entwicklung moderieren. Kostenlos registrieren >>

Pari Singh & Strömungstechnik

Auch wenn Pari's Firma, Strömungsmechanik, das SaaS-Software anbietet, hat das Unternehmen einen unglaublichen Schwenk vollzogen. Pari begann als Maschinenbauingenieur, der sich für SpaceX, was ihn in die Raumfahrtindustrie trieb. Um 2010, als er noch an der Universität war, gründete er ein Unternehmen für die Entwicklung von Raketentriebwerken.

Um es kurz zu machen: Pari baute ein Unternehmen auf, das in der Lage war, Raketentriebwerkskonstruktionen innerhalb von Stunden zu liefern, wo die Konkurrenz Monate brauchte. Dies gelang ihnen durch den Aufbau eines ausgeklügelten Netzwerks miteinander verbundener Modelle (Matlab, CAD, FEM usw.) mit Rückkopplungsschleifen. Sie erkannten, dass der Markt nach agiler Hardware verlangte und dass die handelsüblichen Werkzeuge für Teams, die auf diese Weise arbeiten wollten, völlig ungeeignet waren.

Dies führte zu einer Neuausrichtung des Geschäftsmodells. Als sie mit Investoren sprachen, erkannten sie, dass (1) die Technik kaputt ist, (2) dass sie einen neuen Ansatz für die mechanische Systemtechnik erfunden haben, und (3) dass sie, wenn sie einen Weg finden, das Ganze zu formalisieren und “in eine Box zu packen”, um es ihren ursprünglichen Kunden zu geben, das Problem lösen können, für das sie das Unternehmen gegründet haben, nämlich der gesamten Branche zu helfen, sich viel schneller zu bewegen.

Für Flow haben die Endbenutzer höchste Priorität, wenn es darum geht, sich durchzusetzen. Unternehmen wie Dassault oder Siemens verkaufen an die Chefingenieure oder Entscheidungsträger, was oft zu einer mittelmäßigen Benutzererfahrung führt. Für Flow ist der Aufbau einer besseren Erfahrung für den Endbenutzer der Schlüssel, und sie gehen davon aus, dass sie die Entscheidungsträger für sich gewinnen können, wenn sie den Wert der Lösung für die Endbenutzer demonstrieren können.

Interview mit Pari Singh

Michael Jastram führte dieses Interview mit Pari Singh am 21. Juni 2024

In Ihren Beiträgen äußern Sie sich ausführlich zum agilen Engineering, das sich mittlerweile bewährt hat. Warum tun sich so viele Unternehmen schwer mit der Einführung?

Ich würde gerne etwas über den Kontext dieses Wandels erzählen, denn ich glaube nicht, dass die Systems-Engineering-Gemeinschaft schon eine gute Definition dafür hat, was genau der Wandel ist. Viele Leute sagen, Agil ist zweiwöchige Sprints und ist Software und ist MVP und das ist nicht wirklich der Fall. Lassen Sie mich also vielleicht einen Schritt zurücktreten und einen breiten Überblick über den Kontext geben, in dem sich dies ändert und warum es eine so wichtige Änderung ist.

In der Systems-Engineering-Gemeinschaft vollzieht sich derzeit ein Wandel, der nur einmal in einer Generation stattfindet. Das letzte Mal, dass ein Wandel in dieser Größenordnung stattgefunden hat, war wahrscheinlich in den 1960er Jahren, als die Systemtechnik in den Anfängen entstand. Dieser Wandel vollzieht sich von einem eher traditionellen, von oben nach unten verlaufenden, wasserfallorientierten 10-Jahres-Entwurfszyklus, bei dem es darum geht, mit externen Auftragnehmern zusammenzuarbeiten und sehr rigoros zu sein, hin zu einem viel agileren und iterativen Arbeitsablauf. Und das bedeutet zwei Dinge.

Erstens bedeutet dies, dass es eine Mischung aus Top-Down-Anforderungsmanagement und Bottom-Up-Design gibt. Früher, als unsere Systeme noch weniger komplex waren, konnten wir alle unsere Anforderungen von der Missions- über die System- bis hin zur Subsystem- und schließlich zur Komponentenebene festlegen und mit diesen Annahmen richtig liegen. Aber da unsere Produkte viel komplexer geworden sind, ist das nicht mehr möglich, weil unsere Systeme jetzt so komplex und funktionsübergreifend sind, dass eine winzige Änderung in einem Team zu komplexen Änderungen in anderen Teams und anderen Organisationen führen kann, die wiederum komplexe Änderungen verursachen. Und in den meisten Fällen haben wir kein Fahrzeug dieses Ausmaßes oder dieser Komplexität entwickelt. Oftmals verstehen wir zu Beginn des Projekts die Systeminteraktionen zwischen Software und Hardware nicht vollständig. Und diese Dinge müssen im Laufe der Zeit verstanden werden.

Es ist also die erste große Veränderung von Wasserfall zu agil. Wasserfall ist weitgehend von oben nach unten gesteuert und darauf ausgelegt, Veränderungen zu vermeiden. Agil bedeutet, dass wir in der Anfangsphase Annahmen über unsere Anforderungen haben, aber wir sind offen für Neues, denn Veränderungen sind unvermeidlich.

Und wir werden wahrscheinlich nicht mit allen unseren technischen Annahmen richtig liegen, weil wir so etwas noch nie gebaut haben. Daher brechen agile Teams die Anforderungen nicht nur von der Missions- auf die System- oder Subsystemebene herunter, sondern sie lassen die Anforderungen von L0, L1 bis hinunter zu L3, L4, L5 fließen. Sie haben also eine vollständige Rückverfolgbarkeit von der Auftragsebene bis hinunter zu einer bestimmten Komponentenebene. Das ist die erste große Veränderung.

Die zweite große Veränderung besteht darin, dass wir erkennen, dass der iterative Ansatz wirklich der richtige ist. Einer der Leute, die wir sehr gut kennen, hat vor kurzem diese Geschichte erzählt, die besagt, dass es, wenn man ein Sechs-Zoll-Teleskop bauen will, in der Regel schneller ist, ein Drei-Zoll-Teleskop zu bauen und dann ein Sechs-Zoll-Teleskop zu bauen, als ein Sechs-Zoll-Teleskop zu bauen.

Das ist eine wirklich tolle Analogie. Die besten Teams der Welt beginnen nicht mit der kompliziertesten Version und versuchen, ihre Annahmen frühzeitig festzulegen. Vielmehr finden sie die kleinste Einheit eines integrierten Systems, die sie bauen können, um das Risiko zu verringern und aus ihren Annahmen zu lernen. Und dann fügen sie im Laufe der Zeit iterativ weitere Schichten hinzu, um sehr schnell lernen und entwickeln zu können.

Wenn ich das umformulieren darf: Aus Sicht der Software schlagen Sie den MVP-Ansatz vor, nur dass Sie bei der Software das Produkt weiterentwickeln können, während Sie bei der Hardware ein zweites Teleskop bauen müssen. Aber die Idee ist dieselbe.

Das ist genau richtig. Dieser Ansatz klingt sehr verschwenderisch. Den Hardware-Ingenieuren gefällt das nicht, weil sie es dreimal bauen müssen, anstatt nur einmal.

Aber wenn man sich Unternehmen wie SpaceX, Tesla und die am schnellsten wachsenden Unternehmen anschaut, sieht man, dass dieser Ansatz viel effizienter ist als der traditionelle Ansatz. Wenn man zum Beispiel den Starliner von Boeing mit dem Dragon von SpaceX vergleicht, sieht man, dass Dragon in der Hälfte der Zeit und zu den halben Kosten mehr erreicht hat. Sie haben viele Dragons gebaut, daraus gelernt und sie wieder weggelegt. Dieser iterative Ansatz klingt langsamer und teurer. Aber in der Praxis hat sich gezeigt, dass es viel schneller, effizienter und sicherer ist, so zu arbeiten.

Dem kann ich nur zustimmen. Es erinnert mich an die Einführung von Starship. Was mich wirklich gestört hat, war die Schlagzeile, die ich neulich las: “Vierter Testflug endlich erfolgreich“, was bedeutet, dass die ersten drei nicht erfolgreich waren.

Wir brauchen wirklich einen Paradigmenwechsel, bei dem die Menschen verstehen, dass eine explodierte Rakete kein Fehlschlag ist, sondern ein erfolgreicher Test, weil er Daten geliefert hat. Wie können wir also diesen Paradigmenwechsel erreichen?

Das ist sehr schwierig. Der Schlüssel ist, sich nicht auf die Erfüllung der Anforderungen zu konzentrieren, sondern auf das Lernen. Dies ist also eines der Dinge, die SpaceX immer wieder im Live-Stream für IFT-4. Sie sagten, die Nutzlast seien die Daten. Es geht nicht um den erfolgreichen Flug, es geht nicht darum, dass wir alle unsere Anforderungen erfüllen, es geht nicht darum, dass wir unsere V&V erfolgreich abschließen. Aber die Nutzlast sind die Daten.

Und wenn wir in der Lage sind, wirklich großartige Daten aus dem Fahrzeug zu erhalten und seine genauen Grenzen zu verstehen, wo wir gut und wo wir schlecht abschneiden, dann werden wir in der Lage sein, den IFT-5 oder das nächste Fahrzeug viel schneller, viel besser und viel schneller zu entwickeln. Im Kern geht es also darum, sich auf das Lernen zu konzentrieren. Der nächste Schritt, der sich daraus ableitet, lautet: Wie können wir so schnell wie möglich lernen?

Die zweite große Schwierigkeit für Systemingenieure besteht darin, aus dem “Anforderungsland”, dem “Analyseland” und dem “Denkland” herauszukommen und in das “Umsetzungsland” zu gelangen. Das ist ein sehr schwieriger Übergang für Systemingenieure. Ich kann das nachempfinden: Ich bin von Haus aus Maschinenbauingenieur. Ich habe meine gesamte frühe Karriere damit verbracht, analytische Modelle zu entwickeln, um Raketentriebwerke, Hybride und Flüssigkeiten zu entwerfen. Aber man lernt sehr viel, wenn man einfach nur die kleinsten Mengen baut, sie testet und dann das nächste und das nächste und das nächste baut. Und wenn man sich Apollo ansieht, dann ist das ein großer Teil dessen, was sie getan haben.

Sie haben erkannt, dass sie die Apollo-Missionen bauen müssen, um zum Mond zu fliegen, aber sie können nicht direkt von “hier” zum Mond fliegen. Bevor sie also aufsteigen, mehrere Stufen haben, um den Mond herumfliegen und dann auf dem Mond landen, müssen sie in der Lage sein, aufzusteigen und mehrere Stufen zu haben, um in die Umlaufbahn zu gelangen. Und bevor sie die Umlaufbahn erreichen, müssen sie in der Lage sein, die Kármán-Linie. Der schnellste und billigste Weg, die Kármán-Linie zu überwinden, besteht darin, eine Rakete, wie wir sie heute haben, zu beschaffen, einen Menschen auf die Spitze dieser Rakete zu setzen und sie zu starten. Wenn man sich das Ausmaß dieses Vorhabens vor Augen führt, ist es verrückt, aber der schnellste Weg, um zu lernen, bestand darin, einen Menschen auf einer ICBM-Rakete nachzurüsten und dann so schnell wie möglich zu lernen. Und so sind wir zum Mond gekommen.

Ich stimme dem zu. Die Apollo-Ingenieure haben die Iterationen in dem Tempo durchgeführt, das mit der verfügbaren Technologie machbar war. Aber ich stimme nicht mit der Aussage überein, dass Systemingenieure sich nicht von den Anforderungen entfernen wollen.

Ich glaube, es geht eher um die Angst der Entscheidungsträger, die meinen, dass eine gesprengte Testrakete als Fehlschlag angesehen wird, was nicht der Fall ist. Also noch einmal: Wie können wir diesen Paradigmenwechsel realisieren? Wie können wir mit den Entscheidungsträgern sprechen und ihnen erlauben, den Ingenieuren die Freiheit zu geben, diese Dinge zu tun?

Lassen Sie mich Ihnen zwei oder drei Antworten geben und etwas Kontext. Ich denke, der Kontext ist für unsere Branche wirklich wichtig: Wenn man sich nur den heutigen Tag ansieht, macht die Art und Weise, wie wir Technik betreiben, überhaupt keinen Sinn. Aber wenn man es im breiten Kontext der letzten 20 oder 30 Jahre betrachtet, wird plötzlich klar, warum wir zu den Schlussfolgerungen gekommen sind, zu denen wir gekommen sind. Die Systemtechnik entstand aus den ersten öffentlich finanzierten Missionen, den Weltraummissionen. Das waren die Anfänge dessen, was ich echte Systemtechnik nenne. Und die wird in der Regel vom Steuerzahler finanziert.

In der Regel handelt es sich um eine Mission, die wir noch nie zuvor durchgeführt haben und die sehr, sehr schwierig ist. Und als Ergebnis dieser beiden Dinge, wenn der Kongress Mittel zur Verfügung stellt, wenn Steuergelder in Missionen fließen, die sehr, sehr komplex sind, Missionen, die viele Menschen beschäftigen. Dann gilt das Paradigma, dass man es beim ersten Mal richtig machen muss. Wenn ein Politiker $10 Milliarden oder eine Milliarde Dollar für diese große Mission ausgibt und sie scheitert, dann sieht das wirklich schlecht aus. Das ist der Ursprung der Systemtechnik. Aber jetzt sehen wir, dass private Unternehmen all die Sünden der öffentlich finanzierten Missionen kopieren. Und das ist der Fehler. Der Fehler besteht darin, anzunehmen, dass die gleichen Regeln gelten wie für ein privates Unternehmen, das Geld verdienen und wirklich großartige, sichere und zuverlässige Produkte herstellen und sehr schnell vorankommen will. Das ist die grundlegende Veränderung, die wir vornehmen müssen.

Das erklärt, warum Neugründungen es geschafft haben, diese Ansätze zu übernehmen, und dass große bestehende alte Organisationen damit zu kämpfen haben. Haben Sie eine Idee, ob und wenn ja, wie bestehende große Organisationen diesen Wandel vollziehen können?

Wenn Sie mir vor drei Jahren diese Frage gestellt hätten, hätte ich gesagt, dass es unmöglich ist. In der Wissenschaft gibt es ein großartiges Prinzip, das besagt, dass der Weg zu revolutionären Veränderungen darin besteht, die alten Menschen aussterben und die neue Generation heranwachsen zu lassen. Ich bin wirklich froh, dass ich in diesem Punkt eines Besseren belehrt worden bin.

Ich schaue mir also bestimmte Unternehmen wie Blue Origin an, die eigentlich mit einem viel traditionelleren, konservativen Modell angefangen haben. Sie stellten viele Führungskräfte von Northrop Grumman und anderen traditionellen Luft- und Raumfahrtunternehmen ein und übernahmen diese Kultur, was sie fast umgebracht hätte. Sie stellen derzeit auf einen agileren Ansatz um, und sie machen ihre Sache recht gut. Wir werden sehen, ob es funktioniert und ob eine solche Umstellung in einem Unternehmen mit 10.000 Mitarbeitern möglich ist.

Aber ich bin vorsichtig optimistisch, was diese Veränderung angeht. Der einfachste und schnellste Weg, dies zu erreichen, besteht darin, eine Skunk-Works-Team. Anstatt die bestehenden Mitarbeiter und die bestehende Kultur zu nehmen und zu versuchen, einen neuen Weg einzuschlagen, sollten wir lieber ein neues Team mit einem neuen Auftrag aufbauen, um etwas Schwieriges zu tun, bei dem der einzige Weg agil ist. Und dann nehmen wir dieses Team und setzen es an verschiedenen Stellen in unserer Organisation ein und schaffen auf diese Weise einen kulturellen Wandel.

Kultureller Wandel geschieht durch eine Mischung aus "Bottom-up"- und "Top-down"-Entscheidungsbefugnissen und einem ehrlichen Auslöser. Und dieser Auslöser ist in der Regel ein Großbrand, etwas, das furchtbar schief gelaufen ist und uns dazu zwingt, unsere Prozesse neu zu bewerten. Und meine Sorge ist, dass wir auf viele Großbrände warten werden, bis sie passieren. Wenn ich mir Unternehmen wie Boeing anschaue, dann sehe ich, dass ein Brand nach dem anderen, ein Fehler nach dem anderen, ein Rückruf nach dem anderen diese Dinge verursacht. Und ich hoffe, dass wir einen Weg finden werden, dies zu tun.

Ich möchte den Fokus auf ein eher technisches Thema lenken. Glauben Sie, dass die Modellierung bei diesem Wandel eine Rolle spielt, und wenn ja, gehen wir in die richtige Richtung? Haben Sie eine Meinung zu SysML v2? Befinden wir uns in einer Sackgasse? Sind wir auf dem richtigen Weg? Ist es ein Wegbereiter? Was halten Sie 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 Überzeugungen zurückgehalten. Der erste Punkt hier ist, dass MBSE die Zukunft ist. Und meiner Meinung nach gibt es zwei große Teile von MBSE:

Es gibt die modellbasierte Definition: Eine modellbasierte Sicht 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 eindeutig die Zukunft schlechthin. Davon abgesehen sind wir der Meinung, dass MBSE-Tools völlig am Ziel vorbeigehen, wir finden MBSE-Tools zum Kotzen. Und wenn Sie irgendjemandem in einer anderen Branche SysML v1 oder v2 zeigen und sagen, das sei die Zukunft des Engineerings, wird man Sie 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 Systemingenieure, 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-Systemingenieuren die gleiche Sichtweise wie Systemingenieuren ermöglichen und Systemingenieuren die Möglichkeit geben, von der Dokumentationsarbeit zu einer ganzheitlicheren Betrachtung des Systems überzugehen und Maschinenbau-, Elektro- und Softwareingenieuren dabei 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-Systemingenieure schön und benutzbar machen.

Ingenieure, die keine Systemingenieure 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 Schnittstellenwerten”, und werde so zu einem einheitlichen Modell für das gesamte Team. Die Leute, die ich in der Systems-Engineering-Gemeinschaft 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 wie SysML v2. Ich denke, die Absicht hinter diesen Tools ist erstaunlich, aber ich glaube nicht, dass die Tools für Nicht-Systemingenieure 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 Unterstützung der von Ihnen beschriebenen Vision geeignet machen. Und nun? Was ist mit der Modellierungssprache? Und ist SysML v2 möglicherweise 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 Systemingenieure 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. Ich denke, dass wir irgendwann 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, von der ich wünschte, dass unsere Gemeinschaft sie besser beherrschen würde, dann wäre es das Verständnis für den Unterschied zwischen einem guten Prozess und der tatsächlichen Lieferung eines Produkts.

Viele Systemingenieure, insbesondere junge Systemingenieure, lesen das NASA Systems Engineering Handbook und das INCOSE Handbook. Und sie sagen, wenn ich nur alle Tausende 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 Shell-Statements und bringen kein gutes Produkt heraus.

Was wir in anderen Bereichen gesehen haben, ist vielleicht ein zu extremer Ansatz, aber wir sagen, ohne Prozess, ohne Schritte, ohne Anforderungen, wir bauen einfach etwas und liefern es. Und das liefert tatsächlich ein Produkt, was großartig ist, aber ist sie sicher und zuverlässig?? Und wir müssen einen guten Mittelweg finden. Wir müssen also einen Mittelweg finden, bei dem wir Nicht-Systemingenieure in die Lage versetzen, 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 Systemingenieur in der Lage sein, ein wenig Kontrolle über sein Team abzugeben, damit die Teams, die nicht aus Systemingenieuren bestehen, besser mit ihm zusammenarbeiten können.

Ich komme aus der Software-Welt der ersten Stunde. 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 wird Ihnen all das zur Verfügung gestellt. Sie müssen nur die richtige Architektur für Ihr Softwareprojekt auswählen, und schon fallen alle Teile an ihren Platz, und Sie können anfangen, produktiv funktionierende Software zu liefern.

Das ist wirklich wichtig zu sagen. 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 sie 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 Rückverfolgbarkeit bei dieser Umwandlung, und können Sie auch etwas zum Flow Engineering sagen und wie Sie dieses System-Engineering-Problem in Ihrem Unternehmen zu lösen gedenken?

Ganz genau. Zunächst einmal ist die Rückverfolgbarkeit eines der wichtigsten Dinge, die ein Systemtechnik-Team richtig machen muss. Sie ist der Grund für die Existenz der Systemtechnik. 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 das auszugleichen. Bei der traditionellen Systementwicklung 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 Rückverfolgbarkeit verloren. Der erste Teil sind die Anforderungen auf der tieferen Ebene des Domain Engineering.

Wie können wir also ein System oder ein Teilsystem in spezifische Anforderungen auf niedriger Ebene aufteilen, die ein Ingenieur in seiner V&V erfüllen kann? Und zweitens geht dabei die Rückverfolgbarkeit des Entwurfs verloren. Wir haben also all diese tollen Anforderungen, die besagen, dass wir Folgendes tun müssen. Dann haben wir keinerlei Rückverfolgbarkeit, außer dass wir eine Verbindung dazu herstellen, z. B. durch eine Kamera oder ein Foto des Flugzeugs, um zu beweisen, dass es tatsächlich funktioniert. Und wir stellen fest, dass ein echter Bedarf an detaillierterer Rückverfolgbarkeit 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 Atomindustrie. In der Atomindustrie gibt es neue Vorschriften wie NQA-1 erfordern jetzt eine vollständige Rückverfolgbarkeit, nicht nur auf der Anforderungsseite, sondern bis hin zu spezifischen Entwurfsannahmen und spezifischen Entwurfsparametern, die verschiedene Elemente des Systems steuern. Wir halten die Rückverfolgbarkeit für großartig, aber wenn man nur auf der Ebene der Teilsysteme des Missionssystems zurückverfolgt, verliert man 80% des Designs und 80% des Wertes, der sich aus der Rückverfolgbarkeit ergibt. Wir brauchen also mehr Rückverfolgbarkeit, 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 Systemingenieure 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, als wäre es in den 1990er Jahren entwickelt worden. Unser Kernpunkt ist, dass wir den Systemingenieuren helfen, die Anforderungen von der Mission bis hinunter auf die Komponentenebene aufzuschlüsseln und dann eine Live-Rückverfolgbarkeit und Live-Integration mit Nicht-Systemtechnik-Teams zu ermöglichen.

Die andere große Philosophie der Systemtechnik, die seit einiger Zeit propagiert wird, ist die kontinuierliche Integration und die kontinuierliche Überprüfung. Diese Philosophie wurde in 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 Ball fallen zu lassen, 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 ermöglicht, anstatt nur in einem Team. 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 - mit allen wichtigen Branchen, in denen wir tätig sind. 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 unser Zauber ist unser Produkt. Wenn Sie also mehr erfahren möchten, schauen Sie sich flowengineering.com an, und Sie können sich schnell ein Bild von unseren MBSE-Fähigkeiten oder unseren Anforderungs- und Integrationsfähigkeiten machen.

Pari, vielen Dank für Ihre Zeit und Ihre Erkenntnisse.