Projet partagé d'un gestionnaire de réseau

[DDEFF]

@ Pierre,

Dans ton post #411 du 05/05/24, tu soulèves l'intéressant problème du garage franc.

J'avoue qu'à la SNCF, je ne sais pas comment c'est géré électriquement.
La seule chose visible, c'est une marque blanche au sol (une traverse peinte en blanc, un bloc béton peint en blanc, …). Avec du personnel sur le terrain, c'est jouable. On voit si on dépasse ou pas.
Mais nos petits trains n'ont pas de personnel au sol…

Je propose donc de faire la coupure plus loin, suivant le schéma  :



Les véhicules dessinés sont à bogie car c'est ceux-là qui "dépassent" le plus.
J'entends par "dépassement" la distance entre le bogie côté tampon et le bout du tampon. En gros, 3 cm, à vue de nez.
Donc, on ne fait pas la coupure à l'extrémité de l'aiguille, mais 3 cm plus loin.

Ainsi, si le véhicule avance un peu, il se trouve électriquement sur la zone de l'aiguille et empêche la création d'un itinéraire sur l'autre voie ou empêchant la destruction de l'itinéraire si on ne va pas assez loin sur la zone hors aiguille.

Jusque-là, c'était évident.

Mais on ne peut pas raisonner ainsi si plusieurs aiguilles se suivent.
La dernière zone d'un itinéraire est à la fois occupée électriquement et occupée par l'itinéraire.
Lorsque le train avance, elle devient à la fois inoccupée électriquement et disparait de la liste des zones de l'itinéraire.

Ce que je propose, c'est d'agir en 2 temps :

La zone devient inoccupée électriquement, tout en restant occupée par l'itinéraire.
Elle ne quittera la liste des zones de l'itinéraire que quand on aura 2 zones d'appareils de voie consécutives inoccupées électriquement.
On a ainsi un décalage d'une aiguille entre l'occupation électrique et l'occupation par un itinéraire. Comme l'occupation par un itinéraire bloque la création d'un autre itinéraire utilisant cette aiguille, on a bien une distance supérieure à 3 cm tout le temps, même si on perd un wagon.

Denis

[Pierre59]

Voici une nouvelle version du gestionnaire expérimental json en C/C++. Beaucoup de bugs ont étés éliminés, mais il en reste encore. Comme la précédente version, cette version est prévue pour tourner sur un ORDINATEUR, elle fonctionne comme la version en Processing (Java) en utilisant un TCO en Processing pour faire les tests.

La version Processing et cette version C/C++ sont quasiment équivalentes, mais il y a quelques différences entre la version Processing et la version C/C++ (dans le but de préparer la version tournant sur Arduino), voici les changements de la version C/C++ :

- le transit souple n'est pas encore mis en oeuvre (il faut juste traduire le code de Java vers C/C++ et tester)

- des "bus" ont étés introduits, le gestionnaire communique avec le réseau, le TCO, les manettes, la centrale (box), … par un ou plusieurs "bus", ces bus peuvent êtres très variés : ethernet, wifi, I2C, USB/série, CAN, … . Pour l'instant les messages comportent tous trois octets et ne sont pas répétés (on peut envisager des codes de détection d'erreurs comme un CRC, voire un numéro de message).

Pour passer à une version Arduino il va falloir faire quelques adaptations :

