METHOD FOR OPERATING A TRAIN CONTROL SYSTEM, TRACKSIDE COMPUTING ENVIRONMENT, TRACK-GUIDED VEHICLE, COMPUTER PROGRAM PRODUCT AND COMPUTER-READABLE STORAGE MEDIUM

Description

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the priority, under 35 U.S.C. § 119, of European Patent Application EP 24202918.9, filed Sep. 26, 2024; the prior application is herewith incorporated by reference in its entirety.

FIELD OF THE INVENTION

The invention relates to a method for operating a train control system. The invention further relates to a trackside computing environment of a track-guided transportation network. The invention further relates to a track-guided vehicle with an onboard computing environment. The invention further relates to a computer program product, containing program commands. The invention further relates to a computer-readable storage medium, containing data.

BACKGROUND OF THE INVENTION

The journey time calculation for train control systems is based in a manner known per se on the solution of movement equations by a computing entity, which is also referred to as a solver, the parameters employed in real train operation being known only insufficiently accurately (traction resistances, mass, slewing masses, wind speed, wind direction are changeable variables and are dependent on operating conditions such as weather, wear and tear, and loading status). The parameters are hence calculated using approximation formulae, or mean values are assumed.

The main aim of a train control system (also referred to below as a traffic management system or TMS for short) is to provide a disruption-free timetable, in order to minimize conflicts in the form of train delays. The typical optimization aims proposed in accordance with the prior art include minimizing the average delay or the cumulated delay for example by minimizing convex functions of the train delays. Models to represent feasible solutions are based on the observation of considering the trains as tasks (also referred to below as jobs) and the track resources rather than machines. Thus the problem of train handling is similar to the problem of planning in a production plant (referred to below as a shop). That means that the occupancy time of a train on the resource of the route section corresponds to the machining time of a task on a machine (referred to below as the flexible job shop problem or FJSP for short), for which solvers are employed in accordance with the prior art (cf. for example Leonardo Lamorgese et al., “Train Dispatching”, Springer, 2018). There are however certain rail-specific aspects of the FJSP which have to be taken into account. For example, a train which has reached the end of a resource cannot enter the subsequent resource if it is occupied, meaning that follow-up conflicts can arise due to timetable changes for the solution of conflicts, and in turn delay the trains acting in accordance with the amended timetable. In timetable theory that is known as a blocking condition.

Currently, a forecast for the journey time of a train on a route from location A to location B is calculated in a TMS by a solver as follows:

• • The current speed profile for the maximal possible speed is determined from A to B.
  • resistance profile for the route is calculated (gradients, curves, tunnels).
  • The force-speed characteristic for the vehicle is taken into account.
  • Resistance parameters are assumed for the cars of the vehicle, wherein those may differ by a factor of 10 between good runners and bad runners.
  • Based on the above parameters, the movement differential equation is solved either as an integral of a(t)=F/m for the complete route or as F(v) during acceleration and separately for constant driving and braking. Thus a minimum technical journey time is determined.

That procedure has the following disadvantages:

• • The journey time calculation (forecast) within the TMS takes a relatively long time (computing times in the range of minutes), is complex, and is based on many assumptions. Those assumptions have to be adjusted to each particular individual application in order to bear a similarity to the real traffic.
  • A large number of parameters is required (for example train characteristics).
  • Many parameters have to be estimated or averaged. For annual planning an “averagely” effective train with a particular formation of cars is assumed, for example.
  • The journey time calculation is relatively complex, the software application is thus comparatively elaborate. There is a risk that complex traffic situations cannot be optimized in a sufficiently short time.

In order to implement timetables specified by TMS, methods for automated train operation (also referred to below as ATO for short) are employed in train traffic in a manner known per se and are secured by methods for automatic train control (also referred to below as ATC for short). The ATC in that case implements automatic functions in train operation which are safety-related. For example, the forced braking of the vehicle if a safety risk is determined. The ATO serves to optimize train operation in terms of journey times and energy consumption of the vehicle. Those functions are not safety-related, since the modification of journey times and energy consumption do not trigger any safety risks. Both ATO and ATC require the cooperation of onboard (also referred to below as OB for short) computing entities, including hardware components and software components, as well as trackside (also referred to below as TS for short) computing entities, including hardware components and software components.

The requirements for the certification of safety-related applications, for example in rail technology, are very high. In accordance with international standard IEC 61508 or, specifically for the rail sector, in accordance with European standard EN 50129, for safety functions four safety integrity levels (SIL) or safety requirement levels are distinguished for the required functional safety. There, safety integrity level 4 represents the highest and safety integrity level 1 the lowest level of safety integrity. The respective safety integrity level influences the confidence interval of a measured value such that the higher the safety integrity level to be met by the respective apparatus, the smaller the confidence interval. The dimension of functional safety of the various safety integrity levels can be clearly described by the expected frequency of a failure of the safety-related system MTBF (Mean Time Between Failures), that being specified in years (a). For SIL-1 that is in the range of 10 . . . 100 a, for SIL-2 in the range of 100 . . . 1000 a, for SIL-3 in the range of 1000 . . . 10000 a, and for SIL-4 in the range of 10000 . . . 100000 a.

Starting from a regular timetable which takes into account the interacting vehicles in a track-guided transportation network, the TMS uses a solver to calculate an individual target timetable for a vehicle affected by a disruption, for example. For ATO OB it is provided that it calculates a forecast for a transferred target timetable. That takes place on the basis of precise knowledge of the vehicle and its environment (resistances, mass, slewing masses, external temperature, etc.), wherein the specified characteristic values in the vehicle can for example be captured by sensors.

