State Machines (Zustandsautomaten) für saubere Projektstrukturen

State Machines (Zustandsautomaten) sind eine der zuverlässigsten Methoden, um Arduino- und Embedded-Projekte sauber zu strukturieren, verständlich zu halten und langfristig stabil zu betreiben. Statt viele verschachtelte if-else-Blöcke, verstreute Flags und schwer nachzuvollziehende Sonderfälle zu pflegen, modellieren Sie Ihr System als eine Menge klarer Zustände mit definierten Übergängen. Das ist besonders wertvoll, sobald ein Projekt mehrere Aufgaben gleichzeitig erledigen soll: Eingaben lesen, Ausgaben steuern, auf Zeit reagieren, Kommunikation abwickeln und dabei jederzeit „ansprechbar“ bleiben. Ein Zustandsautomat zwingt Sie dazu, Verhalten explizit zu machen: Was passiert in welchem Zustand? Welche Ereignisse lösen einen Wechsel aus? Welche Aktionen werden beim Eintritt, während der Ausführung und beim Verlassen eines Zustands ausgeführt? Das Ergebnis ist nicht nur besserer Code, sondern auch schnellere Fehlersuche, weniger „Nebenwirkungen“ und eine Struktur, die sich wie ein Plan lesen lässt. Dieser Artikel zeigt Ihnen, wie Sie State Machines praktisch einsetzen, welche Varianten sich für Einsteiger und fortgeschrittene Projekte eignen und wie Sie damit professionelle Projektstrukturen schaffen – ohne unnötige Komplexität.

Grundprinzip: Was ist ein Zustandsautomat?

Ein Zustandsautomat beschreibt ein System, das sich zu jedem Zeitpunkt in genau einem Zustand befindet und auf Ereignisse reagiert, indem es Aktionen ausführt und ggf. in einen anderen Zustand wechselt. Formal besteht ein (endlicher) Automat aus Zustandsmenge, Eingaben/Ereignissen und einer Übergangsfunktion. Für den Praxisalltag reicht eine intuitive Definition:

• Zustand: Ein klarer Modus des Systems (z. B. „Warten“, „Messen“, „Fehler“, „Senden“).
• Ereignis/Trigger: Eine Bedingung, die einen Übergang auslösen kann (z. B. Taste gedrückt, Zeit abgelaufen, Sensorwert außerhalb Range).
• Übergang: Der Wechsel von einem Zustand in den nächsten (ggf. mit Aktion).
• Aktionen: Was beim Eintritt, während des Zustands oder beim Verlassen passiert.

Wenn Sie die Theorie vertiefen möchten, ist eine gute Ausgangsbasis der Überblick zu endlichen Automaten: Endlicher Automat (Wikipedia). Für praxisnahes Software-Design ist außerdem der Blick auf Zustandsmaschinen in der Softwarearchitektur hilfreich: Martin Fowler: Patterns und Entwurfsdenken (als Einstieg in strukturiertes Verhalten; nicht nur für State Machines).

Warum State Machines Projekte „sauber“ machen

Viele Projekte starten übersichtlich und werden dann mit jeder Funktion unübersichtlicher: ein neues Feature, ein neuer Sonderfall, ein weiterer Timer, ein weiterer Kommunikationsweg. Ohne klare Struktur entsteht oft „Spaghetti-Logik“: Flags beeinflussen sich gegenseitig, der Programmfluss ist nicht mehr offensichtlich, und ein Fix an einer Stelle bricht etwas an anderer Stelle. Zustandsautomaten schaffen Ordnung durch klare Grenzen.

• Lesbarkeit: Der aktuelle Zustand erklärt, „wo“ das Programm gerade ist.
• Testbarkeit: Sie können Zustände isoliert testen (Inputs → erwartete Übergänge).
• Robustheit: Unerwartete Ereignisse können pro Zustand definiert abgefangen werden.
• Skalierbarkeit: Neue Zustände/Übergänge lassen sich hinzufügen, ohne alles umzubauen.
• Timing ohne Blockieren: In Kombination mit millis() bleiben Systeme reaktionsfähig.

Die häufigsten Anti-Patterns, die State Machines ersetzen

Wenn Sie sich fragen, ob Ihr Code von einem Zustandsautomaten profitieren würde, prüfen Sie diese typischen Muster:

• Viele globale Flags: isRunning, hasError, stepDone, modeX – und keiner weiß, welche Kombination erlaubt ist.
• Verschachtelte Bedingungen: if in if in if (insbesondere in der Hauptschleife).
• delay()-Ketten: Der Ablauf ist „einfach“, aber das System ist in der Zeit blind und reagiert nicht.
• Implizite Zustände: Der „Zustand“ steht nicht im Code, sondern ergibt sich aus Nebenbedingungen.

