Statemachine Tutorial

Einführung

Eine Statemachine (Zustandsautomat) ist im Prinzip nichts anderes als ein Stück Code, mit einer bestimmten Struktur.
Die Aufgabe einer Statemachine ist es, komplexere Abläufe und Steuerungen zu realisieren.
Hierbei arbeitet die Statemachine in verschiedenen Zuständen (States), die der Programmierer definiert.
Diese Zustände werden in einer Variablen gespeichert und sind zentraler Bestandteil der Statemachine.
Die Struktur einer Statemachine besteht also darin, eine Aufgabe in Zustände zu zerlegen, die in einer Variablen gespeichert werden.
Abhängig vom Inhalt der Variablen wird Code ausgeführt.
Schauen wir uns mal das Grundgerüst einer Statemachine an:

Die Struktur, wie eben beschrieben, ist hier deutlich zu sehen.
In Zeile 11 ist eine Variable definiert, die den Zustand der Statemachine aufnimmt.
Darunter, in Zeile 14 bis 17, sind zur Veranschaulichung die Zustände definiert.
In den Zeilen 21 bis 31 wird geprüft, in welchem Zustand sich die Statemachine gerade befindet. Abhängig davon wird unterschiedlicher Code ausgeführt.
Die Unterscheidung der Zustände wird hier mit Select Case erreicht. Das Prüfen der States muss regelmäßig erfolgen, damit auf Ereignisse reagiert werden kann.
Im einfachsten Fall kann diese Select Case-Struktur in der Hauptschleife angelegt werden.

Natürlich kann man die Unterscheidung des aktuellen Zustands auch mit If-Abfragen umsetzen, ich finde jedoch, dass die Select Case in Punkto Übersicht überzeugt.

Das obige Grundgerüst zeigt den grundlegenden Aufbau, ist allerdings noch nicht ganz komplett.
Hier fehlen die sogenannten Ereignisse, die zu einem Zustandswechsel führen.

Um die Zustände zu ändern, abzufragen und die Handhabung zu vereinfachen, legen wir eine kleine Include-Datei an, welche die folgenden Funktionen bereitstellt.

1. SetState(), zum Setzen eines neuen Zustands (Zustandswechsel)
   
2. GetState(), zum Abfragen des aktuellen Zustands in der Select Case-Anweisung
   
3. IsStateChanged(), zum Abfragen innerhalb einer Case-Anweisung, ob sich der Zustand geändert hat.
   

Die Include-Datei kann immer wieder verwendet werden und sieht dann folgendermaßen aus.
Aufmerksamen Lesern ist bestimmt aufgefallen, dass die Zustands-Variable (_FSM_State) jetzt in der Include-Datei integriert ist.
Das ist nicht zwingend erforderlich, macht aber das Hauptprogramm zunächst mal übersichtlicher.

Aufgrund der Include-Datei ändert sich natürlich das Hauptprogramm und sieht nun wie folgt aus:. Die Variable State entfällt logischerweise, dafür muss die Include-Datei eingebunden werden.
Hinzu kam ebenfalls die Zeile 20, in der ein Anfangszustand festgelegt wird, in dem die Statemachine beginnen soll.
In diesem Grundgerüst werden bereits alle Routinen aus der Include-Datei verwendet.

Zur Erklärung des obigen Codes.
Die Variable, die den aktuellen Zustand der Statemachine enthält, ist in die Include-Datei verlegt worden.
Dort wird auf die Variable mit SetState() und GetState() zugegriffen.

In der Include-Datei wurde zusätzlich noch eine Flag-Variable angelegt, in der weitere Informationen zur Statemachine gespeichert werden können.
Im obigen Fall wurde das FLAG_CHANGED angelegt, das immer gesetzt wird, wenn sich der Zustand durch SetState() ändert.

Das Flag FLAG_CHANGED wird mit der Funktion IsStateChanged() abgefragt und im gleichen Aufwasch gelöscht. Das hat einen Vorteil.

Im Hauptprogramm, in den Case-Fällen (Zuständen) kann nun abgefragt werden, ob der Zustand neu ist (FLAG_CHANGED gesetzt), damit hat man die Möglichkeit einmalige Aktionen auszuführen.
Das ist sehr nützlich z.B. für Display-Ausgaben (vermeidet Flackern) und auch die Aktion selbst. In einem späteren Beispiel wird das noch deutlicher.