The problem arises from the prior art explained above that a TMS should be used to create updated timetables which are as realistic as possible in the shortest possible computing time, and which it should be possible to implement, as achievable target timetables, with a high degree of probability without disruption.

SUMMARY OF THE INVENTION

It is accordingly an object of the invention to provide a method for operating a train control system, a trackside computing environment, a track-guided vehicle, a computer program product and a computer-readable storage medium, which overcome the hereinafore-mentioned disadvantages of the heretofore-known methods and devices of this general type.

In particular, one object is to develop a method for operating a train control system, in which a trackside computing environment and on a vehicle an onboard computing environment are employed, such that the calculation of an updated timetable from a regular timetable can exploit the actually available journey time reserves as much as possible and deliver an achievable result in the form of the updated timetable as quickly as possible. A further object of the invention is to specify a vehicle, a computer program product, and a computer-readable storage medium with which the improved method can be performed.

With the foregoing and other objects in view there is provided, in accordance with a first aspect of the invention, a method for operating a train control system, in which:

• • a) a trackside computing environment and an onboard computing environment are employed, wherein in the trackside computing environment and in the onboard computing environment a planning level and an execution level for target timetables to be executed are implemented, wherein individually
  • b) at the planning level a first computing entity calculates an updated timetable, taking into account target parameters of the target timetable currently to be executed, and conflicts arising from actual parameters of an achievable actual timetable for the solution of the conflicts,
  • c) then at the execution level a second computing entity receives from the first computing entity a message which specifies the updated timetable as a target timetable currently to be executed.

The trackside computing environment and the onboard computing environment are organized separately from each other, since the vehicles that are involved in the implementation of the target timetable to be executed, and thus together form the onboard computing environment, must move in the track-guided transportation network. Strictly speaking, each vehicle that moves in the transportation network forms an independent part of the onboard computing environment with at least one computing entity in each case. The trackside computing environment can in this case be employed for multiple vehicles at the same time. In the execution of the method, computing resources of the onboard computing environment and computing resources of the trackside computing environment are both used, as is explained in greater detail below. In this case it is necessary to divide the software running in the computing environments in the form of suitable program modules into the onboard computing environment and the trackside computing environment.

The message relating to the updated timetable is received by at least one computing entity and is implemented in terms of control (trackside and onboard) such that the vehicle, taking account of the applicable safety requirements, can adhere to the target timetable resulting from the updated timetable. The safety requirements are taken into account in the first computing entity when calculating the updated timetable, so that the updated timetable can also be implemented after being passed to the vehicle (at least with a high degree of probability).

In the context of this description of the invention, a target timetable to be executed is to be understood as a target timetable which is currently being executed or the execution of which should be started immediately (also known as a target timetable currently to be executed) or a target timetable which is to be executed in future. In this case the future execution of the target timetable to be executed can also be optional.

An achievable actual timetable is to be understood as a timetable which at least in part solves conflicts that arise (i.e. solves or at least reduces delays). However, when a conflict arises this actual timetable is initially derived directly from the target timetable to be executed without any optimization. Thus only the control system reacts to the conflicts that are currently arising, usually resulting in delays to the affected vehicles. As an example, a vehicle will not as planned enter a route section still blocked because of a delay by a preceding vehicle which should have already left this route section. However, the term achievable actual timetables should also include timetables which have already achieved a certain degree of optimization as regards the occurrence of conflicts, the further optimization potential of which is however still uncertain, and the further optimization potential of which is still to be leveraged. In this sense, every updated timetable is treated as an achievable actual timetable, regardless of how well the optimization has succeeded. In the context of this description of the invention, an achievable actual timetable can be used as a target timetable to be (currently) executed whenever an optimization process is to be completed.

An apparatus is computer-aided or computer-implemented if it has a computing environment, or a method is so called if a computing environment executes at least one method step of the method.

A computing environment is an IT infrastructure, formed of functional components such as processors, storage units, programs, and data which is to be processed with the programs and which is used for the execution of at least one application that has a task to perform. Further functional components can be formed of sensors and actuators which enable the computing environment to interact with the outside world. The IT infrastructure can also be organized as a network of the functional components mentioned.

Within a computing environment or multiple computing environments, computing entities form functional units which can be assigned to applications (given for example by a number of program modules) and can execute them. When executing the application these functional units form physically (for example computer, processor) and/or virtually (for example program module) self-contained systems.

Computers are electronic devices formed of multiple functional components with data-processing properties. Computers can for example be clients, servers, handheld computers, communication devices, and other electronic devices for data processing which may have processors and storage units, and may also be connected to a network via interfaces.

Processors can for example be transducers, sensors for generating measurement signals, or electronic circuits. A processor can be a central processing unit (CPU), a microprocessor, a microcontroller, or a digital signal processor, possibly in combination with a storage unit for storing program commands and data. A processor can also be understood as a virtualized processor or a soft CPU.

Storage units can run on computer-readable memories in the form of random-access memories (RAM) or data memories (hard disk or data medium).

Program modules are individual software functional units which enable an inventive program sequence of method steps. These software functional units can be implemented in a single computer program or in multiple computer programs communicating with one another. The interfaces implemented hereby can in terms of software be implemented within a single processor or in terms of hardware if several processors are employed.

Interfaces can be implemented in terms of hardware, for example wired or as a radio connection, or in terms of software, for example as an interaction between individual program modules of one or more computer programs, and serve to exchange data, preferably in the form of digital datasets or analog signals.

In order to avoid any misunderstandings, it should be noted at this point that individual claim features are numbered consecutively with small Latin letters, without regard to the claim numbering. This means that each letter occurs only once in the entire set of claims, which allows for the relevant claim features to be addressed uniquely without mentioning the claim number. However, for this reason the order of the letters is of no importance.

