Projet partagé d'un gestionnaire de réseau

[laurentr]

Bonsoir

Je m ajoute aux contributeurs de ce fil

Je voudrais aussi apporter quelques éléments de topographie à intégrer aux réflexions/propositions en cours.

Entre deux cantons ( là où on peut arrêter un train par cantonnement) on rencontre souvent sur nos réseaux des grills d entrées/sorties plus ou moins complexes.( ex double bretelle, TJD,...)
Ce sont des zones à monitorer mais sur lesquelles le cantonnement est "INTERDIT".

On peut associer l'enchainement par construction mais les distances sont parfois de l ordre d un ou deux appareil...

Par ailleurs on peut avoir un enjambement du convoi sur plusieurs zones dont à minima 2 cantons ( car loco en tête assurant une détection, véhicule non consommateur en milieu, et véhicule de fin consommateur)
Autre alternative renseigner les longueurs des convois et zones (cantons, zone grills, ...) et suivre les mappings associés... (nœuds au cerveau garantis!)

Autre cas à considérer:

Circulation en sens inverse des segments de voie parcourus

Circulation en "pousse" ( engin moteur en queue dans le sens de déplacement)

Il n y a surement de solution "toute faite" mais il faudra configurer par un moyen une initialisation avant de pouvoir s'offrir une exploitation.



Laurent

[Dominique]

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

Tous les messages n’ont pas besoin d’être répétés. Un accusé de réception évite les répétitions (cas des commandes de signaux et aiguilles). Les détections ponctuelles aussi.
100ms est arbitraire . Ça peut se déterminer par calcul des temps dans le programme. J’ai souvent mesuré des traitements compliqués de moins de 5ms.
Je pense que cette question n’est pas primordiale pour le moment. C’est du reglage.

[bobyAndCo]

Bonjour Dominique, bonjour à tous,

Ce n’est pas aux commandes d’aiguilles ni de signaux auxquelles je pense qui doivent effectivement arrêter d’être envoyées dès que l’on a l’accusé de réception.

Par contre, je ne suis pas sûr de bien comprendre pour les détections ponctuelles.
Est-ce que tu veux dire que tu limites la fréquence de messages envoyés par les satellites ?

Personnellement, je ne jouerai pas là mais à la réception dans le gestionnaire, en recherchant si, pour un identifiant donné les datas du message sont différentes du précédent envoi.

Certes 100ms c’est arbitraire, toute autre fréquence aussi d’ailleurs. Mais par expérience, on constate que c’est à peu près ce qui est nécessaire pour détecter des capteurs ponctuels comme des IR ou encore des capteurs RFID.

La question est-elle primordiale ? Oui sans doute car je pense qu’elle doit être omni présente au moment de l’écriture du code pour rechercher tous les mécanismes d’économie de calcul.

[Pierre59]

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 ?

