MathWorks System Composer vs. SysML-Tools: Was passt zu deinem Projekt?

„Sollen wir unsere Systemarchitektur im MathWorks System Composer modellieren oder in einem SysML-Tool?" Diese Frage höre ich regelmäßig — meist von Teams, die bereits im MATLAB/Simulink-Ökosystem zu Hause sind und jetzt modellbasiertes Systems Engineering einführen. Die ehrliche Antwort: Es kommt darauf an. Aber es kommt auf Dinge an, die man konkret benennen kann. Hier sind die Dimensionen, die ich vergleiche.

Requirements-Handling und Tool-Integration

Hier spielen ausgereifte SysML-Tools ihre stärkste Karte aus. Sie bieten dedizierte Anforderungsmodellierung mit eigenen Requirements-Diagrammen, bidirektionale Traceability über alle Diagramme hinweg und die Verknüpfung von Anforderungen mit Testfällen. Sie integrieren sich gut mit externen Requirements-Management-Tools wie DOORS oder Polarion, und ihre Kollaborationsfunktionen sind für Teams gebaut, die standortübergreifend an einem Modell arbeiten.

Der System Composer deckt die Grundlagen ab: Anforderungen lassen sich mit Komponenten verknüpfen, und die Requirements Toolbox bringt ReqIF-Import und -Export von Haus aus mit. Aber Verifikation und Validierung hängen stark an Simulink-Modellen, tiefere Integration externer RM-Tools endet meist doch in eigenen Skripten, und die Kollaborationsfähigkeiten sind größtenteils an die Simulink-Welt gebunden.

Wenn dein Projekt von Requirements Traceability lebt — und in regulierten Umgebungen tut es das —, ist dieser Unterschied nicht kosmetisch.

Simulationsfähigkeiten

Hier dreht sich das Bild komplett.

SysML-Tools fokussieren auf Modellierung und konzeptionelle Simulation: überwiegend statisch, mit eingeschränkter Unterstützung für Echtzeit- und Embedded-Simulationen. Um dynamisches Verhalten zu simulieren, muss Simulink oder ein anderes Simulationswerkzeug integriert werden — inklusive Tool-Wechsel, um Simulationen auszuführen und Ergebnisse anzusehen.

Der System Composer wurde für genau das Gegenteil gebaut. Sein Heimspiel ist die detaillierte dynamische Simulation und Model-Based Design: Echtzeit-, dynamische und Embedded-Simulation mit nahtloser MATLAB/Simulink-Integration und direktem Feedback innerhalb eines Ökosystems. Wenn dynamische Simulation dein Tagesgeschäft ist, kommt kein SysML-Tool heran.

SysML-Sprachkonformität

Ein oft unterschätzter Faktor: SysML ist die gemeinsame Sprache der Systems Engineers.

Mit einem SysML-Tool sind neue Kolleginnen und Kollegen, die die Sprache kennen, schnell produktiv. Die Zusammenarbeit mit anderen Teams und externen Organisationen, die SysML-basierte Tools nutzen, ist unkompliziert, und die Integration in große Systems-Engineering-Projekte fällt leichter.

Der System Composer spricht seine eigene, toolspezifische Sprache. Neue Mitarbeitende mit SysML-Hintergrund müssen Konzepte neu lernen, und die Zusammenarbeit über Organisationsgrenzen hinweg braucht individuelle Lösungen.

Ein ehrlicher Einwand: Der „Common Ground"-Vorteil betrifft primär Menschen, nicht Daten. Der Austausch echter SysML-v1-Modelle zwischen Tools verschiedener Hersteller via XMI ist in der Praxis notorisch verlustbehaftet — Standardisierung garantiert also keine Tool-Portabilität.

Onboarding-Zeit

Das Sprachkonformitäts-Argument hat eine Kehrseite, die eine eigene Kategorie verdient: Wie schnell wird ein neues Teammitglied produktiv?

