Method for operating a feeding system with updated driving plan

Abstract

The invention encompasses the following: a method for operating a train control system (TMS). It provides for the use of a trackside computing environment (RUTS) and a vehicle-side computing environment (RUOB), wherein a first computing instance (RI1) calculates an updated timetable (FPA) taking into account control parameters of a standard timetable (FPR) and deviation parameters derived from the actual timetable (FPI) compared to the standard timetable (FPR). Subsequently, a second computing instance (RI2) sends a message concerning an individual target timetable (FPS) to the vehicle-side computing environment (RUOB). Following this, a third computing instance (RI3) generates a driving profile (FP) taking the target timetable (FPS) into account and sends a message concerning the driving profile (FP) to the trackside computing environment (RUTS).According to the invention, a query routine is implemented in the first computing instance (RI1). To execute this routine, the first computing instance (RI1) calculates a simulated updated timetable (SFPA). The second computing instance (RI2) then sends a message to the vehicle-side computing environment (RUOB) describing a simulated individual target timetable (FPS) for the vehicle (FZ). The third computing instance (RI3) then generates a driving profile (FP) in the vehicle-side computing environment (RUOB), taking the target timetable (FPS) into account, and sends a message concerning the driving profile (FP) to the trackside computing environment (RUTS). The message is then used by the first computing instance (RI1) to calculate the updated timetable (FPA).

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. Finally, the invention comprises a computer-readable storage medium containing data. Technical background

[0002] Travel time calculations are 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 precision (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] Currently, a forecast for the travel time of a train on a route from point A to point B in a train control system (hereinafter also referred to as Train Management System, or TMS for short) is calculated by a solver as follows: The current speed profile for the maximum possible speed of AB 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 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. Network-wide, uniform travel time allowances of, for example, 2–3% can also be added, although this is usually achieved by reducing the maximum speed by 2–3%, thereby neglecting braking and acceleration processes.

[0004] 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 car formation is assumed. Assumptions are made regarding wind direction and speed. The dependence of resistance parameters on ambient temperature is ignored. Assumptions are also made regarding train load. Travel time calculation is relatively complex, making the software application comparatively resource-intensive.

[0005] To implement timetables specified by the TMS (Train Management System), automated train operation (ATO) procedures are used in rail traffic, as is customary, 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.

[0006] 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.

[0007] 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.

[0008] Since the solver does not know the vehicle's current parameters but only considers probable assumptions of these parameters, it can happen that a target timetable calculated by the solver cannot be implemented by the vehicle if unexpectedly unfavorable conditions arise. This situation can be reported back to the ATO-OB (Automatic Train Operator - Operational Control) to recalculate the affected target timetable and, if necessary, the updated timetable. However, this involves a further time delay, which exacerbates the timetable situation (for example, caused by delays).

[0009] The object of the invention is to create updated timetables that are as realistic as possible using a TMS - i.e., 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, in such a way that the calculation of an updated timetable from a regular timetable can exploit the actually available reserves as much as possible and deliver a feasible result in the form of the updated timetable as quickly as possible.

[0010] The problem arising from the described state of the art is that a TMS should be able to create updated timetables that are as realistic as possible in the shortest possible computing time. Summary of the invention

[0011] 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.

[0012] The problem is solved by a method for operating a train control system, in which a) A trackside computing environment and a vehicle-side computing environment are used, wherein the trackside computing environment and the vehicle-side computing environment exchange messages, wherein b) a first computing instance in the trackside computing environment calculates an updated timetable, taking into account control parameters of a standard timetable and deviation parameters resulting from the actual timetable compared to the standard timetable. (The first computing instance identifies particularly critical trains that obstruct other trains. These critical trains should fully utilize their actual travel time reserves to minimize the propagation of delays. To determine the actual minimum travel time in the relevant area, the first instance calculates such fast timetables for the critical trains that they are not feasible.)These timetables are sent to the second computing instance), c) then a second computing instance sends a message to the vehicle-side computing environment concerning a target timetable, individual to the vehicle and implementing the updated timetable, d) then a third computing instance in the vehicle-side computing environment generates a (preferably the fastest possible) driving profile taking the target timetable into account and sends a message concerning the driving profile to the trackside computing environment.