On aborde ici une question dont on ne parle pas souvent qui est l'initialisation du gestionnaire.
A son initialisation le gestionnaire à besoin de connaitre toutes les zones qui sont réellement occupées ainsi que les références des l'engins moteurs qui sont dessus (nom, adresse DCC,icone, ...). Pour faciliter ceci on peut lors de l'arrêt normal du gestionnaire sauvegarder ces informations dans un fichier (ou autre) pour les reprendre lors de l'initialisation. Mais quelques cas (crash du gestionnaire, déraillement, ajout d'engin moteur, ...) nécessitent un moyen de dialogue avec le gestionnaire (pas forcement par le biais d'un TCO graphique). De toute façon le gestionnaire a besoin de signaler des infos sur son fonctionnement (des anomalies, des erreurs, ...).

A son initialisation le gestionnaire à besoin aussi de connaitre la position de toutes les aiguilles. Soit on peut obtenir ces positions en questionnant les satellites, soit on peut les sauvegarder dans un fichier lors d'un arrêt normal du gestionnaire, sinon (dont le cas du crash) il faut mettre une par une toutes les aiguilles dans une position connue par manoeuvre.

Pour finir sur l'initialisation tous les signaux carrés sont fermés, les sémaphores présentent les feux voulus et aucun itinéraire n'est formé.

Pierre

[bobyAndCo]

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

Bonjour Denis,

Eh bien oui je suis d’accord avec toi et c’est comme cela que je raisonne pour les satellites autonomes. Certes, je n’ai pas encore voulu inclure le cas de croisement mais comme je te le disais je préfère partir du général et terminer par le particulier qui finira par trouver sa solution.

D’ailleurs, tu prenais aussi le cas de la boucle de retournement. A la réflexion, ce n’est rien d’autres que deux cantons reliés chacun à l’une des extrémités de l’aiguille, non ? 

[Pierre59]

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.

C'est un problème épineux et je suis preneur de solutions originales. Quand une zone passe de l'état libre à occupé on a besoin de savoir quel train rentre dessus. Pour cela on examine les deux zones avoisinantes en fonction de la position des aiguilles, il ni en a au maximum que deux car un train ne peut venir sur une zone que si les aiguilles sont bien positionnées. Si une seule de ces zone est occupée on connait le train (il faut vérifier que c'est possible avec son sens, et sa vitesse), sinon il y a ambiguïté on a deux trains candidats et il faut jouer sur le sens des trains, leur vitesse (arrêt) , le sens des zones, l'état des itinéraires ou des autorisations, ...

On peut très bien ne pas trouver quel est le train (aucune des deux zones voisines occupées ou trains des zones voisines ne convenant pas), cela arrive normalement quand on pose un nouvel engin moteur sur le réseau, le gestionnaire signale alors une anomalie et il faut un dialogue pour le renseigner.

Pierre

[Pierre59]

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 ?"

Bonjour

On fait habituellement une détection de présence sur une zone par consommation de courant. Les engins moteurs consomment du courant (mais problème avec les engins moteurs à l'arrêt en analogique), les véhicules éclairés ou les fourgons (avec les feux arrières) aussi. Les autres véhicules non, Denis nous a indiqué ci-dessus que l'on peut rendre détectables des véhicules avec une petite résistance sur les essieux. Il existe un autre système équivalent le graphitage, il s'agit mettre une sorte de verni sur les bagues isolantes des essieux, ce verni contient du graphite qui conduit un peu le courant.

Idéalement tous les essieux ne prenant pas le courant devraient êtres traités (resistance ou graphite). Pratiquement si on a beaucoup de véhicules c'est un peu fastidieux. Pour palier cela on peut transformer un peu le gestionnaire, à chaque train est associé une liste de zones, quand le train occupe une nouvelle zone elle est ajoutée en tête de liste, quand le train libère une zone si c'est la dernière de la liste on procède à la libération normale de la zone sinon ou "oublie" cette libération (on ne fait rien).
La taille de cette liste peut être bornée en fonction de la topologie du réseau. Mais attention aux ruptures d'attelages qui peuvent faire exploser la taille, des tests et des messages du gestionnaire sont les bienvenus.

Pierre

[laurentr]

Bonjour

Comme je l'indiquais précédemment tu as aussi le cas ou le convoi et à cheval entre 2 cantons mais avec entre ces 2 éléments principaux une "occupation" d'une zone ( ou plusieurs)  (cas des aiguillages).

Si il y a un élément consommateur sur le segment en question pas de sujet il y a association et application des règles de détection.
Dans le cas contraire je ne vois que 2 solutions
La pré réservation d itinéraire qui n est "détruite" que lors de la libration du canton le plus haut de la liste (ici N+1) ou changement d itinéraire ( par forçage)
ex:  N+1 -- ZONE AIGUILLAGEA -- ZONE AIGUILLAGEB -- N -- N-1
Une comparaison parallèle avec les tailles des convois et celle des cantons et de leur déplacement.

Pour illustration la système Pégase réalisait une pré allocation en cas de succession de zone(s) sans arrêt (zone d aiguillage) et avec arrêt(canton) initialement "enjambement" sur 4 segments contigus.

Ce mécanisme est aussi à la base d autres produits ou de trains réel par verrouillage des itinéraires notamment. Je pense entre autre à RRTC


Laurent

[laurentr]

@BobynCo

Christophe, je crois me souvenir que dans ton projet de satellites autonomes l'identification est portée par RAILCOM qui une fois établie ( l Identification) va générer les instructions de freinage pour l'engin moteur concerné.

L indentification au démarrage du système en conception peut  s'appuyer sur un mécanisme analogue (AUTO ENROLLING) ( mais il manquera des info sur par exemple le type de convoi, sa longueur…) qui influent sur le bloc, à défaut on fixera a la longueur maxi permise comme taille de convoi sur le réseau.( par ex 3m20)

Je crois qu'il y a une restriction "forte" pour le cas des UM.
En effet en mode "CONSIST MODE" (UM) en principe l'émission RAILCOM du channel1 est désactivée et on se reporte alors à l émission de l adresse active du "couplage" sur le channel2 si la configuration est faite pour cela.
Dans le cas contraire on va avoir deux émissions de la même info ( une par chaque engin moteur) ( avec un risque de parasitage mutuel)( il est peu probable que chacun soit synchro avec son voisin!) soit il faut filtrer pour que par exemple seul l'engin de tête émette et sur le canal 2 dans ce cas. ( je pense mon interprétation conforme)

Chose inédite je n'ai jamais vu de système ayant plusieurs véhicules émetteur en RAILCOM sur une même section. ( plus par restriction que par non réalisation?) Mais peut être y a t il une magie qui le permettrait...

Laurent

[Pierre59]

Bonjour

Je connais bien le train français et je cherche toujours à rester très proche des techniques utilisée par celui-ci. Je crois que l'on est d'accord sur le fait que le gestionnaire doit assurer la sécurité. La sécurité des vrais trains est assurée par beaucoup de règlements et par la signalisation. Ce qui nous réunit ici c'est plus la signalisation et tout ce qu'il y a derrière. La signalisation est gérée par des postes d'aiguillage et des dispositifs de cantonnement.

Le cantonnement n'assure que l'espacement des trains (anti rattrapage) avec signalisation (BAL,BAPR,BMU, …) ou pas (cantonnement téléphonique, ). Les postes d'aiguillages utilisent des enclenchements (mécaniques ou électriques) pour assurer la sécurité : prise en écharpe, aiguilles mal positionnées, tête à tête, … La signalisation du cantonnement et des postes d'aiguillages peut être commune (BAL,BAPR, …) ou séparée (BMU, …) ce qui complique un peu les choses.

Le cantonnement et les postes d'aiguillages peuvent utiliser des zones pour leurs fonctionnement.

Une zone est un ensemble contigu de voies et d'appareils de voie (aiguille, TJD, TJS, croisement), sur lequel il y a une détection de présence d'un ou plusieurs essieux, par un dispositif électrique ou électronique.

Ces zones sont essentielles dans les cantonnements et les postes d'aiguillages modernes.

Les contraintes sur les zones dépendent un peu de leur utilisation :

- pour les zones dans les bifurcations ou les entrées/sorties de gare on fait en sorte qu'il ne puisse avoir qu'un seul train en circulation dessus, ce qui exclu la présence de plusieurs TJD,TJS ou croisement dans ces zone.

- pour certaines zones, comme celles des voies à quai, on peut avoir plusieurs trains dessus, pour créer des unités multiples ou mettre des motrices en tête. Généralement ces zones n'ont pas ou peu d'appareils de voie.

- pour certaines zones constituant des cantons le cantonnement "permissif" permet à un train d'entrer sur une zone occupé. Généralement ces zones de pleine voie n'ont pas ou peu d'appareils de voie.

Un canton est un ensemble contigu de voies et d'appareils de voie en général plutôt long (quelques kms). L'entrée dans un canton est habituellement protégée par un sémaphore ou un signal pouvant présenter le sémaphore (carré), situé juste avant le début du canton. Si le canton est à double sens il y a un signal des deux côtés. Certains cantonnements utilisent une zone ou plusieurs zones pour assurer le fonctionnement du cantonnement.

Le cantonnement se fait surtout en pleine voie, mais certaines bifurcations et certaines entrées/sorties de gare et leurs voies à quai assurent aussi la continuité du cantonnement. Le sémaphore est alors affiché sur les carrés et les zones servent simultanément au cantonnement et au postes d'aiguillages.

En résumé, on parle trop de canton et pas assez de zone. Une zone peut comporter une TJD ou une TJS ou un croisement ou pas et/ou d'autres aiguilles (ces aiguilles étant disposées de façon à respecter les contraintes précédentes). Il peut y avoir du cantonnement dans une gare.

Pierre

[Dominique]

Moi je suis d’accord avec Pierre : il faut s’occuper des zones en premier,  chacune d’elle ayant un capteur de présence qui permet de détecter l’entrée d’une loco en tire (en pousse il faut faire consommer le wagon de tête).
 Chaque zone doit connaître les zones adjacentes pour permettre la propagation du no de train donc le suivi des trains en recopiant son numéro dès le début de la détection. C’est le mécanisme de base à réaliser avant tout.

Lors d'une détection en entrée de zone, un train est toujours à cheval sur 2 zones. Je marque ainsi la tête de train dans la zone nouvelle,t détectée et la queue du trains dans la zone précédente.
Le train contient les zones occupées et lorsque la tête entre dans une nouvelle zone, en général, la queue libère sa zone. Lorsque la zone de queue est une aiguille, la zone avant aiguille est aussi occupée par la queue.
On pourrait aussi connaitre la longueur du train et celle des zones pour marquer les zones effectivement occupées.

La zone peut faire partie d’un canton qui va définir les signaux à fermer juste après la détection en tenant compte des zones incluses dans le canton. La présence d'aiguille(s) complique un peu les règles de marquage des zones.

La libération des zones dépend donc de la composition du canton, donc des signaux concernés

[Dominique]

En ce qui concerne l'initialisation du gestionnaire, la position des trains au départ, j'utilise une méthode assez infaillible et amusante au démarrage du réseau :

Comme la centrale peut piloter 12 trains dans mon réseau, tous les trains sont arrêtés et j'en bouge un et un seul uniquement jusqu'à ce que les détections de présence le détectent. Cela se produit à un changement de zone. J'en déduit la position et le sens du train. Puis je le recule à la même vitesse pendant la même durée pour qu'il retrouve sa place initiale.

Ensuite je recommence pour un autre train et ainsi de suite.

S'il ne se passe rien, soit le train n'est pas présent sur le réseau, soit il y a un mauvais contact.
Le risque est que le train percute un autre situé sur la zone adjacente mais ce cas est impossible si l'espacement des trains a été conservé à la session précédente.

J'ai modifié mes détecteurs sur mon réseau pour qu'il ne soient sensibles que lorsque les moteurs tournent. Ainsi il n'est plus nécessaire de rouler jusqu'à la zone suivante, la détection est immédiatement faite et cela ne dure qu'une fraction de seconde.
L'inconvénient est que je gestionnaire ne voit plus les trains à l'arrêt.

En cas d'erreurs dans le gestionnaire, un mode "panique" peut stopper tous les trains et relancer la détection de position.

[laurentr]

Bonsoir

La méthode d indentification via RAILCOM est rapide et efficace mais elle n'est que partielle.

En effet il n'y a que l'engin moteur sans autre forme d'info de donner.

Si dans le gestionnaire un fait un mapping avec une référence de composition connue et que celle ci n a pas changé alors on a un convoi dont on connait les caractéristiques.
Sinon l'info est erronée: ex la loco est "haut le pieds" et donc il faut modifier/actualiser le mapping pour que les caractéristiques jouent à plein ensuite et soient exploitées.

Ltr

[DDEFF]

Bonjour à tous,

Le train miniature est sensé représenter le train réel.

Mais dans le train réel, des ingénieurs ont analysé le réseau pendant longtemps, en implantant les signaux en respectant des règles strictes, en prenant en compte de nombreux paramètres.
Dans les trains, il y a un conducteur qui a été formé, à qui on donne toutes les caractéristiques de son train, qui connait à l'avance les passages dangereux.

Et nous, on voudrait faire pareil avec 2 bouts de ficelle ! 

On ne peut pas travailler correctement sans connaître la longueur des zones (et donc des cantons), sans connaître la longueur des trains et à suivre cette longueur.
Dans mon système, comme je pose des éléments de réseau (les pavés), je connais exactement leur longueur à l'écran et comme, maintenant, je dessine à l'échelle, je connais la longueur réelle des zones (à environ 1 mm près), y compris avec des rails flexibles.

Par ailleurs, vous vous en souvenez peut-être, dans "Decodunino", je décris les locos, les wagons, … et donc, leur longueur. Là, c'est dans l'autre sens, la longueur réelle donne la longueur à l'écran puisque c'est à l'échelle.
Aussi, le réseau est constellé de "points" équidistants (merci Pierre pour cette idée géniale) et, donc, à tout moment, je connais la longueur des trains (en points), je sais à quelle distance (en points) je suis du signal qui me commande l'arrêt. Avouez que c'est pratique.

Je sais qu'un train a perdu un wagon car sa longueur (la distance entre le point avant et le point arrière) est plus grande que la longueur initiale du train.
Evidemment, on ne perd pas de wagons sur un train virtuel !

Parce que, finalement, ce que je fais sur mes trains virtuels, on peut évidemment le faire sur les trains réels. Je m'explique :

-> Vous entrez dans une table la longueur de toutes les zones
-> Vous mesurez vos locos et wagons dans une autre table et vous indiquez lesquels vous choisissez lorsque vous posez un train sur le réseau.
-> Vous connaissez la position du train dans un canton car vous connaissez sa vitesse (Voir la vidéo de Renaud Yver et son réseau Luzy avec RRTC pour faire klaxonner un train juste avant un passage à niveau sans mettre d'ILS) et sur quelle zone il est.

Avec la position de l'avant du train et sa longueur, si un wagon reste planté, au bout d'un (court) moment, vous vous rendrez compte que le canton C-1 ne devrait pas être occupé : vous avez perdu un wagon.

J'ai donc un objet "train" qui enregistre tout ça. En particulier la liste des zones occupées, les longueurs, …
Remarque :
Il faut sauvegarder la composition des trains en cas de plantage complet, ainsi que la longueur des zones.

Identification :

Dans ma solution, un train est OBLIGATOIREMENT sur un "itinéraire" qui peut être réduit à un seul canton quand il est arrivé au bout de l'itinéraire.
Donc, quand on pose un train, c'est le seul qui n'est pas sur un itinéraire. Cela l'identifie.

Denis

[Dominique]

Tout ca c’est très intéressant et c’est bon de le savoir : ce sujet est une mine d’information.


Mais j’aime bien des choses faisables : par exemple pour connaître la longueur d’un train, il suffit de le faire traverser une zone de longueur connue et de connaître sa vitesse.

C’est ce que je fais sur une zone de parade. La distance est connue et le temps de traversée du train entre les 2 détecteurs de présence donne la vitesse. Ensuite le temps de présence dans la zone donne la longueur du train !

Ça me sert aussi à étalonner les vitesses des trains.

Simple et pratique

A chaque passage des trains le processus recommence et la perte d’un wagon se détecte 🚂🚉

Après. Il vaut mieux de bons attelages et éviter de perdre des wagons. C’est la qu’on s’aperçoit de la qualité des petits trains réels. En N ce n’est pas si simple !

Denis, combien de locos et de wagons réels as-tu ?