Einführung in die Modellbildung und Simulation mit Stateflow Urban Brunner

1 Einleitung

Technische Systeme müssen auf Ereignisse reagieren. Dazu benötigen sie eine Steuerlogik, die den zu automatisierenden Prozess beim Auftreten solcher Ereignisse in gewünschter Weise beeinflusst. Man spricht auch von reaktiven Systemen. Ist das dynamische Verhalten eines technischen Prozesses ursächlich sowohl durch zeitkontinuierliches Verhalten, meist beschrieben durch Differentialgleichungen, als auch durch reaktives ereignisgetriebenes Verhalten geprägt, so liegt ein gemischt kontinuierlich-diskretes System, ein sog. hybrides System vor. Beispiele hybrider Systeme sind gesteuerte Produktionsprozesse, Regelungen mit veränderlicher Struktur, Verkehrssysteme - im Grunde genommen alle hierarchisch organisierten Systeme. Ein hybrides System besteht aus einem oder mehreren kontinuierlichen zeitgetriebenen Teilsystemen und mindestens einem bzw. mehreren diskreten ereignisgetriebenen Teilsystemen. Stateflow ist ein Zusatz zu Simulink, um hybride Systeme beschreiben und mittels animierter Simulation analysieren zu können. In Stateflow wird ein ereignisgetriebenes System graphisch und dessen Schnittstelle zu einem mit Simulink-Blöcken beschriebenen zeitgetriebenen System textuell spezifiziert. Formal basiert Stateflow auf (erweiterten) Zustandsautomaten und orientiert sich an der von Harel [1] eingeführten Notation für Statecharts. Statecharts schließen die üblichen Modellarten zur Beschreibung diskreter Systeme ein. Einen guten Überblick über die gebräuchlichsten Modellarten, wie Endliche Automaten, Markov-Ketten, Petri-Netze und Warteschlangen, vermittelt [2].

Stateflow ist als eine Erweiterung von Simulink konzipiert, wobei eine benutzerfreundliche Oberfläche und eine durchgängige Unterstützung beim Entwurf von reaktiven Systemen im Vordergrund stehen [3]. Insbesondere unterstützt Stateflow die Modellbildung von hierarchisch aufgebauten ereignisgetriebenen Systemen. So können größere Modelle strukturiert, d.h. bottom-up und/oder top-down, entwickelt werden. Die Interaktion zwischen den ereignisgetriebenen Teilsystemen beruht auf der synchronen Kooperation [4], [5]. Überdies können mit Stateflow Entscheidungssituationen graphisch beschrieben werden in einer an Flussdiagrammen orientierten Form, die auch den Aufruf von MATLAB- und C-Funktionen zulässt. Schließlich kann aus der Modellbeschreibung mit Stateflow Coder und Real-Time Workshop ausführbarer Code generiert werden. Dadurch wird die Konsistenz zwischen beschriebenem Modell bzw. simuliertem Verhalten und implementiertem Code garantiert. Anhand der Konstruktion eines einfachen Beispiels wird in Kapitel 2 das Werkzeug Stateflow vorgestellt. Die eigentliche Modellbildung mit Stateflow wird dann in Kapitel 3 gezeigt. In Kapitel 4 werden einige Besonderheiten der Notation und Semantik von Stateflow dokumentiert. Für eine Beschreibung aller Stateflow Menus und Befehle wird auf das Manual [3] sowie die integrierte Help-Funktion sfhelp verwiesen. Schließlich wird in Kapitel 5 anhand eines kleinen Projekts ein systematischer Steuerungsentwurf mittels Stateflow demonstriert.

2

Einführung in die Modellbildung und Simulation mit Stateflow Urban Brunner

2 Konstruktion und Simulation eines einfachen Simulink/Stateflow-Modells