In accordance with the invention, it is provided that:

• • d) a first routine and parallel in time to the first routine a second routine run in the first computing entity, for the performance thereof,
  • e) in the first routine, whenever a new achievable actual timetable is present, a preliminary updated timetable is calculated with a first solver in accordance with method step b), without taking into account consequential conflicts in the preliminary updated timetable (i.e. without taking into account the resulting consequential conflicts during the microsimulation when deciding on individual conflict solutions), wherein the preliminary updated timetable is passed to the second routine as an achievable actual timetable,
  • f) in the second routine whenever an achievable actual timetable was passed from the first routine, an optimized updated timetable is calculated with a second solver in accordance with method step b), wherein consequential conflicts in the optimized updated timetable are taken into account and wherein, as long as an abort criterion according to step g) is not met, the optimized updated timetable is passed to the first routine as an achievable actual timetable,
  • g) as soon as the abort criterion is met, the updated timetable last calculated in steps e) and f) is used for step c), wherein as an abort criterion at least one first condition is taken into account that in accordance with step f) no deviating optimized updated timetable can be calculated compared to the last calculated preliminary updated timetable.

In accordance with the invention it is thus provided that, to solve conflicts in a regular timetable, which simultaneously represents an achievable actual timetable (as long as no conflicts have yet arisen), a comparatively fast-calculating first solver is used which, because it calculates only on the basis of existing conflicts (here meaning the conflicts which have already arisen or are directly foreseeable and which arise from the actual parameters, i.e. calculation is based on a local view of the conflicts), can calculate a solution for the existing conflicts in the shortest possible time. In the context of this description of the invention, this calculation is referred to as a microsimulation and the result is referred to as a preliminary updated timetable, because this updated timetable cannot usually optimize all foreseeable conflicts (i.e. including the consequential conflicts arising from the performance of the preliminary updated timetable). The microsimulation solves all conflicts. Only because in every decision the consequential conflicts are ignored, the solutions are normally not optimal from a global perspective. However, since the preliminary updated timetable is available for this purpose in a very short time, it can also replace the existing regular timetable, which means that the conflicts existing in the replaced regular timetable can be reacted to without technically relevant time delays (more on this below).

In this connection a regular timetable is to be understood as the timetable laid down by the rail operator as standard, i.e. without the presence of any conflicts, and in this respect is already known before the start of operation of the vehicles in question. The achievable actual timetable is, after an adjustment of the regular timetable, to be understood as the updated timetable which replaces the regular timetable, in order to solve conflicts or at least as much as possible to minimize the effects thereof in the form of train delays. In other words, as soon as the regular timetable has been updated the method is also applied to the updated timetable if further conflicts arise.

However, it should be taken into account that the relevant preliminary updated timetable cannot normally be completely technically implemented by the individual vehicles. While the trackside computing environment can implement the TMS by completing the functionality of a comparison between the regular timetable and the actual timetable and, based on this, the creation of an updated timetable taking into account all vehicles and trackside limitations (for example permissible train headway times or distances, the maximum permissible route speed), the onboard computing environment can for example take into account current measured values which must be determined in the vehicle anyway due to the requirements for its functionality, but which physically limit the possibilities for the vehicle (for example the maximum acceleration capacity, the vehicle-related maximum permissible speed and the maximum braking capacity). These measured values also allow conclusions to be drawn about limiting factors for the implementation of the target timetable applicable to the vehicle in question, which is derived from the updated timetable.

In the context of this description of the invention, conflicts are defined as follows:

• • A conflict is the situation in which more than one train could run operationally over a route section, but only one train is permitted. All others must wait until the route section becomes free for it.
  • Waiting times and delays are the effects of conflicts—conflict consequences that are minimized.

Consequential conflicts arise because the vehicles would be mutually influenced when implementing their individually determined preliminary updated timetable as a target timetable. This means new waiting times would arise, which are to be inventively prevented. In addition, consequential conflicts can also be defined as other restrictions, for example an earliest departure time of certain resources (platform stop) or a maximum journey time between two resources, which can be useful to ensure that a train does not take too long to reach the next station. Hence the optimization problem for the timetable can be considered as an FJSP with blocking and no-waiting restrictions. As soon as routings for each train are established by the first solver, this type of problem can be effectively formulated by a disjoint solution which can be found with the second solver. This process is referred to below as macrosimulation. In this case, in order to achieve faster calculation times, the limitations taken into account in the microsimulation are disregarded when creating the optimized updated timetable.

By simplifying the FJSP in the second routine the optimized updated timetable is found in a greatly reduced computing time, but conflicts can arise once again if the optimized updated timetable cannot be implemented by individual vehicles. Hence the optimized updated timetable is returned to the first routine, so that conflicts remaining in the context of the microsimulation and in particular newly arisen conflicts can be identified.

Switching between the first routine and the second routine multiple times will lead to an ever greater improvement overall in both the preliminary current timetable and the optimized updated timetable. So that the process can be stopped, at least one abort condition is defined. A check is at least made here to see whether further optimization could not be achieved in the context of the second routine. This is the latest meaningful time to abort the calculation by using the first routine and the second routine and to specify the then valid current timetable, which is the preliminary updated timetable calculated in the last previous first routine (because a further optimization was not possible), as the current target timetable to be executed. This means that this new target timetable for the traffic to be performed in the relevant rail infrastructure from this point in time onwards is valid. In other words, an optimization occurs iteratively in two routines, while the two routines mutually influence one another:

First routine: There is a simple fast conflict solver (first solver), which when integrated with a synchronous microscopic simulation quickly solves individual conflicts; in this case it decides on routes and train sequences. It ignores the consequential conflicts (these are still unknown at the time of the solution) and is hence fast (˜300 ms per run). The solution is passed to the second routine.

Second routine: a flexible job shop problem (FJSP) based on conflicts (not infrastructure as known in accordance with the prior art) is formulated from the solved conflicts with consequential conflicts and is solved in the context of a macroscopic simulation. The corrected conflicts are passed to the first routine and enforced. A conflict is a “machine” in FJSP, relevant trains in the conflict are “jobs” of the FJSP. Delay transfers between conflicts as journey times from the microsimulation are transport times in the FJSP. Alternative routes for the trains (alternative conflicts on these routes) are the “flexible” part of FJSP (flexible in the conventional understanding means that a job could be machined on multiple alternative machines).

In the course of the iterations, conflicts in the FJSP are augmented by previous runs, so that the FJSP over time includes all important aspects (conflicts and dependencies thereof) of the current situation.

It is realistic for the first run of a first solver (microscopic simulation) to calculate a solution in under 1 second which solves about 90% of conflicts optimally. This solution can be implemented directly. The iterations together with the FJSP are realistically run 10 to 20 times within 5 to 10 minutes, wherein each cycle takes 10 to 20 seconds and produces a new (normally) better solution. So-called MILP solvers (MILP stands for mixed-integer linear programming) use multicore processors very efficiently, so that they scale well in the range of between 1 and 64 cores.

Estimation for a real solution: In a country such as Norway, about 1300 conflicts were solved with the first solver in a model test run when loading a timetable onto the infrastructure with many deviations. Most were individual conflicts without consequential conflicts. There were 110 independent conflict trees taking account of consequential conflicts, with the largest conflict tree of about 300 conflicts. All trees could be solved independently with the second solver. Most trees (108 out of 110) had 2 to 4 conflicts—these could be solved in milliseconds with MILP. Thus a major FJSP was about 300 binary variables in size. Such a size of task was solved reliably quickly (in less than 1 minute) and “well” enough by current MILP solvers: CBC (opensource), CPLEX, Gurobi (commercial).

In the prior art, the same system would have significantly higher complexity if it were to be solved holistically by a single solver. In an infrastructure-based formulation, the FJSP would be more than 500,000 variables in size. Problems of this magnitude are not suitable for the real-time solution (only for timetable creation in advance).

With the foregoing and other objects in view there is also provided, in accordance with a further aspect of the invention, a trackside computing environment of a track-guided transportation network, having at least one computing entity. In accordance with this aspect it is inventively provided that the trackside computing environment is configured to execute a method as described above.

With the foregoing and other objects in view there is provided, in accordance with a further aspect of the invention, a track-guided vehicle with an onboard computing environment, having at least one computing entity. In accordance with this aspect it is inventively provided that the onboard computing environment is configured to execute a method as described above. The advantages connected to these aspects of the invention have already been explained above, whereby reference is made to these advantages.

With the foregoing and other objects in view there is provided, in accordance with a further aspect of the invention, a computer program product, containing program commands which can be executed jointly by a trackside computing environment of a track-bound transportation network and an onboard computing environment of a track-guided vehicle operated in the transportation network. In accordance with this aspect it is inventively provided that the method is executed as described above.

In accordance with the invention, a computer program product containing program modules with program commands is thus described, whereby the program modules can run in the same computing entity or multiple computing entities of the computing environment. Through the use of the computer program product, which may include one computer program or multiple computer programs, the inventive method and/or the exemplary embodiments thereof can be executed in each case and the advantages described above are achieved with the execution.

With the foregoing and other objects in view there is provided, in accordance with a further aspect of the invention, a computer-readable storage medium, containing data which is stored as datasets by the storage medium. In accordance with this aspect it is inventively provided that the datasets make it possible to execute the computer program product described above as claimed in the last preceding claim.

In addition, a provision device for storing and/or providing the computer program in the form of a computer-readable storage medium is thus described. The provision device is for example a storage unit which stores the computer program and provides it for retrieval. Alternatively or additionally, the provision device is a network service, a computer system, a server system, in particular a distributed, for example cloud-based, computer system or virtual computer system which stores the computer program on a computer-readable storage medium and preferably provides it in the form of a data stream.

The provision takes place in the form of program datasets describing program modules as a file, in particular as a download file, or as a data stream, in particular as a download data stream, of the computer program product. The computer program product is for example transferred to a computing environment using the provision device, so that the inventive method can be executed in one computing entity or multiple computing entities of this computing environment.

EMBODIMENTS OF THE INVENTION

Variants describing developments of the invention are explained below without limitation of the basic idea of the invention.

In accordance with one variant, the aspects of the invention explained above are ascertained in that:

• • h) as soon as a preliminary updated timetable is completed, it is used correspondingly for step c),
  • i) until step g) is performed.

In this connection the feature h) means that the preliminary updated timetable is used immediately after its creation for the further operational sequence of the method in accordance with method step c). This implies that the preliminary updated timetable, which does not yet take the consequential conflicts into account, is used directly as a basis for the subsequent control of the vehicles, in order to enable a rapid improvement, before an optimized updated timetable is ready.

The feature i) means here, and preferably, that the method provides that the preliminary updated timetable is used until the abort criterion described in claim 1 is met in accordance with step g). This ensures that, as long as there is no definitive solution, the preliminary updated timetable will at least partially improve the operation of the vehicles as regards delays that arise, until the definitive solution has been found. An alternative embodiment could be in a scenario in which the preliminary updated timetable is reviewed regularly and updated as necessary in order to continue to ensure the most optimum operation possible until the abort criterion signals a definitive solution.