[0013] During the execution of feature d), the trains may accelerate as they attempt to implement the fastest driving profiles. Once the fastest driving profile reaches the second processing instance, it sends the previous timetable to the third, train-side processing instance. The first processing instance uses the fastest driving profiles to generate a conflict-free, drivable target timetable. This is then sent to the second processing instance for implementation (more on this below).

[0014] The trackside computing environment and the vehicle-side computing environment are organized separately because the vehicle must move within the track-guided traffic network. More precisely, each vehicle moving within the traffic network forms its own vehicle-side computing environment. 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. This requires distributing the software running in the computing environments between the vehicle-side and trackside computing environments in the form of suitable program modules.

[0015] 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.

[0016] 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.

[0017] Within a computing environment, 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).

[0018] 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.

[0019] 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.

[0020] 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).

[0021] 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.

[0022] 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.

[0023] 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.

[0024] According to the invention, a query routine is implemented in the first computing instance, for the execution of which e) the first computing instance calculates a simulated updated timetable, for which predefined test parameters are used at least in part instead of the control parameters and deviation parameters, f) then the second computing instance sends a message to the vehicle-side computing environment describing a target timetable that implements the simulated updated timetable and is individual to the vehicle, g) then the third computing instance generates a driving profile in the vehicle-side computing environment, taking the target timetable into account, and sends a message concerning the driving profile to the trackside computing environment, h) then the procedure steps b), c) and d) are carried out, taking the message concerning the driving profile into additional consideration.

[0025] Control parameters are based on the regular timetable and thus describe the scheduled train movements on the rail network (for example, departure and arrival times of vehicles at timing points). Deviation parameters describe deviations from the control parameters (for example, delays or train cancellations). Test parameters describe train operations under specific test conditions, preferably more challenging ones. They serve to modify the control parameters in such a way that determining changed parameters of a train profile for a modified timetable is likely to be at least more difficult. In other words, there is less leeway to create the modified timetable while simultaneously meeting safety requirements.It is even possible to specify test parameters that make determining the aforementioned parameters so difficult that creating a driving profile that meets these parameters becomes impossible (more on this below). The ATO can be configured so that the ATO-OB only sends a message with a forecast to the ATO-TS if the required times are not met. That is, if the train does not send anything, the TMS assumes that the times are achievable. By specifying the aforementioned "impossible" test parameters, such a message is thus forced.

[0026] The teaching according to the invention consists in the innovative use of computing resources for carrying out the method. While the trackside computing environment can implement the TMS by performing the functionality of comparing the standard timetable with the actual timetable and, based on this, generating an updated timetable taking into account all vehicles in the transport network, the vehicle-side computing environment can consider current measured values ​​that must be determined in the vehicle anyway due to the requirements of its functionality. 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.

[0027] In cases where the regular 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. To avoid having to rely on empirical data at this point, the invention uses the ATO onboard system with a simulated (i.e., manipulated / adjusted target timetable for the purpose of determining the minimum possible travel time) target timetable to quickly calculate an accurate forecast in the form of a driving profile (also called journey profile, see below), without major impact on operations.

[0028] 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 roughly 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 target schedule.According to the invention, the ATO-OB is prompted by the ATO-TS to calculate a driving profile under "demanding" test conditions. "Demanding" conditions are defined as those specified by the parameters used for calculating the driving profile. These parameters are assumed to have values ​​that complicate the ATO OB's calculation of the driving profile and, in particular, are expected to make it impossible while adhering to the actual timetable (meaning that a driving profile that fulfills the specifications as closely as possible is calculated). Therefore, these are not parameters that are currently in effect, but rather parameters that simulate these "demanding" conditions.In this process, the TMS can draw on empirical data stored in a memory unit of a suitable computing environment, or reduce the travel times that are usually applicable to the relevant section of the route (calculated as actual timetable or according to the regular timetable) to generate the test parameters, for example by halving them.

[0029] Successful calculation of a driving profile under the aforementioned "demanding conditions" is considered confirmation that the solver and the ATO-TS can definitely implement parameter sets that represent a less critical scenario overall (given more challenging, but not impossible, specifications). If a driving profile that meets the specifications cannot be successfully calculated (given impossible specifications), the ATO-OB will, however, calculate a driving profile that achieves at least one timing point with the shortest possible travel time under the given conditions. This is considered the upper limit of what is feasible under the current conditions. The timing points are adjusted accordingly by the ATO-OB and reported back to the trackside computing environment, in particular the TMS, in the message relating to the driving profile.Therefore, when calculating the updated timetable, it is possible to take into account which limits currently apply to the vehicle in question.

