Method for operating a train management system

Abstract

The invention comprises a method for operating a train control system (TMS) in which a planning level (PLE) and an execution level (AFE) for executing target timetables (FPS) are implemented. Specifically, at the planning level (PLE), a first computing instance (RI1) calculates an updated timetable (FPA) to resolve conflicts. Subsequently, at the execution level (AFE), a second computing instance (RI2) receives a message from the first computing instance (RI1) specifying the updated timetable (FPA). In the first computing instance (RI1), a first routine (R1) and, sequentially to the first routine (R1), a second routine (R2) are executed.Routine (R1): Whenever a new feasible actual timetable (FPI) is available, a preliminary updated timetable (FPA) is calculated using a first solver (SOV1), without considering any subsequent conflicts in the preliminary updated timetable (FPA). The preliminary updated timetable (FPA) is then passed to the second routine (R2) as a feasible actual timetable (FPI). Second routine (R2): Whenever a feasible actual timetable (FPI) is passed from the first routine (R1), an optimized updated timetable (FPA) is calculated using a second solver (SOV2). Subsequent conflicts are considered in the optimized updated timetable (FPA), and as long as a termination criterion is not met, the optimized updated timetable (FPA) is passed to the first routine (R1) as a feasible actual timetable (FPI). Once the termination criterion is met, the last calculated updated timetable (FPA) will be used.Furthermore, the invention comprises a trackside computing environment, a track-guided vehicle, a computer program product and a computer-readable storage medium.

Description

Technical field

[0001] The invention comprises a method for operating a train control system. Furthermore, the invention comprises a trackside computing environment for a track-guided traffic network. The invention also comprises a track-guided vehicle with an on-board computing environment. Furthermore, the invention comprises a computer program product containing program instructions. The invention also comprises a computer-readable storage medium containing data. Technical background

[0002] The calculation of travel times for train control systems is based, in a well-known manner, on the solution of equations of motion by a computational instance, also known as a solver. However, the parameters used in real-world train operations are only known with insufficient accuracy (train resistance, mass, rotating masses, wind speed, and wind direction are variable quantities and depend on operating conditions such as weather, wear, and load). Therefore, the parameters are calculated using approximation formulas or average values ​​are assumed.

[0003] The primary goal of a train control system (hereinafter also referred to as a traffic management system or TMS) is to design a disruption-free timetable to minimize conflicts in the form of train delays. Typical optimization goals proposed according to the state of the art include minimizing the average delay or the cumulative delay, for example, by minimizing convex functions of train delays. Models for representing feasible solutions are based on the observation that by considering trains as orders (hereinafter also referred to as jobs) and track resources rather than machines, the train control problem becomes similar to the planning problem in a manufacturing plant (hereinafter referred to as a shop).This means that the occupancy time of a train on the resource corresponds to the processing time of a job on a machine (hereinafter referred to as the Flexible Job Shop Problem, or FJSP for short), for which solvers are used according to the state of the art (see, e.g., Leonardo Lamorgese et al., "Train Dispatching", Springer, 2018). However, there are some railway-specific aspects of the FJSP that must be considered. For example, a train that has reached the end of a resource cannot enter the next resource if it is occupied. Thus, timetable changes to resolve conflicts can create subsequent conflicts, which in turn delay the trains operating according to the changed timetable. In timetable theory, this is known as a blocking condition.

[0004] Currently, a forecast for the travel time of a train on a route from location A to location B in a TMS is calculated by a solver as follows: The current speed profile for the maximum possible speed from A to B is determined. A resistance profile for the route is calculated (gradients, curves, tunnels). The force-speed characteristic curve for the vehicle is taken into account. Resistance parameters are assumed for the vehicle's carriages, which can differ by a factor of 10 between smooth and slow-running carriages. Based on the parameters mentioned above, the differential equation of motion is solved either as an integral of a(t) = F / m for the overall trajectory or as F(v) during acceleration, and separately for constant speed and braking. This determines a minimum technical travel time.

[0005] This approach has the following disadvantages. Travel time calculation (forecasting) within the TMS is relatively time-consuming (calculation times in the range of minutes), complex, and based on numerous assumptions. These assumptions must be adapted to each use case to closely resemble real-world traffic. A multitude of parameters are required (e.g., train characteristics). Many parameters must be estimated or averaged. For example, for annual planning, a moderately efficient train with a specific train formation is assumed. Travel time calculation is relatively complex, making the software application comparatively resource-intensive. There is a risk that complex traffic situations cannot be optimized within a sufficiently short timeframe.

[0006] To implement timetables specified by the TMS (Train Management System), automated train operation (ATO) procedures are used in rail traffic, as is already known, and are secured by automatic train control (ATC) procedures. ATC performs safety-relevant automatic functions in train operation, such as emergency braking if a safety risk is detected. ATO optimizes train operation with regard to travel times and energy consumption. These functions are not safety-relevant, as modifying travel times and energy consumption does not pose any safety risks.Both the ATO and the ATC require cooperation between vehicle-side (hereinafter also referred to as onboard or OB for short) computing instances, consisting of hardware components and software components, and track-side (hereinafter also referred to as trackside or TS for short) computing instances, consisting of hardware components and software components.

[0007] The requirements for the certification of safety-relevant applications, for example in railway technology, are very high. According to the international standard IEC 61508, and specifically for the railway sector according to the European standard EN 50129, four Safety Integrity Levels (SILs) are distinguished for safety functions to ensure the required functional safety. 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; the higher the Safety Integrity Level that the respective device must meet, the smaller the confidence interval.The dimension of functional safety for the various Safety Integrity Levels (SILs) can be clearly described by the expected frequency of a failure of the safety-relevant system, MTBF (Mean Time Between Failures), which is expressed in years (a). For SIL-1, this ranges from 10 to 100 years, for SIL-2 from 100 to 1000 years, for SIL-3 from 1000 to 10000 years, and for SIL-4 from 10000 to 100000 years.

