Projet partagé d'un gestionnaire de réseau

[Dominique]

Nous sommes quelques uns à nous intéresser à la réalisation d'un gestionnaire de réseau qui soit capable de détecter les positions des trains qui circulent sur un réseau et qui soit capable de les commander pour respecter les règles de circulation ferroviaire :
- un seul train par canton,
- des signaux positionnés selon ces règles (sémaphores, carrés, avec ralentissement, etc..),
- des commandes des trains pour le respect des ralentissements et arrêts selon la signalisation,
- des détecteurs de présence et/ou d'identification(RFID, RailCom) des trains par canton, zone, aiguille, etc.
- une représentation du réseau sous forme de TCO ou écran graphique,
- une centrale DCC pour commander les trains aussi bien automatiquement (par le gestionnaire) que manuellement (par des manettes, smartphone ou TCO),
- des possibilités de réaliser des itinéraires avec commande des appareils de voie, aussi bien manuels qu'automatiques.
- des animations contextuelles (sons, lumières, etc..)

Le sujet a été très bien expliqué par Pierre59 dans sa série d'articles : Un gestionnaire en C++ pour votre réseau.
https://www.locoduino.org/spip.php?article154
https://www.locoduino.org/spip.php?article167
https://www.locoduino.org/spip.php?article172
https://www.locoduino.org/spip.php?article184
Il offre une boite à outils très complète pour réaliser un gestionnaire, que j'ai eu le plaisir de mettre en oeuvre sur mon réseau.

DDEF a également exposé ses principes dans la série : SGDD : Système de Gestion DD
https://www.locoduino.org/spip.php?article132
https://www.locoduino.org/spip.php?article134
https://www.locoduino.org/spip.php?article151

Des réalisations partielles ont été décrites comme : Gestion d’une gare cachée
https://www.locoduino.org/spip.php?article155
https://www.locoduino.org/spip.php?article156
https://www.locoduino.org/spip.php?article157

Sans oublier les solutions commerciales ou de l'open source comme JMRI, RocRail, iTrain et autres RRTC qui tournent sur PC/MAC et nécessitent des interfaces avec la centrale DCC et la rétrosignatisation, entraînant souvent des coûts importants.

Depuis pas mal de temps, Locoduino recommande le bus CAN pour les communications. entre les diverses entités du réseau. LaBox est l'exemple de centrale DCC pilotable par Bus CAN et en même temps par logiciel JMRI, RocRail via l'USB.

Le but de ce sujet est de recueillir vos souhaits et préférences dans le but de concevoir un système de gestion de réseau architecturé autour d'un bus CAN.

Suite à l'expression des divers desiderata, nous établieront un cahier des charges puis démarrera une réalisation.

Le tracé du réseau à équiper se trouve en page 11 :
https://forum.locoduino.org/index.php?topic=1645.msg17785#msg17785
A vous maintenant.

Cordialement
Dominique

[Dominique]

Pour démarrer, j'appuie la proposition de BobyAndCo qui propose de commencer par résoudre les points les plus généraux pour s’attaquer ensuite au particulier.
 
Parmi les principaux points auxquels il faut trouver des réponses :
 
La Topographie : Décrire précisément toutes les liaisons des cantons entre eux, préciser si ces liaisons sont directes, par l’intermédiaires d’aiguilles (droites ou déviées), de TJD etc… C’est je crois le travail le plus fastidieux et aussi, c’est assez compliqué à modifier quand on fait des modifications sur le réseau. Il n’y a pas qu’un seul procédé pour ce faire. Soit on propose les boutons et les switches sur des satellites, soit un outil graphique. Pourquoi pas ? Si celui-ci peut générer un document formaté ou toutes les liaisons sont décrites et qui pourraient être importé tel quel dans le gestionnaire ; fichier json par exemple.

