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

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

Info

Publication number
EP0773155A1
EP0773155A1 EP96402126A EP96402126A EP0773155A1 EP 0773155 A1 EP0773155 A1 EP 0773155A1 EP 96402126 A EP96402126 A EP 96402126A EP 96402126 A EP96402126 A EP 96402126A EP 0773155 A1 EP0773155 A1 EP 0773155A1
Authority
EP
European Patent Office
Prior art keywords
tasks
task
network
message
route
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP96402126A
Other languages
German (de)
English (en)
Inventor
Gilles Antonetti
Yvan Herreros
Guillaume Bres
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alstom Transport SA
Original Assignee
GEC Alsthom Transport SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by GEC Alsthom Transport SA filed Critical GEC Alsthom Transport SA
Publication of EP0773155A1 publication Critical patent/EP0773155A1/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B61—RAILWAYS
    • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
    • B61L19/00—Arrangements for interlocking between points and signals by means of a single interlocking device, e.g. central control
    • B61L19/06—Interlocking devices having electrical operation
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B61—RAILWAYS
    • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
    • B61L1/00—Devices along the route controlled by interaction with the vehicle or vehicle train, e.g. pedals

Definitions

  • the invention relates to safe train traffic on a rail network, and more particularly to a rail interlocking system based on a software architecture.
  • the system includes a rule base, an inference engine, and a data model on which rules are applied to establish and release routes.
  • the data model represents the track equipment constituting the network by sorts of logic gates. Each rule defines conditions to be verified by a logic gate before entry by a train to the corresponding track equipment of the network is permitted.
  • This interlocking system has the advantage of being much more flexible than traditional relay-based solutions.
  • such an interlocking system can be implemented by computer processing of a high level abstraction description file of the network and of the rule base so as to constitute the data model corresponding to the network to be checked.
  • the rule base is designed to be generic enough, it can be used for implementing other interlocking systems without modification.
  • this known rail interlocking system requires, for its execution, a centralized processing resource in which the rule base, the data model and the inference engine resides. The processing capacities of this resource must be all the more important as the rail network under control is complex since the complexity of the data model increases with that of the network. It is moreover suggested in the document cited above, to exploit a multiprocessor resource which makes it possible to parallelize certain treatments with the drawback of making the maintenance of the system more complex.
  • the object of the invention is to propose a rail interlocking system based on a software architecture of another design and capable of being distributed over a plurality of low-cost processing resources such as microcomputers.
  • the invention aims to provide such a rail interlocking system capable of exploiting the processing resources already in place in the control / command installations of existing rail networks and serving for the acquisition of signals from track equipment. .
  • the subject of the invention is a rail interlocking system based on a software architecture and used for the safe train traffic on a network made up of a plurality of track equipments.
  • This system comprises a set of tasks associated respectively with the track equipment constituting the network.
  • the tasks implement a distributed logic of establishment and release of routes by propagation of messages through successions of logical communication channels interconnecting the tasks according to a provision corresponding to a certain geographical topology of the railway network under control.
  • this distributed message propagation logic is implemented in tasks in the form of finite state machines. Finite state machines interact with each other by propagating messages along logical communication channels.
  • the tasks have an asynchronous behavior.
  • the great complexity of a rail network to be checked results in a large number of tasks to be performed.
  • the tasks have an asynchronous behavior, it is not useful to provide a processing resource of very high capacity for their execution because the tasks can be distributed on a low-performing processing resource set if only a small number of tasks reside in each low-capacity processing resource, the cost of such a low-capacity processing resource being much lower than that '' a single processing resource of equivalent capacity.
  • the autonomous and asynchronous operation of the tasks of the solution according to the invention allows simple control of the proper functioning of each task, which contributes to reducing the maintenance costs of the engagement system.
  • the invention extends to a method for implementing such a rail interlocking system on the basis of computer processing of a high level abstraction description file of the rail network to be checked and of a library of modules.
  • generic software each implementing a finite state machine corresponding to a type of track equipment.
  • the library of generic software modules can be used, without modification, to implement different interlocking systems to control different corresponding rail networks.
  • Figure 1 schematically shows an integrated electronic control center including the system according to the invention.
  • Figure 2 is a block diagram of a rail network.
  • FIG. 3 illustrates the software architecture of the system according to the invention adapted to the rail network shown in FIG. 2.
  • FIG. 4 is a diagram illustrating the propagation of message streams through tasks associated with a succession of corresponding channel equipment.
  • FIG. 5 illustrates the method for implementing a system according to the invention.
  • Figure 6 is a block diagram of a rail network from which a high-level network abstraction description file is made.
  • the rail interlocking system 1 is part of a more complex assembly (integrated electronic control center) comprising a control station 2 from which an operator monitors the situation on the rail network 3 under control of the interlocking system.
  • a control station 2 from which an operator monitors the situation on the rail network 3 under control of the interlocking system.
  • a rail interlocking system is used to establish (interlock) and release routes so as to maintain the safety of traffic on a network.
  • interlock it is a question of avoiding the collision of trains on the network.
  • a collision can occur if, for example, interlocked routes intersect.
  • the interlocking system 1 comprises a set of tasks respectively associated with corresponding channel equipment constituting the network to be controlled and communicating with each other by messages asynchronously as described below.
  • the tasks implement a distributed logic for establishing and freeing routes by propagation of messages through successions of logical communication channels each interconnecting a message output of a task and a message input of another task.
  • the logical communication channels are implemented between the tasks according to an arrangement corresponding to a certain geographical topology of the network so that each succession of logical communication channels corresponds in fact to a predefined route for the circulation of trains on the network. In other words, for a route passing successively through a succession of track equipment, there is a corresponding succession of logical communication channels which interconnect tasks associated with this equipment.
  • FIG. 2 schematically shows a rail network which serves as an example to explain the invention and
  • FIG. 3 shows the software architecture of the rail interlocking system corresponding to this example of network.
  • the rail network comprises two tracks AE and AB coupled by a switch and serving a station G.
  • This network consists, from a functional point of view, of a plurality of track equipment, the relative arrangement of the equipment of track defining a certain geographic topology of the network.
  • a first track circuit referenced AEA On the AE track, there is arranged in sequence (from left to right in FIG. 2), a first track circuit referenced AEA, a second track circuit AEB, a multi-aspect signal MP263 (three-color light for example), a first switch MP2205B (electrically controlled), a second switch MP2206A, an operating signal MP1002 (two-color light in particular), a third AED track circuit, a second multi-aspect signal MP265, a fourth AEE track circuit and a fifth circuit AEF track.
  • a first track circuit referenced AEA On the AE track, there is arranged in sequence (from left to right in FIG. 2), a first track circuit referenced AEA, a second track circuit AEB, a multi-aspect signal MP263 (three-color light for example), a first switch MP2205B (electrically controlled), a second switch MP2206A, an operating signal MP1002 (two-color light in particular), a third AED track circuit
  • a first ABE channel circuit On the AB channel, there are arranged in sequence (from right to left in FIG. 2), a first ABE channel circuit, a second ABG channel circuit, a first multi-aspect signal MP262, a third ABJ channel circuit, a first switch MP2206B, a second switch MP2205A, a second multi-aspect signal MP261, a fourth ABP channel circuit and a fifth ABR channel circuit.
  • trains can use different predefined routes, each starting from a multi-aspect signal such as the MP261 signal or from a switching signal and passing through different successions of track equipment.
  • a multi-aspect signal such as the MP261 signal or from a switching signal and passing through different successions of track equipment.
  • the route referenced R261 in FIG. 2 starts from the multi-aspect signal MP261 and passes successively through the switch MP2205A, the switch MP2206B, the switch MP2206A, the track circuit AED and finally by the multi-aspect signal MP265.
  • the signals are or are not part of a route depending on their orientation with respect to the direction of travel of the train on the route.
  • FIG 3 the software architecture of the rail interlocking system corresponding to the rail network of Figure 2 shows the geographic topology of this network.
  • the tasks are represented by blocks between which appear logical communication channels represented by arrows 6.
  • a logical communication channel implemented between two tasks corresponds to part of a route passing through the two associated track equipments. to these two tasks. If a train can travel this part of the route in both directions, the corresponding tasks are interconnected by two logical channels of parallel communication. This is the case for example for the two logical communication channels interconnecting the tasks referenced dPnt-2205A and dPnt-2206B.
  • tasks Sig-261, Sig-262, Sig-263 and Sig-265 each associated with a multi-aspect signal
  • tasks Trc-AEA, TrcAEB, Trc-AED, Trc-AEE, Trc -AEF, Trc-ABE, Trc-ABG, Trc-ABJ, Trc-ABP and Trc-ABR each associated with a track circuit
  • tasks Shi-1002 associated with an operating signal and tasks dPnt-2205A, dPnt- 2205B, dPnt-2206A and dPnt-2206B each associated with a switch.
  • the operating principle of the logic distributed by message propagation is described below on the basis of the route R261 and with reference to FIGS. 3 and 4.
  • the route R261 corresponds to a succession of the logical communication channels interconnecting in sequence Sig-261, dPnt-2005A, dPnt-2006B, dPnt-2005B, Trc-AED and Sig-265 whose corresponding blocks are shown hatched in Figure 3.
  • the entry of route R261 corresponds to task Sig-261.
  • the establishment of a route is required from control station 1.
  • a request to establish this route sent from control station 1 (symbolized by Sys in FIG. 4) is received by the input task of the route in the form of an entry message including a route identifier.
  • task Sig-261 receives the message Req (R261), the route identifier being symbolized by R261.
  • a first process for propagating the route establishment request message, from the route entry task and following a loop passing through the series of tasks corresponding to this route and returning to the entry task of the route, is implemented by all of these tasks.
  • the message R261 is propagated by the tasks Sig-261, dPnt-2005A, dPnt-2006B, dPnt-2005B, TrcAED and Sig-265 following a loop called allocation loop during which, each task in question s allocates for route R261 on receipt of the Req message (R261) except in the presence of a conflict situation (the task is already allocated for another route).
  • a Conf message (R261) is raised, from task to task, from the task in question to the route entry task such as task Sig-261, which transmits this message to the control post.
  • a second process is then implemented by the tasks which have been allocated for a route, in order to check that all the track equipment of the route is placed in a correct position (positioning of the needles in particular) before opening the running of a train on the route and, if not, order them to place them in the required position.
  • This second process also consists in the propagation of a Ctrl message from task to task, from the entry task of the route and following a loop called the control loop. on receipt of this message, each task commands the correct positioning of the track equipment with which it is associated and recovers in a status signal information relating to the current position occupied by this equipment.
  • the message Ctrl (R261, rtechk) is propagated from task to task while the parameter rtechk is updated by each task and each track equipment is ordered to occupy the correct position before the route is opened.
  • the Sig-265 task returns the message Ctrl (R261, rtechk) to the Sig-261 task.
  • the Sig-261 task When the Sig-261 task receives the Ctrl message (R261, rtechk), it performs processing to check, from the information contained in the rtechk parameter, whether all the track equipment is positioned correctly. If all the track equipment is not positioned correctly, the message Ctrl (R261, rtechk) is propagated again according to the command loop. If the track equipment is all correctly positioned, the Sig-261 task sends the message Set (R261) to the control station to confirm that the route R261 is now established (or initiated) until the occurrence of a release condition.
  • the Sig-261 task Upon receipt of the Ctrl message (R261, rtechk), the Sig-261 task begins a process of periodically checking the condition of the track equipment. This process consists in the propagation of the message Chk (R261, rtechk), from task to task, following a loop called control loop during which each task recovers information relating to the current state of the track equipment which it is associated and sends this information back in the rtechk parameter via the Chk message (R261, rtechk) to the route entry task.
  • Task Sig-265 returns the message Chk (R261, rtechk) to task Sig-261 which checks, from the parameter rtechk, the current state of the track equipment, so that a malfunction of the track equipment of the the started route can easily be detected. This process is carried out periodically, with a fairly high frequency.
  • task Sig-261 From the moment that task Sig-261 detects that the train has crossed a certain number of track circuits of the route by identifying the changes in the rtechk parameter at each control loop, it begins a process of releasing the route R261 which still consists in the propagation of a message, here the Free message (R261), from task to task following a loop called loop release during which each task reallocates for the route on receipt of the Free message.
  • the task Sig-261 receives the message Free (R261) from the task Sig-265, all the tasks of the route R261 are deallocated and the task Sig-261 sends this message at the checkpoint for information. From this moment, traffic on the R261 route is no longer authorized until this route is established again.
  • this message propagation logic can be refined, according to the principle indicated above, to implement other functionalities such as the release of routes at the request of the operator, the permanent maintenance of an established route, etc ...
  • the message propagation logic is advantageously constituted by finite state automata which are implemented in the tasks.
  • Each automaton of a task is triggered on reception of an expected message, transits from a current state to another state by carrying out a certain processing and returns an output message.
  • the successive states of each automaton correspond to the successive processes of propagation of the different messages.
  • the implementation of the rail interlocking system 1 can be carried out semi-automatically from a computer processing of a file 5 of high level abstraction description of the rail network to be checked and a library 6 of generic software modules each implementing a finite state machine corresponding to a type of track equipment.
  • FIG. 5 from a block diagram 4 of the rail network to be checked, a technician expresses the characteristics of the network into high-level abstraction language data, this data being recorded in the description file 5.
  • An example of the content of a high-level abstraction description file for the rail network shown in Figure 6 is given in Annex 1 (note that this rail network is similar to that shown in Figure 2).
  • the content of this description file is analogous to that used to implement the rail interlocking system known from European patent No. 0581281 indicated as state of the art.
  • Level 2A there is a description of the route R261 which served as an example for the description of the operation of the distributed logic of propagation of messages.
  • An example of the source code of a generic software module implementing a finite state automaton corresponding to a multi-aspect signal is provided in appendix 2.
  • Another example of the source code of a generic module corresponding to a track circuit is also provided in appendix 3.
  • the source code of each module is given here in a high level semantic language. It comprises several sections and in particular a section for declaring input messages "Input Messages", a section for declaring output messages "Output Messages" and a section for declaring transition states "States".
  • the sender or receiver of the message is represented by a generic identifier such as "Sig”, “Tim”, “Sys", “Up”, “Dn", " Back ".
  • Appendix 4 illustrates the flow of messages Req, Ctrl, Chk etc ... by taking again the terminology of the messages used in the source code of the generic modules given in appendices 2 and 3.
  • each task is generated from the source code of a generic module corresponding to the track equipment which must be associated with the task and the Generic message sender and receiver identifiers are "replaced" by appropriate task identifiers retrieved from the network description file to establish logical communication channels.
  • each logical communication channel is a connection which is established, in the source code of each task, by a primitive for transmitting or receiving a point-to-point communication protocol of the first in first out (FIFO) type. ).
  • the source code of the tasks is then compiled to obtain the executable tasks communicating by messages of the interlocking system according to the invention. It is understood that the processing units supporting the tasks must be connected to each other via a physical communication network, of the field network type, which supports a communication protocol as defined above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Automation & Control Theory (AREA)
  • Train Traffic Observation, Control, And Security (AREA)
  • Electric Propulsion And Braking For Vehicles (AREA)

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. <IMAGE>

