METHOD AND SYSTEM FOR THE AUTOMATED DETERMINATION OF THE TRAIN INTEGRITY OF A TRAIN

Description

The invention relates to a method and a system for the automated determination of the train integrity of a train, in particular for releasing line sections, e.g. as part of ETCS Level 3.

With the planned operation with ETCS Level 3, train integrity monitoring (TIM) is prescribed by standards. An automatic train protection (ATP) system looks for train integrity information about the vehicle at the interface to the vehicle. The train integrity information indicates the current train integrity status. The train integrity information must be validated at a specific safety integrity level, “SIL 2”.

SILs are the measure of the performance or reliability of safety functions and are defined in the IEC61508 and EC61511 standards concerning the “Functional safety of electrical/electronic/programmable electronic (E/E/PE) systems”. There are a total of four SIL levels with ascending levels of required protection.

The most important aspect that must be taken into account here with SIL 2 is the uninterrupted monitoring of train integrity by a safety controller, which should have redundant CPUs and power supplies, redundant network communication infrastructures and processing units, so that train integrity can continue to be monitored in the event of equipment failure.

Since operation with ETCS Level 3 has not yet been implemented, the automated monitoring of train integrity has not yet been relevant in practice.

The object of the present invention is to provide an alternative, more convenient method and a corresponding system for the automated determination of train integrity, which avoids the disadvantages described above and, in particular, enables safe train operation as part of ETCS Level 3.

This object is achieved by a method as claimed in claim 1, a system as claimed in claim 10 and a train as claimed in claim 11.

The method according to the invention for the automated determination of the integrity of a train comprises the following steps:

• • Optional: providing composition data concerning the make-up of the train, comprising at least information about the cars from which the train is composed, to a first central control unit of the train,
  • determining the rear car of the train,
  • transmitting rear car data to the first central control unit of the train during train movement, wherein this data is transmitted continuously throughout said movement, and the transmission of the data is designed such that this data can be assigned to the rear car,
  • generating status information based on the rear car data, wherein, in the event that correct data is received from the rear car by the first central control unit, status information is generated which indicates correct train integrity and, in the event that no correct data is received from the rear car by the first central control unit within a predetermined time period, status information is generated which indicates loss of train integrity,
  • outputting the status information.

During automated determination of the train integrity of a train, a check is performed to ensure that the train is still complete, i.e. that it has not lost any cars. In ETCS Level 3 operation, track vacancy detection and train integrity monitoring are no longer carried out by an interlocking, but by the trains themselves. Trackside track vacancy detection, e.g. by means of axle counters or track circuits, is no longer necessarily provided. In order to be able to run in ETCS Level 3, trains must therefore have a system for train integrity monitoring, which is made possible by the method according to the invention.

The optionally provided train composition data represents information about the make-up of the train, i.e. about its cars and possibly also the car sequence (which is not absolutely necessary, but can make it easier to determine the rear car). There may also be information about the length of the train. It should be noted that the method can provide useful results even without composition data, although this data is very advantageous as it can be used to check whether the determination of the rear car was correct. It therefore constitutes a redundancy that contributes to safety. For example, if a car was erroneously determined as the rear car due to defective sensors in its coupling, this error can be eliminated based on the car sequence information.

As indicated above, the rear car can be determined using a predefined car sequence. However, it is preferably determined independently of this, with particular preference using components that are available to a car for train operation. These include sensors on a coupling that measure whether said coupling is coupled to another car. In a train, all but two cars are normally coupled using both of their couplings. Only the two cars at the front and rear end of the train are coupled with a single coupling. As the driver is in the car at the front end of the train, the car at the rear end of the train (without driver) can be identified as the rear car by this and by its coupling status. The information “car coupled to a single coupling” and “car not occupied by driver” could therefore be used to automatically determine the rear car. In the case of trains made up of two or more multiple units, it may be sufficient to check the status of the end cars of the multiple units in order to determine the rear car. In such a multiple unit train, for example, a central control unit (CCU) in the multiple units can use the “driver's cab occupied” and “coupled” signals to automatically determine whether an end car is at the head end of the train, in the middle of the train or at the rear end of the train. In practice, the CCU can then determine the status of its two end cars in each multiple unit of the train and forward this status to the first (or “leading”) central train control unit in the train.

A train may have a single central control unit, but this is rare. More often, there are a plurality of central control units in a train, especially in a train composed of a plurality of multiple units. There may also be a plurality of CCUs in a multiple unit, e.g. in each of the two end cars of the multiple unit. A “first” central control unit should then be selected. As a rule, this is currently done automatically, wherein the CCU located in the multiple unit (or rather end car) occupied by the driver is selected as the first (leading) CCU.

It is very important for the method that the rear car transmits data continuously to the first central control unit throughout the train movement. This can be done directly, but in practice it is often the case that boundaries to different hierarchies have to be crossed when transmitting data. For example, the data of the rear car can be collected at car level, transmitted to the central control unit of a multiple unit (multiple unit level) and transmitted from there to the first CCU (train level).

Protocols already exist for data transmission, such as “Flexicom”, “Profisafe” or “SPCSsafe”, which can be used for secure data transmission.

It is important that data is transmitted continuously, i.e. that a data set from the rear car repeatedly arrives at the first CCU. These data sets can be separated by time intervals, but these should preferably be shorter than one second. In practice, it is entirely possible for the data from the rear car to arrive at the first CCU after 0.1 seconds.

The data must be transmitted in such a way that it can be assigned to the rear car. This means that the data itself contains information, e.g. an address or identification information, which makes this assignment possible and/or the data channel on which the transmission takes place allows this assignment, e.g. because the data is transmitted via a specific cable or a specific frequency which can be assigned to the rear car. The important consideration here is simply that the first CCU can reliably determine that the received data set indeed originates from the rear car.

The status information can now be generated from knowledge about the receipt or non-receipt of the data from the rear car, which basically only has to report two states: a state (e.g. “OK”) that indicates correct train integrity and a state (e.g. “Lost”) that indicates loss of train integrity. Also advantageous is a third state (e.g. “Unknown”), which can preferably only be attained when the train is at a standstill and indicates that the architecture of the train has changed, e.g. due to the coupling or uncoupling of train components.

The status information is generated based on the data of the rear car. For example, if correct data is received, status information with the status “OK” is generated and if no correct data has been received within a specified period of time, status information with the status “Lost” is generated.

It should be noted that “correct data” refers to data that is normally transmitted by the rear car, i.e. includes predefined information. The term “no correct data” here means that no data set was received by the first CCU or that the data set was incomplete or incorrect in some other way, arrived on an incorrect data channel or its transmission was otherwise corrupted or interrupted. Any data set from the rear car whose transmission (which also means its content) was other than as specified is deemed to be incorrect. This means that in this case no correct rear car data has been received by the first central control unit. In this respect it is preferred that, if a fault is detected, e.g. if something has been lost from the car, its connection to the rest of the train is impaired or some other (serious) error state is present, the rear car will stop sending data or send a data set that deviates from the normal and which can be interpreted by the first CCU as “no correct data”.

The status information can be output to another control unit, e.g. to a so-called “European Vital Computer” (EVC), which can assume control tasks for the operational process within the framework of ETCS Level 3 or pass on relevant information. The status information is therefore preferably made available to the EVC. The EVC reads the status and forwards the status to a control center via the radio LAN connection. If the status “Unknown” or “Lost” is reported, the section of track last traversed by the train is no longer released for succeeding trains.

A system according to the invention for automated determination of the train integrity of a train uses in particular a method according to the invention and comprises the following components:

• • Optional: a data interface designed to receive composition data about the make-up of the train, comprising at least information about the cars from which the train is composed,
  • a determination unit designed to determine the rear car of the train,
  • a data transmission unit designed to transmit data of the rear car to a first central control unit of the train during movement of the train, wherein this data is transmitted continuously throughout the movement and the transmission of the data is designed such that it can be assigned to the rear car,
  • a first central control unit (the one to which the data is transmitted) designed to generate status information based on the data of the rear car, wherein, in the event that correct data from the rear car is received by the first central control unit, status information is generated which indicates correct train integrity and, in the event that no correct data is received from the rear car by the first central control unit, status information is generated which indicates loss of train integrity,
  • a data interface designed to output the status information.

A train according to the invention comprises a number of multiple units and a system according to the invention.

The invention can be implemented in particular in the form of a computer unit, in particular in a control facility, using suitable software. The computer unit can, for example, have one or more cooperating microprocessors or the like for this purpose. In particular, it can be implemented in the form of suitable software program sections in the computer unit. The advantage of a largely software-based implementation is that previously used computer units in multiple units or trains or in the cars thereof can also be easily upgraded by a software or firmware update in order to operate in the manner according to the invention. In this respect, the object is also achieved by a corresponding computer program product comprising a computer program which can be loaded directly into a memory device of a computer unit, having program sections for carrying out all the steps of the method according to the invention when the program is executed in the computer unit. In addition to the computer program, such a computer program product May comprise additional elements such as documentation and/or additional components, including hardware components such as hardware keys (dongles, etc.) for using the software. A computer-readable medium, such as a memory stick, a hard disk or some other transportable or permanently installed data carrier on which the program sections of the computer program that can be read in and executed by a computer unit are stored can be used for transportation to the computer unit and/or for storage on or in the computer unit. Other particularly advantageous embodiments and developments of the invention will emerge from the dependent claims and the following description, wherein the claims of one category of claims can also be further developed analogously to the claims and sections of the description of another category of claims and, in particular, individual features of different exemplary embodiments or variants can also be combined to form new exemplary embodiments or variants.

To determine the rear car, a preferred method involves determining which car of the train is not coupled to one of its two couplings (i.e. is only coupled to one coupling) and whether this car is occupied by a driver and, in the event that a car does not have one of its two couplings coupled, i.e. it is running at the front end or rear end of the train and is not occupied (by said driver), this car is determined to be the rear car. The usual coupling signals and “driver's cab occupied” signals can be used for this purpose, which are present anyway during train operation. The rear car can therefore be determined automatically and no additional equipment needs to be used for this purpose; instead, signals that are usually present during a train movement can be used. Compared to determining the rear car from a predefined car sequence, the safety advantage of this automatic determination is that the actual train is really observed. This eliminates erroneous assumptions about the last car due to an incorrect car sequence. However, the information from the car sequence can serve as a useful verification by checking whether the automatically determined rear car matches the specified rear car in the car sequence. For the purposes of this embodiment, only the end cars of a multiple unit can be regarded as “cars” as these form the ends of the multiple unit.

According to a preferred method, the data transmitted by the rear car is transmitted via a communication channel that can be assigned to the rear car, e.g. via a specific cable, a specific radio frequency or some other specific data channel. Alternatively or additionally, the data from the rear car contains identification information, e.g. an address or an identification number, which can be assigned to the rear car. Theoretically, the mere presence of data could already constitute such an assignment if data is transmitted exclusively from the rear car. In practice, however, it is often the case that at least the end cars of a multiple unit transmit data. In this case, it should be clear which data originates from the rear car.

According to a preferred method, after a coupling operation in which a number of cars have been uncoupled from the train or a number of cars have been coupled to the train, a rear car and a first central control unit are first (re-)determined. It should be noted here that after a coupling operation, e.g. if a train has been divided or multiple units have been added to a train, the rear car usually changes or the first central control unit changes, at least if the driver has changed end car.

The method can preferably also be reinitialized with the provision of (new) composition data about the make-up of the train.

According to a preferred method, the train is made up of a plurality of multiple units. Each multiple unit preferably comprises at least one central control unit. The central control unit of the multiple unit or end car that has an occupied driver's cab during the train movement is then preferably selected as the first (leading) central control unit. It is preferred that the data of the rear car is transmitted from a central control unit of the multiple unit comprising said rear car to the first central control unit of another multiple unit, as the driver is normally located in the frontmost multiple unit and the rear car on the rearmost.

According to a preferred method, at least the data of the rear car is transmitted by means of a data transmission protocol from a car hierarchy, preferably via a multiple unit hierarchy, to a train hierarchy. Alternatively or additionally, the status information is output by means of a data transmission protocol from a train hierarchy, preferably via a multiple unit hierarchy, to a car hierarchy. It is preferred that the data of the rear car and/or the status information is verified by checksums and is preferably transmitted with architecture patterns that have been defined for SIL 2. This guarantees sufficiently secure data transmission.

According to a preferred method, the generating of the status information and the outputting of the status information is designed such that this entire process takes less than one second. Normally, a data transmission only takes a fraction of a second. However, if a plurality of hierarchies are crossed and special safety protocols are applied, a transmission from one hierarchy to another may well take up to 200 ms. Transmission times between hierarchies of more than 10 ms or more than 50 ms are preferred and can typically be assumed to be 100 ms. In addition, there may be time intervals between the transmission of data sets, separating the transmission of successive sets of rear car data. These time intervals should be less than 1 s, as the system should react quickly to the loss of a car.

It is particularly preferred that the predefined period of time, after which status information indicating loss of train integrity is generated if no data from the rear car is received by the first central control unit, is longer than the time of transmission of successive sets of data from the rear car, in particular longer than twice this time. This ensures that a “Lost” status is not set prematurely in the event of a brief interruption of transmission. After all, in such a case the line would be completely closed and only reopened after being fully traversed and inspected. This means that a “Lost” status should only be generated if an emergency situation actually arises and not in the event of a brief interruption of data transmission. For example, in Germany, the time after which a “Lost” status must be assumed following the loss of a car should be under one second. Thus, it would be advantageous if the rear car can transmit its data at least twice within one second so that, in the event that one data set is not received by the first central control unit due to a brief interruption, the second data set can still reach the CCU within the period of one second and prevent a “Lost” status from being set.

According to a preferred method, the status information is output to an EVC control unit (EVC: European Vital Computer).

According to a preferred method, an emergency brake loop (SBS) assigned to the rear car is also checked when the status information is generated. It is preferred that, in the event that the emergency brake loop is open or defective, status information is generated that indicates loss of train integrity and, in the event that the emergency brake loop is intact, there will again be a predefined waiting period for data from the rear car. The SBS thus represents a second mechanism for more reliably determining a status (since an incorrectly determined “Lost” signal has significant operational impact). If the rapid brake loop (SBS) is open, car detachment is highly probable (however, the information from the SBS alone is not sufficiently reliable). In combination with the method according to the invention, however, checking the SBS provides a very advantageous means of increasing the reliability of the conclusion drawn. Even if the SBS is not open, car detachment could still have occurred. In this case, as a precaution, data from the rear car is again awaited. If the data arrives correctly, then the SBS information was incorrect, and operation can continue with the status “OK”. If the data from the rear car does not arrive (or is incorrect), the status would have to be set to “Lost”.

According to a preferred train, each multiple unit comprises a central control unit which is designed to generate status information based on the data from the rear car. Preferably, in the event that data from the rear car is received by the first central control unit, status information indicating train integrity is generated, and in the event that no data from the rear car is received by the first central control unit, status information indicating loss of train integrity is generated.

According to a preferred train, each end car of a multiple unit is designed to determine the status of its couplings and the occupancy status of a driver's cab and to transmit data to a central control unit.

A major advantage of this invention is that it can be implemented using existing communication means. No additional hardware is required. It can be implemented immediately in any train in a simple manner.

The invention will now be explained in more detail with reference to the accompanying drawings using exemplary embodiments. Identical components are provided with the same reference characters in the various figures. The figures are generally not to scale. In the drawings,

FIG. 1 shows an example of a train with two multiple units according to the invention,

FIG. 2 shows an example of a system according to the invention,

FIG. 3 shows a block diagram for an example of a method according to the invention,

FIG. 4 shows a flowchart for carrying out a preferred method.

FIG. 1 shows an example of a train 1 with two multiple units 2 according to the invention. The train 1 is traveling from left to right, as indicated by the driver F schematically illustrated in the right-hand end car E of the right-hand multiple unit 2. The train 1 has a system 4 according to the invention, as shown in more detail in FIG. 2, for example. FIG. 1 shows the central control units 3 in the end cars E, of which the central control unit in the end car E with the driver F is regarded as the first central control unit 3a. Each end car E of a multiple unit 2 is designed here to determine the status of its couplings and the occupancy status of a driver's cab and to transmit data to a central control unit 3.

FIG. 2 shows an example of a system 4 according to the invention for the automated determination of the train integrity of a train 1, as shown, for example, in FIG. 1. The system 4 comprises the following components:

A determination unit 6 designed to determine the rear car S of the train 1. In this example, the determination unit sends an identification number of the determined rear car S to the first central control unit 3a, as indicated by an arrow. A determination unit 6 can actually be a central control unit 3 of an end car E or all the central control units 3 of the end cars E as shown in FIG. 1.

A data transmission unit 7 designed for the transmission (arrow) of data D from the rear car S to the first central control unit 3a of the train 1 during the movement of the train 1, wherein this data D is transmitted continuously throughout said movement and the transmission of the data D is designed such that it can be assigned to the rear car S.

Said first central control unit 3a designed to generate status information St based on the data D of the rear car S, wherein in the event that correct data D is received from the rear car S by the first central control unit 3a, status information St is generated which indicates correct train integrity, and in the event that no correct data D is received from the rear car S by the first central control unit 3a within a predetermined period of time, status information St indicating loss of train integrity is generated.

A data interface 5 designed to output the status information St.

FIG. 3 shows a block diagram for an example of a method according to the invention for the automated determination of the train integrity of a train 1.

In step I, composition data about the make-up of the train is provided which comprises at least information about the cars from which the train is composed. The data is provided to the first central control unit of the train (see e.g. FIG. 2). Although this step is essentially optional, it is extremely advantageous.

In step II, the rear car S of the train 1 is determined. For this purpose, it is preferably determined which car of the train 1 is not coupled to one of its two couplings and whether that car is occupied by a driver F. In the event that one of the two couplings of a car is not coupled and the car is not occupied by a driver, that car is identified as the rear car S. In FIG. 1, for example, the end car E on the far right is the rear car S, as indicated.

It is preferred that after a coupling operation in which a number of cars have been uncoupled from the train 1 or a number of cars have been coupled to the train 1, the rear car S and the first central control unit 3a are re-determined. It is also preferred to provide or update the composition data again.

In step III, data D of the rear car S is transmitted to the first central control unit 3a of the train 1 during movement of the train 1. This data D is transmitted continuously throughout the train movement and the transmission of the data D is designed such that it can be assigned to the rear car S.

The data D transmitted by the rear car S can be transmitted via a communication channel that can be assigned to the rear car S and/or comprise identification information that can be assigned to the rear car S.

In step IV, status information St is generated based on the data D of the rear car S. In the event that correct data D from the rear car S is received by the first central control unit 3a, status information St is generated indicating correct train integrity. In the event that no correct data D is received from the rear car S by the first central control unit 3a within a predetermined period of time, status information St indicating loss of train integrity is generated.

The thick arrow on the symbol of the status information St is intended to indicate that the status information St is then output.

FIG. 4 shows a flow chart for carrying out a preferred method. If a train 1 formed of a plurality of multiple units 2 as shown in FIG. 1 is considered, each multiple unit 2 generally comprises at least one central control unit 3a (in FIG. 1, each multiple unit 2 comprises two). Data originating from cars is often transmitted through a plurality of hierarchies until it arrives at the first central control unit 3a.

A table is shown, the columns of which symbolize different hierarchies from right to left (hereinafter referred to as “levels”). The hierarchy on the right is that of the European Vital Computer EVC, which is positioned here in an end car and is contacted by the car level. To the left of the EVC level is the car level followed by the multiple unit level and the level of the first central control unit 3a, which can also be the train level. The far left and far right show the origins of signals that are not assigned to a specific level here, but may well originate from the individual levels.

The process begins on the far right with two signals, one of which indicates the state where an end car E is occupied by a driver F (top) and one of which indicates the coupling state. The dashed coupling is intended to indicate that a search is carried out for the case where an end car E is coupled with only one coupling and the other coupling is free. It should be noted that in addition to the state of the coupling, the state of the coupling status contactor is often also measured. This indicates whether or not a coupling is meant to be coupled. The process of detecting the end car takes 8 ms, for example.

It is then determined at car level which car is the rear car S. This then sends its data D to the first central control unit 3a via the multiple unit level, e.g. by “Flexi-com” and/or using the “SPCSsafe” protocol. This process can take between 10 and 200 ms, and in this example takes 100 ms.

The first central control unit 3a evaluates all the signals from the end cars and recognizes the signal from the rear car S. In addition, as indicated from the left, information about a coupling operation (top) and the emergency brake loop (SBS, below) can also be made available to the first central control unit 3a.

The first central control unit 3a now generates status information St from the data D of the rear car S and here also using data about coupling operations and data from the SBS. For example, the status information St is “OK” if the rear car S sends correct data D, and “Lost” if no data or incorrect data D is received by the first central control unit 3a. Here it is also possible to determine whether the emergency brake loop SBS of the multiple unit 2 with the rear car is still intact. If it is broken, the status “Lost” is set in any case; if it is intact, the system again waits for data D from the rear car S as a precaution. In the case of a coupling operation, the status can be set to “Unknown” and a rear car S and a first central control unit 3a can be re-determined.

In this example, the status information St is then transmitted from the first central control unit 3a to the European Vital Computer EVC via the multiple unit level and the car level and used for the train movement. Secure data transmission takes between 10 and 200 ms for each level (e.g. 100 ms here) and can be carried out using “Flexicom” and the “Profisafe” protocol. A function that checks whether the EVC has contact with the first central control unit 3a and automatically sets the status “Lost” if contact is lost could be used as an additional safeguard.

Finally, it should be reiterated that the methods described in detail above and the system presented are merely exemplary embodiments which can be modified in various ways by a person skilled in the art without departing from the scope of the invention. In addition, the use of the indefinite articles “a” or “an” does not exclude the possibility that the features in question may be present more than once. Similarly, the terms “unit” and “device” do not preclude the components in question from comprising a plurality of interacting sub-components, which may also be spatially distributed. The term “a number” is to be understood as meaning “at least one”.