![\"Hand-drawn](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2026\/04\/state-machine-diagram-embedded-systems-infographic.jpg\"\/)
<\/figure>\n<\/div>\n\ud83e\udde0 Qu’est-ce qu’un diagramme d’\u00e9tat ?<\/h2>\n
Un diagramme d’\u00e9tat, souvent appel\u00e9 Statechart ou diagramme d’activit\u00e9 ax\u00e9 sur les \u00e9tats, repr\u00e9sente le comportement dynamique d’un syst\u00e8me. Contrairement \u00e0 un organigramme, qui repr\u00e9sente une s\u00e9quence lin\u00e9aire d’\u00e9tapes, une machine \u00e0 \u00e9tats mod\u00e9lise les conditions<\/strong> dans lesquelles un syst\u00e8me existe \u00e0 tout instant donn\u00e9. Il r\u00e9pond \u00e0 la question : \u00ab \u00c0 quoi ressemble le syst\u00e8me en ce moment, et qu’est-ce qui fait changer cet aspect ? \u00bb<\/p>\n Dans le contexte des syst\u00e8mes embarqu\u00e9s, cela est souvent \u00e9quivalent \u00e0 une machine \u00e0 \u00e9tats finis (FSM). La partie \u00ab fini \u00bb est cruciale. Cela signifie que le syst\u00e8me ne peut \u00eatre dans qu’un seul \u00e9tat sp\u00e9cifique \u00e0 tout moment donn\u00e9. Il ne peut pas \u00eatre \u00e0 la fois \u00ab en cours d’ex\u00e9cution \u00bb et \u00ab arr\u00eat\u00e9 \u00bb simultan\u00e9ment. Cette s\u00e9paration nette simplifie le d\u00e9bogage et les tests.<\/p>\n Pour construire un diagramme, vous devez ma\u00eetriser le vocabulaire. Chaque diagramme valide est construit \u00e0 partir d’un ensemble sp\u00e9cifique de blocs de construction. Ces \u00e9l\u00e9ments d\u00e9finissent la structure et la logique du syst\u00e8me.<\/p>\n Un \u00e9tat repr\u00e9sente une condition au cours de la vie d’un objet ou d’un syst\u00e8me. C’est une p\u00e9riode pendant laquelle le syst\u00e8me attend un \u00e9v\u00e9nement. Visuellement, les \u00e9tats sont g\u00e9n\u00e9ralement repr\u00e9sent\u00e9s par des rectangles arrondis.<\/p>\n Une transition est le passage d’un \u00e9tat \u00e0 un autre. Elle repr\u00e9sente le changement d’\u00e9tat du syst\u00e8me. Les transitions sont dessin\u00e9es sous forme de fl\u00e8ches reliant deux \u00e9tats.<\/p>\n Un \u00e9v\u00e9nement est une occurrence importante qui d\u00e9clenche une transition. Dans les syst\u00e8mes embarqu\u00e9s, les \u00e9v\u00e9nements sont souvent :<\/p>\n Les actions sont le travail effectu\u00e9 par le syst\u00e8me. Elles sont associ\u00e9es aux \u00e9tats ou aux transitions. Il existe trois types principaux d’actions :<\/p>\n Une condition de garde est une expression bool\u00e9enne qui d\u00e9termine si une transition peut avoir lieu. Elle agit comme un gardien. M\u00eame si un \u00e9v\u00e9nement se produit, l’\u00e9tat ne changera pas \u00e0 moins que la condition de garde ne soit \u00e9valu\u00e9e \u00e0 vrai.<\/p>\n Pour clarifier les diff\u00e9rences entre ces composants, reportez-vous au tableau ci-dessous.<\/p>\n Cr\u00e9er un diagramme \u00e0 partir de z\u00e9ro peut sembler accablant. Suivez ce processus structur\u00e9 pour garantir une coh\u00e9rence logique et une compl\u00e9tude.<\/p>\n D\u00e9finissez ce que la machine \u00e0 \u00e9tats contr\u00f4le. S’agit-il de l’appareil entier, ou seulement d’un module sp\u00e9cifique ? Garder la port\u00e9e g\u00e9rable est essentiel. Par exemple, ne cherchez pas \u00e0 mod\u00e9liser l’ensemble du syst\u00e8me \u00e9lectronique de la voiture dans un seul diagramme. Concentrez-vous sp\u00e9cifiquement sur l'”Unit\u00e9 de contr\u00f4le du moteur” ou le “Module de gestion de l’alimentation”.<\/p>\n Faites une s\u00e9ance de cerveau de groupe sur chaque condition possible du syst\u00e8me. Demandez-vous : “Quels sont les modes de fonctionnement distincts ?”<\/p>\n Assurez-vous que ces \u00e9tats sont mutuellement exclusifs. Le syst\u00e8me ne doit pas \u00eatre dans deux \u00e9tats en m\u00eame temps.<\/p>\n Qu’est-ce qui fait passer le syst\u00e8me d’un \u00e9tat \u00e0 un autre, comme vous les avez list\u00e9s \u00e0 l’\u00e9tape 2 ? Regardez les entr\u00e9es.<\/p>\n Connectez les \u00e9tats \u00e0 l’aide de fl\u00e8ches. \u00c9tiquetez chaque fl\u00e8che avec l’\u00e9v\u00e9nement qui la d\u00e9clenche. Si une transition n\u00e9cessite une condition, ajoutez la condition de garde entre parenth\u00e8ses.<\/p>\n Pr\u00e9cisez ce qui se produit \u00e0 l’int\u00e9rieur de chaque \u00e9tat. Si l’entr\u00e9e dans l’\u00e9tat \u00ab Actif \u00bb n\u00e9cessite l’initialisation d’une variable, indiquez cela comme une action d’entr\u00e9e. Si la sortie de l’\u00e9tat \u00ab Actif \u00bb n\u00e9cessite la sauvegarde de donn\u00e9es, indiquez cela comme une action de sortie.<\/p>\n Appliquons ces concepts \u00e0 un sc\u00e9nario classique embarqu\u00e9 : un thermostat num\u00e9rique. Cet exemple montre comment g\u00e9rer la logique de contr\u00f4le de temp\u00e9rature de mani\u00e8re claire.<\/p>\n Le thermostat dispose de deux modes principaux : Chauffage et Refroidissement. Il commence dans un \u00e9tat \u00ab \u00c9teint \u00bb. Lorsqu’un bouton est press\u00e9, il passe en mode \u00ab Configuration \u00bb. Si la temp\u00e9rature descend en dessous d’un point fixe, il active le \u00ab Chauffage \u00bb. Si la temp\u00e9rature monte au-dessus d’un point fixe, il active le \u00ab Refroidissement \u00bb.<\/p>\n Voici comment les \u00e9tats et les transitions se d\u00e9composent pour ce syst\u00e8me.<\/p>\n Cette structure garantit que le chauffage ne s’allume jamais sauf si le syst\u00e8me est explicitement dans l’\u00e9tat “Chauffage”. Elle emp\u00eache \u00e9galement les actions conflictuelles, telles que l’allumage du chauffage et du ventilateur en m\u00eame temps de mani\u00e8re \u00e0 provoquer un court-circuit.<\/p>\n M\u00eame les ing\u00e9nieurs exp\u00e9riment\u00e9s peuvent introduire une complexit\u00e9 qui rend les machines \u00e0 \u00e9tats difficiles \u00e0 maintenir. Soyez attentif \u00e0 ces probl\u00e8mes courants.<\/p>\n \u00c9vitez de cr\u00e9er un diagramme o\u00f9 chaque \u00e9tat est connect\u00e9 \u00e0 tous les autres. Si vous voyez un r\u00e9seau de fl\u00e8ches crois\u00e9es, la logique est probablement trop complexe. Utilisez des \u00e9tats compos\u00e9s pour regrouper des comportements li\u00e9s. Par exemple, au lieu d’avoir “Erreur_1”, “Erreur_2” et “Erreur_3” comme \u00e9tats de niveau sup\u00e9rieur s\u00e9par\u00e9s, regroupez-les sous un \u00e9tat parent “Erreur” avec des sous-\u00e9tats.<\/p>\n Que se passe-t-il si un \u00e9v\u00e9nement se produit dans un \u00e9tat o\u00f9 il n’est pas d\u00e9fini ? Dans les syst\u00e8mes embarqu\u00e9s, cela entra\u00eene souvent un plantage ou un comportement ind\u00e9fini. D\u00e9finissez toujours une transition \u00ab tout attraper \u00bb ou assurez-vous que le syst\u00e8me g\u00e8re les \u00e9v\u00e9nements impr\u00e9vus de mani\u00e8re \u00e9l\u00e9gante, par exemple en passant \u00e0 un \u00e9tat d’erreur par d\u00e9faut.<\/p>\n Assurez-vous que les transitions se produisent comme une unit\u00e9 logique unique. Si une transition implique le changement de plusieurs variables, elles doivent toutes \u00eatre mises \u00e0 jour avant que le syst\u00e8me n’entre dans l’\u00e9tat suivant. Ne permettez pas au syst\u00e8me de rester dans un \u00e9tat partiellement mis \u00e0 jour.<\/p>\n Bien que les actions “Do” soient utiles pour un suivi continu, leur surutilisation peut faire para\u00eetre la machine \u00e0 \u00e9tats comme une boucle continue plut\u00f4t qu’un mod\u00e8le bas\u00e9 sur des \u00e9tats. R\u00e9servez les actions “Do” aux t\u00e2ches qui doivent s’ex\u00e9cuter de mani\u00e8re r\u00e9p\u00e9t\u00e9e pendant que le syst\u00e8me attend un \u00e9v\u00e9nement, telles que le sondage des capteurs.<\/p>\n L’une des questions les plus fr\u00e9quentes en conception embarqu\u00e9e est o\u00f9 placer la logique : dans la condition de garde ou dans l’action elle-m\u00eame.<\/p>\n Consid\u00e9rez un sc\u00e9nario o\u00f9 une transition a lieu uniquement si le niveau de la batterie est suffisant. La condition doit v\u00e9rifier Une fois le diagramme termin\u00e9, comment savez-vous qu’il fonctionne ? La conception bas\u00e9e sur le mod\u00e8le vous permet de tester le diagramme avant d’\u00e9crire une seule ligne de code C ou C++.<\/p>\n Suivez tous les chemins possibles \u00e0 travers le diagramme. Pouvez-vous atteindre chaque \u00e9tat ? Pouvez-vous atteindre chaque transition ? Assurez-vous qu’il n’y ait pas de culs-de-sac o\u00f9 le syst\u00e8me se bloque.<\/p>\n Simulez une s\u00e9quence d’\u00e9v\u00e9nements. Par exemple, appuyez sur le bouton, attendez 5 secondes, appuyez \u00e0 nouveau sur le bouton. L’\u00e9tat change-t-il comme pr\u00e9vu ? Cela aide \u00e0 v\u00e9rifier que le timing et l’ordre des \u00e9v\u00e9nements sont corrects.<\/p>\n Testez les limites. Que se passe-t-il si la temp\u00e9rature est exactement au seuil ? Que se passe-t-il si deux \u00e9v\u00e9nements se produisent simultan\u00e9ment ? Assurez-vous que la machine \u00e0 \u00e9tats g\u00e8re ces cas limites sans plantage.<\/p>\n Les d\u00e9butants confondent souvent les diagrammes de machines \u00e0 \u00e9tats avec les sch\u00e9mas de flux. Bien qu’ils utilisent des formes et des fl\u00e8ches, ils ont des objectifs diff\u00e9rents.<\/p>\n Pour les syst\u00e8mes embarqu\u00e9s, la machine \u00e0 \u00e9tats est sup\u00e9rieure pour la logique de contr\u00f4le car elle g\u00e8re explicitement les p\u00e9riodes d’attente et les r\u00e9ponses aux \u00e9v\u00e9nements qui d\u00e9finissent les syst\u00e8mes temps r\u00e9el.<\/p>\n Pour maintenir la qualit\u00e9 du code et la fiabilit\u00e9 du syst\u00e8me, respectez ces directives lors de l’impl\u00e9mentation de la logique d\u00e9riv\u00e9e de votre diagramme.<\/p>\n Concevoir du logiciel embarqu\u00e9 exige pr\u00e9cision et anticipation. Les diagrammes de machines \u00e0 \u00e9tats fournissent la base visuelle n\u00e9cessaire pour atteindre cette pr\u00e9cision. En d\u00e9composant un comportement complexe en \u00e9tats discrets et des transitions bien d\u00e9finies, vous cr\u00e9ez des syst\u00e8mes plus faciles \u00e0 comprendre, \u00e0 tester et \u00e0 maintenir.<\/p>\n Commencez petit. Mod\u00e9lisez d’abord une fonction simple. Au fur et \u00e0 mesure que vous vous familiariserez avec les composants \u2014 \u00e9tats, transitions, \u00e9v\u00e9nements et gardes \u2014 vous d\u00e9couvrirez que ces diagrammes deviennent des outils indispensables dans votre bo\u00eete \u00e0 outils d’ing\u00e9nieur. Ils transforment la logique abstraite en une carte concr\u00e8te, guidant votre code \u00e0 travers les complexit\u00e9s de l’interaction avec le mat\u00e9riel du monde r\u00e9el.<\/p>\n Souvenez-vous, l’objectif n’est pas seulement d’\u00e9crire du code qui fonctionne, mais de concevoir des syst\u00e8mes r\u00e9silients face \u00e0 la nature impr\u00e9visible du monde physique. Avec une base solide de machine \u00e0 \u00e9tats, vos projets embarqu\u00e9s seront plus solides.<\/p>\n","protected":false},"excerpt":{"rendered":" Les syst\u00e8mes embarqu\u00e9s fonctionnent dans un monde de contraintes strictes. Chaque cycle compte, et chaque octet de m\u00e9moire a son<\/p>\n","protected":false},"author":3479,"featured_media":11183,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_title":"Bases des diagrammes de machines \u00e0 \u00e9tats : Guide pour syst\u00e8mes embarqu\u00e9s","_yoast_wpseo_metadesc":"Apprenez les bases des diagrammes de machines \u00e0 \u00e9tats pour les syst\u00e8mes embarqu\u00e9s. Un guide pas \u00e0 pas en UML couvrant les \u00e9tats, les transitions, les \u00e9v\u00e9nements et les meilleures pratiques pour les d\u00e9butants.","fifu_image_url":"","fifu_image_alt":"","footnotes":""},"categories":[127],"tags":[163,101],"class_list":["post-11182","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-unified-modeling-language","tag-academic","tag-uml"],"yoast_head":"\n\ud83d\udd11 Composants fondamentaux d’une machine \u00e0 \u00e9tats<\/h2>\n
1. \u00c9tats<\/h3>\n
\n
2. Transitions<\/h3>\n
\n
3. \u00c9v\u00e9nements<\/h3>\n
\n
4. Actions<\/h3>\n
\n
5. Conditions de garde<\/h3>\n
\n
si (niveauBatterie > 20 %)<\/code><\/li>\nsi (temp\u00e9rature < 100)<\/code><\/li>\n<\/ul>\n\ud83d\udcca Tableau de comparaison des composants<\/h2>\n
\n\n
\n \nComposant<\/th>\n Symbole visuel<\/th>\n Fonction<\/th>\n Chronologie<\/th>\n<\/tr>\n<\/thead>\n \n \u00c9tat<\/td>\n Rectangle arrondi<\/td>\n Repr\u00e9sente une condition<\/td>\n Dur\u00e9e (peut \u00eatre longue ou courte)<\/td>\n<\/tr>\n \n Transition<\/td>\n Fl\u00e8che<\/td>\n Connecte deux \u00e9tats<\/td>\n Instantan\u00e9e<\/td>\n<\/tr>\n \n \u00c9v\u00e9nement<\/td>\n Texte sur la fl\u00e8che<\/td>\n D\u00e9clenche la transition<\/td>\n Point d’occurrence<\/td>\n<\/tr>\n \n Garde<\/td>\n Texte entre crochets []<\/td>\n Valide la transition<\/td>\n Avant l’ex\u00e9cution de la transition<\/td>\n<\/tr>\n \n Action<\/td>\n Texte sur la fl\u00e8che ou dans l’\u00e9tat<\/td>\n Ex\u00e9cute la logique<\/td>\n Pendant l’entr\u00e9e, la sortie ou le s\u00e9jour<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \ud83d\udee0\ufe0f Guide \u00e9tape par \u00e9tape pour cr\u00e9er un diagramme<\/h2>\n
\u00c9tape 1 : Identifier la port\u00e9e du syst\u00e8me<\/h3>\n
\u00c9tape 2 : Listez les \u00e9tats<\/h3>\n
\n
\u00c9tape 3 : D\u00e9finissez les \u00e9v\u00e9nements<\/h3>\n
\n
\u00c9tape 4 : Dessinez les transitions<\/h3>\n
\n
\u00c9tape 5 : Ajouter des actions<\/h3>\n
\ud83c\udf21\ufe0f Exemple pratique : Logique d’un thermostat<\/h2>\n
Description du sc\u00e9nario<\/h3>\n
Construction du diagramme<\/h3>\n
\n
\n
\n
\n
\u26a0\ufe0f Pi\u00e8ges courants dans la conception d’\u00e9tats<\/h2>\n
1. L'”\u00c9tat spaghetti”<\/h3>\n
2. Transitions manquantes<\/h3>\n
3. Transitions non atomiques<\/h3>\n
4. Surutilisation des actions “Do”<\/h3>\n
\ud83d\udd0d Approfondissement : Conditions de garde vs. logique dans les actions<\/h2>\n
\n
si (batterie > 10%)<\/code>. Si vrai, l’action pourrait \u00eatre demarrerMoteur()<\/code>. Cette s\u00e9paration rend le diagramme lisible : la fl\u00e8che vous indique quand<\/em> cela se produit, et l’\u00e9tiquette vous indique quoi<\/em> il fait.<\/p>\n\ud83e\uddea Tests et validation<\/h2>\n
1. Couverture des chemins<\/h3>\n
2. Tests de s\u00e9quence d’\u00e9v\u00e9nements<\/h3>\n
3. Cas limites<\/h3>\n
\ud83d\udd04 Machine \u00e0 \u00e9tats vs. Sch\u00e9ma de flux<\/h2>\n
\n\n
\n \nFonctionnalit\u00e9<\/th>\n Diagramme de machine \u00e0 \u00e9tats<\/th>\n Sch\u00e9ma de flux<\/th>\n<\/tr>\n<\/thead>\n \n Objectif<\/td>\n Comportement du syst\u00e8me dans le temps<\/td>\n Flux d’ex\u00e9cution de l’algorithme<\/td>\n<\/tr>\n \n Dur\u00e9e<\/td>\n Les \u00e9tats ont une dur\u00e9e (temps pass\u00e9)<\/td>\n Les \u00e9tapes sont instantan\u00e9es<\/td>\n<\/tr>\n \n Entr\u00e9e<\/td>\n \u00c9v\u00e9nements (externes\/interruptions)<\/td>\n Donn\u00e9es d’entr\u00e9e<\/td>\n<\/tr>\n \n R\u00e9utilisabilit\u00e9<\/td>\n \u00c9lev\u00e9e (les \u00e9tats peuvent \u00eatre r\u00e9utilis\u00e9s)<\/td>\n Faible (chemin lin\u00e9aire)<\/td>\n<\/tr>\n \n Id\u00e9al pour<\/td>\n Contr\u00f4le embarqu\u00e9, logique d’interface<\/td>\n Calculs, traitement de donn\u00e9es<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \ud83d\udcdd Meilleures pratiques pour les machines \u00e0 \u00e9tats embarqu\u00e9es<\/h2>\n
\n
\u00c9tatInactif<\/code>) et le CamelCase pour les \u00e9v\u00e9nements (par exemple, SurAppuiBouton<\/code>).<\/li>\n\ud83d\ude80 Conclusion<\/h2>\n