Für Ingenieure, die von Simulink kommen, ist die MathWorks-Toolchain schlicht leichter zu handhaben — gleiche Umgebung, gleiches Denkmodell, gleiche Skripte. Und unabhängig vom Hintergrund: Das Vokabular des System Composer ist deutlich kleiner als das von SysML v1, dessen schiere Menge an Elementtypen und Diagrammarten ein wohlverdienter Kritikpunkt ist. Selbst gegenüber dem gestrafften SysML v2 ist das System-Composer-Konzept leichter zu erfassen.

Aber dieser Vorteil ist an Bedingungen geknüpft. Für Teammitglieder ohne MATLAB-Hintergrund ist der MATLAB-zentrische Workflow eine eigene Lernkurve. Und ein kleines Vokabular schneidet in beide Richtungen: Fehlt der Sprache ein Konzept, das dein Projekt braucht — Viewpoints, Verfeinerungssemantik, Allokationsregeln —, beginnen Teams, es in Namenskonventionen und Stereotypen zu codieren. Die Komplexität verschwindet nicht; sie wandert in undokumentierte Projekt-Folklore.

Flexibilität und Scripting

Ein großes Plus der MathWorks-Welt: Mit dem richtigen .m-Skript kann man praktisch alles machen — von individuell angepassten HTML-Reports bis zu jeder erdenklichen Analyse, direkt gegen das Modell.

Fairerweise: SysML-Tools sind nicht skriptlos. Cameo hat seine Open API und Makro-Engines, Enterprise Architect eine vollständige Automatisierungsschnittstelle. Der eigentliche Unterschied ist, wer automatisieren kann: Jeder Simulink-Ingenieur schreibt ohnehin MATLAB, Automatisierung ist damit selbstverständlicher Teil der täglichen Arbeit. Ein SysML-v1-Tool zu automatisieren heißt dagegen meist Java-zentrische Plugin-Entwicklung, die nur ein dedizierter Tool-Spezialist anfasst. In der Praxis macht das die MathWorks-Toolchain für ein normales Engineering-Team deutlich anpassbarer.

Stakeholder-zentrierte Sichten auf das Modell

Dieses Kriterium ist nach meiner Erfahrung eines der entscheidendsten geworden — und es taucht in kaum einer Feature-Liste auf.

Früher oder später fragt ein Stakeholder nach einer Sicht: „Zeig mir alles, was die Software-Domäne umsetzen muss — Struktur, Verhalten und die zugeordneten Anforderungen." Das zu beantworten heißt, eine konsistente Sicht über strukturelle und verhaltensbezogene Elemente aus dem Modell herauszuschneiden.

Im System Composer ist das sehr schwer. Architecture Views sind filterbasiert, Allokationsbeziehungen können in keiner Architektursicht dargestellt werden, und wer getrennte Modelle für funktionale und physische Architektur pflegt — ein übliches und sinnvolles Muster —, für den ist eine modellübergreifende Sicht faktisch außer Reichweite.

SysML-Tools lösen das mit einem expliziten View/Viewpoint-Mechanismus, und SysML v2 macht Views zu Bürgern erster Klasse der Sprache: Ich kann jede benötigte Sicht definieren, Struktur und Verhalten kombinieren, und sie bleibt konsistent zum Modell. Wenn dein Prozess von Domänen-Übergaben lebt, gewichte dieses Kriterium hoch.

Integration von KI-Fähigkeiten

Eine Kategorie, die es zu Beginn dieses Vergleichs noch nicht gab — und die die Balance bereits verschiebt.

Einige Tools bringen integrierte KI-Chat-Assistenten mit, die schon viel können. Interessanter aber: MathWorks unterstützt einen offiziellen MCP-Server. Damit kann ein KI-Assistent wie Claude Code das gesamte Modell abfragen und mächtige Ad-hoc-Sichten darauf erzeugen — was die oben beschriebene Schwäche des System Composer bei der Präsentation von Modellinhalten teilweise kompensiert. Auf der SysML-Seite fehlen offizielle MCP-Server bislang größtenteils; Open-Source-Lösungen existieren, und zumindest der Cameo Systems Modeler bietet eine REST-API als Basis.