In accordance with one variant, the aspects of the invention explained above are determined by the fact that a second condition is also taken into account as an abort criterion, and resides in the fact that a specified computing time is exceeded, wherein only one of the conditions has to occur for the abort criterion to be considered as met.

In accordance with one variant the aspects of the invention explained above are determined by the fact that a third condition is also taken into account as an abort criterion, namely that a specified number of performances of the second routine and/or a specified number of performances of the first routine must not be exceeded, wherein only one of the conditions has to occur for the abort criterion to be considered as met.

The feature “abort criterion” means here that a limit or a specific point is determined at which the ongoing calculations for planning and optimizing timetables are discontinued and the current status of the timetable calculations is adopted. In this connection, the abort criterion ensures that the system can react efficiently and in good time in order to be employed in real time.

The fact that a “specified computing time is exceeded” means here that the calculations are interrupted as soon as a predefined maximum computing time is exceeded. This predefined computing time is a fixed duration, which should ensure that the calculations are completed within a particular timeframe, to enable timely and efficient decision-making.

The expression “wherein only one of the conditions has to occur for the abort criterion to be considered as met” means here that the abort criterion is already met if either the first or the second (or the third, if present) condition has occurred. The system thus does not require all conditions in order to consider the abort criterion as met.

In an alternative form of embodiment, the “specified computing time” could be adjusted dynamically and on the basis of different parameters such as the current traffic situation or the system load. Another alternative form of embodiment could provide that instead of a strict time limit, a computing-time-dependent performance evaluation is applied, in which the current result is evaluated after a certain computing time, and when a predetermined result quality is reached the calculations are likewise stopped. These alternatives ensure a flexible adjustment to different realistic scenarios.

In accordance with one variant the aspects of the invention explained above are determined by the fact that:

• • j) in step e) an achievable journey profile of at least one vehicle which is to implement the preliminary updated timetable is taken into account as an actual parameter.

One advantage of this variant is that aspects can be taken into account in the context of the microsimulation which are not taken into account in the context of macrosimulation. Within the microsimulation, the real behavior of the vehicles can be taken into account because of the low complexity of the subproblem of each microsimulation, since as a result the computing times increase only insignificantly.

In cases where the individual target timetable has to be modified and available journey time reserves are to be exploited, the minimal possible journey time of a vehicle to a timing point of interest is required. For this, the ATO onboard can be used by a simulated target timetable to rapidly calculate a precise forecast in the form of a journey profile (see below), without greater effects on operation.

In operation of the ATO an energy-optimized trajectory (this can be a speed profile, the speed being determined as a function of the elapsing journey time or the distance to be covered by the vehicle, generally also referred to below as the journey profile) is calculated. This requires as accurate as possible a model of the vehicle and its behavior (for example resistance/drive coefficients), which can only be estimated outside the vehicle. However, realistic model parameters are normally determined onboard during the journey by the control monitoring. As soon as these are available, they can then inventively also be used for the simulated individual target timetable to calculate a comparatively accurate journey time currently applicable for the vehicle. These are thus parameters which are to be employed in the calculated last updated timetable. The parameter sets mentioned can be part of a database, which can also be regularly updated or individualized.

A successful calculation of a journey profile for the above conditions is considered as a confirmation that the first solver and the ATO TS can in any case implement parameter sets which were chosen for the last created updated timetable. This is the case for most driving situations. However, for achievable actual timetables which were passed from the second routine to the first routine, it may subsequently turn out that they cannot be implemented by the vehicle in question, since a check in this regard did not take place in the second routine in accordance with the invention. The journey profile calculated as a test under the conditions mentioned is then no longer used by the ATO OB in accordance with the invention, because it was calculated merely to confirm the reserves available onboard. It is replaced in that a realistic scenario for the current timetable is taken as a basis by the first solver and in that a target timetable calculated therefrom is sent to the ATO OB. This immediately calculates a new journey profile which meets the actual requirements for the (preliminary) updated timetable.

The advantage of the confirmation by the ATO OB is that it can take into account the currently applicable real conditions for the vehicle in question, and thus fewer critical scenarios can be implemented as a journey profile with a very high degree of probability. When timetable changes are required, the first solver can then select parameter sets which solve the actual timetable conflicts present and can be successfully used by the ATO OB to calculate actually used journey profiles with a very high degree of probability. The computing times required for this can hence advantageously be even lower by avoiding recursions, meaning that the method can be used more efficiently.

The ATO OB and the ATO TS can be connected by what is known as an SS-126 interface (named as per UNISIG Standard for ATO over ETCS Subset 126). The SS126 interface contains a return channel, in that in response to the target timetable the ATO OB returns a prediction to the timing points (TP for short). Timing points refer to locations in the route profile for which a particular point in time is specified at which the vehicle is situated at the location in question. The point in time can be an arrival time or a departure time, in which case it is known as a stopping point, or a point in time of the passing time, in which case it is known as a passing point. These terms are in accord with the UNISIG Standard for ATO over ETCS, for example Subset-125.

Although the interface SS126 provides that the ATO OB, i.e. the onboard part of the ATO, can calculate a forecast and pass it to the ATO TS, the use of ATO OB by TMS as an accurate journey time calculation prior to the creation of a new individual target timetable for the vehicle has not hitherto been implemented. Currently this information is only used (retrospectively) as a fallback level in accordance with the standard if the TMS passes a non-achievable target timetable to the vehicle.

In accordance with one variant the aspects of the invention explained above are determined in that:

• • k) in step e) in accordance with claim 1 a message relating to a target timetable individual to the vehicle and implementing the preliminary updated timetable is sent to the onboard computing environment,
  • l) then a third computing entity in the onboard computing environment generates an individual journey profile taking into account the individual target timetable and sends a message relating to the journey profile to the trackside computing environment,
  • m) a check is made in the trackside computing environment to see whether the journey profile can implement the preliminary updated timetable,
  • n) if the journey profile cannot implement the preliminary updated timetable, step e) is repeated, wherein the individual journey profile is used as an achievable journey profile in step j).

In conflict solutions, there are cases in which minimum technical journey times are required in order to calculate certain scenarios. The ATO OB normally sends a response within 3-5 seconds. If the train is stationary, its standing time for the journey time determination can be used without “side effects” that the journey profile generated in the test procedure is implemented by the ATO OB. If the train is moving, the train would accelerate a maximum of 3-5 seconds after receiving the journey profile generated in the context of the test procedure (if the V-Max is not yet reached) and consume additional energy. However, this energy consumption is accepted in the interest of timetable optimization in accordance with the inventive method, since a greater potential for energy savings can be leveraged in the timetable optimization and delays can additionally be minimized.

Other features which are considered as characteristic for the invention are set forth in the appended claims.

Although the invention is illustrated and described herein as embodied in a method for operating a train control system, a trackside computing environment, a track-guided vehicle, a computer program product and a computer-readable storage medium, it is nevertheless not intended to be limited to the details shown, since various modifications and structural changes may be made therein without departing from the spirit of the invention and within the scope and range of equivalents of the claims.

The construction and method of operation of the invention, however, together with additional objects and advantages thereof will be best understood from the following description of specific embodiments when read in connection with the accompanying drawings.

Further details of the invention are described below on the basis of the drawing. Identical or corresponding drawing elements are each provided with the same reference characters in the individual figures and are only explained multiple times to the extent that differences arise between the individual figures.

The exemplary embodiments explained below are preferred forms of embodiment of the invention. In the case of the exemplary embodiments, the described components of the forms of embodiment each represent individual, independently considered variants of the invention, which also develop the invention independently of one another and are therefore also to be regarded as part of the invention individually or in a combination other than the one shown. Furthermore, the described components can also be combined with the variants of the invention described above.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a block diagram of an exemplary embodiment of the inventive apparatuses, i.e. the trackside computing environment and the diagrammatically-illustrated track-guided vehicle, with their interdependencies between the functional components employed;

FIG. 2 is a block diagram of an exemplary embodiment of a computing environment for the apparatuses in accordance with FIG. 1, showing the individual functional components and the interfaces formed therebetween, wherein individual computing entities execute program modules which can each run in one or more of the computers shown by way of example and wherein the interfaces shown can accordingly be executed in terms of software in a computer or in terms of hardware between different computers.

FIG. 3 is a block diagram representing the interaction of program modules or computing entities in each case in the trackside computing environment and the onboard computing environment, wherein the timetables and the journey profile are calculated or modified by a first solver and a second solver; and

FIG. 4 is a flow diagram of an exemplary embodiment of the inventive method, wherein the method steps shown can be implemented individually or in groups by program modules and wherein the computing entities and interfaces in accordance with FIG. 2 are indicated by way of example.

DETAILED DESCRIPTION OF THE INVENTION

Referring now to the figures of the drawings in detail and first, particularly, to FIG. 1 thereof, there is seen an exemplary environment in which train operation can be controlled and take place. A route network is represented by way of example by a track GL, on which a vehicle FZ is situated. On the track GL, route elements STE explained in more detail below are provided, and form a trackside infrastructure. The vehicle FZ, an interlocking STW, and a control center LZ each form by way of example an onboard unit (other vehicles FZ not shown would form other onboard units) and a trackside unit. In view of the operational sequence of the method, which is computer-aided, these units are also referred to as an onboard computing environment RUOB and a trackside computing environment RUTS.

A trackside computing environment RUTS and an onboard computing environment RUOB, in which the inventive method runs, can be taken from a joint consideration of FIG. 1 and FIG. 2. The computing entities and functional components employed interact with one another through interfaces. A vehicle FZ and an interlocking STW are connected to one another via antennas AT through a first interface S1. A control center LZ and the vehicle FZ are connected to one another via antennas AT through a second interface S2. The vehicle FZ and a satellite STL for positioning using GNNS (for example GPS) are connected to one another through a third interface S3. The control center LZ and the interlocking STW are connected to one another through a fourth interface S4. In other words, the control center LZ, the interlocking STW, and the vehicle FZ are networked to one another via air interfaces and the vehicle FZ can position itself using satellite support.

The interlocking STW additionally has connections to various route elements STE, in order to be able to perform control of the trackside infrastructure. This is indicated by way of example by the following components (real trackside infrastructures clearly have considerably more route elements STE and additionally other route elements STE). The interlocking STW and an axle counter AZ are connected to one another through a fifth interface S5. The interlocking STW and a balise BL are connected to one another through a sixth interface S6. The interlocking STW and a controller CTL with a processor (not shown) of a light signal SG are connected to one another through a seventh interface S7. The interlocking STW and a switch drive WA with a processor (not shown) for a switch W are connected to one another through an eighth interface S8.