Um mit Stateflow arbeiten zu können, muss zuerst MATLAB gestartet werden. Mittels Eintippen von sfnew in das MATLAB-Kommandofenster oder mittels Doppelklick auf New Chart im Launch Pad wird ein neues Simulink Model mit einem leeren Chart-Block erzeugt. Ein Chart-Block, auch Stateflow-Block genannt, ist ein Simulink-Baustein und muss demzufolge immer in einem Simulink-Modell eingebettet sein. Ein Stateflow System, eine sog. Stateflow Machine, besteht aus einem oder mehreren Chart- Blöcken,die wie gewöhnliche Subsysteme in Simulink durch Eingangs- und Ausgangssignale mit andern Simulink-Blöcken interagieren und auf den MATLAB-Workspace Zugriff haben (vgl. Abb. 2-1). Das Erstellen eines Stateflow Systems geschieht objektorientiert und zwar auf zwei Stufen. Einerseits werden graphische Objekte mit dem Editor zu einem Zustandsdiagramm zusammengebaut. Anderseits werden mit dem Explorer über Dialogfenster die nicht-graphischen Objekte Events und Data definiert, die im Wesentlichen das Interface zum umgebenden Simulink-Modell beschreiben.

Abb. 2-1: Verbund von MATLAB, Simulink und Stateflow

3

Einführung in die Modellbildung und Simulation mit Stateflow Urban Brunner

2.1 Der Editor

Der Editor wird durch Doppelklicken auf den Chart-Block gestartet. Mit dem Editor können per Maus graphische Elemente, wie Zustände und Transitionen, zu einem Zustandsdiagramm zusammengebaut werden. Abb. 2-2 zeigt das Stateflow Editor Fenster. Am linken Rand ist die Objektpalette für die graphischen Elemente zu erkennen, die mittels Drag and Drop auf die Arbeitsfläche gezogen und miteinander verknüpft werden können. Auf der Arbeitsfläche ist das Stateflow Diagram des Simulink-Modells stoppuhr.mdl zu sehen. Das dargestellte Zustandsdiagramm besteht aus den drei Zuständen (bezeichnet als Ruheszustand, Zeit_steht und Zeit_läuft) sowie den vier Transitionen (bezeichnet als Start, Stop und Reset).

Abb. 2-2: Das Stateflow Editor Fenster (stoppuhr.mdl)

Ein Zustand wird eingefügt, indem man im linken Toolbar auf das Icon State klickt und dieses auf die Arbeitsfläche zieht. Durch Loslassen der linken Maustaste wird der Zustand auf der Arbeitsfläche platziert. Die Größe des den Zustand darstellenden Rechtecks kann durch Ziehen an den Ecken verändert werden, wodurch u.a. eine Verschachtelung von Zuständen graphisch dargestellt werden kann. Transitionen können direkt; d.h. ohne Anklicken eines Icons gezeichnet werden. Dazu wird der Mauszeiger auf den Rand des Ausgangszustands bewegt, wo der Mauszeiger die Form eines Fadenkreuzes annimmt. Nun drückt man die linke Maustaste und bewegt die Maus bei gedrückter Taste zum Destinationszustand. Zustände und Transitionen werden durch Anklicken des zugehörigen Fragezeichens und Eintippen eines Namens bezeichnet. Dabei können auch die ggf. auszuführenden Aktionen in Form von MATLAB-Anweisungen eingegeben werden. Ist das Fragezeichen einer Transition im Fenster

4

Einführung in die Modellbildung und Simulation mit Stateflow Urban Brunner

nicht sichtbar, so genügt ein Anwählen der Transition durch Mausklick und es wird wieder angezeigt. Zustände und Transitionen können per Maus (linke Taste gedrückt halten und Maus ziehen) zu einer Gruppe zusammengefasst und dann als Gruppe verschoben werden.

Stateflow kennt im wesentlichen zwei Arten von auszuführenden Aktionen; nämlich Aktionen, die je nach Status eines Zustands und solche, die bei einem Zustandsübergang ausgeführt werden. Die Aktionen des Beispiels stoppuhr.mdl sind selbst erklärend. So werden mit entry:Zeit=0 beim Eintritt in den Ruhezustand die Variable Zeit gleich null gesetzt und mit ml(’tic’) beim Zustandsübergang Start die MATLAB-Funktion tic aufgerufen. Mit den MATLAB-Funktionen tic und toc kann die in der Zwischenzeit verstrichene CPU-Zeit bestimmt werden. Die eigentliche Syntax der Action Language wird in Kapitel 4.1 beschrieben. Um die nicht-graphischen Objekte einer Stateflow-Machine zu definieren, wird der Explorer über den entsprechenden Button im (horizontalen) Toolbar, mittels rechter Maustaste oder mit Tools.Explore... aufgerufen.

