Système d'enclenchement ferroviaire à architecture logicielle et son procédé d'implémentation

Abstract

 Un système d'enclenchement ferroviaire, qui sert au trafic des trains en sécurité sur un réseau constitué d'une pluralité d'équipements de voie, comprend un ensemble de tâches (Trc-AEA,...) associées respectivement aux équipements de voie constituant le réseau. Les tâches mettent en oeuvre une logique distribuée d'établissement et de libération d'itinéraires par propagation de messages à travers des successions de canaux (6) logiques de communication interconnectant les tâches suivant une disposition correspondant à une certaine topologie géographique du réseau ferroviaire sous contrôle. L'implémentation du système se fait par un traitement informatique d'un fichier de description du réseau et d'une bibliothèque de modules génériques implémentant chacun un automates à états finis.

Description

[0001] L'invention concerne le trafic des trains en sécurité sur un réseau ferroviaire, et plus particulièrement un système d'enclenchement ferroviaire basé sur une architecture logicielle.

[0002] Un tel système est déjà connu de la demande de brevet européen N°0581281. Ce système comprend une base de règles, un moteur d'inférence, et un modèle de données sur lequel sont appliquées les règles pour établir et libérer des itinéraires. Le modèle de données représente les équipements de voie constituant le réseau par des sortes de portes logiques. Chaque règle définit des conditions à vérifier par une porte logique avant qu'une entrée d'un train sur l'équipement de voie correspondant du réseau soit permise.

[0003] Ce système d'enclenchement présente l'avantage d'être beaucoup plus flexible que les solutions traditionnelles à base de relais. En particulier, un tel système d'enclenchement peut être implémenté par un traitement informatique d'un fichier de description de haut niveau d'abstraction du réseau et de la base de règles de façon à constituer le modèle de données correspondant au réseau à contrôler. Si la base de règles est conçue de façon assez générique, elle peut servir pour l'implémentation d'autres systèmes d'enclenchement sans modification. Malgré sa flexibilité, ce système d'enclenchement ferroviaire connu requiert pour son exécution, une ressource de traitement centralisée dans laquelle réside la base de règles, le modèle de données et le moteur d'inférence. Les capacités de traitement de cette ressource doivent être d'autant plus importantes que le réseau ferroviaire sous contrôle est complexe puisque la complexité du modèle de données croît avec celle du réseau. Il est d'ailleurs suggéré dans le document cité ci-dessus, d'exploiter une ressource multiprocesseurs qui permet de paralléliser certains traitements avec pour inconvénient de rendre la maintenance du système plus complexe.

[0004] Le but de l'invention est de proposer un système d'enclenchement ferroviaire basé sur une architecture logicielle d'une autre conception et susceptible d'être distribué sur une pluralité de ressources de traitement de faible coût comme des micro-ordinateurs. En particulier, l'invention vise à fournir un tel système d'enclenchement ferroviaire apte à exploiter les ressources de traitement déjà en place dans les installations de contrôle/commande de réseaux ferroviaires existants et servant à l'acquisition des signaux provenant des équipements de voie.

[0005] A cet effet, l'invention a pour objet un système d'enclenchement ferroviaire basé sur une architecture logicielle et servant au trafic des trains en sécurité sur un réseau constitué d'une pluralité d'équipements de voie. Ce système comprend un ensemble de tâches associées respectivement aux équipements de voie constituant le réseau. Les tâches mettent en oeuvre une logique distribuée d'établissement et libération d'itinéraires par propagation de messages à travers des successions de canaux logiques de communication interconnectant les tâches suivant une disposition correspondant à une certaine topologie géographique du réseau ferroviaire sous contrôle. En particulier, cette logique distribuée de propagation de messages est implémentée dans les tâches sous la forme d'automates à états finis. Les automates à états finis interagissent entre eux en propageant les messages le long des canaux logiques de communication.

