GB2580873A

GB2580873A - Method and arrangement for safely operating at least one track-bound vehicle

Info

Publication number: GB2580873A
Application number: GB1817957.2A
Authority: GB
Inventors: Bocionek Siegfried
Original assignee: Bombardier Transportation GmbH
Current assignee: Alstom Transportation Germany GmbH
Priority date: 2018-11-02
Filing date: 2018-11-02
Publication date: 2020-08-05
Also published as: GB201817957D0

Abstract

A method and system for operating a track-bound vehicle comprising operating at least one vehicle 10, providing data concerning the vehicle to a virtual model of the track bound vehicle. Simulating, using the virtual model and the received data a future state of the vehicle, the simulation predicting future events up to a predication time margin. The simulation being used to identify a critical operating state of the vehicle. The data relating to the track vehicle may be travel speed, acceleration and/or vehicle location. The critical operating state of the vehicle may be a potential crash of the vehicle and/or the vehicle being at an unsafe position. The critical operating state may alternatively be potential malfunction of the vehicle. Where a critical operating state is detected an automatic corrective action, such as breaking, is carried out.

Description

Method and Arrangement for safely operating at least one track-bound vehicle The invention relates to a method and an arrangement for operating of at least one track-bound vehicle.

For ensuring the safe operation of track-bound vehicles, such as trains, locomotives or trams, it is known to include various safety measures. These include external signaling equipment (e.g. wayside signaling systems) for coordinating the movement of a plurality of vehicles. Also, vehicle integrated sensors may be used in conjunction with a so-called ATP (automatic train protection system) that checks whether travelling speeds are within a permitted range and may initiate automated corrective actions (e.g. braking). For doing so, the ATP may communicate with a signaling infrastructure through track-mounted devices (e.g. balises, track circuits) or via a wireless communication network.

It is also known that with help of so-called railroad control centres or operating control systems, the movements of trains within a railroad network as well as the states of infrastructure elements, such as signalling equipment or railroad switches, can be monitored in real-time. This may e.g. be done with help of so-called RBC-systems (radio block centre) or electronic interlocking systems. In this context, it is also state of the art to gather data on the trains and infrastructure elements in order to monitor their current operating states.

These known solutions focus on detecting operational states of the vehicle within their real world physical environment in a real-time manner. The costs of these solutions is comparatively high due to the necessary hardware components for gathering data. Moreover, these solutions focus on real-time operational states of the vehicles only and may thus not be able to pre-emptively avoid critical situations that lie ahead.

From DE 10 2014 226 910 Al it is further known to provide a wayside hardware-in-theloop system in which real world vehicle data are used for operating a simulation unit that includes hardware components to be tested. It is also mentioned to, by means of the simulation unit, determine a target vehicle state and to compare this to an actual vehicle state in order to detect an unsafe operation. Again, this focuses on real-time operational states of the vehicle and, moreover, on testing selected hardware components.

It is an objective of the invention to improve the operational safety of track-bound vehicles.

This objective is solved by a method and arrangement according to the attached independent claims. Advantageous embodiments are defined in the dependent claims.

According to a basic idea of the invention, a virtual model of the real-world vehicle is provided and said virtual model is used to run a simulation for predicting future operating states and in particular movements of the vehicle. This way, the safe operation of the vehicle cannot only be achieved with regard to a current point of time. Rather, the simulation allows for a predictive assessment of the operational states of the vehicle in the preferably near future, thereby determining potentially critical operational states ahead of time. Differently put, the simulation runs ahead of the real world vehicle operation, so that that safety measures can be activated before a critical scenario predicted by and/or occurring in the simulation actually arises in the real world.

This increases safety since critical scenarios may be avoided before they actually arise (i.e. the invention not being limited to reacting to critical scenarios occurring in the real world, but to pre-emptively avoid them). Moreover, this offers a cost saving potential as hardware components for detecting real-time operating states of the vehicle may be omitted, reduced or may be designed with a reduced performance.

In more detail, a method for operating at least one track-bound vehicle, such as a train, tram or locomotive, is suggested, the method comprising: operating (in particular moving) at least one track-bound vehicle in the real world (e.g. by driving it along tracks or a track system or, differently put, a railroad network); providing a virtual model of said track-bound vehicle (e.g. in a virtual simulation environment); receiving data concerning at least one current operating parameter of the vehicle; running a simulation based on the received data and the virtual model in order to predict a future vehicle operating state (e.g. future vehicle movements and/or locations), the simulation being directed at a future point of time lying ahead a current point of time by a prediction time margin (or, differently put, a look-ahead time margin or a defined time margin); and identifying a critical operating state of the vehicle based on said simulation, wherein said identification may e.g. automatically take place as a part of the simulation and/or wherein said identification is manually carried out by or a person supervising the simulation.

The virtual model and/or the simulation may be provided by means of a simulation unit. The simulation unit may comprise at least one computing device and/or a processing unit, such as a microprocessor. The simulation may be run by means of a computer program (i.e. software) executed with help of the simulation unit. The simulation may be purely virtually executed (i.e. the virtual model may be provided purely virtually and not comprise any real world physical actuators and/or hardware components). Instead, the simulation may fully be based on computer-generated models.

