Einführung in die Modellbildung und Simulation ereignisgetriebener Systeme mit Stateflow


Skript, 2009

47 Seiten


Leseprobe

Inhaltsverzeichnis

1 Einleitung

2 Konstruktion und Simulation eines einfachen Simulink/Stateflow-Modells
2.1 Der Editor
2.2 Der Explorer
2.3 Interpretation von Zustandsdiagrammen
2.4 Simulation und Animation von Zustandsdiagrammen

3 Modellbildung mit Stateflow
3.1 Sicht und Modellbildung
3.2 Sequentielle Zustände (Exclusive Decomposition)
3.3 Parallele Zustände (Parallel Decomposition)
3.4 Hybride Systeme (State Events)

4 Notation und Semantik von Stateflow
4.1 Action Language
4.2 Inner Transitions
4.3 Debugger

5 Projekt
5.1 Beschreibung der Anlage und Problemformulierung
5.2 Steuerungsentwurf
5.2.1 Modellierung der ungesteuerten Anlage
5.2.2 Modellierung der gesteuerten Anlage
5.3 Test und Implementierung

6 Literatur- und Abbildungsverzeichnis

1 Einleitung

Technische Systeme müssen auf Ereignisse reagieren. Dazu benötigen sie eine Steuer­logik, 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 tech­nischen Prozesses ursächlich sowohl durch zeit­kontinuierliches Verhalten, meist beschrieben durch Differentialgleichungen, als auch durch reaktives ereignisgetriebenes Verhalten geprägt, so liegt ein gemischt konti­nuierlich-diskretes System, ein sog. hybrides System vor. Beispiele hybrider Systeme sind gesteuerte Produktions­prozesse, Rege­lungen mit veränder­licher Struktur, Ver­kehrs­­systeme – im Grunde genom­men alle hierar­chisch organisierten Systeme.

Ein hybrides System besteht aus einem oder mehreren kontinuierlichen Teilsystemen und einem oder mehreren ereignisgetriebenen Teilsystemen. Stateflow ist ein Zusatz zu Simu­link, um hybride Systeme beschreiben und mittels animierter Simulation analysieren zu können. In Stateflow wird ein ereig­nis­­getrie­benes System graphisch und dessen Schnitt­stel­le zu einem mit Simu­link-Blöcken bes­chrie­benen, zeit­ge­trie­benen System textuell spe­zi­­fi­ziert. Formal basiert Stateflow auf (er­wei­terten) Zu­stands­­­­automaten und orientiert sich an der von Harel [1] einge­führten Notation für State­charts. Statecharts schließen die ge­bräuch­­lichen Modellarten zur Beschreibung ereignis­­­­getriebener Systeme ein. Einen guten Überblick über die gebräuchlichsten Modell­­arten, wie Endliche Automaten, Petri-Netze und Warteschlangen, vermittelt [2].

Stateflow ist als eine Erweiterung von Simulink konzipiert, wobei eine benutzer­freund­liche Oberfläche und eine durchgängige Unterstützung beim Entwurf von reak­tiven Systemen im Vordergrund stehen [3]. Insbesondere unterstützt Stateflow einen hierar­chischen Aufbau von ereignisgetriebenen Modellen. So können größere Modelle struktu­riert, d.h. bottom-up und/oder top-down, entwickelt werden. Die Interaktion von Teilsystemen beruht auf der synchronen Ko­operation [4], [5]. Überdies können mit Stateflow Ent­schei­dungs­­situationen graphisch in einer an Flussdiagrammen orientier­ten Form, die auch den Aufruf von MATLAB- und C-Funktionen zulässt, beschrieben werden. Schließlich kann aus der Modell­beschreibung mit Stateflow Coder und Real-Time Workshop aus­führ­barer Code generiert werden. Dadurch wird Konsistenz zwischen beschriebenem Modell, bzw. simuliertem Verhalten, und imple­men­­tiertem Code garantiert.