[0006] Selon cette architecture logicielle, les tâches ont un comportement asynchrone. Une grande complexité d'un réseau ferroviaire à contrôler se traduit par un grand nombre de tâches à exécuter. Toutefois, vu que les tâches ont un comportement asynchrone, il n'est pas utile de prévoir une ressource de traitement de très forte capacité pour leur exécution car les tâches peuvent être distribuées sur un ensemble de ressources de traitement de faible capacité d'exécution si seulement un petit nombre de tâches résident dans chaque ressource de traitement de faible capacité, le coût d'un tel ensemble de ressources de traitement de faible capacité étant en plus bien inférieur à celui d'une ressource unique de traitement de capacité équivalente. En plus, le fonctionnement autonome et asynchrone des tâches de la solution selon l'invention permet un contrôle simple du bon fonctionnement de chaque tâche ce qui contribue à diminuer les coûts de maintenance du système d'enclenchement.

[0007] L'invention s'étend à un procédé pour implémenter un tel système d'enclenchement ferroviaire sur la base d'un traitement informatique d'un fichier de description de haut niveau d'abstraction du réseau ferroviaire à contrôler et d'une bibliothèque de modules logiciel génériques implémentant chacun un automate à états finis correspondant à un type d'équipement de voie. La bibliothèque de modules logiciel génériques peut servir, sans modification, à implémenter différents systèmes d'enclenchement pour contrôler différents réseaux ferroviaires correspondants.

[0008] Un exemple de réalisation de l'invention est décrit ci-dessus en référence aux figures.

[0009] La figure 1 montre schématiquement un centre de contrôle électronique intégré incluant le système selon l'invention.

[0010] La figure 2 est un synoptique d'un réseau ferroviaire.

[0011] La figure 3 illustre l'architecture logicielle du système selon l'invention adaptée au réseau ferroviaire montré à la figure 2.

[0012] La figure 4 est un schéma illustrant la propagation de flots de messages à travers des tâches associées à une succession d'équipements de voie correspondants.

[0013] La figure 5 illustre le procédé pour implémenter un système selon l'invention.

[0014] La figure 6 est un synoptique d'un réseau ferroviaire à partir duquel est constitué un fichier de description de haut niveau d'abstraction du réseau.

[0015] Figure 1, le système d'enclenchement ferroviaire 1 selon l'invention fait partie d'un ensemble plus complexe (centre de contrôle électronique intégré) comprenant un poste de contrôle 2 depuis lequel un opérateur surveille la situation sur le réseau ferroviaire 3 sous le contrôle du système d'enclenchement.

[0016] Un système d'enclenchement ferroviaire sert à établir (enclencher) et libérer des itinéraires de telle façon à maintenir la sécurité du trafic sur un réseau. En particulier, il s'agit d'éviter la collision de trains sur le réseau. Or une collision peut survenir si par exemple des itinéraires enclenchés se croisent.

[0017] Le système d'enclenchement 1 selon l'invention comprend un ensemble de tâches associées respectivement à des équipements de voie correspondants constituant le réseau à contrôler et communiquant entre elles par des messages de façon asynchrone comme décrit ci-après.

[0018] Plus particulièrement, les tâches implémentent une logique distribuée pour établir et libérer des itinéraires par propagation de messages à travers des successions de canaux logiques de communication interconnectant chacun une sortie de message d'une tâche et une entrée de message d'une autre tâche. Les canaux logiques de communication sont implémentés entre les tâches suivant une disposition correspondant à une certaine topologie géographique du réseau de telle sorte que chaque succession de canaux logiques de communication correspond en fait à un itinéraire prédéfini de circulation des trains sur le réseau. En d'autres termes, pour un itinéraire passant successivement par une succession d'équipements de voie, il y a une succession correspondante de canaux logiques de communication qui interconnectent des tâches associées à ces équipements.

[0019] La figure 2 montre schématiquement un réseau ferroviaire qui sert d'exemple pour expliquer l'invention et la figure 3 montre l'architecture logicielle du système d'enclenchement ferroviaire correspondant à cet exemple de réseau.

[0020] Figure 2, le réseau ferroviaire comporte deux voies AE et AB couplées par un aiguillage et desservant une gare G. Ce réseau est constitué, d'un point de vue fonctionnel, d'une pluralité d'équipements de voie, la disposition relative des équipements de voie définissant une certaine topologie géographique du réseau.