In accordance with FIG. 2, the computers forming the respective computing entities are shown in greater detail. The vehicle FZ, the control center LZ, the interlocking STW, and a route element STE, which for example can be the axle counter AZ, the balise BL, the controller CTL or the switch drive WA in accordance with FIG. 1 or else another route element STE, are each schematically shown as boxes in FIG. 2, each of which contains at least one computer. The tasks in the individual units can of course also be processed by multiple interacting computers. In a first computer CP1 a first processor PR1 is connected to a first storage unit SE1 through an eleventh interface S11. In addition, by way of example, a sensor SN (for example a tachometer), which is shown in the vehicle FZ, is connected to the first processor PR1 via a tenth interface S10. In the same way further sensors SN (not shown) can be employed. In a second computer CP2 a second processor PR2 is connected to a second storage unit SE2 through a twelfth interface S12. In a third computer CP3 a third processor PR3 is connected to a third storage unit SE3 through a thirteenth interface S13. In a fourth computer CP4 a fourth processor PR4 is connected to a fourth storage unit SE4 though a fourteenth interface S14. If only computers, processors, storage units or interfaces are mentioned in the context of this description of the invention, the specifications generally refer to all the computers, processors, storage units, and other functional components mentioned individually above which, connected by the interfaces, contribute to the formation of the computing environment.

FIG. 3 shows the interworking of individual components of a train control system TMS taking into account the applicable timetables and journey profiles FP. As already explained, a distinction is made between the trackside computing environment RUTS and the onboard computing environment RUOB. A first solver SOV1 and a second solver SOV2 are employed at a planning level PLE in a first computing entity RI1, and as computing programs perform an optimization of timetables from various points of view. These have access to achievable actual timetables FPI, which are valid for the transportation network on the basis of real disruptions (but are not optimized with regard for example to a cumulative delay time of the vehicles involved in the implementation of the achievable actual timetable FPI) or which were created by the first solver SOV1 in a first routine R1 or by the second solver SOV2 in a second routine R2 (cf. FIG. 4) to a certain degree for example of the above-mentioned optimization. For the current achievable actual timetable, it can be used preliminarily as a target timetable in the vehicle FZ, having an onboard computing environment RUOB which is shown, even if it has not yet been definitively optimized. In any case, the first solver SOV1 has data available about the achievable actual timetable FPI, which describes the actual operational sequence in the transportation network and for example deviates from the regular timetable FPR due to delays or other disruptions without having undergone an optimization. With this achievable actual timetable FPI, the optimization procedure according to the first routine R1 and the second routine R2 is started.

Based on an analysis of the deviations between the regular timetable FPR and an achievable actual timetable FPI, in which the conflicts have not yet been solved (prior to the start of the first routine R1 and the second routine R2) or are not yet optimally solved (during the parallel run of the first routine R1 and the second routine R2 prior to the occurrence of an abort condition) the first solver SOV1 can use a microscopic simulation T to calculate an updated timetable FPA, which reacts to conflicts arising from the deviations found. The aim is to compensate for the disruptions and to bring the updated timetable FPA as close as possible back to the regular timetable FPR (i.e. with a view to the conflicts that have occurred and are foreseeable, but not the resulting consequential conflicts), i.e. to minimize delays of the vehicles involved in the implementation of the regular timetable FPR. The preliminary updated timetable FPA can be passed as a new achievable actual timetable FPI to the first routine R1.

The second solver SOV2 can now perform a macroscopic simulation, in order further to optimize the current achievable actual timetable FPI. Here the focus is on the conflicts and consequential conflicts not optimally solved in the achievable actual timetable FPI. The resulting updated timetable FPA can be passed to the first routine R1 as a new achievable actual timetable FPI. The recursion shown in FIG. 3 thus applies for the first solver SOV1 and the second solver SOV2, which are employed alternately in order to improve the achievable actual timetable iteratively by respective generation of updated timetables (preliminary/optimized), until an abort condition has occurred (more on this below).

A second computing entity RI2 in an execution level AFE implements the ATO TS. Here a target timetable FPS is calculated trackside together with a third computing entity RI3 in the vehicle FZ, which implements the ATO OB, on the basis of the current achievable actual timetable FPI, preferably the one after the abort condition is present, on the basis of the present achievable actual timetable FPI. This target timetable FPS includes a further optimization as regards the energy consumption of the vehicle FZ in question in the context of the possibilities of the specified achievable actual timetable FPI. In the example in accordance with FIG. 3 the generation of the target timetable FPS takes place in the ATO TS and the generation of the journey profile FP takes place in the ATO OB, but another division of labor between the second computing entity RI2 and the third computing entity RI3 can also be implemented. In the exemplary embodiment in accordance with FIG. 3 the third computing entity RI3 also returns the journey profile FP to the second computing entity RI2.

The ATC TS is employed as a fourth computing entity RI4 and the ATC OB is employed as a fifth computing entity RI5. In the interaction of the fourth computing entity RI4 with the fifth computing entity RI5, a safety-related control of the vehicle FZ in the route network is carried out. In this case, the fifth computing entity RI5 also checks the control requirements of the third computing entity RI3. As soon as a violation of the safety requirements occurs, the fifth computing entity RI5 intervenes, wherein the control functions of the fifth computing entity RI5 take precedence over those of the third computing entity RI3.

The execution level AFE explained can also be used to evaluate an achievable actual timetable during the first routine R1 and second routine R2 in order to check its implementability in the execution level AFE. This is preferably performed inventively with an achievable actual timetable, which was created by the first solver SOV1. This can be checked at the level of microsimulation in cooperation with the vehicle FZ in question, for implementability and in particular also for the optimization potential with regard to energy consumption. As a result, the latter optimization potential is already included in the first routine R1 for example, so that the updated timetable FPA resulting from the parallel performance of the first routine R1 and the second routine R2, which can be implemented in the final routine R2, is included.