[0030] The driving profile calculated as a test under "demanding" conditions is not used by the ATO-OB according to the invention for an extended period, because it was only calculated to confirm the vehicle's available reserves. It is replaced by the solver applying a realistic scenario to the current timetable and sending a target timetable calculated from this scenario to the ATO-OB. This immediately calculates a new driving profile that meets the actual requirements for the updated timetable.

[0031] The advantage of incorporating the ATO-OB lies in its ability to consider the currently prevailing real-world conditions for the vehicle in question. This allows for the implementation of less critical scenarios as driving profiles with a very high probability. Subsequently, when timetable changes are necessary, the solver can select parameter sets that resolve the actual timetable conflicts as optimally as possible and can be successfully used by the ATO-OB to calculate the driving profiles actually employed with a very high probability. The required travel time buffers can be kept low or even eliminated entirely due to better utilization of track capacity, thus making the process more efficient.

[0032] The ATO-OB and ATO-TS can be connected via an SS126 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 at that location. 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.

[0033] While the SS126 interface allows the ATO-OB to calculate a forecast and transmit it to the ATO-TS, the TMS's use of the ATO-OB for precise travel time calculations before creating a new 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. In other words, there is no known way to simulate timetable situations during operation to determine the fastest, actually achievable driving profiles.

[0034] According to a further aspect of the invention, a trackside computing environment of a track-guided traffic network, comprising at least one computer, is described. According to this aspect, the invention provides that the trackside computing environment is configured to execute a method as described above, i.e., to at least participate in it.

[0035] According to a further aspect of the invention, a track-guided vehicle with a vehicle-mounted computing environment comprising at least one computer is described. According to this aspect, the invention provides that the vehicle-mounted computing environment is configured to execute a method as described above, i.e., to at least participate in it. The advantages associated with these aspects of the invention have already been explained above, and reference is made to these advantages.

[0036] 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.

[0037] 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 multiple computing instances of the two computing environments. 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.

[0038] 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.

[0039] 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.

[0040] 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

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

[0042] According to one variant, the aspects of the invention explained above are determined by the fact that a first test parameter consists of a driving time that the vehicle may require to cover a predetermined distance as a second test parameter or until reaching a timing point as a third test parameter, control parameter or deviation parameter.

[0043] One advantage of this approach is that by specifying a fictitious travel time for a particular route or a fictitious time for reaching a timing point in the simulation, the vehicle's response can be tested. This allows verification of whether the test-generated target timetable is too demanding for the actual conditions existing in the vehicle. In this case, creating a driving profile that fulfills the target timetable is not possible. This method allows verification of whether the time reserves for creating the initially simulated target timetable are sufficient. If the simulated target timetable can be implemented, the following applies: If the actual target timetable is subsequently generated, it can likely be converted into a driving profile, provided the requirements are less critical than those of the simulated target timetable.If the simulated target timetable cannot be implemented, the following applies: A less demanding target timetable must be simulated to check whether it is feasible. Specifically, this means that a shorter route or a later time for reaching the timing point is included in the simulated target timetable.

[0044] The TMS transmits a long-duration driving profile (>30 minutes) with very short required travel times as a test before departure or even during the journey. The ATO-OB responds with a forecast for all transmitted timing points. As soon as the forecast is received, the ATO-TS sends new, realistic, scheduled driving profiles. This provides the TMS, and especially its solver, with a very precise travel time calculation for calculating the realistic driving profiles, without assumptions about dynamic parameters. Based on this, the optimal updated timetable can be calculated and sent to the ATO-OB of the vehicles affected by timetable conflicts.

[0045] According to one variant, the aspects of the invention explained above are determined by the fact that a fourth test parameter is derived from an actual timetable with an alternative route.