[0021] Sur la voie AE, on trouve disposés en séquence (de gauche à droite sur la figure 2), un premier circuit de voie référencé AEA, un second circuit de voie AEB, un signal multi-aspects MP263 (feu tricolore par exemple), un premier aiguillage MP2205B (à commande électrique), un second aiguillage MP2206A, un signal de manoeuvre MP1002 (feu bicolore notamment), un troisième circuit de voie AED, un second signal multi-aspects MP265, un quatrième circuit de voie AEE et un cinquième circuit de voie AEF.

[0022] Sur la voie AB, on trouve disposés en séquence (de droite à gauche sur la figure 2), un premier circuit de voie ABE, un second circuit de voie ABG, un premier signal multi-aspects MP262, un troisième circuit de voie ABJ, un premier aiguillage MP2206B, un second aiguillage MP2205A, un second signal multi-aspects MP261, un quatrième circuit de voie ABP et un cinquième circuit de voie ABR.

[0023] Sur ce réseau, les trains peuvent empreinter différents itinéraires prédéfinis partant chacun d'un signal multi-aspects comme le signal MP261 ou d'un signal de manoeuvre et passant par des successions différentes d'équipements de voie. A titre d'exemple, l'itinéraire référencé R261 sur la figure 2, part du signal multi-aspects MP261 et passe successivement par l'aiguillage MP2205A, l'aiguillage MP2206B, l'aiguillage MP2206A, le circuit de voie AED et enfin par le signal multi-aspects MP265. Il est entendu que les signaux font ou non partie d'un itinéraire suivant leur orientation par rapport au sens de circulation du train sur l'itinéraire.

[0024] Figure 3, l'architecture logicielle du système d'enclenchement ferroviaire correspondant au réseau ferroviaire de la figure 2 reprend la topologie géographique de ce réseau. Sur cette figure, les tâches sont représentées par des blocs entre lesquels apparaissent des canaux logiques de communication représentés par des flèches 6. Un canal logique de communication implémenté entre deux tâches correspond à une partie d'un itinéraire passant par les deux équipements de voie associés à ces deux tâches. Si un train peut emprunter cette partie d'itinéraire dans les deux sens de circulation, les tâches correspondantes sont interconnectées par deux canaux logiques de communication parallèles. C'est le cas par exemple pour les deux canaux logiques de communication interconnectant les tâches référencées dPnt-2205A et dPnt-2206B.

[0025] Pour plus de clarté, les blocs représentant les tâches sont présentés suivant des formes différentes en fonction du type d'équipement de voie associé à chaque tâche car les tâches associées à un même type d'équipement de voie ont un fonctionnement logique identique. On distingue sur la figure 3, des tâches Sig-261,Sig-262,Sig-263 et Sig-265 associées chacune à un signal multi-aspects, des tâches Trc-AEA,TrcAEB,Trc-AED,Trc-AEE,Trc-AEF,Trc-ABE,Trc-ABG,Trc-ABJ,Trc-ABP et Trc-ABR associées chacune à un circuit de voie, une tâche Shi-1002 associée à un signal de manoeuvre et des tâches dPnt-2205A,dPnt-2205B,dPnt-2206A et dPnt-2206B associées chacune à un aiguillage.

[0026] Le principe de fonctionnement de la logique distribuée par propagation de messages est décrit ci-après sur la base de l'itinéraire R261 et en référence aux figures 3 et 4. L'itinéraire R261 correspond à une succession des canaux logiques de communication interconnectant en séquence les tâches Sig-261,dPnt-2005A,dPnt-2006B,dPnt-2005B,Trc-AED et Sig-265 dont les blocs correspondant sont montrés hachurés sur la figure 3. L'entrée de l'itinéraire R261 correspond à la tâche Sig-261.

Etablissement de l'itinéraire R261