2.2 Der Explorer

Wie bereits erwähnt, wird mit dem Explorer das Interface zum zugehörigen Simulink-Modell definiert. Abb. 2-3 zeigt das Explorer Fenster. Im linken Teil des Fensters ist die Objekthierarchie zu sehen. Aggregierte Objekte, z.B. verschachtelte Zustände können durch Doppelklicken auf den Namen expandiert werden. Die Stateflow-Machine von stoppuhr.mdl enthält nur einen Chart-Block (den Chart-Block Zeitmesser), der seinerseits aus drei (nicht weiter zu expandierenden) Zuständen besteht. Im rechten Teil des Fensters sind die auf der angewählten Hierarchiestufe definierten nicht-graphischen Objekte aufgelistet. Auf Stufe Zeitmesser sind vier Ereignisobjekte (bezeichnet mit Start, Stop, Reset und Enable) sowie zwei Datenobjekte (bezeichnet mit DT und Zeit) definiert.

Abb. 2-3: Das Stateflow Explorer Fenster (stoppuhr.mdl)

5

Einführung in die Modellbildung und Simulation mit Stateflow Urban Brunner

Nicht-graphische Objekte werden mittels dem Menü Add eingefügt. Dabei müssen Sichtbarkeitsregeln beachtet werden. Jeder Event und jedes Data gehört zu dem Zustand (is parented by), in dem sie definiert werden. Deren Sichtbarkeit beschränkt sich auf diesen und die darunter liegenden Zustände. Selbstverständlich sollten bei einer größeren Stateflow-Machine Objekte möglichst lokal definiert werden, um Namenskonflikte und ungewollte Seiteneffekte zu vermeiden. Die Eigenschaften der Objekte, wie Name, Scope, Trigger etc., werden durch Anklicken des entsprechenden Felds und einer Eingabe spezifiziert. Im Beispiel stoppuhr.mdl sind die vier Ereignisse als steigende oder fallende Flanken (Trigger: Either) von Signalen aus dem Simulink-Modell (Scope: Input from Simulink) definiert. Die Variablen DT und Zeit sind vom Type double und werden mit null initialisiert, wobei DT als lokale Variable und Zeit als Output Signal zum Simulink-Modell definiert sind. Das Interface zum Simulink-Modell (vgl. Abb. 2-4) besteht somit aus einem Triggereingang mit vier Komponenten sowie einem Ausgangsport. Der Block Manual Switch gehört zur Simulink-Library Nonlinear. Während der Simulation können durch Doppelklick auf die manuellen Schalter die Ereignisse Start, Stop und Reset generiert werden. Durch ein Start-Ereignis wird die Stoppuhr gestartet. Nach einem Stop-Ereignis wird die abgelaufene Zeit im Display-Block angezeigt.

Abb. 2-4: Simulink-Modell mit Chart-Block Zeitmesser (stoppuhr.mdl)

2.3 Interpretation von Zustandsdiagrammen

Bevor ein Simulink-Modell, das ein Stateflow-Diagramm enthält, simuliert werden kann, muss die Update Method im Menu File.Chart Properties spezifiziert werden (vgl. Abb.

6

Einführung in die Modellbildung und Simulation mit Stateflow Urban Brunner

2-5). Die Update Methode bestimmt die Zeitpunkte, an denen die Simulationsroutine, der sog. Solver, die Zustandsdiagramme aufweckt und auswertet. Neben der Wahl der Auswertungszeitpunkte ist die Interpretation einer Statechart durch die Auswertung zu diesen Zeitpunkten gegeben. Eine durch ein Ereignis aufgeweckte Statechart wird prinzipiell top-down ausgewertet; d.h. von oben nach unten in der Objekthierarchie dieser Statechart. Oben in der Hierarchie steht die Chart selbst. Auf der nächsten Stufe stehen die direkt nachkommenden Zustände, und diese wiederum werden gefolgt von deren Nachkommen (sog. Substates) und so fort. Auf jeder Stufe der Hierarchie wird für die jeweils aktiven Zustände zunächst geprüft, ob during- oder on event_name-Aktionen (vgl. dazu auch Kapitel 4.1) auszuführen sind und werden ggf. auch ausgeführt, und erst dann wird geschaut, ob unter den Nachkommen dieser aktiven Zustände gültige Transitionen vorkommen, die dann schließlich auch ablaufen werden.