Anhand der Konstruktion eines einfachen Beispiels wird in Kapitel 2 das Werk­zeug Stateflow vorgestellt. Die eigentliche Modellbildung mit Stateflow wird dann in Kapitel 3 ge­zeigt. In Kapitel 4 werden einige Besonderheiten der Notation und Seman­tik von Stateflow dokumentiert. Für eine Beschreibung aller Stateflow Menus und Befehle wird auf das Manual[3] sowie die integrierte Help-Funktion sfhelp ver­wiesen. Schließlich wird in Kapitel 5 anhand eines kleinen Projekts ein systematischer Steuerungsentwurf mittels Stateflow demonstriert.

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 er­zeugt. 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 Sub­­systeme in Simulink durch Eingangs- und Aus­gangs­signale mit andern Simulink-Blöcken inter­agieren und auf den MATLAB-Workspace Zugriff haben (vgl. Abb. 2-1). Das Erstellen eines Stateflow Systems geschieht objektorientiert und zwar auf zwei Stufen. Einer­­seits werden graphische Objekte mit dem Editor zu einem Zustands­dia­gramm zu­sam­mengebaut. Ander­seits werden mit dem Explorer über Dialogfenster die nicht­-graphischen Objekte Events und Data definiert, die im wesentlichen das Interface zum um­gebenden Simulink-Modell be­schreiben.

Abbildung in dieser Leseprobe nicht enthalten

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

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 Zustands­­diagramm zusammengebaut werden. Abb. 2-2 zeigt das Stateflow Editor Fenster. Am linken Rand ist die Objekt­palette für die graphischen Elemente zu erkennen, die mittels Drag and Drop auf die Arbeits­­fläche gezogen und miteinander verknüpft werden können. Auf der Arbeitsfläche ist das Stateflow Diagram des Simulink-Modells stop­puhr.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).

Abbildung in dieser Leseprobe nicht enthalten

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 Arbeits­fläche platziert. Die Größe des den Zustand darstellenden Rechtecks kann durch Ziehen an den Ecken verändert werden, wodurch u.a. eine Ver­schachtelung 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 Ausgangs­zustands be­wegt, 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 Frage­zeichens und Eintippen eines Namens bezeichnet. Dabei können auch die ggf. auszuführenden Aktionen in Form von MATLAB-Anweisungen eingegeben werden. Ist das Frage­zeichen einer Transition im Fenster 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 zusammen­gefasst 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­über­gang ausgeführt werden. Die Aktionen des Beispiels stoppuhr.mdl sind selbst erklä­rend. So werden mit entry:Zeit=0 beim Eintritt in den Ruhe­zustand 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 ver­strichene 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 (hori­zon­talen) Toolbar, mittels rechter Maustaste oder mit Tools.Explore... auf­gerufen.

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. ver­schachtelte Zustände können durch Doppelklicken auf den Namen expandiert werden. Die Stateflow-Machine von stop­p­uhr.mdl enthält nur einen Chart -Block (den Chart -Block Zeit­messer), der seinerseits aus drei (nicht weiter zu expandierenden) Zuständen besteht. Im rechten Teil des Fensters sind die auf der angewählten Hierarchie­stufe definierten nicht-­graphischen Objekte aufgelistet. Auf Stufe Zeitmesser sind vier Ereignisobjekte (bezeichnet mit Start, Stop, Reset und Enable) sowie zwei Daten­objekte (bezeichnet mit DT und Zeit) definiert.

Abbildung in dieser Leseprobe nicht enthalten

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

Nicht-graphische Objekte werden mittels dem Menü Add eingefügt. Dabei müssen Sicht­bar­keits­­­regeln 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 liegen­den Zustände. Selbstverständlich sollten bei einer größeren Stateflow-Machine Objekte möglichst lokal definiert werden, um Namens­konflikte und ungewollte Seiten­­effekte zu vermeiden. Die Eigenschaften der Objekte, wie Name, Scope, Trig­ger etc., werden durch Anklicken des entsprechenden Felds und einer Eingabe spezifiziert. Im Bei­spiel stoppuhr.mdl sind die vier Ereignisse als steigende oder fallende Flanken (Trig­ger: Either) von Signalen aus dem Simulink-Modell (Scope: Input from Simu­­link) definiert. Die Variab­len 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 Inter­face zum Simulink-Modell (vgl. Abb. 2-4) be­steht somit aus einem Triggereingang mit vier Komponenten sowie einem Aus­gangs­port. Der Block Manual Switch gehört zur Simulink-Library Nonlinear. Während der Simu­lation 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.