- la bibliothèque json utilisée existe sur Arduino (c'est pour cela quelle a été choisie) on pourra supprimer l'onglet et utiliser un "include" à la place (le changement de bibliothèque a représenté le plus gros du travail pour passer de Processing à C/C++)

- remplacer les structures de données, genre "vector", par des versions adaptée à l'Arduino et faire attention à la gestion mémoire

- choisir le ou les bus et les implémenter

- régler les problèmes d'initialisation du gestionnaire comme il a été discuté dans le post n° #461 et les suivants de ce fil

- prévoir un moyen de dialogue avec le gestionnaire pour l'affichage de ses messages et l'obtention des informations sur les trains, voir aussi le post n° #461 à ce sujet

- choisir où mettre le "fichier" json, sur carte SD ou en mémoire RAM ou FLASH (PROGMEM)


Les fichiers joints sont tout à fait fonctionnels, mais assez difficiles à mettre en oeuvre, c'est juste une version avant de passer à l'Arduino.

Pierre

[Thierry33]

Bonjour,

J’ai presque tout lu, pas tout compris, mais très intéressé par le sujet.
Et puis pouf, 19 septembre 2024, plus rien.
Trop compliqué, peu d’intérêt, en cours de finition?

Thierry 33

[DDEFF]

Bonjour,

Et encore, tu es gentil, moi, je n'ai plus écrit depuis le 23 juillet...

Je n'ai pas abandonné, loin de là.
 
Depuis le mois d'août, j'ai développé, quand j'avais le temps, testé, re-testé, modifié, simplifié, dans le but de générer un fichier JSON et un TCO avec le minimum d'information au départ.
J'estime avoir passé 4 mois de temps plein sur ce programme depuis le mois d'août.
Aujourd'hui, j'ai encore supprimé un bug qui m'avait échappé.
Je préfère n'écrire que quand je n'en trouverais plus.
Après, il faudra qu'on se mette d'accord avec Pierre sur le contenu définitif du JSON qui deviendra le JSON Locoduino.

Pierre, de son côté, s'est occupé de "l'autre côté du JSON", c'est à dire du gestionnaire.

J'ai quasiment fini le topo qui présentera ça.

Pour faire patienter, voici le TCO que mon programme calcule tout seul à partir de, finalement, très peu d'infos demandées au modéliste.
En PJ :
1°) le TCO avec toutes la signalisation calculées en fonction du réseau
2°) le fichier de départ, celui qui recense la totalité des infos que le programme ne peut pas deviner (le nom des zones, des aiguilles, de la présence ou non d'un signal, ...) 6 Ko !
Pour info, il faut l'ouvrir avec Excel (ou un tableur), comme tout fichier .tsv (Tabulation Separated Variables)

Denis

[DDEFF]

POST DU 10/03/25 PARTIE 1/2

Bonjour à tous,

Je reprends le fil après 4 mois de travail. Mon programme est passé de la version 9 à la version 20 ! (et maintenant version 23)
De très nombreuses choses ont évolué et le JSON est complet, zones multiples comprises. C'est cette dernière fonction qui a été la plus complexe.
Il y a même un TCO à partir des éléments actuels. C’est nécessaire pour passer au gestionnaire.
C'est un TCO schématique, type TCO physique avec des boutons et on ne sera pas obligé de représenter tout le réseau à l’échelle, comme avec mon précédent TCO. On pourra mettre les éléments où on veut.
Mes recherches ont porté sur les infos minimales nécessaires pour décrire un réseau. Tout ce qu'un programme ne peut pas deviner seul. Pour le reste, c'est à lui de compléter…
Pour l’instant, ce qui fonctionne, c’est une description du réseau à partir de dessins schématiques et quelques infos demandées à l’utilisateur (le nom de la zone, de ses voisins, de la présence ou non de signaux, de ralentissements, de longueurs, …).
On rentre ces quelques infos, on appuie sur "Sauve" et le JSON est automatiquement créé !!

LEXIQUE :

En informatique, on doit être extrêmement précis dans les libellés et je vais commencer par un lexique, de difficulté croissante, pour qu’on soit sûrs qu’on parle tous de la même chose.
Et ça donnera aussi une idée de tout ce qu'on doit prendre en compte pour créer un gestionnaire.

ELEMENT :

Un élément, c'est ce qu'on achète dans le commerce : un rail, un aiguillage, …

ZONE :

Une zone, c'est le plus petit ensemble d'éléments avec une détection de présence par consommation de courant. Il y a 2 types de zones : les sections et les appareils de voie.

SECTION :

Une section est une zone composée uniquement des éléments suivants : rail droit, rail courbe, rail flexible.
La section est le seul type de zone à pouvoir posséder et gérer des signaux.
APPAREIL DE VOIE :
Un appareil de voie, c'est tout ce qui n'est pas dans une section : aiguillage, TJD, …
Un appareil de voie ne peut pas posséder de signaux.
Mais on verra dans les "zones multiples" une méthode pour leur en affecter quand même.
Les appareils de voie sont à la SNCF de 2 types : les traversées et les branchements.
Pour nommer un appareil de voie, on est libres, mais avec 2 contraintes :
Ne doit pas démarrer par "Br" ou "Su" (voir plus loin pourquoi).

TRAVERSEE :

A la SNCF, on appelle "traversée" ce que les modélistes appellent "croisement".
Et, ainsi, on comprend mieux pourquoi une TJS s'appelle "Traversée Jonction Simple" puisque composée d'une traversée et d'une jonction et la TJD, une "Traversée Jonction Double" puisque composée d'une traversé et de 2 jonctions.
Bien plus qu'un problème de vocabulaire, la traversée pose en gestion des trains des problèmes tout à fait spécifiques.
Je garderai donc le terme de "traversée" pour la suite pour désigner ces 3 éléments liés.
Il y a un cas particulier lié à la traversée simple.
Elle n'a aucun moteur, tout est fixe, mais il y a quand même 2 positions liées à l'alimentation des rails. Il y aura donc une position "gauche" et "droite", par analogie aux aiguilles.

BRANCHEMENT / AIGUILLAGE / AIGUILLE :

Le "branchement", c'est le terme SNCF pour ce que les modélistes appellent "aiguillage"
Je garderai le terme "aiguillage" ou "aiguille", ce qui ne pose pas de difficulté ici.
Une aiguille peut être prise "en pointe", c’est-à-dire que, dans ce cas, on peut lui affecter plusieurs directions ou "en talon" où il n'y a qu'une seule direction possible : vers la pointe.
Une aiguille a une position "gauche" ou "droite" dans le JSON et pour le gestionnaire. Cette position est indépendante du fait qu'il puisse y avoir une position "tout droit" ou "dévié".
Les termes "gauche" et "droite" sont universels, même dans des aiguilles symétriques, enroulées et même pour la traversée simple (voir ci-avant).
LAMES :
Les appareils de voie ont des éléments mobiles appelés "lames".
J'utiliserai ce terme pour designer les différentes positions des appareils de voie.
Une aiguille a "lames = 0" quand on va à la première position (en général "tout droit")
Une aiguille a "lames = 1" quand on va à la deuxième position (en général "dévié")
Sur le TCO, c'est la valeur de "lames" qui permettra de dessiner la position effective des lames de l'appareil de voies.
Pour une TJD, on aura 4 positions, de 0 à 4, pour une TJS, 3 positions, etc…

CANTON :

Un canton, c'est une ou plusieurs zones qui commencent et/ou terminent par un signal.
Il peut y avoir des cantons unidirectionnels qui n'ont qu'un signal à une extrémité et des cantons bidirectionnels avec un signal à chaque extrémité.
Il faut bien distinguer les zones et les cantons. Ils ne sont pas du tout synonymes.
Par exemple, une aiguille peut être une zone, avec sa détection de présence spécifique, mais ne peut pas être un canton car il n'y a pas de signal.
Un canton peut être constitué de 3 zones. L'inverse n'a pas de sens.
L'ambiguïté vient du fait que, très souvent, on explique le cantonnement par un exemple en pleine voie où le canton n'a qu'une zone.

CANTONNEMENT :

Le cantonnement est un système de gestion des trains qui permet l'espacement de 2 trains qui se suivent de façon à leur éviter un rattrapage ou une "prise en écharpe" (2 trains arrivant en talon simultanément sur chaque branche d'une aiguille).
Un système de signalisation complexe à respecter scrupuleusement pour éviter tout problème.

ZONE SIMPLE :

C'est ce que vous aurez à décrire dans ce programme. Soit une section, soit un appareil de voie.
Le nom d'une zone simple peut être quelconque, à une exception près : il ne doit pas comporter de "/", caractéristique des zones multiples (voir plus loin).

PARITE :

La parité est une donnée intrinsèque de la zone.
Quand on trace un trait sur une feuille, il y a une origine et une extrémité.
Dans mon programme, l'origine s'appelle "A" et l'extrémité "B".
Pour une section, le côté pair est du côté "A" et le côté impair du côté "B".
Pour une aiguille, le côté pair est du côté "A" (la pointe) et les côtés impairs les côtés "B", "C", "D" (les talons).
Pour une traversée, les côtés "A" et "C" sont du côté pair et "B" et "D" les côtés impairs.
Pour une section, il y a toujours une parité : c'est la direction principale de déplacement lorsque la section peut être parcourue dans les 2 sens.
A noter que, pour une section unidirectionnelle, le signal éventuel sera toujours côté "B".
La parité permet de définir des voisins pairs et des voisins impairs.

VOISINS PAIRS / IMPAIRS :

Cette caractéristique a été proposée par Pierre au début de ce fil et elle est d'une puissance que je n'imaginais pas au départ. C'est vraiment une excellente idée.

CONNECTEUR :

Un connecteur est l'unique point commun entre 2 zones voisines.
Je les utilise dans la recherche des itinéraires. Mais Pierre a dit qu'on n'en avait pas besoin et, au début, ça m'a rendu perplexe, tant ils me paraissaient nécessaires.
Puis j'ai remarqué qu'on pouvait effectivement s'en passer grâce à la puissance de la notion de voisins. Quand j'en serai à la phase optimisation, je reverrais ma recherche d'itinéraires en utilisant les voisins.
La recherche d'itinéraires étant la partie la plus complexe de mon programme, je démarrerai prudemment…
En développant le TCO (voir plus loin), j'ai, à nouveau eu besoin des connecteurs pour localiser les coupures de rail. C'est donc plus compliqué que prévu de s'en passer.

ZONE MULTIPLE :

C'est un ensemble de zones simples dont le nom comporte un "/".
Exemple : 3 zones simples "Z1/0", "Z1/1" et "Z1/3" deviendront la zone multiple "Z1".
Le côté pair d'une zone multiple est le côté de "/0" ("Z1/0" dans l'exemple précédent).
On peut mélanger des sections et des appareils de voie, sans limite.
En ajoutant une section de longueur nulle à un appareil de voie, on peut ajouter un signal à un appareil de voie dans la zone multiple ainsi créée.
Mais il doit exister une caractéristique essentielle dans une zone multiple : un pivot unique.

PIVOT :

C'est un point réel ou virtuel unique qui sépare en deux une zone multiple.
Une zone multiple peut être vue comme une étoile, avec le pivot en son centre.
La zone multiple a des voisins pairs et des voisins impairs.
Il doit n'y avoir qu'un seul chemin entre un voisin pair et le pivot.
Il doit n'y avoir qu'un seul chemin entre un voisin impair et le pivot.
Le pivot est le point de passage obligé entre un voisin pair et un voisin impair.
Quand il y a une traversée dans une zone multiple, le pivot est virtuel et est en son centre.
Quand il n'y a pas de traversée, le pivot est réel (c'est un connecteur) et se trouve là où 2 aiguilles se touchent par leurs pointes (à une section intermédiaire près).

ITINERAIRE :

C'est la ou les façons de transiter d'une section à une autre section.
Un itinéraire démarre et finit obligatoirement par une section parce qu'il va d'un signal à un autre signal.
A la SNCF, les itinéraires sont gérés par des postes d'aiguillages.
Un poste d'aiguillage a une zone d'action qui lui est propre dans laquelle il gère tous les appareils de voie, les occupations et la signalisation.
Une gare peut avoir plusieurs postes d'aiguillages si elle est très grande.
Et donc plusieurs gestions d'itinéraires possibles pour une seule gare.
Mais l'inverse peut être vrai aussi.
Un poste d'aiguillage peut aussi gérer plusieurs petites gares.
Par exemple, à Reims, on a longtemps géré, en conduite centralisée, les 7 gares entre Reims et Epernay en voie unique sur 23 km.
Cette caractéristique m'a incité à étendre la gestion d'itinéraire à tout le réseau. C'est un choix.
Mon programme calcule tous les itinéraires possibles d'un réseau. C'est nécessaire pour la définition automatique des zones multiples. Il sort même la liste dans un fichier.
A part en développement, afficher ce fichier n'a qu'un intérêt anecdotique.
On doit pouvoir enregistrer les itinéraires, même si, au moment de l'enregistrement, ils ne sont pas réalisables. C'est le déplacement des trains qui, en libérant des zones, permettra alors de débloquer les itinéraires automatiquement.
Pour moi, l'itinéraire, c'est bien plus que le simple fait de faire bouger plusieurs appareils de voie avec un seul bouton. Il y a, en plus de la gestion des occupations, des priorités, des enregistrements, …
Les itinéraires sont très rapides à calculer. Je propose de les faire "à la volée" dans le gestionnaire plutôt que de prendre de la place dans le JSON.

ZONE DE GARE :
 
La définition des zones de gare est du ressort de l'utilisateur, aidé par le programme.
Il faut définit les zones d'approche, les zones de sortie et au moins une zone dans la gare. Le programme se charge d'attribuer la caractéristique de "gare" aux zones intermédiaires.
Dans le cas d'une grande gare, c'est appréciable de ne pas avoir à spécifier "fait partie de la gare" à toutes les zones.
En particulier, il existe des zones d'approche, des zones de gare et des zones de sortie.

ZONE D'APPROCHE :

Ce sont les zones par les quelles débutent les itinéraires allant vers la gare. Elles sont caractérisées par un signal carré en allant vers la gare, jusqu'à ce que l'aiguilleur donne un itinéraire.

ZONE DE SORTIE :

C'est la dernière zone d'un itinéraire.

ENCLENCHEMENT :

C'est la partie la plus complexe de la gestion des itinéraires.
Quand un itinéraire est enclenché, on ne peut plus le modifier d'une part et, d'autre part, tous les itinéraires avec lesquels il est incompatible ne sont plus réalisables.
La présence dans la zone d'approche est la méthode la plus basique de la gestion des enclenchements. Mais il y en a d'autres, qu'on verra quand on en sera à la gestion des trains.
Evidemment, l'enclenchement se termine quand on quitte la zone de sortie.

ZONE DE MANŒUVRES :

La définition des zones de manœuvres est du ressort de l'utilisateur, aidé par le programme.
Il faut définit les zones d'approche, les zones de sortie et au moins une zone dans la zone de manœuvres. Le programme se charge d'attribuer la caractéristique de "manœuvre" au zones intermédiaires. Dans le cas d'une grande zone de manœuvres, c'est appréciable de ne pas avoir à spécifier "fait partie de la zone de manœuvres" à toutes les zones.
Dans la réalité (et surtout aux débuts de la SNCF), il n'y avait quasiment aucun signal dans une zone de manœuvres, la sécurité était assurée par des hommes et une vitesse limitée à 15 km/h.
Dans un réseau miniature, il n'y a pas d'hommes pour faire la sécurité et encore moins des mécaniciens qui marchent "à vue".
La zone de manœuvres sera donc gérée comme le reste, avec des zones toutes bidirectionnelles et des feux virtuels et quelques-uns réels (des carrés violets).
Les carrés violets apparaitront au TCO et, pour les carrés violets virtuels, il y aura simplement un cercle vide indiquant leur emplacement. La vitesse est limitée à 15 km/h et les feux sont seulement des carrés violets.

TRANSIT SOUPLE :

On part d'un constat simple : plus les zones sont courtes, plus elles sont libérées rapidement et plus elles peuvent être affectées à un autre train avec un délai minimal.
Cela favorise la fluidité du trafic.
Mais cela suppose plus de zones, plus de câblage et, évidemment, un coût beaucoup plus élevé. Il faudra donc faire une analyse du réseau et optimiser le nombre de zones (via les zones multiples) et la densité du trafic. Il y a un équilibre à trouver.
Les premiers postes à relais ont été les PRA (Postes tous Relais à destruction Automatique) en 1939 au poste 5 d'Argenteuil. Le principe est qu'un itinéraire est détruit automatiquement quand le train a franchi le tout dernier appareil de voie. C'est presque toujours ce genre de fonctionnement sur les réseaux miniatures.
Puis sont venus les PRS (Postes tous Relais à transit Souple) en 1950 à Gagny-Montereau.
Au lieu d'attendre que tout l'itinéraire soit franchi, on libère les aiguillages au fur et à mesure de l'avancée du train. On perd ainsi beaucoup moins de temps et on peut faire passer plus de trains sur le même grill de voies. C'est plus fluide.
Puis vinrent les PRG (Postes tous Relais Géographiques) en 1971 à Montargis.
Identiques aux PRS dans le transit souple, mais on n'a plus de bouton d'itinéraire : on choisit un point d'entrée et un point de sortie. Ce sera le type d'itinéraires de mon futur gestionnaire.
Le PRG a pour lui d'avoir besoin de moins de boutons : un bouton par voie d'entrée ou sortie au lieu d'un bouton par itinéraire.
A noter que cette idée de commande géographique date de 1909 (Poste Descubes de Nancy) en choisissant d'abord la sortie puis l'entrée. Bien avant les relais…

SIGNALISATION :

Mon programme gère la signalisation lumineuse de type BAL (voir plus loin).
On a juste à définir l'emplacement des feux sur les sections et le programme calcule tous les feux affichables pour un signal donné. Là aussi, le fait d'avoir calculé tous les itinéraires possibles était nécessaire.
En regardant simplement le JSON, on saura combien de signaux il faut acheter et quel devra être leur type (Panneau A à panneau H), y compris les feux vers les voies de manœuvres au sol.


 
BAL :

Block Automatique Lumineux.
C'est un système de gestion SNCF basé sur des cantons, avec une signalisation lumineuse permettant d'assurer la sécurité du réseau.

MOTEURS :

Par la suite, j'appellerai "moteur" tout système permettant de changer la position des aiguilles. Il peut s'agir de solénoïdes, de servos ou de moteurs à mouvement lent.
A ce sujet, une traversée simple aura un "moteur virtuel" pour identifier les deux possibilités de traverser l'appareil de voie. C'est obligatoire pour gérer l'alimentation des voies de la traversée.
Les TJS et TJD seront considérées comme deux aiguilles tête-bêche par leurs pointes et, donc, auront 2 moteurs.
Mais j'ai aussi considéré le cas de Märklin qui, pour ses TJD, n'utilise qu'un seul moteur et un astucieux système de renvois.




Les aiguilles triples ont, eux aussi 2 moteurs, même chez Märklin, et il existe des aiguilles triples dites "symétriques" où le dessin semble symétrique, mais, en fait ne l'est pas vis-à-vis des moteurs. Il y aura donc un moteur plus "en avant" que l'autre, d'où des aiguilles triples gauche ou droite.

Suite dans le post suivant

[DDEFF]

POST DU 10/03/25 PARTIE 2/2

