Dans le domaine de l'automatisation industrielle, les State Machines (machines à états) sont souvent utilisées pour modéliser le comportement des systèmes hardware.
Définition
Les State machines se composent :
- d'états : ils indiquent que le système est en train d’effectuer une action ou d’attendre quelque chose. On retrouve par exemple l’état « Idle » (inactif) lorsque le système attend qu’un bouton soit enfoncé, ou l’état « Moving » (en mouvement) lorsque le système est en mouvement.
- de transitions : elles représentent tous les changements d’état possibles, comme une transition de l’état « Idle » à l’état « Moving ».
- d'événements : ils représentent un élément pouvant se produire pour déclencher une transition. Par exemple, un évènement “eMove” est généré lorsque le bouton “Move” est pressé sur le système, ce qui active la transition de l’état “Idle” vers l’état “Moving”. Un évènement peut également être déclenché par un minuteur.
- de conditions : elles empêchent le passage d’un état à un autre si les conditions ne sont pas remplies, même si l’évènement est déclenché. Elles vérifient par exemple l’état d'un autre dispositif représenté par une autre State machine.
- d'actions : ce sont des opérations à effectuer soit lors de l’exécution, soit à l’entrée d’un état, soit à la sortie d’un état.
Les State machines sont utiles pour modéliser des comportements complexes et les représenter visuellement.

En UML (Unified Modeling Language), les diagrammes de classes sont souvent utilisés par les développeurs pour modéliser la structure du code et les relations entre les classes. Les diagrammes d’états peuvent être utilisés pour représenter le comportement dynamique. Ils reposent sur le concept mathématique des State machines, avec quelques adaptations issues des diagrammes d’états de Harel.
Implémentation des States machines
Les State machines peuvent être facilement implémentées dans n’importe quel langage de programmation à l’aide d’une simple instruction switch/case, en utilisant l’état actuel comme critère de sélection. Cependant, cette implementation présente plusieurs inconvénients :
- Cela nécessite de tenir à jour séparément un schéma de la State machine.
- Il existe souvent des doutes à propos de la bonne mise à jour du schéma par rapport à la dernière version du code.
- Certains développeurs ne dessinent pas la State machine : ils commencent avec un modèle simple à 3 états, mais au bout de 6 mois, la complexité a augmenté et il n’y a plus aucune documentation !
- Il n’existe aucun contrôle syntaxique permettant de vérifier que le schéma représente correctement la machine implémentée.
- Pour des State machines complexes, le switch/case peut être source d’erreurs (oubli d’un break, confusion entre les états, etc.).
Visual State Machines (Machines à états visuels)
Chez Agileo Automation, nous pensons, pour reprendre les mots d’Aristote, que :
L'âme ne pense jamais sans image
En conséquence, nous avons intégré les State Machines dans Visual Studio afin de permettre :
- À un développeur de dessiner les états et transitions d’un équipement ou d’un système plus complexe.
- De partager cette State machine sous forme d’image avec ses collègues et partenaires afin de remettre en question sa conception et, par conséquent, de l’améliorer.
- D’obtenir un schéma directement exécutable, sans écrire de code. Cela s’inscrit dans une approche low-code : What You See Is What You Get (WYSIWYG).
Ce processus est itératif et s’inscrit dans une démarche agile.
A²ECF-Industry et A²ECF-SEMI intègrent :
- Un éditeur visuel de State machines directement dans Visual Studio pour concevoir la machine et la relier au code C# (déclenchement d’évènements, appel d’actions).
- Un moteur de State machines pour exécuter le modèle : changement d’états lors d’évènements, vérification des conditions et exécution des actions dans le code C#.
Découvrez comment cela fonctionne et comment cela peut accélérer le développement de vos contrôleurs d'équipement et améliorer tant leur qualité que leur documentation :