Question signalisation

[henrion 101]

je pense que Jules31 pourra me répondre.

 

Dans le règlement S1A, il est dit à l'article 103:

 

"Disposition complémentaire:

Certains signaux lumineux sont normalement éteints: ils ne présentent d'indication qu'à l'approche des trains, ou bien leur allumage n'est commandé que sous certaines conditions"

 

Je ne vois pas du tout de quels signaux il peut s'agir.

[Jules31 44]

Quatres types de signaux :

 

1) Les signaux de cantonnement intermédiaires en contre-sens sur IPCS. Ils ne s'allument que si la ligne de sens adéquate est activée sur le pas (une ligne parcourant un pas d'IPCS permettant de configurer les équipements du terrain selon le sens sélectionné : annonces de PN, allumage des signaux intermédiaires de contre-sens en cas d'utilisation du contre-sens, désactivation des crocodiles et des boites à pétards des carrés de sens contraire, voyants de sens normal et de contre-sens dans les postes de campagne en cas de reprise des installations en local, etc).

 

2) Les guidons d'arrêt.

 

3) Les signaux de BAL régional Est de la région de Metz-Nancy s'il en existe encore (ne s'allumant qu'à l'approche, car ils ne sont pas alimentés par secteur mais par des piles qu'il faut économiser). Un peu dans le même principe et le même but, il y avait les block Paul et Ducousso du Midi qui ne s'ouvraient qu'à l'approche, et si aucune protection ne l'en empêchait (il y avait en gare ce qu'on appelle des clés de gare qui permettaient d'empêcher d'ouvrir les signaux d'entrée de la gare pour assurer sa protection).

 

4) Les feux de PN à franchissement conditionnel, qui ne présentent deux feux vert que si les barrières sont fermées, et qui autorisent au conducteur du train de franchir le PN. Dans les autres cas, le signal est éteint.

 

Si j'en oublie, je te préviendrai et j'éditerai ce post (ajout des feux de PN FC).

Edited February 1, 2010 by Jules31

[henrion 101]

Merci, je comprends mieux.

 

cela ne va pas être simple à programmer un pas d'IPCS

Edited February 1, 2010 by henrion

[Jules31 44]

Avec plaisir camarade.

 

Et oui ca n'a rien de facile

 

Pour les signaux des IPCS, c'est toujours une question de sens courant sur une voie parcourable dans les deux sens (comment simuler la prise de sens qui normalement est effectuée par un agent-circulation ou un automate d'itinéraire, comment en faire connaître les signaux et autres appareils de voie, etc). Le problème est le même en voie unique et sur voie banalisée.

 

Sur ce sujet, ca a muri de ton coté, histoire qu'on confronte un peu nos idées en la matière ? :lol:

Edited February 1, 2010 by Jules31

[henrion 101]

En ce qui concerne la voie unique, tu avais suggéré que le sémaphore de sortie de gare gère après les aiguillages en incluant ceux d'entrée de la gare suivante. Cela ne me semble pas faisable car il faudrait mettre les liens 1 et 2 après les aiguillages de la gare suivante soit 10 ou 20 km du lien 0. Je ne sais pas si c'est possible mais cela ne me semble pas pratique du tout à faire. Je suis donc un peu au point mort à ce sujet.

 

En ce moment je fais des scripts de signaux pour essayer de les adapter au mieux à la signalisation française. Je me penche aussi sur le fonctionnement des signaux en gare et notamment lors de la jonction de plusieurs automoteurs ou lors de changement de motrice. Mais il faut que je teste avec des scripts parfaitement au point.

 

Pour les IPCS il y a un problème que je ne vois pas comment résoudre: mettre au carré le signal dans le sens descendant avant que l'aiguillage ne soit positionné vers l'IPCS dans le sens montant. En fait on ne sera jamais sûr qu'une rame ne soit pas engagée dans le sens descendant. Ce qui limite l'intérêt. Au mieux on pourra vérifier que le pas d'IPCS est libre mais uniquement quand l'aiguillage est positionné vers le pas.

Edited February 1, 2010 by henrion

[Jules31 44]

Pour les VU, est-ce que tu connais le fonctionnement des signaux et des différents équipements qui participe à la sécurité ? (la pédale de blocage d'un sémaphore, la pédale de reddition et sa pédale de préparation en bloc manuel de voie unique BMVU, les compteurs d'essieux en BAPR).

 