In the context of this disclosure, the term virtual may be understood as relating to a digital and/or computed feature that is e.g. provided by and/or operated with help of a computer and e.g. displayed on a computer screen, but not existing as an actual physical object in the real world.

The simulation unit may be vehicle-bound. According to an embodiment, however, the simulation unit is a wayside and/or stationary unit that is provided externally of the vehicle. For example, the simulation unit may be provided in or as part of a railroad control centre or, differently put, an operation control system used for operating a railroad network. This allows running the simulation for a plurality of real-world vehicles and/or for said simulation to be supervised by a further person apart from an actual train conductor, thereby increasing safety.

Note that in case the simulation unit is vehicle-bound, it may equally be possible to run the simulation with regard to a plurality of vehicles, e.g. in case the vehicle is configured to receive data from other vehicles. This way, a plurality of vehicles within a railway network may each run their own simulations while communicating with one another, e.g. in order to avoid crashes. However, for reasons of efficiency, it may generally be preferred to provide the simulation unit as part of a (central) railroad control centre which supervises and controls the operation of a larger railway network as well as the vehicles operated therein.

Note that the term virtual can but must not necessarily imply a virtual representation of a respective feature e.g. on a computer screen. Instead, the simulation may compute the relevant operating states without or only with a reduced (i.e. not complete) virtual representation of said operating state. According to an embodiment, generating a (preferably complete) virtual representation of the virtual model and/or the simulated operating states is, however, possible. This also relates a simulation of a physical environment and possible infrastructure elements located therein as detailed below.

Preferably, the whole of the track-bound vehicle is represented by the virtual model. On the other hand, in case critical operating states are to be determined for only selected components of the vehicle, the virtual model may only relate to or focus on a part or, in other words, a component of said vehicle, which is likewise referred to as a model of the vehicle herein. This may, for example, relate to parts that are subject to wear, the simulation serving to pre-emptively identifying critical wear of such parts. Nonetheless, even in case the virtual model focuses on to such selected parts, operating parameters of the complete (real-world) vehicle may be considered to simulate the state of such parts.

For receiving data from the vehicle, the simulation unit may comprise a (hardware) receiving unit, such as an antenna, and the vehicle may comprise a (hardware) sending unit e.g. comprising an antenna as well. In general, the communication for receiving data may be wireless and e.g. conducted via a cellular communication network (e.g. an existing mobile communication network), a digital mobile communication system such as a GSM (Global System for Mobile Communications)-based system (e.g. GSM-R), a radio network or a radio link. The above-mentioned receiving and sending unit may thus be adapted to carry out a respective communication via mobile communication, radio link or WLAN. The communication may take place directly between the vehicle and the simulation unit.

Preferably, however, the vehicle sends the data to an intermediate (preferably wayside and/or stationary) receiving unit, which then forwards said data to e.g. a railroad control centre or operation control system. The latter may forward the data to the simulation unit. In general, it is state of the art for railroad control centres or operation control systems to gather data on the location and/or speed of vehicles within their respectively controlled railway networks. Thus, the simulation unit may generally receive operating parameters of a vehicle from such railroad control centres or operation control systems or may be configured as a unit of such a centre or system.

Generally, it is also possible that the simulation unit sends data to the vehicle, for example, in order to provide notifications and/or warnings to an operator of the vehicle. According to one example, the simulation unit may send control signals to the vehicle in order to control the vehicle's operation. This may relate to an emergency break activation signal in case the simulation unit has identified an upcoming critical operating state. Therefore, it is generally possible to (at least indirectly, e.g. via a railroad control centre) exchange data between the vehicle and the simulation unit.

The simulation may generally determine (e.g. calculate) future vehicle operating states, thereby predicting such operating states. The current point of time may relate to the same point of time for which operating parameters of the vehicle have been received. In this context, it is to be understood that due to the time required for identifying, sending and/or receiving data from the vehicle, the operating parameters may not exactly represent current operating parameters, but be a suitable representation thereof, e.g. by being delayed by less than 10 seconds, less than 3 seconds or less than 1 second before being received by the simulation unit.

The prediction time margin may relate to a defined time margin by which the simulation runs ahead of the real world vehicle operation. Differently put it, the prediction time margin allows the simulation to look ahead of the actual vehicle operation. Accordingly, the simulation may generally relate to a future point of time which lies ahead of a current point of time by the prediction time margin.

The prediction time margin may be constant (i.e. static) or may be dynamically adjusted e.g. in reaction to changing travelling speeds of the vehicle (see below). The latter allows for taking account of changes in the real world vehicle operation, thereby increasing the chance that critical operating states are detected sufficiently early to e.g. initiate a real-world braking action.

The operating state of the vehicle may relate to any state of the operating parameters for which data have been received (in particular to a vehicle location). Additionally or alternatively, the operating state may relate to a state of wear of certain parts or components of the vehicle (such as its brakes or doors). Also, the operating state may relate to an interaction between the vehicle and its physical environment, e.g. the vehicle reaching a certain location, such as a level crossing, at a certain point of time.

