SysML & modélisation

Machines à états en SysML : modéliser les modes de fonctionnement d'un système

SysML & modélisation · Par la rédaction de Vue Système · Publié le 2026-10-31

Un système ne fait pas toujours la même chose. Un avion est au sol, en roulage, en vol ou en maintenance ; un train est en traction, sur l'erre ou en freinage d'urgence ; une pompe est arrêtée, en marche ou en défaut. La machine à états est l'outil de SysML pour décrire ces modes, ce qui fait passer de l'un à l'autre, et ce que le système fait dans chacun. C'est aussi l'un des diagrammes les plus utiles pour dialoguer avec les équipes logicielles et de sûreté de fonctionnement.

À quoi sert une machine à états

Le diagramme de machine à états (abrégé stm) décrit le comportement d'un élément en réaction à des événements. Il répond à trois questions : dans quels états l'élément peut-il se trouver, quels événements le font changer d'état, et quelles actions s'exécutent à ces occasions. Dans la taxonomie des neuf diagrammes de SysML v1, c'est un diagramme de comportement repris d'UML sans modification majeure : la spécification SysML renvoie pour l'essentiel à la sémantique des machines à états d'UML.

Il se distingue du diagramme d'activité, qui décrit un enchaînement d'actions et des flux d'objets, et du diagramme de séquence, qui montre un scénario d'échanges entre éléments. La machine à états, elle, décrit une logique de réaction : elle couvre tous les cas, y compris ceux qu'aucun scénario n'a prévus. C'est précisément ce qui la rend précieuse pour l'analyse des modes dégradés.

En pratique, une machine à états est le plus souvent rattachée à un bloc, dont elle constitue le comportement propre : le bloc « Feu piétons » possède une machine à états qui décrit son cycle. Les événements qui la déclenchent arrivent souvent par les ports du bloc, décrits dans le diagramme de blocs internes ; nous avons détaillé ces notions dans notre article sur les blocs, les ports et les flux.

Les éléments de base

À l'intérieur d'un état, trois comportements peuvent être attachés : entry, exécuté à l'entrée, exit, exécuté à la sortie, et do, une activité qui se déroule tant que l'état est actif et qui est interrompue si une transition en sort. Placer une action en entrée d'état plutôt que sur chacune des transitions qui y mènent évite les oublis et les doublons.

Quatre sortes d'événements

• Événement de signal : la réception d'un message asynchrone, par exemple l'appui sur le bouton d'appel du piéton.
• Événement d'appel : l'invocation d'une opération du bloc.
• Événement temporel : after une durée écoulée depuis l'entrée dans l'état, ou at un instant donné.
• Événement de changement : when une condition devient vraie, comme une température qui dépasse un seuil.

Un exemple : le feu pour piétons à appel

Prenons un feu piétons placé sur une avenue. Au repos, il est rouge pour les piétons. Un appui sur le bouton fait passer la machine dans un état d'attente ; au bout d'un délai, le feu passe au vert piéton, puis revient au rouge. Pendant le vert, un nouvel appui ne doit rien changer. Une panne de lampe détectée doit faire basculer l'ensemble dans un mode de sécurité, quel que soit l'état courant.

Le modèle se construit en deux niveaux. Un état composite Fonctionnement normal contient les sous-états Rouge, Attente et Vert, avec les transitions AppelPiéton de Rouge vers Attente, after(délai) d'Attente vers Vert, et after(durée du vert) de Vert vers Rouge. Une seule transition DéfautLampe part du contour de l'état composite vers l'état Mode sécurité : elle s'applique à tous les sous-états à la fois. C'est l'intérêt de la hiérarchie : une transition au lieu de trois, et aucun cas oublié.

Pour revenir de maintenance, un pseudo-état d'historique dans l'état composite permettrait de reprendre au dernier sous-état actif. Ici, on préférera repartir de l'état initial, au rouge : c'est le choix sûr, et le modèle rend ce choix explicite.

États composites et régions parallèles

Un état composite peut contenir plusieurs régions orthogonales, actives en même temps. Le feu pourrait ainsi comporter une région pour la signalisation lumineuse et une autre pour le signal sonore destiné aux personnes malvoyantes. Les régions évitent l'explosion combinatoire : deux régions de trois états valent mieux qu'une machine à neuf états qui croise toutes les combinaisons. En contrepartie, il faut documenter soigneusement les interactions entre régions, qui sont une source classique d'ambiguïtés.

Le même exemple en SysML v2

SysML v2 conserve les concepts des machines à états, mais les exprime avec les définitions et les usages propres au nouveau langage. Une state def définit un type de comportement à états, un state en est un usage, et les transitions se déclarent par accept (le déclencheur), if (la garde), do (l'effet) et then (l'état cible). Voici une version très simplifiée du cycle normal, en notation textuelle :

state def CycleFeuPieton {
    entry; then rouge;

    state rouge;
    accept AppelPieton
        then attente;

    state attente;
    accept FinTemporisation
        then vert;

    state vert;
    accept FinVert
        then rouge;
}

Dans cette forme abrégée, chaque accept s'applique à l'état qui le précède. Un bloc, devenu définition de partie, indique qu'il présente ce comportement avec exhibit state. La notation textuelle se prête bien à la relecture et à la gestion de versions ; nous en avons présenté les principes dans notre article sur ce que change SysML v2.

Les erreurs les plus fréquentes

1. Confondre état et action. « Ouvrir la vanne » est une action ; « Vanne ouverte » est un état. Un état se nomme par un adjectif ou un participe, une situation qui dure.
2. Oublier des événements. Pour chaque état, se demander ce qui se passe si chacun des événements possibles survient. Une machine qui ignore silencieusement un défaut en cours de démarrage est un risque de sûreté.
3. Écrire des gardes qui se recouvrent. Deux transitions sortant du même état sur le même événement, avec des gardes vraies en même temps, rendent le comportement indéterminé.
4. Tout mettre à plat. Sans états composites, les transitions de défaut se multiplient et finissent par se contredire.
5. Modéliser le logiciel au lieu du système. Au niveau système, la machine décrit des modes observables (au sol, en vol, dégradé), pas les variables internes d'un programme.

À lire ensuite

Plus dans SysML & modélisation

SysML & modélisation

Les neuf diagrammes de SysML

Exigences, blocs, activités, états, séquences… à quoi sert chaque diagramme, et par lesquels commencer.

SysML & modélisation

Blocs, ports et flux

Blocs et parties, bdd et ibd, ports, interfaces et flux : la grammaire de la structure, avec un exemple pas à pas.

SysML & modélisation

SysML v2 : ce qui change

KerML, notation textuelle, API, définitions et usages : la rupture avec SysML v1, et comment s'y préparer.