[0008] The TMS uses a solver to calculate an individual target timetable for a vehicle affected by a disruption, for example, based on a standard timetable that considers the interacting vehicles in a track-guided traffic network. The ATO-OB (Automated Train Operation - On-Board) is designed to calculate a forecast for a transmitted target timetable. This is based on precise knowledge of the vehicle and its environment (resistances, mass, rotating masses, ambient temperature, etc.), whereby the aforementioned parameters can be recorded in the vehicle, for example, by sensors.

[0009] The problem arising from the described state of the art is that a TMS should be used to create updated timetables that are as realistic as possible and in the shortest possible computing time, and which should be able to be implemented as feasible target timetables with a high probability of being able to operate without disruption. Summary of the invention

[0010] The object of the invention is to solve the problems described in the prior art. In particular, it is an object to further develop a method for operating a train control system, in which a trackside computing environment and a vehicle-side computing environment are used, such that the calculation of an updated timetable from a standard timetable can utilize the actually available travel time reserves as fully as possible and deliver a feasible result in the form of the updated timetable as quickly as possible. Furthermore, it is an object of the invention to specify a vehicle, a computer program product, and a computer-readable storage medium with which the improved method can be implemented.

[0011] According to a first aspect of the invention, a method for operating a train control system is described, in which a) A trackside computing environment and a vehicle-side computing environment are used, wherein a planning level and an execution level for target timetables to be executed are implemented in the trackside computing environment and in the vehicle-side computing environment, wherein in detail b) at the planning level, a first computing instance calculates an updated timetable, taking into account target parameters of the currently executed target timetable and conflicts arising from actual parameters of a feasible actual timetable in order to resolve the conflicts, c) thereafter, at the execution level, a second computing instance receives a message from the first computing instance that specifies the updated timetable as the currently executed target timetable.

[0012] The trackside computing environment and the vehicle-side computing environment are organized separately because the vehicles involved in implementing the target timetable, and thus collectively forming the vehicle-side computing environment, must move within the track-guided traffic network. More precisely, each vehicle moving within the traffic network forms an independent part of the vehicle-side computing environment, with at least one computing instance. The trackside computing environment can be used for multiple vehicles simultaneously. During the execution of the process, computing resources from both the vehicle-side and trackside computing environments are used, as explained in more detail below.It is necessary to divide the software running in the computing environments into suitable program modules for the vehicle-side computing environment and the track-side computing environment.

[0013] The message concerning the updated timetable is received by at least one processing unit and implemented in the control systems (both trackside and vehicle-side) in such a way that the vehicle can adhere to the target timetable resulting from the updated timetable, taking into account the applicable safety regulations. The safety regulations are considered in the calculation of the updated timetable at the first processing unit to ensure that the updated timetable is (at least with a high degree of probability) feasible after transmission to the vehicle.

[0014] Within the scope of this invention description, a target timetable to be executed is understood to be a target timetable that is currently being executed or whose execution is to begin immediately (also referred to as a target timetable currently being executed), or a target timetable that is to be executed in the future. The future execution of the target timetable to be executed can also be optional.

[0015] A feasible actual timetable is understood to be a timetable that at least partially resolves conflicts that arise (i.e., resolves or at least reduces delays). However, when a conflict occurs, this actual timetable is initially derived directly from the planned timetable without any optimization. Thus, the system only reacts to the conflicts that are currently occurring, which usually results in delays for the affected vehicles. For example, a vehicle might not enter a track section as scheduled because it is still blocked due to a delay caused by a preceding vehicle that should have already left that section.However, the term "realizable actual timetables" also includes timetables that have already achieved a certain degree of optimization with regard to conflicts, but whose further optimization potential is still uncertain and whose further optimization potential is yet to be realized. In this sense, every updated timetable is treated as a realizable actual timetable, regardless of how successful the optimization was. Within the scope of this invention description, a realizable actual timetable can always be used as a (currently) executable target timetable when an optimization process is to be completed.

[0016] A device is computer-aided or computer-implemented if it has a computing environment, or a method is computer-implemented if a computing environment performs at least one step of the method.

[0017] A computing environment is an IT infrastructure consisting of functional components such as processors, memory units, programs, and the data to be processed by these programs. This data is used to execute at least one application, which has a specific task to perform. Additional functional components can include 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 these functional components.

[0018] Within a computing environment or multiple computing environments, computing instances form functional units that can be assigned to applications (defined, for example, by a number of program modules) and can execute them. During application execution, these functional units form self-contained systems, either physically (e.g., computer, processor) and / or virtually (e.g., program module).

[0019] Computers are electronic devices consisting of several functional components and possessing data processing capabilities. For example, computers can be clients, servers, handheld computers, communication devices, and other electronic devices for data processing, which may include processors and memory units and may also be interconnected via interfaces to form a network.

[0020] Processors can be, for example, converters, 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 memory unit for storing program instructions and data. The term "processor" can also refer to a virtualized processor or a soft CPU.

[0021] Storage units can be implemented on computer-readable storage devices in the form of random-access memory (RAM) or data storage devices (hard disk or data carrier).

[0022] Program modules are individual software functional units that enable a program sequence of process steps according to the invention. These software functional units can be implemented in a single computer program or in several communicating computer programs. The interfaces implemented here can be implemented in software within a single processor or in hardware if multiple processors are used.

[0023] Interfaces can be implemented using hardware, for example wired or wireless connections, or software, for example as interaction between individual program modules of one or more computer programs, and serve to exchange data, preferably in the form of digital data sets or analog signals.

[0024] To avoid misunderstandings, it should be noted that individual claim features are numbered with lowercase Latin letters, without regard to the claim numbering. This means that each letter appears only once in the entire claim set, allowing for unambiguous addressing of the relevant claim features without mentioning the claim number. Therefore, the order of the letters is irrelevant.

