Projet partagé d'un gestionnaire de réseau

[DDEFF]

8 locos et 40 voitures et 8 wagons

[laurentr]

Bonsoir Denis

Limpide.

L'objet" itinéraire est donc un "LOT CONSOLIDE " de toutes les zones d'une extrémité (entrée) d un canton à un autre (sortie)
Tout ce qui est "entre" ces points distincts doit être associé par logique à cette réservation et rien ne peut y être sécant (sécurité des itinéraires)

En BAL ( Bloc Automatique Lumineux) Les combos de signaux ne sont que 3 états principaux enrichi de contextes spécifiques:
ROUGE = ARRET
JAUNE = RALENTIR
VERT = VOIE LIBRE

On a 3 types de "ROUGE" : carré, sémaphore et carre violet
Au niveau "JAUNE" on a:  le rouge clignotant ( sous réserve de franchissement possible, sinon le remettre au dessus)  Avertissement, Ralentissement 30, Ralentissement 60, Rappel de ralentissement30, rappel de ralentissement 60 et en combo je jaune en sus
On peut y associer le vert clignotant par extension.

en "VERT" Enfin el voie libre et ou le blanc ( départ en Manœuvre) et ou le blanc clignotant ( départ en manœuvre réduite)

Les carrés( rouge et violet) assurent des protections.
Les autres feux hors manœuvre assurent le cantonnement

Quel facteur fait que le "JAUNE" est l'un ou l'autre?
La construction d un arbre de conditions qui conduisent par combinaison(s) à préciser le contexte pour l'affichage de l un des cas si applicable à un cas JAUNE.= principalement des positions d aiguilles, et ou de bloc.

Idem pour différencier vert et blanc.

On peut choisir de faire influer ou pas les vitesses aux états ( en étant K proportionnel) ce n'est pas obligatoire des lors que le rouge est bien un contexte d arrêt absolu;, que le "JAUNE" produit une vitesse inferieure ou égale à la vitesse nominale, le "fine tunning" des vitesses  intermédiaires est affaire de choix.


Pour résumer on a donc besoin de 3 blocs fonctionnelles pour piloter:
un bloc pour les segments de voie et leur caractéristiques (gestion de l infra)
un bloc pour la gestion des matériels et leur association( gestion convoi)
un "hyperbloc" qui établit un mapping entre les deux premiers, interagit et assure les fonctions désirées.

Si on pose une loco inconnue en base alors on actualise des éléments ( a minima) . ( on peut au mieux juste récupérer son adresse DCC via RAILCOM en automatique)
On associe un "convoi" dont on précise les caractéristiques ( longueur, …)
Si le convoi a évolué ou changé( loco sur un autre convoi) on actualise ses caractéristiques. Par défaut on applique une règle de sécurité qui force aux conditions les plus défavorables l'attribution des caractéristiques "max" au nouveau convoi ( ex longueur la plus longue admise sur le réseau avec une marge de sécurité.)

On voit donc que le mode 100/100 autonome exclusif va être contraint de disposer à minima en sus d'une IHM pour traiter les caractéristiques sur les ambitions indiquées.
On passe alors sur une réalisation plus ambitieuse avec des parties bien identifiées.

Laurent

[laurentr]

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.

Super méthode en effet mais je pense que tu ne peux pas prendre en compte dans ce cas un train qui est plus long que ta section de mesure. Donc cette zone est au plus court la longueur max d un convoi.

On est OK la dessus?

Ltr

[DDEFF]

@ Dominique

Ta méthode marche, bien sûr, mais il faut repasser par la zone de test pour identifier un problème.
Avec ma méthode (plus complexe à gérer, bien sûr) on le sait très rapidement après qu'on a perdu un wagon.
Prenons un exemple :
Soit 3 cantons de 10 unités de long C1, C2 et C3 et un train de 8 unités de long
Dès que le train a parcouru 8 unités du canton 2, on ne devrait plus rien avoir sur le canton 1. S'il reste une présence sur C1, c'est un wagon perdu.
Une autre méthode, moins précise :
Si le train est présent sur C1 et C2 et C3, c'est qu'on a perdu quelque chose.

Denis

[Dominique]

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.

Super méthode en effet mais je pense que tu ne peux pas prendre en compte dans ce cas un train qui est plus long que ta section de mesure. Donc cette zone est au plus court la longueur max d un convoi.

