Étude de cas : Conception d’une machine à états pour un contrôleur d’arrosage intelligent pour jardin

1. Introduction

Le jardinage et l’agriculture modernes comptent de plus en plus sur l’automatisation pour optimiser l’utilisation des ressources, en particulier l’eau, une ressource rare dans de nombreuses régions. Un contrôleur d’arrosage intelligentautomatise l’arrosage en fonction des conditions réelles du sol plutôt que d’horaires fixes, réduisant ainsi les pertes, évitant le sur-arrosage ou le sous-arrosage, et favorisant une croissance plus saine des plantes.

Cette étude de cas se concentre sur la modélisation du comportement d’un tel système à l’aide d’un diagramme d’états UML (appelé également un diagramme d’états). Ce diagramme capture le cycle de vie du système, les points de décision et les réponses aux événements tels que les mesures d’humidité, les délais d’attente et les interventions utilisateur.

La conception utilise la syntaxe PlantUMLsyntaxe, similaire à l’exemple du café fourni, qui modélise élégamment les états composés, les gardes, les actions et les chemins d’erreur/récupération.

2. Énoncé du problème et exigences

Un contrôleur d’arrosage automatisé pour un jardin domestique ou une petite serre doit :

  • Démarrer en mode Veilleà faible consommation la majeure partie du temps.
  • Se réveiller périodiquement selon un programme (déclencheur de minuterie) pour vérifier les conditions.
  • Passer à l’état Sensing pour lire le niveau d’humidité du sol (via un capteur capacitif ou résistif).
  • Si l’humidité < 30% (seuil de sécheresse configurable), commencer Irrigationen ouvrant une vanne solénoïde ou en activant une pompe.
  • Si l’humidité ≥ 30%, revenir à En attente (pas besoin d’arrosage).
  • Tant que En cours d’arrosage, surveiller continuellement (ou périodiquement) l’humidité.
  • Arrêter l’arrosage et fermer la vanne lorsque :
    • L’humidité atteint 80% (seuil humide réglable) → objectif atteint.
    • Un Délai de sécurité expire (par exemple, 30 minutes) → empêche les inondations, les fuites de tuyaux ou les problèmes électriques en cas de défaillance du capteur.
  • Après avoir arrêté l’arrosage, passer à l’état Arrêt.
  • Dans Arrêt, attendre confirmation manuelle (appui sur bouton ou commande de l’application) avant de revenir à En attente — cela permet à l’utilisateur d’inspecter le système ou de le forcer si nécessaire.
  • Gérer les anomalies de manière appropriée (par exemple, défaillance du capteur, vanne bloquée) en passant à un état Erreur avec des options de récupération.

Comportements supplémentaires souhaitables (maintenus simples ici) :

  • Pas d’arrosage pendant certaines heures (géré par programme/chronomètre).
  • La journalisation ou les notifications sont hors du cadre de cette machine d’états principale.

3. Concepts clés de la machine à états utilisés

  • États: Inactif/En veille, Détection, Arrosage, Arrêt, Erreur.
  • État composite: L’arrosage inclut une logique de surveillance interne (bien que conservée plate ici pour simplifier).
  • Transitions:
    • Déclenchées par des événements (chronomètre, lecture d’humidité, expiration).
    • Protégées par des conditions [humidité < 30 %], [humidité >= 80 %].
  • Actions: /ouvrir_vanne(), /fermer_vanne(), /notifier_utilisateur(), etc.
  • Pseudostates initiaux / finaux: [*] pour le début/la fin.
  • Transitions internes et boucles de récupération.

4. Diagramme d’états en PlantUML

Ci-dessous se trouve le code PlantUML complet mettant en œuvre le comportement décrit. Il suit les conventions de l’exemple de café (style skinparam, états composites là où approprié, gardes entre [], actions avec /).

plantuml
@startuml

skinparam {
' Style général
' Couleurs
ArrowColor #333333
ArrowFontColor #333333
BackgroundColor #FFFFFF
BorderColor #333333

' Style des états
State {
BorderColor #005073
BackgroundColor #E6F5FF
FontColor #005073
}
}

[*] --> En veille

En veille --> Détection : minuteur_active()

Détection --> Arrosage : humidite_sol < 30%
Détection --> En veille : humidite_sol >= 30%

Arrosage --> Arrêt : humidite_sol >= 80% OU delai_securite_expire()
Arrosage --> Arrêt : delai_securite_expire() // Protection par délai de secours

Arrêt --> En veille : utilisateur_confirme_reinitialisation()

En veille --> [*]

@enduml

Explication du diagramme

  • En veille — État par défaut à faible consommation/inactif.
  • Détection — Vérification rapide déclenchée par minuteur ; évite un arrosage inutile.
  • Arrosage (composite) — Phase d’arrosage active avec sous-activité interne Arrosage sous-activité.
    • Sortie lorsque l’humidité cible est atteinte ou après expiration du délai de sécurité.
  • Arrêt — État d’attente post-arrosage nécessitant une confirmation pour reprendre l’automatisation (fonction de sécurité).
  • Erreur — État de containment des pannes avec transition de récupération manuelle.

5. Raisonnement et avantages du design

  • Conservation de l’eau — Arrose uniquement quand cela est réellement nécessaire (basé sur l’humidité du sol plutôt que sur le temps).
  • Prévention des inondations — Deux conditions de sortie de l’état d’arrosage (objectif d’humidité + délai d’expiration).
  • Sécurité et contrôle de l’utilisateur — Confirmation manuelle après une interruption anormale empêche le redémarrage automatique après des problèmes potentiels.
  • Extensibilité — Facile à ajouter des états (par exemple, Pluie détectée, Batterie faible, Mode hiver) ou ajuster les seuils.
  • Faible complexité — Simple là où c’est possible, composé uniquement là où un regroupement logique ajoute de la clarté (arrosage).

Ce design équilibre robustesse, sécurité et simplicité — adapté à une implémentation sur microcontrôleur embarqué (Arduino, ESP32, etc.).

6. Conclusion

Machine à étatsLes machines à états fournissent un formalisme excellent pour modéliser des systèmes de contrôle réactifs comme les contrôleurs d’arrosage intelligents. En définissant clairement les états, les événements, les gardes et les actions, les ingénieurs peuvent raisonner sur le comportement du système, les cas limites et la récupération d’erreurs avant d’écrire du code.

La représentation PlantUML ci-dessus sert à la fois de documentation et de plan directeur pour l’implémentation. Son rendu (via des outils PlantUML ou des serveurs en ligne) produit un diagramme propre et professionnel prêt pour des revues de spécifications, la génération de code ou l’enseignement des concepts UML.

Des extensions futures pourraient inclure :

  • Intégration de l’API météo (sauter le capteur si pluie prévue).
  • Plusieurs zones avec des seuils d’humidité par zone.
  • Notifications sur application mobile en cas de délai d’expiration ou d’erreur.

Cette étude de cas démontre comment un problème d’automatisation apparemment simple bénéficie grandement de la modélisation structurée basée sur les états.