[0025] According to the invention, it is provided that d) in the first computing instance, a first routine and, in parallel to the first routine, a second routine are executed, for the purpose of which e) in the first routine, whenever a new feasible actual timetable is available, a preliminary updated timetable is calculated with a first solver after procedure step b), without considering consequential conflicts in the preliminary updated timetable (i.e., without considering the resulting consequential conflicts when deciding on individual conflict resolutions in the microsimulation), wherein the preliminary updated timetable is passed to the second routine as a feasible actual timetable, f) in the second routine, whenever a feasible actual timetable has been passed from the first routine, an optimized updated timetable is calculated with a second solver after procedure step b), whereby consequential conflicts in the optimized updated timetable are taken into account, and wherein,as long as a termination criterion according to step g) is not met, the optimized updated timetable is passed to the first routine as a feasible actual timetable; g) as soon as the termination criterion is met, the last updated timetable calculated in steps e) and f) is used for step c), whereby at least a first condition is taken into account as a termination criterion that, according to step f), no different optimized updated timetable can be calculated compared to the last calculated preliminary updated timetable.

[0026] According to the invention, a relatively fast first solver is used to resolve conflicts in a regular timetable, which simultaneously represents a feasible actual timetable (as long as no conflicts have yet occurred). This solver calculates a solution for existing conflicts in a very short time because it only considers existing conflicts (which are understood to be conflicts that have already occurred or are directly foreseeable and arise from the actual parameters; thus, the calculation is based on a local analysis of the conflicts). Within the scope of this invention description, this calculation is referred to as microsimulation, and the result is referred to as a preliminary updated timetable, because this updated timetable cannot usually optimize all foreseeable conflicts (i.e., also the subsequent conflicts arising from the implementation of the preliminary updated timetable).While microsimulation resolves all conflicts, the fact that it ignores subsequent conflicts in every decision means the solutions are usually not optimal from a global perspective. However, since the preliminary updated timetable is available very quickly, it can replace the existing regular timetable, allowing for immediate responses to conflicts within the replaced timetable without significant technical delays (more on this below).

[0027] In this context, the standard timetable is understood to be the timetable that the railway operator sets as a matter of course, i.e., without any conflicts, and which is therefore known before the relevant vehicles begin operating. The feasible actual timetable, after an adjustment of the standard timetable, is the updated timetable that replaces the standard timetable in order to resolve conflicts or at least minimize their impact in the form of train delays. In other words, once the standard timetable has been updated, the procedure is also applied to the updated timetable if further conflicts arise.

[0028] It should be noted, however, that the relevant preliminary updated timetable is not usually fully technically feasible for individual vehicles. While the trackside computing environment can implement the TMS by performing a comparison between the regular timetable and the actual timetable, and then creating an updated timetable that takes into account all vehicles on the network and trackside limitations (e.g., permissible headways or intervals, the maximum permissible line speed), the vehicle-side computing environment, for example, can consider current measurements that must be determined in the vehicle anyway due to the requirements of its functionality, but which physically limit the vehicle's capabilities (e.g., maximum acceleration, vehicle-specific maximum permissible speed, and maximum braking capacity).These measurements 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.

[0029] Conflicts are defined as follows within the scope of this invention description. A conflict is a situation where more than one train could technically use a section of track, but only one train is permitted. All others must wait until the track is clear. Waiting times and delays are the effects of conflicts – consequences of conflicts that should be minimized.

[0030] Consequential conflicts arise because the vehicles would mutually influence each other when implementing their individually determined preliminary updated timetable as the target timetable. This would create new waiting times, which the invention aims to avoid. Furthermore, other constraints can also be defined as consequential conflicts, such as an earliest departure time from certain resources (platform stops) or a maximum travel time between two resources, which can be useful to ensure that a train does not take too long to reach the next station. Therefore, the timetable optimization problem can be viewed as a Free-Jumping-Sequence Problem (FJSP) with blocking and no-waiting constraints. Once routes for each train have been determined by the first solver, this type of problem can be effectively formulated by a disjoint solution that can be found with the second solver.This process is referred to below as macrosimulation. To achieve faster calculation times, the limitations considered in microsimulation are disregarded when creating the optimized, updated timetable.

[0031] Simplifying the FJSP in the second routine allows the optimized, updated timetable to be found in a significantly reduced computation time. However, conflicts can reoccur if individual vehicles cannot implement the optimized, updated timetable. Therefore, the optimized, updated timetable is returned to the first routine so that any remaining and, in particular, newly arising conflicts can be identified during the microsimulation.

[0032] The repeated switching between the first and second routines will lead to a continuous improvement of both the preliminary current timetable and the optimized, updated timetable. To allow the process to be stopped, at least one termination condition is defined. This condition checks whether further optimization could not be achieved within the second routine. This is the latest sensible point at which to terminate the calculation using the first and second routines and to specify the then-current timetable—which is the preliminary, updated timetable calculated in the last preceding first routine (since further optimization was not possible)—as the target timetable to be executed. This means that this new target timetable is valid for all traffic to be carried out from this point onward on the relevant railway infrastructure.In other words, optimization is performed iteratively in two routines, with each routine influencing the other: First routine: There is a simple, fast conflict resolver (first solver) that, integrated with a synchronous microscopic simulation, quickly resolves individual conflicts, deciding on routes and train sequences. It ignores subsequent conflicts (which are unknown at the time of solution) and is therefore fast (~300 ms per run). The solution is then passed to the second routine.

[0033] Second routine: From the resolved conflicts and their subsequent conflicts, a Flexible Job Shop Problem (FJSP) is formulated based on conflicts (not infrastructure as known according to the state of the art) and solved within a macroscopic simulation. The corrected conflicts are passed to the first routine and enforced. A conflict is a "machine" in FJSP, and the trains involved in the conflict are "jobs" of the FJSP. Delay propagation between conflicts, representing travel times from the microsimulation, constitutes transport times in the FJSP. Alternative routes for the trains (alternative conflicts on these routes) represent the "flexible" part of FJSP (in the classical understanding, flexible means that a job could be processed on several alternative machines).

[0034] During the iterations, conflicts in the FJSP are enriched from previous runs, so that over time the FJSP includes all important aspects (conflicts and their dependencies) of the current situation.

