Parlons Arduino > Modélisation, Architectures logicielles et matérielles

Machine à états

<< < (2/5) > >>

Dominique:
Bonjour Marc-Henri,

Ce sujet est très intéressant, surtout du fait que tu en montres une application concrète.

Le fait d'installer un IDE supplémentaire comme Eclipse m'effraie toujours, ainsi que le fait d'utiliser plusieurs langages de programmation (C, C++, Java).

Je suppose qu'avant d'installer cet outil de développement Java sous Eclipse, tu as essayé de trouver quelques outils et bibliothèques dans l'environnement Arduino.

Quand j'écris "outil" je ne pense pas forcément "logiciel", mais aussi méthode de réflexion avec papier, crayon et neurones.

Peux-tu nous expliquer ton cheminement jusqu'à StateChart, ce qui pourrait nous éviter des pertes de temps, car je suis en pleine reflexion sur la modélisation et la gestion de mon réseau, avec d'autres amis de ce site, bien évidemment, car on est plus forts à plusieurs.

Merci d'avance
Dominique

jac56:
Bonsoir,

La modélisation d'un système par machine d'états-transitions est, à ma connaissance, un des moyens les plus efficaces pour analyser un problème et écrire du bon code (dans le sens conforme, efficace, facile à mettre au point et à maintenir). Cela s'applique à la gestion de systèmes physiques en toute sécurité ou à des protocoles de communication, avec la même facilité. C'est une approche malheureusement insuffisamment connue.