La sécurité : Lorsque l’on cherche à faire avancer un convoi dans un sens donné, on recherche si le canton suivant, en fonction de la position d’aiguille éventuelle est libre ou occupé. Si libre, la loco peut avancer, doit s'arrêter ou ralentir. Si elle s’engage sur le canton C+1, on cherchera maintenant à connaitre l’état d’occupation de C+2. Si occupé, on donne l’ordre à la loco de ralentir au franchissement du premier capteur et de stopper au franchissement du second capteur.

La gestion d’itinéraire. On a un point A de départ et un point B d’arrivée. On a aussi des options comme je l’ai déjà dit : Itinéraire le plus court en distance, itinéraire où aucun canton n’est occupé au moment du lancement, itinéraire qui se modifie de lui-même en cas de modifications. Mais la recherche automatique d'itinéraire n'est pas souvent nécessaire sauf dans les réseaux compliqués cet les cas d'école. Bien souvent un petit jeu d'itinéraires prévus à l'avance suffira. Il sera capable de tester la non-occupation des éléments de voie à emprunter, positionner les aiguilles nécessaires et libérer tout ou partie du tracé au fur et à mesure de l'avancement du train.

L'architecture matérielle : Il est trop tôt pour la décrire et la limiter tant que les principes ci-dessus ne sont pas clairs.
Mais il apparait tout de même dans cette réflexion qu'il s'agit d'un gestionnaire qui diffère des logiciels existants comme JMRI, RocRail, iTrain ou autres RRTC qui existent déjà et dont la mise en oeuvre et l'utilisation font l'objet d'autres sujets sur ce forum.
Comme dans mon propre réseau, une carte Arduino un peu puissante et connectée au bus CAN peut faire office de gestionnaire avec une interface homme-machine qui peut prendre diverses formes : (écran graphique tactile associé, PC/Mac connecté avec application ad hoc, etc..

Tout autour du bus Can on trouvera des détecteurs et des actionneurs comme la carte Satellite V1 proposée il y a quelques lustres ou les cartes Satellite de BobyAndCo de type "Canton" qui seront décrites dans de prochains articles.

[Pierre59]

Bonjour

Pour le gestionnaire je pense qu'il ne faut pas le limiter au seul bus CAN, mais l'ouvrir à tous les bus possibles : CAN, WIFi, Ethernet, BlueTooth, Série, ... Avec une messagerie qui fonctionne de la même façon sur tous les bus (même API).

On parle toujours de "canton", mais faudrait bien se mettre d'accord sur ce que c'est. Pour moi ce qui est important c'est la zone : une portion de voie avec ou sans appareil de voie sur laquelle il y a une détection de présence de matériel roulant. Un canton c'est une ou plusieurs zones consécutives (pas forcément toujours les mêmes) qui se trouvent entre deux signaux pouvant présenter le sémaphore (sémaphores, carrés, ...). Les cantons servent à l'espacement des trains avec un mécanisme de cantonnement (BAL, BAPR, BMU, ...). Sur un réseau il y a des parties qui ne sont pas cantonnées : dépôts, partie marchandises, petites lignes, ... donc sans cantons mais avec éventuellement des zones.

Les zones sont essentielles dans le gestionnaire, ce sont leur occupations/libérations qui rythment son fonctionnement.

Fondamentalement un gestionnaire peut être centralisé ou repartit (dans les satellites par exemple). Un gestionnaire repartit est beaucoup plus difficile à écrire et à mettre au point qu'un gestionnaire centralisé (j'ai longuement travaillé dans des équipes CNRS de programmation répartie). Le langage à utiliser reste ouvert : Java ou C++ il faudra en discuter.

J'en reste la pour l'instant, dites ce que vous en pensez.

Pierre

[DDEFF]

Bonjour à tous,

Le système SGDD était un tout premier essai, vraiment mes tout débuts.
J'ai, depuis développé des programmes en Processing, nettement plus évolués.
Ma dernière contribution pour Locoduino était ce gestionnaire qui sert d'exemple de réalisation.
Il n'est pas parfait, loin de là, mais le but est de donner une idée d'un gestionnaire maison, sur mesure.
https://www.locoduino.org/IMG/zip/train_tco_v1_9_1.zip