Description

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Un exemple de réalisation de l'invention est décrit ci-dessus en référence aux figures.
  • La figure 1 montre schématiquement un centre de contrôle électronique intégré incluant le système selon l'invention.
  • La figure 2 est un synoptique d'un réseau ferroviaire.
  • La figure 3 illustre l'architecture logicielle du système selon l'invention adaptée au réseau ferroviaire montré à la figure 2.
  • 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.
  • La figure 5 illustre le procédé pour implémenter un système selon l'invention.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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
  • 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.
  • 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....
  • 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.
  • 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.
  • 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.
  • 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.
    Figure imgb0001
    Figure imgb0002
    Figure imgb0003
    Figure imgb0004
    Figure imgb0005
    Figure imgb0006
    Figure imgb0007
    Figure imgb0008
    Figure imgb0009
    Figure imgb0010
    Figure imgb0011
    Figure imgb0012
    Figure imgb0013
    Figure imgb0014
    Figure imgb0015
    Figure imgb0016
    Figure imgb0017
    Figure imgb0018
    Figure imgb0019
    Figure imgb0020
    Figure imgb0021
    Figure imgb0022
    Figure imgb0023
    Figure imgb0024
    Figure imgb0025
    Figure imgb0026
    Figure imgb0027
    Figure imgb0028
    Figure imgb0029
    Figure imgb0030
    Figure imgb0031
    Figure imgb0032
    Figure imgb0033
    Figure imgb0034
    Figure imgb0035
    Figure imgb0036
    Figure imgb0037
    Figure imgb0038
    Figure imgb0039
    Figure imgb0040
    Figure imgb0041
    Figure imgb0042
    Figure imgb0043
    Figure imgb0044
    Figure imgb0045
    Figure imgb0046
    Figure imgb0047
    Figure imgb0048
    Figure imgb0049
    Figure imgb0050
    Figure imgb0051