Gerade der Umstieg von delay() auf nicht-blockierendes Timing ist ein Klassiker. Die Arduino-Referenz zu millis() ist eine nützliche Quelle: Arduino millis() Referenz.

Der einfachste Einstieg: Switch-Case State Machine

Für viele Mikrocontroller-Projekte reicht eine einfache State Machine, die den Zustand in einer Variablen hält und in der Hauptschleife per switch abarbeitet. Der Vorteil: Sie bleiben in einer vertrauten Denkweise, gewinnen aber Struktur und Klarheit.

• State-Variable: Ein enum (oder Konstanten), die alle Zustände beschreibt.
• Pro Zustand: Eingaben prüfen, Aktionen ausführen, Bedingungen für Übergänge bewerten.
• Übergang: State-Variable setzen, ggf. Zeitstempel oder Kontext aktualisieren.

Wichtig ist, dass jeder Zustand „kleine Schritte“ ausführt und schnell wieder zurückkehrt, damit andere Aufgaben nicht blockiert werden. So entsteht quasi „Kooperatives Multitasking“: Jede Schleifeniteration erledigt ein bisschen etwas – aber nie so lange, dass das System stehenbleibt.

Eintritt, Ausführung, Austritt: Drei Phasen sauber trennen

Ein häufiger Grund für unruhige oder fehleranfällige Zustandsmaschinen ist, dass Einmal-Aktionen und Wiederhol-Aktionen vermischt werden. Eine bewährte Struktur ist daher, pro Zustand drei Arten von Verhalten zu unterscheiden:

• On-Enter: Einmalig beim Wechsel in den Zustand (z. B. Displayzeile initial setzen, Timer starten).
• On-Update: Wiederholt in jeder Schleife, solange der Zustand aktiv ist (z. B. Sensor pollt, PWM anpasst).
• On-Exit: Einmalig beim Verlassen (z. B. Motor stoppen, Logging finalisieren).

Praktisch lässt sich das ohne komplizierte Frameworks umsetzen, indem Sie beim Zustandswechsel einen Zeitstempel oder ein „entered“-Flag setzen. Der Code bleibt dadurch nicht nur stabiler, sondern auch einfacher zu lesen.

Ereignisgetrieben statt bedingungsgetrieben denken

Viele Anfänger bauen Zustandsautomaten rein über Bedingungen: „Wenn X und Y, dann Zustand wechseln“. Das funktioniert, führt aber häufig zu unübersichtlichen Übergängen. Eleganter ist ein ereignisgetriebener Ansatz: Sie definieren Ereignisse (Events) wie BUTTON_PRESSED, TIMEOUT, SENSOR_OK, SENSOR_FAIL. Dann entscheidet jeder Zustand, wie er auf ein Ereignis reagiert.

• Vorteil: Ereignisse werden zentral erkannt, Zustände reagieren klar definiert.
• Konsequenz: Weniger doppelte Logik, weniger „zufällige“ Übergänge.
• Skalierung: Neue Events ergänzen Sie, ohne jeden Zustand unkontrolliert anzufassen.

Formales Modell: Übergangsfunktion als Denkwerkzeug

Sie müssen die formale Theorie nicht auswendig kennen, aber sie hilft beim Entwurf: Ein Zustandsautomat kann als Übergangsfunktion verstanden werden, die aus aktuellem Zustand und Eingabe/Ereignis den nächsten Zustand bestimmt.

$\delta (q,e)=q\prime$

Dabei ist q der aktuelle Zustand, e ein Ereignis und q′ der Folgezustand. Diese Sichtweise ist besonders nützlich, wenn viele Übergänge möglich sind: Sie können eine „Übergangstabelle“ denken (oder auf Papier skizzieren), bevor Sie Code schreiben. Wer tiefer in Modellierung einsteigen möchte, findet im UML-Kontext einen guten Überblick: Zustandsdiagramm (Wikipedia).

Hierarchische State Machines: Wenn ein Zustand zu groß wird

In echten Projekten werden Zustände manchmal zu „Sammelcontainern“: Der Zustand „RUNNING“ enthält plötzlich 20 Unterfälle. Das ist ein Signal für eine hierarchische Zustandsmaschine (HSM). Dabei hat ein Oberzustand gemeinsame Logik (z. B. „System läuft“), und Unterzustände definieren Details (z. B. „Messen“, „Senden“, „Warten auf Antwort“).

• Oberzustand: Gemeinsame Regeln (z. B. Not-Aus, Fehlerbehandlung, Watchdog-Kick).
• Unterzustände: Fachlogik, die innerhalb des Oberzustands wechselt.
• Vorteil: Weniger Code-Duplizierung und klarere Verantwortlichkeiten.

