Auteur Sujet: Machine à états  (Lu 5078 fois)

Marc-Henri

  • Jr. Member
  • **
  • Messages: 95
    • Voir le profil
    • Modélisme ferroviaire & électronique
Machine à états
« le: septembre 07, 2015, 12:54:41 pm »
Bonjour à tous,

Lorsque les applications doivent gérer plusieurs événements ainsi que des timeouts, il est avantageux de les organiser sous forme d'une ou plusieurs machines à états. Une machine à états se représente sous la forme d'un diagramme états - transitions qui ensuite se traduit quasi systématiquement dans le langage de programmation.

Bien qu'ayant une longue expérience du développement de systèmes embarqués / temps réel pour l'avoir pratiqué professionnellement et maintenant en tant que hobby, l'élaboration même du diagramme à partir du comportement attendu du système me préoccupe. J'ai constaté qu'il est souvent plus simple de décrire des scénarios de fonctionnement particuliers plutôt que de généraliser tout de suite sous forme de diagramme états - transitions.

Je me demande donc s'il existe des outils qui, partant d'un ensemble de scénarios de fonctionnement, sont capables d'en déduire le diagramme d'états correspondant. J'ai trouvé plusieurs articles de recherche sur le sujet, mais aucune référence d'outils.

Le cas concret qui m'a amené à ces réflexions est la gare cachée de mon prochain réseau. Les caractéristiques de cette gare cachée sont les suivantes:
  • Elle comporte 2 voies.
  • Les 2 voies peuvent être empruntées dans les 2 sens, la gare cachée étant dans un tunnel le long d'une voie unique.
  • Si la gare contient 2 trains dans le même sens de marche, c'est le 1er arrivé qui sort en 1er.
  • Si la gare contient 2 trains en sens de marche opposés, il n'est plus nécessaire d'imposer un ordre de sortie. Chaque train peut partir n'importe quand.
  • La gare reçoit des ordres du système qui gère le reste du réseau tels que: recevoir un train d'un côté ou de l'autre, faire un sortir un train d'un côté ou de l'autre, retourner l'info s'il y a une place de libre.

Il est simple de parcourir le diagramme d'états pour retrouver les scénarios de fonctionnement et c'est ce que l'on ferait pour définir les cas test du système. Mais la synthèse du diagramme d'états à partir des scénarios est plus complexe. À défaut d'un outil, une méthode systématique applicable manuellement m'intéresserait déjà.

Qu'en pensez-vous ?

Bon début de semaine et meilleures salutations.

Marc-Henri

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Machine à états
« Réponse #1 le: septembre 07, 2015, 09:12:35 pm »
Bonsoir Marc-Henri,

Je dois être comme Monsieur Jourdain : je faisais des machines à état sans le savoir.
Moi qui n'ai fait qu'un organigramme dans ma vie (le jour de l'examen d'informatique, après avoir fait le programme...  :( ), je ne connaissais pas la terminologie.

Mais tu as parfaitement raison : ce serait bien que ça existe.
Je suis déjà bien content de voir que quand on a ce diagramme de fait, le programme en découle "mécaniquement" et ça vaut le coup de chercher.

Bonne semaine
Denis
« Modifié: novembre 09, 2015, 08:18:20 pm par DDEFF »

Marc-Henri

  • Jr. Member
  • **
  • Messages: 95
    • Voir le profil
    • Modélisme ferroviaire & électronique
Re : Machine à états
« Réponse #2 le: septembre 23, 2015, 11:32:05 am »
Bonjour Denis,

Je fais des essais avec les scénarios d'exploitation de mon prochain réseau et de sa gare cachée.

Un site allemand mentionne un logiciel Open Source permettant d'éditer / simuler des statecharts et générer du code C, C++ et Java à partir de ces modèles. Il est disponible pour Windows, Mac et Linux à cette adresse: http://www.statecharts.org/. Les statecharts sont une généralisation des machines d'états qui incluent la notion de hiérarchie: états et sous-états ainsi que le parallélisme, ce qui peut simplifier les graphes d'états.

La simulation m'intéresse en tant que moyen de vérifier que la/les machine(s) d'états permettent de produire tous les scénarios d'exploitation. J'ai l'intention d'évaluer ce logiciel et je décrirai mon expérience dans ce post.

Bonne journée et meilleures salutations.

Marc-Henri

Marc-Henri

  • Jr. Member
  • **
  • Messages: 95
    • Voir le profil
    • Modélisme ferroviaire & électronique
www.statecharts.org
« Réponse #3 le: septembre 24, 2015, 07:47:31 am »
Bonjour à tous,

J'ai commencé l'évaluation de l'outil Open source Yakindu Statechart Tool disponible à l'adresse http://www.statecharts.org/.

Installation
Cet outil est un plug-in de l'environnement de développement Eclipse. Son installation se fait comme suit:
  • Inscription sur le site pour communiquer prénom, nom et une adresse e-mail.
  • Téléchargement à partir du lien reçu par e-mail. La taille fait près de 200 MB.
  • Décompression du fichier et recopie du répertoire eclipse dans l'arborescence /opt/ réservée aux logiciels installés manuellement.
  • Créer le fichier suivant: /usr/share/applications/eclipse.desktop, nécessite certainement un sudo pour des questions de droits.
  • Copier le contenu suivant dans le fichier eclipse.desktop:
[Desktop Entry]
Name=Eclipse
Type=Application
Exec=/opt/eclipse/eclipse
Terminal=false
Icon=/opt/eclipse/icon.xpm
Comment=Integrated Development Environment
NoDisplay=false
Categories=Development;IDE
Name[en]=eclipse.desktop

On peut alors lancer eclipse après avoir recherché l'application et éventuellement l'épingler dans la liste d'applications. La suite est décrite dans les tutoriaux en ligne et vidéo.

Premiers pas
Il vaut la peine d'ouvrir le projet d'exemple "traffic lights" pour voir à quoi cela ressemble.

Ensuite, j'ai commencé la modélisation de ma gare cachée en créant:
  • 2 listes d'événements, l'une pour les événements venant des détections de trains, l'autre pour les commandes venant du reste du réseau.
  • 2 régions, l'une pour la voie 1, l'autre pour la voie 2. Chaque région correspond à une machine d'états tournant en quasi parallèle.
  • Pour chaque région, j'ai défini les états qui peuvent avoir le même nom local car, au niveau du système, ils sont préfixés par le nom de la région. Exemple: Voie_C1.Vide, Voie_C2.Vide.
  • J'ai fait quelques essais de simulation et c'est déjà très intéressant. On clique sur les événements et l'état courant se met en rouge au fur et à mesure de l'avancement.

Je posterai des images ces prochains jours, l'outil permettant de produire de fichiers .png à partir des graphes d'états.

Complément d'information
Ce blog, en anglais, http://scholtyssek.blogspot.ch/2013/10/yakindu-statechart-tools-arduino.html présente l'exemple "traffic lights" pour Arduino.


Bonne journée et meilleures salutations.

Marc-Henri
« Modifié: septembre 24, 2015, 12:07:47 pm par Marc-Henri »

Marc-Henri

  • Jr. Member
  • **
  • Messages: 95
    • Voir le profil
    • Modélisme ferroviaire & électronique
Statecharts: modélisation de gare cachée
« Réponse #4 le: septembre 29, 2015, 09:01:11 pm »
    Bonsoir à tous,

    Voici le 1er essai de modélisation de la gare cachée de mon prochain réseau à l'aide de l'outil Yakindu Statechart Tool. Ce modèle est bien entendu susceptible d'évoluer car il ne comporte encore aucune gestion des alimentations ni des aiguilles.

    Il comporte 2 régions C1 et C2 correspondant à 2 machines d'états parallèle pour chacune des 2 voies de la gare cachée. Les événements sont décrits dans le bloc sous les diagrammes et sont regroupés en interfaces, l'une pour les événements déclenchés par le passage des trains, l'autre par les commandes adressées à la gare cachée. Leurs significations sont:

    interface trains:
    • in event C1G: train détecté sur voie C1 à gauche
    • in event C1D: train détecté sur voie C1 à droite
    • in event C2G: train détecté sur voie C2 à gauche
    • in event C2D: train détecté sur voie C2 à droite

    Ces événements de détection seront très certainement produits par des zones de détection de courant aux extrémités de chaque voie.

    interface commandes:
    • in event SortieG: on demande de faire sortir un train par la gauche de la gare cachée
    • in event SortieD: on demande de faire sortir un train par la droite de la gare cachée

    Ces commandes proviendront de la machine d'états principale du réseau.

    Les états possibles d'une voie sont:
    • Vide
    • Occupee_D / Occupee_G: 2 états composés pour l'occupation de la gare dans un sens ou l'autre. Ces états se décomposent en sous-états: Entrant, Attente, Arret.
    • Entrant: le train est détecté à l'entrée de la voie.
    • Arret: le train est arrivé à l'autre extrémité de la voie, il s'arrête.
    • Attente: le train est arrivé à l'autre extrémité de la voie, mais comme il y a déjà un train dans le même sens de marche sur l'autre voie, il doit attendre pour repartir. Ce sera l'autre train qui partira avant lui.

    Les conditions signifient par exemple:
    • trains.C1G: le train a été détecté à gauche de la voie C1.
    • trains.C1D [ ! active(C2.Occupee_D.r1.Arret)]: le train a été détecté à gauche de la voie C1 et la voie C2 n'est pas dans le sous-état Arret de Occupee_D. La condition entre crochets s'appelle une garde, elle introduit une condition supplémentaire en plus de l'événement.
    • always [ ! active(C2.Occupee_D.r1.Arret)]: dès que la garde est vraie, dans ce cas la voie C1 n'est plus dans le sous-état Arret de Occupee_D, cette transition est effectuée. Le mot-clé always indique qu'il ne faut pas attendre un événement quelconque.

    En simulation, j'ai ainsi pu vérifier que les voies C1 et C2 sont indépendantes tant qu'elles ont des trains en sens opposés, mais elles deviennent liées si les 2 trains vont dans le même sens. Dans ce cas, le dernier train arrivé attend que le 1er arrivé soit parti.

    À suivre...

    Bonne soirée et meilleures salutations.

    Marc-Henri

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1246
  • 100% Arduino et N
    • Voir le profil
Re : Machine à états
« Réponse #5 le: novembre 09, 2015, 12:40:35 pm »
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
« Modifié: novembre 09, 2015, 12:51:18 pm par Dominique »

jac56

  • Newbie
  • *
  • Messages: 12
    • Voir le profil
Re : Machine à états
« Réponse #6 le: novembre 15, 2015, 01:45:15 am »
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.

Jacques

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1246
  • 100% Arduino et N
    • Voir le profil
Re : Machine à états
« Réponse #7 le: novembre 15, 2015, 09:53:59 pm »
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 ?

Marc-Henri

  • Jr. Member
  • **
  • Messages: 95
    • Voir le profil
    • Modélisme ferroviaire & électronique
Re : Machine à états
« Réponse #8 le: novembre 17, 2015, 10:50:24 pm »
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

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1246
  • 100% Arduino et N
    • Voir le profil
Re : Machine à états
« Réponse #9 le: novembre 17, 2015, 11:11:17 pm »
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

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1246
  • 100% Arduino et N
    • Voir le profil
Re : Machine à états
« Réponse #10 le: novembre 18, 2015, 11:05:11 am »
Bonjour à tous,

J'avoue découvrir l'UML !
J'ai trouvé ce cours très intéressant sur les différentes phases de conception qui se termine sur une synthèse :

http://laurent-audibert.developpez.com/Cours-UML/?page=mise-en-oeuvre-uml

avec un schéma global joint.

L' application à notre domaine de Marc-Henri est très interessante.
J'en profite pour essayer de l'appliquer à la "mise en mouvement" de la modélisation de mon réseau.

A suivre ...

Merci de m'avoir conduit vers ce savoir  :D

Bien cordialement
Dominique



« Modifié: novembre 18, 2015, 11:08:15 am par Dominique »

jac56

  • Newbie
  • *
  • Messages: 12
    • Voir le profil
Re : Machine à états
« Réponse #11 le: novembre 18, 2015, 12:30:27 pm »
Je suis heureux que cela vous semble utile.

C'est étonnant comme ce formalisme relativement simple fonctionne bien.
Le cœur de la modélisation suffit : graphe entre états qui décrit avec une précision diabolique quels événements (et eux seuls) permettent de 'transiter' d'un état à un autre, et avec quel effet.
Chaque 'case' du 'switch case' concerne un état. Le code à l'intérieur de chaque 'case' est, en général, une forêt d'if(); if (tel_événement == vrai) alors {}; seuls les événements permettant une transition sont représentés; les autres sont ignorés: l'état reste inchangé.

Personnellement, je ne saurais plus m'en passer pour aborder ce genre de problèmes.
J'ai découvert cette approche professionnellement, il y a bien longtemps (années 80...), alors que j'étais (bien jeune et)  en train de me noyer dans un problème de ce type abordé, par ignorance, sans une méthode suffisamment rigoureuse et efficace. C'était une analyse de signal assez complexe (du style: 'interprêter un électrocardiogramme', mais dans un domaine technique très industriel). Je m'en suis toujours souvenu, même si ensuite j'ai abandonné ce terrain de jeu. C'était l'époque bénie où les consultants des sociétés de service en informatique vous aidaient réellement à trouver rapidement des solutions très concrètes à vos soucis.

Dans quelques exemples traités pour le modélisme ferroviaire, sans l'usage de diagrammes états-transitions, je pense que je ne serais pas parvenu au but.
Exemple avec l'enchaînement d'opérations nécessaire pour régler les courses des aiguillages (4 points par aiguillage) de mon petit TCO. Il faut pouvoir revenir en arrière en cas d'erreur de manipulation, à tous les stades, tout en gérant minutieusement les messages à l'écran pour ne pas perdre le fil de là où l'on est (c'est très vite fait!), et en parvenant au résultat, in fine.
La combinatoire devient vite énorme. J'étais parti avec l'idée de laisser beaucoup trop de latitude à l'utilisateur, comme par exemple, lui laisser choisir le sens de parcours des points. Parfaitement superflu et surtout dangereux, car foisonnant. Les premières esquisses sur papier m'ont permis de voir qu'il fallait davantage canaliser l'opérateur, tout en ajoutant la faculté de retours-arrière, bien encadrés, et pas tous pressentis au départ. Et je pourrais multiplier les exemples dans le domaine Locoduino.