[0046] One advantage of this approach is that the simulation can also be used to check alternative routes for a specific vehicle. The benefit is that the minimum travel times for an alternative route can also be determined. This increases the solver's degrees of freedom when optimizing the timetable. An alternative route exists when the vehicle in question is rerouted within the transport network, meaning it is assigned a route that differs from the original one. This might be necessary, for example, due to a track closure or if the originally planned route is temporarily blocked due to delays caused by vehicles ahead. If the simulated target timetable can be implemented, the following applies: The alternative route can be selected to get the vehicle to its destination (timing point) in a shorter time.However, this does not fully utilize the available travel time reserves. If the simulated target timetable cannot be implemented, the following applies: ATO-OB calculates a driving profile that contains the shortest possible travel time achievable under the given conditions (also referred to as the minimum technical travel time) and can be taken into account by the TMS in the final calculation of the alternative timetable.

[0047] 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, even though it doesn't solve the real-world problem. If the train is moving, it would, for example, accelerate to its maximum speed (if its maximum speed hasn't 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 subsequently more than compensated for by the optimized "real-world" driving profile. If the train is in conflict with other trains, it must travel as fast as possible anyway.In most cases, he would receive a faster new driving profile, and the handling of the "wrong" timetable would therefore have hardly any impact on energy consumption.

[0048] According to one variant, the aspects of the invention explained above are determined by the fact that i) the second computing instance (RI2) sends the message according to feature c) mentioned above, which concerns the previously applicable target timetable, as soon as it receives the message according to feature g), j) thereafter the third computing instance (RI3) completes an implementation of the driving profile (FP) generated according to feature g) of claim 1 as soon as it has generated a driving profile (FP) taking into account the previously applicable target timetable (FPS) and begins implementing this driving profile, k) thereafter the third computing instance (RI3) completes an implementation of the driving profile (FP) generated according to feature j) mentioned above as soon as it has generated a driving profile (FP) according to feature h) mentioned above and begins implementing this driving profile.

[0049] One advantage of this approach is that it prevents the vehicle from being driven for extended periods using a test-generated "incorrect" driving profile. An "incorrect" driving profile is one created based on a simulated target schedule and therefore used solely for testing purposes. This could, for example, mean that the vehicle has to accelerate sharply to adhere to the simulated target schedule, which is not necessary in reality. To prevent the vehicle from reacting to the "incorrect" driving profile for too long, the system switches back to the "original" driving profile intermittently.

[0050] This variant of the invention can be summarized as follows: During the journey, the third computing instance has a driving profile. When the query routine begins, the third computing instance receives data regarding the test-calculated target timetable and generates a driving profile intended solely for evaluating the technical reserves for achieving shorter travel times (as explained above). To ensure that this "incorrect" driving profile is implemented for the shortest possible time, the second computing instance immediately sends a message containing the still available, previously valid target timetable upon receiving the corresponding message. This allows the third computing instance to immediately convert this back into a realistic, namely the "old," driving profile. The TMS's consideration of the test-generated driving profile requires processing time in the range of seconds, which is bridged by this process.However, as soon as a new, more realistic target timetable is available, it is sent by the ATO-TS to the ATO-OB, and the driving profile is recalculated. This final calculation then implements the updated timetable definitively calculated by the TMS. Should further timetable changes be necessary, the process starts again.

[0051] This allows the vehicle to react appropriately to the realistic timetable by calculating a realistic driving profile. Even if this profile is only implemented with a time delay, there is usually still enough time available to implement the corrected ("correct") driving profile. A time delay of, for example, 5 seconds can be set. This will be sufficient in most cases. Should the calculation of the corrected driving profile take longer on occasion, this does not pose a safety risk. At most, the train might react "incorrectly" to the real situation for a short time in a non-energy-optimized manner, since the simulated driving profile used does not correspond to the optimal operating profile.

[0052] According to one variant, the aspects of the invention explained above are determined by the fact that test parameters specified according to feature e) of claim 1 are used, the implementation of which will probably not be possible when generating the driving profile according to feature g) of claim 1.

[0053] The test parameters define the conditions within which a driving profile is to be simulated in such a way that these conditions are met. For example, a driving time can be specified within which a real-world timing point must be reached. If this driving time is intentionally set in such a way that, considering factors such as the permissible maximum speed on the track or the vehicle's maximum acceleration and permissible maximum speed, reaching the timing point within this driving time is not feasible, then the ATO-OB is forced to calculate a driving profile that results in the smallest possible time loss with respect to the required driving time. This functionality of the ATO-OB is well-known and requires no further explanation here.The effect according to the invention lies in the fact that the feedback from the simulated driving profile allows a direct conclusion to be drawn about the minimum driving time that can be achieved under the given circumstances, which can be determined on the vehicle, for example, by sensors. This is then taken into account by the TMS when calculating the updated timetable by specifying a timing point for the vehicle in question that requires a driving time of at least this minimum driving time.