BRETELLES :

Les appareils de voie sont commandés par de moteurs, mais, dans certaines configurations, la position d'une aiguille entraîne obligatoirement la position d'une autre aiguille sous peine de déraillement. Ce sont les bretelles. Elles permettent donc des gains en câblage et en sécurité.
Exemple de bretelle :



Contrairement aux apparences, le problème de les détecter automatiquement n'est pas simple.
Les aiguilles, dans une bretelle, sont opposées par leurs talons. C'est obligatoire.
Souvent, elles sont reliées par leurs voies déviées, comme dans l'exemple ci-dessus, mais elles peuvent aussi être voie directe - voie déviée, avec une aiguille droite et une aiguille gauche :



On peut aussi avoir un élément droit dans la bretelle :



Et c'est là qu'on apprécie les joies de l'informatique…
On cherche : "Des aiguilles, opposées par leurs talons, avec la possibilité d'une aiguille droite et d'une aiguille gauche et possibilité d'éléments droits ou courbes entre les talons des aiguilles".
Et on tombe sur ça :


 
Qui est tout, … sauf une bretelle !
Il manque donc un autre paramètre : la longueur des éléments, indispensable ici !

C'est pareil pour une bretelle double.
Il y a tout un monde entre ça :


 
Et ça :


 
Et pourtant, le schéma est le même !
Donc, il faut tenir compte des longueurs dans la détermination automatique des bretelles.
Il y a donc, dans mon programme, une longueur maxi (L_MAXI dans le setup) qui permet de bien définir les bretelles.
A noter que le branchement simple est le seul appareil de voie possible dans une bretelle pour la bonne raison qu'il n'a pas de moteur (cas de la bretelle double).
Dans une bretelle, il ne peut y avoir que 2 aiguilles.
Il s'ensuit que les appareils impliqués sont : les aiguilles, l'une des aiguilles d'une TJS, l'une des aiguilles d'une TJD à 2 moteurs, une aiguille triple.
Il n'est pas possible d'avoir une TJD à un seul moteur dans une bretelle.
Une bretelle, c'est le plus simple des super appareils (voir ci-après).

SUPER APPAREIL :

On a diminué le nombre de zones en créant des zones multiples.
On peut aussi diminuer le nombre de positions à étudier en regroupant les moteurs des appareils de voie des bretelles.

1°) Les bretelles simples :

Deux aiguilles, c'est 2 x 2 positions possibles. Mais comme les deux aiguilles sont liées, il n'y a que 2 positions à étudier : la position "bretelle" et la position "non-bretelle".
On n'a plus qu'un seul super appareil, composé des 2 aiguilles, et seulement 2 positions pour ce super appareil.
On remarquera que, dans une bretelle simple, les deux aiguilles sont dans la même position.


           
Ex : a0 droite et a1 droite pour la bretelle, a0 gauche et a1 gauche pour les voies parallèles, c’est-à-dire "non bretelle".
Donc, la définition d'une bretelle peut se simplifier :
"Br0" : a0, a1, droite.
La position "non-bretelle" peut s'écrire "Br0-" sans qu'on ait besoin de la décrire dans le JSON (Ce serait Br0- : a0, a1, gauche).
Dernière remarque :
Il n'est pas besoin de décrire une section qui serait entre les 2 aiguilles (une section n'a qu'une position)

2°) Les bretelles doubles :


 
Dans une bretelle double, il y a 5 appareils de voie. On n'oublie pas, en effet, la traversée centrale composée d'une "aiguille virtuelle", amenant 2 alimentations potentielles, elles bien réelles, en fonction de la bretelle choisie. Soit 32 positions potentielles et seulement 3 positions possibles.
Br0 : a0, a3, droite, a4
Br1 : a1, a2, gauche, a4
La description de la bretelle reste la même que la bretelle simple, mais, ici, on indique aussi la traversée simple en fin de description, sans donner sa position puisqu'elle est identique à celle des aiguilles.
Les 3 positions sont les suivantes :
- position 0 : Br0, Br1-, a4
- position 1 : Br0-, Br1, a4
- position 2 : Br0-, Br1-
En position 1, a4 est à droite par Br0 et à "non-gauche" = droite par Br1- : il est donc à droite.
En position 2, a4 est à "non droite" = gauche par Br0- et à gauche par Br1- : il est donc à gauche.
En position 3, a4 n'est pas concerné.
 

 
Mais attention, super appareil ne veut pas dire une seule zone : la bretelle double ci-dessus a bien 7 zones de détection de présence.

3°) Aiguilles triples. Exemple dans le réseau de Dominique :


 
Z29 est une aiguille triple, décomposée ici en 2 aiguilles consécutives : a9 et a11.
Dans la pratique, il y a 3 aiguilles à gérer ici, soit, à priori 2 x 2 x 2 = 8 possibilités.
Il y a bien une bretelle Br0 : a8, a11, gauche, mais elle ne fonctionne que si a9 est à gauche.
Donc il n'y a que 3 positions qui aient un sens :
- Position 0 : Br0, a9 gauche.
- Position 1 : Br0-, a9 gauche
- Position 2 : Br0-, a9 droite.
Il peut paraître surprenant, quand a9 est à droite, que la position de la bretelle intervienne, mais c'est nécessaire à la sécurité : si a9 est à droite, on ne peut pas envoyer un train venant de a8 vers la bretelle.
Autre exemple, dans le réseau de Dominique complété pour essais :


 
Z26 est une aiguille triple, décomposée ici en 2 aiguilles consécutives : a0 et a1.
Br0 : a0, a2, droite
Br1 : a1, a51/0, gauche
Les 3 positions sont :
- Position 0 : Br0, Br1-
- Position 1 : Br1, Br0-
- Position 2 : Br0-, Br1-