[0027] L'établissement d'un itinéraire est requis depuis le poste de contrôle 1. Une requête d'établissement de cet itinéraire envoyée du poste de contrôle 1 (symbolisé par Sys sur la figure 4) est reçue par la tâche d'entrée de l'itinéraire sous la forme d'un message d'entrée incluant un identificateur d'itinéraire. Dans l'exemple, la tâche Sig-261 reçoit le message Req(R261), l'identificateur d'itinéraire étant symbolisé par R261. Un premier processus de propagation du message de requête d'établissement de l'itinéraire, depuis la tâche d'entrée de l'itinéraire et suivant une boucle passant par la série de tâches correspondant à cet itinéraire et revenant à la tâche d'entrée de l'itinéraire, est mis en oeuvre par l'ensemble de ces tâches. En particulier, le message R261 est propagé par les tâches Sig-261,dPnt-2005A,dPnt-2006B,dPnt-2005B,TrcAED et Sig-265 suivant une boucle dite boucle d'allocation au cours de laquelle, chaque tâche en question s'alloue pour l'itinéraire R261 sur réception du message Req(R261) sauf en présence d'une situation de conflit (la tâche est déjà allouée pour un autre itinéraire). Dans le cas d'une situation de conflit détectée par une tâche, un message Conf(R261) est remonté, de tâche en tâche, depuis la tâche en question vers la tâche d'entrée d'itinéraire comme la tâche Sig-261, laquelle transmet ce message au poste de contrôle. Figure 4, si toutes les tâches correspondant à l'itinéraire R261 se sont allouées pour l'itinéraire R261, la dernière tâche Sig-265 renvoie le message Req(R261) à la tâche Sig-261 d'entrée de l'itinéraire R261. La tâche Sig-261 envoie un message Alloc(R261) au poste de contrôle pour confirmation. Ce premier processus garantit que chaque tâche s'alloue pour un seul itinéraire prédéfini dont l'établissement est requis.

[0028] Un second processus est ensuite mis en oeuvre par les tâches qui se sont allouées pour un itinéraire, afin de contrôler que l'ensemble des équipements de voie de l'itinéraire sont placés dans une position correcte (positionnement des aiguilles notamment) avant d'ouvrir la circulation d'un train sur l'itinéraire et, dans le cas contraire, les commander pour les placer dans la position requise. Ce second processus consiste encore dans la propagation d'un message Ctrl de tâche en tâche, depuis la tâche d'entrée de l'itinéraire et suivant une boucle dite boucle de commande. sur réception de ce message, chaque tâche commande la mise en position correcte de l'équipement de voie auquel elle est associée et récupère dans un signal d'état une information relative à la position courante occupée par cet équipement. En particulier, la tâche Sig-261 sur réception du message Req(R261) provenant de la tâche Sig-265 commande la mise au rouge du signal MP261, récupère l'information relative à l'état courant du signal MP261 et propage cette information dans un paramètre rtechk inclu dans le message Ctrl(R261,rtechk). Le message Ctrl(R261,rtechk) est propagé de tâche en tâche tandis que le paramètre rtechk est mis à jour par chaque tâche et chaque équipement de voie est commandé pour occuper la position correcte avant l'ouverture de l'itinéraire. Finalement, la tâche Sig-265 renvoie le message Ctrl(R261,rtechk) à la tâche Sig-261. Quand la tâche Sig-261 reçoit le message Ctrl(R261,rtechk), elle effectue un traitement pour contrôler, à partir des informations contenues dans le paramètre rtechk, si l'ensemble des équipements de voie sont positionnés correctement. Si l'ensemble des équipements de voies ne sont pas positionnés correctement, le message Ctrl(R261,rtechk) est de nouveau propagé suivant la boucle de commande. Dans le cas où les équipements de voie sont tous positionnés correctement, la tâche Sig-261 envoie le message Set(R261) au poste de contrôle pour confirmer que l'itinéraire R261 est maintenant établi (ou enclenché) jusqu'à l'occurrence d'une condition de libération. Il est possible que le message Ctrl soit propagé plusieurs fois suivant la boucle de commande avant que l'ensemble des équipements de voie soient positionnés correctement en raison du fait que le temps nécessaire à certains équipements de voie pour changer de position (changement de position d'une aiguille) est plus long que le temps nécessaire pour propager le message Ctrl suivant la boucle de commande.