Abb. 2-5: Stateflow Editor Menu File und Dialogmaske Chart Properties...

7

Einführung in die Modellbildung und Simulation mit Stateflow Urban Brunner

Da auf der obersten Stufe (Stufe Chart) keine during- oder on event_name-Aktionen auszuführen sind, ergeben sich folgende Schritte beim Eintreffen eines Ereignisses:

1. Es wird geprüft, ob auf Stufe Chart unter den direkt nachkommenden Zuständen Transitionen ablaufen können. 2. Gültige (engl. valid) Transitionen laufen ab.

3. Für die verbleibenden aktiven Zustände werden gegebenenfalls during- und/oder on event_name-Aktionen ausgeführt.

4. Es wird geprüft, ob aus einem Substate heraus oder unter Substates Transitionen ablaufen können. (Dies entspricht dem 1. Schritt, nun auf Stufe Zustände.) Gehe zu Schritt 2 und führe die Schritte 2 bis 4 für die in der Hierarchie nachkommenden Zustände aus.

Diese Schritte werden solange wiederholt, bis alle Hierarchiestufen abgearbeitet sind. Da Stateflow parallele Zustände kennt (vgl. Kapitel 3.3), können auf einer Hierarchiestufe mehrere Zustände gleichzeitig aktiv sein. In Stateflow muss daher eine Abarbeitungsreihenfolge (sog. Aktivierungsreihenfolge) unter den jeweils aktiven Zuständen einer Hierarchiestufe festgelegt sein. Klare Kenntnisse dieser Aktivierungsreihenfolge sind für eine saubere und korrekte Modellbildung erforderlich. Leider kann die Semantik einer graphischen Programmiersprache nicht so kompakt beschrieben werden. Deshalb werden jeweils an passender Stelle, insbesondere in Kapitel 3.3 und in 4.1 entsprechende Hinweise gegeben.

Nachfolgend wird die Auswertung einer Statechart für die übliche Wahl Triggered or Inherited erläutert. Nebenbei diese Wahl ist auch defaultmäßig eingestellt. Bei dieser Update-Methode bestimmen die Inputs aus dem Simulink-Modell die Auswertungszeitpunkte. Sind Input-Ereignisse definiert, so triggern diese die Auswertung. Sind nur Input-Data und keine Input-Ereignisse definiert, so werden die Erneuerungszeitpunkte des „schnellsten“ Input Signals als Auswertungszeitpunkte übernommen. Sind weder Input-Ereignisse noch Input-Data definiert, so wird die Auswertung mit der vom Simulink-Solver bestimmten Sample-Rate angestoßen.

Im Beispiel stoppuhr.mdl sind Input-Ereignisse definiert (vgl. Abb. 2-3) und die Update-Methode Triggered or Inherited gewählt. Somit triggert jeweils das Auftreten eines Ereignisses die Auswertung des Zustandsdiagramms und löst dadurch gegebenenfalls Zustandsübergänge und/oder Aktionen aus. Durch die Bezeichnung der Transition vom Zustand Zeit_steht zum Zustand Zeit_laeuft mit Start (vgl. Abb. 2-2) wird diese Transition mit dem Ereignis Start verknüpft. Beim Auftreten eines Ereignisses Start und unter der Voraussetzung, dass zu diesem Zeitpunkt der Zustand Zeit_steht aktiv ist, ist diese Transition gültig und der Zustandsübergang findet statt. Mit einer allfälligen Transition sind implizite lokale Ereignisse verbunden. So wird durch Stateflow vor dem Verlassen eines Zustands das implizite Ereignis exit ausgelöst und die zugeordnete Exit-Aktion ausgeführt. Im Beispiel stoppuhr.mdl wird DT=0 gesetzt. Daraufhin wird der Zustand Zeit_steht als inaktiv markiert und erst dann wird die der Transition zugeordnete Aktion (hier: ml(’tic’)) ausgeführt.

