Es ist kein MBSE, wenn du draw.io oder Visio verwendest

Ich habe in den letzten Jahren eine ganze Reihe von Modellierungsworkshops moderiert, und es war häufig das erste Mal, dass alle Beteiligten gemeinsam über ein System nachdenken konnten. Das wurde entsprechend als sehr hilfreich empfunden. Und das wäre wahrscheinlich genauso gewesen, wenn keine formale Sprache verwendet worden wäre und das Ergebnis kein formales Modell gewesen wäre.

Ein Bild sagt mehr als tausend Worte. Das stimmt.

Aber ein Systemmodell nur als Kommunikationsmittel zu betrachten, greift zu kurz. Wer sich auf das Zeichnen von Bildern beschränkt, kann die Vorteile eines wirklich modellbasierten Ansatzes nicht nutzen. Die erfassten Informationen lassen sich so nicht ohne weiteres validieren. Es können keine anderen nützlichen Darstellungen abgeleitet werden: kein FMEA-Rahmen auf Basis einer funktionalen und technischen Zerlegung des Systems, kein Quellcode oder Testfälle aus Schnittstellen- und Verhaltensspezifikationen.

Ich würde sogar so weit gehen zu sagen: Generative KI lässt sich nur dann sinnvoll einsetzen, wenn das Systems Engineering auf (formalen) Modellen basiert. Angesichts der inhärenten Unschärfe, die diese neue Technologie mit sich bringt, ist MBSE die Absicherung für generierten Content.

Es ist völlig in Ordnung, wenn man einfach nur zeichnen möchte. Aber ich bin sicher, dass man damit nicht ins Ziel kommt. Und bitte: Nennt es nicht MBSE. Es ist keins.

Was ein Modell eigentlich zum Modell macht

Draw.io und Visio erzeugen Geometrie. Kästchen, Pfeile, Beschriftungen — visuelle Artefakte, die Bedeutung nur im Kopf des Lesers tragen. Es gibt keine maschinenlesbare Semantik dahinter. Keinen definierten Begriff von „Komponente", „Schnittstelle" oder „Funktion". Keine Regeln, die einschränken, was mit was verbunden werden darf.

Ein formales Modell ist anders. Dahinter liegt ein Metamodell: ein präzise definiertes Vokabular aus Konzepten, Beziehungen und Constraints, das vorschreibt, was ausgedrückt werden kann und wie. Eine Komponente hat einen Typ. Eine Schnittstelle hat eine Richtung. Eine Verbindung zwischen zwei inkompatiblen Ports ist nicht nur unschön — sie ist strukturell ungültig. Das Werkzeug weiß das und zeigt es sofort an.

Das ist der grundlegende Unterschied. Es geht nicht um die grafische Notation. SysML und Capella erzeugen Diagramme, die ähnlich aussehen wie das, was man in Visio zeichnen würde. Der Unterschied liegt darunter: Semantik, über die eine Maschine urteilen kann.

Drei Dinge, die nur mit echten Modellen möglich sind

Sobald ein Modell Semantik trägt, werden drei Dinge möglich, die Zeichnungen grundsätzlich nicht bieten können.

Konsistenzvalidierung. Ein Großteil der Modellprüfung läuft live, während man modelliert. Strukturelle und semantische Regeln werden kontinuierlich ausgewertet. Fehler erscheinen im Modell — nicht sechs Monate später im Hardware-Prototyp. Das ist ein klassischer Shift-left-Effekt, der sich genau dort auszahlt, wo es darauf ankommt: bei komplexen Systemen, bei denen Fehler im Nachgang teuer werden.

Abgeleitete Repräsentationen. Die System-FMEA ist ein kanonisches Beispiel. Manuell aus einem Word-Dokument abzuleiten ist mühsam und fehleranfällig. Aus einem Modell mit vollständiger funktionaler und technischer Dekomposition und lückenloser Anforderungsverfolgung lässt sie sich halbautomatisch ableiten — und bleibt konsistent mit der Architektur, während das Modell sich weiterentwickelt. Die Sicherheitsanalyse ist kein separat gepflegtes Dokument mehr, das vom Design abdriftet. Sie ist eine Sicht auf das Modell. Dasselbe gilt für Schnittstellenspezifikationen, Testfall-Frameworks und Architekturdokumentation.

Code-Generierung. Aus einem formalen Verhaltensmodell — etwa einem Zustandsautomaten — lässt sich deterministisch produktionsreifer C-, C++- oder Java-Code generieren. Dasselbe Modell, derselbe Generator, dieselbe Ausgabe. Diese Reproduzierbarkeit ist nicht nur eine Annehmlichkeit: In der geregelten Entwicklung unter ISO 26262, DO-178C oder IEC 61508 ist sie die Grundlage der Nachweiskette. Das bekommt man aus einer Zeichnung nicht heraus.