In den Case-Fällen der verschiedenen Zustände ist noch per Kommentar angedeutet, dass Code, der immer im jeweiligen Zustand ausgeführt werden soll, eingetragen werden kann.
Dort gehören auch die Exit-Bedingungen (Ereignisse) rein, die zu einen Zustandswechsel führen sollen, sofern gewünscht.

So, nun haben wir eigentlich alles, was wir brauchen, um etwas mit einer Statemachine zu steuern.
Das was bisher gezeigt wurde ist in Grunde die Statemachine.

Das FSM_Grundgerüst der Statemachine gibt's zum Download am Ende des Beitrags.


Praktischer Teil

Im praktischen Teil soll an einem kleinen Beispiel gezeigt werden, wie man vorgeht.
Also, in dem folgenden Fall-Beispiel werden wird notwendige Zustände und Ereignisse definieren, den Programmablauf bestimmen und dann den Code entsprechend schreiben.

Beispiel 1 (LED-Steuerung)


Ein wirklich einfaches Beispiel für eine Statemachine wäre eine LED, die man mit einem Taster einschaltet und mit einem anderen Taster wieder aus macht.
Klar kann man jetzt sagen, das geht doch einfach mit 2 If-Abfragen, das stimmt. Aber es geht hier darum zu erklären, wie man die Aufgabe mittels Statemachine lösen kann.
Denn wenn die Aufgaben kompliziert werden, wird es nach altem Schema immer schwieriger den Überblick zu behalten.

Zurück zum Beispiel mit der LED-Steuerung.
Stellt sich nun die Frage, welches sind die Ereignisse, auf die die Statemachine reagieren soll, und was sind die erforderlichen Zustände und die Aktionen, um die Aufgabe zu erfüllen.

Ereignisse definieren
Beginnen wir mit den Ereignissen. Ereignisse sind immer Vorgänge, die einen Zustandswechsel nach sich ziehen. Also was bewirkt einen Zustandswechsel?
Die Frage ist recht einfach zu beantworten. Im Beispiel kommen nur die die zwei Taster in Frage, die Einfluss auf die LED haben. Also sind die Ereignisse entsprechend die Betätigung der Taster.
Genauer ist eine Ereignis die Betätigung des Taster 1, den wir mal Taster_AN nennen, und das andere
Ereignis die Betätigung des Taster 2, den wir mal Taster_AUS nennen wollen.

Zustände definieren
Welche Zustände kennt die Steuerung?
Auch diese Frage ist einfach zu beantworten. Die Steuerung soll die LED entweder AN oder AUS schalten. Dazwischen gibt es nichts. Dimmen ist nicht vorgesehen.
Es gibt somit in unserem Beispiel nur 2 Zustände für den Automat.

• ZUSTAND_LED_AN und
  
• ZUSTAND_LED_AUS
  

Programm-Ablauf
Wie bereits beschrieben, soll die Steuerung bei Taste_AN die LED einschalten und bei Taste_AUS die LED ausschalten. Das ist aber gelinde gesagt recht lapidar ausgedrückt,
und reicht allenfalls als Umschreibung für die Steuerung aus.
Wir müssen das Verhalten der Steuerung präzisieren, denn ein Programm soll zuverlässig und ohne Seiteneffekte funktionieren. Daher muss man sich immer die folgenden Fragen stellen.

1. In welchen Zustand soll die Steuerung beginnen?
   
2. Auf welche Ereignisse ist in den einzelnen Zuständen wie zu reagieren?
   
3. Welche Aktionen sind in den einzelnen Zuständen auszulösen?
   

Wir legen also fest, dass die Steuerung in dem Zustand ZUSTAND_LED_AUS beginnen soll und präzisieren das Verhalten der Steuerung:

Befindet sich die Steuerung im Zustand LED_AUS, soll sie nur auf die Taste_AN reagieren und den ZUSTAND_LED_AN aktivieren. Die andere Taste hat keine Funktion.
Bedindet sich die Steuerung im ZUSTAND_AN, soll sie nur auf die Taste_AUS reagieren und den ZUSTAND_LED_AUS aktivieren. Die andere Taste hat keine Funktion.
Die jeweilige Aktion wird in dem Zustand erledigt, der als neuer Zustand definiert wird.

Es muss also für jeden möglichen Zustand definiert sein, wie die Steuerung zu reagieren hat.
Die Aktion, die durchgeführt werden soll, also Led ein- oder ausschalten, wird in dem Codeabschnitt untergebracht, der nur 1x ausgeführt wird.