Pour chaque état, un (ou des) évènements permettent une transition vers un autre état (ou d'autres états), en réalisant éventuellement une action déterminée. Il peut parfois y avoir retour vers le même état (à une variable d'état près, éventuellement). A chaque état peuvent être associées un jeu de valeurs des variables d'état (ce qui peu matérialiser en quoi consiste une 'transition', mais pas toujours).
Cette approche permet effectivement de réfléchir à bien poser le problème, à trouver les bons états, les bonnes variables d'état, à tester sur papier la conformité du fonctionnement aux attentes, tout cela avec rapidité (ce n'est finalement que du dessin servant de support à une 'expérience de pensée') mais avec une grande sûreté (l'automate dessiné fait ce que l'on veut, ou non, le constat est immédiat, et en cas de non, c'est que la modélisation est à revoir). Cette approche événementielle est en général vécue comme assez naturelle. Tout cela sans avoir écrit une seule ligne de code !

Le passage du schéma au code est grandement simplifié, et une grande partie en devient assez 'mécanique', donc sûre :
- un bel enum() pour les états possibles de la variable 'état' (on peut mettre des noms parlants; si on en ajoute un, intermédiaire, rien n'est cassé avec l'enum) ;
- un grand switch sur la variable 'état' pour le choix de l'état courant à traiter, avec autant d' instructions 'case' que d'états recensés;
- et sous chaque 'case' du switch, la succession des événements possibles dans cet état (et seulement ceux-là) [souvent des  if() ],  suivi du code des actions à appliquer pour réaliser la transition correspondant à cette événement (changement de certaines valeurs d'état ou autre action) avec, in fine, le passage dans le nouvel état pour cet événement (nouvelle valeur assignée à 'état').
Ce code peut bien souvent être enrichi progressivement: on fait tourner la machine à vide au début (pour vérifier tous les enchaînements avec des traces simples), puis on ajoute les actions (dont certaines peuvent être 'dangereuses' surtout en cas de bug et pour lesquelles il vaut mieux être certain du fonctionnement correct de l'automate avant de les activer). Si l'étude est bien faite, cela doit marcher du premier coup, ou presque (pour la part automate, au moins).
Chacun pourra selon ses goûts y ajouter une dose appropriée de programmation-objet. Une transition, finalement, cela peut-être une action, donc une méthode appliquée à un objet.
De la sorte, on peut résoudre des problèmes très complexes en les divisant en des transitions simples et précisément définies. Cette approche structurée facilite la lisibilité, la maintenance et les évolutions.

Dans un projet de type Locoduino, il peut facilement y avoir besoin de plusieurs diagrammes états-transitions : un pour une phase de réglage de paramètres, par exemple, un pour le fonctionnement d'exploitation proprement dit, pour gérer un affichage, etc...

Un lien en français qui décrit une façon d'aborder cette modélisation : http://frederique.lafoux.free.fr/cours/pdf/ISI_UML_DiagrammeEtatsTransitions.pdf.
et il y en a sûrement bien d'autres.

Quoiqu'il en soit, en ce qui concerne la mise en oeuvre de la partie 'étude de l'automate', je suis d'accord avec Dominique, un outil n'est pas essentiel.
Au-delà du simple papier crayon gomme, un outil graphique pour faire des rectangles, des flèches et mettre des commentaires convient parfaitement. A défaut un Excel ou un LibreOffice répond aussi au besoin. Cela facilite l'établissement et les itérations de mise au point en restant plus 'propre' qu'un dessin manuel. Après, on peut aussi acheter l'outil de génie logiciel qui passe directement du schéma au squelette du code, mais c'est peut-être un peu luxueux.
J'ai même connu des concepteurs qui se contentaient de plusieurs colonnes : état de départ, événement, état d'arrivée, commentaires ou description de l'action. Il 'suffit' de détailler toutes les instances nécessaires, ligne par ligne. A chacun sa façon et ses préférences ...

Un autre lien qui donne des informations sur divers logiciels de génie logiciel, dont StarUml qui pourrait, sous Windows, répondre à la question : https://www.projet-plume.org/fr/fiche/staruml (non testé; et il y a beaucoup d'autres logiciels sur ce site, certains bien connus).

En espérant que cela pourra vous être utile.

Dominique:
Merci pour cette excellente contribution qui nous éclaire bien sur les 2 briques essentielles d'une bonne gestion de réseau :
- la modélisation qui consiste à traduire en objets les éléments du réseau (zones, aiguilles, signaux, trains, itinéraires, ..), avec les méthodes propres à chaque objet,
- la table d'états et d'actions, l'automate qui associe les événements aux actions.

On a bien à faire avec deux démarches indépendantes qu'il faut étudier conjointement.

J'ai pratiqués les automates dans des machines de Telecom dans le passé et cette experience me revient bien à l'esprit en lisant ce fil. À l'époque il n'existait pas de logiciel de type StateChart. Le crayon et le papier précédaient l'assembleur !

Ce qui serait intéressant, ce serait de faire tourner un noyau et un configurateur d'automate sur Arduino !
Est-ce utopique ?

savignyexpress:
Bonsoir à tous,

Je vous remercie pour vos contributions très pertinentes sur ce sujet. Voici quelques éléments de réponse:

Structure d'un programme
Je partage le point de vue de Jac56 sur les machines d'états en tant que meilleur moyen pour structurer un programme. J'ajouterais que c'est encore plus pertinent pour un système embarqué tels que les applications basées sur l'Arduino et les microcontrôleurs.

Cheminement pour aboutir au StateChart
J'ai bien évidemment commencé par tracer des graphes d'état à la main, sans m'aider d'un outil. C'est toujours plus rapide qu'avec un outil et on peut se permettre des libertés quant au formalisme sans se heurter à l'intransigeance de l'outil.

En introduisant la hiérarchie et le parallélisme, les StateCharts simplifient les graphes d'état en permettant de placer au niveau adéquat les transitions gérant les erreurs par exemple ainsi qu'en évitant l'explosion combinatoire.

Le principal avantage de l'outil est la possibilité de simuler le comportement sans avoir écrit la moindre ligne de code. C'est le support de l'expérience de pensée dont parle Jac56. Il faut tout de même une certaine dose d'imagination pour "voir" les trains circuler en déroulant les scénarios d'exploitation. La génération de code, pas encore testée, ne me paraît pas une fonctionnalité indispensable car, comme l'explique Jac56, le passage du graphe au code est très mécanique.

La simulation peut aussi se faire avec une version PC du programme où les entrées-sorties avec l'environnement de l'Arduino sont remplacées par des entrées-sorties clavier-écran. Cf. le post sur les techniques de mise au point: http://forum.locoduino.org/index.php?topic=105.0.

L'installation d'Eclipse ne pose pas trop de difficultés, au bout d'une soirée le Yakindu Statechart Tool était opérationnel.

Je vais suivre le lien de Jac56 sur la manière d'aborder la modélisation par machines d'états, c'est un sujet qui m'intéresse beaucoup.

Noyau et configurateur d'automate
Je ne vois pas très bien ce que Dominique entend par "noyau" sur Arduino. S'il s'agit d'un noyau temps réel, c'est certainement trop gourmand en mémoire programme et RAM. Des petits noyaux fait maison, comme par exemple la bibliothèque Schedule Table de Jean-Luc, sont plus appropriés pour les ressources d'un microcontrôleur.

Le concept de configurateur d'automate n'est pas clair pour moi. Peux-tu préciser ce que tu entends par là ?


À bientôt pour la suite de ces réflexions.
Bonne soirée et meilleures salutations.

Dominique:
Bonjour à tous,

Je pensais au noyau de l'automate c'est à dire un modèle de programme à adapter à son cas personnel (et non a un noyau temps réel ou multitâche). En fait Jac56 a donné l'idée qui est un grand switch avec des case appelant les actions à exécuter aux transitions. Je peux comprendre que cela suffit pour démarrer.

Quand au configurateur, j'imagine que les liens entre les événements et les états et actions pourraient être inscrits dans des variables avec un outil interactif dit "configurateur" plutôt qu'entrés en "dur" dans l'automate "switch.. case".

Au stade de la réflexion dans lequel je suis, le crayon et le papier seront les plus utiles. Mais je pense déjà aux erreurs à corriger, aux évolutions et modifications futures, donc à la forme d'écriture la plus ouverte aux évolutions, si cela peut exister.

Sincères salutations
Dominique

Navigation

[0] Index des messages

[#] Page suivante

[*] Page précédente