Abbildung in dieser Leseprobe nicht enthalten

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. 2-5). Die Update Methode bestimmt die Zeitpunkte, an denen die Simulations­routine, der sog. Solver, die Zustands­diagramme aufweckt und auswertet. Neben der Wahl der Auswertungs­zeit­punkte ist die Interpretation einer Statechart durch die Aus­wertung zu diesen Zeit­punkten gegeben. Eine durch ein Ereignis aufgeweckte State­chart wird prinzipiell top-down ausgewertet; d.h. von oben nach unten in der Objekt­hierarchie 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 -Aktio­nen (vgl. dazu auch Kapitel 4.1) auszuführen sind und werden ggf. auch ausgeführt, und erst dann wird geschaut, ob unter den Nach­kommen dieser aktiven Zustände gültige Tran­sitionen vorkom­men, die dann schließlich auch ablaufen werden.

Abbildung in dieser Leseprobe nicht enthalten

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

Da auf der obersten Stufe (Stufe Chart) keine during- oder on event_name-Aktionen aus­zu­führen sind, er­geben sich folgende Schritte beim Eintreffen eines Ereignis­ses:

1. Es wird geprüft, ob auf Stufe Chart unter den direkt nachkommenden Zuständen Tran­­sitionen ab­laufen 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_na­me -Aktionen ausgeführt.
4. Es wird geprüft, ob aus einem Substate heraus oder unter Substates Transi­tionen ab­lau­fen 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 nach­kom­men­den Zustände aus.

Diese Schritte werden solange wiederholt, bis alle Hierarchiestufen abgearbeitet sind. Da State­flow parallele Zustände kennt (vgl. Kapitel 3.3), können auf einer Hierarchie­stufe mehrere Zustände gleichzeitig aktiv sein. In Stateflow muss daher eine Ab­­ar­bei­tungs­­­­­reihenfolge (sog. Aktivierungs­reihen­folge) unter den jeweils aktiven Zuständen einer Hierarchie­­­stufe festge­­legt sein. Klare Kenntnisse dieser Aktivierungs­reihenfolge sind für eine saubere und kor­rekte Modell­­bildung erforderlich. Leider kann die Semantik einer graphischen Pro­gram­­mier­­­sprache nicht so kompakt beschrieben werden. Deshalb werden jeweils an passender Stelle, insbesondere in Kapitel 3.3 und in 4.1 entsprechende Hin­weise gegeben.

Nachfolgend wird die Auswertung einer State­chart 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 Aus­wertungs­zeitpunkte. Sind Input-Ereignisse definiert, so triggern diese die Auswertung. Sind nur Input-Data und keine Input-Ereignisse definiert, so werden die Erneuerungs­zeitpunkte des „schnellsten“ Input Signals als Auswertungs­zeitpunkte über­nom­men. 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 gegebenen­falls 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 Ereignis­ses 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 zuge­ordnete Aktion (hier: ml(’tic’)) ausgeführt. 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 Default­transition (vgl. Abb. 2-2). Beim ersten Aufwecken einer Chart wird die Default­tran­sition, bzw. für parallele Zustände werden die Default­transitionen ausgeführt und die ent­sprechen­den 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 Anfangs­zustand (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 vervoll­stä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 wer­den. 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 Check­box Enable debugging/animation anzuklicken.

[...]

Ende der Leseprobe aus 47 Seiten

Details

Titel
Einführung in die Modellbildung und Simulation ereignisgetriebener Systeme mit Stateflow
Autor
Jahr
2009
Seiten
47
Katalognummer
V129403
ISBN (eBook)
9783640613335
ISBN (Buch)
9783640613595
Dateigröße
1946 KB
Sprache
Deutsch
Schlagworte
Einführung, Modellbildung, Simulation, Systeme, Stateflow
Arbeit zitieren
Prof. Dr. Urban Brunner (Autor), 2009, Einführung in die Modellbildung und Simulation ereignisgetriebener Systeme mit Stateflow, München, GRIN Verlag, https://www.grin.com/document/129403

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Einführung in die Modellbildung und Simulation ereignisgetriebener Systeme mit Stateflow



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden