Zustandsdiagramme
- Statechart [3]:
- starke Erweiterung des endlichen Automaten
- viele Implementierungen, u.a. in Matlab (Stateflow)
und Modelica (StateGraph)
- jeweils leichte Abweichungen und Erweiterungen
- hier Stateflow-Notation
- geht wesentlich über Statecharts hinaus, aber
sehr komplex und oft nicht klar definiert (vgl. [4]
und [5])
- Hierarchien von Zuständen
- Zustand kann mehrere Unterzustände enthalten
- System im Zustand A ↔ entweder A1 oder A2 aktiv (Decomposition/Exclusive)
- B wird aktiv → B1 wird aktiv (Default-Zustand)
- direkte Auswahl des Unterzustands von Start und
Ziel möglich
- Modell ohne interne Zustandsdetails (Group
& Subchart/Subchart, Format/Content
Preview/off)
- Parallele Zustände
- Gesamtzustand = Produkt von Teilzuständen
- System befindet sich in A und B gleichzeitig (Decomposition/Parallel)
- Zustand beim Start konkret A1/B1
- Aktionen und Aktivitäten
- Übergang kann Aktivitäten auslösen, auch in
anderen Teilzuständen
- Im Zustand A1/B1 werde a = 2 ⇒ (A1 → A2) ⇒ trigger wird 1 ⇒ (B1 → B2)
- Nebeneffekte möglich, da trigger
global
- besser mit lokalem Event, etwa in A2/B2: send(goBack,
B2) ⇒ (B2 → B1)
- Event erzeugen mit Chart/Add
Other Elements/Local Event...
- Aktivitäten können auch ausgelöst werden bei
Betreten (entry) oder Verlassen (exit) eines Zustands
- Beispiel Robotersteuerung:
- Roboter soll auf Startsignal hin Objekt von A nach B
bringen
- Motorverhalten beschrieben durch
- drei Geschwindigkeiten MV: 0, langsam, schnell
- zwei Richtungen MR: nach links, nach rechts
- Sensoren S1 .. S6 zeigen
Erreichen einer Position an
- Ablauf
- Startposition ist 0, MV = 0, MR = L
- Startsignal → Roboter fährt nach A, zunächst
schnell, dann ab S3 langsam
- bleibt bei S4 stehen, greift das
Objekt (als Zeitverzögerung modelliert)
- fährt nach B, zunächst schnell, ab S5
langsam
- bleibt bei S6 stehen, setzt Objekt
ab (Zeitverzögerung)
- fährt zurück nach 0, erst schnell, langsam ab S2
- bleibt bei S1 stehen
- Implementierung in Stateflow (robcontrol1A):
- Chart-Block im Modell öffnen
- Eingänge start, S1 ... S6
definieren (Chart/Add Inputs &
Outputs/Data Input From Simulink)
- analog Ausgang v
- Elemente für interaktive Steuerung hinzufügen
- Aufbau des Diagramms
- zur Übersichtlichkeit Hierarchiestufen nutzen
- Grobstruktur
- Feinstruktur
- Definieren der Geschwindigkeit jeweils bei Betreten
eines Zustands (entry)
- Transitionen
- meistens bei Aktivieren des Startknopfs oder
eines Sensors
- Aufnehmen (PickingUp)
und Absetzen (Unloading) nach fester
Zeit im Zustand
- mit Stateflow-Funktion after(n,
sec)
- Masken-Parameter (vl, vh, tp, tu)
müssen in Chart aktiviert werden
- in Chart Variablen anzeigen lassen (View/Symbols)
- für alle Masken-Parameter TYPE
= Parameter Data setzen
- Testlauf manuell:
- Hauptebene und Chart in zwei Fenstern nebeneinander
- Simulation starten → aktiver Zustand Waiting
wird markiert
- Taster Start anklicken → Getting Object und Cruising
werden markiert
- durch Anklicken der Sensor-Taster Ablauf
nachvollziehen
- Testlauf automatisiert (robcontrol1B):
- Signalgeber für Startimpulse
- Signalgeber, der in geeigneten Zeitabständen von 1
bis 6 hoch und runter zählt
- Wert = i → Sensor i ist aktiv
- Ergebnis zeigt den gewünschten Verlauf der
Geschwindigkeit
- Modellierung des Gesamtsystems (robcontrol2):
- Hybridmodell mit diskreter Steuerung und
kontinuierlicher Außenwelt (Roboter/Sensoren)
- Roboter
- Eingang: v
- Ausgang: x
- Parameter: Anfangsort x0
- Implementierung: einfacher Integrator
- Sensoren
- Eingang: x
- Ausgänge S1 ... S6 (Typ boolean)
- Parameter: Orte x1 ...
x6 der Sensoren, Sensorbreite b
- Implementierung: 6 Intervalltester
- Gesamtmodell
- Ergebnis seltsam
- Fehler in Simulink (Version 2019a):
- Solver überspringt Sensorreaktion → Roboter fährt
einfach weiter
- einfacher Fix: Solverparameter Max
step size von auto auf 0.01
- eigentliche Fehlerursache
- im Block Interval Test
ist Zero Detection ausgeschaltet!
- besserer Fix
- eigener Block Interval tester
mit Zero Detection
- Max step size bleibt auf
auto
- Modell funktioniert
- Hinzufügen eines Greifers:
- Funktion
- kann greifen oder loslassen
- fährt zum Aufnehmen herunter, zum Transport hoch
- Anschlüsse
- Eingang Motor (+vg nach oben, -vg nach unten)
- Eingang Greifer (g = 0, 1)
- Ausgänge zweier Sensoren (Sgu = unten, Sgo =
oben)
- Modellierung des Greifers (robcontrol3):
- könnte über Subzustände bei PickingUp
und Unloading eingefügt werden
- übersichtlicher als paralleles Subsystem Grab
- Grundaufbau
- Greifer wechselt zwischen vier Zuständen
- Aufnehmen (Picking) und
Ablegen (Dropping) jeweils Subzustände
-
- Kopplung zwischen Robot und
Grab
- PickingUp wird betreten
- → lokales Event pick
wird an Grab geschickt
- → Transition von Idling
zu Picking
- Picking wird verlassen
- → lokales Event deliver
wird an Robot geschickt
- → Transition von PickingUp
zu DeliveringObject/CruisingB
- analog bei Unloading
und Dropping
- Symboltabelle zeigt übersichtlich alle verwendeten
Symbole an (Ein-/Ausgänge, Parameter, Events, Zustandsnamen)
- Implementierungsdetails:
- Transition von Picking.AscendingFull
nach Moving (u.ä.)
- in Picking über die
Grenze hinausziehen → Pfeil endet mit Querstrich (Slit)
- wird in Grab als rotes
Dreieck angezeigt
- von dort aus Transition zu Moving
ziehen
- Gesamtmodell
- primitive Modelle für Grab
(Integrator mit Saturation) und dessen Sensoren
- Ausgabe der angenommenen Zustände über die Zeit als
Hilfe beim Debuggen
- Kontextmenü in Robot/Properties...
- Create output for
monitoring/Leaf state activity
- Voraussetzung: Zustände in Robot
haben verschiedene Namen
- analog für Grab
- Ausgabe zeigt komplettes Systemverhalten
- Aufgaben: