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

Machine à états

(1/5) > >>

savignyexpress:
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:
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

savignyexpress:
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

savignyexpress:
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

savignyexpress:
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

Navigation

[0] Index des messages

[#] Page suivante