Formale Modelle als Fundament für sinnvollen KI-Einsatz

Das KI-Argument verdient mehr als einen Absatz.

Generative KI ist mächtig, aber statistisch. Derselbe Prompt erzeugt unterschiedliche Ausgaben. Es gibt keine Garantie für strukturelle Konformität, keine Nachvollziehbarkeit, keine Reproduzierbarkeit. Das sind keine beiläufigen Schwächen — es sind strukturelle Eigenschaften großer Sprachmodelle.

Ein formales Modell verändert, was KI leisten kann. Wenn eine KI innerhalb eines Modellraums arbeitet — in dem Konzepte, Beziehungen und Gültigkeitsbedingungen präzise definiert sind — werden ihre Vorschläge automatisch auf gültige Konstrukte eingeschränkt. Ganze Fehlerklassen sind strukturell ausgeschlossen, bevor ein Mensch die Ausgabe prüft. Das Modell ist nicht nur Dokumentation, die die KI liest; es ist eine abgeschlossene Welt, die einschränkt, was die KI vorschlagen kann.

KI-gestützte Modellierung: Ein LLM generiert aus natürlichsprachigen Anforderungen einen ersten strukturellen oder verhaltensbeschreibenden Modellentwurf. Engineers validieren und verfeinern — das Modell ist das stabile Artefakt, nicht der Prompt.

Konkret: KI kann Anforderungstexte in erste Modellentwürfe überführen, Konsistenzverbesserungen vorschlagen oder Testfälle aus Verhaltensspezifikationen generieren. Aber diese Ausgaben bleiben innerhalb der semantischen Grenzen des Modells. Der deterministische Generierungsschritt — vom Modell zum Code — bleibt vollständig reproduzierbar und prüfbar. KI beschleunigt den Modellaufbau; das Modell bleibt die Single Source of Truth; die Code-Generierung bleibt deterministisch. Keine dieser drei Ebenen ersetzt die andere.

Deshalb ist MBSE die Absicherung für KI-generierten Content. Nicht als Metapher. Als strukturelles Argument.

Wann eine Zeichnung tatsächlich ausreicht

Ich möchte an diesem Punkt ehrlich sein. Wer eine isolierte Steuereinheit für eine bestehende Maschine entwickelt — mit kleinem Team, stabilen Anforderungen, ohne Variantenmanagement — bei dem übersteigt der Aufwand eines formalen Modells wahrscheinlich den Nutzen. Dokumentenbasierte Abstimmung ist schlicht schneller.

MBSE rechnet sich, wenn die Entwicklungsaufgabe wirklich komplex ist: wenn mehrere Disziplinen beteiligt sind, Anforderungen sich dynamisch verändern, Änderungsanalysen über Subsystemgrenzen hinweg gefragt sind oder Sicherheitsnachweise systematisch erbracht werden müssen. Dann zahlen sich der Shift-left-Effekt formaler Validierung, die Konsistenz abgeleiteter Repräsentationen und der Determinismus der Code-Generierung in echten Einsparungen aus.

Wenn diese Voraussetzungen für das eigene Projekt nicht zutreffen, sollte man es nicht erzwingen. Aber einen Ansatz mit Visio-Diagrammen auch nicht MBSE nennen — denn das erweckt einen falschen Eindruck von den tatsächlichen Möglichkeiten der Methode und schürt Erwartungen, die sie strukturell nicht erfüllen kann.

Was MBSE also ausmacht

Ein Modell, über das eine Maschine urteilen kann. Ein definiertes Vokabular mit semantischen Constraints. Die Fähigkeit, daraus zu validieren, abzuleiten und zu generieren. Das ist die Grundlage.

Die Workshops, die Visualisierungen, das gemeinsame Durchdenken — das alles ist wertvoll. Aber es ist unabhängig davon wertvoll, ob eine formale Sprache verwendet wird. Den Nutzen strukturierter Kommunikation mit dem Nutzen formaler Modellierung gleichzusetzen ist der Fehler. Das eine bringt Ausrichtung; das andere bringt einen Hebel, um Komplexität zu beherrschen, Sicherheitsnachweise abzuleiten und KI zuverlässig zu integrieren.

Zeichne, wenn du kommunizieren willst. Modelliere, wenn du engineering betreiben willst.

MBSE-Einführung mit itemis — von der Tool-Evaluierung bis zu Methodik und Rollout: Systems Engineering →