4°) Toujours dans le réseau de Dominique, une bretelle avec aiguille commune. Ici a16.


 
Il y a 3 aiguilles, donc 8 positions et, en fait, seulement 2 utiles :
- Position 0 : Br0, Br1-
- Position 1 : Br1, Br0-
On a la liste exhaustive de tous les super appareils possibles :
Bretelle, bretelle double, triple 1 et triple 2, aiguille commune.

LISTES D'APPAREILS DE VOIE :

C'est le moment de faire le point sur les différentes listes consacrées aux appareils de voie.

1°) On a une liste de tous les appareils de voie :
            "a0" : {
                    "nom" : "a0",
                    "type" : "TripleSDa",
                    "no" : 0
            },
Qui se lit : l'appareil a pour nom "a0", il est du type "aiguille triple symétrique à droite côté A", c'est le 1er appareil de la liste des appareils et a pour identifiant le numéro 0.

Rappel 1 : Une aiguille triple a sa première aiguille en partant de la pointe à droite et la suivante à gauche dans le cas d'une "TripleD" et sa première aiguille en partant de la pointe à gauche et sa suivante à droite dans le cas d'une "TripleG".
Si, en plus, elle est d'apparence symétrique, il y aura TripleSD et TripleSG.
La 1ere aiguille est côté A et la deuxième côté B.

Rappel 2 : Une aiguille ayant toujours 2 positions ("gauche" et "droite"), ce n'est pas la peine de l'indiquer dans le JSON.

2°) Une liste des bretelles :
            "Br0" : {
                    "nom" : "Br0",
                    "position" : ["a0","a2","droite"],
                    "no" : 0
            },
Qui se lit : Bretelle 0, position a0 et a2 à gauche, identifiant numéro 0.
L'autre position n'est pas décrite et s'appellera "Br0-".
Là, les positions sont décrites car spécifiques au réseau. On voit aussi pourquoi le nom d'une aiguille ne doit pas démarrer par "Br".

3°) Une liste des super appareils :
            "Su0" : {
                    "nom" : "Su0",
                    "positions" :  [["Br0", "Br1-"], ["Br0-", "Br1"], ["Br0-", "Br1-"]],
                    "no" : 0
            },
Là, les positions sont décrites car spécifiques au réseau. On voit aussi pourquoi le nom d'une aiguille ne doit pas démarrer par "Su".
 
BALISE :

On a considéré que la détection de présence dans une zone se fait par consommation de courant. C'est le système le plus performant. Mais il suppose de nombreuses coupures de rails.
Il existe aussi des détections de présence ponctuelles (ILS, infra rouge, capteurs à effet Hall…) et on les appellera des balises.
Mon programme ajoute systématiquement une balise (notée Bs) à chaque signal. Ce système sert pour garantir un arrêt devant un signal à un point précis.
Le programme ajoute aussi systématiquement une balise (notée Bb) avant un butoir pour garantir l'arrêt.
Je n'ai pas géré le cas de balises isolées (passage à niveaux, tunnels, panneaux "S", …), mais on pourrait définir une méthode pour en ajouter.

LONGUEURS :

Il est indispensable de connaitre la longueur de chaque zone. Par défaut, la longueur d'une zone sera de 999 mm dans mon programme.
Par ailleurs, il faut que des sections de longueur nulle existent pour "affecter" un signal à un appareil de voie.
De plus, certains signaux (jaune clignotant, rouge clignotant, blanc clignotant) sont liés à la longueur de la zone.
Enfin, dans le gestionnaire, j'aurais besoin de longueur précises les sections et branches des appareils de voies pour calculer la distance qui sépare un train de son signal d'arrêt. J'y reviendrai dans le gestionnaire, c'est fondamental.

FICHIERS :

Pour l'instant, dans Processing, tous mes fichiers sont issus de "Tables" et sont donc des fichiers dont l'extension est obligatoirement ".tsv", c’est-à-dire "Tabulation Separated Values" (valeurs séparées par une tabulation) qui se trouve être le fichier natif des fichiers Excel.
Il s'ensuit que le meilleur moyen d'ouvrir ces fichiers texte est l'application Excel (ou tout autre tableur).
La conséquence, c'est que le fichier JSON sort actuellement en "_JSON________.tsv".
Si on veut un vrai fichier JSON, il suffit de le copier ailleurs et de changer l'extension ".tsv" en ".json" et on obtient le fichier "_JSON________.json".
Le fichier JSON est, ici, un fichier de sortie et le fichier ZONES est le fichier d'entrée. Il ne contient que les informations que le programme ne peut pas deviner.
Le fichier ZONES, quant à lui contient exclusivement les valeurs nécessaires au calcul du fichier JSON. Il n'y a que des valeurs que vous rentrez. Tout le reste est calculé.
Il est fortement déconseillé de modifier des valeurs directement dans le fichier ZONES, tant elles sont liées les unes aux autres. En passant par le programme, tous les liens sont pris en compte et la cohésion est garantie.

Variables du fichier ZONES :
NOM :
Le nom de la zone simple.
PARITE :
La parité de la section, avec une aide dans le programme.
TYPE :
Numérotés de 0 à 11


 
ORIENTATION :

L'orientation est la position du dessin d'une section ou d'un appareil de voie par rapport à la verticale dans un pavé. La "précision" de cette orientation est de 45°. Elle est caractérisée par un nombre entre 0 et 7 dans le fichier zones.

GARE :

L'info de la gare. On a :
g0, g1, … qui sont les zones de gare (on n'en rentre qu'une partie)
ap_g0, ap_g1, … qui sont les zones d'approche des zones de gare (on les rentre toutes)
so_g0, so_g1, … qui sont les zones de sortie des zones de gare (on les rentre toutes)

MANŒUVRE :

