Projet partagé d'un gestionnaire de réseau

[bobyAndCo]

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 !

@Dominique. Ce n'est pas la messagerie CAN qui est à taquet. Sur les satellites autonomes, pour 50 satellites sur le bus, à raison d'un message par satellite toutes les 100 ms, à 1Mbps et sur une longueur de bus de 30 mètres, la charge du bus CAN est de 7,15% de sa capacité théorique !!!

Dans la réponse que j'ai faite à Denis, tu constateras que je demande au microcontrolleur de faire beaucoup de choses en 100 ms et que toute la puissance de l'ESP32 n'est pas superflue.

Tu me disais sur ton DUE perdre, non pas des messages mais des trains !!! N'est-ce pas là le problème ?

[Dominique]

Tu me disais sur ton DUE perdre, non pas des messages mais des trains !!! N'est-ce pas là le problème ?

Non ce n’est pas une question de performance mais d’analyse et de codage : des cas d’erreur mal traités.

C’est pour ça que cette discussion m’intéresse 

[dmskd]

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.

Si le gestionnaire assure la sécurité, est-ce qu'il ne doit pas filtrer toute commande manuelle, par exemple interdire d'accélérer sur un canton au ralenti, ou interdire d'actionner une aiguille occupée par un train ?

[bobyAndCo]

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.

Si le gestionnaire assure la sécurité, est-ce qu'il ne doit pas filtrer toute commande manuelle, par exemple interdire d'accélérer sur un canton au ralenti, ou interdire d'actionner une aiguille occupée par un train ?

Oui effectivement dans le cas d'un gestionnaire centralisé, c'est la solution "économique". J'ai un peu de mal à me détacher du satellite autonome car je baigne complètement dedans. Pour la commande d'aiguillage sur le satellite autonome, celle-ci est adressée à un satellite X qui connait la présence ou non d'un convoi mais qui devra aussi s'assurer que le convoi n'est pas à cheval sur deux cantons.

Pour la traction, la commande doit en effet "transiter" par le gestionnaire qui la laisse passer, la bloque ou la modifie (limitation de vitesse par exemple) selon la topologie du réseau à l'instant.

Bien vu et merci !

Christophe

[DDEFF]

@ Christophe
Si tu sais, à tout moment, pour un canton C donné, quel est son C+1 en fonction de la position des aiguilles, tu peux gérer une première information : pas de C+1 => afficher le C (Carré) du canton C.

Si C+1 existe, tu regardes si C+1 est occupé.
Si oui, tu affiche S (Sémaphore), sinon tu ne changes pas le signal.

La question, après, consiste à connaitre quel est le signal affiché au bout de C+1. Il y a plusieurs cas à gérer.
Si le signal de C+1 est S ou C, afficher A (Avertissement) pour le cas le plus simple.

Evidemment, pareil côté C-1. L'identité d'un train n'a aucune incidence sur la signalisation… dans un premier temps.

Connaître C+2 et C-2 est moins utile, bien que je m'en serve dans mon gestionnaire :
J'estime, en ligne droite et avec une bonne visibilité, que le conducteur voyant un signal A sait qu'il va bientôt voir S et devoir s'arrêter et que, dans ces conditions, il ne va pas accélérer à fond pour freiner juste avant le signal A. Et qu'il va maintenir sa vitesse actuelle en espérant que le A devienne VL (Voie Libre) et que, là, il a presque 2 cantons libres devant lui.

Si on n'est pas en ligne droite, si le canton est court, etc… il y a d'autres cas à gérer.

A mon avis, dans un premier temps, sur un circuit sans piège, gérer C+1, C-1 et C, S, A, VL est plausible. Par contre, il est nécessaire qu'un canton connaisse, via le CAN, le signal de C+1 et C-1.
De même, il doit faire respecter les signaux de son canton par "son" train, une fois qu'il a fait les calculs.

Denis

[Dominique]

On voit que Denis a décortiqué des tas de choses.

J’en déduit qu’il y a, dans un gestionnaire sérieux, toute une suites de traitements à faire les uns avant ou après les autres et dont l’ordre est très important ,

-1- détections des occupations et libérations zone par zone comme le dit Pierre et mise à jour des signaux

-2- suivi des trains pour identifier a tout moment ceux qui sont détectés, afin d’être capable de leur appliquer :