Für Embedded-Projekte ist das besonders hilfreich, wenn Sicherheits- oder Fehlerlogik überall gelten soll, aber die eigentlichen Abläufe variieren.

Parallelität ohne Chaos: Mehrere State Machines statt „Super-State“

Ein sehr praxistaugliches Muster ist, nicht eine riesige State Machine zu bauen, sondern mehrere kleine, die nebeneinander laufen. Beispiel: Eine State Machine für die Benutzeroberfläche, eine für die Sensorik, eine für Kommunikation, eine für Aktorsteuerung. Jede bleibt klein und verständlich, und in der Hauptschleife rufen Sie sie nacheinander auf.

• UI-Automat: Menüs, Tasten, Display-Updates.
• Sensor-Automat: Messen, Filtern, Plausibilisieren, Kalibrieren.
• Comm-Automat: Verbinden, Senden, Warten, Retry, Fehler.
• Aktor-Automat: Anlaufen, regeln, stoppen, Schutzfunktionen.

Dieses „Kompositionsprinzip“ passt hervorragend zu nicht-blockierendem Code: Jede Maschine macht pro Loop nur kleine Schritte. Das ist oft die sauberste Projektstruktur, wenn mehrere Dinge gleichzeitig passieren sollen.

Time-outs, Retries und Debounce als Zustandslogik

Viele typische Embedded-Probleme lassen sich elegant als Zustände modellieren, statt als verstreute Timer-Variablen:

• Debounce von Tastern: Zustände „Idle“, „Prellphase“, „Pressed“, „Released“.
• Kommunikation mit Antwort: „Send“, „WaitForAck“, „Retry“, „Fail“.
• Sensor-Plausibilisierung: „Measure“, „Validate“, „Accept“, „Reject“.

Der Nutzen ist enorm: Zeitouts sind nicht „Zahlen im Code“, sondern ein expliziter Teil des Ablaufs. Dadurch finden Sie Fehler schneller und können das Verhalten leichter ändern.

Fehlerbehandlung mit Zuständen statt Ausnahme-Logik

Ein häufiger Stabilitätsgewinn entsteht, wenn Fehler nicht als „Sonderfall im selben Codepfad“ behandelt werden, sondern als eigener Zustand. Ein „ERROR“-Zustand kann:

• Ausgänge in einen sicheren Zustand bringen
• Fehler anzeigen (LED, Display, Log)
• automatische Wiederherstellung versuchen (z. B. nach Zeit)
• manuelle Quittierung erfordern (Taste, Kommando)

So verhindern Sie, dass sich Fehler quer durch normale Abläufe ziehen und später schwer reproduzierbare Folgeschäden erzeugen.

Projektstruktur: Wie State Machines Ihren Code organisiert halten

Saubere Projektstrukturen entstehen nicht nur durch den Zustandsautomaten selbst, sondern durch die Art, wie Sie ihn in Dateien und Module schneiden. Bewährte Strukturprinzipien:

• Trennung von Logik und Hardware: Zustandslogik kennt keine Pin-Nummern, sondern ruft Hardware-Funktionen auf (z. B. motor_set_speed).
• Trennung von Input und State Update: Inputs sammeln, dann State Machines updaten, dann Outputs setzen.
• Zustandsdaten kapseln: Kontext (Timer, letzte Werte, Retry-Zähler) gehört zur State Machine, nicht als wilde globale Variablen.
• Dokumentation im Code: Pro Zustand kurz beschreiben: Zweck, Eintritt, Exit, Übergänge.

Wenn Sie diese Trennung konsequent einhalten, wird Ihr Projekt nicht nur stabiler, sondern auch leichter erweiterbar – besonders, wenn später weitere Sensoren, Kommunikationswege oder UI-Elemente dazukommen.

Praxisregeln: So bleibt Ihre State Machine wartbar

• Zustände klein halten: Ein Zustand sollte eine klare Aufgabe haben, keine „Mini-App“ sein.
• Übergänge explizit machen: Jede Zustandsänderung sollte an wenigen Stellen passieren.
• Keine versteckten Seiteneffekte: Übergänge nicht „nebenbei“ in Hilfsfunktionen auslösen.
• Default-Verhalten definieren: Was passiert, wenn ein Event im aktuellen Zustand nicht vorgesehen ist?
• Kontext bewusst speichern: Zeitstempel, Retry-Zähler, Flags gehören strukturiert in den Zustand-Kontext.

Werkzeuge und weiterführende Quellen für bessere Zustandsmodelle

• Endlicher Automat: Grundlagen und Begriffsklärung
• Zustandsdiagramm: Zustände und Übergänge visualisieren
• Arduino millis(): Nicht-blockierendes Timing als Basis für State Machines
• Crash Course in UML State Machines (praxisnahes PDF)

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.