Il ne faut surtout pas alourdir la modélisation : sa légèreté fait sa force, car elle garantit la rapidité et l'exhaustivité de l'exploration du 'terrain'.

L' 'expérience de pensée' n'est pas difficile, et elle est, de toutes façons, incontournable.
Étant dans tel état, quel événement vais-je autoriser, et s'il arrive, vers quel état va-t-il me conduire?
Quel événement veux-je (dois-je) ignorer dans tel état?
Compte tenu des opérations à faire, pourrais-je raisonnablement atteindre l'état que je vise en un seule étape? Dois-je me ménager une étape intermédiaire, une voie de repli? etc...
Qu'est ce qui caractérise ce nouvel état atteint (en terme de variables d'état)?
Faute de graves déboires futurs, il est inévitable d'agiter toutes ces questions en amont du codage.
La démarche de pensée reste assez naturelle.

Pour illustrer ces propos, voilà ce que ça peut donner :
http://www.forum-train.fr/forum/viewtopic.php?f=16&t=14445

Dominique y reconnaîtra la toile de fond de certains échanges que nous avons eu naguère.

Bien cordialement et à votre disposition sur tel ou tel sujet, dans la limite de ce que j'ai compris.



« Modifié: novembre 18, 2015, 01:05:21 pm par jac56 »
Jacques

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Machine à états
« Réponse #12 le: décembre 15, 2015, 09:17:56 pm »
Je vais vous paraître prétentieux, mais SGDD a été fait de tête, sans machine d'état (je ne savais même pas ce que c'était) et pratiquement sans notes.

