Dieser Beitrag ist ein reiner Werkzeugvergleich. Wer zuerst verstehen möchte, was Statecharts sind und wie sie funktionieren, findet eine ausführliche Einführung auf statecharts.online und einen praktischen Einstieg am Beispiel einer Jalousiesteuerung in Modellieren mit Zustandsautomaten. Wer direkt zu Funktionsumfang und Lizenzmodell von itemis CREATE möchte, gelangt über die itemis CREATE Produktseite dorthin.
Reaktives, ereignisgesteuertes Verhalten steckt im Kern der meisten eingebetteten Systeme: ein medizinisches Beatmungsgerät, das Atemzyklen steuert, ein Automotive-ECU, das sicherheitskritische Funktionen koordiniert, eine industrielle Steuerung, die Prozessschritte sequenziert. Zur Spezifikation und Implementierung solcher Systeme eignen sich insbesondere Zustandsautomaten, wie sie z. B. in der UML definiert sind. Entscheidet sich ein Team für den Einsatz dieses Konzepts, dann muss es entscheiden, wie es zustandsbasierte Logik modelliert und implementiert — und die Wahl des Werkzeugs prägt Produktivität, Codequalität und Zusammenarbeit für Jahre.
Drei Werkzeuge begegnen mir in Kundenprojekten regelmäßig: MathWorks Stateflow, IBM Engineering Rhapsody und itemis CREATE. Allen gemeinsam ist das Thema Statecharts — doch sie vertreten sehr unterschiedliche Philosophien darüber, was ein Statechart-Werkzeug leisten soll.
Dieser Beitrag beleuchtet im Detail, was diese Alternativen bieten, wo sie sich unterscheiden und was sie tatsächlich kosten.
Ein Hinweis zur Transparenz
itemis CREATE ist unser Produkt. Wir haben es entwickelt, wir setzen es in Kundenprojekten ein, und wir stehen dahinter. Dies prägt natürlich unsere Perspektive. Wir haben uns bemüht, diesen Vergleich fair und sachlich zu gestalten, aber du solltest wissen, von welchem Standpunkt aus wir urteilen. Wo wir uns gegenüber einem Mitbewerber günstiger bewerten, legen wir die Begründung offen dar, damit du sie selbst einordnen kannst. Ich selbst beschäftige mich seit 2001 mit modellgetriebener Softwareentwicklung, seit 2006 bei itemis, und bin Product Owner von itemis CREATE. Unsere Kunden aus der Automobil- und Medizintechnik entscheiden sich dabei je nach Projektrahmen für itemis CREATE oder für eines der beiden anderen Werkzeuge.
Drei Werkzeuge, drei Philosophien
MathWorks Stateflow ist ein Add-on für MATLAB und Simulink. Es ist tief im MathWorks-Ökosystem verwurzelt. Das ist seine größte Stärke und gleichzeitig seine deutlichste Einschränkung. Teams, die Simulink bereits für die Regelungstechnik einsetzen, profitieren von nahtloser Simulation und Codegenerierung über ihr gesamtes Modell. Teams, die das nicht tun, müssen den vollständigen Stack erwerben, nur um Statecharts nutzen zu können.
IBM Engineering Rhapsody ist kein reines Statechart-Werkzeug, es ist eine vollständige UML/SysML-Modellierungsumgebung. Statecharts sind nur einer von vielen Diagrammtypen, neben Klassendiagrammen, Sequenzdiagrammen, Aktivitätsdiagrammen und AUTOSAR-Unterstützung. Diese Breite macht es für große, spezifikationsgetriebene Systems-Engineering-Projekte geeignet. Für die Generierung von eingebettetem und echtzeitfähigem C/C++-Code ist in der Regel ein separates Framework wie RXF (von SodiusWillert) erforderlich, was Kosten und Integrationsaufwand erhöht.
itemis CREATE (ehemals YAKINDU Statechart Tools) ist speziell für Statechart-Modellierung, Simulation und Codegenerierung entwickelt worden. Der Scope ist bewusst schmaler als der von Rhapsody — das Werkzeug tut eine Sache und tut sie gut. Es unterstützt C, C++, Java, Python, C# und SCXML, läuft als Desktop-Anwendung, VS-Code-Extension und Web-App und richtet sich an das gesamte Spektrum vom Bare-Metal-Mikrocontroller bis zur JVM-basierten Serverkomponente.
Detaillierter Funktionsvergleich
| Feature | Stateflow (MathWorks) | IBM Rhapsody | itemis CREATE |
|---|
| Zielgruppe | Regelungs- und Systemingenieure in MATLAB/Simulink-basierten Workflows | Systemarchitekten und -ingenieure in sicherheitskritischen, spezifikationsgetriebenen Umgebungen | Softwareentwickler und -architekten, interdisziplinäre Entwicklungsteams, Rapid Prototyping |
| Lernkurve | ⚠️ Moderat — leistungsstark für Regelungsingenieure, aber weniger zugänglich für Softwareentwickler oder funktionsübergreifende Teams | ❌ Hoch — hohe Einstiegshürde durch UML/SysML-Komplexität; formale Schulung und langes Onboarding erforderlich | ✅ Flach — intuitive Modellierungsoberfläche, gute Dokumentation, schnelles Onboarding |
| Lizenzmodell | ⚠️ Nur kommerziell, modulare Preisgestaltung. Versteckte Kosten für viele wesentliche Funktionen. | ⚠️ Hochpreisig, Enterprise-Lizenzierung. Typischerweise langfristige Bindungen erforderlich. | ✅ Transparent, voller Funktionsumfang in einer Lizenz. |
| Umfang der Modellierungsumgebung | ⚠️ Statecharts & Blockdiagramme — leistungsstark für Signalflussmodellierung, aber Overhead bei reiner Statechart-Logik | ⚠️ Breiter UML-Scope — nützlich für Systemarchitekten, aber zu generisch und überladen für fokussierte Implementierung | ✅ Reine Statecharts — zweckorientiert, saubere Trennung der Logik, vollständige SCXML-Konformität, optionale Code-Annotationen |
| Plattformverfügbarkeit | ⚠️ Desktop und Web — erfordert MATLAB/Simulink-Suite oder Simulink Online | ❌ Nur Desktop | ✅ Desktop, Web-App, VS-Code-Extension |
| Anpassbarkeit und Erweiterbarkeit | ⚠️ Eingeschränkte Anpassung — hauptsächlich über MATLAB-Skripte und proprietäre Erweiterungen | ⚠️ Erweiterbar, aber stark an das IBM-Ökosystem gebunden | ✅ Offene APIs, vollständig anpassbare Codegeneratoren, erweiterbare textuelle DSLs |
| Grafischer Editor | ⚠️ Gut mit Simulink integriert, aber unübersichtlich für Nicht-Regelungsingenieure | ⚠️ Voll ausgestatteter Editor, aber optisch veraltet und weniger intuitiv | ✅ Saubere, leichtgewichtige, intuitive Benutzeroberfläche |
| Simulation & visuelles Debugging | ✅ Sehr leistungsstarke Simulation — erfordert den vollständigen MATLAB/Simulink-Stack und Konfigurationsaufwand | ⚠️ Debugging möglich, aber komplexes Setup und eingeschränkte Interaktivität; Visualisierung wenig unmittelbar | ✅ Eingebaute Simulation, intuitiv und schnell |
| Codegenerierung | ⚠️ C/C++ über Simulink Coder (optionales Add-on) | ⚠️ Generiert C (optional C++) mit IBM-spezifischen Mustern — weniger Kontrolle über Struktur, Lesbarkeit oder Portabilität | ✅ Generiert sauberen, portablen Code in C, C++, Java, Python, C# — kein Vendor-Lock-in |
| SCXML-Unterstützung | ❌ Nein | ❌ Nein | ✅ Ja |
| Integration mit handgeschriebenem Code | ⚠️ Unterstützt den Aufruf externer C-Funktionen — Integration auf vordefinierte Schnittstellen begrenzt, abhängig von Simulinks Build-Umgebung | ⚠️ Unterstützt den Aufruf externer C-Funktionen — enge Kopplung macht iterative Entwicklung weniger praktikabel | ✅ Tiefe Integration mit handgeschriebenem C/C++- und Java-Code — Modell und Code Seite an Seite für kooperative Entwicklung |
| Verifikation & Validierung | ✅ Simulink Design Verifier, Simulink Coverage (optionale Toolboxen) — fortgeschrittene V&V möglich, aber separate Toolboxen und tiefes Simulink-Wissen nötig | ⚠️ Model Checking, Konsistenzprüfungen, Testintegration — für Entwickler weniger zugänglich; Setup- und Nutzungskomplexität deutlich höher | ✅ Live-Validierung, eingebautes Test-Framework SCTUnit, Coverage-Analyse (SCov) |
| Hierarchische Modellierung | ✅ Composite States und parallele, interagierende Zustandsmaschinen | ✅ Composite States und parallele, interagierende Zustandsmaschinen | ✅ Composite States und parallele, interagierende Zustandsmaschinen |
| Zusammenarbeit & Multi-User-Support | ⚠️ Kollaboration über Simulink Projects | ✅ Zentralisierte Multi-User-Infrastruktur, Repository- und Lizenzverwaltung | ✅ Git/SVN-Integration, modellbasierte Diff- & Merge-Tools inklusive |
| Web-Einbettbarer Player / Interaktive Dokumentation | ❌ Nicht unterstützt | ❌ Nicht unterstützt | ✅ Dynamischer Export als interaktiver HTML-Player — verwandelt Modelle in lebendige Dokumentation, einbettbar in Jira, DOORS oder Wikis |
| Headless-Codegenerierung / CI-Integration | ⚠️ Ja — erfordert MATLAB-Lizenzierung auf Build-Agents, komplexes Scripting und hohen Ressourcenbedarf zur Laufzeit | ⚠️ Ja — Kommandozeilenintegration möglich, erfordert aber Wrapper-Skripte und tiefes Werkzeugwissen | ✅ Einfache, konfigurierbare Headless-Codegenerierung über CLI/CI |
Was die Tabelle nicht zeigt: Preise
Funktionsvergleiche können verdecken, dass diese Werkzeuge sehr unterschiedlichen Preissegmenten angehören. Hier sind die relevanten Zahlen, basierend auf öffentlich verfügbaren Informationen und Sekundärquellen, Stand Sommer 2026 (mit * markierte Angaben stammen aus Sekundärquellen und sind nicht herstellerseitig bestätigt):
| Stateflow (vollständiger Stack) | IBM Rhapsody Developer + RXF | itemis CREATE |
|---|
| Jährliche Kosten pro Arbeitsplatz | ≥ 5.000 € / Jahr* (MATLAB + Simulink + Stateflow + Embedded Coder) | ~2.800–6.800 € / Jahr* (Rhapsody-Abo + RXF) | 1.350 € / Jahr |
| Dauerlizenz (Kauf) | ~7.850 € + 1.413 € / Jahr Support (ohne Embedded Coder) | ~6.000–10.000 € + ~20 % Wartung p.a.* | Verfügbar (Single/Floating/Dongle) |
Um den Kostenunterschied konkret zu machen: Für ein Team aus drei Entwicklern über ein dreijähriges Projekt vergleichen sich die reinen Werkzeuglizenzkosten ungefähr so:
| Werkzeug | 3 Entwickler × 3 Jahre | Hinweis |
|---|
| MathWorks Stateflow | ≥ 45.000 €* | Voller Stack je Entwickler erforderlich |
| IBM Rhapsody + RXF | ~20.000–30.000 €* | Zzgl. einmaliger RXF-Lizenz je Arbeitsplatz |
| itemis CREATE | ~12.150 € | Skaliert mit Teamgröße und Projektlaufzeit |
Der Stateflow-Stack kostet über einen typischen Projektzyklus mehr als das Dreifache — ein Unterschied, der noch stärker ins Gewicht fällt, wenn man bedenkt, dass viele Teams Stateflow nur für Statechart-Modellierung benötigen und dabei für die gesamte Simulationsplattform drumherum zahlen.
Welches Werkzeug für welchen Kontext?
Stateflow wählen, wenn das Team bereits tief im MATLAB/Simulink-Ökosystem verwurzelt ist. Dies ist der Fall etwa beim modellbasierten Reglerentwurf, wo kontinuierliche Simulation und diskrete Zustandslogik eng verzahnt sein müssen. Wer neu anfängt und primär Zustandsmaschinen braucht, zahlt für den gesamten Stack einen erheblichen Aufpreis.
IBM Rhapsody wählen, wenn es sich um ein großes, spezifikationsgetriebenes Systems-Engineering-Projekt handelt, das die volle Breite von UML und SysML benötigt — Use-Case-Modellierung, Klassenhierarchien, Sequenzdiagramme, AUTOSAR-Integration — und Statecharts nur eine Komponente eines umfassenderen Modellierungsvorhabens sind. Dabei sind zusätzliche RXF-Lizenzkosten und Integrationsaufwand in eingebetteten Kontexten einzuplanen.
itemis CREATE wählen, wenn der primäre Bedarf Statechart-Modellierung mit sauberer, portabler und einfach zu integrierender Codegenerierung für unterschiedliche Zielsprachen ist. Die Codegenerierung deckt Bare-Metal- und RTOS-basierte Embedded Systems ebenso ab wie skriptbasierte, JVM- und .NET-basierte Anwendungen. Das Werkzeug eignet sich besonders für interdisziplinäre Teams, in denen Hardware-Experten, Softwareentwickler und Fachdomänen-Spezialisten über gemeinsame Modelle kommunizieren müssen. Einzellizenz-Preismodell, flache Lernkurve und CI-fähiger Headless-Generator machen es zur praktischen Wahl für Teams, die ohne komplexen Werkzeug-Stack schnell vorankommen wollen. Wer dagegen die volle Breite von UML und SysML oder die enge Kopplung an kontinuierliche Regelstreckensimulation benötigt, ist mit Rhapsody beziehungsweise Stateflow besser bedient.
Modellgetriebene Softwareentwicklung bei itemis — Statecharts modellieren, simulieren und produktionsreifen Code generieren: Modellgetriebene Softwareentwicklung →