-3- les consignes de conduite locales : ralentissement (15, 30, 60, 90), arrêt et redémarrage

Sans empêcher toutes sortes de cas particuliers : ralentissement dans les virages et aiguilles déviées par exemple, coup de klaxon avant sortie de tunnel et passages à niveau, ..et un mélange de conduite manuelle et automatique.

La difficulté est l’ordre dans lequel faire ces traitements. Par exemple des qu’un train entre dans un canton C le C-1 est fermé et il ne faut arrêter le train qui y est encore (j’ai eu ce cas avec le Locoduinodrome).

Donc il faut ajouter et manipuler des variables d’état pour conditionner les comportements.

La boîte à outils de Pierre (Un gestionnaire en C++) est très intéressante mais il faut ajouter les traitements ci-dessus.

C’est ça qui est amusant 🤩 et ça plante parfois.

J’espère trouver la potion magique dans ce sujet !

[Pierre59]

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.

@ Christophe
Très bonne analyse, je suis tout à fait d'accord.

@ Tous
Par contre pour les aiguilles, comme d'autres l'on déjà dit, seul le gestionnaire peut manoeuvrer les aiguilles. Sinon risque de manoeuvrer une aiguille avec un train dessus, risque de manoeuver une aiguille d'un itinéraire formé dirigeant un train n'importe où, ...
Pour "l'accélérateur" c'est un peu pareil le gestionnaire doit filtrer les commandes pour traiter les arrêts aux signaux, les limitations de vitesse, ... Je préconise aussi l'usage d'un encodeur en quadrature plutôt qu'un potentiomètre, la position du potentiomètre de reflétant pas toujours la vitesse effective du train et il peut y avoir des mouvements mal controlés du train.

Pierre

[bobyAndCo]

Bon, ça avance bien je trouve.

Je repose une question pour laquelle je n’ai pas eu vos réponses et elle m’intéresse car je trouve qu’elle est à résoudre avant toutes les autres.

Comment faites-vous pour associer une locomotive à un canton-zone à la mise sous tension du réseau ou en posant la locomotive sur les rails ?

Les gestionnaires graphiques le font avec la souris à l’endroit où est la loco, mais si pas d’interface graphique ?

Et pour le suivi des trains d'un canton à l'autre, j’ai bien ma petite idée de l’algorithme de suivi lors du passage d’un canton-zone à un autre, mais j’aimerais savoir comment d’autres voient la chose.

Autre question dans le même registre, comment déterminez-vous qu’un convoi à totalement quitté un canton-zone ?

Cela me conduit à demander à Pierre "quand le gestionnaire sait il qu’il n’y a pas de train qui chevauche ?"

Par contre pour les aiguilles, comme d'autres l'on déjà dit, seul le gestionnaire peut manoeuvrer les aiguilles. Sinon risque de manoeuvrer une aiguille avec un train dessus

Christophe

[bobyAndCo]

Je reviens également sur la capacité de calcul pour un gestionnaire centralisé qui serait basé sur un microcontrôleur et qui aurait, disons 20 satellites à superviser.

Est-on d’accord que la fréquence moyenne d’envoi par chaque satellite de ses informations d’états est d’environ 100 ms ?

Partant de là, on est d’accord je pense pour considérer que le gestionnaire centralisé devra recevoir et traiter un message toutes les 5ms et donc avoir fait ce qu’il a à faire pour ce satellite donné dans ce laps de temps : Mise à jour des données variables, capteurs ponctuels, arrêt ou ralentissement de la locomotive au besoin, modification de la signalisation.

Sachant que par ailleurs il doit ponctuellement modifier les aiguilles, assurer le suivi des convois !

Je pose vraiment cette question sans arrière-pensée.

Christophe

[Pierre59]

Bonsoir

Je suis un peu débordé par toutes les questions, mais je vais répondre, demain vraissemblablement.

Pierre

[DDEFF]

Je peux donner des éléments de réponse

1°) On détecte la présence d'un train par consommation de courant.
C'est évident pour une loco, et pour un wagon ou une voiture isolée, il faut souder une résistance CMS (10 kOhm) entre la roue isolée et l'essieu.
Toute autre méthode n'est pas sûre (en particulier les ILS/ Effet Hall, ... qui sont ponctuels)
Pour être franc, il existe une autre méthode fiable : le comptage d'essieu. Mais, pour la mettre sur un réseau, bonjour...