[0054] According to one variant, the aspects of the invention explained above are determined by the fact that i) A fourth computing instance in the trackside computing environment generates trackside control commands for train operation, taking into account a predefined safety level; j) A fifth computing instance in the vehicle-side computing environment generates vehicle-side control commands for train operation, taking into account the predefined safety level, whereby the implementation of the driving profile by the control commands of the fourth computing instance and / or the fifth computing instance is overridden if the implementation of the driving profile by control commands of the third computing instance would lead to a violation of the predefined safety level or could not be guaranteed by the available traction or braking power. This ensures that the required safety levels are always guaranteed, as ATC control commands always take precedence over those of the ATO. Exemplary embodiments of the drawing

[0055] 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.

[0056] The exemplary embodiments described below are preferred embodiments of the invention. In these exemplary embodiments, the described components 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 regarded as 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 with their interactions between the functional components used. Figure 2 shows an exemplary embodiment of a computing environment for the device 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 3 shows 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. Figure 4An 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

[0057] 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 form trackside infrastructure and are explained in more detail below. The vehicle FZ represents one vehicle-side unit (other vehicles FZ not shown would form other vehicle-side units), and an interlocking system STW and a control center LZ each represent 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.

[0058] A computing environment in which the method according to the invention takes place can be considered jointly by Figure 1 and Figure 2The data can be extracted. The computing instances and functional components used interact with each other via interfaces. A first interface, S1, connects the vehicle (FZ) and the interlocking system (STW) via antennas (AT). A second interface, S2, connects the control center (LZ) and the vehicle (FZ) via antennas (AT). A third interface, S3, connects the vehicle (FZ) and a satellite for positioning using a GNSS (Global Navigation Satellite System, e.g., GPS). 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.

[0059] 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).

[0060] 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 1 or another track element STE, are in Figure 2Each unit is schematically represented as a box, each containing at least one computer. Naturally, the tasks within each unit can also be processed by multiple interacting computers. In the first computer, CP1, a first processor, PR1, is connected to a first memory unit, SE1, via an eleventh interface, S11. Additionally, a sensor, SN (for example, a speedometer), is shown in the vehicle, FZ, which is connected to the first processor, PR1, via a tenth interface, S10. Other sensors, not shown, can be used in the same way. In the second computer, CP2, a second processor, PR2, is connected to a second memory unit, SE2, via a twelfth interface, S12. In the third computer, CP3, a third processor, PR3, is connected to a third memory unit, SE3, via a thirteenth interface, S13.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 that, when connected via the interfaces, contribute to the formation of the computing environments.

[0061] In Figure 3The interaction of individual components of a train control system (TMS) is illustrated, taking into account the applicable timetables and driving profiles (FP). As previously explained, a distinction is made between the trackside computing environment (RUTS) and the vehicle-side computing environment (RUOB). A solver (SOV) is used in the first computing instance (RI1), which performs timetable optimization as a computational program. This solver has access to the standard timetable (FPR), which applies to the transport network in which the vehicle (FZ), whose vehicle-side computing environment is depicted, operates. Furthermore, the solver (SOV) has access to data on the actual timetable (FPI), which describes the actual flow of traffic on the network and may deviate from the standard timetable (FPR) due to delays or other disruptions.

[0062] The solver SOV in a first computational instance RI1 can calculate an updated timetable FPA based on an analysis of the deviations between the regular timetable FPR and the actual timetable FPI. This updated timetable at least addresses conflicts arising from the identified deviations. Simultaneously, it even aims to compensate for the disruptions and bring the updated timetable FPA as close as possible to the regular timetable FPR.

[0063] Furthermore, the SOV solver can calculate a simulated updated timetable SFPA from model timetable data provided in a suitable storage unit, e.g., the first storage unit SE1. The model timetable data is specifically selected to simulate a "challenging" timetable situation. For example, very short available travel times to the next timing point for the vehicle FZ, which are unlikely to be realized, can be selected for correction purposes.

[0064] A second computing instance, RI2, implements the ATO-TS. Here, a driving profile, FP, is implemented on the trackside by interacting with a third computing instance, RI3, in the vehicle FZ, which implements the ATO-OB. In the example according to... Figure 3 The transmission of the target timetable FPS is carried out by the ATO-TS and the generation of the driving profile FP in the ATO-OB. In the exemplary embodiment according to Figure 3The third computing instance RI3 also returns the driving profile FP to the second computing instance RI2.

[0065] 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, RI13. 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.

[0066] 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 (not shown in detail). Reading and writing data to the storage units is illustrated by way of example. Insofar as the interfaces are described below... Figure 1 and 2 These can also be used in Figure 4 marked.

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

[0068] In a second step, step 2, a check is performed to determine whether the actual timetable (FPI) still corresponds to the standard 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 standard 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.

[0069] It is advantageous (not shown) if the TMS analyzes which vehicles are affected by a disruption to the regular timetable. These are critical vehicles. These are initially trains that, for example, are experiencing timetable conflicts due to delays. Furthermore, critical vehicles can be identified for which subsequent conflicts are foreseeable because their regular timetable is affected by the already delayed trains. The following third step (3) is then carried out for the identified critical trains.

[0070] In a third step, an updated timetable (FPA, abbreviated SFPA) is simulated. This takes into account specific parameters, which may be stored in a database and, in particular, contain potentially critical timetable situations. In this way, the train control system (TMS) simulates a timetable overlap, meaning that the vehicle (FZ) can no longer react adequately to a critical timetable situation under the given conditions (in the expectation that the actual timetable situation is less critical).

[0071] In a fourth step, a vehicle-specific target timetable (FPS) is created. This target timetable (FPS) applies to the vehicle in question (FZ) and is transmitted to the vehicle's computer (FZ) via the second interface (S2).

[0072] In a fifth step (5), a driving profile is created in the vehicle (FZ), i.e., the speed profile over the remaining distance traveled or the remaining travel 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. Once the generation of the driving profile (FP) is complete, the process continues in the vehicle (FZ) (more precisely, in the vehicle-side computing environment RUOB) with the eighth step (8). In the trackside computing environment RUTS, the process continues with the seventh step (7).

[0073] In a seventh step, the actual updated timetable FPA (or simply FPA) is created. This can now be generated taking into account the results of the simulated updated timetable SFPA. This means that within the possibilities explored by successfully generating the simulated driving profile FP based on the simulated updated timetable SFPA, the actual updated timetable FPA can be created and, therefore, will very likely be implemented by the vehicle FZ.

[0074] In an eighth step (8), the implementation of the timetable currently applicable to the vehicle FZ (abbreviated: EXE-FP) may already take place. This is because the vehicle's computing environment RUOB cannot distinguish between simulated updated timetables SFPA and the actual updated timetables FPA.

[0075] In a ninth step, 9, a new target timetable FPS for the vehicle FZ is generated in the trackside computing environment RUTS, based on the updated timetable FPA (abbreviated FPA). This target timetable FPS is then transferred to the vehicle-side computing environment RUOB to generate a new driving profile FP. In a tenth step, 10, this driving profile FP (abbreviated FP) is generated. This driving profile FP then replaces the current driving profile FP, which was still based on the simulated timetable.

[0076] In an 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 updated timetable FPA to be adhered to.

[0077] In the twelfth step (12), during the processing of the driving profile FP, the system repeatedly checks whether the driving profile FP has been fully processed (abbreviated: NW-EXE?). If not, the system continues with the implementation of the existing driving profile FP (eleventh step 11). If, however, it has been, the system proceeds to the thirteenth step 13.

[0078] In step 13, a query is made as to whether the process should be stopped in the vehicle-side computing environment RUOB, for example, due to the end of service (STP). If this is not the case, a new driving profile FP is requested in the trackside computing environment RUTS. In other words, step 7 is repeated. After the timetable is updated in step 9, a new target timetable FPS is generated for the vehicle FZ in question.

[0079] 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, however, a recursion to step 2 occurs to ensure that, in the event of further timetable deviations, the process for creating a simulated updated timetable (SFPA) and subsequently a (real) updated timetable is repeated.

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

