Method for requesting and setting a cross-country roadways in railway traffic

Abstract

The present invention discloses a system and a method for requesting and setting routes (9) in rail-bound transport, comprising the following steps: a) providing a control system (2, 2a) for managing rail traffic within a railway network, wherein the railway network, in addition to the actual track network, also includes a depot and / or shunting area (6) with a track system (G1 to G4) and associated train protection systems (W1 to W3, S1 to S3); b) defining a shunting request (11), the associated shunting route (9) of which comprises a number of route elements of the track system and / or the train protection system provided for this purpose and set accordingly;c) Providing a control system-side check instance (12) for the shunting request (11), wherein the check instance has knowledge of data on the topology and / or design of the track and safety system as well as information on the states of the track elements located in the track system; d) Checking the defined shunting request (12) with the control system-side check instance, whereby a check sequence (14) is carried out which checks the requested shunting route (9) for compliance with existing safety regulations and / or queries the interlocking system as to whether the track elements (W1 to W3) affected by the requested shunting route (9) and their setting can be carried out within a predefined period;e) if the verification of the safety regulations and / or the conditions queried by the interlocking system is positive, the shunting request (11) is issued to the interlocking system (4) with the request to set the requested shunting route (9); and f) the route elements (W1 to W3) involved in the requested shunting route (9) are set and the shunting route (9) is released for traversal.

Description

[0001] The present invention relates to a method for requesting and setting routes, in particular shunting routes, in rail-bound transport.

[0002] In rail transport, trains travel the railway network along routes requested by a control system at the operational train control level. This request can be triggered automatically when trains are operating according to schedule, thus ensuring a sequence of previously planned routes. In the event of deviations from the timetable or other interventions, the routes are requested manually by the train dispatcher. Each requested route is only set by a control unit (central or decentralized) once the route elements (points, signals, block occupancy detection, moving block in ETCS) are available and can be set accordingly and locked against other use by competing routes. After the route has been traversed, the route is then...Once the roadway elements located within it are closed, this closure will be lifted and the roadway elements will be available again for setting new routes.

[0003] The situation is different in the so-called depot and / or shunting areas of the railway companies, where trains (both passenger and freight) are configured and parked. Route setting in these depot and / or shunting areas is usually done by local control on site, for which the railway companies generally operate a second system in parallel with the control system out on the track. Unfortunately, this setup does not allow for a comprehensive overview of the existing infrastructure.

[0004] Because the task of setting and releasing shunting routes and carrying out switch maintenance must be performed by the control center of the higher-level control system, and because communication between the train dispatcher and the shunting personnel is carried out by radio, this has already caused coordination problems and unsafe situations in the depot and / or shunting areas.

[0005] Specifically, shunting routes are currently set exclusively manually by the train dispatcher (Fdl) at the ILTIS® control system workstation, for example, on the Swiss Federal Railways (SBB). Before the train dispatcher sets a shunting route requested by a shunting supervisor, they must consider a multitude of factors.

[0006] The train dispatcher must: know which vehicles are to be used for shunting, know which vehicles are where, know the condition of the individual track elements (tracks, points, signals, etc.), know what will change in the foreseeable future, know the capabilities of the shunting and train protection system, know and comply with the regulations.

[0007] Setting shunting routes is therefore a completely manual process, the responsibility of the train dispatcher, with little system support and consequently prone to errors, which can ultimately have negative effects on safety.

[0008] In some Iltis stations, shunting routes are requested via a radio track detector (person / device). However, this primarily simplifies communication. The shunting routes are still set manually by the train dispatcher. The railway companies, however, aim to significantly increase the level of automation in shunting operations.

[0009] The present invention therefore aims to provide a method for requesting and setting routes in rail-bound transport, which makes it possible to avoid unsafe situations in the depot and / or shunting areas and at the same time to have a uniform and reliable overview of the current setting of the track infrastructure and also to increase the degree of automation in shunting.

[0010] This task is accomplished according to the invention by a method for requesting and setting routes in rail-bound traffic, which comprises the following steps: a) Providing a control system for managing rail traffic within a railway network, wherein the railway network includes, in addition to the actual track network, a depot and / or shunting area with a track system and associated train protection systems; b) Defining a shunting request, the associated shunting route of which comprises a number of track elements of the track system and / or the train protection system provided and configured accordingly; c) Providing a control system-side verification instance for the shunting request, wherein the verification instance has knowledge of data on the topology and / or design of the track and protection system as well as information on the states of the track elements located in the track system;d) Checking the defined shunting request with the control system's verification process, whereby a verification sequence is executed that checks the requested shunting route for compliance with existing safety regulations and / or queries the interlocking system to determine whether the route elements affected by the requested shunting route and their settings can be completed within a specified time period; e) if the verification of the safety regulations and / or the interlocking system's statuses are positive, issuing the shunting request to the interlocking system with the request to set the requested shunting route; and f) setting the route elements involved in the requested shunting route and releasing the shunting route for traversal.

[0011] In this way, the present invention ensures that planned / intended shunting movements can be planned and / or optimized in advance in a traffic management system, e.g., TMS at SBB (Swiss Federal Railways), and then transmitted to the control system (Iltis®, ILTIS NETZ®) in a timely manner. Before the request for the actual setting of the shunting route is issued to the interlocking system, the control system's check mechanism verifies whether its implementation violates any regulations and / or whether there is a reasonable chance of the interlocking system successfully setting the shunting route immediately. If these checks are successful, the shunting route can then be set automatically, so that, as a rule, no operator (previously the train dispatcher) is involved.Manual intervention by the train dispatcher at the control system's workstation should only be necessary in exceptional cases. This allows railway companies to successfully pursue two goals: firstly, to increase safety in the shunting route setting process, and secondly, to enable automation in the route setting process.

[0012] In a suitable embodiment of the present invention, the states of the track elements located in the track system can be derived from the process image available on the control system side.

[0013] Further advantageous embodiments of the present invention can be found in the remaining dependent claims.

[0014] Advantageous embodiments of the present invention are explained in more detail with reference to the drawing. The figure shows a schematic view of a solution concept for requesting and setting routes in a shunting area 6, which is simplified here by way of example, incorporating a dispatching control system 2 and an interlocking 4 for this shunting area 6. The shunting area 6 has four shunting tracks G1 to G4, which are accessible via three turnouts W1 to W3 and corresponding dwarf signals S1 to S3 indicating the turnout position. Within the control system 2, here for example the ILTIS Netz® system of Siemens Mobility AG, Wallisellen, Switzerland, a control system cell 2a, specifically adapted to shunting area 6, is configured for processing shunting route requests.

[0015] A shunting route is requested, for example, by a shunting supervisor in the user interface of a train management system 8 – hereinafter referred to as TMS – by the TMS transmitting the desired route (path) in the form of a shunting request 9 in a timely manner via a communication interface 10 to the control system 2, i.e., to its responsible control system cell 2a. In the control system 2, the received shunting request 11 is checked in a function referred to here as RafaController 12. A previously defined check sequence 14 is executed, which ensures that no regulations are violated by the implementation of the shunting request 9 and that there is a good chance of the shunting route 9 being successfully set immediately by the signal box 4.Upon successful verification by the RafaController 12 functionality, an operating request 16 for this shunting route 9 is generated, and a function for processing the operation 18 within the control system 2 issues a command 20 to the relevant signal box 4 to set the shunting route 9 required for implementing the shunting request 11. To perform the verifications, the RafaController 12 functionality requires data on the topology / design of the track and signaling system as well as information 22 on the states of the infrastructure elements, here the tracks G1 to G4, the points W1 to W3, and the dwarf signals S1 to S3, from a process image 24 processed within the control system 2. This process image 24 is generated and displayed, for example, in the form of magnified images in a control center from the data 28 received from signal box 4.At the same time, this data 28 can then be sent to the interface 10 of the TMS 8 in the form of application-compatible data 28' (for example, according to a predefined interface protocol).

[0016] The test sequence 14 is the set of all test steps that this functionality selects from a predefined set of available test steps, which are then executed by the RafaController 12 for each shunting request 11. Test sequence 14 can include test steps that are executed only once, as well as those that are executed continuously until a positive test result is obtained or until an optional time limit specified in the shunting request 11 is reached. The shunting request 11 is considered successfully tested if all test steps of test sequence 14 return a positive result.

[0017] If the RafaController 12 successfully completes the check, the control system 2 issues command 20 to set the shunting route(s) required for implementing shunting request 11 via an interface 26 to the relevant interlocking system 4. If the check fails, for example, because at least one check step in the check sequence returns a negative result after the time limit has expired, a negative confirmation is sent back to the TMS 8. This negative result could, for example, originate from a switch position that is currently locked for another shunting route and is therefore unavailable for a change in switch position. The negative confirmation lists all check steps that returned a negative result after the time limit has expired.

[0018] The test steps to be performed within test sequence 14 are defined directly in the RafaController 12 configuration. It may be possible to configure the system to import a new version of the test sequence at runtime and activate it system-wide at a predetermined time x.

[0019] The special effect of the present invention lies, therefore, in both the method and the system adapted for this purpose, in the fact that an external system (in this case, for example, the TMS 8 of a railway operator (e.g., SBB)) can transmit a shunting route 9 in the form of a shunting request 11 to the control system 2 (in this case, Iltis Netz®). This request is checked in the RafaController 12 functionality and, if successful, output to the signal box 4. Thus, this software solution performs the actions that would otherwise require laborious communication between the train dispatcher and the shunting supervisor. The method according to the invention therefore has the advantage that an external system can automatically set shunting routes 9 in the control system 2 without, as a rule, requiring the involvement of a train dispatcher.

Claims

1. A procedure for requesting and setting routes (9) in rail-bound transport, comprising the following steps: a) providing a control system (2, 2a) for managing rail traffic within a railway network, wherein the railway network includes, in addition to the actual track network, a depot and / or shunting area (6) with a track system (G1 to G4) and associated train protection systems (W1 to W3, S1 to S3); b) defining a shunting request (11), the associated shunting route (9) of which comprises a number of route elements of the track system and / or the train protection system provided and set accordingly;c) Providing a control system-side check instance (12) for the shunting request (11), wherein the check instance has knowledge of data on the topology and / or design of the track and safety system as well as information on the states of the track elements located in the track system; d) Checking the defined shunting request (12) with the control system-side check instance, whereby a check sequence (14) is carried out which checks the requested shunting route (9) for compliance with existing safety regulations and / or queries the interlocking system as to whether the track elements (W1 to W3) affected by the requested shunting route (9) and their setting can be carried out within a predefined period;e) if the verification of the safety regulations and / or the conditions queried by the interlocking system is positive, the shunting request (11) is issued to the interlocking system (4) with the request to set the requested shunting route (9); and f) the route elements (W1 to W3) involved in the requested shunting route (9) are set and the shunting route (9) is released for traversal.

2. Method according to claim 1, characterized by the fact that the states of the track elements located in the track system are derived from the process image (24) available on the control system.

Images