[0035] It is realistic that the first run of the first solver (microscopic simulation) computes a solution in under 1 second that optimally resolves approximately 90% of conflicts. This solution can be implemented directly. The iterations, together with the FJSP, are realistically run 10 to 20 times within 5 to 10 minutes, with each cycle taking 10 to 20 seconds and producing a new (usually) improved solution. So-called MILP solvers (MILP stands for Mixed-Integer Linear Programming) utilize multicore processors very efficiently, allowing them to scale well from 1 to 64 cores.

[0036] Estimate for a real-world solution: In a model test run for a country like Norway, when loading a timetable onto the infrastructure with numerous deviations, approximately 1300 conflicts were resolved using the first solver. Most were single conflicts without subsequent conflicts. This resulted in 110 independent conflict trees, taking subsequent conflicts into account, with the largest conflict tree containing approximately 300 conflicts. All trees could be solved independently using the second solver. Most trees (108 out of 110) had 2 to 4 conflicts – these could be solved closed in milliseconds using MILP. Thus, for an important FJSP (Future Timetable Problem), a size of approximately 300 binary variables was obtained. Tasks of this size were solved reliably, quickly (in less than 1 minute), and "well" enough by current MILP solvers: CBC (open source), CPLEX, and Gurobi (commercial).

[0037] With current technology, the same system would be significantly more complex if implemented holistically using a single solver. An infrastructure-based formulation would result in a FJSP with more than 500,000 variables. Problems of this magnitude are not suitable for real-time solutions (only for advance timetable planning).

[0038] According to a further aspect of the invention, a trackside computing environment of a track-guided traffic network is described, comprising at least one computing instance. According to this aspect, the invention provides that the trackside computing environment is configured to execute a method as described above.

[0039] According to a further aspect of the invention, a track-guided vehicle with a vehicle-side computing environment comprising at least one computing instance is described. According to this aspect, the vehicle-side computing environment is configured to execute a method as described above. The advantages associated with these aspects of the invention have already been explained above, and reference is made to these advantages.

[0040] According to a further aspect of the invention, a computer program product is described, containing program instructions that can be executed jointly by a trackside computing environment of a rail-bound traffic network and a vehicle-side computing environment of a track-guided vehicle operating in the traffic network. According to this aspect, the invention provides that the method is carried out as described above.

[0041] According to the invention, a computer program product containing program modules with program instructions is described, wherein the program modules can run in the same computing instance or in several computing instances of the computing environment. The computer program product, which can comprise one or more computer programs, can be used to execute the method according to the invention and / or its exemplary embodiments, and the advantages described above are achieved through its execution.

[0042] According to a further aspect of the invention, a computer-readable storage medium containing data, which is stored as data records on the storage medium, is described. According to this aspect, the invention provides that the data records make the computer program product described above, according to the last preceding claim, executable.

[0043] Furthermore, a provisioning device for storing and / or providing the computer program in the form of a computer-readable storage medium is described. The provisioning device is, for example, a storage unit that stores the computer program and makes it available for retrieval. Alternatively or additionally, the provisioning device is a network service, a computer system, a server system, in particular a distributed computer system, such as a cloud-based system or virtual computer system, which stores the computer program on a computer-readable storage medium and preferably makes it available in the form of a data stream.

[0044] The provision of the computer program product takes the form of program modules describing program data sets as a file, in particular as a download file, or as a data stream, in particular as a download data stream. The computer program product is transferred, for example, using the provisioning device to a computing environment so that the method according to the invention can be executed in one or more computing instances of this computing environment. Embodiments of the invention

[0045] Further developments of the invention, describing variants, are explained below without limiting the basic idea of ​​the invention.

[0046] According to one variant, the aspects of the invention explained above are determined by the fact that, h) once a preliminary updated timetable is finalized, it will be used for step c) as appropriate, i) until step g) is carried out.

[0047] In this context, feature h) means that the preliminary updated timetable is used immediately after its creation for the further course of the procedure according to process step c). This implies that the preliminary updated timetable, which does not yet take the resulting conflicts into account, is used directly as the basis for the subsequent control of the vehicles in order to enable rapid improvement before an optimized updated timetable is available.

[0048] Feature i) here means, and preferably, that the method provides for the use of the preliminary updated timetable until the termination criterion defined in claim 1 is met according to step g). This ensures that, as long as no final solution exists, the preliminary updated timetable at least partially improves the operation of the vehicles with regard to any delays that occur, until the final solution is found. An alternative embodiment could consist of a scenario in which the preliminary updated timetable is regularly reviewed and updated as needed to continue ensuring the most optimal operation possible until the termination criterion signals a final solution.

[0049] According to one variant, the aspects of the invention explained above are determined by the fact that a second condition is also taken into account as a termination criterion, which consists of exceeding a predetermined computation time, whereby only one of the said conditions has to occur for the termination criterion to be considered fulfilled.

[0050] According to one variant, the aspects of the invention explained above are determined by the fact that a third condition is also taken into account as a termination criterion, namely that a predetermined number of executions of the second routine and / or a predetermined number of executions of the first routine must not be exceeded, whereby only one of the said conditions has to occur for the termination criterion to be considered fulfilled.

[0051] The feature "termination criterion" here means that a boundary or specific point is defined at which the ongoing calculations for planning and optimizing timetables are stopped and the current state of the timetable calculations is adopted. In this context, the termination criterion ensures that the system can react efficiently and in a timely manner to be used in real time.

[0052] Exceeding the specified computation time means that the calculations are interrupted as soon as a predefined maximum computation time is exceeded. This predefined computation time is a fixed duration designed to ensure that the calculations are completed within a specific timeframe, enabling timely and efficient decision-making.

[0053] The phrase "where only one of the aforementioned conditions needs to be met for the termination criterion to be considered fulfilled" means that the termination criterion is already met if either the first or the second (or the third, if any) condition is met. The system therefore does not require all conditions to be met in order to consider the termination criterion fulfilled.

[0054] In an alternative embodiment, the "predetermined computation time" could be dynamically adjusted based on various parameters such as the current traffic situation or system load. Another alternative embodiment could employ a computation-time-dependent performance evaluation instead of a strict time limit. In this evaluation, the current result is assessed after a certain computation time, and calculations are stopped once a predetermined result quality is reached. These alternatives ensure flexible adaptation to various realistic scenarios.