In order to check an updated timetable FPA created by the first solver SOV1 as an achievable actual timetable FPI in the execution level AFE this can optionally be employed only for a short time in the execution level AFE. Since this is an achievable actual timetable FPI, it is unobjectionable from the point of view of functional safety. The check can be aborted after the presence of an evaluation result, so that the implementation of a preliminary achievable actual timetable FPI as a target timetable in the execution level AFE has few if any effects on the actual control of the vehicle FZ. However, a check is not absolutely necessary for an application of the inventive method.

The inventive method will be explained below by way of example step by step, as shown in the flow diagram in accordance with FIG. 4. Computer-aided steps take place in the processors not shown in greater detail. Where the interfaces in accordance with FIGS. 1 and 2 are used here, they are also characterized in FIG. 4.

In a first step 1 the method is started both in the trackside computing environment and in the onboard computing environment RUOB (START for short).

In a second step 2 a query is made as to whether the actual timetable FPI still corresponds to the regular timetable FPR (FPR=FPI? for short). This is the case as long as train traffic runs undisrupted. This means that no delays or train cancellations occur. Otherwise the actual timetable FPI deviates from the target timetable FPS. If no deviations can still be found, the query mentioned is repeated recursively. If however a deviation is found, the process continues with the third step 3.

In a third step 3 the first routine R1 is performed in the first solver SOV1 (EXE R1 for short). In this routine an updated timetable FPA is created, which is subsequently further processed in the fourth step 4 by the second routine R2 (second solver SOV2).

A determined updated timetable FPA can optionally be passed to the onboard computing environment RUOB as a target timetable, in order to perform an optimization in the execution level AFE as regards the energy consumption (as described above). A check as to whether the vehicle FZ in question reaches its physical limits in the execution of the actual timetable FPI can also be carried out on a test basis in this context. The process then continues with the fifth step 5, otherwise with the fourth step 4.

In a fourth step 4 the second routine R2 is performed in the second solver SOV2 (EXE R2 for short). In this routine an updated timetable FPA is created, in which consequential conflicts are also taken into account.

In a fifth step 5 a query is made as to whether an abort criterion is present, which forms a prerequisite for aborting the execution of the first routine R1 and of the second routine R2 (ABB? for short). The abort criterion can at least include the condition that during the execution of the second routine R2 no further improvement of the updated timetable FPA was possible compared to the updated timetable FPA transferred as an achievable actual timetable FPI by the first routine R1. If this is the case, the process continues with the fifth step 5. If this is not the case there is a recursion to the third step 3.

In a sixth step 6 a journey profile FP is created in the vehicle FZ, i.e. velocity curve over the distance covered or the remaining journey time until at least the next timing point (FP for short). When creating the journey profile FP, account is taken in a manner not shown of sensory measured values that were generated in the vehicle FZ.

In a seventh step 7 a check is made in the trackside computing environment across the board to see whether all journey profiles of the vehicles affected by the achievable actual timetable in particular can be implemented from the point of view of energy optimization. The result of the check can be included in the first routine (step 3) in a manner not shown in greater detail, in order to leverage a further optimization potential, so long as the first routine and the second routine still run in parallel.

In an eighth step 8 the journey profile FP currently applicable for the vehicle FZ is implemented (EXE FP for short). This is due to the fact that the onboard computing environment RUOB cannot distinguish between achievable actual timetables FPI in accordance with the third step 3 and the fifth step 5. Since the basis is in any case an achievable actual timetable, which may not yet be conclusively optimized, this is unobjectionable.

In a thirteenth step 13 a query is made as to whether the method should be stopped in the onboard computing environment RUOB, for example because of the end of operation (STP? for short). If this is not the case, a recursion is made to the sixth step 6, otherwise the method ends in the onboard computing environment.

In a fourteenth step 14 a query is made in parallel to the thirteenth step 13 as to whether the method should be stopped in the trackside computing environment RUTS (STP? for short). If this is the case, the method is stopped. However, if this is not the case, a recursion is made to the second step 2, to ensure that in the event of renewed timetable deviations the method for creating a simulated updated timetable SFPA is repeated.

In a 15th step 15 the method is terminated (STOP for short).

The following is a summary list of reference numerals and the corresponding structure used in the above description of the invention:

• • AFE Execution level
  • AT Antenna
  • AZ Axle counter
  • BL Balise
  • CP1 First computer
  • CP2 Second computer
  • CP3 Third computer
  • CP4 Fourth computer
  • CTL Controller
  • FP Journey profile
  • FPA Updated timetable
  • FPI Actual timetable
  • FPR Regular timetable
  • FPS Target timetable
  • FZ Vehicle
  • GL Track
  • LZ Control center
  • PLE Planning level
  • PR1 First processor
  • PR2 Second processor
  • PR3 Third processor
  • PR4 Fourth processor
  • R1 First routine
  • R2 Second routine
  • RI1 First computing entity
  • RI2 Second computing entity
  • RI3 Third computing entity
  • RI4 Fourth computing entity
  • RI5 Fifth computing entity
  • RUOB On-board computing environment
  • RUTS Trackside computing environment
  • S1 First interface
  • S10 Tenth interface
  • S11 Eleventh interface
  • S12 Twelfth interface
  • S13 13th interface
  • S14 14th interface
  • S2 Second interface
  • S3 Third interface
  • S4 Fourth interface
  • S5 Fifth interface
  • S6 Sixth interface
  • S7 Seventh interface
  • S8 Eighth interface
  • SE1 First storage unit
  • SE2 Second storage unit
  • SE3 Third storage unit
  • SE4 Fourth storage unit
  • SFPA Simulated updated timetable
  • SG Light signal
  • SN Sensor
  • SOV1 First solver
  • SOV2 Second solver
  • STE Route element
  • STL Satellite
  • STW Interlocking
  • TMS Train control system
  • W Switch
  • WA Switch drive