Embedded C/C++: Ein einfacher Zustandsautomat
Zustandsautomaten können fast alles!
Seit Alan Turing und seine Kollegen die ENIGMA mit Hilfe eines endlichen Zustandsautomaten geknackt haben, ist der Begriff kaum mehr wegzudenken. Nicht nur lassen sich mit Hilfe von Zustandsautomaten scheinbar komplexe Aufgaben lösen, sondern der Zustandsautomat wird auch zu einer Beschreibung der Wirklichkeit. Zustandsautomaten sind z.B. hervorragend dafür geeignet, sequenzielle Abläufe zu beschreiben bzw. zu spezifizieren...
Die Ampel als Beispiel
Eine Ampel für Fahrzeuge verfügt im regulären Betrieb über vier Zustände: Autos warten, Autos fertig machen, Autos fahren, Autos Achtung.
Das ist schon die erste Überraschung. Die Zustände lauten nicht etwa rot, rot-gelb, grün und gelb, sind also nicht mit den eingeschalteten Lampen verknüpft, sondern mit der erwarteten Handlung der durch den Zustandsautomaten gesteuerten Objekte, der Autos. Ich rate jedem Modellierer eines Zustandsautomaten an dieser Stelle pingelig und exakt zu sein! Zwei Deppen, der eine zuständig für die Autoampel, der andere für die Fußgängerampel, werden sonst bestimmt auf die ungünstige Idee kommen, ihre grünen und roten Zustände zur gleichen Zeit einzunehmen ...
Bei dem nebenstehenden Beispiel handelt sich um eine sog. state centric state machine. Der Zustandswechsel wird dabei von dem aktuellen Zustand initiiert, hier durch den Ablauf einer Warteschleife. Für die hier benötigte Zeitablaufsteuerung ist das völlig ausreichend


Den Code zu diesem sehr einfachen Zustandsautomaten gibt es hier:

Was lässt sich verbessern?
Der zuvor gezeigte Zustandsautomat für eine Fahrzeugampel würde durch die Ergänzung einer Fußgängerampel ungleich komplexer und unüber-sichtlicher. Eleganter ist eine Lösung, in der Fahrzeug- und Fußgängerampel zunächst unabhängig voneinander implementiert werden können, z.B. in zwei verschiedenen Tasks. Später kombiniert man das dann zu einem Überweg über die Straße ...
Das bereits vorgestellte einfache Betriebssystem für ein Arduino lässt sich dafür hervorragend einsetzen. Das ist mit dem weiteren Vorteil verbunden, dass die ineffizienten und blockierenden delay-Schleifen vermieden werden können. An ihre Stelle treten stattdessen die gestern erst eingeführten Software-Timer.
Bis zur Fußgängerampel ist der Weg nun nicht mehr weit. Allerdings möchte ich zuvor noch zwei Dinge erledigen:
- eine elegantere Umsetzung des Zustandsautomaten: API-Schnittstelle
- freie Auswahl zwischen state centric state machine oder event driven state machine
Den Code zum Zustandsautomaten im RTOS gibt es hier:



