EP0773155A1 - Railway interlocking system with logical architecture and implemention method - Google Patents

Abstract

The control system allows the safe movement of trains over the railway network which comprises a number of piece of line equipment. The system includes a number of tasks (Trc-AEA) associated with each of the pieces of line equipment respectively. The tasks form a distributed logic system enabling the establishment of journeys along permitted free routes. A series of logic channels (6) enable the tasks to communicate by propagation of messages following the specific geographical topology of the railway network. The implementation of the system is achieved by computer processing of a file which describes the network, and a library of generic modules each implementing a specific automated process.

Description

The invention relates to safe train traffic on a rail network, and more particularly to a rail interlocking system based on a software architecture.

Such a system is already known from European patent application No. 0581281. 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. In particular, 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. If the rule base is designed to be generic enough, it can be used for implementing other interlocking systems without modification. Despite its flexibility, 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. In particular, 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. .

To this end, 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. In particular, 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.

According to this software architecture, 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. However, since 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. In addition, 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.

An exemplary embodiment of the invention is described above with reference to the figures.

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.

Figure 1, the rail interlocking system 1 according to the invention 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 rail interlocking system is used to establish (interlock) and release routes so as to maintain the safety of traffic on a network. In particular, it is a question of avoiding the collision of trains on the network. However, a collision can occur if, for example, interlocked routes intersect.

The interlocking system 1 according to the invention 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.

More particularly, 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.

Figure 2, 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.

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.

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.

On this network, 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. By way of example, 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. It is understood that 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.

Figure 3, the software architecture of the rail interlocking system corresponding to the rail network of Figure 2 shows the geographic topology of this network. In this figure, 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.

For clarity, the blocks representing the tasks are presented in different forms depending on the type of track equipment associated with each task because the tasks associated with the same type of track equipment have identical logical operation. There are in FIG. 3, 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, a task 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.

Establishment of route R261

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. In the example, 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. In particular, 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). In the case of a conflict situation detected by a task, 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. Figure 4, if all the tasks corresponding to route R261 are allocated for route R261, the last task Sig-265 returns the message Req (R261) to the task Sig-261 entering the route R261. Task Sig-261 sends an Alloc message (R261) to the control station for confirmation. This first process ensures that each task is allocated for a single predefined route whose establishment is required.

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. In particular, the task Sig-261 on reception of the message Req (R261) coming from the task Sig-265 commands the reddening of the signal MP261, collects the information relating to the current state of the signal MP261 and propagates this information in an rtechk parameter included in the Ctrl message (R261, rtechk). 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. Finally, the Sig-265 task returns the message Ctrl (R261, rtechk) to 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. It is possible that the Ctrl message is propagated several times following the command loop before all of the track equipment is positioned correctly due to the fact that the time necessary for some track equipment to change position (change of position d 'a needle) is longer than the time required to propagate the Ctrl message following the command loop.

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.

Automatic release of the established route

When a train sets off on route R261 which has been established, its progress on this route is reflected in changes to the information in the rtechk parameter of the Chk message. Normally, only the multi-aspect input signal of the route R261 can evolve in time, between the moment when the route is established and the moment when it is released, passing successively into the red, orange states. and green. 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. In the example of figure 4, when 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.

It is understood that 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 ...

According to the invention, 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. According to this solution, 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.

More particularly, 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. We find in this file different sections (indicated by "Level 0, Level 1, ....") which define the characteristics of the network, list all the track equipment and identify routes. Thus in the section referenced "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". In the entry or exit message declaration sections, 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.

At the time of the computer processing indicated above with reference to FIG. 5, the source code of 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. It will be readily understood that 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.

Claims (4)

A rail interlocking system based on a software architecture and used for safe train traffic on a rail network made up of a plurality of track equipment, characterized in that it comprises a set of tasks (Trc-AEA, Trc-AEB, ...) associated respectively with the corresponding track equipment (AEA, AEB, ...) constituting the network, in that the tasks implement a distributed logic for the establishment and the release of routes by propagation of messages (Req, Ctrl, Chq, Free) through successions of logical communication channels (6) each interconnecting a message output of a task and a message input of another task, and in that the logical channels of communication are implemented between the tasks according to a provision corresponding to a certain geographic topology of the network. The system according to claim 1, in which the distributed message propagation logic consists of finite state machines implemented in the tasks. The system according to claim 1, in which the distributed logic is arranged to propagate messages through a succession of tasks whose associated track equipment defines a route, such that these messages follow logical communication channels interconnecting these tasks according to a loop starting from the first task of this succession, passing successively through the other tasks of this succession and returning to the first task. A method for implementing a rail interlocking system according to claim 2, comprising the computer processing of a file description of the high level of abstraction of the rail network and of a library of generic software modules each implementing a finite state machine corresponding to a type of track equipment.

Images