Claims (4)

  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.
EP96402126A 1995-10-13 1996-10-07 Système d'enclenchement ferroviaire à architecture logicielle et son procédé d'implémentation Withdrawn EP0773155A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9512026A FR2739824B1 (fr) 1995-10-13 1995-10-13 Systeme d'enclenchement ferroviaire a architecture logicielle et son procede d'implementation
FR9512026 1995-10-13

Publications (1)

Publication Number Publication Date
EP0773155A1 true EP0773155A1 (fr) 1997-05-14

Family

ID=9483497

Family Applications (1)

Application Number Title Priority Date Filing Date
EP96402126A Withdrawn EP0773155A1 (fr) 1995-10-13 1996-10-07 Système d'enclenchement ferroviaire à architecture logicielle et son procédé d'implémentation

Country Status (12)

Country Link
EP (1) EP0773155A1 (fr)
JP (1) JPH09123912A (fr)
KR (1) KR970020825A (fr)
CN (1) CN1158803A (fr)
AU (1) AU6815596A (fr)
BR (1) BR9605136A (fr)
CA (1) CA2187817A1 (fr)
FR (1) FR2739824B1 (fr)
MX (1) MX9604771A (fr)
NO (1) NO964327L (fr)
TW (1) TW381198B (fr)
ZA (1) ZA968654B (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998056635A1 (fr) * 1997-06-10 1998-12-17 Siemens Aktiengesellschaft Dispositif pour commander des passages a niveau
WO2000010860A1 (fr) * 1998-08-19 2000-03-02 Siemens Schweiz Ag Procede de commande et de surveillance d'une installation de prevision d'ecoulement du trafic
EP1273499A1 (fr) 2001-07-05 2003-01-08 Alcatel Procédé de formation et de gestion d'itinéraires et réseau mettant en oeuvre un tel procédé
WO2004044788A1 (fr) * 2002-11-14 2004-05-27 Alstom Ferroviaria S.P.A Dispositif et procede de verification des moteurs logiciels de chemin de fer permettant de commander des installations telles que des gares
EP3258400A1 (fr) * 2016-06-14 2017-12-20 ALSTOM Transport Technologies Procédé et système de conception permettant de concevoir un système de commande d'interverrouillage

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9003039B2 (en) * 2012-11-29 2015-04-07 Thales Canada Inc. Method and apparatus of resource allocation or resource release
EP3071469B1 (fr) * 2013-12-30 2019-05-15 INEO Urban Transportation Solutions Procédé et dispositif informatisé pour l'enclenchement d'un itinéraire ferroviaire

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR1350263A (fr) * 1963-03-01 1964-01-24 Ericsson Telefon Ab L M Agencement de transmission de signaux
FR1408405A (fr) * 1964-07-10 1965-08-13 Ericsson Telefon Ab L M Agencement pour la recherche d'un itinéraire sur une installation de voie ferrée
EP0105182A2 (fr) * 1982-08-31 1984-04-11 Alcatel N.V. Dispositif d'enclenchement décentralisé de voies dans une installation d'enclenchement de la voie ferrée
EP0407875A2 (fr) * 1989-07-10 1991-01-16 IVV Ingenieurgesellschaft für Verkehrsplanung und Verkehrssicherung GmbH Procédé et agencement pour la configuration d'un système de commande pour rails
DE4406924A1 (de) * 1994-02-28 1995-08-31 Siemens Ag Verfahren zum synchronisierten Betrieb eines aus mehreren Rechnern bestehenden verteilten Datenverarbeitungssystems und Einrichtung zur Anwendung des Verfahrens

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR1350263A (fr) * 1963-03-01 1964-01-24 Ericsson Telefon Ab L M Agencement de transmission de signaux
FR1408405A (fr) * 1964-07-10 1965-08-13 Ericsson Telefon Ab L M Agencement pour la recherche d'un itinéraire sur une installation de voie ferrée
EP0105182A2 (fr) * 1982-08-31 1984-04-11 Alcatel N.V. Dispositif d'enclenchement décentralisé de voies dans une installation d'enclenchement de la voie ferrée
EP0407875A2 (fr) * 1989-07-10 1991-01-16 IVV Ingenieurgesellschaft für Verkehrsplanung und Verkehrssicherung GmbH Procédé et agencement pour la configuration d'un système de commande pour rails
DE4406924A1 (de) * 1994-02-28 1995-08-31 Siemens Ag Verfahren zum synchronisierten Betrieb eines aus mehreren Rechnern bestehenden verteilten Datenverarbeitungssystems und Einrichtung zur Anwendung des Verfahrens

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998056635A1 (fr) * 1997-06-10 1998-12-17 Siemens Aktiengesellschaft Dispositif pour commander des passages a niveau
WO2000010860A1 (fr) * 1998-08-19 2000-03-02 Siemens Schweiz Ag Procede de commande et de surveillance d'une installation de prevision d'ecoulement du trafic
EP1273499A1 (fr) 2001-07-05 2003-01-08 Alcatel Procédé de formation et de gestion d'itinéraires et réseau mettant en oeuvre un tel procédé
FR2826921A1 (fr) * 2001-07-05 2003-01-10 Cit Alcatel Procede de formation et de gestion d'itineraires et reseau mettant en oeuvre un tel procede
WO2004044788A1 (fr) * 2002-11-14 2004-05-27 Alstom Ferroviaria S.P.A Dispositif et procede de verification des moteurs logiciels de chemin de fer permettant de commander des installations telles que des gares
EP3258400A1 (fr) * 2016-06-14 2017-12-20 ALSTOM Transport Technologies Procédé et système de conception permettant de concevoir un système de commande d'interverrouillage

Also Published As

Publication number Publication date
AU6815596A (en) 1997-04-17
NO964327L (no) 1997-04-14
FR2739824A1 (fr) 1997-04-18
KR970020825A (ko) 1997-05-28
MX9604771A (es) 1997-08-30
JPH09123912A (ja) 1997-05-13
CA2187817A1 (fr) 1997-04-14
TW381198B (en) 2000-02-01
BR9605136A (pt) 1998-07-07
ZA968654B (en) 1997-05-13
NO964327D0 (no) 1996-10-11
FR2739824B1 (fr) 1997-11-14
CN1158803A (zh) 1997-09-10

Similar Documents

Publication Publication Date Title
EP0076196A1 (fr) Système d&#39;arbitrage des demandes d&#39;accès de plusieurs processeurs à des ressources communes, par l&#39;intermédiaire d&#39;un bus commun
FR2694828A1 (fr) Bus d&#39;ordinateur à transfert de paquets.
EP0616477A1 (fr) Dispositif de recherche du chemin de moindre coût dans un réseau de télécommunication
FR2728749A1 (fr) Procede de commande d&#39;un sous-systeme d&#39;exploitation et de gestion pour un systeme n[1 d&#39;echange de messages de signalisation
FR2467523A1 (fr) Systeme de controle d&#39;un reseau de connexion
EP0773155A1 (fr) Système d&#39;enclenchement ferroviaire à architecture logicielle et son procédé d&#39;implémentation
FR2649574A1 (fr) Reseau de communication entre equipements utilisateurs
FR2598575A1 (fr) Dispositif de commande de reseau de zone locale
FR2547686A1 (fr) Circuit de test a bouclage de systeme de commutation
FR2750276A1 (fr) Procede de commande de transfert d&#39;informations entre les composants ainsi que composants pour la mise en oeuvre du procede
CA1209712A (fr) Procede et installation de transmission de donnees numeriques
EP1531589B1 (fr) Système et procédé de transmission d&#39;une séquence de messages dans un réseau d&#39;interconnexions
FR2774536A1 (fr) Procede de detection d&#39;un ou plusieurs canaux libres dans un multiplex temporel optique, un dispositif de mise en oeuvre et une application du dispositif
CA2115880A1 (fr) Centre satellite a technologie mixte photonique-electronique pour raccorder des lignes d&#39;abonne optiques a un reseau de telecommunication a mode de transfert asynchrone
EP0838968B1 (fr) Réseau local d&#39;accès à des mobiles et un procédé d&#39;aiguillage dans un tel réseau
FR2689265A1 (fr) Système de communication entre des cartes de communication montées séparément dans des étagères.
EP0011540B1 (fr) Dispositif d&#39;interface entrée-sortie entre un commutateur de données et une pluralité de voies de transmission
EP0818686A1 (fr) Dispositif de commutation notamment de système sous test
FR2694468A1 (fr) Procédé et système de communication entre un équipement appelant et un équipement appelé via un autocommutateur.
FR2577849A1 (fr) Systeme de commande pour machines a imprimer
EP0877484B1 (fr) Dispositif de validation de messages numériques, applicable notamment aux systèmes de régulation du trafic ferroviaire
FR2710804A1 (fr) Dispositif numérique de connexion d&#39;une pluralité de stations de travail sur un réseau local en anneau.
EP0471633A1 (fr) Réseau de communication à anneau d&#39;écriture et anneau de lecture et procédé d&#39;accès et de reconfiguration d&#39;un tel réseau
EP1273499A1 (fr) Procédé de formation et de gestion d&#39;itinéraires et réseau mettant en oeuvre un tel procédé
EP1087568B1 (fr) Procédé et dispositif de gestion des circuits de transmission d&#39;un réseau

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH DE ES FI GB GR IE IT LI LU NL PT SE

17P Request for examination filed

Effective date: 19971001

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Withdrawal date: 19990327