Zwei Einschränkungen, bevor du dieses Kriterium zu hoch gewichtest: Erstens bewegt sich dieses Feld schnell — der Abstand zwischen „offiziell" und „Community" kann in sechs Monaten anders aussehen. Zweitens ist eine LLM-generierte Sicht ad hoc und nicht deterministisch. Für Exploration und Q&A hervorragend — einen auditierbaren Viewpoint-Mechanismus für die Release-Dokumentation ersetzt sie nicht.

Kosten, Zugänglichkeit und Versionsverwaltung

Drei praktische Aspekte, die in Evaluierungen oft zu spät auf den Tisch kommen — und das sollten sie nicht:

Kosten. Absolut betrachtet sind beide teuer, und ein voll ausgestatteter MathWorks-Stack ist der teurere von beiden. Aber der Greenfield-Vergleich ist selten der realistische: Teams, die den System Composer evaluieren, zahlen meist bereits für MATLAB und Simulink — die Zusatzkosten sind eine weitere Toolbox. Ein SysML-Tool-Arbeitsplatz plus Kollaborationsserver ist dagegen ein komplett neuer Budgetposten. Rechne dein eigenes Delta, nicht die Listenpreise.

Zugänglichkeit und Cloud. Keines der Tools ist cloud-native — das Modell zu Kolleginnen und Kollegen ohne lokale Installation zu bringen, kostet Zusatzaufwand. SysML-Tools wie Cameo bieten einen serverbasierten Weg: Teamwork Cloud mit browserbasierter Publikation für Stakeholder ohne Tool-Lizenz. MathWorks bietet einen klickbaren HTML-Export und einen Weg über den MATLAB Web App Server, aber das Deployment muss angepasst werden — und der HTML-Export enthält keine Allokationen zwischen Modellen. Wieder das View-Problem. Beobachtenswert: Die neue Generation von SysML-v2-Tools ist häufig web-first, diese Lücke dürfte also eher größer werden.

Versionsverwaltung. SysML-Tools bringen typischerweise eine eingebaute, modellelement-basierte Versions- und Konfigurationsverwaltung mit — die bevorzugte Wahl für Teams, die parallel an großen Systemmodellen arbeiten. Der System Composer setzt auf klassische dateibasierte Versionskontrolle wie Git oder SVN, die nicht auf das Nachverfolgen einzelner Modellelemente spezialisiert ist.

Fazit: Es gibt keinen Sieger — es gibt einen Fit

Unterm Strich haben beide Tools ihre Vor- und Nachteile. Ohne die konkrete Situation und Motivation in deiner Organisation zu kennen, kann niemand seriös zum einen oder anderen raten. Aber zwei Muster zeichnen sich ab:

1. Wer in einem großen Systems-Engineering-Projekt mit vielen Anforderungen arbeitet, in dem viele Personen parallel am Modell arbeiten und regelmäßig Stakeholder maßgeschneiderte Sichten brauchen, profitiert klar von einem SysML-Tool. SysML als „Common Ground" erleichtert das Onboarding neuer Systems Engineers, und der View/Viewpoint-Mechanismus sorgt dafür, dass jede Domäne auf einen konsistenten Ausschnitt desselben Modells blickt.

2. Wenn nur eine begrenzte Zahl von Entwicklern parallel arbeitet — idealerweise mit Simulink-Erfahrung —, sind die SysML-Vorteile womöglich weniger ausschlaggebend. Wer vor allem dynamisches Verhalten in einer Echtzeitumgebung simulieren, direkt aus der bestehenden Simulink-Toolchain Code generieren und den Workflow mit Skripten automatisieren will, die die eigenen Ingenieure ohnehin schreiben können — für den ist der System Composer wahrscheinlich die richtige Wahl.

Und behalte die KI-Dimension im Blick: Offizielle MCP-Unterstützung beginnt, klassische Tool-Schwächen abzumildern — auf beiden Seiten dieses Vergleichs.

Die schlechteste Entscheidung ist die, die auf Annahmen statt Fakten basiert. Evaluiere gegen eigene Kriterien und mit eigenen Use Cases, bevor du dich festlegst — ein Thema, das einen eigenen Beitrag verdient.

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