L'info de la zone de manœuvres.
m0, m1, … qui sont les zones de manœuvre (on n'en rentre qu'une partie)
ap_m0, ap_m1, … qui sont les zones d'approche des zones de manœuvre (on les rentre toutes)
so_m0, so_m1, … qui sont les zones de sortie des zones de manœuvre (on les rentre toutes)

VITESSES :

L'info de la vitesse limite d'une zone ou, dans un appareil de voie, d'un segment de l'appareil.
X, Y :
Ce sont les coordonnées du centre du "pavé" sur le TCO. Un pavé n'a pas d'orientation. Il est calé sur une grille.
Les X, Y ne sont pas demandés lors de la création des zones simples :
C'est uniquement lors de modifications, c’est-à-dire dans une deuxième étape.

TCO :

A la SNCF, c'est le "Tableau de Contrôle Optique". Il est, en général, le long d'un mur dans le poste d'aiguillage et représente le tracé de toutes les zones gérées par ce poste d'aiguillage, avec l'occupation par les trains, la position des aiguilles, des itinéraires, ...
C'est purement visuel. Il n'y a pas de boutons sur un TCO à la SNCF.

Les modélistes se sont dit qu'il serait pratique, justement, d'y regrouper tous les boutons et le TCO est devenu le "Tableau de Commande Optique".

Tableau de Commande Optique (TCO)

C'était tentant du fait qu'on a déjà le dessin de tous les éléments…
Mais je n'avais pas envie de le dessiner : c'est le programme qui va se charger de le faire.
On doit quand même positionner les éléments (X, Y) et, le plus simple, c'est de rentrer les noms des zones dans Excel. C'est très souple, on peut déplacer plusieurs éléments d'un coup et avoir un positionnement global satisfaisant. C'est plus simple de se mettre en notation "L1C1" plutôt qu'en ABCD. Attention : Excel démarre à 1 et Processing à 0…
On note le nombre de cellules en horizontal et en vertical. En général, le nombre en horizontal est supérieur au nombre en vertical. C'est celui-là qui compte.
On rentre le nombre de colonnes d'Excel dans le setup "NB_PAVES = xx"
Une fois qu'on a rentré tous les X, Y dans les zones, on peut afficher le TCO.

1°) On appuie sur le bouton "Analyse" pour faire tous les calculs et on est ainsi sûr qu'il n'y a pas d'erreur. Si on oublie d'appuyer sur "Analyse" avant, on n'a pas les calculs des portions intermédiaires…

2°) On appuie sur le bouton "TCO" et on a un "paté" du TCO, coincé dans un carré de 500 x 500.
Il faut alors passer au plein écran et le TCO apparait.
On se rend compte alors que certains positionnements ne sont pas bons et on peut alors les modifier directement sur l'écran en cliquant dans les pavés des zones.
Si vous cliquez à gauche dans un pavé, il avance d'une case vers la gauche et le dessin se met à jour. De même pour droite, haut et bas. Et le dessin se recalcule immédiatement !
Quand vous êtes satisfaits du résultat, n'oubliez pas de sauver les X, Y :
1°) Cliquez sur "Valider" dans le rond en bas à droite
2°) Choisissez "Sauver" dans le menu général.

Composition du TCO :

Ce TCO est volontairement orienté vers la vérification des données, plus que vers un gestionnaire.
Par exemple, il n'affiche pas la position des appareils de voie (les lames).
Il affiche des panneaux de signaux complets avec tous les feux allumés en même temps …
Il y a un code couleur des zones :
Noir pour les gares
Violet pour les zones de manœuvres
Noir large sur Aqua pour les zones d'approche de gare
Noir étroit sur Aqua pour les zones de sortie de gare
Violet large sur Aqua pour les zones d'approche de manœuvres ou Violet large sur Noir si on est en gare.
Ce code couleur n'est utile que pour les vérifications et n'aura pas d'intérêt dans le gestionnaire.

Signaux :

Une particularité des panneaux de signaux SNCF est qu'il est impossible d'avoir, sur le même panneau, à la fois l'affichage du Carré et du Carré violet (les feux sont au même endroit).
J'ai donc décidé que, si l'on doit pouvoir afficher C et Cv au même endroit, il faut deux feux : un sur poteau et un au sol pour le Cv.
Dans les zones de manœuvres, j'ai décidé de faire figurer tous les feux, puisque chaque zone est banalisée. Mais les feux virtuels sont simplement affichés par un rond vide.
J'aimerais bien faire figurer ici les vitesses limites, toujours dans un but de vérification des entrées, mais il n'y a pas beaucoup de place…

Impression :

Il suffit de faire une copie-écran et l'imprimer. Mais comme j'ai pitié des cartouches d'imprimante, on peut mettre un fond blanc avant de faire la copie-écran en appuyant sur la bascule "Fond", en bas à gauche.

[Dominique]

Bravo Denis,

Très gros travail de présentation de toutes les sortes d'éléments d'un réseau, rassemblés dans un grand texte complet qui les rassemble, ce qui évite de chercher.

De retour la semaine prochaine, je me penche sur ton programme.. a bientôt

[Pierre59]

bonjour

Joli travail pour le lexique.
Mais il me semble qu'il manque un mot essentiel : ENCLENCHEMENT.

Le problème de prise en écharpe c'est du ressort des enclenchements et pas du cantonnement.
Les itinéraires sont aussi en grande partie du ressort des enclenchements.

Je reviendrais sur d'autres points, mais faut que je regarde les programmes avant.

Bon courage.

Pierre

[DDEFF]

Bonjour Pierre,

Tu as raison, il faut détailler les enclenchements. D'autant que je parle des zones d'approche et des itinéraires.
C'est un sujet fondamental, régulièrement oublié quand on résume les itinéraires à une liste d'aiguilles qui se mettent en mouvement quand on appuie sur un bouton.