2°) Le vocabulaire est très clair :
Une ZONE correspond à une détection de présence. Ce peut être un rail avec des coupures, une aiguille seule, plusieurs aiguilles.
Un croisement, une TJS, une TJD sont forcément une zone à eux tout seuls car on ne peut pas les relier à un canton.

Un CANTON, c'est un ensemble de zones avec des signaux à chaque extrémité. Ou à une seule extrémité si c'est une voie à sens unique, évidemment.

Donc, faire une "carte canton" est ambigu : cela correspond à un cas très particulier : une seule zone avec un signal à chaque bout. C'est très réducteur.

Maintenant, c'est clair : un canton est libre quand TOUTES les zones qui le composent sont vides

3°) Personnellement je pense qu'il faut réserver les boutons qui commandent des aiguilles aux cas très simples (une ou 2 aiguilles isolées). Sinon, on passe par un itinéraire.
Dans tous les cas, un bouton ne commande pas directement une aiguille. Un bouton demande au gestionnaire de changer la position de l'aiguille et le gestionnaire le fait quand les conditions de sécurité sont remplies

Comme je l'ai déjà dit, il existe un état "occupé par un itinéraire", complètement distinct d'une occupation physique d'une zone.

A la SNCF, les zones correspondant à un itinéraire sont affichées au TCO (par exemple en blanc clignotant) et l'occupation physique (par exemple en rouge). Pas seulement la position des aiguilles. Et on voit les zones s'effacer derrière le train au fur et à mesure que le train avance sur l'itinéraire.

Il faut pouvoir enregistrer des itinéraires, sans tenir compte des occupations (physiques et par un autre itinéraire).
Après, le gestionnaire libère les trains quand c'est possible en toute sécurité.

On voit que Denis a décortiqué des tas de choses

Entre autres, j'ai lu la "Bible" de la signalisation : "La signalisation ferroviaire" de Roger Rétiveau (639 pages !!)

[bobyAndCo]

l faut souder une résistance CMS (10 kOhm) entre la roue isolée et l'essieu.

Merci pour cette info.

Un croisement, une TJS, une TJD sont forcément une zone à eux tout seuls car on ne peut pas les relier à un canton.

Un CANTON, c'est un ensemble de zones avec des signaux à chaque extrémité.

Je ne te suis pas, tu dis que "Un croisement, une TJS, une TJD sont forcément une zone à eux tout seuls", là je suis OK mais tu dis "on ne peut pas les relier à un canton." alors que tu dis plus loin : Un CANTON, c'est un ensemble de zones

Merci pour la réponse

Christophe

[DDEFF]

Simplement, dans ta carte, tu englobes jusqu'à 2 aiguilles. Tu peux parce que tu prends les aiguilles "en talon" (pas "en pied", d'ailleurs).
Si un train est en phase de quitter le canton du côté des aiguilles et qu'il soit uniquement sur les aiguilles, le fait que le canton reste occupé n'a pas d'incidence, ça ne gêne pas les autres trains.
Et s'il n'est que sur la partie sans aiguilles, de toutes façons aucun train ne pourrait venir sur les aiguilles. C'est "un tout".

Par contre, un croisement doit être géré tout seul, on ne peut pas le relier à un voisin. Voir le schéma.
J'ai supposé qu'on reliait le croisement au canton 1.
Si un train est sur le canton 1, sans être sur le croisement, même à l'arrêt, on empêche un train qui va du canton 2 au canton 3 de passer à cause de l'occupation du croisement.
Et pareil pour les autres extrémités. Il doit être géré tout seul.

Mais ça n'est pas un canton car il n'y a pas de signaux

[DDEFF]

Quand l'une des zones d'un canton est occupée, TOUT le canton est occupé

[DDEFF]

Pour info sur les résistances CMS pour détection de présence :
Le "Petit Train du Tertre", le site d'une bande d'amis (dont notre Jean Luc à ses débuts, avec un certain Pierre Molinaro)

https://lestrainsdutertre.redheberg.com/TouteVapeur/Les_trains_du_Tertre/Articles_Trains_du_Tertre/C03_La_detection_de_presence.html

Plein d'idées sur plein de sujets
ou

http://rouge-et-creme.over-blog.com/2014/08/detection-facile-de-vos-wagon-et-voitures-en-ho.html