Fallstudie: Zustandsmaschinen-Design für einen intelligenten Bewässerungs-Steuerungs-Controller für einen Garten

1. Einleitung

Moderne Gartenbau- und Landwirtschaftspraktiken verlassen sich zunehmend auf Automatisierung, um den Ressourceneinsatz zu optimieren, insbesondere Wasser – eine knappe Ressource in vielen Regionen. Ein intelligenter Bewässerungs-Steuerungs-Controller automatisiert die Bewässerung basierend auf Echtzeit-Bodenbedingungen anstelle von festen Zeitintervallen, reduziert Verschwendung, verhindert Über- oder Unterbewässerung und fördert ein gesünderes Pflanzenwachstum.

Diese Fallstudie konzentriert sich auf die Verhaltensmodellierung eines solchen Systems mithilfe einer UML-Zustandsmaschinen-Diagramm (auch Zustandsdiagramm genannt). Das Diagramm erfasst den Lebenszyklus des Systems, Entscheidungspunkte und Reaktionen auf Ereignisse wie Feuchtigkeitsmessungen, Zeitüberschreitungen und Benutzerinterventionen.

Das Design verwendet PlantUMLSyntax, ähnlich dem bereitgestellten Kaffeehaus-Beispiel, das komposite Zustände, Wächter, Aktionen und Fehler-/Wiederherstellungspfade elegant modelliert.

2. Problemstellung und Anforderungen

Ein automatischer Bewässerungs-Steuerungs-Controller für einen Heimgarten oder einen kleinen Gewächshaus muss:

  • Starte im energiesparenden StandbyModus die meiste Zeit.
  • Wache periodisch gemäß einem Zeitplan (Zeitgeber-Auslöser) auf, um die Bedingungen zu überprüfen.
  • Gehe in den SensingZustand, um den Bodenfeuchtigkeitswert zu lesen (über kapazitive oder widerstandsbasierte Sensoren).
  • Wenn Feuchtigkeit < 30% (einstellbarer Trocken-Schwellwert), starte Bewässerungdurch Öffnen eines Magnetventils oder Aktivieren einer Pumpe.
  • Wenn Feuchtigkeit ≥ 30%, kehre zurück zu Wartezustand (keine Bewässerung erforderlich).
  • Während Bewässerung, kontinuierlich (oder periodisch) Feuchtigkeit überwachen.
  • Bewässerung stoppen und das Ventil schließen, wenn:
    • Die Feuchtigkeit erreicht 80% (einstellbarer Feuchtigkeits-Schwellwert) → Ziel erreicht.
    • Ein Sicherheits-Timeout läuft ab (z. B. 30 Minuten) → verhindert Überschwemmungen, Rohrbrüche oder elektrische Probleme, falls der Sensor ausfällt.
  • Nach Beendigung der Bewässerung in den Zustand Abschaltung übergehen.
  • Im Zustand Abschaltung, warten auf manuelle Bestätigung (Tastendruck oder App-Befehl), bevor zurückgekehrt wird zu Wartezustand — dies ermöglicht es dem Benutzer, das System zu überprüfen oder gegebenenfalls zu überschreiben.
  • Behandle Fehler ordnungsgemäß (z. B. Sensorausfall, Ventil verkeilt) durch Wechsel in den Zustand Fehler mit Wiederherstellungsoptionen.

Zusätzliche wünschenswerte Verhaltensweisen (hier einfach gehalten):

  • Keine Bewässerung zu bestimmten Zeiten (durch Zeitplan/Timer behandelt).
  • Protokollierung oder Benachrichtigungen liegen außerhalb des Umfangs dieser Kernzustandsmaschine.

3. Verwendete Schlüsselkonzepte der Zustandsmaschine

  • Zustände: Leerlauf/Standby, Erfassung, Bewässerung, Abschaltung, Fehler.
  • Verbundzustand: Bewässerung beinhaltet interne Überwachungslogik (obwohl hier zur Vereinfachung flach gehalten).
  • Übergänge:
    • Ausgelöst durch Ereignisse (Timer, Feuchtigkeitsmessung, Timeout).
    • Geschützt durch Bedingungen [Feuchtigkeit < 30%], [Feuchtigkeit >= 80%].
  • Aktionen: /open_valve(), /close_valve(), /notify_user(), usw.
  • Anfangs-/Endpseudozustände: [*] für Start/Ende.
  • Selbstübergänge und Wiederherstellungsschleifen.

