1. Wprowadzenie
Nowoczesne ogrodnictwo i rolnictwo coraz częściej opierają się na automatyzacji w celu optymalizacji zużycia zasobów, szczególnie wody — zasobu rzadkiego w wielu regionach. System inteligentny sterownik podlewania automatyzuje podlewania na podstawie rzeczywistych warunków gleby zamiast ustalonych timerów, zmniejszając straty, zapobiegając nadmiernemu lub niedostatecznemu podlewaniu oraz wspierając zdrowszy wzrost roślin.
Ten studium przypadku skupia się na modelowaniu zachowania takiego systemu za pomocą diagram maszyny stanów UML (nazywany również diagramem stanów). Diagram ten uchwyca cykl życia systemu, punkty decyzyjne oraz reakcje na zdarzenia, takie jak odczyty wilgotności, wygaśnięcia timera i interwencje użytkownika.
Projekt wykorzystuje składnię PlantUMLsyntax, podobną do przykładu z kawiarni podanego, która elegancko modeluje stany złożone, warunki (guardy), działania oraz ścieżki błędów/odzyskiwania.
2. Sformułowanie problemu i wymagania
Automatyczny sterownik podlewania dla ogrodu domowego lub małego szklarni musi:

- Rozpocząć działanie w trybie Oczekiwanianajczęściej w trybie niskiego zużycia mocy.
- Okazjonalnie budzić się zgodnie z harmonogramem (wyzwalacz timera), aby sprawdzić warunki.
- Wejść w stan Sondowania aby odczytać poziom wilgotności gleby (przez czujnik pojemnościowy lub rezystancyjny).
- Jeśli wilgotność < 30% (próg konfigurowalny dla suchości), rozpocząć Podlewania otwierając zawór elektromagnetyczny lub aktywując pompy.
- Jeśli wilgotność ≥ 30%, powrócić do Gotowy (podlewanie nie jest potrzebne).
- Podczas gdy Podlewania, ciągle (lub okresowo) monitoruj wilgotność.
- Zatrzymaj podlewania i zamknij zawór, gdy:
- Wilgotność osiąga 80% (dostosowalny próg wilgotności) → cel osiągnięty.
- Za Czas wyłącznika bezpieczeństwa wygasa (np. 30 minut) → zapobiega zalaniu, pęknięciom rur lub problemom elektrycznym, jeśli czujnik się nie powiedzie.
- Po zatrzymaniu podlewania przejdź do Wyłączenia stanu.
- W Wyłączenia, czekaj na potwierdzenie ręczne (naciśnięcie przycisku lub polecenie aplikacji) przed powrotem do Gotowy — umożliwia użytkownikowi sprawdzenie systemu lub jego przejęcie, jeśli to konieczne.
- Obsługuj błędy zgodnie z zasadami (np. awaria czujnika, zawór zablokowany) poprzez przejście do stanu Błąd stanu z opcjami odzyskania.
Dodatkowe pożądane zachowania (utrzymane prosto tutaj):
- Brak podlewania w określonych godzinach (zarządzane przez harmonogram/czasomierz).
- Rejestrowanie lub powiadomienia są poza zakresem tego podstawowego maszyn stanów.
3. Kluczowe koncepcje maszyny stanów użyte
- Stany: Bezczynność/Stan gotowości, wykrywanie, podlewania, zatrzymanie, błąd.
- Stan złożony: Podlewania obejmuje logikę wewnętrznej kontroli (choć utrzymywana jest płaska tutaj dla uproszczenia).
- Przejścia:
- Wyzwalane przez zdarzenia (timer, odczyt wilgotności, przekroczenie czasu).
- Chronione warunkami [wilgotność < 30%], [wilgotność >= 80%].
- Działania: /otworz zawór(), /zamknij zawór(), /powiadom użytkownika(), itd.
- Pseudostany początkowy / końcowy: [*] dla początku/końca.
- Przejścia samodzielne oraz pętle odzyskiwania.
4. Diagram stanów w PlantUML
Poniżej znajduje się kompletny kod PlantUML implementujący opisane zachowanie. Używa konwencji z przykładu kawiarni (stylowanie skinparam, stany złożone tam gdzie odpowiednio, warunki w [], działania z /).
plantuml
@startuml
skinparam {
‘ Ogólny styl
‘ Kolory
KolorStrzałki #333333
KolorCzcionkiStrzałki #333333
KolorTła #FFFFFF
KolorObramowania #333333
‘ Stylowanie stanów
Stan {
KolorObramowania #005073
KolorTła #E6F5FF
KolorCzcionki #005073
}
}
[*] –> Gotowy
Gotowy –> Wykrywanie : timer_wywołuje()
Wykrywanie –> Irigacja : wilgotność_rolna < 30%
Wykrywanie –> Gotowy : wilgotność_rolna >= 30%
Irigacja –> Zatrzymanie : wilgotność_rolna >= 80% OR timeout_zabezpieczenia()
Irigacja –> Zatrzymanie : timeout_zabezpieczenia() // Ochrona awaryjna przed przekroczeniem czasu
Zatrzymanie –> Gotowy : użytkownik_potwierdza_reset()
Gotowy –> [*]
@enduml
Wyjaśnienie diagramu
- Gotowy — Domyślny stan niskiego zużycia/mocy
- Wykrywanie — Szybka kontrola wyzwalana timere; unika niepotrzebnego podlewania.
- Irigacja (złożony) — Aktywna faza podlewania z wewnętrznąPodlewaniem aktywnością.
- Zakończenie przy docelowej wilgotności lub przekroczeniu czasu zabezpieczenia.
- Zatrzymanie — Stan zatrzymania po podlewaniu wymagający potwierdzenia do wznowienia automatyzacji (funkcja bezpieczeństwa).
- Błąd — Stan zawężenia uszkodzenia z przejściem ręcznym do odzyskania.
5. Podstawy projektu i korzyści
- Oszczędzanie wody — Podlewa tylko wtedy, gdy jest to naprawdę potrzebne (na podstawie wilgotności gleby, a nie czasu).
- Zapobieganie powodzi — Dwa warunki wyjścia z fazy irygacji (docelowa wilgotność + timeout).
- Bezpieczeństwo użytkownika i kontrola — Potwierdzenie ręczne po nieprzewidzianym zatrzymaniu zapobiega automatycznemu ponownemu uruchomieniu po możliwych problemach.
- Rozszerzalność — Łatwe dodawanie stanów (np. Wykryto deszcz, Niski poziom baterii, Tryb zimowy) lub dostosowanie progów.
- Niska złożoność — Płaskie tam, gdzie to możliwe, złożone tylko tam, gdzie logiczne grupowanie zwiększa przejrzystość (irygacja).
To projekt balansuje odporność, bezpieczeństwo i prostotę — odpowiedni do wdrożenia na mikrokontrolerach wbudowanych (Arduino, ESP32 itp.).
6. Wnioski
Maszyna stanówMaszyny stanów zapewniają doskonały formalizm do modelowania systemów sterowania reaktywnego, takich jak inteligentne sterowniki irygacji. Poprzez jasne określenie stanów, zdarzeń, warunków i działań inżynierowie mogą analizować zachowanie systemu, przypadki graniczne i odzyskiwanie po błędach jeszcze przed napisaniem kodu.
Reprezentacja PlantUML powyżej pełni rolę zarówno dokumentacji, jak i szkicu do wdrożenia. Jej renderowanie (przez narzędzia PlantUML lub serwery online) generuje czysty, profesjonalny diagram gotowy do przeglądów wymagań, generowania kodu lub nauczania koncepcji UML.
Przyszłe rozszerzenia mogą obejmować:
- Integracja z API pogodowym (pomiń czujniki, jeśli prognozowany jest deszcz).
- Wiele stref z progami wilgotności na każdą strefę.
- Powiadomienia aplikacji mobilnej w przypadku przekroczenia czasu lub błędu.
Ten przypadek ilustruje, jak problem automatyzacji, który wydaje się prosty, znacznie korzysta z modelowania opartego na stanach.