Es bietet sich in diesem Zusammenhang oft an, die Zustände, Ereignisse und Aktionen in einer Tabelle festzuhalten. Bei Änderungen der Steuerung kann dadurch die Funktion der Steuerung recht schnell nachvollzogen werden. Eine Tabelle ist auch hilfreich bei Dokumentationen. Ich lege hierfür in der Tabelle die Zustände in Zeilen und die Ereignisse in Spalten an, eine zusätzliche Spalte für Aktion bzw. Kommentare. Das ganze kann dann etwa so aussehen:

Tabelle der Zustände

Damit können wir den Code für die Steuerung angehen, der dann wie folgt aussieht:

Das Programm FSM_Led-Steuerung kann am Ende des Beitrags herunter geladen werden.
Man erkennt deutlich die wiederkehrende Struktur, die eingangs erwähnt wurde. Nach diesem Schema lassen sich viele Programme als Statemachine ausführen.

Beispiel 2 (Notbeleuchtung)

Das obige Beispiel ist zugegebener weise sehr einfach. Deshalb möchte ich die Statemachine mit einem 2. Beispiel gerne vertiefen.

Wir wollen eine Notbeleuchtung bauen. Sie soll im Falle eines Stromausfalls einen Flur beleuchten.

Wie soll die Notbeleuchtung funktionieren?
Die Notbeleuchtung ist am Netz (Via Steckernetzteil) angeschlossen. Die Netz-Spannung wird verwendet, um festzustellen, ob der Strom ausgefallen ist. Solange der Strom da ist, wird die Netzspannung genutzt, um den Akku zu laden bzw. die Akkuladung zu erhalten. Setzt die Netzspannung aus (Stromausfall), so soll die Notbeleuchtung angehen. Allerdings nur, wenn es ausreichend dunkel ist. Bedeutet, bei ausreichender Helligkeit bleibt bei Stromausfall die Notbeleuchtung aus (die LED_Netz geht jedoch aus).

Weiterhin soll die Notbeleuchtung den Status des Akkus und der Netzspannung per LED anzeigen.

• Netzspannung da, grüne LED (LED_Netz) leuchtet.
  
• Akku wird geladen, rote LED (LED_Batt_Charge) leuchtet.
  
• Akku voll, Ladung wird erhalten, grüne LED (LED_Batt_Full)
  

Um den Akku zu schützen, soll bei Stromausfall die Notbeleuchtung abgeschaltet werden, bevor der Akku tiefentladen wird und damit Schaden nehmen kann.

Die Notbeleuchtung soll noch Tasten erhalten mit folgenden Funktionen.

• Taste Test simuliert einen Stromausfall. Der Controller erkennt Stromausfall und verhält sich so, solange die Taste gedrückt bleibt. Taster ist ein Öffner und unterbricht die Spannung zum Eingang (Pin_Power), der feststellt ob Netz (Spannung vom Steckernetzteil) da ist oder nicht.
  
• Taste Set (Schließer) ermöglicht die Einstellung der Helligkeit, bei der die Notbeleuchtung einschaltet.
  
• Taste Akkupflege (Schließer), der Akku wird einmal komplett entladen und dann neu geladen. Damit soll ein Memory-Effekt des Akkus verhindert werden. Tritt während der Akkupflege ein Stromausfall ein, so soll die Notbeleuchtung wie oben beschrieben aktiv werden.
  

Ich denke an dieser Stelle ist recht klar, wie die Notbeleuchtung funktioniert. Zu erwähnen ist noch, dass ein LDR mit PullDown-Widerstand zur Helligkeitsmessung, und ein Poti zur Helligkeits-Einstellung verwendet werden soll.

Welche Zustände kennt die Notbeleuchtung?

Um zu ermitteln, welche Zustände die Steuerung benötigt, kann man auch fragen: In welchen Zuständen verharrt die Steuerung, bis ein Ereignis eintritt?

Nun, beim Einschalten muss man erst mal prüfen, wie die aktuelle Lage ist. Haben wir Netzspannung, wie ist die Akkuspannung, und daraufhin wird entschieden, mit welchem Zustand die Steuerung fortfährt. Die Feststellung der Lage kann also bereits als ein Zustand angesehen werden und kann auch diverse Initialisierungen darin vornehmen. Man kann ihn z.B. benennen als ZUSTAND_DEFAULT oder ZUSTAND_START. Da wir aber etwas schreibfaul sind verwenden wir anstelle ZUSTAND nur ST für State. So können sich folgende Zustände für die Steuerung ergeben.