4. Zustandsdiagramm in PlantUML

Unten finden Sie den vollständigen PlantUML-Code, der das beschriebene Verhalten implementiert. Er folgt den Konventionen des Kaffeehaus-Beispiels (skinparam-Stil, Verbundzustände wo angebracht, Bedingungen in [], Aktionen mit /).

PlantUML
@startuml

skinparam {
' Gesamtstil
' Farben
ArrowColor #333333
ArrowFontColor #333333
BackgroundColor #FFFFFF
BorderColor #333333

' Zustandsformatierung
State {
BorderColor #005073
BackgroundColor #E6F5FF
FontColor #005073
}
}

[*] --> Standby

Standby --> Sensing : timer_triggers()

Sensing --> Irrigating : soil_moisture < 30%
Sensing --> Standby : soil_moisture >= 30%

Irigating --> Shutdown : soil_moisture >= 80% ODER safety_timeout()
Irigating --> Shutdown : safety_timeout() // Fallback-Timeout-Schutz

Shutdown --> Standby : user_confirms_reset()

Standby --> [*]

@enduml

Erklärung des Diagramms

  • Standby — Standardzustand mit geringem Energieverbrauch/Leerlauf.
  • Erfassung — Schnelle Überprüfung, ausgelöst durch Timer; vermeidet unnötige Bewässerung.
  • Bewässerung (Verbund) — Aktive Bewässerungsphase mit internerBewässerung Unteraktivität.
    • Beendet sich bei Erreichen der Zielfeuchtigkeit oder bei Sicherheits-Timeout.
  • Herunterfahren — Zustand nach der Bewässerung, der eine Bestätigung erfordert, um die Automatisierung fortzusetzen (Sicherheitsfunktion).
  • Fehler — Zustand zur Fehlerbegrenzung mit manueller Wiederherstellung.

5. Design-Gründe und Vorteile

  • Wasserschonung — Bewässert nur, wenn tatsächlich erforderlich (basiert auf Bodenfeuchte statt Zeitplan).
  • Überschwemmungsverhütung — Zwei Ausgangsbedingungen aus dem Bewässerungszustand (Feuchteziel + Timeout).
  • Benutzersicherheit und Kontrolle — Manuelle Bestätigung nach einem abnormalen Stopp verhindert eine automatische Neustart nach möglichen Problemen.
  • Erweiterbarkeit — Einfach erweiterbar durch Hinzufügen von Zuständen (z. B. Regen erkannt, Niedriger Akkustand, Wintermodus) oder Schwellenwerte anpassen.
  • Geringe Komplexität — So flach wie möglich, zusammengesetzt nur dort, wo logische Gruppierung Klarheit schafft (Bewässerung).

Dieses Design bietet ein Gleichgewicht zwischen Robustheit, Sicherheit und Einfachheit – geeignet für die Implementierung auf eingebetteten Mikrocontrollern (Arduino, ESP32 usw.).

6. Fazit

ZustandsmaschineZustandsmaschinen bieten ein hervorragendes formales Modell für reaktive Steuerungssysteme wie intelligente Bewässerungssteuerungen. Durch die klare Definition von Zuständen, Ereignissen, Bedingungen und Aktionen können Ingenieure das Systemverhalten, Randfälle und Fehlerbehebung bereits vor der Code-Implementierung analysieren.

Die obenstehende PlantUML-Darstellung dient sowohl als Dokumentation als auch als Bauplan für die Implementierung. Die Darstellung (mittels PlantUML-Tools oder Online-Server) erzeugt ein sauberes, professionelles Diagramm, das für Anforderungsreviews, Codegenerierung oder die Vermittlung von UML-Konzepten geeignet ist.

Zukünftige Erweiterungen könnten beinhalten:

  • Integration von Wetter-APIs (Sensing überspringen, wenn Regen vorhergesagt wird).
  • Mehrere Zonen mit zonenbezogenen Feuchteschwellenwerten.
  • Benachrichtigungen über eine Mobile-App bei Timeout oder Fehler.

Diese Fallstudie zeigt, wie ein scheinbar einfaches Automatisierungsproblem erheblich von einer strukturierten, zustandsbasierten Modellierung profitiert.