[0029] Sur réception du message Ctrl(R261,rtechk), la tâche Sig-261 commence un processus de contrôle périodique de l'état des équipements de voie. Ce processus consiste dans la propagation du message Chk(R261,rtechk), de tâche en tâche, suivant une boucle dite boucle de contrôle au cours de laquelle chaque tâche récupère une information relative à l'état courant de l'équipement de voie qui lui est associé et fait remonter cette information dans le paramètre rtechk via le message Chk(R261,rtechk) jusqu'à la tâche d'entrée de l'itinéraire. La tâche Sig-265 renvoie le message Chk(R261,rtechk) à la tâche Sig-261 qui contrôle, à partir du paramètre rtechk, l'état courant des équipements de voie, de sorte qu'un dysfonctionnement des équipements de voie de l'itinéraire enclenché peut facilement être détecté. Ce processus est mis en oeuvre de façon périodique, avec une fréquence assez élevée.

Libération automatique de l'itinéraire établi

[0030] Quand un train s'engage sur l'itinéraire R261 qui a été établi, sa progression sur cet itinéraire se traduit par des changements des informations dans le paramètre rtechk du message Chk. Normalement, seul le signal multi-aspects d'entrée de l'itinéraire R261 peut évoluer dans le temps, entre l'instant où l'itinéraire est établi et l'instant où il est libéré, en passant successivement dans les états rouge, orange et vert. A partir du moment où la tâche Sig-261 détecte que le train a franchi un certain nombre de circuits de voie de l'itinéraire par identification des changements dans le paramètre rtechk à chaque boucle de contrôle, elle commence un processus de libération de l'itinéraire R261 qui consiste encore dans la propagation d'un message, ici le message Free(R261), de tâche en tâche suivant une boucle dite boucle de libération au cours de laquelle chaque tâche se désalloue pour l'itinéraire sur réception du message Free. Dans l'exemple de la figure 4, quand la tâche Sig-261 reçoit le message Free(R261) de la tâche Sig-265, l'ensemble des tâches de l'itinéraire R261 sont désallouées et la tâche Sig-261 envoie ce message au poste de contrôle pour information. A partir de ce moment, la circulation sur l'itinéraire R261 n'est plus autorisée jusqu'à ce que cet itinéraire soit de nouveau établi.

[0031] Il est entendu que cette logique de propagation de messages peut être raffinée, suivant le principe indiqué ci-dessus, pour implémenter d'autre fonctionnalités comme la libération d'itinéraires sur requête de l'opérateur, le maintien permanent d'un itinéraire établi, etc....

[0032] Suivant l'invention, la logique de propagation de messages est constituée avantageusement par des automates à états finis qui sont implémentés dans les tâches. Chaque automate d'une tâche se déclenche sur réception d'un message attendu, transite d'un état courant à un autre état en effectuant un certain traitement et renvoie un message en sortie. Les états successifs de chaque automate correspondent aux processus successifs de propagation des différents messages. Suivant cette solution, l'implémentation du système d'enclenchement ferroviaire 1 peut être réalisée de façon semi-automatique à partir d'un traitement informatique d'un fichier 5 de description de haut niveau d'abstraction du réseau ferroviaire à contrôler et d'une bibliothèque 6 de modules logiciel génériques implémentant chacun un automates à états finis correspondant à un type d'équipement de voie.

[0033] Plus particulièrement, figure 5, à partir d'un synoptique 4 du réseau ferroviaire à contrôler, un technicien exprime les caractéristiques du réseau en données d'un langage de haut niveau d'abstraction, ces données étant consignées dans le fichier de description 5. Un exemple du contenu d'un fichier de description de haut niveau d'abstraction pour le réseau ferroviaire montré à la figure 6 est donné à l'annexe 1 (à noter que ce réseau ferroviaire est analogue à celui montré à la figure 2). Le contenu de ce fichier de description est analogue à celui utilisé pour implémenter le système d'enclenchement ferroviaire connu du brevet européen N°0581281 indiqué comme état de la technique. On retrouve dans ce fichier différentes sections (indiquées par "Level 0, Level 1,...." ) qui définissent les caractéristiques du réseau, répertorient l'ensemble des équipements de voie et identifient des itinéraires. Ainsi à la section référencée "Level 2A", on trouve une description de l'itinéraire R261 qui a servi d'exemple pour la description du fonctionnement de la logique distribuée de propagation des messages.