Mode d'emploi :
Après avoir installé la dernière version de Processing, vous pouvez extraire le fichier zip.
Vous lancez n'importe quel programme et quand la fenêtre s'ouvre, vous selectionnez "circuit d'essai.tsv" puis "ouvrir".
S'affiche alors un circuit biscornu qui regroupe quasi tous les pièges dans lesquels on peut tomber sur son réseau.
Pour lancer un train, on doit créer un itinéraire :
Vous sélectionnez (souris vers le bas de l'écran) la "fourche" (icone de l'itinéraire point à point) et vous cliquez avec la flèche verte un point de départ (sur n'importe quel signal), puis un point d'arrivée (là aussi sur un signal).
Le premier itinéraire possible s'affiche en orange.
En cliquant GAUCHE, un autre itinéraire s'affiche, toujours avec les mêmes points de départ et d'arrivée.
En cliquant GAUCHE, on voit donc défiler, à chaque fois un nouvel itinéraire possible, jusqu'à "plus d'itinéraire" (retour à l'afficha des rails en gris)
Si vous recliquez GAUCHE, vous reprenez le cycle.
En cliquant DROIT, vous choisissez cet itinéraire.
Un train apparait au début de l'itinéraire et la souris devient, cette fois, une horloge.
Apparait aussi une manette et, en faisant glisser le curseur, vous décidez du temps d'arrêt au bout de cet itinéraire.
Un clic DROIT met fin aux choix.
Maintenant, en bougeant le curseur, vous faites partir le train qui va jusqu'au bout de l'itinéraire et s'arrête.
Remarque : vous pouvez "chaîner" les itinéraires et décider, pour chaque fin d'itinéraire, du temps d'arrêt (ou non).

Si vous voulez plusieurs trains, il suffit de les programmer à partir d'une zone vide. Il se crée un nouveau train.
Si vous voulez un circuit bouclé, choisissez l'icone en forme d'anneau. Vous chaînez les itinéraires jusqu'à revenir au point de départ.

Bon, je m'arrête là pour aujourd'hui. J'ai présenté UNE possibilité. Il y aura, bien sûr, d'autres propositions.
Pour l'instant, ce ne sont que des trains virtuels. Il y a encore du boulot avant que ça fasse bouger des trains réels.

Denis

[bobyAndCo]

Bonsoir à tous,

@Dominique. Excellente initiative. Je constate avec satisfaction que les réactions et propositions n’ont pas tardées.

Alors quels seraient pour ma part mes souhaits prioritaires ?

Eh bien, avant tout que mes trains puissent rouler en toute sécurité, c’est la base. Je voudrais donc qu’un train qui entre dans un canton dont le canton +1 est occupé soit automatiquement ralenti puis stoppé.

De plus, J’aimerais une simplification maximale du paramétrage et de la description des liaisons entre zones ou cantons. Par exemple, lorsque trois extrémités de cantons convergent en un seul point, l'application devrait automatiquement déduire la présence d'une aiguille et créer l'objet logiciel correspondant. Il est essentiel que toute modification physique du réseau ne devienne pas un casse-tête lors de la mise à jour du gestionnaire. J’aimerais me dispenser de passer de longs moments à saisir les identifiants des cantons, des aiguilles ou des capteurs.

Je remercie Denis pour sa présentation très détaillé mais c’est justement cela que je souhaite éviter, glisser-déposer, clic gauche, clic droit et encore clic droit !!!

Et comme la signalisation ferroviaire française est complexe et que je n’y comprends pas grand-chose, je souhaiterais que le logiciel indique les cibles nécessaires sur le canton et que je n’ai pas à m’en occuper car je vais y passer beaucoup de temps et probablement me tromper.

Je voudrais aussi bien sûr que le gestionnaire sélectionne lui-même les signaux à allumer sans que j’ai besoin de lui préciser au préalable.

En résumé, j'aspire à ce que les trois aspects évoqués par Dominique - topographie, sécurité, et gestion d'itinéraire - deviennent pratiquement transparents pour l'utilisateur.

Enfin, pour faire court, je suis d’accord avec Pierre sur l’ensemble de ce qu’il aborde. Et je suis particulièrement d’accord qu’il vaudrait mieux un gestionnaire répartit qu’un gestionnaire centralisé. Chaque satellite assurant toutes les fonctions d’un gestionnaire mais de manière locale en se « nourrissant » des informations échangées avec tous les autres satellites sur le bus.

Cette architecture offre en premier lieu l’avantage d’être beaucoup moins sollicitée qu’un gestionnaire central. L’évolutivité peut se faire plus facilement sans perturber l'ensemble du réseau.

Mais quand j’ai dit tout cela, je me dis que ce type de gestionnaire existe déjà avec les satellites autonomes.



Alors je me dis qu’il serait nécessaire de publier au moins les trois premiers articles sur les satellites autonomes pour que cela puisse aussi servir de base de réflexion pour la suite.

Bien amicalement

Christophe

[Dominique]

Pierre a écrit qu’ « Un gestionnaire repartit est beaucoup plus difficile à écrire et à mettre au point qu'un gestionnaire centralisé .

Par contre des éléments répartis par cantons comme le suggère Christophe pourraient-ils être réunis dans un gestionnaire centralisé ? J’imagine que les communications entre objets canton seraient équivalentes aux échanges via Can.

Cela me faciliterait la tâche vu que mon gestionnaire est actuellement centralisé.

Dominique

[bobyAndCo]

des éléments répartis par cantons comme le suggère Christophe pourraient-ils être réunis dans un gestionnaire centralisé ?

Oui, en théorie, chaque satellite autonome étant en lui-même un gestionnaire, le code peut assez facilement s’adapter ! Mais l'un des intérêts avec une solution en répartit est que la charge de calcul est  divisée entre les différents microcontrôleurs des satellites.

Les satellites autonomes fonctionnent avec des ESP32, donc assez puissants. J'utilise pleinement les deux cœurs pour répartir les charges et je suis pourtant presque au max sur chaque. Un seul microcontrôleur pour tous le réseau risque de « louper » des étapes !

[Dominique]

Les satellites autonomes fonctionnent avec des ESP32, donc assez puissants. J'utilise pleinement les deux cœurs pour répartir les charges et je suis pourtant presque au max sur chaque. Un seul microcontrôleur pour tous le réseau risque de « louper » des étapes !

C’est étonnant car j’utilise un Due avec un seul cœur ARM Cortex M3 a 84mhz, il affiche le réseau à jour sur un écran 5 pouces en même temps et il ne semble pas perdre de messages !

[DDEFF]

Ce que vient de dire Christophe m'inquiète aussi quant à la capacité de calcul des ESP32.
Pour moi, ce que fait sa "carte de canton" est très simple : enregistrer qui est le canton suivant dans chaque sens en fonction de la position des aiguilles en utilisant le bus CAN.
J'ai peine à croire que ça suffise à saturer les 2 cœurs d'un ESP32.

Mais si on veut se passer d'un ordinateur, il faut, au moins, un TCO physique avec des LED et des boutons. Donc une carte LED et une carte boutons reliées au bus CAN.

Je pense qu'on devrait parler de cartes de zones et pas de carte de canton. C’est-à-dire des cartes qui ne gèrent pas les signaux. Et avoir des cartes spécifiques pour les signaux.

Il est d'ailleurs intéressant de constater qu'il faut exactement le même nombre de boutons sur le TCO que ceux qui se trouvent sur les cartes de zone : un bouton par sens et par zone.

Au point de se demander si on ne pourrait pas utiliser les boutons du TCO pour décrire le réseau.

Je m'explique :
 
On définit un identifiant pour chaque carte de zone.
Chaque bouton du TCO génère un identifiant, le même que celui de la zone qu'il gère.
A un endroit du TCO, on a un switch (un octet)
A un autre endroit, on a un bouton "programmation"
On appuie sur le bouton de programmation sur le TCO : on entre dans le mode "programmation"
On affiche sur le switch la position des aiguilles entre les 2 cartes de zone à programmer.
On appuie sur le bouton de zone départ sur le TCO : c'est enregistré.
On appuie sur le bouton de la zone arrivée sur le TCO : c'est enregistré.
On appuie sur le bouton de programmation, ce qui envoie dans le bus CAN le message qui va bien vers les 2 cartes de zone.

Dit autrement, je centralise les boutons qui sont sur la carte de zone sur le TCO.

L'avantage, c'est qu'on n'est pas obligé d'avoir accès aux cartes de zone qui peuvent alors être sous le réseau.
Cartes qui peuvent alors être plus petites, débarrassées des boutons et de la signalisation.

[Dominique]

Revenons d’abord aux préoccupations principales :
- la topographie : comment obtenir le graphe complet du réseau, par exemple pour l’afficher sur un TCO ?

- comment assurer la sécurité : le suivi des trains, la mise à jour du graphe, de la signalisation et l’application a la conduite des trains.

-les itinéraires : on y reviendra plus tard, l’algorithme de choix étant une option.

[dmskd]

Bonjour à tous,

Je viens de lire avec grand intérêt ce lancement de projet, d'autant plus grand que j'ai en projet un nouveau réseau.
Il y a eu beaucoup de remarques pertinentes et mes connaissances "limitées" dans ce domaine ne me permettent pas de commenter.
Le seul point pour lequel j'interviens est qu'on a parlé de PC et Mac, mais il ne faut pas oublier qu'il y a PC-Windows et PC-Linux (qui est mon cas).
Je pense que s'il y a une interface sur ordinateur, elle doit être "universelle", comme un navigateur web.

[Pierre59]

Revenons d’abord aux préoccupations principales :
- la topographie : comment obtenir le graphe complet du réseau, par exemple pour l’afficher sur un TCO ?

Le graphe du réseau (avec beaucoup d'annotations) peut peut être suffire au gestionnaire, mais ne permet pas d'afficher correctement un TCO (ils faut d'autres informations). Ce ne sont pas les mêmes informations qui sont nécessaires dans les deux cas.
Je ne vois que que deux possibilités pour obtenir le graphe, un éditeur graphique ou un codage en mode texte avec un éditeur de texte.
Un éditeur graphique c'est un très gros programme. J'ai fais pas mal d'essais pour un éditeur graphique de TCO, il reste encore pas mal de petits bugs; voir aussi les travaux de Denis.
Un codage en mode texte est peu être plus abordable (json,XML, ...) mais faut pouvoir coder toutes les informations nécessaires.
Il faut remarquer que les classes proposées dans la série d'articles constituent en fait "un" codage du graphe d'un réseau.

- comment assurer la sécurité : le suivi des trains, la mise à jour du graphe, de la signalisation et l’application a la conduite des trains.

La sécurité se fait essentiellement avec les enclenchements (voir l'article 3). La SNCF assure cette sécurité surtout avec des relais (peut être aussi avec des programmes à logique majoritaire), mais il reste encore pas mal d'enclenchements mécaniques. Les relais changent leurs états en fonction des infos d'occupation des zones, des appuis sur des pédales par des essieux et des demandes d'itinéraires.
Clairement cette sécurité sur nos réseaux on la fait avec des programmes qui ont comme données variables des occupations/libérations de zones, des détections de train ponctuelles et demandes de trajets ou itinéraires de trains.

-les itinéraires : on y reviendra plus tard, l’algorithme de choix étant une option.

Je suis tout à fait d'accord avec toi.

Pierre

[Dominique]

Le seul point pour lequel j'interviens est qu'on a parlé de PC et Mac, mais il ne faut pas oublier qu'il y a PC-Windows et PC-Linux (qui est mon cas).
Je pense que s'il y a une interface sur ordinateur, elle doit être "universelle", comme un navigateur web.

Ty as tout à fait raison, il faut être compatible à tous les OS.

Mais pour cela il faut savoir ce que l’on veut faire avec un PC :
- y faire tourner le gestionnaire ? Ça existe déjà avec JMRI et d’autres compatibles linux. Ce n’est pas notre objectif.
- développer une interface avec le gestionnaire : oui bien sûr mais il faut décrire ce qu’elle doit faire.

[bobyAndCo]

Ce que vient de dire Christophe m'inquiète aussi quant à la capacité de calcul des ESP32.
Pour moi, ce que fait sa "carte de canton" est très simple : enregistrer qui est le canton suivant dans chaque sens en fonction de la position des aiguilles en utilisant le bus CAN.
J'ai peine à croire que ça suffise à saturer les 2 cœurs d'un ESP32.

Mais non mon cher Denis, le satellite ne fait pas que cela. Par exemple, il émet sur le bus toutes les 100ms un message CAN sur 8 octets dans lequel on trouve l’adresse de la loco (s’il y en a une), et en fonction de la position de ses différentes aiguilles, quel est son C+1 et son C+2 ainsi que son C-1 et son C-2.

Mais surtout, il reçoit de tous les autres satellites ce même message, je rappelle toutes les 100 ms, prend en compte les messages qui le concerne et adapte son comportement en conséquence : Arrêt de sa propre loco, adaptation de signalisation et quelques autres opérations.

Il doit également s’occuper toutes les 100ms de lire l’état de ses différents capteurs et aussi assurer la lecture de Railcom.

Ici un apperçu de la principale méthode qui s’occupe de toutes ces mises à jour : https://github.com/BOBILLEChristophe/Satellites_autonomes_client/blob/main/src/GestionReseau.cpp

Crois moi, répété toutes les 100ms, c'est déjà pas mal.

[bobyAndCo]

Le graphe du réseau (avec beaucoup d'annotations) peut peut être suffire au gestionnaire, mais ne permet pas d'afficher correctement un TCO (ils faut d'autres informations). Ce ne sont pas les mêmes informations qui sont nécessaires dans les deux cas.

Selon moi, Pierre soulève judicieusement la distinction qu’il faut faire entre gestionnaire et TCO (d’une manière générale) ou tout ce qui permet d’agir sur l’état du réseau ou de visualiser l'état du réseau.

Même si souvent ces deux fonctions sont rassemblées en un seul appareil (logiciel), ce sont pourtant deux choses à bien distinguer au risque de tout mélanger et de n’arriver à rien.

Au risque de se répéter, le gestionnaire doit en priorité assurer la sécurité et afficher la bonne signalisation. Qu’on lui demande de faire de la gestion d’itinéraires n’est finalement qu’une extension des précédentes fonctions.

De fait, le gestionnaire au sens strict n’a pas d’interface graphique, il n’en a pas besoin. Il fonctionne essentiellement en boucle et agit en fonction des informations qu'il reçoit.

C’est pour cela que l’on peut imaginer toutes sortes de périphériques, logiciels (HTML, Processing…) ou simplement matériels, boutons poussoirs, manettes de gaz etc…

Ces périphériques n’ayant même pas de communication avec le gestionnaire ou sans doute très peu. La manette de gaz par exemple agit directement sur la centrale DCC qui en confirmant la réception de la commande, met à jour le gestionnaire.

De même pour les aiguilles, l’ordre est donné par un bouton physique ou logiciel et seul un message informe le gestionnaire du changement. Dans ce cas précis, on voit bien l’intérêt d’un interrupteur en butée de servo d’aiguille qui est le meilleur moyen de s’assurer du changement d’état.

Ainsi, le gestionnaire, développé pour se concentrer sur ses fonctions de base est indépendant de tout autres systèmes de commande.

J’espère que j’explique bien ce point et que ce que je dis est partagé.

Christophe