For identifying critical operating states, the simulation unit may compare simulated (i.e. predicted) operating states with predefined critical operating states that are e.g. stored in a database of the simulation unit. In case a match is detected as a result of by said comparison, reaching a critical operating state may be determined. Additionally or alternatively, rules may be defined, such as the vehicle only being allowed to pass a certain location when a specific rule is fulfilled, such as a barrier having been closed, a desired signalling state having been set or no non-track-bound traffic being present. In case the simulation unit determines a violation of such a rule, a critical operating state may be identified. In general, identifying critical operating states may be carried out by computations and/or calculations performed by the simulation unit.

The simulation may generally include simulating movements of the vehicle, i.e. the predicted operating state relating to movements and/or locations of the vehicle. The operating state and in particular the critical operating state may generally relate to an interaction of the vehicle with an exterior of the vehicle (i.e. an environment of the vehicle and in particular with objects present therein). This may relate to interactions with other vehicles and/or living beings and/or objects on the track.

Generally, a critical operating state may relate to a vehicle potentially crashing with another vehicle or with an object and/or to a component or part of the vehicle reaching an unacceptable level of wear. Also, the critical operating state may relate to the vehicle reaching a certain location at a point of time were passing or staying at said location is not considered safe (see below). Additionally or alternatively, the critical operating state may relate to the vehicle reaching a travelling speed above an acceptable threshold (e.g. during downhill descent), the vehicle reaching a signalling equipment before a signalling state of said equipment has been switched to a desired state or the vehicle reaching a (railroad) switch before said switch has assumed a desired state.

According to an embodiment of the method and arrangement, the operating parameter is one of a travelling speed, a (vehicle) acceleration and a vehicle location. The travelling speed and acceleration can be determined by standard vehicle sensors and/or a (satellite) positioning system, such as GPS. The vehicle location may likewise be determined by means of such a positioning system. Preferably, however, at least some of these operating parameters are determined via a railroad control centre or an operating control system. In a generally known manner, these may comprise a so-called RBC (radio block centre)-system and/or an interlocking-system with balises and/or track circuits. An RBCand/or interlocking-system may generally be used (i.e. also independently of a railroad control centre or an operating control system) to determine any of the vehicle operating parameters disclosed herein.

The simulation may be run by means of an extrapolation that is based on the received data (e.g. by extrapolating the received data directly or by extrapolating information derived from said received data). Specifically, the simulation may be based on an extrapolation that (directly or indirectly) uses the received data. The extrapolation may be carried out as a function of the duration of the prediction time margin. For example, a future vehicle location may be determined by starting from a current vehicle location and extrapolating said vehicle location by multiplying the current vehicle travelling speed with the prediction time margin. The result of said multiplication may be added to the current location in order to determine the future vehicle location, thereby extrapolating the current vehicle location.

The extrapolation (and/or generally the determination of future vehicle operating states by means of the simulation) may also take into account further (preferably non-vehiclebased) information e.g. relating to upcoming operating conditions, such as speed limitations, inclinations or the like.

The simulation may further be performed in and/or include a virtual simulation environment that simulates characteristics of the (real world) physical environment of the vehicle. The virtual simulation environment may be generated by and/or run on the simulation unit discussed above. The virtual simulation environment may include models of real world items, such as the infrastructure elements discussed below. Additionally or alternatively, the virtual simulation environment may include geographical (e.g. an inclination) and/or static characteristics. Additionally or alternatively, the virtual simulation environment may include dynamic characteristics, such as signalling or railroad switch states, in order to react to changing conditions of the vehicle's environment.

In the latter case, such dynamic characteristics may be signalled to the simulation unit e.g. by infrastructure elements such as a switch or, more preferably, by a railroad control centre or operation control system. In an as such known manner, such centres/systems may be configured to determine operating parameters of infrastructure elements such as a switch, signalling equipment or a barrier e.g. via preferably wireless communication links. As noted above, said centres/systems may comprise a central computer system and/or an RBC-or interlocking-system, in particular an electronic interlocking system as known in the prior art and used for safely operating a railway network to avoid conflicting vehicle movements therein.

The characteristics of the physical environment may relate to at least one of: a course of the (railroad) track(s) on which the vehicle travels or will possibly travel or, differently put, a track layout; -the presence of at least one of the following infrastructure elements: a switch (or, more precisely, a railroad switch), a signaling equipment (or, more precisely, a railroad or railway signalling equipment), a barrier (e.g. at a level-crossing), a level crossing, a tunnel (e.g. through which the tracks run), a (railroad) station. Note that the preceding exemplary remarks in brackets may generally apply to all references to the associated features in this disclosure, i.e. a switch may generally be a railroad switch; dynamic environmental characteristics, such as a signaling state of a signaling equipment and/or the presence of non-track-bound traffic.

A signalling state may generally relate to which out of a plurality of signalling states is currently set (i.e. displayed) via the signalling equipment. This may relate to which light signal is currently set or which other information is currently signalled via the signalling equipment. As is well known, a signalling equipment may comprise at least one signalling unit e.g. in form of a colour light signal or a mechanical signal.

According to a further embodiment of the method and arrangement, the prediction time margin may be adjusted based on at least one operating parameter of the vehicle and in particular based on its travelling speed and/or a required braking time which may also depend on weather conditions (wetness) but in particular on the vehicle's weight. Also, a required braking distance may be considered. For example, the prediction time margin may (e.g. proportionally or quadratically) increase at a higher (i.e. increasing) travelling speeds and/or braking distances and decrease at decreasing travelling speeds and/or braking distances. This takes account of the longer time required for bringing the vehicle to a halt at higher travelling speeds. In other words, the look-ahead time may be increased to ensure that in case a critical operating state is identified by means of the simulation, a timely stopping of the (real world) vehicle can still be achieved before said critical operating state actually occurs in the real world.

Note that on the other hand a too large prediction time margin may limit the preciseness of the simulation by e.g. failing to take account of recently changing conditions. Thus, according to one embodiment, the prediction time margin may be smaller than five minutes, smaller than three minutes, smaller than two minutes and in particular smaller than one minute.

In a further development of the method and arrangement, running the simulation includes predicting a vehicle operating state for each of a plurality of real-world-operated vehicles based on (and by generating) a respective plurality of virtual models and the prediction time margin is adjusted (in particular by being increased or decreased accordingly) based on the fastest travelling speed and/or the longest braking distance (or a corresponding longest braking time) out of said plurality of vehicles. This ensures that the prediction time margin is sufficiently large to bring even the fastest out of the plurality of vehicles and/or the one requiring the longest braking distance to a halt in a timely manner (i.e. before a predicted critical operating state actually occurs in the real world). The required braking distance may be estimated based on the travelling speed and the vehicle's weight. As an option, weather conditions (wetness) and/or information about a braking effect of said vehicle may be considered as well. Considering the longest braking distance is advantageous in case the vehicles strongly deviate from one another. For example, a single fast locomotive may require a longer braking distance than a slower but heavier train having a plurality of wagons.

In general and as indicated above, the prediction time margin may be equal to or larger than a (e.g. an expected) time difference needed to halt the vehicle at a current travelling speed. Said time difference may be calculated based on the current travelling speed and a known or assumed break effect of the vehicle.

The critical operating state that is detectable via the simulation may relate to a potential crash (i.e. collision) of the vehicle with another object. In this context, the object may be moving and the simulation may include a virtual model of said moving object. The object may be another track-bound vehicle that is either static or moving.

A crash with such a vehicle may occur in a frontal manner (i.e. the vehicles approaching each other on the same track). Further, a crash may occur by approaching another standing or slower vehicle from behind, thereby causing a rear collision. Also, the vehicles may approach each other close to a switch (i.e. pass by and approach each other from the side due to the track layout in the region of the switch). This may lead to a side or flank collision. Each and in particular all of these collision scenarios may represent a critical operating state that is detectable via the simulation and in particular based on a plurality of virtual models for a plurality of real-world vehicles, each of the models being simulated based on received data indicated above.

According to a further example of the method and arrangement, the critical operating state relates to reaching a location (e.g. within a railway network) at a point of time at which a state of said location does not allow for a safe passage or stay of the vehicle. The state of said location may be detected as an environmental parameter (e.g. by receiving data from infrastructure elements, a railroad control centre and/or a RBC-system). Additionally or alternatively, this state may be determined (i.e. predicted) as part of the simulation. Similarly, whether or not the vehicle reaches the location at a certain point of time or, generally, at which point of time a location is reached by the vehicle, may equally be determined by means of the simulation.

The location may be a level-crossing. A state of the location not allowing for a safe passage or stay may generally be marked by at least one of: - a signalling equipment at said location not being operable and/or being in an undesired signalling state (e.g. displaying the wrong signal, for example by failing to display a stop signal to the vehicle and/or to other non-track-bound traffic); - a barrier not being closed or not being closable until the location is reached by the vehicle (which may be predicted as part of the simulation e.g. based on a virtual model of the barrier); - non-track-bound traffic being present at said level-crossing.

In the context of this disclosure, non-track-bound traffic may include non-track-bound vehicles such as cars or trucks. Yet, this traffic may also include pedestrians. Whether or not such traffic is present may be detected via sensors, such as cameras, surveying the location.

According to a further embodiment of the method and arrangement, the critical state relates to a potential malfunction of the vehicle (i.e. a malfunction detected for the virtual model). A malfunction may e.g. occur due a part or component of the vehicle experiencing wear beyond an acceptable threshold. Accordingly, a state of such parts or components (e.g. with respect to wear) may be predicted by way of the simulation. This may apply e.g. to breaks of the vehicle and/or to other frequently operated vehicle components, such as door arrangements.

Note that it is equally possible to, by way of the simulation, determine critical operating states of the physical environment of the vehicle and in particular of infrastructure elements, such as switches or barriers. For doing so, the operation of the switches or barriers may be determined by way of data e.g. received from railway network operating systems and a state thereof (in particular with respect to wear) may be predicted by means of the simulation (e.g. by taking into account future expected operations of such elements by extrapolating historically experienced operations thereof). This way, a timely exchange or repair of such elements may be initiated. This likewise helps to increase the safety of the vehicle operation.

In general, in case the critical operating state relates to the malfunction of the vehicle or infrastructure elements, the prediction time margin may be larger than the margin used for predicting crashes, e.g. by a factor of at least 10, at least 100 or even at least 1000. For example, for predicting malfunctions, the prediction time margin may amount to several days or weeks (e.g. at least two or four weeks). Also, in this context it may be considered to regularly check (i.e. sample) the actual state of the vehicle or infrastructure elements and include this state in the simulation e.g. in the sense of an update.

Still further, in case a critical operating state is detected, a notification may be issued in the real world and/or as part of the simulation. The notification may include a visual, audio and/or haptic feedback e.g. to an operator of the vehicle and/or to a person supervising the simulation. Additionally or alternatively, the notification may include information (e.g. in written form) on which type of critical state has been detected and/or what countermeasures would be appropriate. In one example, the notification is a control signal that may be configured to e.g. activate an automated emergency braking procedure of the vehicle.

Specifically, in case the critical operating state is detected, an automatic (i.e. driver-independent) corrective action may be initiated, such as a braking action.

The invention further relates to an arrangement for operating at least one track-bound vehicle, the arrangement comprising a track-bound vehicle that is operable in the real world and a simulation unit that is configured to: -generate a virtual model of said track-bound vehicle; receive data concerning current operating parameters of the vehicle; run (i.e. execute) a simulation based on the received data and the virtual model in order to predict a future vehicle operating state, the simulation running ahead of a current point of time by at least one prediction time margin; and identify a critical operating state of the vehicle based on said simulation.

The arrangement may comprise any development or any further feature in order to provide any of the previously or subsequently discussed interactions, operating states and steps. Specifically, any of the previous or subsequent explanations and developments regarding the method-features may also apply to the equivalent arrangement-features. In general, the arrangement may be configured to carry out a method according to any of the previous or subsequent aspects.

In the following, an embodiment of the invention will be described with reference to the attached schematic figures. In the figures,: Fig. 1 is a schematic representation of an arrangement according to an embodiment of the invention; Fig. 2 is a flow diagram of a method carried out by the arrangement of figure 1; and Fig. 3 is a flow diagram of an additional or alternative method carried out by the arrangement of figure 1.

Figure 1 shows a schematic illustration of an arrangement 1 according to an embodiment of the invention, said arrangement 1 carrying out a method according to the invention.

The arrangement 1 comprises a real world track-bound vehicle in form of a train 10. The train 10 (as a mere exemplary configuration) has a powered rail car (or, differently put, a motor coach) 12 as well as a plurality of passenger wagons 13a-13k. The train 10 runs on schematically indicated tracks 14.

As further indicated in figure 1, the arrangement 1 comprises a wayside (i.e. stationary) real-world simulation unit 16 that is e.g. provided as a computer or a computer system. In the shown example, the simulation unit 16 is part of an operating centre of a railroad network, such as a railroad control centre 11. Said railroad control centre 11 is, in a known manner, connected to various infrastructural elements, such as switches and signalling equipment, as well as to vehicles operated (i.e. moving) within the railroad network controlled by said railroad control centre 11. The connection is achieved by communication means and in particular wireless communication means such as GSM-R connections or via train-balise telegram exchange methods. Thereby, any of the operating parameters discussed herein may be determined with help of the railroad control centre 11 communicating with the vehicles and/or infrastructural elements within the railroad network in a known manner.

The simulation unit 16 is configured to generate a virtual model of the train 10 in a virtual simulation environment. The virtual simulation environment includes characteristics of the real world physical environment (i.e. of the railroad network in which the train 10 operates) such as the infrastructure elements discussed below.

In the shown example, both of the virtual model of the train 10 as well as the virtual simulation environment are displayed on a computer screen 18 of the simulation unit 16. This, however, is not mandatory. Instead, the simulation may be run without a graphical representation of e.g. the virtual model of the train 10 and only the results and/or notifications of the simulation may be displayed via the computer screen 18.

The railroad control centre 11 comprises a receiving unit 20 (e.g. comprising an antenna) for receiving data on operating parameters of the train 10. The train 10 comprises a sending unit 22 (e.g. comprising an antenna) for sending data on its operating parameters to the receiving unit 20. This may be done via a mobile communication network and in particular a GSM-R network as indicated by the dotted line in figure 1. The simulation unit 16 receives the respective data from the receiving unit 20 is indicated by a respective arrow in figure 1. Note that alternative communication methods, such as train-balise telegram exchange method, are equally possible.

In the shown example, at least the current travelling speed and current location of the train 10 are received as current operating parameters by the simulation unit 16 and possibly also an acceleration of the train 10.

Based on these operating parameters, the simulation unit 16 predicts an operating state of the train 10 in terms of its location and possibly also its travelling speed and/or acceleration at a future point of time. Specifically, the transmitted current operating parameters relate to a current point of time, whereas the simulated operating state of the train 10 relates a future point of time. The future point of time and the current point of time are separated by a prediction time margin (i.e. the future point of time lying ahead the current point of time by said prediction time margin). Said margin may e.g. amount to at least 30 seconds and preferably at most two minutes, but, as shown below, may generally be adjustable while running the simulation.

In general, the duration of the prediction time margin is chosen (e.g. by way of the examples for its duration mentioned herein) so as to ensure that the train 10 can be brought to a halt before a predicted critical operating state occurs in the real world. Moreover, the duration of the prediction time margin is chosen (e.g. by way of the examples for its duration mentioned herein) so as to ensure a sufficiently realistic simulation, i.e. not looking too far ahead the current point of time in order to take account of short-term changes.

In the shown example, the simulation unit 16 receives the operating parameters of the real world train 10 and performs an extrapolation based thereon to determine the future operating state of the train 10. Specifically, a location of the train 10 at the future point of time at which the simulation is directed (i.e. that is separated from the current point of time but the prediction time margin) can be determined as indicated by the dotted train 10 in figure 1 which represents a current location of the train's virtual model compared to current location of the left non-dotted real world train 10. For doing so, the current travelling speed of the real world train 10 is multiplied by the prediction time margin, the result of which being added to the current location of the real world train 10, thereby arriving at the predicted future location.

In figure 1, it is indicated that said simulated future location is close to a real world level crossing 22. This is recognized by the simulation unit 16 by comparing the predicted future location with map data of the railway network. Such map data may e.g. be available from a database of the railroad control centre 11.

At said level crossing 22, a movable barrier 24 is shown as well as a light signal 26 which is an example of a signalling equipment. Both are provided to stop non-track bound traffic (e.g. cars and pedestrians) from entering the level crossing 22 when a train passes therethrough. Note that the light signal 26 (or an additional light signal 26) could also be used for providing signals to a train conductor, e.g. for signalling whether or not passing the level crossing 22 is safe. Furthermore, the level crossing 22 comprises a camera 28 used for supervising, whether or not non-track-bound traffic currently crosses the level crossing 22.

Each of the level crossing 22, the barrier 24, the light signal 26 and the camera 28 represent an infrastructure element of the real-world environment. As part of the virtual simulation environment, the simulation unit 16 is also configured to simulate a state of at least some and preferably each of said infrastructure elements at the future point of time. For doing so, it may e.g. receive data on the operating parameters of such infrastructure elements either from these elements directly or from the railroad control centre 11.

For example, the simulation unit 16 may receive data that the barrier 24 is currently open to then predict whether or not at the future point of time at which the train 10 reaches the level crossing 22, the barrier 24 is likely to be closed (i.e. whether the protection time margin would be sufficient to close the barrier e.g. based on a simulation of the physical behaviour of said barrier 24). If this is not the case, the simulation unit 16 may detect a critical operating state and notify a person supervising the computer screen 18 and/or the train conductor e.g. via a respective message. Alternatively, the simulation unit 16 may generally be configured to initiate an emergency brake operation of the train 10, e.g. by issuing a notification in form of a control signal which activates said emergency brake operation. For doing so, the simulation unit 16 may comprise a respective communication unit and/or the receiving unit 20 or a different communication unit of the railroad control centre 11 may be configured to receive data from the simulation unit 16 (see double arrow in figure 1) and send them to the train 10.

Additionally or alternatively, the simulation unit 16 may, by way of the simulation, determine a signalling state of the light signal 26 and/or a possible malfunction thereof as soon as the virtual model reaches the level crossing 22 in the simulation. Also, in case non-vehicle-bound traffic is detected via the camera 28, the simulation unit 16 may generally detect a critical operating state and e.g. determine a latest point of time at which a real world emergency braking procedure would have to be initiated to bring the train 10 to a halt before reaching the level-crossing 22.

In general, the simulation unit 16 thus mainly serves to predict that the train 10 is about to reach the level crossing 22 (or a similar location) in order to check in advance, whether or not said level crossing 22 (or a similar location) is safe for being passed by the train 10. If this is not the case, a notification concerning an upcoming critical operating state is issued by the simulation unit 16.

Note that due to choosing the prediction time margin in a manner, so that it is sufficiently large to bring the train to a halt, it can be ensured that the train 10 is stopped prior to actually reaching the level crossing 22 in the real world. This way, the simulation improves the safety and e.g. avoids potential collisions with foreign objects.

In this context, it is particularly advantageous if the prediction time margin is adjusted and in particular adjusted based on the current travelling speed of the train 10. For example, the prediction time margin can be adjusted as a (linear or preferably quadratic) function of the travelling speed and/or become larger at increasing travelling speeds. This helps to ensure that the prediction time margin is sufficiently large to bring the train 10 to a halt in case the simulation determines an upcoming critical operating state, even in case of varying travelling speeds of the train 10. Adjusting the prediction time margin may be carried out by the simulation unit 16 e.g. with help of standard calculations and by monitoring the travelling speed as an operating parameter of the train 10.

Overall, the simulation unit 16 is thus configured to check whether or not the state of the level crossing 22 (or in general a location which the train 10 will pass in the future) is likely to be safe or not when the train 10 actually reaches said level crossing 22.

In a similar manner, the simulation unit 16 may predict that the train 10 is about to reach schematically illustrated switch 30. As a part of the simulation, the simulation unit 16 may e.g. predict whether the time until the real world train 10 reaches said switch 30 (i.e. the duration of prediction time margin) is sufficient to e.g. change a setting of the switch 30 in a desired manner. If this is not the case, a critical operating state is identified and a respective notification may be issued.

Moreover, in figure 1 a further vehicle in form of a single locomotive 32 is shown. The simulation unit 16 is configured to also receive data on operating parameters of said locomotive 32 and to generate a virtual model thereof as part of the simulation. For receiving the data, the locomotive 32 may again be configured to, via a sending unit 22, send data to the receiving unit 20.

The simulation unit 16 may thus be configured to predict future locations, speeds and/or in general movements of the train 10 as well as the locomotive 32 with help of the respectively generated virtual models. This may be used to identify critical operating states during the simulation.

Specifically, it may be detected that e.g. as a result of a wrong setting of the switch 30, both of the train 10 and the locomotive 32 approach each other on the same track. This may generally be detected as a critical operating state by the simulation unit 16. For example, the simulation unit 16 may have access to a database concerning a timetable for trains operating within the railway network and thus frequently determine, whether or not the virtual models of the vehicles 10, 32 run on actually desired tracks. Additionally or alternatively, the simulation unit 16 may be configured to determine a crash of the virtual models of the train 10 and the locomotive 32 before said crash occurs in the real world. The simulation unit 16 may detect this as a critical operating state and issue a respective notification.

Note that further crash scenarios, which may equally be predicted via the simulation e.g. via colliding virtual models, relate to the train 10 and the locomotive 32 driving in the same direction, but (when viewed in the driving direction) the rear vehicle being faster than the front vehicle. This can result in a rear collision in which the faster rear vehicle crashes into the slower front vehicle. Similarly, in case the switch 30 does not operate as intended or the vehicles 10, 32 operate too close to one another in the region of said switch 30, a side or flank collision may occur when passing each other.

In case a plurality of vehicles 10, 32 are simulated by a virtual models, the prediction time margin is preferably chosen as a function of the fastest travelling speed and/or the longest braking distance (or a corresponding longest braking time) out of the plurality of vehicles 10, 32. This way, it can be ensured that the look-ahead time of the simulation is sufficient to allow even the fastest vehicle 10, 32 and/or the vehicle requiring the longest braking distance or time to be braked sufficiently early in the real world in case the simulation has detected a critical operating state and in particular a potential crash. As previously discussed, by considering the longest braking distance or time differences in the braking effect and in particular in the weight of the different vehicles can be taking into account.

Finally, the simulation unit 16 is also configured to detect possible malfunctions, in particular due to wear, of a vehicle 10, 32. For doing so, it may predict a state of a part a component of the vehicle 10, 32 based on the received data on operating parameters of said vehicle. Specifically, wear of said part which may lead to a respective malfunction may be predicted by way of the simulation. For doing so, based on the received data on the operating parameters, the simulation may e.g. determine a frequency and extent of brake operations and use this to, via a virtual model including the brakes, determine a state of wear of said brakes and in particular, whether or not these have reached a critical wear threshold.

In figure 2, a flow diagram is shown in which the simulation unit 16 detects a critical operating state in form of a vehicle 10, 32 reaching a location in an unsafe state (i.e. said location not allowing for a safe passage or stay of the vehicle 10, 32). Note that for explanatory purposes, only one vehicle 10, 32 is considered in the following, but that the following method may be carried out for any and in particular each vehicle 10, 32 out of a plurality of simulated vehicles 10, 32.

In a step S1, the simulation unit 16 generates a virtual model of e.g. the train 10 (and/or the locomotive 32). Also, a virtual simulation environment including characteristics of the physical (real world) environment of the train 10 is generated or provided (e.g. by being read out from a database of the simulation unit 16). The virtual simulation environment includes details (such as the location and/or operating state) of infrastructure elements such as the level-crossing 22 of figure 1 and the further infrastructure elements 24, 26, 28 associated therewith.

In step S2, the simulation is run (i.e. executed) and for doing so, the simulation unit 16 receives data concerning current or, differently put, real-time operating parameters of the train 10. As previously noted, these data are preferably available and received from the railroad control centre 11 and/or non-illustrated interlocking control centers or interlocking control sub-centers connected to said railroad control centre 11. Similarly, data on the operating states of the infrastructure elements and in particular the barrier 24, the light signal 26 and the camera 28 are received from the railroad control centre 11.

In step S3, it is determined by way of the simulation that the virtual model of the train 10 reaches the level crossing 22. Whether or not said virtual model reaches such a location may be constantly supervised by the simulation unit 16.

In step S4, which is preferably immediately carried out after step S3 (i.e. without substantial delays), the simulation unit 16 checks the operating parameters of the infrastructure elements associated with the level crossing 22. Specifically, the simulation unit 16 checks whether the barrier 24 is closed in a sub-step S4a, whether the light signal 26 is set to a desired signalling state (e.g. signals a stop to non-track-bound traffic) in a sub-step S4b and whether the camera 28 indicates that no non-track-bound traffic is present at the level crossing in a sub-step S4c.

In case the checks in the sub-steps S4a-c deliver a positive result as indicated by arrows Y (i.e. the barrier 24 being closed, the light signal 26 being set to a desired state and the camera 28 indicating no non-track-bound traffic), it is determined that the level-crossing 22 is safe for being passed by the train 10 in step S5. Accordingly, no notifications are issued by the simulation unit 16 with regard to potentially critical operating states.