[0055] According to one variant, the aspects of the invention explained above are determined by the fact that j) in step e) a realizable driving profile of at least one vehicle, which is to implement the preliminary updated timetable, is taken into account as an actual parameter.

[0056] One advantage of this approach is that microsimulation allows for the consideration of aspects that remain unaddressed in macrosimulation. Due to the low complexity of each microsimulation subproblem, the real-world behavior of the vehicles can be incorporated into the microsimulation, resulting in only a negligible increase in computation time.

[0057] In cases where the individual timetable needs to be modified and existing travel time reserves are to be utilized, the minimum possible travel time of a vehicle to a timing point of interest is required. For this purpose, the ATO onboard can be used with a simulated timetable to quickly calculate an accurate forecast in the form of a journey profile (also called a journey profile, see below), without major impact on operations.

[0058] During operation of the ATO, an energy-optimized trajectory (which can be a speed profile where the speed is determined as a function of the elapsed travel time or the distance to be covered, hereinafter also generally referred to as a driving profile) is calculated on the vehicle. This requires the most accurate possible model of the vehicle and its behavior (e.g., drag / drive coefficients), which can only be estimated outside the vehicle. However, realistic model parameters are usually determined onboard during the journey through control engineering observation. Once these are available, they can then be used, according to the invention, to calculate a comparatively accurate and currently applicable travel time for the simulated individual target schedule.These are parameters intended for use in the most recently calculated and updated timetable. The aforementioned parameter sets can be part of a database that can also be regularly updated or customized.

[0059] Successful calculation of a driving profile under the specified conditions is considered confirmation that the first solver and the ATO TS can definitely implement parameter sets selected for the most recently generated, updated timetable. This is the case for most driving situations. However, for feasible actual timetables transferred from the second routine to the first routine, it may subsequently turn out that these cannot be implemented by the vehicle in question, since a corresponding check was not performed in the second routine according to the invention. The driving profile calculated as a test under the specified conditions is then no longer used by the ATO-OB according to the invention, because it was only calculated to confirm the reserves available on the vehicle side.It is replaced by the first solver applying a realistic scenario to the current timetable and sending a calculated target timetable to the ATO-OB. This immediately calculates a new driving profile that meets the actual requirements for the (provisional) updated timetable.

[0060] The advantage of confirmation by the ATO OB lies in its ability to consider the currently prevailing real-world conditions for the vehicle in question, thus enabling the implementation of less critical scenarios as driving profiles with a very high probability. Subsequently, when timetable changes are necessary, the first solver can select parameter sets that resolve the actual timetable conflicts and can then be successfully used by the ATO OB to calculate the driving profiles actually in use with a very high probability. The computation times required for this can therefore be further reduced by avoiding recursion, making the process more efficient.

[0061] The ATO-OB and ATO-TS can be connected via an SS-126 interface (named after the UNISIG standard for ATO over ETCS Subset 126). The SS126 interface includes a feedback channel through which the ATO-OB sends a prediction of the timing points (TPs) in response to the planned timetable. Timing points are locations on the route profile for which a specific time is defined at which the vehicle will be located. This time can be an arrival time or a departure time, in which case it is called a stopping point, or a passing time, in which case it is called a passing point. These terms are consistent with the UNISIG standard for ATO over ETCS, for example, Subset 125.

[0062] While the SS126 interface allows the ATO OB (the vehicle-side part of the ATO) to calculate a forecast and transmit it to the ATO TS, the use of ATO OB by the TMS for precise travel time calculations before creating a new, individualized target timetable for the vehicle has not yet been implemented. Currently, this information is only used (subsequently) as a fallback option, in accordance with the standard, if the TMS transmits an unrealizable target timetable to the vehicle.

[0063] According to one variant, the aspects of the invention explained above are determined by the fact that k) in step e) according to claim 1, a message relating to a target timetable individual to the vehicle, which implements the preliminary updated timetable, is sent to the vehicle-side computing environment, l) thereafter a third computing instance in the vehicle-side computing environment generates an individual driving profile taking into account the individual target timetable and sends a message relating to the driving profile to the trackside computing environment, m) in the trackside computing environment it is checked whether the driving profile can implement the preliminary updated timetable, n) if the driving profile cannot implement the preliminary updated timetable, step e) is repeated, wherein the individual driving profile is used as a realizable driving profile in step j).

[0064] In conflict resolution, there are cases where minimal technical travel times are required to calculate certain scenarios. The ATO-OB typically sends a response within 3-5 seconds. If the train is stationary, its stationary time can be used to determine the travel time without the "side effect" of the ATO-OB implementing the driving profile generated in the test procedure. If the train is moving, it would, for example, accelerate to its maximum speed (if the maximum speed has not yet been reached) during the 3-5 seconds after receiving the driving profile generated in the test procedure, thereby consuming additional energy. However, this energy consumption is accepted in the interest of timetable optimization according to the inventive method, since timetable optimization can unlock greater potential for energy savings and, moreover, minimize delays. Exemplary embodiments of the drawing

[0065] Further details of the invention are described below with reference to the drawing. Identical or corresponding drawing elements are provided with the same reference numerals in each figure and are only explained more than once to the extent that differences arise between the individual figures. The exemplary embodiments described below are preferred embodiments of the invention. In these exemplary embodiments, the described components of the embodiments each represent individual variants of the invention, which can be considered independently of one another. Each of these variants further develops the invention independently and can therefore be considered part of the invention individually or in a combination other than that shown. Furthermore, the described components can also be combined with the variants of the invention described above. Figure 1schematically shows an embodiment of the devices according to the invention, i.e. the trackside computing environment and the track-guided vehicle, with their interrelationships between the functional components used. Figure 2 shows an exemplary embodiment of a computing environment for the devices according to Figure 1 as a block diagram of the individual functional components and the interfaces formed between them, wherein individual computing instances execute program modules that can each run in one or more of the exemplary computers shown, and wherein the interfaces shown can accordingly be implemented in software in one computer or in hardware between different computers. Figure 3shows a schematic representation of the interaction of program modules or computing instances in the trackside computing environment and the vehicleside computing environment, whereby the timetables and the driving profile are calculated or modified by a first solver and a second solver. Figure 4 An embodiment of the method according to the invention is shown as a flowchart, wherein the process steps shown can be implemented individually or in groups by program modules, and wherein the computing instances and interfaces are defined according to Figure 2 are indicated by example. Detailed description of the exemplary implementations