On est OK la dessus?

Ltr

Tout à fait d’accord. On fait un réseau dans le but que ça marche et on accepte un peu de contraintes. Je ne compose pas de trains avec 12 voitures, d’ailleurs je n’en ai pas tant que ça !

[Dominique]

@ Dominique

Ta méthode marche, bien sûr, mais il faut repasser par la zone de test pour identifier un problème.
Avec ma méthode (plus complexe à gérer, bien sûr) on le sait très rapidement après qu'on a perdu un wagon.
Prenons un exemple :
Soit 3 cantons de 10 unités de long C1, C2 et C3 et un train de 8 unités de long
Dès que le train a parcouru 8 unités du canton 2, on ne devrait plus rien avoir sur le canton 1. S'il reste une présence sur C1, c'est un wagon perdu.
Une autre méthode, moins précise :
Si le train est présent sur C1 et C2 et C3, c'est qu'on a perdu quelque chose.

Denis

Je suis aussi d’accord avec toi Denis. J
Je ne recherche pas la perfection maximale mais aussi le plaisir de voir tourner mes trains.
Parfois je dois crapahuter pour récupérer un wagon renversé dans un tunnel inaccessible, mais je m’arrange ensuite pour éviter ça.

On devrait d’abord converger vers un gestionnaire pratique, faisable, compréhensible et fonctionnel dans un grand nombre de cas. Puis le perfectionner ensuite.

Plutôt que se limiter à l’impossible !

Plus concrètement, si le bus Can transmet des messages de détection de présence (donc avec un numéro de zone tout simplement), que doit faire le gestionnaire:
- dans le cas d’un gestionnaire centralisé ?
- dans le cas d’un gestionnaire de canton autonome?

Vous avez 1 heure.

[laurentr]

@ Dominique

Moi je sais, moi je sais:

Tout bien faire comme il faut!

Fastoche hein !


@Denis

Qui d un convoi qui se "morcèlerait"( rupture d attelage)  il serait pour partie sur des zones non contiguës ce qui génère une "anomalie"/"alerting?
C est bien la libération de la dernière "zone active" ( avec présence détectée)  ( par rapport à la tête et du nombre d unités occupées par un convoi)  qui est à suivre pour actualiser l itinéraire, ce qui est entre les deux dans ce cas reste simplement à surveiller ( sinon morceaux multiples!)

Ltr

[Dominique]

@Laurent,

En effet on traite la tête du train avec l’occupation et la queue du train avec la libération.
Puis on compare.

[bobyAndCo]

@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

Bonjour Laurent,

En effet, c'est Railcom qui est utilisé pour la détection sur les satellites autonomes, mais il s'agit dans ce sujet de rechercher des solutions "plus universelle".

Railcom est très intéressant et permet de contourner pas mal de problème pour lesquels on se casse la tête ici mais !!! Mais tout le monde n'est pas équipé en Railcom, et comme tu le soulèves il y a peut être des problèmes non vus encore comme les UM.

Les satellites autonomes sont bien adaptés pour des les petits et moyens réseaux et les dioramas ce qui représente déjà bon nombres de besoins. Mais sur des réseaux complexes comme présente par exemple Denis avec plus de 2 ou 3 aiguilles en successions, des croisements, des TDJ et je ne sais quoi encore ou des UM pourquoi pas comme comme tu le dis il ne seront pas adaptés.

Christophe

[Pierre59]

Bonjour

@ Laurent

Je ne suis pas trop d'accord avec ton "analyse" des feux des signaux. Si on exclut pour simplifier les feux clignotants, il y a trois sortes de feux : les feux de block, les feux de protection et les feux de limitation de vitesse.

Il y a trois feux de block : voie libre (Vl), avertissement (A) et sémaphore (S).
Pour les feux de protection il y a deux sous-sortes, les feux de manoeuvre carré violet  (Cv) et manoeuvre (M), et les "normaux" carré (C), avertissement (A) et voie libre (Vl).
Les feux de ralentissement sont le ralentissement (R) et le rappel de ralentissement (RR).

En pratique il y a souvent un mélange des trois sortes de feux, exemples un sémaphore avec un feu ralentissement, un carré avec un feu sémaphore, un carré avec un feu manoeuvre, un carré avec un feu rappel de ralentissement, ...