• ST_START: In diesem Zustand startet die Statemachine, hier wird ermittelt, welche Spannung der Akku hat, und ob Netzspannung vorhanden ist. Entsprechend wird der Zustand der Statemachine eingestellt.
  
• ST_BATT_CHARGING: In diesem Zustand wird der Akku geladen, bis die Ladeschlussspannung erreicht ist. In Diesem Zustand wird die Netzversorgung überwacht, aber auch die Taster Test und Set. Anwahl der Akkupflege ist in diesem Zustand nicht erlaubt.
  
• ST_BATT_FULL: In diesem Zustand ist der Akku vollgeladen, die Ladung wird nur noch erhalten. In diesem Zustand wird die Netzspannung überwacht, aber auch die Tasten Test, Set und Akkupflege.
  
• ST_BATT_UNCHARGING: In diesem Zustand wird der Akku aufgrund der Benutzereingabe „Akkupflege“ entladen. Bei Stromausfall wird der Zustand natürlich beendet. Taste Test beendet den Zustand logischerweise ebenfalls, denn sie simuliert den Stromausfall.
  
• ST_POWER_FAILURE: In diesem Zustand dauert der Stomausfall an. Die Notbeleuchtung ist an, wenn der eingestellte Helligkeitswert unterschritten ist.
  
• ST_SET: In diesem Zustand kann mit dem Poti der Schwellwert eingestellt werden, bei dem die Notbeleuchtung eingeschaltet wird. Es wird also direkt der Poti-Wert mit dem LDR-Wert verglichen und entsprechend die Notbeleuchtung ein- oder ausgeschaltet. Bei erneutem Drücken der Set-Taste, wird der Poti-Wert im EEProm gespeichert und als Helligkeitswert im Falle des Stromausfalls als Grenzwert verwendet. Um anzuzeigen, dass der Einstellmode aktiv ist, soll die LED_Netz im Sekundentakt blinken.
  
• ST_BATT_CRITICAL: In diesem Zustand ist die Akkuspannung unter einem kritischen Wert. Die Notbeleuchtung wird abgeschaltet, LED’s alle aus, bis auf LED_Charge, diese soll blinken, um den kritischen Zustand anzuzeigen.
  

Das Ganze ist etwas unübersichtlich, daher verwenden wir wieder unsere Zustandstabelle. Zustände in die Zeilen, Ereignisse (Sensorwerte, Tasten) in die Spalten eintragen. An den Schnittpunkten werden die Zustände eingetragen, in die gewechselt wird, wenn das entsprechende Ereignis auftritt.




Die obige Zustandstabelle zeigt an, was der Automat (Notbeleuchtung) in welchem Zustand macht und auf welche Ereignisse er reagiert. Auf diese weise kann man keine Ereignisse vergessen, auf die reagiert werden muss, da in jedem Feld etwas stehen muss.
Vielleicht ist die Tabelle für den einen oder anderen noch etwas unklar zu verstehen, daher ein greife ich zur Erklärung einen Zustand heraus.
Angenommen die Notbeleuchtung befindet sich gerade im Zustand ST_BATT_CHARGING. Das bedeutet, der Akku soll geladen werden. Dies ist auch in der Spalte Bemerkung/Aktion zu sehen. Nun können in diesem Zustand verschiedene Ereignisse eintreten. In den Spalten sind alle Ereignisse (siehe 1. Zeile) aufgeführt, die eintreten können. Nun steht in dem Feld in dem sich der Zustand mit dem Ereignis kreuzt der resultierenden Zustand. in den gewechselt werden soll. Tritt also im Zustand ST_BATT_CHARGING (Zeile 3) ein Ausfall der Netzspannung ein (Spalte Netzspannung), wird in den Zustand -> ST_POWER_FAILURE gewechselt. In Spalte Akkupflege steht z.B. ein Strich. Bedeutet, bei diesem Ereignis wird kein Zustandswechsel stattfinden. In Spalte Taster Set steht "-> ST_SET", das bedeutet, dass wenn Taste Set gedrückt wird immer in den Zustand ST_SET gewechselt wird.

Das Zeichen "->" deutet nur an, dass ein Zustandswechsel erfolgt. Davor kann eine Bedingung stehen. Nach dem Zeichen "->" steht der Ziel-Zustand, in den gewechselt wird.
Man könnte das auch kurz etwa so notieren: [Bedingung] -> Ziel-Zustand

Bedingung ist optional (deshalb in eckigen Klammern) und macht oft Sinn, eine anzugeben.

