1. 簡介
現代園藝與農業越來越依賴自動化來優化資源使用,特別是水——在許多地區是一種稀缺資源。一個智慧灌溉控制器根據即時土壤狀況自動灌溉,而非固定時鐘,減少浪費,防止過度或不足灌溉,並促進植物更健康的生長。
本案例研究著重於使用UML狀態機圖 (也稱為狀態圖)。該圖捕捉系統的生命周期、決策點以及對濕度讀數、逾時和使用者干預等事件的回應。
設計使用PlantUML語法,類似於所提供的咖啡店範例,能優雅地模擬複合狀態、守衛條件、動作以及錯誤/恢復路徑。
2. 問題陳述與需求
家用花園或小型溫室的自動灌溉控制器必須:

- 大多數時間處於低功耗待機模式。
- 根據時程(定時觸發)定期喚醒以檢查狀況。
- 進入感測狀態,以讀取土壤濕度(透過電容式或電阻式感測器)。
- 若濕度 < 30%(可設定的乾燥閾值),開始灌溉透過打開電磁閥或啟動水泵。
- 若濕度 ≥ 30%,返回至待機(無需澆水)。
- 當灌溉中,持續(或定期)監測濕度。
- 當出現以下情況時,停止灌溉並關閉閥門:
- 濕度達到80%(可設定的濕度閾值)→ 目標達成。
- 一個安全超時到期(例如 30 分鐘)→ 若感測器故障,可防止淹水、管線破裂或電氣問題。
- 停止灌溉後,切換至關機狀態。
- 在關機狀態下,等待手動確認(按鈕按壓或應用程式指令)後,再返回至待機——這允許使用者檢查系統或必要時進行手動覆蓋。
- 透過切換至錯誤狀態並提供恢復選項,以妥善處理故障(例如感測器故障、閥門卡住)。
其他理想行為(此處保持簡化):
- 特定時段內不進行灌溉(由排程/定時器處理)。
- 記錄或通知不在此核心狀態機的範圍內。
3. 使用的核心狀態機概念
- 狀態: 空閒/待機、感測、灌溉、關機、錯誤。
- 複合狀態: 灌溉包含內部監控邏輯(儘管為簡化起見在此保持平坦)。
- 轉移:
- 由事件觸發(計時器、濕度讀取、逾時)。
- 由條件保護 [濕度 < 30%],[濕度 >= 80%]。
- 動作: /open_valve(),/close_valve(),/notify_user(),等等。
- 初始/最終虛擬狀態: [*] 用於開始/結束。
- 自我轉移以及恢復迴圈。
4. PlantUML 中的狀態圖
以下是實現所述行為的完整 PlantUML 程式碼。它遵循咖啡店範例的規範(skinparam 風格、適當使用複合狀態、條件用 [] 表示、動作用 / 表示)。
plantuml
@startuml
skinparam {
‘ 整體風格
‘ 顏色
箭頭顏色 #333333
箭頭字體顏色 #333333
背景顏色 #FFFFFF
邊框顏色 #333333
‘ 狀態樣式
狀態 {
邊框顏色 #005073
背景顏色 #E6F5FF
字體顏色 #005073
}
}
[*] –> 待機
待機 –> 檢測 : 定時器觸發()
檢測 –> 灌溉 : 土壤濕度 < 30%
檢測 –> 待機 : 土壤濕度 >= 30%
灌溉 –> 停機 : 土壤濕度 >= 80% 或 安全超時()
灌溉 –> 停機 : 安全超時() // 備用超時保護
停機 –> 待機 : 使用者確認重置()
待機 –> [*]
@enduml
圖示說明
- 待機 — 預設低功耗/空閒狀態。
- 檢測 — 由定時器觸發的快速檢查;避免不必要的灌溉。
- 灌溉 (複合) — 內部包含「灌溉」子活動的主動灌溉階段。灌溉 子活動。
- 停機 — 灌溉後的暫停狀態,需確認後才能恢復自動化(安全功能)。
- 錯誤 — 故障隔離狀態,需手動恢復轉移。
5. 設計原理與優勢
- 節水 — 僅在真正需要時才灌溉(基於土壤濕度,而非時間)。
- 防洪 — 灌溉階段設有雙重退出條件(濕度目標 + 超時)。
- 使用者安全與控制 — 異常停止後的手動確認可防止潛在問題後的自動重新啟動。
- 可擴展性 — 容易新增狀態(例如,偵測到降雨, 電量不足, 冬季模式)或調整閾值。
- 低複雜度 — 在可能的情況下保持扁平化,僅在邏輯分組能提升清晰度時才使用複合結構(例如:灌溉中)。
此設計在穩健性、安全性與簡潔性之間取得平衡——適合嵌入式微控制器實現(如 Arduino、ESP32 等)。
6. 結論
狀態機狀態機為建模反應式控制系統(如智慧灌溉控制器)提供了優異的形式化方法。透過明確定義狀態、事件、守衛條件與動作,工程師可在撰寫程式前,深入分析系統行為、邊界情況與錯誤恢復機制。
上述的 PlantUML 表示法兼具文件與實作藍圖的功能。透過 PlantUML 工具或線上伺服器渲染後,可產生清晰且專業的圖示,適用於需求審查、程式碼生成或教授 UML 概念。
未來的擴展功能可包括:
- 天氣 API 整合(若預報有雨,則跳過感測)。
- 多個區域,並針對各區域設定不同的濕度閾值。
- 在逾時或發生錯誤時,透過行動應用程式發送通知。
本案例研究顯示,看似簡單的自動化問題,透過結構化的狀態模型可獲得顯著改善。