Pierre

[DDEFF]

Voici comment je raisonne pour mes trains virtuels.
Mais c'est en l'appliquant aux trains réels que ça va devenir intéressant.



Sur l'image, on voit 4 cantons à une zone qui se suivent. On est dans un cas hyper simple.

Dans l'étape 1 (1ère ligne) le C1 a 70 points de longueur, C2 a 40 points, C3 a 90 points et C4 a 80 points.
Le train 1 est sur C4. Il est en automatique. Son itinéraire fait 80 points et comme il est arrivé à la fin de son itinéraire, il y a le C (carré). Il est à 30 points du C et finit son arrêt.
Le train 2 est sur C1. C'est moi qui le conduis. Mon itinéraire fait 280 points car je souhaite aussi m'arrêter en gare en C4.
Mon prochain signal est à 20 points et c'est VL que j'affiche sur ma manette.

Dans l'étape 2 (2ème ligne), le train 1 est arrêté à 10 points du C.
Le train 2 a toujours un itinéraire de 280 points, mais mon prochain signal est à 30 points et c'est A (Avertissement) que j'affiche sur ma manette.
Mais ce que je sais, c'est que je suis à 130 points du S (sémaphore) quand j'entre dans le C2. Je vais donc devoir m'arrêter en 130 points.
Pour l'instant, j'ai commencé à freiner et il me reste 120 points pour m'arrêter.

Ce qui me parait intéressant dans cette démarche, c'est que je ne raisonne plus en cantons, mais en longueur à parcourir jusqu'au prochain signal qui va m'obliger à m'arrêter.
Ça prend donc en compte la longueur des cantons, la distance de freinage, de façon tout à fait automatique sur un itinéraire sur lequel je sais tout ce qui va m'arriver.

La signalisation est mise à jour indépendamment des itinéraires, en fonction des positions des aiguilles et des occupations.
Puis, une fois la signalisation mise à jour globalement, on l'intègre dans les itinéraires et ça agit sur les trains.

Dernière remarque :

Mes trains virtuels n'ont pas le DCC, évidemment.
Donc, c'est dans le programme que je calcule le ralentissement, via une courbe de ralentissement (semblable à une décharge de condensateur) que je mets à jour suivant 2 paramètres : la vitesse initiale et la durée de ralentissement (= le nombre de points). Je suis alors CERTAIN que le train s'arrêtera au bon endroit puisque la courbe tient compte de la longueur d'arrêt.
Si on fait confiance au DCC pour gérer le freinage, on prend un risque de ne pas arrêter au bon endroit.

Denis

[Pierre59]

Bon et si on se mettait au travail, commencer à écrire du programme.

Faut choisir un langage, personnellement le préconiserais d'en utiliser deux C++ et Java (Processing). Les deux langages sont très proches, des grandes parties de la syntaxe son strictement les mêmes, il y a un article sur le site qui explique les petites différences entre les deux. Le programme en C++ est plutôt destiné aux micro-controleurs et le programme en Java plutôt destiné au ordinateurs ou micro-ordinateurs (genre Raspberry).

Celui qui écrit un bout de programme le fait dans son langage préféré et après mise au point on le transcrit facilement dans l'autre langage.

Bien évidemment il faut utiliser la programmation objet. Donc un bout de programme est une classe (un objet).

Personnellement je n'écrirais rien, je ne veux pas orienter vos choix. Mais je peux vous aider pour la programmation objet. Par ailleurs j'ai déjà écrit pour mon propre réseau un très gros gestionnaire.

Pierre

[Dominique]

Pour compléter mon message précédent, un bout de code du traitement des messages CAN reçus par le gestionnaire dans le cas des occupations et libération par un détecteurs de présence.

Il y a effectivement des objets zone, et des objets train qu'il faut adresser à travers des tables d'objets renseignées juste après la création des objets. Il faut aussi des objets canton portant la signalisation.
Le structure du message Can sera a adapter à celle qui sera retenue. Ici c'est l'exemple de mon réseau.

Code: [Sélectionner]

// reception d'un message CAN

data = frame.data.bytes[0];  // bit 6 occupation + no de zone
occupation = bitRead(data, 6);    // masque occupation 0x40 = bit 6 : True=occupé, False=libre
nzc = data & 0x3F;           // No de ZONE detectée
zone* zc;                    // = zone ou a lieu la detection
zc = tableZones[nzc];
zone* zp;  // = zone precedente à trouver
train* tt;