[0034] Un exemple du code source d'un module logiciel générique implémentant un automate à états finis correspondant à un signal multi-aspects est fourni à l'annexe 2. Un autre exemple du code source d'un module générique correspondant à un circuit de voie est encore fourni à l'annexe 3. Le code source de chaque module est donné ici dans un langage de haut niveau sémantique. Il comprend plusieurs sections et notamment une section de déclaration de messages d'entrée "Input Messages", une section de déclaration de messages de sortie "Output Messages" et une section de déclaration d'états de transition "States". Dans les sections de déclaration de messages d'entrée ou de sortie, l'émetteur ou le récepteur du message est représenté par un identificateur générique tel "Sig","Tim","Sys","Up","Dn","Back". L'annexe 4 illustre les flots de messages Req,Ctrl,Chk etc... en reprenant la terminologie des messages utilisée dans le code source des modules génériques donné aux annexes 2 et 3.

[0035] Au moment du traitement informatique indiqué ci-dessus en référence à la figure 5, le code source de chaque tâche est généré à partir du code source d'un module générique correspondant à l'équipement de voie qui doit être associé à la tâche et les identificateurs génériques d'émetteur et de récepteur de messages sont "remplacés" par des identificateurs de tâche appropriés récupérés du fichier de description du réseau pour établir les canaux logiques de communication. On cmprendra aisément que chaque canal logique de communication est une connexion qui est établie, dans le code source de chaque tâche, par une primitive d'émission ou de réception d'un protocole de communication point à point du type premier entré premier sorti (FIFO). Le code source des tâches est ensuite compilé pour obtenir les tâches exécutables communiquant par messages du système d'enclenchement selon l'invention. Il est entendu que les unités de traitement supportant les tâches devront être connectées entre elles par l'intermédiaire d'un réseau physique de communication, du genre réseau de terrain, qui supporte un protocole de communication comme défini ci-dessus.

Revendications

1. Un système d'enclenchement ferroviaire basé sur une architecture logicielle et servant au trafic des trains en sécurité sur un réseau ferroviaire constitué d'une pluralité d'équipements de voie, caractérisé en ce qu'il comprend un ensemble de tâches (Trc-AEA,Trc-AEB,...) associées respectivement aux équipements de voie (AEA,AEB,...) correspondant constituant le réseau, en ce que les tâches implémentent une logique distribuée pour l'établissement et la libération d'itinéraires par propagation de messages (Req,Ctrl,Chq,Free) à travers des successions de canaux logiques de communication (6) interconnectant chacun une sortie de message d'une tâche et une entrée de message d'une autre tâche, et en ce que les canaux logiques de communication sont implémentés entre les tâches suivant une disposition correspondant à une certaine topologie géographique du réseau.

2. Le système selon la revendication 1, dans lequel la logique distribuée de propagation de messages est constituée par des automates à états finis implémentés dans les tâches.

3. Le système selon la revendication 1, dans lequel la logique distribuée est agencée pour propager des messages à travers une succession de tâches dont les équipements de voie associés définissent un itinéraire, de telle façon que ces messages suivent des canaux logiques de communication interconnectant ces tâches selon une boucle partant de la première tâche de cette succession, passant successivement par les autres tâches de cette succession et revenant à la première tâche.

4. Un procédé pour implémenter un système d'enclenchement ferroviaire selon la revendication 2, consistant dans le traitement informatique d'un fichier de description de haut niveau d'abstraction du réseau ferroviaire et d'une bibliothèque de modules logiciel génériques implémentant chacun un automate à états finis correspondant à un type d'équipement de voie.

Dessins