[0081] ATA Antenna AZ Axle counter BLBalise CP1 First computer CP2 Second computer CP3 Third computer CP4 Fourth computer CTL Controller FP Driving profile FPA Updated timetable FPI Actual timetable FPR Regular timetable FPS Target timetable FZ Vehicle GL Track LZ Control center PR1 First processor PR2 Second processor PR3 Third processor PR4 Fourth processor RI1 First computing instance R12 Second computing instance RI3 Third computing instance RI4 Fourth computing instance RI5 Fifth computing instance RUOB Vehicle-side computing environment RUTS Track-side computing environment S1 First interface S10 Tenth interface S11 Eleventh interface S12 Twelfth interface S13 13th interface S14 14th 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 SOV 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 the trackside computing environment (RUTS) and the vehicle-side computing environment (RUOB) exchange messages, wherein b) a first computing instance (RI1) in the trackside computing environment (RUTS) calculates an updated timetable (FPA) taking into account control parameters of a standard timetable (FPR) and deviation parameters resulting from the actual timetable (FPI) compared to the standard timetable (FPR), c) a second computing instance (RI2) then sends a message to the vehicle-side computing environment (RUOB) concerning a target timetable (FPS) that implements the updated timetable (FPA) and is specific to the vehicle (FZ).d) then a third computing instance (RI3) in the vehicle-side computing environment (RUOB) generates a driving profile (FP) taking into account the planned timetable (FPS) and sends a message concerning the driving profile (FP) to the trackside computing environment (RUTS), , characterized by the fact thatIn the first computing instance (RI1), a query routine is implemented, for the execution of which e) the first computing instance (RI1) calculates a simulated updated timetable (SFPA), for which predefined test parameters are used at least partially instead of the control parameters and deviation parameters, f) then the second computing instance (RI2) sends a message to the vehicle-side computing environment (RUOB) concerning a target timetable (FPS) that implements the simulated updated timetable (SFPA) and is individual to the vehicle (FZ), g) then the third computing instance (RI3) generates a driving profile (FP) in the vehicle-side computing environment (RUOB) taking into account the target timetable (FPS) and sends a message concerning the driving profile (FP) to the trackside computing environment (RUTS), h) then the procedure steps b), c) and d) are carried out taking additional account of the message concerning the driving profile (FP).

2. Method according to claim 1, characterized by the fact that A first test parameter consists of a driving time that the vehicle (FZ) may require to cover a predetermined distance as a second test parameter, or until reaching a timing point as a third test parameter, control parameter, or deviation parameter.

3. Method according to claim 1 or 2, characterized by the fact that a fourth test parameter from an actual timetable with alternative route guidance.

4. Method according to any one of the preceding claims, characterized by the fact thati) the second computing instance (RI2) sends the message according to feature c) of claim 1, which relates to the previously applicable target timetable, as soon as it receives the message according to feature g) of claim 1, j) thereafter the third computing instance (RI3) completes an implementation of the driving profile (FP) generated according to feature g) of claim 1 as soon as it has generated a driving profile (FP) taking into account the previously applicable target timetable (FPS) and begins implementing this driving profile, k) thereafter the third computing instance (RI3) completes an implementation of the driving profile (FP) generated according to feature j) as soon as it has generated a driving profile (FP) according to feature h) of claim 1 and begins implementing this driving profile.

5. Method according to any one of the preceding claims, characterized by the fact thattest parameters specified according to feature e) of claim 1 are used, the implementation of which is not expected to be possible when generating the driving profile according to feature g) of claim 1.

6. Method according to any one of the preceding claims, characterized by the fact thati) a fourth computing instance (RI4) in the trackside computing environment (RUTS) generates trackside control commands for train operation, taking into account a specified safety level; j) a fifth computing instance (RI5) in the vehicle-side computing environment (RUOB) generates vehicle-side control commands for train operation, taking into account the specified safety level, whereby the implementation of the driving profile (FP) by the control commands of the fourth computing instance (RI4) and / or the fifth computing instance (RI5) is overridden if the implementation of the driving profile (FP) by control commands of the third computing instance (RI3) would lead to a violation of the specified safety level or could not be guaranteed by the available traction or braking power.

7. Trackside computing environment of a track-guided transport network, comprising at least one computer, characterized by the fact thatthe route-side computing environment (RUTS) is set up to execute a method according to one of claims 1 to 7.

8. Track-guided vehicle with a vehicle-mounted computing environment (RUOB), comprising at least one computer, characterized by the fact that the vehicle-side computing environment (RUOB) is set up 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