To the contrary, if any of the checks in the sub-steps S4a-c deliver a negative result as indicated by arrows N, step S6 is arrived at, said step S6 having a higher priority than step S5 (i.e. if any of the sub-steps S4a-c is negative, step S6 will be executed regardless of whether any other of the sub-steps S4a-c is positive. In step S6, it is identified that a critical operating state has occurred in the simulation and may thus potentially arise in the real world as well. Therefore, a notification according to any of the above examples will be issued by that simulation unit 16. The above logical relations are expressed by corresponding logical AND-and OR connectors in figure 2 In figure 3, a flow diagram is shown in which the simulation unit 16 detects a critical operating state in form of a plurality of vehicles 10, 32 potentially colliding with one another. In step S1, a plurality of virtual models is generated by the simulation unit 16 for each of the real world vehicles 10, 32 to be simulated. Additionally, a virtual simulation environment may again be generated which, additionally or alternatively to any of the examples mentioned in connection with figure 2, may in particular be directed at the track layout of the railroad network as well as the operating state of its switches 30 (i.e. to which position these are currently set).

In step S2, operating parameters are received from both of the real world vehicles 10, 32 as well as the infrastructure elements included in the virtual simulation environment. This is done in a similar manner as explained with respect to figure 2 (i.e. via the railroad control centre 11).

In step S3, the simulation is executed and the movements of the virtual models of the vehicles 10, 32 are constantly supervised. These movements are subject to e.g. changing states of switches 30 which may equally be reflected in the simulation.

As part of this simulation, the simulation unit 16 constantly monitors, whether or not the virtual models of the vehicles 10, 32 collide with one another. Numerous potential collision scenarios have been explained above.

In case a respective collision is detected, a notification according to any of the above examples is issued in step S4.

According to the above embodiments, the operation and in particular movements of track-bound vehicles within a railroad network can be predicted ahead of the real world operation, thereby identifying potentially arising critical operating states in advance and, preferably, introducing countermeasures to avoid them from actually occurring in the real world.

Claims

Claims 1. A method for operating of at least one track-bound vehicle (10, 32), the method comprising: - operating at least one track-bound vehicle (10, 32) in the real world; providing at least one virtual model of said track-bound vehicle (10, 32); receiving data concerning at least one current operating parameter of the vehicle (10, 32); - running a simulation based on the received data and the virtual model in order to predict a future vehicle operating state, the simulation running ahead of a current point of time by a prediction time margin; and identifying a critical operating state of the vehicle based on said simulation.
2. The method according to claim 1, wherein the operating parameter is one of a travelling speed, an acceleration and a vehicle location.
3. The method according to claim 1 or 2, wherein the simulation is based on an extrapolation that uses the received data.
4. The method according to any of the previous claims, wherein the simulation is performed in a virtual simulation environment that simulates characteristics of the physical environment of the vehicle.
5. The method according to claim 4, wherein the characteristics of the physical environment are at least one of: - a course of the track; - the presence of at least one of the following infrastructure elements: a switch (30), a signaling equipment (26), a barrier (24), a level crossing (22), a tunnel, a station; dynamic environmental characteristics, such as a signaling state of a signaling equipment (26) and/or the presence of non-track-bound traffic.
6. The method according to any of the previous claims, wherein the prediction time margin is adjusted based on at least one operating parameter of the vehicle (10, 32) and in particular based on the travelling speed and a required braking time.
7. The method according to any of the previous claim 1 to 5, wherein running the simulation includes predicting a vehicle operating state for each of a plurality of real-world-operated vehicles (10, 32) based on a respective plurality of virtual models; and wherein the prediction time margin is adjusted based on the fastest travelling speed and/or the longest braking distance out of said plurality of vehicles (10, 32).
8. The method according to claim 6 or 7, wherein the prediction time margin is equal to or larger than a time difference needed to halt the vehicle (10, 32) at a current travelling speed.
9. The method according to any of the previous claims, wherein the critical operating state relates to a potential crash of the vehicle (10, 32) with another object.
10. The method according to claim 9, wherein the object is moving and the simulation includes a virtual model of said moving object.
11. The method according to any of the previous claims, wherein the critical operating state relates to reaching a location at a point of time at which a state of said location does not allow for a safe passage or stay of the vehicle (10, 32).
12. The method according to claim 11, wherein the location is a level-crossing (22) and a state thereof not allowing for a safe passage or stay is marked by at least one of: a signalling equipment (26) at said location not being operable and/or being in an undesired signalling state; a barrier (24) not being closed or not being closable within the prediction time margin; non-track-bound traffic being present at said level-crossing (22).
13. The method according to claim 11 or 12, wherein a state of the location is predicted based on the simulation.
14. The method according to any of the previous claims, wherein the critical operating state relates to a potential malfunction of the vehicle.
15. The method according to any of the previous claims, wherein in case the operating critical state is detected, a notification is issued in the real world and/or as part of the simulation.
16. The method according to any of the previous claims, wherein in case the operating critical state is detected, an automatic corrective action is initiated, such as a braking action.
17. An arrangement (1) for operating at least one track-bound vehicle (10, 32), the arrangement (1) comprising a track-bound vehicle (10, 32) that is operable in the real world and a simulation unit (16) that is configured to: generate a virtual model of the track-bound vehicle (10, 32); receive data concerning current operating parameters of the vehicle (10, 32); run a simulation based on the received data and the virtual model in order to predict a future vehicle operating state, the simulation running ahead of a current point of time a prediction time margin; and identify a critical operating state of the vehicle (10, 32) based on said simulation.