Studi Kasus: Desain Mesin Status untuk Pengontrol Irigasi Taman Cerdas

1. Pendahuluan

Berkebunan dan pertanian modern semakin mengandalkan otomasi untuk mengoptimalkan penggunaan sumber daya, terutama air — sumber daya yang langka di banyak wilayah. Sebuah pengontrol irigasi cerdasmengotomatiskan penyiraman berdasarkan kondisi tanah secara real-time daripada menggunakan timer tetap, mengurangi pemborosan, mencegah penyiraman berlebihan atau kurang, serta mendukung pertumbuhan tanaman yang lebih sehat.

Studi kasus ini berfokus pada pemodelan perilaku sistem semacam itu menggunakan diagram mesin status UML (juga disebut diagram statechart). Diagram ini menangkap siklus hidup sistem, titik keputusan, dan respons terhadap peristiwa seperti pembacaan kelembapan, waktu habis, dan intervensi pengguna.

Desain ini menggunakan PlantUMLsintaks, serupa dengan contoh kafe yang disediakan, yang dengan elegan memodelkan status komposit, penjaga, tindakan, serta jalur kesalahan/pemulihan.

2. Pernyataan Masalah & Persyaratan

Sebuah pengontrol irigasi otomatis untuk taman rumahan atau rumah kaca kecil harus:

  • Mulai dalam mode Siagamode sebagian besar waktu.
  • Bangun secara berkala sesuai dengan jadwal (pemicu timer) untuk memeriksa kondisi.
  • Masuk ke status Pendeteksianuntuk membaca tingkat kelembapan tanah (melalui sensor kapasitif atau resistif).
  • Jika kelembapan < 30% (ambang batas kering yang dapat dikonfigurasi), mulai Menyiramdengan membuka katup solenoid atau mengaktifkan pompa.
  • Jika kelembapan ≥ 30%, kembali ke Siaga (tidak perlu penyiraman).
  • Saat Menyiram, terus-menerus (atau secara berkala) pantau kelembapan.
  • Hentikan penyiraman dan tutup katup saat:
    • Kelembapan mencapai 80% (ambang basah yang dapat dikonfigurasi) → target tercapai.
    • Sebuah Waktu Tunda Keamanan berakhir (misalnya, 30 menit) → mencegah banjir, pecahnya pipa, atau masalah listrik jika sensor gagal.
  • Setelah menghentikan penyiraman, pindah ke Mode Mati keadaan.
  • Dalam Mode Mati, tunggu hingga konfirmasi manual (tekanan tombol atau perintah aplikasi) sebelum kembali ke Siaga — ini memungkinkan pengguna memeriksa sistem atau menonaktifkan jika diperlukan.
  • Kelola kesalahan secara baik (misalnya, kegagalan sensor, katup macet) dengan beralih ke status Kesalahan dengan opsi pemulihan.

Perilaku tambahan yang diinginkan (dibuat sederhana di sini):

  • Tidak ada penyiraman selama jam-jam tertentu (ditangani oleh jadwal/waktu).
  • Pencatatan atau pemberitahuan berada di luar cakupan mesin status inti ini.

3. Konsep Mesin Status Utama yang Digunakan

  • Status: Idle/Standby, Pemantauan, Penyiraman, Mati, Kesalahan.
  • Status komposit: Penyiraman mencakup logika pemantauan internal (meskipun dibuat datar di sini untuk kesederhanaan).
  • Transisi:
    • Dipicu oleh peristiwa (timer, bacaan kelembapan, timeout).
    • Dilindungi oleh kondisi [kelembapan < 30%], [kelembapan >= 80%].
  • Aksi: /buka_valve(), /tutup_valve(), /notifikasi_pengguna(), dll.
  • Pseudostate awal / akhir: [*] untuk awal/akhir.
  • Transisi diri dan putaran pemulihan.

4. Diagram Status dalam PlantUML

Di bawah ini adalah kode PlantUML lengkap yang menerapkan perilaku yang dijelaskan. Ini mengikuti konvensi dari contoh kafe (penyempurnaan skinparam, status komposit di tempat yang tepat, penjagaan dalam [], aksi dengan /).

plantuml
@startuml

skinparam {
' Gaya keseluruhan
' Warna
ArrowColor #333333
ArrowFontColor #333333
BackgroundColor #FFFFFF
BorderColor #333333

' Gaya status
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% OR safety_timeout()
Irigating --> Shutdown : safety_timeout() // Perlindungan timeout cadangan

Shutdown --> Standby : user_confirms_reset()

Standby --> [*]

@enduml

Penjelasan Diagram

  • Standby — Status default hemat daya/idle.
  • Pemantauan — Pemeriksaan cepat yang dipicu oleh timer; menghindari penyiraman yang tidak perlu.
  • Penyiraman (komposit) — Fase penyiraman aktif dengan aktivitas bawah internal Penyiraman sub-aktivitas.
    • Keluar saat kelembapan target tercapai atau timeout keselamatan.
  • Hentikan — Status tahan setelah irigasi yang memerlukan konfirmasi untuk melanjutkan otomasi (fitur keselamatan).
  • Kesalahan — Status penahanan kesalahan dengan transisi pemulihan manual.

5. Alasan Desain & Manfaat

  • Konservasi air — Hanya menyiram saat benar-benar diperlukan (berbasis kelembapan tanah alih-alih berbasis waktu).
  • Pencegahan banjir — Kondisi keluar ganda dari menyiram (target kelembapan + waktu habis).
  • Keselamatan dan kendali pengguna — Konfirmasi manual setelah berhenti tidak normal mencegah restart otomatis setelah masalah potensial.
  • Kemampuan ekstensi — Mudah menambahkan status (misalnya, Hujan Terdeteksi, Baterai Rendah, Mode Musim Dingin) atau menyesuaikan ambang batas.
  • Kompleksitas rendah — Rata di mana memungkinkan, komposit hanya jika pengelompokan logis menambah kejelasan (Menyiram).

Desain ini menyeimbangkan ketahanan, keselamatan, dan kesederhanaan — sesuai untuk implementasi mikrokontroler tertanam (Arduino, ESP32, dll.).

6. Kesimpulan

Mesin statuss menyediakan formalisme yang sangat baik untuk memodelkan sistem kontrol reaktif seperti pengontrol irigasi cerdas. Dengan mendefinisikan secara jelas status, peristiwa, penjaga, dan tindakan, insinyur dapat memahami perilaku sistem, kasus batas, dan pemulihan kesalahan sebelum menulis kode.

Representasi PlantUML di atas berfungsi sebagai dokumentasi dan juga gambaran awal untuk implementasi. Menampilkan (melalui alat PlantUML atau server online) menghasilkan diagram yang bersih dan profesional siap untuk tinjauan kebutuhan, generasi kode, atau pengajaran konsep UML.

Ekstensi masa depan bisa mencakup:

  • Integrasi API cuaca (lewatkan Sensing jika prakiraan hujan).
  • Banyak zona dengan ambang batas kelembapan per zona.
  • Pemberitahuan aplikasi mobile saat waktu habis atau terjadi kesalahan.

Studi kasus ini menunjukkan bagaimana masalah otomasi yang tampaknya sederhana sangat diuntungkan dari pemodelan berbasis status yang terstruktur.