Je peux te faire un schéma si besoin. C'est à mon avis de bonnes sources d'inspiration pour nos problèmes, car dans le pire des cas, on modélise l'ensemble des éléments participant dans la réalité, et on est plus embêté (j'exagère bien sûr mais je pense que la solution sera un compromis à partir de ce qui se fait dans la réalité). Mais je peux surement me gourer. Bref, seul moyen pour le savoir, c'est d'en parler.

 

Pour les signaux de gare, tu parles du cas du rouge cli ou de la bande jaune ?

 

Pour les IPCS, c'est quoi pour toi le sens descendant et le sens montant ?

 

Quand tu dis "aiguillage positionnée vers l'IPCS", tu veux dire les deux aiguilles d'une communication Voie1/Voie2 donnant accès à une voie en contre-sens, avec les aiguilles en position pour donner cet accès à contre-sens ? J'ai bien compris ? (je ne suis pas sûr)

 

PS : A ceux qui nous lisent, qui ont les bases et qui s'intéressent au sujet, n'hésitez pas à intervenir ! Ce n'est pas juste un dialogue entre moi et Henrion ! Critiques autorisées ici !

Edited February 1, 2010 by Jules31

[henrion 101]

J'imagine un train sud_Nord qui va prendre le pas d'IPCS (sens montant). Le sens descendant est celui opposé. Exact pour l'aiguillage de l'IPCS. C'est plus complexe que je ne l'aurai imaginé.

 

Le fonctionnement de la VU, je ne connais pas donc si tu as un schéma il sera le bienvenu.

 

Pour les gares je ne parle pas du rouge cli ou de la bande jaune, cela est facile à programmer. En fait il faut vérifier le fonctionnement des gOccupationtable[] Exemple: si un automoteur arrive sur un quai il met la gOccupationTable à 1. Si un deuxième automoteur arrive sur le même quai il va incrémenter la gOccupationTable et la mettre sur 2. Si les deux automoteurs font la jonction, en sortant de la gare il n'y aura qu'une décrémentation de 1 de la gOccupationTable qui va rester à 1 et donc le signal va rester au rouge alors que le quai est vide. Il en va de même en cas de changement de motrice. Mais comme je ne suis pas sûr de ce fonctionnement qui serait logique, il faut vérifier avec des scripts parfaitement au point.

[Erakis 147]

PS : A ceux qui nous lisent, qui on les bases et qui s'intéressent au sujet, n'hésitez pas à intervenir ! Ce n'est pas juste un dialogue entre moi et Henrion !

J'ai bien fait d'appuyer sur la touche F5 ! Enfin, vous allez peut-être le regretter...

 

