Simulation ist eines der stärksten Argumente für MBSE: Statt zu hoffen, dass ein Modell das gewünschte Verhalten beschreibt, kann man es ausführen und zusehen. Mit CATIA Magic 2026 Refresh 1 gibt es dafür jetzt ein Simulations-Plugin für SysML v2. Wir haben es ausgepackt - und zeigen, was heute schon trägt, wo die Grenzen liegen und welche Stolperfallen man besser vorher kennt.

Warum Simulation der wertvollste Feedback-Kanal im Design ist

Simulation verschiebt Feedback nach vorne. Fehler, die sonst erst beim Test des realen Produkts auffallen, zeigen sich schon am Modell - dort, wo Korrekturen günstiger und einfach sind. MBSE bringt auch ohne Simulation viel, aber der Blick auf das dynamische Verhalten fehlt.

Und es gibt einen neuen Grund, genauer hinzusehen: KI braucht Feedback für ihre Arbeit. Ein ausführbares Modell ist genau das - eine objektive Rückmeldung, ob ein generierter Entwurf sich so verhält wie beabsichtigt.

Was das Plugin heute abdeckt

Der Fokus liegt momentan insbesondere auf zustandsbasiertem Verhalten. Simuliert werden Exhibit States mit ihren Zuständen, Transitionen und Triggern - inklusive Payload-, Change- und Time-Trigger sowie Guards. In Entry-, Do- und Exit-Abschnitten lassen sich über Assign Actions Attributwerte verändern. Mit an Bord: ein Expression Evaluator, der Ausdrücke laufend auswertet, und ein Requirement Checker, der während der Simulation zeigt, ob eine Anforderung erfüllt ist.

Das Simulationsfenster selbst ist angenehm schlicht: eine Konsole mit vollständigem Log, die aktuellen Variablenwerte, Einzelschritt, manuelles Auslösen von Transitionen, ein Geschwindigkeitsregler, Zeitreihendiagramme für ausgewählte Variablen und CSV-Export der Ergebnisse.

Wie weit das reicht, zeigt das mitgelieferte Wasserbehälter-Beispiel: Ein Controller regelt über ein Ventil den Füllstand, das Zeitreihendiagramm zeigt das typische Auf und Ab eines Regelkreises. Das ist erkennbar echtes Systemverhalten.

Was noch fehlt

Das Plugin ist Technology Preview - und das merkt man an den Rändern. Parametrik und die Simulation von Action-Verhalten sind nicht enthalten. Definitions werden kaum unterstützt; gearbeitet wird im Wesentlichen mit Usages. Einheiten und Größen berücksichtigt die Simulation nicht, was bei physikalischen Größen Vorsicht verlangt. Und die Richtung gerichteter Features an Ports wird nicht geprüft: Der Payload wird übertragen, ob die Richtung stimmt oder nicht.

Fünf Stolperfallen aus der Praxis

Erstens: Modelliere Verhalten über Parts (usage) mit Exhibit State. Direkt verwendete States verhalten sich unerwartet - auch die Beispiele des Herstellers nutzen Exhibit States, und semantisch passt es besser.

Zweitens: Setze den Initial Node explizit. Fehlt er, startet die Simulation alle Zustände, auf die keine Transition zeigt. Das kann zu unnötiger Ambiguität führen.

Drittens: Nur Werte mit := sind zur Laufzeit editierbar. Wer Werte während der Simulation verändern will, muss das so modellieren.

Viertens: Für Payload-Transfer müssen Sender und Empfänger in einem gemeinsamen Kontext liegen - ein umgebendes Part, das beide enthält.

Fünftens: Nutze die Konsole. Bei schnellen Abläufen sieht man Zwischenschritte im Diagramm nicht, im Log dagegen jeden Wertwechsel.

Ausblick: Simulation trifft KI

Parametrik sowie Einheiten und Größen sind angekündigt. Spannender ist aber die Kombination, die sich abzeichnet: Simulation als automatisierte Rückmeldung für KI-gestützte Modellierung. Wenn generierte Modelle nicht nur syntaktisch geprüft, sondern ausgeführt werden können, entsteht ein Korrekturzyklus, der ohne manuelles Nachrechnen funktioniert.

Der Einstieg ist unaufwändig: ein Part mit Exhibit State, zwei Zustände, eine Transition ohne Trigger. Dann Trigger ergänzen, ein Attribut mitlaufen lassen, eine Anforderung prüfen. Mehr braucht es nicht, um auf dem aktuellen Stand zu sein.

Hast du ein Thema, über das wir schreiben sollen? Lass es uns wissen.