switch (frame.id) {  // type de message

  case 0x10:  // OCCUPATION ou LIBERATION de zone zc venant des détecteurs

    if (occupation) {
      zc->occuper();
      zp = zc->provenance();  // zone précédente
      if (zp != NULL) {
        tt = zp->train;
        zc->train = tt;  // marquage du train dans la zone zc de détection
        // ensuite il faut mettre à jour les signaux, celui de zp si c'est une limite de canton
      }
    } else {  // liberation de la zone zc
      zc->liberer();
      zc->train = NULL;
      // et mise a jour ds signaux
    }
    break;
Evidemment c'est le cas le plus simple et la plus grande partie du code sert à traiter les erreurs !

Les détections de présence, d'identité (RFID ou Railcom) et d'arrêt ont des traitement particuliers qui leur sont associés grâce aux identifiants différents des messages Can.
De plus, les changement de régime des locos sous l'action manuelle du conducteur donnent lieu à des messages Can pour enregistrer la consigne voulue par le conducteur dans les objets train, afin qu'il reprenne la vitesse demandée lorsque les contraintes ont disparu.

Dans une autre tâche du processeur, se fait la régulation des trains : Pour chaque train le signal présent à la fin du canton détermine un ralentissement (30, 60..) avec arrêt en fin de zone si c'est un carré ou sémaphore. Le ralentissement se fait par palier de 30 ou 15 km/h (60, puis 30, puis 15 pour un arrêt), j'ai trouvé que ça suffit et qu'il n'est pas nécessaire d'inonder le bus Can de commandes intermédiaires. Par contre c'est la centrale sui gère les vitesses intermédiaires un peu comme le slowmotion servo.
Dans cette tâche, les trains redémarrent quand le signal le libère.

Au sujet des graphiques (représentation de type TCO, faite par le même processeur du DUE) , pour chaque zone il y a une fonction d'affichage, par exemple :

Code: [Sélectionner]

void GA3::tracer(int c) {
  if (etat) {//droit
    myGLCD.setColor(K_ferme);
    geo.drawArc(196, 336, 38, 315, 360, 5); //a3
    myGLCD.setColor(c);
    drawbarreH(196, 298, -27); // z28
  }
  else {     // devié
    myGLCD.setColor(K_ferme);
    drawbarreH(196, 298, -27); // z28
    myGLCD.setColor(c);
    geo.drawArc(196, 336, 38, 315, 360, 5); //a3
  }
}
GAiguille* Ga3 = new GA3( 3,44 ); // a3  est dans la zone z44
Le numéro de zone est le même que celui de sa représentation graphique

J'ajouterai dès que possible une petite vidéo montrant ce qui se passe sur l'écran graphique du gestionnaire.

Plus de détails ici :
https://forum.locoduino.org/index.php?topic=290.120

[laurentr]

Bonjour

@Denis

Tu peux confier au DCC le freinage. Il te faudra toutefois étalonner ton matériel pour cela.

En effet tu dois garder une vitesse mini avant l'arrêt, cette valeur est propre à chaque matériel avec sa vitesse mini et éventuellement les coef de passage entre les seuils hauts et bas ( décélération) et inversement ( accélération)

Pour confirmer la bonne exécution une détection devant la fin du canton confirme bien l'arrivée de la tête de train dans la zone d'arrêt devant le signal. Si cet éventement ne se produit pas alors le train s'est arrêté "trop tôt". A défaut de cette zone de détection avant le signal on peut avoir quelques surprises. Mais on peut s'en passer des lors que pour chaque entrée dans une nouvelle zone il y a re synchro distance/vitesse/position. ( et donc re calculs)

Tu peux aussi penser à utiliser l'ABC LENZ cote HARD pour générer ce freinage mais il y aura moins de progressivité dans le mouvement.

Ltr

[dmskd]

Bonjour,

Une ZONE correspond à une détection de présence. Ce peut être un rail avec des coupures, une aiguille seule, plusieurs aiguilles.

Comment fait-on pour détecter une présence sur une aiguille ?
Faut-il isoler l'aiguille complètement ?
Faut-il un ou deux capteurs ?
...?