Un système, ses états, ses événements
Ce que ce chapitre apporte5 points
- Décrire un système par ses états, ses événements et ses transitions.
- Lire un diagramme d'automate : la flèche d'entrée, les cercles, les arcs étiquetés, le double cercle.
- Faire tourner un automate sur une séquence d'événements et repérer l'endroit exact où la lecture se bloque.
- Repérer une séquence dangereuse qu'un modèle autorise, puis corriger le modèle.
- Expliquer ce qu'un état résume du passé, et ce qu'il oublie forcément.
Un séquenceur de chaîne, un grafcet, une machine à états écrite sur un microcontrôleur : l'objet de ce module est déjà familier à qui a câblé un automate de contrôle. Ce chapitre lui donne son nom, son vocabulaire et son dessin, en partant d'un système réel plutôt que d'une théorie. Il montre surtout ce qu'un état représente vraiment : le résumé de tout ce qu'un système a besoin de retenir de son passé, et rien de plus. C'est ce résumé qui rend le modèle utilisable, et c'est aussi ce qui fixe sa limite.
Une machine à états, déjà rencontrée
Un portique d'accès a deux situations possibles, et deux seulement : verrouillé, ou déverrouillé le temps d'un passage. Deux événements le font changer de situation : un badge validé par le lecteur, et le passage d'une personne détecté par la cellule. Rien d'autre ne compte, ni l'heure, ni le nom du porteur du badge, ni le nombre de passages de la journée.
Ce système se dessine avec deux cercles et deux flèches. La petite flèche qui vient de nulle part désigne la situation de départ, celle du portique à la mise sous tension.
badgepassage
État actif : fermé.
Sur la séquence proposée, le cercle allumé passe de fermé à ouvert, puis revient à fermé. Sur badge badge passage, la figure s'arrête après le second badge et annonce qu'aucune transition ne porte cet événement : depuis ouvert, aucune flèche ne porte l'étiquette badge.
Ce blocage n'est pas un incident de la figure, c'est une information sur le modèle. Deux lectures en sont possibles, et il faut choisir : soit un second badge sur un portique déjà déverrouillé est impossible, soit il est possible et ne produit rien. La seconde lecture est la bonne pour un portique réel, et elle se dessine par une flèche qui revient sur son propre cercle.
badgebadgepassage
État actif : fermé.
Un état est une situation du système, décrite assez finement pour que la suite du comportement en dépende seulement, sans consulter le passé. Un événement est ce qui arrive au système depuis l'extérieur : un capteur qui bascule, un message reçu, une commande. Une transition relie un état de départ à un état d'arrivée et porte le nom de l'événement qui la déclenche.
Ce que cette définition écarte se voit tout de suite : un automate ne connaît ni durée ni grandeur mesurée, seulement des événements nommés. Une température qui franchit un seuil doit lui parvenir sous la forme d'un événement, jamais sous celle d'une valeur.
Le double cercle, lui, marque les situations où une séquence peut s'arrêter sans anomalie : le portique au repos, verrouillé. Une séquence qui se termine ailleurs laisse le système en cours de cycle. Le chapitre sur la reconnaissance d'une séquence fait de ce double cercle le cœur du sujet ; ici, il suffit de savoir qu'il désigne une fin de séquence légitime.
Ce dessin est un graphe orienté étiqueté au sens propre : les cercles en sont les sommets, les flèches les arcs, et le vocabulaire des graphes s'applique tel quel à un automate.
Deux conventions de dessin reviennent dans toutes les figures du module, et mieux vaut les nommer tout de suite. La première est la flèche d'entrée, déjà rencontrée : elle désigne l'état de départ. La seconde est une mention portée par l'en-tête de la figure, « incomplet : une lecture peut se bloquer ». Elle apparaît dès qu'un automate ne prévoit pas tous les événements dans tous les états. Les deux portiques ci-dessus la portent : depuis fermé, l'événement passage n'est prévu nulle part.
La même machine à états se retrouve dans le programme d'une carte, où elle remplace les attentes bloquantes. Le chapitre sur les machines à états d'une carte Arduino la met en œuvre : le programme y retient son état au lieu d'attendre.
Le portique se contentait de deux états parce qu'il n'avait rien à interdire. Un système où certaines séquences sont dangereuses en demande davantage, et c'est là que le modèle commence à rendre service : il montre ce que la spécification n'a pas dit.
Le sas de sécurité
Un sas à deux portes sépare une zone propre d'un atelier. Une seule règle de sécurité gouverne ce système, et elle est absolue : les deux portes ne doivent jamais être ouvertes en même temps. Le système reçoit cinq événements, tous produits par des capteurs ou par le lecteur de badge :
| Événement | Ce qui le produit |
|---|---|
badge | le lecteur valide un badge et déverrouille la porte A |
A-ouvre | le capteur de la porte A signale son ouverture |
A-ferme | le capteur de la porte A signale sa fermeture |
B-ouvre | le capteur de la porte B signale son ouverture |
B-ferme | le capteur de la porte B signale sa fermeture |
Les états, eux, portent le nom de la situation physique du sas, jamais une lettre : repos, A déverrouillée, A ouverte, sas fermé, B ouverte. Un état nommé q3 n'aurait rien appris, et surtout n'aurait rien permis de vérifier.
Un premier jet, et la séquence qu'il autorise
Voici le modèle tel qu'il sort d'une première réunion. Chaque événement a été branché là où le bouton existe physiquement : la porte B possède un bouton d'ouverture accessible depuis l'intérieur du sas, donc une transition B-ouvre part de l'état A ouverte.
badgeA-ouvreB-ouvre
État actif : repos.
Trois événements suffisent : un badge, l'ouverture de A, l'ouverture de B. L'état allumé à l'arrivée est deux ouvertes, et son nom dit exactement ce que la règle de sécurité interdit. Le modèle n'est pas ambigu, il est faux : il autorise une séquence dangereuse, et il l'autorise en trois coups.
Rien dans le texte de la spécification ne l'avait signalé. C'est le déroulé de la séquence sur le dessin qui l'a rendu visible, et c'est la raison pour laquelle un automate se vérifie en le faisant tourner, pas en le relisant.
Le modèle corrigé
La correction ne consiste pas à ajouter une alarme dans l'état deux ouvertes : elle consiste à supprimer l'état, donc les transitions qui y mènent. Un sas correctement conçu verrouille mécaniquement la porte B tant que la porte A n'est pas refermée. L'événement B-ouvre ne peut alors pas se produire depuis A ouverte, et le modèle doit dire cette impossibilité en ne prévoyant aucune transition.
badgeA-ouvreB-ouvre
État actif : repos.
La même séquence de trois événements ne va plus au bout. Après badge et A-ouvre, l'état actif est A ouverte ; l'événement B-ouvre n'y est prévu nulle part, la figure annonce qu'aucune transition ne porte cet événement et que la séquence s'arrête là. Le sas interdit cette séquence, et c'est ce que le dessin affirme désormais.
Le même modèle s'écrit aussi en tableau, les états en lignes et les événements en colonnes, chaque case portant l'état d'arrivée. La flèche désigne l'état initial et la coche le double cercle.
| État | badge | A-ouvre | A-ferme | B-ouvre | B-ferme |
|---|---|---|---|---|---|
→ repos ✓ | A déverrouillée | ||||
A déverrouillée | A ouverte | ||||
A ouverte | sas fermé | ||||
sas fermé | B ouverte | ||||
B ouverte | repos |
Le tableau apporte ce que le dessin cache : ses cases vides, vingt sur vingt-cinq, chacune étant un événement qu'aucune transition ne traite dans cet état. Sur un diagramme, une flèche absente ne se voit pas, alors qu'une case vide se compte, et c'est là que se lisent les impossibilités affirmées par le modèle.
La séquence nominale, elle, fait le tour complet.
badgeA-ouvreA-fermeB-ouvreB-ferme
État actif : repos.
Cinq événements, cinq transitions, et le sas revient au repos : la séquence se termine sur le double cercle. Le modèle décrit maintenant un cycle, et un seul.
Un automate ne connaît que ses transitions. Un événement sans transition dans l'état courant arrête la lecture : le modèle affirme qu'il ne peut pas se produire. C'est une affirmation forte, qui doit être vraie dans le système réel, garantie par un verrou mécanique ou par un enclenchement électrique. Quand elle ne l'est pas, il faut prévoir la transition, même pour dire que rien ne se passe, comme la boucle du portique plus haut.
Ce qu'un état résume
Le sas a été découpé en cinq états sans que rien n'ait dit d'où venait ce découpage. Une seule question le décide, et elle vaut pour tout système : que faut-il retenir du passé pour savoir comment le système réagira ?
Dans le sas, la réponse est courte : la position des deux portes et l'état du verrou. Ni le nombre de passages effectués depuis la mise en service, ni l'identité des porteurs de badge, ni l'heure. Deux histoires différentes qui laissent les portes dans la même position conduisent à la même suite de comportements, donc au même état.
badgeA-ouvreA-fermeB-ouvreB-fermebadgeA-ouvreA-ferme
État actif : repos.
Après huit événements, l'état actif est sas fermé. Après les trois événements badge A-ouvre A-ferme, il est sas fermé également. Le sas ne se souvient pas d'avoir déjà laissé passer quelqu'un : rien dans son comportement futur n'en dépend, donc rien ne le retient.
Un automate ne mémorise pas son passé, il le résume dans son état présent. Deux séquences d'événements qui mènent au même état sont indiscernables pour la suite : le système se comportera exactement pareil. Choisir les états d'un modèle, c'est décider ce qui mérite d'être retenu.
Ce résumé est ce qui rend le modèle utilisable : un système d'une complexité quelconque se ramène à une poignée de cercles, et l'on peut vérifier exhaustivement ce qu'il autorise. C'est aussi sa limite, parce que le nombre d'états est fixé une fois pour toutes.
Retenir un compte, c'est ajouter des états
Reste à savoir ce que coûte une information qui est un nombre. Le lecteur de badge du sas déclenche une alarme après trois refus consécutifs. Retenir « combien de refus consécutifs ont eu lieu » demande un état par valeur possible, et il n'y a pas d'autre moyen.
refusrefusvalidérefusrefusrefus
État actif : 0 refus.
Le déroulé se lit ligne à ligne, en partant de 0 refus :
| Événement lu | État atteint |
|---|---|
refus | 1 refus |
refus | 2 refus |
validé | 0 refus |
refus | 1 refus |
refus | 2 refus |
refus | alarme |
Le badge validé au troisième symbole ramène le compteur à 0 refus, et il faut de nouveau trois refus pour atteindre l'alarme. La séquence proposée y parvient au sixième événement.
Trois refus demandent trois états de comptage. Dix refus en demanderaient dix. Compter sans limite fixée d'avance, en revanche, est hors de portée : un automate possède un nombre fini d'états, décidé au moment du dessin. Cette limite n'est pas un détail de mise en œuvre, c'est la frontière du modèle, et le chapitre sur ce qu'un automate ne sait pas faire la démontre et l'exploite.
Quand les états se multiplient
Un compteur ajoute des états un par un. Des conditions indépendantes en ajoutent tout autrement : elles les multiplient.
Une cuve chauffée possède deux organes indépendants : une résistance de chauffage, et une vanne de vidange. Chacun est ouvert ou fermé. Le système a donc quatre situations, une par combinaison, et les états d'un automate décrivent toujours une combinaison de conditions, jamais une seule.
C+V+C-V-
État actif : repos.
La séquence allume tour à tour chauffe seule, chauffe et vanne, vanne seule, puis revient à repos. Ajouter un troisième organe indépendant, un agitateur par exemple, porterait le compte à huit états, et un quatrième à seize. Cette croissance est la vraie difficulté de la modélisation par états. Deux gestes la contiennent : ne retenir que les conditions dont le comportement dépend réellement, et découper un gros système en plusieurs automates plutôt qu'en un seul.
La figure signale ici encore un automate incomplet : depuis chauffe et vanne, l'événement C+ n'est prévu nulle part, car la résistance est déjà en marche. Prévoir une boucle qui ne change rien, ou laisser la lecture se bloquer, est un choix de modélisation à assumer explicitement.
Exercices type
G+D+D-G-
État actif : aucun.
Une presse ne descend que si les deux boutons, gauche et droit, sont enfoncés en même temps. Les quatre événements sont `G+`, `G-`, `D+`, `D-`. Quelle est la séquence la plus courte qui déclenche la descente, et que se passe-t-il si l'opérateur relâche un seul bouton pendant la descente ?
La descente demande deux événements, G+ puis D+, ou D+ puis G+ : ces deux séquences atteignent l'état descente, et c'est exactement l'intention d'une commande bimanuelle, qui interdit de bloquer un bouton avec une cale.
Relâcher un seul bouton produit G- ou D- depuis descente, et l'automate quitte cet état pour droit seul ou gauche seul. La presse remonte donc dès le premier bouton relâché, ce que le dessin garantit : aucune boucle sur descente ne permet d'y rester après un relâchement.
L'automate est incomplet, et volontairement : depuis descente, les événements G+ et D+ ne sont prévus nulle part, puisque les deux boutons y sont déjà enfoncés. Un bouton ne peut pas être enfoncé deux fois de suite sans avoir été relâché, et le modèle affirme cette impossibilité physique.
démarrerpurgerniveau-bas
État actif : vide.
Le modèle ci-dessus décrit une cuve de rinçage : elle se remplit, atteint son niveau haut, puis se purge. La transition `remplissage -> vidange : purger` a été ajoutée pour permettre un arrêt d'urgence. Quelle séquence devient possible, et pourquoi pose-t-elle un problème si la vanne de purge ne doit jamais s'ouvrir pendant que la pompe tourne ?
La séquence démarrer purger niveau-bas est autorisée par le modèle : la cuve passe de vide à remplissage, puis directement à vidange, et revient à vide. Elle ouvre la purge alors que rien n'a arrêté la pompe de remplissage, puisque aucun événement d'arrêt n'apparaît entre les deux.
Le défaut est le même que celui du sas : le modèle autorise une séquence que le système physique interdit. Deux corrections sont possibles, et elles ne décrivent pas le même équipement.
- Si l'arrêt d'urgence doit exister, il faut un événement qui arrête la pompe, et un état intermédiaire qui le retient :
remplissage -> arrêt pompe : arrêt, puisarrêt pompe -> vidange : purger. L'état supplémentaire est exactement ce qui empêche la séquence dangereuse. - Si la purge ne doit être possible que cuve pleine, il suffit de supprimer la transition ajoutée. L'événement
purgerbloque alors la lecture pendant le remplissage, et c'est la bonne façon de dire qu'il ne peut pas se produire.
démarrerarrêtpurgerniveau-bas
État actif : vide.
Dans le modèle du sas corrigé, combien de séquences différentes mènent à l'état `sas fermé` ? Que retient cet état de la séquence qui l'a produit ?
Les séquences qui mènent à sas fermé sont en nombre illimité : badge A-ouvre A-ferme, puis la même chose précédée d'un cycle complet, de deux cycles complets, et ainsi de suite. Chaque cycle badge A-ouvre A-ferme B-ouvre B-ferme ramène au repos et peut être répété autant de fois que voulu.
L'état sas fermé ne retient rien de tout cela. Il dit une seule chose : les deux portes sont fermées et une personne se trouve dans le sas. C'est la seule information dont dépend la suite, à savoir que le prochain événement utile est l'ouverture de la porte B. Le nombre de passages déjà effectués n'a aucune influence sur le comportement, donc aucun état ne le mémorise.
Un modèle qui devrait compter les passages, par exemple pour bloquer le sas après vingt cycles, aurait besoin de vingt fois plus d'états : un jeu d'états par valeur du compteur.
Vérification
1.Que représente la petite flèche qui arrive sur un cercle sans venir d'un autre cercle ?
2.Dans le modèle du sas corrigé, que fait la figure quand l'événement B-ouvre survient dans l'état A ouverte ?
3.Un modèle doit-il prévoir une transition pour un événement qui ne produit aucun effet ?
4.Deux séquences d'événements différentes mènent au même état. Que peut-on en conclure ?
5.Combien d'états faut-il pour déclencher une alarme au troisième refus consécutif de badge ?
6.Une machine possède trois organes indépendants, chacun en marche ou à l'arrêt. Combien d'états son automate compte-t-il au maximum ?
La méthode
- Lister les événements avant les états : ce sont les entrées du système, capteurs, messages, commandes, et leur liste est courte et vérifiable.
- Chercher ce qui doit être retenu du passé pour savoir comment le système réagira, et rien d'autre : c'est la question qui donne les états.
- Nommer chaque état par la situation physique qu'il décrit, jamais par une lettre : un nom faux se repère à la lecture, un
q3non. - Tracer les transitions événement par événement, en se demandant pour chaque état si l'événement peut s'y produire, et ce qu'il change.
- Dérouler les séquences dangereuses sur le dessin, celles que la spécification interdit, et vérifier qu'elles bloquent ou qu'elles n'atteignent pas l'état redouté.
- Décider, pour chaque événement absent d'un état, s'il est réellement impossible ou simplement sans effet : dans le second cas, ajouter la boucle qui le dit.
Synthèse
- Un état est une situation du système, un événement ce qui lui arrive, une transition le lien entre les deux, étiqueté par l'événement.
- La flèche d'entrée désigne l'état initial, le double cercle une fin de séquence légitime, et une boucle un événement qui survient sans rien changer.
- Un événement sans transition dans l'état courant bloque la lecture : le modèle affirme qu'il est impossible, ce qui doit être vrai dans le système réel.
- Une séquence dangereuse se découvre en faisant tourner le modèle, pas en le relisant : le sas autorisait l'ouverture simultanée des deux portes en trois événements. La corriger a consisté à supprimer l'état redouté et les transitions qui y menaient, pas à y ajouter une alarme.
- Un état résume le passé : deux séquences qui mènent au même état sont indiscernables pour la suite du comportement.
- Retenir un compte demande un état par valeur, et des conditions indépendantes multiplient le nombre d'états ; le nombre d'états étant fixé, ce que le modèle peut retenir l'est aussi.
La suite du module garde ce dessin et change la question posée. Reconnaître une séquence ne demande plus de commander un système, mais de rendre un verdict sur une suite d'événements lue jusqu'au bout.
Mettre en pratique
Faire tourner un automate à la main, repérer où la lecture se bloque, et compter ce qu'un état retient.
Tous les exercices sur états et événements