Dans les systèmes embarqués, la robotique et les plateformes autonomes, la logique de contrôle doit satisfaire un ensemble d'exigences strictes : déterminisme, prévisibilité, testabilité, comportement temps réel et maintenabilité à grande échelle.
Les Machines à États Finis (FSM) classiques sont utilisées depuis longtemps pour modéliser cette logique. Mais lorsque les systèmes gagnent en complexité, le modèle FSM classique s'effondre — et cet effondrement est brutal. Cet article explique ce qu'est UMTSM, pourquoi il était nécessaire et comment il redéfinit le rôle des machines à états dans les systèmes réactifs modernes.
Le problème des FSM classiques
Il existe un malentendu courant qu'il vaut la peine d'aborder directement :
« Les machines à états modélisent le comportement. »
C'est vrai — mais seulement en partie. Et cette couverture partielle crée de véritables problèmes à grande échelle.
La pensée centrée sur les états mène à l'explosion d'états
La plupart des FSM sont conçus en commençant par les états — Inactif, En cours, Erreur, Récupération — puis en ajoutant du comportement à l'intérieur. Avec le temps, les états deviennent surchargés, les transitions s'emmêlent et la logique se répand de façon incontrôlée :
- Complexité cyclomatique élevée
- Tests et vérification difficiles
- Systèmes fragiles et peu fiables
Pas de conscience structurée des données
Les FSM traditionnels fonctionnent selon la logique événement → transition. Mais les systèmes réels dépendent fortement des conditions sur les données :
if temperature > 30 AND battery < 20 → act
Sans intégration structurée des données, les FSM cachent la logique dans les gestionnaires d'états, s'appuient sur des conditions implicites et deviennent de plus en plus opaques avec le temps.
Sémantique d'exécution indéfinie
C'est peut-être le problème le plus dangereux : dans de nombreuses implémentations FSM, des questions telles que « quand les gardes sont-elles évaluées ? », « que se passe-t-il si plusieurs transitions correspondent ? » ou « quel est l'ordre d'exécution ? » ont des réponses implicites — ou aucune réponse du tout. Cela conduit à du non-déterminisme, des comportements incohérents et des systèmes vraiment difficiles à déboguer.
Qu'est-ce que UMTSM ?
UMTSM (Unified Modeling Technologies State Machine) est défini comme :
Une plateforme de machine à états étendue, déterministe, événementielle et hiérarchique avec une sémantique d'exécution explicite et des capacités de génération de code.
Ce n'est pas seulement un framework de machine à états. Il étend les FSM classiques avec la modélisation hiérarchique (Statecharts UML), des gardes sensibles aux données, un modèle d'exécution explicite et formel, un système de types fort, une résolution de transitions déterministe et une génération de code de qualité production.
L'évolution du FSM classique vers UMTSM :
Principes de conception fondamentaux
1. Événementiel, pas basé sur l'interrogation de données
UMTSM suit strictement :
Événement → Évaluation → Transition
Plutôt que d'interroger l'état dans une boucle, les données sont traitées en dehors de la machine à états. Les générateurs d'événements — qui peuvent eux-mêmes être des machines à états — produisent des événements significatifs et sémantiquement riches :
temperature_crossed_threshold
battery_low
gps_lost
Ce découplage entraîne une utilisation CPU plus faible, une meilleure séparation des préoccupations et une architecture système plus claire.
2. Modèle d'exécution déterministe
UMTSM définit un cycle d'exécution formel en six étapes :
- Acquérir les événements
- Évaluer les gardes dans l'état actuel le plus interne, de haut en bas
- Évaluer les gardes dans les états parents, de l'interne vers l'externe
- Sélectionner la première transition dont la garde est absente ou vraie
- Déclencher exactement une transition
- Mettre à jour l'état
La garantie fondamentale : avec les mêmes entrées et la même synchronisation, le système produit toujours les mêmes sorties.
3. Modélisation hiérarchique et concurrente
UMTSM prend entièrement en charge la sémantique des Statecharts UML :
- États imbriqués et composites
- Régions orthogonales (exécution parallèle réelle)
- Synchronisation Fork/Join
- Historique profond et superficiel
- Points d'entrée/sortie
- États finaux et de terminaison
Cela permet de modéliser des workflows complexes, des sous-systèmes concurrents et une logique de contrôle multicouche qui nécessiterait sinon des dizaines d'états plats.
4. Prise de décision basée sur les gardes
Les transitions dans UMTSM suivent une syntaxe complète et expressive :
event_a, event_b [temperature > 30 && is_daytime] -> monitoring / open_windows(), start_ventilation();
Les gardes sont des expressions pures, opèrent sur des données partagées et sont évaluées de façon déterministe. Pas d'effets de bord cachés, pas d'ordonnancement implicite.
5. Exécution contrôlée avec do et complete
UMTSM introduit un modèle puissant pour les états auto-évaluants :
state check_temperature
{
do / evaluate_temperature;
[is_high] --> check_temperature / start_cooling();
[is_low] --> check_temperature / start_heating();
}
L'action do s'exécute, émet un événement complete implicite, les gardes sont évaluées et l'état peut se réentrer. Cela crée une boucle d'exécution contrôlée sans interrogation incontrôlée — une distinction critique pour les systèmes temps réel.
Vue d'ensemble de l'architecture
Un système typique basé sur UMTSM suit une architecture en couches claire :
La séparation est explicite :
| Préoccupation | Emplacement |
|---|---|
| Traitement des données | Générateurs d'événements |
| Logique de contrôle | Machine à états |
| Modèle d'exécution | Moteur UMTSM |
| Effets | Actions / sorties |
Système de types fort et génération de code
UMTSM s'intègre étroitement avec C/C++, supportant les types primitifs intégrés, les structs, unions, enums, les types externes, les espaces de noms et les données globales/partagées. Cela permet :
- Une génération de code transparente et typée
- Une intégration directe avec les bases de code existantes
- Pas d'effacement de types à l'exécution ni de conversions cachées
Déterminisme et résolution de conflits
UMTSM applique une règle stricte :
Au plus une transition peut se déclencher par cycle d'évaluation.
Les stratégies de résolution de conflits sont explicites et configurables :
- Strict — erreur à la compilation si une ambiguïté existe
- Basé sur la priorité — priorité numérique explicite par transition
- Première correspondance — évaluation ordonnée, la première garde passante gagne
Cela élimine la classe de bugs provenant des implémentations FSM non déterministes.
Comparaison avec d'autres approches
| Fonctionnalité | FSM classique | Statecharts UML | UMTSM |
|---|---|---|---|
| Hiérarchie | ✗ | ✓ | ✓ |
| Gardes sensibles aux données | ✗ | ✓ | ✓ |
| Sémantique d'exécution formelle | ✗ | Partielle | ✓ |
| Garantie de déterminisme | ✗ | Partielle | ✓ |
| Politique de résolution de conflits | Implicite | Indéfinie | Explicite |
| Génération de code production | Limitée | Limitée | ✓ |
| Aptitude temps réel | ✓ | Partielle | ✓ |
| Modèle événementiel | ✓ | ✓ | ✓ |
L'intuition fondamentale
UMTSM opère un changement architectural fondamental, facile à énoncer mais difficile à intérioriser :
Les machines à états ne sont pas responsables du suivi de toutes les données.
Au lieu de cela, les changements de données génèrent des événements, et les événements pilotent la machine à états. Cela empêche le mode de défaillance le plus courant dans les systèmes basés sur FSM : surcharger la machine à états avec une conscience des données pour laquelle elle n'a jamais été conçue, créant des dépendances implicites et un couplage caché pratiquement impossible à tester.
Orientations futures
UMTSM évolue vers une plateforme réactive unifiée. Fonctionnalités prévues :
- Moteur d'expressions — remplacement des gardes basées sur des fonctions par des expressions inline
- Événements paramétrés — événements transportant des charges utiles typées directement dans les expressions de garde
- Modélisation de flux de données — intégration de pipelines de données réactifs avec la génération d'événements
- Analyse à la compilation — vérification statique de l'accessibilité, de l'absence de blocage et de la couverture des gardes
- Intégration de pipelines réactifs — connexion de UMTSM avec des architectures basées sur les flux
Conclusion
UMTSM ne remplace pas les machines à états. Il redéfinit leur rôle — de simples diagrammes comportementaux statiques à des systèmes d'exécution déterministes qui relient modélisation, implémentation et déploiement temps réel.
Le principe directeur est simple :
Votre machine à états ne devrait pas essayer de comprendre le monde entier. Elle devrait réagir à des événements significatifs — de façon déterministe.
UMTSM est construit exactement pour cela.
