Projet partagé d'un gestionnaire de réseau

[DDEFF]

Je pense qu'il faut faire les choses dans l'ordre.

Pour l'instant, on se cadre sur la description du réseau. On n'en est pas encore à la signalisation.
On a juste mis des signaux pour le schéma et pour savoir quel type de signal il fallait et où il fallait en mettre.
On fait une première description du réseau, ne serait-ce que pour savoir si on la rentre sous forme de texte brut ou de texte un peu plus structuré (JSON)
Après, il faudra faire circuler UN train pour voir comment les infos circulent dans le bus CAN (localisation, retour vers le gestionnaire, gestionnaire centralisé ou décentralisé ...)

Il est évident qu'il faudra d'autres infos dans le JSON de la description du réseau, liées à la vitesse maxi, par exemple.

Dernière remarque : on a volontairement écarté la zone de manœuvre dans le Locoduinodrome. Ça ne veut pas dire qu'on n'en parlera jamais, mais pas pour l'instant.
Je pense que la gestion de la zone de manœuvre sera très simple une fois que le système général fonctionnera.

Denis

[DDEFF]

On était parti dans la définition de certains termes.

Je propose qu'on indique dans le cahier des charges qu'on a une signalisation type BAL (Bloc Automatique Lumineux).
Il existe à la SNCF de nombreux types de blocs correspondant à différents types de situations. Mais on se limitera ici au BAL qui est le plus utilisé aujourd'hui.

[Pierre59]

Bonjour

Bon j'en ai plus qu'assez de cette guéguerre entre cantons et zones qui pollue complètement ce fil. Je propose la solution suivante, on parle de gestionnaires basés sur des cantons dans le fil de Christophe et de gestionnaires basés sur des zones dans ce fil.

Ce qui veut dire que dans ce fil on ne parle plus (ou presque plus de cantons) mais cela viendra comme pour les itinéraires.

Qu'en pensez vous.

Pour les indécis allez trainer dans une gare pour voir comment sont réellement découpées les voies.

Pierre

[bobyAndCo]

Sans apporter plus d'argumentation, alors ce sera sans moi et je vais effectivement me concentrer sur mon projet.

Bonne chance à vous et l'on se retrouve quand les projets respectifs seront bouclés.

Christophe

[Dominique]

N'y a t'il personne sur ce fil pour faire un peu de modération ?

Si !

Tu fais partie du staf de Locoduino donc tu as un rôle de modérateur, mais dans ce cas si tu es à la fois juge et partie, c’est compliqué.

1) il n’y a eu AUCUN dénigrement dans ce fil.
Aucun produit ni aucune entreprise n’est dénigré.
Mais la contradiction est permise, surtout si les ouvrages que tu cites sont conformes à ce que le modélisme fait habituellement.

2) ton système est sans doute très différent des concepts de gestionnaire classiques qui se basent sur les pratiques de la sncf et qu’on retrouve dans cdmRail, RRTC, etc.
Je crois comprendre que tu réalises des cantons intelligents mais ce ne sont pas des gestionnaires répartis. La détection globale du canton est Railcom et elle peut être globale (ne pas regarder l’état des aiguilles) car un train et un seul peut occuper le canton. De plus, la conduite à la main ne nécessite pas d’itinéraires (commande manuelle des aiguilles, les enclenchements ne sont que inter-canton.

3) mais je me trompe peut-être tant que tu ne présentes pas ton projet plus globalement.
C’est sans doute la raison pour laquelle tu n’acceptes pas les terminologies et les définitions que nous cherchons à utiliser d’un commun accord.

4) il y a des points de convergence à creuser, comme le fichier de description du réseau et les outils pour le faire et l’exploiter

[Etienne66]

Écoute Etienne, tu es dans une entreprise de dénigrement systématique :

Christophe,
J'ai réalisé pour le logitiel TrainZ un gestionnaire complet avec la signalisation SNCF, la circulation automatique des trains avec gestion des priorités,
des voies réservées aux différents types de trains (voyageurs, fret, express, ommnibus...) ainsi que la gestion des manoeuvres avec la possibilité
pour le joueur de contrôler un train en manuel.
Je sais ce qui marche ou peut marcher mais surtout je sais ce qui ne marchera pas pour y avoir passé des mois.

Je comprends ta démarche de vouloir simplifier le système pour l'utilisateur mais plus on veut faire simple pour l'utilisateur et plus c'est
complexe pour le programmeur.
Ton système ne peut pas faire seul la différence entre une TJD et une TJS, c'est un fait. Le logiciel devra demander l'information à l'utilisateur.
De même il devra demander sur quelles broches tu as branché tes aiguilles et tes feux.
Donc tu vas avoir besoin d'une interface utilisateur pour les questions et les réponses.

J'ai suggéré de mettre des voies de manoeuvre et une portion de voie unique sur le réseau de test. Il y a une raison à çà : la gestion de ces
cas de figure demande une autre structure de données, et donc une description différente du réseau.
Par exemple une voie peut être en sens unique pour un train en ligne mais à double sens pour les manoeuvres. Donc ton système horaire/antihoraire
doit être dupliqué.
Je sais aussi par expérience qu'il faut savoir si une manoeuvre est une manoeuvre de couplage, auquel cas il faut savoir quelle est la voie de destination
vu qu'on devra autoriser l'entrée sur cette voie qui est un canton occupé. (et qui dit connaitre la destination dit itinéraires)

Maintenant tu fais ce que tu veux de mes conseils et tu peux tester des solutions par toi-même mais tu gagnerais du temps à m'écouter.

[Pierre59]