...parce que je ne vais probablement pas faire avancer le schmilblick : quelle est la problématique de la "prise de sens courant" ? (Si ça ne vous dérange pas de m'expliquer, bien sûr.)

Edited February 1, 2010 by Erakis

[Erakis 147]

En fait il faut vérifier le fonctionnement des gOccupationtable[] Exemple: si un automoteur arrive sur un quai il met la gOccupationTable à 1. Si un deuxième automoteur arrive sur le même quai il va incrémenter la gOccupationTable et la mettre sur 2. Si les deux automoteurs font la jonction, en sortant de la gare il n'y aura qu'une décrémentation de 1 de la gOccupationTable qui va rester à 1 et donc le signal va rester au rouge alors que le quai est vide. Il en va de même en cas de changement de motrice. Mais comme je ne suis pas sûr de ce fonctionnement qui serait logique, il faut vérifier avec des scripts parfaitement au point.

Je pense quand même que les concepteurs du jeu ont prévu ce cas de figure, qui apparaît finalement à chaque attelage ou dételage : à ma connaissance le sémaphore de protection du canton où a eu lieu un dételage de wagons ne s'ouvre pas lorsque la loco en HLP quitte ce même canton. Probablement que le jeu compte le nombre de convois différents sur chaque canton (ou sur les cantons adjacents) à chaque fois qu'un signal de protection de canton est franchi. Non ?

Edited February 1, 2010 by Erakis

[henrion 101]

J'ai bien fait d'appuyer sur la touche F5 ! Enfin, vous allez peut-être le regretter...

 

...parce que je ne vais probablement pas faire avancer le schmilblick : quel est la problématique de la "prise de sens courant" ? (Si ça ne vous dérange pas de m'expliquer, bien sûr.)

En fait en schématisant, lorsqu'un train va entrer dans un pas d'IPCS, il faut que celui-ci soit libre et que le signal opposé soit au carré pour éviter d'avoir deux trains face à face. Or on ne peut vérifier ou donner un ordre à un signal sur une autre voie que si l'aiguillage est positionné vers cette voie. Dans ces conditions on ne sera jamais sûr qu'un train n'est pas déjà dans le pas d'IPCS dans le sens normal quand l'aiguillage fera mouvement vers l'IPCS. Je ne sais pas si je me fais bien comprendre.

[henrion 101]

Je pense quand même que les concepteurs du jeu ont prévu ce cas de figure, qui apparaît finalement à chaque attelage ou dételage : à ma connaissance le sémaphore de protection du canton où a eu lieu un dételage de wagons ne s'ouvre pas lorsque la loco en HLP quitte ce même canton. Probablement que le jeu compte le nombre de convois différents sur chaque canton (ou sur les cantons adjacents) à chaque fois qu'un signal de protection de canton est franchi. Non ?

 

C'est justement ce que je veux vérifier parce que normalement c'est mathématique à chaque franchissement de signal on incrémente ou on décrémente de 1. Si cela ne se fait pas je veux comprendre pourquoi. j'utiliserai le déboggage du signal.

 

Si cela ne semble pas poser de problème pour un changement de loco par contre pour deux automoteurs qui s'assemblent je pense que c'est plus problématique.

 

Bonne soirée.

[Jules31 44]

Henrion, pour les ipcs, si on considère le schéma suivant où tu as le train devant emprunter la voie paire en contre-sens sur le pas que je représente, ton problème est de savoir comment fermer les carrés 7, 4 et 2 avant que l'itinéraire entre le carré 1 et 8 soit tracé ?

 

(les carrés représentent les signaux carrés et carrés violet. Les flèches doubles sur les voies indiquent le sens "normal" et la flèche simple le "contre-sens")

 

 

Pour la gare, je comprends le besoin, mais comme Erakis, je pense que la table d'occupation est bien mise à jour aussi bien dans le cas d'un attelage qu'un dételage. Pour les équipements de sécurité en VU, je te transmets çà, quand j'aurai fait un joli dessin avec l'explication qui va avec

 

 

Erakis, pas de problème pour les explications !

La prise de sens, c'est le fait pour une voie ou portion de voie pouvant être empruntée couramment dans les deux sens de définir le sens pour lequel les équipements sont positionnés pour assurer en toute sécurité les circulations dans ce sens. Il s'agit par exemple pour un passage à niveau d'activer les équipements permettant d'annoncer un train pour le sens qui nous intéresse et de désactiver ceux du sens contraire (je donne une liste d'équipements à activer ou désactiver dans le message 2). Une des conditions pour prendre ce sens est que personne n'ait pris le sens contraire pour éviter tout nez à nez. C'est le rôle de ce qu'on appelle l'enclenchement de sens. Que ce soit en block automatique ou manuel, il y a une "demande de sens", puis un "accord de sens". Une fois le train passé sur la portion de voie qui nous intéresse, l'enclenchement ne fait en général plus effet (sauf si l'agent-circulation le maintien par un dispositif adéquat, pour un autre train de même sens par exemple) et autorise toute nouvelle prise de sens. En block manuel, la libération de cet enclenchement s'appelle la reddition et est effectuée par l'agent-circulation (elle est soumise à plusieurs contrôles visant à s'assurer que le train à bien libéré la portion de voie). En block automatique, la libération de l'enclenchement est automatique et est effectuée soit par circuit de voie, soit à l'aide de compteurs d'essieux comptant le nombre d'essieux rentrant sur la portion de voie et en sortant.

 

On retrouve cela aussi bien entre les gares en voie unique que sur un pas IPCS ou voie banalisée, et la problématique est strictement la même ! Prévoir les équipements pour circuler sur une même voie dans les deux sens et éviter le nez à nez. Dans le simulateur, il me semble que c'est exactement la même chose. La problématique et les solutions pour les VU, IPCS et voies banalisées seront certainement les mêmes !

 

Dans le simulateur, n'ayant pas d'agents-circulation, il faut donc que la prise de sens soit faite par les trains eux-mêmes (sinon on pourrait modéliser un petit appareil de block ou on pourrait appuyer pour faire ces manips , je rigole mais à mon avis, c'est comme sélectionner une destination à l'aide des panneaux prévus à cet effet dans RW). Pour faire porter cette action par les trains, j'avais émis la possibilité de faire la demande par approche du signal de protection, via un dispositif spécifique (certainement un objet invisible). Ensuite, il faut pouvoir vérifier l'occupation de la portion de voie, un peu à la manière d'un compteur d'essieux (peut être utiliser la table d'occupation). Ensuite, la question est de savoir où et quoi assure la libération de la portion de voie qui nous intéresse. On avait pensé faire jouer le rôle aux signaux de protection de sens inverse à l'autre bout de la portion de voie (les signaux de sortie de gare en VU par exemple mais vient la problématique de l'aiguille de dédoublement pouvant se situer après le signal et l'empêchant de communiquer avec les signaux de protection de la gare aval).

 

Cela répond-il à ta question Erakis ? J'ai été assez clair j'espère.

 

PS : Excusez-moi du problème avec l'image ...

Edited February 1, 2010 by Jules31

[Erakis 147]

Merci à tous les deux pour votre patience !

 

En fait en schématisant, lorsqu'un train va entrer dans un pas d'IPCS, il faut que celui-ci soit libre et que le signal opposé soit au carré pour éviter d'avoir deux trains face à face. Or on ne peut vérifier ou donner un ordre à un signal sur une autre voie que si l'aiguillage est positionné vers cette voie. Dans ces conditions on ne sera jamais sûr qu'un train n'est pas déjà dans le pas d'IPCS dans le sens normal quand l'aiguillage fera mouvement vers l'IPCS. Je ne sais pas si je me fais bien comprendre.

Erakis, pas de problème pour les explications !

La prise de sens, c'est le fait pour une voie ou portion de voie pouvant être empruntée couramment dans les deux sens de définir le sens pour lequel les équipements sont positionnés pour assurer en toute sécurité les circulations dans ce sens. Il s'agit par exemple pour un passage à niveau d'activer les équipements permettant d'annoncer un train pour le sens qui nous intéresse et de désactiver ceux du sens contraire (je donne une liste d'équipements à activer ou désactiver dans le message 2). Une des conditions pour prendre ce sens est que personne n'ait pris le sens contraire pour éviter tout nez à nez. C'est le rôle de ce qu'on appelle l'enclenchement de sens. Que ce soit en bloc automatique ou manuel, il y a une "demande de sens", puis un "accord de sens". Une fois le train passé sur la portion de voie qui nous intéresse, l'enclenchement ne fait en général plus effet (sauf si l'agent-circulation le maintien par un dispositif adéquat, pour un autre train de même sens par exemple) et autorise toute nouvelle prise de sens. En bloc manuel, la libération de cet enclenchement s'appelle la reddition et est effectuée par l'agent-circulation (elle est soumise à contrôle visant à s'assurer que le train à bien libéré la portion de voie). En bloc automatique, la libération de l'enclenchement est automatique et est effectuée soit par circuit de voie, soit à l'aide de compteur d'essieux comptant le nombre d'essieux rentrant sur la portion de voie et en sortant.

 

On retrouve cela aussi bien entre les gares en voie unique que sur IPCS ou voie banalisée, et la problématique est strictement la même ! Prévoir les équipements pour circuler sur une même voie dans les deux sens et éviter le nez à nez. Dans le simulateur, il me semble que c'est exactement la même chose. La problématique et les solutions pour les VU, IPCS et voies banalisées seront certainement les mêmes !

 

Cela répond-il à ta question Erakis ? J'ai été assez clair j'espère.

Finalement, si j'ai bien compris, la problématique est d'arbitrer quant à l'enclenchement ou non de l'IPCS en fonction du trafic au voisinage de la portion de voie susceptible d'être prise à contresens ? J'imagine que le critère pour le tracé de l'itinéraire c'est de favoriser le convoi le plus proche de la portion soumise à l'IPCS, ce qui suppose un test sur l'occupation des 1 ou 2 cantons situés de part et d'autre de cette portion ?

 

Histoire de comprendre la difficulté à implémenter la chose dans RailWorks : on ne peut pas connaître l'état d'occupation des cantons qui ne sont pas situés sur l'itinéraire qui est tracé, c'est bien ça ?

 

Si c'est ça, effectivement je comprends votre désarroi.

 

C'est justement ce que je veux vérifier parce que normalement c'est mathématique à chaque franchissement de signal on incrémente ou on décrémente de 1. Si cela ne se fait pas je veux comprendre pourquoi. j'utiliserai le déboggage du signal.

 

Si cela ne semble pas poser de problème pour un changement de loco par contre pour deux automoteurs qui s'assemblent je pense que c'est plus problématique.

 

Bonne soirée.

Pour la gare, je comprends le besoin, mais comme Erakis, je pense que la table d'occupation est bien mise à jour aussi bien dans le cas d'un attelage qu'un dételage.

J'ai flâné un peu du côté du forum UKTrainSim, et apparemment Henrion tu as raison : par défaut, il semblerait que la table d'occupation du canton n'évolue pas en fonction des différents attelages et dételages qui peuvent s'y produire. Ceci dit ce que j'ai lu s'applique à Rail Simulator et a été écrit en 2007 ; je ne sais pas si le problème a été traité depuis.

 

Ceci dit je pense qu'il y a moyen de ruser, peut-être en remplaçant la table d'occupation par une variable booléenne gEstOccupe qui ne pourrait prendre que les valeurs true et false, et qui ne pourrait retourner à false que lorsque la longueur cumulée des convois sortant du canton est au moins égale à la longueur cumulée des convois qui y sont entrés. (Je crois que la longueur des convois qui passent un signal est accessible avec la fonction OnConsistPass().)

 

Bon, en pratique ce n'est probablement pas aussi simple !

 

Bonne soirée à vous également.

Edited February 1, 2010 by Erakis

[Jules31 44]

La problématique est exactement celle là : comment assurer la prise de sens et le contrôle de l'enclenchement de sens, sachant que ca veut dire qu'il faut connaître l'occupation de la portion de voie pour savoir si l'enclenchement est libéré ou non.

 

On pourrait faire assurer ce contrôle sur les signaux de protection des signaux amonts (avant le premier signal pouvant présenter une information restrictive en vue d'un arrêt au carré). En voie unique, je pensais faire assurer ce rôle à un objet invisible qui pourrait être utilisé de la même manière en sortie des gares de voie unique. Ceci dit, reste le problème des aiguilles qui ne permettrait de communiquer d'avec tous les signaux que l'on désire à l'autre bout du pas d'IPCS ou dans la gare aval en VU.

 

Erakis, vu que tu sembles côtoyer le forum UK (plus que moi en tout cas), saurais-tu dire s'ils gèrent ces problèmes avec les signaux UK ou allemands ?

 

Bonne soirée.

Edited February 1, 2010 by Jules31

[henrion 101]

Bonjour,

Benoit, dans le message 12, je parlais du carré 2. Mais dans le fond je me demande si l'on ne se pose pas des questions inutiles. Car en fait quand on fait un scénario, je pense que l'on trace l'itinéraire (à confirmer)et dans ces conditions la position des aiguillages est définie d'office et donc les signaux prennent la bonne indication vis-à-vis d'eux. Reste à savoir si les trains AI, d'après ce que j'ai pu lire, respectent les signaux d'arrêt.

 

En ce qui concerne les mouvements en gare. J'ai essayé avec la première version des signaux de JYM26 (donc avec des scripts d'origine modifiés). Quand un train s'arrête en gare et que la motrice se dételle et sort de la gare, le signal d'entrée reste au rouge. Quand une motrice revient s'atteler en tête du train et passe avec toute la rame le signal de sortie, celui d'entrée se remet bien au vert. Donc ce cas est à priori résolu. N'empêche que j'aimerai bien comprendre pourquoi l'occupationTable ne s'incrémente pas ou ne se décrémente pas à chaque passage du lien par la motrice. Cela voudrait dire que railworks garde en mémoire la longueur de la rame.

 

En ce qui concerne la fusion de deux rames il va aussi falloir vérifier.

Edited February 2, 2010 by henrion

[Jules31 44]

Le problème est même plus général ! Imagine une machine qui vient assurer un secours en pleine ligne par devant et qui franchit des signaux à revers. Tu vas avoir le même problème.

 

Par contre, avec les signaux de JYM, on a des problèmes de réinitialisation des signaux R pris à revers. Pour le coup, il n'y a pas d'attelage ni de dételage, mais le problème est peut être le même.

 

 

Concernant le problème des carrés. J'ai eu la même réaction que toi hier soir au sujet de la manière dont sont tracés les itinéraires par le simulateur. Je me suis demandé si on ne se prenait pas la tête pour rien. Malheureusement, il me semble que non.

 

Prenons mon image avec mon train qui approche du carré 1 pour entrer sur la voie paire en contre-sens. L'itinéraire va être tracé entre le carré 1 et 8 en conséquence. A l'autre bout du pas, les aiguilles des communications sont toutes positionnées pour donner la voie directe. A un moment donné, il va bien falloir que tu gères un éventuel nez à nez entre le train arrivant au carré 1 et un autre train pouvant se présenter sur la voie paire en sens normal au carré 2 ! Avec l'état des aiguilles comme je viens de le décrire (donc avec les itinéraires mis en œuvre), il faudra quand même s'assurer qu'entre le carré 1 et 2, un seul puisse s'ouvrir car il y a un itinéraire tracé qui les relie (vérifier l'enclenchement de sens sur la portion de voie située entre le carré 1 et 2).

Edited February 2, 2010 by Jules31

[henrion 101]

J'ai essayé aussi de positionner une rame en gare et de lancer le jeu. Même avec cette rame arrêtée, le signal d'entrée reste au vert. Ce qui veut donc dire que Railworks ne détecte pas un matériel présent sur une portion de voie.

 

Autre gag, j'ai franchi avec cette rame en marche arrière le signal d'entrée et curieusement il a présenté l'avertissement alors que le signal de sortie était au vert.

 

Pour le pas d'IPCS, si l'itinéraire est tracé préalablement, l'aiguillage d'entrée (au carré 1) est positionné vers le pas, celui de sortie (au carré 8) est il me semble, aussi positionné vers la reprise du sens normal et donc le risque de tête à tête n'existe pas puisque le carré 2 sera fermé dans ce cas?

Edited February 2, 2010 by henrion

[Jules31 44]

Ok pour le fait que l'itinéraire soit tracé à la fois pour assurer l'entrée et la sortie du contre-sens.

 

Mais si un train évoluant à contre-voie se présente après coup au carré violet 5 pour récupérer la voie normale ou pour rentrer à contre-sens sur le pas ? On retombe dans les travers précédents.

 

Petite remarque sur la terminologie : l'aiguille n'est pas positionnée vers le pas, mais pour rentrer en contre-sens sur la pas Le pas, c'est une portion unitaire de ligne permettant la circulation à contre-sens (via des IPCS ou ITCS) à l'aide des communications de rentrée et de sortie du contre-sens. Rentrer sur un pas ne veut pas dire "rentrer sur le pas à contre-sens", car on peut également "rentrer sur le pas en sens normal"

Edited February 2, 2010 by Jules31

[GerardS 539]

J'ai essayé aussi de positionner une rame en gare et de lancer le jeu. Même avec cette rame arrêtée, le

Bonjour

 

Même essai

aprés avoir positionné la rame,puis relancé le jeu, le signal reste au vert. Mais si aprés avoir positionné la rame on quitte le jeu, puis on le relance , la rame est détectée et le signal est fermé.

 

L'initialisation de l'itinéraire du scénario s'éffectuant au lancement de Rail Simulator.

(Enfin chez moi il fonctionne comme ça)

 

Cordialement

Geluc

[henrion 101]

Après réflexion, en fait la fonction Initialise() se déclenche lorsque la route se charge où que le scénario est relancé. Donc, si je ne me trompe pas, après toute modification, il faut ressortir (pas forcément du jeu mais en revenant à l'écran de choix des routes) et relancer la route/scénario pour que toutes les modifications soient prises en compte, ce que je n'avais pas fait dans mon test.

Edited February 2, 2010 by henrion

[Jules31 44]

Bonjour.

 

Suite à quelques recherches historiques, je suis tombé sur ce détail qui pourrait intéresser ceux qui se posent des questions sur l'utilisation de l'œilleton.

 

Avant 1974, la règlementation prévoyait l'installation d'un œilleton sur tous les signaux de BAL. A l'époque, la règlementation du BAL prévoyait de privilégier l'observation de l'œilleton à la plaque d'identification. Cela permettait de reconnaitre tout signal qui ne dispose que d'un feu rouge allumé ou qui est éteint. Bien entendu, on avait quand même les plaques Nf ou F qui datent de 1950 (de la définition du BAL unifié SNCF).

 

En 1974, une réforme de la règlementation du BAL a privilégié l'observation de la plaque d'identification sur celle de l'œilleton. Les œilletons étaient alors superflus sur les signaux ne permettant pas d'afficher le carré ou le carré violet avec un sémaphore (la seule présence de la plaque est suffisante). Il a été alors décidé de supprimer tous les œilletons sur ces signaux sauf ceux situés sur portique ou potence pour des raisons de repérages des signaux en hauteur.