Was noch fehlt ist der Code, wie man die Notbeleuchtung in Code umsetzt.



Der Code des Automaten ist jetzt schon deutlich komplexer geworden.
Ladet den einfach unten herunter und öffnet den Source in die Bascom-IDE. Es sieht schlimmer aus als es ist.

Fakt ist, dass man im Code schon unterteilt die Zustände erkennt (Hauptschleife), in denen auch die Aktionen und die Ereignisse behandelt werden.
Man sollte sofort erkennen, dass ein so programmierter Code sehr Übersichtlich ist. Man erkennt auch deutlich, wie die Statetabelle und die Code-Struktur korreliert.

Der Code wurde übrigens nicht mit Hardware getestet und ist eigentlich nur für die Einführung in die Statemachine als etwas komplexeres Beispiel gedacht.
Wer es dennoch real ausprobieren möchte, muss auch mit Programmierfehlern rechnen. Die zu beheben sollte jedoch aufgrund der State-Tabelle und ausreichend kommentiertem Code nicht schwer fallen. Auch Anpassungen sollten keine größeren Schwierigkeiten bereiten.

Die Eingangs gestellt Frage, was eine Statemachine ist und wie man die in Bascom einbindet, dürfte damit geklärt sein. Bleibt noch die Frage, wozu man das braucht.
Nun, es erleichtert die Programmierung und auch die Dokumentation. Es lassen sich komplexe Steuerung und Abläufe realisieren, die immer noch übersichtlich bleiben. Wer mal versucht die obige Steuerung herkömmlich zu programmieren, also ohne Statemachine, wird schnell merken wo die Vorteile der Statemachine liegen. Der Code bleibt wartbar.

Viel Spaß damit.

Übungsaufgaben

Wer jetzt Blut geleckt hat und es mal selbst versuchen möchte, kann sich mal Gedanken zu folgenden Aufgaben machen und versuchen eine State-Tabelle anzulegen oder den Code umzusetzen.


Übung 1: Akkuwächter für 12V Akkus.
Die Spannung einer Autobatterie soll überwacht werden. LED's sollen den Zustand anzeigen. Ist die Spannung <11,5V soll eine rote LED den niedrigen Batteriezustand signalisieren. Eine gelbe LED signalisiert Spannungen über 13,8V. Eine grüne LED zeigt korrekte Akkuspannung an. Die Akkuspannung soll mittels ADC gemessen werden.

Übung 2: Torsteuerung
Ein elektrisch betriebenes Firmentor soll manuell gesteuert werden. Hierfür sind 3 Bedienknöpfe (Taster Auf, Zu, Stop) vorgesehen. Wenn das Tor geschlossen ist (Endschalter Tor zu aktiv) ist, kann nur die Taste Auf betätigt werden. Wenn das Tor geschlossen ist (Endschalter Tor zu aktiv), kann nur die Taste Auf bedient werden. Während das Tot auf- bzw. zu fährt kann das Tor (Taste Stop) vorzeitig gestoppt werden. Ist keiner der Endschalter aktiv, soll mit Taster Auf bzw. Taster Zu das Tor wieder in Bewegung versetzt werden können. Der Antrieb für das Tor wird durch 2 Ausgänge gesteuert. Ein Pin für Richtung (Tor Öffnen = HIGH, Tor Schließen = Low) und ein Pin für Motor an (An = High).

Torsteuerung: Ampel-Erweiterung

Wenn ihr die Steuerung bis hierhin geschafft habt, könnt ihr mal die Ampel-Erweiterung einbauen.
Nach einer gewissen Zeit möchte der Auftraggeber, dass eine Ampel (Rot/Grün) nachgerüstet wird. Sie soll anzeigen, ob man hineinfahren darf oder nicht. Ist das Tor vollständig geöffnet (Endschalter aktiv), soll die Ampel grün leuchten. Während sich das Tor bewegt oder wenn es vorzeitig gestoppt wurde, soll die Ampel rot zeigen. Ist das Tor geschlossen, geht die Ampel aus, um Energie zu sparen.

Torsteuerung: Aufprallschutz-Erweiterung
Wenn ihr es bis hier her geschafft habt, könnt ihr noch eine Erweiterung nachrüsten.
Der Auftraggeber hat festgestellt, dass es eine Gefahr darstellt, wenn das Tor zu fährt und sich noch etwas im Weg befindet wie eine Person oder ein Fahrzeug. Um Verletzungen und Schäden zu vermeiden, soll ein Aufprallschutz am Tor angebracht werden. Dieser besteht aus einem Taster, der betätigt wird, wenn das Tor beim Schließen auf ein Hindernis trifft. In dem Fall soll das Tor sofort stoppen. Die Manuelle Bedienung lässt dann nur die Taste Auf als Bedientaste zu.