8

Einführung in die Modellbildung und Simulation mit Stateflow Urban Brunner

Anschließend werden der Zustand Zeit_laeuft als aktiv markiert und aufgrund des impliziten Ereignisses entry ggf. eine Entry-Aktion (hier: keine) ausgeführt. Damit ist die Auswertung für diesen Zeitpunkt abgeschlossen.

Zu Beginn der Simulation ist kein Zustand als aktiv markiert. Dazu dient die Defaulttransition (vgl. Abb. 2-2). Beim ersten Aufwecken einer Chart wird die Defaulttransition, bzw. für parallele Zustände werden die Defaulttransitionen ausgeführt und die entsprechenden Zustände als aktiv markiert. Im Simulink-Modell stoppuhr.mdl wird mittels dem Step-Block zu Beginn der Simulation ein Ereignis Enable generiert, um den Anfangszustand (bezeichnet mit Ruhezustand) als aktiv zu markieren.

2.4 Simulation und Animation von Zustandsdiagrammen

Für die Generierung von ausführbarem Code muss das erstellte Zustandsdiagramm, der Chart-Block, mit Informationen über den Ziel Code (Target) zu einer sog. Stateflow Machine vervollständigt werden. Für die Simulation mit Simulink muss Simulationscode generiert werden. Dazu muss im Editor mit Tools.Open Simulation Target... eine von Simulink ausführbare S-Function als Target angegeben und das zugehörige Target Builder Fenster geöffnet werden. Wie aus Abb. 2-6 ersichtlich ist, werden defaultmäßig jeweils nur Code für neue, bzw. geänderte Objekte generiert. Über den Button Coder Options... können ein weiteres Pop-up Window geöffnet und zusätzliche Optionen gewählt werden. Insbesondere besteht die Möglichkeit, die Zustandsübergänge eines Chart-Blocks zu visualisieren. Dazu ist die Checkbox Enable debugging/animation anzuklicken.

9

Einführung in die Modellbildung und Simulation mit Stateflow Urban Brunner

Abb. 2-6: Pop-up Windows Simulation Target Builder und Simulation Coder Options

Der Buildprozess muss nicht explizit durch einen Befehl initiiert werden. Denn durch Anklicken von Simulation.Start werden die folgenden Schritte ausgeführt: x Zuerst wird das Zustandsdiagramm analysiert und entsprechender C-Code generiert (Parsing und Code Generation). Die generierten Files werden im Unterverzeichnis sfprj abgelegt. Dieses Verzeichnis wird bei Bedarf neu angelegt. x Der C-Code wird zu einer von Simulink ausführbaren S-Funktion compiliert. Unter Windows wird ein entsprechendes mex-File *_sfun.dll generiert. (Vor der ersten Benutzung von Stateflow ist ein Setup-Vorgang des Compilers durchzuführen. Dazu gibt man im MATLAB-Kommandofenster >>mex -setup ein und wählt dann den mitgelieferten Compiler Lcc aus.) x Die eigentliche Simulation wird gestartet.

Dieser Vorgang benötigt unter Umständen eine gewisse Zeit und kann im MATLAB-Kommandofenster verfolgt werden. Werden beim Parsing Syntaxfehler entdeckt, so werden diese in einem Pop-up Window angezeigt. Zur Überprüfung der syntaktischen Korrektheit von Zustandsdiagrammen könnte der Parser jederzeit während der Programmerstellung aufgerufen werden. Mit dem Befehl Tools.Parse Diagramm (vgl. Abb. 2-6), bzw. mit dem Befehl Tools.Parse können das aktuelle Zustandsdiagramm, bzw. alle Chart-Blöcke überprüft werden. Da im Beispiel stoppuhr.mdl keine kontinuier-

10