Ein Zustandsdiagramm (oder Zustandsautomat) zeigt das dynamische Verhalten einer Anwendung. Es handelt sich um ein Diagramm mit Zuständen und Übergängen, die die Reaktion auf Ereignisse in Abhängigkeit vom aktuellen Zustand der Anwendung beschreiben. Zustandsautomaten werden seit Jahrzehnten im Hardware-Design verwendet. Und in den letzten Jahren auch mehr und mehr im Bereich der Softwareentwicklung. Besonders bei eingebetteten Echtzeitsystemen ist die Verwendung von Zustandsdiagrammen beliebt, da das Verhalten von Anwendungen und/oder Geräten in diesem Bereich oft sehr gut mit Zustandsdiagrammen beschrieben werden kann. Das Papier von D. Harel “Statecharts: A Visual Formalism for Complex Systems” aus dem Jahr 1987 ist immer noch eine Pflichtlektüre.

Ein wichtiger Aspekt von Zustandsdiagrammen ist, dass der Entwurf direkt in ausführbaren Code umgewandelt werden kann. Das bedeutet, dass es keinen Bruch zwischen dem Entwurf und der Implementierung gibt. Dies ist umso wichtiger, wenn das zu entwickelnde Gerät bestimmte formale Qualitätskriterien erfüllen muss (z.B. nach IEC61508). Bitte beachten Sie, dass der Code-Generator selbst in keiner Weise zertifiziert ist. Es liegt in Ihrer Verantwortung zu überprüfen und zu validieren, dass der generierte Code Ihre Anforderungen erfüllt!

SinelaboreRT wurde speziell für Entwickler von eingebetteten Echtzeitsystemen entwickelt. Es konzentriert sich auf eine einzige Aufgabe: Codegenerierung aus Zustandsdiagrammen. Ein Kommandozeilenwerkzeug und eine Konfigurationsdatei sind alles, was benötigt wird.

Der generierte Code basiert auf verschachtelten switch/case und if/then/else Anweisungen. Er ist leicht zu lesen und zu verstehen. Der generierte Code bereitet bei der Verwendung von statischen Code-Analysatoren kein Kopfzerbrechen.

SinelaboreRT engt Sie in keiner Weise bei der Wahl der Systemarchitektur ein. Daher ist es kein Problem, den generierten Code im Kontext eines Echtzeitbetriebssystems oder innerhalb einer Interrupt-Service-Routine oder in einem Vordergrund-/Hintergrundsystem zu verwenden. Der Generierungsprozess kann beeinflusst werden, um spezifische Anforderungen zu erfüllen.

Wie arbeitet SinelaboreRT? Aus einer mit dem Cadifra UML-Editor, Enterprise Architect, UModel oder Magic Draw … erstellten Zustandsdiagramm generiert der Code-Generator die komplette Statemachine-Implementierung. Für eine Beispieldatei namens oven.cdd sieht die Befehlszeile wie folgt aus:

java -cp "path_to_coden_jar:*" codegen.Main -p CADIFRA -o oven oven.cdd 

Als Ergebnis werden Dateien erzeugt:

• oven.c implementiert die State-Machine, wie sie in der Datei oven.cdd grafisch dargestellt ist
• oven_ext.h definiert die Ereignisse (Events), die an die State-Machine gesendet werden können
• oven_dbg.h definiert Funktionen, die Sie beim Debuggen unterstützen
• oven.h definiert die Funktionsprototypen, Zustände usw., die in der State-Machine verwendet werden.

Diese Dateien realisieren den kompletten Zustandsautomaten. Sie sind in klar lesbarem Zielsprachencode und können von jedem C/C++-Programmierer verstanden und überprüft werden.

Hierarchische Zustandsdefinition: Zustandsautomaten können hierarchisch oder flach sein. Ein Zustand mit Unterzuständen wird als hierarchischer Zustandsautomat bezeichnet. Zustände können einen Eintrittscode definieren (Entry Code), der immer ausgeführt wird, wenn ein Zustand betreten wird. Exit-Code wird ausgeführt, wenn der Zustand verlassen wird. Ein Zustand kann auch einen Aktionscode haben. Der Aktionscode wird immer dann ausgeführt, wenn der Zustand aktiv ist, kurz bevor Ereignisübergänge ausgewertet werden.