Merci pour tes encouragements.

Denis

[DDEFF]

Bonjour,

J'ai remis à jour le lexique (zones d'approche, de sortie, enclenchements et TCO).

La partie TCO de mon programme doit être remaniée. J'y ai ajouté les coupures de rails et je vais déplacer les signaux à leur proximité.
Et, surtout revoir la manière de travailler en gérant, à nouveau, des connecteurs (X, Y, orientation, ...).
C'est vraiment dur de s'en passer ...

Denis

[DDEFF]

Bonjour à tous,

Mais pourquoi donc ai-je réalisé ce programme ?

C'est vrai qu'on pourrait se poser la question à une époque où il y a des IA qui génèrent automatiquement un fichier JSON à partir de données.

Pourquoi un fichier au format JSON ?

C'est un format moderne qui permet de ranger des informations dans une structure claire, en identifiant bien les objets. En plus, il est géré nativement dans Processing, ce qui ne gâche rien.

Le choix du format JSON étant fait, pourquoi se casser la tête avec un programme de plus de 10 000 lignes, avec plus de 1 000 "if" et près de 500 "case" ??
Parce que, si la rédaction d'un fichier au format JSON quand on a déjà les infos est automatisable par IA, le calcul de toutes les infos l'est beaucoup moins.

Il faut se rendre compte que mon fichier JSON contient 90 % d'infos calculées, pour 10 % d'infos directes !
Par exemple, je dis qu'une zone s'appelle "Z25" et qu'elle "a un signal côté B".
Dans le JSON, on saura ça :
------------------------------------------------------------------
zone Z25 signal cote A : panneau -, signaux = -
zone Z25 signal cote B : panneau Cv sol, G, signaux = C1 : A, VL, RR30, (Z26 lames2), RR60, (Z26 lames1),  R30, (Z28), C, Cv, M,  Bs19
1°) Il n'y a pas de signal côté A (ça, ce n'est pas dur)
2°) Du côté B, il y a un signal sur un panneau "G", avec un signal au sol qui affiche "Carré violet" et "Manœuvres" et, sur le panneau, qui s'appelle "C1", les signaux "Avertissement", "Voie Libre", "Rappel de Ralentissement à 30 km/h" quand l'aiguille de la zone Z26 a les lames en position 2, "Rappel de Ralentissement à 60 km/h" quand l'aiguille de la zone Z26 a les lames en position 1, "Ralentissement à 30 km/h" si vous allez vers la zone Z28, le "Carré" et que la balise qui concerne ce signal a le numéro 19.

Au passage, ça vous dit quels panneaux acheter pour votre réseau et comment brancher vos moteurs d'aiguilles pour économiser les boutons (bretelles détectées automatiquement, "super appareils" pour regrouper les moteurs)

Et, "accessoirement", on dessine un TCO dans la foulée…

Et, tout ça sans à priori sur le réseau qui peut être de n'importe quelle taille et composé de n'importe quels éléments.

Denis

[Pierre59]

Bonjour

Bonnes questions sur ce que l'on fait, c'est nécessaire de temps en temps.

Mais ton programme est trop gros parce que tu n'utilise pas vraiment la Programmation objet. Je peut d'aider comme je l'ai déjà fait.

L'IA peut peut-être nous aider

Amicalement

Pierre

[DDEFF]

Bonjour à tous,

PARENTHESE...

Je viens d'aller voir ce que j'avais écrit sur mon éditeur de réseau (dessinez votre réseau (le système de Denis)) et mon gestionnaire (gérez votre réseau (le système de Denis)) et il ne reste quasi rien de mes fils. Le piratage est passé par là...
J'étais surpris que plus personne ne me pose de questions : j'ai la réponse 

De toutes façons, Ces deux fils servaient surtout à voir la faisabilité de réaliser un TCO facilement sous Processing et de faire un gestionnaire complet, également sous Processing. Il y avait de jolis trains virtuels et il restait à relier ça à un bus CAN pour qu'on passe aux trains réels.

Je vais les ressusciter ici, d'une part parce qu'il y avait quand même pas mal de bonnes idées et, d'autre part, parce que le gestionnaire était fonctionnel. Toutes les questions que je m'étais posées restent tout à fait d'actualité.

Le gestionnaire que je vais écrire, à la suite de la création du JSON sera, bien évidemment, fortement inspiré de mon ancien gestionnaire, sans trains virtuels.

J'ai, aussi, sous le coude un éditeur de TCO parfaitement à l'échelle (genre CDM rails, mais plus développé), mais il est pour l'instant encore avec des bugs. On verra plus tard.

FIN DE LA PARENTHESE

Denis

PS : merci d'avance à Pierre pour son aide 

[Dominique]

Bizarre, je pense qu’on n’a rien supprimé. On va voir.

[DDEFF]

Bonjour à tous,

Voici la dernière version de mon éditeur JSON, version 21.

Après avoir corrigé quelques bugs, j'ai bien développé le TCO, en 2 versions :

1°) Version de vérification avec toutes les infos (nom des signaux, gare, manœuvre)
2°) La version gestionnaire, plus sobre, qui tient compte des zones multiples (en gris) et qui affiche la première position des lames pour les appareils de voie.

Le programme est effectivement énorme.

C'est en faisant le gestionnaire que je vais essayer de m'approprier des techniques de programmation objet nettement plus efficaces et que j'utiliserai les fonctions JSON de Processing.
Pour l'instant, je faisais tout "à la main" parce que je voulais définir toutes les infos nécessaires et dessiner un TCO. Maintenant que c'est fait, que je vois vraiment où j'en suis, je vais utiliser des techniques nouvelles.
 
Mais j'aurais un cahier des charges complet.

Les puristes vont me dire : "Mais il fallait commencer par là". C'est vrai…

Denis