Read this post in: en_USes_ESfr_FRid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Fallstudie: Zustandsmaschinen-Design für einen intelligenten Bewässerungsregler für einen Garten

AI ChatbotAIYesterday

1. Einleitung

Moderne Gartenbau- und Landwirtschaft prägen sich zunehmend durch Automatisierung aus, um den Ressourceneinsatz zu optimieren, insbesondere Wasser – eine knappe Ressource in vielen Regionen. Ein intelligenter Bewässerungsregler automatisiert die Bewässerung basierend auf Echtzeit-Bodenbedingungen anstelle fester Timer, 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 eines UML-Zustandsmaschinen-Diagramm (auch Zustandsdiagramm genannt). Das Diagramm erfasst den Lebenszyklus des Systems, Entscheidungspunkte und Reaktionen auf Ereignisse wie Feuchtigkeitsmessungen, Zeitüberschreitungen und Benutzerinteraktionen.

Das Design verwendet PlantUMLSyntax, ähnlich dem bereitgestellten Kaffeehaus-Beispiel, das geschickt zusammengesetzte Zustände, Bedingungen, Aktionen und Fehler-/Wiederherstellungspfade modelliert.

2. Problemstellung und Anforderungen

Ein automatischer Bewässerungsregler für einen Hausgarten oder ein kleines Gewächshaus muss:

  • Starte im energiesparenden StandbyModus die meiste Zeit.
  • Wache sich periodisch gemäß einem Zeitplan (Timer-Auslöser) auf, um die Bedingungen zu überprüfen.
  • Gehe in den Zustand Sensingzum Ablesen des Bodenfeuchtigkeitsniveaus (über kapazitiven oder widerstandsbasierten Sensor).
  • Wenn Feuchtigkeit < 30% (einstellbarer Trocken-Schwellwert), beginne 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:
    • Feuchtigkeit erreicht 80% (einstellbarer Feuchtigkeits-Schwellenwert) → Ziel erreicht.
    • Ein Sicherheits-Timeout läuft ab (z. B. 30 Minuten) → verhindert Überschwemmung, Rohrbrüche oder elektrische Probleme bei Sensorausfall.
  • Nach Beendigung der Bewässerung zum Zustand Abschaltung übergehen.
  • Im Abschaltung, warten auf manuelle Bestätigung (Tastendruck oder App-Befehl), bevor zurückgekehrt wird zu Wartezustand — dies ermöglicht dem Benutzer, das System zu überprüfen oder bei Bedarf zu überschreiben.
  • Behandle Fehler reibungslos (z. B. Sensorausfall, Ventil blockiert), indem du in einen FehlerZustand mit Wiederherstellungsoptionen wechselst.

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

  • Keine Bewässerung zu bestimmten Stunden (durch Planung/Uhrzeit gesteuert).
  • Protokollierung oder Benachrichtigungen liegen außerhalb des Umfangs dieser Kernzustandsmaschine.

3. Verwendete Schlüsselkonzepte der Zustandsmaschine

  • Zustände: Leerlauf/Bereitschaft, Erfassung, Bewässerung, Herunterfahren, 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: /öffneVentil(), /schließeVentil(), /benachrichtigeBenutzer(), usw.
  • Anfangs-/Endpseudozustände: [*] für Start/Ende.
  • Selbstübergänge und Wiederherstellungsschleifen.

4. Zustandsdiagramm in PlantUML

Unten ist der vollständige PlantUML-Code zur Umsetzung des beschriebenen Verhaltens. Er folgt den Konventionen des Kaffeehaus-Beispiels (skinparam-Stil, Verbundzustände wo angebracht, Bedingungen in [], Aktionen mit /).

PlantUML

@startuml

skinparam {
‘ Gesamter Stil
‘ Farben
Pfeilfarbe #333333
Pfeilschriftfarbe #333333
Hintergrundfarbe #FFFFFF
Rahmenfarbe #333333

‘ Zustandsstil
Zustand {
Rahmenfarbe #005073
Hintergrundfarbe #E6F5FF
Schriftfarbe #005073
}
}

[*] –> Bereitschaft

Bereitschaft –> Erfassung : timer_triggers()

Erfassung –> Bewässerung : bodenfeuchte < 30%
Erfassung –> Bereitschaft : bodenfeuchte >= 30%

Bewässerung –> Abschaltung : bodenfeuchte >= 80% ODER sicherheits_timeout()
Bewässerung –> Abschaltung : sicherheits_timeout() // Fallback-Timeout-Schutz

Abschaltung –> Bereitschaft : benutzer_bestätigt_rücksetzen()

Bereitschaft –> [*]

@enduml

Erklärung des Diagramms

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

5. Design-Überlegungen und Vorteile

  • Wasserschonung — Bewässert nur, wenn tatsächlich nötig (basiert auf Bodenfeuchte statt Zeit).
  • Überflutungsschutz — Zwei Ausgangsbedingungen aus der Bewässerung (Zielfeuchte + Timeout).
  • Benutzersicherheit und -kontrolle — Eine manuelle Bestätigung nach einem abnormalen Stopp verhindert einen automatischen Neustart nach möglichen Problemen.
  • Erweiterbarkeit — Einfach, Zustände hinzuzufügen (z. B. Regen erkannt, Niedriger Akkustand, Wintermodus) oder Schwellenwerte anpassen.
  • Geringer Komplexitätsgrad — So flach wie möglich, zusammengesetzt nur dort, wo eine logische Gruppierung Klarheit bringt (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, Grenzfälle und Fehlerbehandlung vor der Codeerstellung analysieren.

Die oben stehende 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 Anforderungsüberprüfungen, Codegenerierung oder die Vermittlung von UML-Konzepten geeignet ist.

Zukünftige Erweiterungen könnten beinhalten:

  • Integration von Wetter-APIs (Sensoren überspringen, falls Regen vorhergesagt wird).
  • Mehrere Zonen mit zonenbezogenen Feuchtigkeits-Schwellenwerten.
  • Benachrichtigungen über eine Mobile-App bei Zeitüberschreitung oder Fehler.

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

Sidebar Search
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...