[0066] The Figure 1This diagram illustrates an exemplary environment in which train operations can be controlled and carried out. A track network is represented by a track GL on which a vehicle FZ is located. Track GL is connected to track elements STE, which will be explained in more detail below and form trackside infrastructure. The vehicle FZ, an interlocking system STW, and a control center LZ each represent, for example, a vehicle-side unit (additional vehicles FZ, not shown, would form other vehicle-side units) and a trackside unit. Due to the computer-aided nature of the process, these units are also referred to as the vehicle-side computing environment RUOB and the trackside computing environment RUTS.

[0067] A trackside computing environment RUTS and a vehicle-side computing environment RUOB, in which the inventive method takes place, can be considered together. Figure 1 and Figure 2The computing instances and functional components used interact with each other via interfaces. A first interface, S1, connects a vehicle (FZ) and an interlocking system (STW) via antennas (AT). A second interface, S2, connects a control center (LZ) and the vehicle (FZ) via antennas (AT). A third interface, S3, connects the vehicle (FZ) and a satellite for GNSS (e.g., GPS) positioning. A fourth interface, S4, connects the control center (LZ) and the interlocking system (STW). In other words, the control center (LZ), the interlocking system (STW), and the vehicle (FZ) are networked via wireless interfaces, and the vehicle (FZ) can locate itself using satellite support.

[0068] The STW interlocking system also has connections to various trackside elements (STE) to control the trackside infrastructure. This is illustrated by the following components (real trackside infrastructure naturally has many more trackside elements (STE) and also additional trackside elements). A fifth interface, S5, connects the STW interlocking system to an axle counter (AZ). A sixth interface, S6, connects the STW interlocking system to a balise (BL). A seventh interface, S7, connects the STW interlocking system to a controller (CTL) and a processor (SG) for a light signal (not shown). An eighth interface, S8, connects the STW interlocking system to a point motor (WA) and a processor (W) for a point (not shown).

[0069] According to Figure 2The computers forming the respective computing instances are described in more detail. These include the vehicle FZ, the control center LZ, the signal box STW, and a track element STE, which might include, for example, the axle counter AZ, the balise BL, the controller CTL, or the point drive WA. Figure 1The components, which can also be other track elements STE, are each schematically represented as boxes in Figure 2, each containing at least one computer. Naturally, the tasks in the individual units can also be processed by several interacting computers. In a first computer CP1, a first processor PR1 is connected to a first memory unit SE1 via an eleventh interface S11. Furthermore, a sensor SN (for example, a speedometer) in the vehicle FZ is shown as an example, which is connected to the first processor PR1 via a tenth interface S10. Additional sensors SN, not shown, can be used in the same way. In a second computer CP2, a second processor PR2 is connected to a second memory unit SE2 via a twelfth interface S12. In a third computer CP3, a third processor PR3 is connected to a third memory unit SE3 via a thirteenth interface S11.Interface S13 is connected. In a fourth computer CP4, a fourth processor PR4 is connected to a fourth memory unit SE4 via a 14th interface S14. When this description of the invention refers only to computers, processors, memory units, or interfaces, the information generally refers to all of the computers, processors, memory units, and other functional components named above in detail, which, connected via the interfaces, contribute to the formation of said computing environments.

[0070] In Figure 3The interaction of individual components of a train control system (TMS) is depicted, taking into account the applicable timetables and driving profiles (FP). As already explained, a distinction is made between the trackside computing environment (RUTS) and the vehicle-side computing environment (RUOB). At a planning level (PLE), a first computing instance (RI1) employs a first solver (SOV1) and a second solver (SOV2), which, as computational programs, optimize timetables from various perspectives. These programs have access to feasible actual timetables (FPI) that apply to the transport network due to real disruptions (however, they are not optimized with regard to, for example, the cumulative delay time of the vehicles (FZ) involved in realizing the feasible actual timetable FPI) or that are generated by the first solver (SOV1) in a first routine (R1) or the second solver (SOV2) in a second routine (R2) (see [reference]). Figure 4) with a certain degree of optimization, for example, as described above. The current feasible actual timetable can be used provisionally as the target timetable in the vehicle FZ, whose on-board computing environment RUOB is represented, even if it has not yet been fully optimized. In any case, the first solver SOV1 has access to data about the feasible actual timetable FPI, which describes the actual flow of traffic in the network and deviates from the standard timetable FPR, for example, due to delays or other disruptions, without having undergone optimization. The optimization process is then started using this feasible actual timetable FPI, according to the first routine R1 and the second routine R2.

[0071] The first solver, SOV1, can calculate an updated timetable, FPA, based on an analysis of the deviations between the standard timetable (FPR) and a feasible actual timetable (FPI), where conflicts are either not yet resolved (before the start of the first routine R1 and the second routine R2) or not yet optimally resolved (during the parallel execution of the first routine R1 and the second routine R2 before a termination condition occurs). Using microscopic simulation, SOV1 calculates an updated timetable FPA that reacts to conflicts arising from the identified deviations. The aim is to compensate for the disturbances and to approximate the updated timetable FPA as closely as possible to the standard timetable FPR (i.e., with regard to the conflicts that have occurred and are foreseeable, but not the resulting consequential conflicts). This minimizes delays for the vehicles FZ involved in implementing the standard timetable FPR.The preliminary updated timetable FPA can be passed to the first routine R1 as the new feasible actual timetable FPI.

[0072] The second solver, SOV2, can now perform a macroscopic simulation to further optimize the current feasible actual timetable (FPI). The focus here is on conflicts and subsequent conflicts that are not optimally resolved in the feasible actual timetable (FPI). The resulting updated timetable (FPA) can then be passed to the first routine, R1, as the new feasible actual timetable (FPI). Figure 3 The recursion shown thus applies to the first solver SOV1 and the second solver SOV2, which are used alternately to iteratively improve the feasible actual timetable by generating updated timetables (provisional / optimized) until a termination condition occurs (more on this below).