Certes, je connais bien le sujet de la commande des trains depuis des années et, même si je pars d'un écran blanc, je sais où je vais.
Je pars d'un problème simple que je résous, puis je le mets dans une boucle pour qu'il s'applique à tout le réseau. Etc.

Par exemple, la commande des signaux se fait en seulement 100 lignes (Block.cpp, lignes 142 à 241) quelle que soit la taille du réseau.
J'ai 100 aiguilles et 155 cantons car j'ai pris un byte.
Mais si j'avais pris un interger, le programme n'aurait pas une ligne de plus.

Le vrai problème, c'est de définir le vrai canton suivant, qui dépend de la position des aiguilles.
C'est ça qui m'a obligé à  traiter des itinéraires.

Mon programme aurait certainement été meilleur avec une machine à états.
Mais c'est surtout la façon d'appréhender le problème au départ qui différencie deux programmes.

petitrain

  • Jr. Member
  • **
  • Messages: 75
    • Voir le profil
Re : Machine à états
« Réponse #13 le: décembre 19, 2015, 07:43:11 pm »
Bonjour à tous,
Je lis avec intérêt vos échanges, même si je ne comprends pas toujours tout. Je suis un menuisier à la retraite,
aimant bien les petits trains mais très limité en programmation et en anglais...
J'ai découvert la plateforme Arduino depuis quelques temps déjà et, comme tous les néophytes, on commence par recopier des petits programmes à droite et à gauche, émerveillé que cela marche...puis on a envie d'écrire ses propres sketches.... Par manque d'expérience et de méthode, on est souvent déçu et même découragé.
Aussi quand je vous ai lu, j'ai cherché du côté des machines à état, évoquées sur plusieurs sites. J'ai découvert que le Grafcet est une des méthodes d'approche pour écrire un programme clair et je suis tombé sur ce site:
http://www.electronics-micros.com/software-hardware/plclib-arduino/
Il propose une bibliothèque Arduino, très bien documentée pour transformer un Arduino  en un automate programmable (PLC). On nous explique que l'on peut facilement retranscrire un Grafcet , mais aussi écrire du code supplémentaire qui ne serai pas pris par la bibliothèque. Depuis quelques temps, j'écris des petits Grafcets que je transpose en code et ça marche!... La vision que l'on a du code à écrire s’éclaircit beaucoup et c'est un grand bonheur à concevoir. Allez faire un tour sur ce site, il me semble intéressant pour les petits trains.

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1246
  • 100% Arduino et N
    • Voir le profil
Re : Machine à états
« Réponse #14 le: décembre 19, 2015, 08:19:07 pm »
Bonjour Petitrain,

Merci pour ce lien. Je viens de jeter un coup d'oeil et je suis un peu déçu car je trouve que c'est une manière de contourner le langage C et C++ de l'IDE Arduino en lui substituant un langage différent. En faisant le tour des pages, je trouve même que ce PLC est moins riche que ce que l'Arduino offre en standard, avec les multiples apports des développeurs et la richesse des bibliothèques disponibles.

Je ne veux pourtant pas décevoir car je suis passé rapidement sur le site. J'ai bien vu à la fin que c'est en cours de développement et que des extensions sont à venir.

Mais je trouve simplement dommage de s'éloigner du langage C et C++ de l' Arduino, dont on trouve facilement des tonnes de tutos, pour se lancer dans un nouveau langage : c'est une source de confusion.

Par contre les approches UML, pour l'analyse des situations à résoudre est un bon investissement. La programmation ensuite peut rester classique.

Mais j'ai peut-être mal compris ...

Cordialement
Et joyeux Noël