Regionen : Regionen ermöglichen die Modellierung parallelen Verhaltens innerhalb desselben Zustandsdiagramms. Der Vorteil der Verwendung von Regionen besteht darin, dass dieses parallele Verhalten explizit dargestellt werden kann, anstatt verschiedene Zustandsdiagramme zu erstellen.

Transitionen: Es gibt zwei Arten von Übergängen: a) ereignisbasierte Übergänge und b) bedingte Übergänge. Ereignisbasierte Übergänge sind Auslöser (Trigger), die von außerhalb einer State-Machine kommen. Ein ereignisbasierter Übergang hat die folgende Syntax: eventName[guardExpression]/action. Ein bedingter (oder wenn) Übergang wird nicht durch ein Ereignis ausgelöst, sondern durch einen C-Ausdruck, der zu wahr ausgewertet wird (z.B. Portpin gesetzt). Sie hat die Syntax: #condition/action.

Choice States: Die OMG UML-Spezifikation besagt: …Choice States, die, wenn sie erreicht werden, zu einer dynamischen Guard-Auswertung des Triggers der ausgehenden Transitionen führen. Damit wird eine dynamische bedingte Verzweigung realisiert. Es ermöglicht die Aufteilung von Transitionen in mehrere ausgehende Pfade, so dass die Entscheidung über den zu wählenden Pfad eine Funktion der Ergebnisse früherer Aktionen sein kann, die im selben Schritt der Ausführung durchgeführt wurden.

Historische Zustände: Wenn ein hierarchischer Zustand verlassen und das nächste Mal betreten wird, wird in der Regel der Standardzustand verwendet. Wenn stattdessen der letzte aktive Zustand betreten werden soll, kann ein History Marker (flat history) in den Zustand gesetzt werden. Wenn Sie die Historie für alle Unterzustände des Zustands aktivieren wollen, verwenden Sie stattdessen eine sog. tiefe Historienmarkierung (deep history). Es werden Makros bereitgestellt, um die Historie bei Bedarf zurückzusetzen.

Interaktiver Test und Simulation: Wenn das Kommandozeilenflag -s (für Simulation) verwendet wird, wechselt der Codegenerator nach dem Parsen der Eingabedatei in den interaktiven Modus. Es wird dann kein Code erzeugt. Nach dem Parsen der Eingabedatei können Sie Ereignisse eingeben und prüfen, wie der Zustandsautomat reagiert. Während eines Simulationsschritts wird der gesamte Code, der als Reaktion auf ein Ereignis ausgeführt wird, ausgedruckt (z. B. der OnEntry-Code). Bei Verwendung des Kommandozeilenflags -S wird die grafische Simulation gestartet.

Debugging / Trace-Unterstützung: In der Datei *_dbg.h werden Hilfsfunktionen bereitgestellt, die für das Debugging von Zustandsautomaten nützlich sind. Die Funktion *_GetNameByState(id) gibt den Namen des Zustands zurück, die Funktion *_GetNameByEvent(id) gibt den Namen eines Ereignisses zurück, das jeweils durch seine ID identifiziert wird. Trace-Anweisungen können der Maschine automatisch hinzugefügt werden. Dies ermöglicht es, den Fluss der Ereignisse zu verfolgen.

Integrierter Zustandsdiagramm-Editor: Mit dem Befehlszeilen-Flag -E wird der integrierte Zustandsdiagramm-Editor aufgerufen. Er bietet eine effiziente baumbasierte Eingabemethode. Die grafische Darstellung wird automatisch erstellt. So können Sie sich voll und ganz auf die Modellierungsaufgabe konzentrieren. Für Windows und Mac werden statt des Jar Files auch Exe Files bereitgestellt, die direkt den integrierten Editor starten.

Laden sie die Testversion direkt herunter und testen Sie den Generator. Ihr Feedback ist willkommen!