[0073] A second computing instance RI2 in an execution level AFE implements the ATO-TS. Here, on the trackside, together with a third computing instance RI3 in the vehicle FZ, which implements the ATO-OB, a target timetable FPS is calculated based on the current feasible actual timetable FPI, preferably the one after the termination condition is met, and implemented as a driving profile FP. This target timetable FPS includes further optimization regarding the energy consumption of the vehicle FZ within the possibilities of the given feasible actual timetable FPI. In the example according to Figure 3 The target timetable (FPS) is generated in the ATO-TS and the driving profile (FP) in the ATO-OB; however, a different division of labor between the second computing instance (RI2) and the third computing instance (RI3) can also be implemented. In the exemplary embodiment according to... Figure 3The third computing instance RI3 also returns the driving profile FP to the second computing instance RI2.

[0074] The fourth computing instance, RI4, is the ATC-TS, and the fifth, RI5, is the ATC-OB. The interaction between the fourth and fifth computing instances, RI4 and RI5, enables safety-relevant control of the vehicle (FZ) within the rail network. The fifth computing instance, RI5, also checks the control instructions of the third computing instance, RI3. As soon as a violation of the safety instructions occurs, the fifth computing instance, RI5, intervenes, with its control functions taking precedence over those of the third computing instance, RI3.

[0075] The execution level AFE described above can also be used during the execution of the first routine R1 and the second routine R2 to evaluate a feasible actual timetable in order to verify its implementation at the execution level AFE. According to the invention, this is preferably carried out with a feasible actual timetable generated by the first solver SOV1. This timetable can be checked for feasibility and, in particular, for its optimization potential with regard to energy consumption at the microsimulation level in conjunction with the vehicle FZ in question. This optimization potential is then incorporated, for example, into the first routine R1, so that the updated timetable FPA resulting from the parallel execution of the first routine R1 and the second routine R2, which is implemented in the final feasible actual timetable, is included.

[0076] For the purpose of verifying an updated timetable FPA generated by the first solver SOV1 as a feasible actual timetable FPI in the execution level AFE, it can optionally be used in the execution level AFE only for a short time. Since it is a feasible actual timetable FPI, this is safe from the perspective of functional safety. The verification can be terminated after an evaluation result is available, so that the implementation of a preliminary feasible actual timetable FPI as a target timetable in the execution level AFE has no or at least only a minor impact on the actual control of the vehicle FZ. However, verification is not strictly necessary for the application of the method according to the invention.

[0077] The following describes the method according to the invention by way of example, as shown in the flowchart according to Figure 4The process will be presented and explained step by step. Computer-aided steps take place in the processors, which are not shown in detail. Insofar as the interfaces are as described above, Figure 1 and 2 These can also be used in Figure 4 marked.

[0078] In a first step 1, the procedure is started both in the trackside computing environment and in the vehicleside computing environment RUOB (short: START).

[0079] In a second step, step 2, a check is performed to determine whether the actual timetable (FPI) still corresponds to the regular timetable (FPR). (In short: FPR = FPI?). This is the case as long as train traffic runs smoothly. This means that no delays or train cancellations occur. Otherwise, the actual timetable (FPI) deviates from the planned timetable (FPS). If no deviations are detected, the aforementioned check is repeated recursively. However, if a deviation is detected, the process continues with step 3.

[0080] In a third step, the first routine is executed in the first solver, R1 (SOV1 for short). This routine creates an updated timetable, FPA, which is then further processed in the fourth step by the second routine, R2 (second solver, SOV2).

[0081] Optionally, a determined, updated timetable FPA can be transferred as a target timetable to the vehicle's computing environment RUOB to optimize energy consumption at the execution level AFE (as described above). A test check can also be performed in this context to determine whether the vehicle FZ reaches its physical limits when executing the actual timetable FPI. If so, the process continues with step 5; otherwise, it proceeds to step 4.

[0082] In a fourth step, the second routine R2 is executed in the second solver SOV2 (abbreviated: EXE-R2). This routine generates an updated roadmap FPA, which also takes subsequent conflicts into account.

[0083] In a fifth step (5), a check is performed to determine if a termination criterion exists that would justify aborting the execution of both the first routine R1 and the second routine R2 (abbreviated as ABB?). The termination criterion can include at least 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 passed by the first routine R1 as the feasible actual timetable FPI. If this is the case, the process continues with step 5. If not, the process recursively returns to step 3.

[0084] In a sixth step, a driving profile (FP) is created in the vehicle (FZ). This profile represents the speed profile over the remaining distance traveled or the remaining driving time until at least the next timing point (FP). Sensor measurements generated in the vehicle (FZ) are taken into account during the creation of the driving profile (FP), although these measurements are not shown.

[0085] In a seventh step, a comprehensive check is performed in the trackside computing environment to determine whether all driving profiles of the vehicles affected by the feasible actual timetable are implementable, particularly with regard to energy optimization. The result of this check can be incorporated into the first routine (step 3) in a manner not described in detail, in order to unlock further optimization potential, as long as the first and second routines are still running in parallel.

[0086] In an eighth step (8), the driving profile FP (EXE-FP) currently applicable to the vehicle FZ is implemented. This is because the vehicle's computing environment RUOB cannot distinguish between feasible actual driving plans FPI according to the third step (3) and the fifth step (5). Since the basis in every case is a feasible actual driving plan, which may simply not yet be fully optimized, this is not a problem.

[0087] In the eleventh step, the driving profile FP (abbreviated: EXE-FP) calculated in the last step is now implemented. This is the driving profile FP that allows the current target timetable to be adhered to.

[0088] In step 13, a query is performed to determine whether the process should be stopped in the vehicle's computing environment RUOB, for example, due to end of operation (abbreviated as STP?). If this is not the case, the process recursively returns to step 6; otherwise, the process terminates in the vehicle's computing environment.