Parmi les innombrables message d'hier, il y a un message de Christophe disant que ce serait bien que les liens entre les zones du fichier json soient dans les zones. Je suis tout à fait d'accord.

Il y a beaucoup de liens croisés entre les zones (une zone A a un lien sur une zone B, et B à un lien sur A). Quand on traite le fichier json on crée des objets (instances) pour chaque zone mais on ne peut traiter les liens (quand on traite une zone A, la zone B peut ne pas encore traitée).

Quand toutes les zones sont crées on peut alors traiter les liens. C'est pour cela que les liens sont sortis des zones dans le fichier json.

Mais on peut les mettre dans les zones, en traitant deux fois la partie zones du fichier json, une fois pour créer les zones et une deuxième fois pour ajouter les liens.

Pierre

[DDEFF]

Ok, c'est vrai qu'il faut des choses claires.

Si on revenait au JSON de Pierre ?
Parce que je suis tout à fait novice sur ce format de données qui m'a l'air intéressant.
Qu'est ce qui doit être entre crochets [...] et qu'est ce qui doit être entre accolades ? {...}

Denis

[Etienne66]

On était parti dans la définition de certains termes.

Je propose qu'on indique dans le cahier des charges qu'on a une signalisation type BAL (Bloc Automatique Lumineux).
Il existe à la SNCF de nombreux types de blocs correspondant à différents types de situations. Mais on se limitera ici au BAL qui est le plus utilisé aujourd'hui.

On n'a pas de permissivité possible vu qu'on n'a aucun moyen de gèrer la présence de 2 trains sur un même canton (ce n'est possible qu'avec un comptage d'essieux)
donc on peut utiliser des cibles BAL,BM ou BAPR pour le réalisme vu qu'en réalité on sera toujours informatiquement sur du BAPR.

[Pierre59]

Je suis tout à fait d'accord avec Etienne, j'ai aussi déjà beaucoup travaillé sur les gestionnaires et je connais les problèmes des manoeuvres. Il faudra y venir en rajoutant ce qu'il faut (tiroirs, signalisation, ...), j'ai déjà timidement ajouté des "sens" aux zones, mais cela sera insuffisant.

Pierre

[Pierre59]

On n'a pas de permissivité possible vu qu'on n'a aucun moyen de gèrer la présence de 2 trains sur un même canton (ce n'est possible qu'avec un comptage d'essieux)
donc on peut utiliser des cibles BAL,BM ou BAPR pour le réalisme vu qu'en réalité on sera toujours informatiquement sur du BAPR.

On a effectivement pas de permissivité possible mais on peut envoyer une machine sur un canton occupé (pour faire une mise en tête par exemple) avec des itinéraires en manoeuvre, signal carré présentant le feu blanc (M), cela se fait à l'a SNCF dans les grandes gares.

Pierre

[Pierre59]

Si on revenait au JSON de Pierre ?
Parce que je suis tout à fait novice sur ce format de données qui m'a l'air intéressant.
Qu'est ce qui doit être entre crochets [...] et qu'est ce qui doit être entre accolades ? {...}

En json on regroupe tout avec des accolades et on y accède avec des "clés", sauf les tableaux dont les éléments sont entre crochets et on y accède avec des indices.

Pierre

[Etienne66]

Je pense qu'il faut faire les choses dans l'ordre.

Pour l'instant, on se cadre sur la description du réseau.
Denis

Description minimale :
- Aiguillages :
--- gauche/droite
--- adresse DCC
- Signaux :
--- type de cible
--- adresse DCC
- Blocs de présence (détection par courant) :
--- adresse du détecteur sur le bus de retrosignalisation
--- liste des aiguillages faisant partie du bloc
--- Interconnexions possibles : bloc de début, bloc de fin, position des aiguilles
- Cantons (d'un signal à un autre avec la même direction que les signaux) :
--- Bloc de départ
--- Signal de départ
--- Blocs traversés dans l'ordre
--- Interconnexions utilisées (peut être déduit des interconnexions possibles)
--- Signal de fin
--- Bloc de fin (après le signal)
--- Autorisé normal
--- Autorisé manoeuvres
--- Optionnel : détecteur IR de zone d'arrêt, adresse sur le bus de rétrosignalisation

Tout çà c'est le minimum pour la description du réseau.
Ensuite il faut rajouter des variables :
- aiguilles :
--- position actuelle
- Signaux :
--- aspect
--- canton suivant
--- feu suivant
- blocs :
--- libre/occupé (donné directement par le capteur)
--- réservé par un train (numero du train)
- cantons :
--- réservé
--- occupé
--- numéro du train  (attention : on peut avoir un canton occupé par des wagons mais pas de loco donc pas de numéro de train)

[laurentr]

Bonjour Etienne

Sur les aiguillages je pense que tu peux ajouter quelques rubriques utiles:

• position par défaut: droite/déviée

• type de moteur ( servo; solénoïdes, moteur lent,...)

• orientation du moteur ( pour les servo)

On peut peut être aussi évaluer si cet aiguillage doit être couplé à d autres (cas de "bretelles")

Enfin on peut envisager aussi une vitesse de circulation selon les directions( MAX, 70, 60, 30,...)

Ltr

[DDEFF]

@ Etienne

Je pense que la distinction des aiguilles gauche/droite n'est pas la bonne. Je préfèrerait TD/DV (Tout Droit/ DeVié) pour voir la distinction de vitesse entre la vitesse en cas de position tout droit et en position déviée. Il y a les aiguilles enroulées, bien sûr 
On peut aussi dire autrement en donnant carrément la vitesse pour chaque position (120/30) qui serait plus universelle ?

Denis