Bonjour,
J'ai lu vos échanges sur les cantons, zones, N+1, N-2, etc... et vous essayez d'inventer le bogie avant d'avoir inventé la roue.
Il y a deux choses distinctes dans la sécurité des trains : le cantonnement et l'interconnexion (interlocking en anglais)
Et il y a un grand principe : un conducteur ne doit jamais se voir présenter un feu rouge avant d'avoir passé un avertissement.
Pour les signaux de cantonnement pas de souci : on regarde l'occupation de n+1 et le feu n+1 et ça peut se faire localement sans
passer par la centrale.
Mais pour les carrés c'est totalement différent et ça ne peut se faire que par une gestion d'itinéraire.
Un carré ne doit passer au vert (ou jaune) que si un train a demandé le passage vers une destination, que son trajet ne rentre
pas en conflit avec celui d'un autre train et que les aiguilles ont été positionnées pour ce trajet. Et il faut souvent pouvoir gèrer
le feu en avance, alors que le train n'a pas encore passé le signal précédent.
Pourquoi ne pas mettre un carré au vert en l'absence de train si les aiguillages offrent un trajet libre? Parce que si un train arrive
et qu'un autre train demande le passage le feu va passer au rouge devant son nez.
Donc il faut une gestion d'itinéraire qui va gérer des réservations au moins à deux cantons devant un train.
La définition de cantons ne suffit pas pour la gestion des carrés. Il faut définir des trajets constitués de plusieurs cantons,
avec des sens de circulation pour chaque canton avec la possibilité de réserver un trajet pour plusieurs trains si ils vont dans le même sens.
Il faut aussi définir les trajets incompatibles entre eux. Par exemple les trajets utilisant un groupe d'aiguillages ou deux trajets
avec un croisement.
La boucle de retournement pose également un problème particulier (le train en N est aussi en N+2 mais dans l'autre sens!)
La gestion du carré violet impose également le système d'itinéraire car il faut savoir si le train est en manoeuvre ou pas et
ça ne peut pas se faire automatiquement.
Enfin il y a les conflits à longue distance. Par exemple il ne faut peut-être pas engager un train sur une voie unique si il n'y a pas
de voie libre dans la gare suivante.
Bonjour Etienne66
Je suis désolé de te contredire, mais ce que tu affirmes est faux, tout au moins sur nos petits réseaux miniatures. J’ai démontré le contraire avec les satellites autonomes.
Rapidement, je rappelle le concept. Sur chaque canton est disposé un satellite et chaque satellite dispose d’un gestionnaire qui est rigoureusement identique sur chaque satellite. Il n’y a donc aucune gestion centralisée du réseau. C’est ce que Pierre a qualifié de gestion répartie.
Chaque satellite autonome connait ses liaisons avec ses voisins (rien de nouveau), et comme il connait ses voisins, il connait aussi les voisins de ses voisins.
Aussi, le satellite à C0 connait l’état des aiguilles de C+1 et aussi l’état d’occupation de C+1.
Il en est de même pour C+2 et ainsi C0 connait l’état d’occupation C+2 et l'état de ses aiguilles et peut alors afficher un ralentissement ou toute signalisation adéquate comme C+1 sait aussi afficher la bonne signalisation.
On voit donc qu’il n’y a aucune notion d’itinéraire, je ne l’utilise d’ailleurs pas sur mon réseau, tout est simplement déterminé en fonction de l’état du réseau à un instant t, état connu par chacun des satellites qui reçoit des autres ces informations toutes les 100 ms au travers du bus CAN et qui adapte son comportement en fonction des informations reçues.
Vitesse et direction des trains sont aussi des informations connues des satellites.
Je précise cependant que la détection est faite avec Railcom, ce qui permet aussi aux satellites de connaitre en temps réel chaque train, sa position, sa vitesse et sa direction et chaque satellite si nécessaire, sait envoyer une commande à la centrale pour ralentir ou encore arrêter un train.
A ta disposition pour discuter de cela au besoin.
Christophe