[0089] In step 14, parallel to step 13, a query is performed to determine whether the process should be stopped in the trackside computing environment RUTS (abbreviated as STP?). If so, the process is stopped. If not, a recursion to step 2 occurs to ensure that the process for creating a simulated updated timetable (SFPA) is repeated in the event of further timetable deviations.

[0090] In step 15, the process is terminated (abbreviated: STOP). Reference symbol list

[0091] AFE Execution level AAntenna AZAx counter BLBalise CP1First computer CP2Second computer CP3Third computer CP4Fourth computer CTLController FPDriving profile FPAUpdated timetable FPIActual timetable FPRRegular timetable FPSTarget timetable FZVehicle GLTrack LZControl center PLEPlanning level PR1First processor PR2Second processor PR3Third processor PR4Fourth processor R1First routine R2Second routine RI1First computing instance RI2Second computing instance RI3Third computing instance RI4Fourth computing instance RI5Fifth computing instance RUOBVehicle-side computing environment RUTSTrack-side computing environment S1First interface S10Tenth interface S11Eleventh interface S12Twelfth interface S13Third interface S14Fourth interfaceInterface 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 SFP Simulated updated timetable SG Light signal SN Sensor SOV1 First solver SOV2 Second solver STE Track element STW Interlocking system TMS Train guidance system W Switch WA Switch drive.

Claims

1. A method for operating a train control system (TMS) in which a) a trackside computing environment (RUTS) and a vehicle-side computing environment (RUOB) are used, wherein a planning level (PLE) and an execution level (AFE) for target timetables (FPS) to be executed are implemented in the trackside computing environment (RUTS) and in the vehicle-side computing environment (RUOB), wherein, in detail, b) at the planning level (PLE), a first computing instance (RI1) calculates an updated timetable (FPA) taking into account target parameters of the currently executed target timetable (FPS) and conflicts arising from actual parameters of a feasible actual timetable (FPI) to resolve the conflicts, c) thereafter, at the execution level (AFE), a second computing instance (RI2) receives a message from the first computing instance (RI1) specifying the updated timetable (FPA) as the currently executed target timetable (FPS). characterized by the fact thatd) in the first computing instance (RI1) a first routine (R1) and a second routine (R2) run in parallel to the first routine (R1), for the purpose of executing the second routine (R2) e) in the first routine (R1) whenever a new feasible actual timetable (FPI) is available, a preliminary updated timetable (FPA) is calculated with a first solver (SOV1) after procedure step b), without taking into account any subsequent conflicts in the preliminary updated timetable (FPA), wherein the preliminary updated timetable (FPA) is passed to the second routine (R2) as a feasible actual timetable (FPI), f) in the second routine (R2) whenever a feasible actual timetable (FPI) has been passed from the first routine (R1), an optimized updated timetable (FPA) is calculated with a second solver (SOV2) after procedure step b), whereby subsequent conflicts in the optimized updated timetable (FPA) are taken into account and wherein,as long as a termination criterion according to step g) is not met, the optimized updated timetable (FPA) is passed to the first routine (R1) as the feasible actual timetable (FPI); g) as soon as the termination criterion is met, the last updated timetable (FPA) calculated in steps e) and f) is used for step c), whereby at least a first condition is taken into account as a termination criterion that, according to step f), no different optimized updated timetable (FPA) can be calculated compared to the last calculated preliminary updated timetable (FPA).

2. Method according to claim 1, characterized by the fact that , h) once a preliminary updated timetable (FPA) is completed, it is used for step c) according to claim 1, i) until step g) according to claim 1 is carried out.

3. Method according to one of claims 1 or 2, characterized by the fact thatA second condition is also considered as a termination criterion: that a predetermined computation time is exceeded, whereby only one of the aforementioned conditions needs to occur for the termination criterion to be considered fulfilled.

4. Method according to any of the preceding claims, characterized by the fact that A third condition is also considered as a termination criterion: that a predetermined number of executions of the second routine (R2) and / or a predetermined number of executions of the first routine (R1) must not be exceeded, whereby only one of the aforementioned conditions must occur for the termination criterion to be considered fulfilled.

5. Method according to any one of the preceding claims, characterized by the fact that j) in step e) according to claim 1, a realizable driving profile (FP) of at least one vehicle (FZ) that is to implement the preliminary updated timetable (FPA) is taken into account as an actual parameter.

6. Method according to claim 5, characterized by the fact thatk) in step e) according to claim 1, a message relating to a target timetable (FPS) for the vehicle (FZ) that implements the preliminary updated timetable (FPA) is sent to the vehicle-side computing environment (RUOB), l) thereafter a third computing instance (RI3) in the vehicle-side computing environment (RUOB) generates an individual driving profile (FP) taking into account the individual target timetable (FPS) and sends a message relating to the driving profile (FP) to the trackside computing environment (RUTS), m) in the trackside computing environment (RUTS) it is checked whether the driving profile (FP) can implement the preliminary updated timetable (FPA), n) if the driving profile (FP) cannot implement the preliminary updated timetable (FPA), step e) according to claim 1 is repeated, wherein the individual driving profile (FP) is used as a realizable driving profile (FP) in step j) according to claim 5.

7. Trackside computing environment of a track-guided traffic network, comprising at least one computing instance, characterized by the fact that which at least one computing instance is set up as part of the trackside computing environment (RUTS) to execute a method according to one of claims 1 to 6.

8. Track-guided vehicle with a vehicle-side computing environment (RUOB), comprising at least one computing instance, characterized by the fact that the at least one computing instance is set up as part of the vehicle-side computing environment (RUOB) to execute a method according to one of claims 1 to 6.

9. Computer program product comprising program instructions that can be jointly executed by a trackside computing environment (RUTS) of a track-bound traffic network and a vehicle-side computing environment (RUOB) of a track-guided vehicle (FZ) operated in the traffic network, such that the method according to one of claims 1 - 6 is executed.

10. Computer-readable storage medium containing data which are stored as data records on the storage medium, such that the data records make the computer program product according to the last preceding claim executable.

Images