Torsteuerung: Überwachung Torbewegung
Der Auftraggeber möchte, dass die Torbewegung überwacht werden soll. Hierfür soll ein Timeout erkennen, ob das Tor ordnungsgemäß schließt oder öffnet. Die Funktion sieht folgendermaßen aus.
Wenn das Taste Tor Zu betätigt wird, dauert es eine gewisse Zeit, bis das Tor den Endschalter ZU erreicht. Ist die Zeit deutlich länger, kann man davon ausgehen, dass ein Fehler am Antrieb vor liegt. Der Auftraggeber sagt, dass das Tor nie länger als 60 Sekunden zum Öffnen bzw. Schließen benötigt. Sollte nach 90 Sekunden der Endschalter nicht erreicht sein, kann man von einem Fehler ausgehen. In diesem Fall soll der Antrieb auf jeden Fall abgeschaltet werden. Und um den Fehler anzuzeigen, soll die rote Ampel im Sekundentakt blinken.

Schlussbemerkung
Eine Statemachine kann sehr unterschiedliche Anforderungen erfüllen und ist damit situationsbedingt sehr flexibel.
So kann es unter Umständen gewünscht sein, dass bestimmte Zustände auf keinerlei Ereignisse reagieren sollen. Das könnte z.B. Im Fehlerfall bei einer Notabschaltung der Fall sein, um größeren Schaden zu vermeiden. In der Regel sind aber in jedem Zustand Ereignisse notwendig, um den Zustandswechsel zu initiieren.

In meinen Beispielen habe ich die Aktion, die bei einem Zustandswechsel ausgeführt werden soll, stets in den Ziel-Zustand im Bereich der Bedingung "If IsStateChanged() = TRUE" eingefügt. Das hat einen einfachen Grund. Man muss die Aktion nur 1x ausführen und zwar in dem Zustand, in den gewechselt wird.

Zustandsautomaten sind nicht nur für Steuerungen (Hardware) einsetzbar, sondern können auch bei Regelungen eingesetzt werden. Ein weiterer Einsatzbereich ist neben der Hardwaresteuerung auch die Software-Steuerung. Hierbei ändert der Automat seinen Zustand abhängig von den Daten, die er verarbeitet. Dies kann z.B. beim dekodieren von seriellen Signalen der Fall sein (Serielle Schnittstelle, Netzwerk-Datenverkehr). Auch ein Interpreter ist im Grunde eine Statemachine. Denn sie interpretiert die geschriebenen Befehle und führt dann die entsprechende Aktion aus. Compiler sind im Grunde auch nichts anderes. Sie interpretieren Text und erzeugen abhängig davon einen Binärcode, den der Prozessor versteht.

Die hier vorgestellte Möglichkeit einer Statemachine kann ein einzelnen Zustandsautomat (Objekt) verwalten.
Es gibt Situationen, da reicht ein einzelner Automat nicht aus. Möchte man mehrere Automaten quasi parallel laufen lassen, ist das möglich, wenn die Include-Datei angepasst wird, so dass mehrere Zustände unabhängig voneinander verwaltet werden können. Ein typische Beispiel für parallelle Automaten sind beispielsweise Computer-Spiele.

Jeder kennt Spiele in denen man gegen den Computer spielt. Der Computer-Spieler ist in dem Fall ein Automat. Manche Spiele lassen es zu, den Computer gegen sich selbst spielen zu lassen. In dem Fall spielt allerdings ein weiterer Automat den 2. Spieler. Es spielt also Automat 1 gegen Automat 2. Jeder Automat kann hier als eigenständiges Objekt betrachtet werden das unabhängig vom anderen Objekt ist. Sie verwenden möglicherweise die gleichen Konstanten als Zustände, jeder Automat kann sich trotzdem in einem anderen Zustand befinden.

Man mag es kaum glauben, aber fast alles kann man, sofern man das möchte, als Automat betrachten.
Man verzeihe mir den Vergleich mit Babette, aber auch sie ist ein Automat. Babette ist entweder am schlafen, sie ist sauer oder gar eingeschnappt. Oder sie ist gelangweilt und erzählt einen Witz. Das alles sind Zustände.

In diesem Sinne frohes Gelingen!

Mitch