EP4644210A1 - Verfahren zum betreiben eines zugleitsystems mit aktualisiertem fahrplan - Google Patents

Verfahren zum betreiben eines zugleitsystems mit aktualisiertem fahrplan

Info

Publication number
EP4644210A1
EP4644210A1 EP24172886.4A EP24172886A EP4644210A1 EP 4644210 A1 EP4644210 A1 EP 4644210A1 EP 24172886 A EP24172886 A EP 24172886A EP 4644210 A1 EP4644210 A1 EP 4644210A1
Authority
EP
European Patent Office
Prior art keywords
timetable
vehicle
computing environment
driving profile
computing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24172886.4A
Other languages
English (en)
French (fr)
Inventor
Stefan Wegele
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens Mobility GmbH
Original Assignee
Siemens Mobility GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Mobility GmbH filed Critical Siemens Mobility GmbH
Priority to EP24172886.4A priority Critical patent/EP4644210A1/de
Publication of EP4644210A1 publication Critical patent/EP4644210A1/de
Pending legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B61—RAILWAYS
    • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
    • B61L27/00—Central railway traffic control systems; Trackside control; Communication systems specially adapted therefor
    • B61L27/60—Testing or simulation
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B61—RAILWAYS
    • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
    • B61L27/00—Central railway traffic control systems; Trackside control; Communication systems specially adapted therefor
    • B61L27/10—Operations, e.g. scheduling or time tables
    • B61L27/12—Preparing schedules
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B61—RAILWAYS
    • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
    • B61L27/00—Central railway traffic control systems; Trackside control; Communication systems specially adapted therefor
    • B61L27/10—Operations, e.g. scheduling or time tables
    • B61L27/14—Following schedules
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B61—RAILWAYS
    • B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
    • B61L15/00—Indicators provided on the vehicle or train for signalling purposes
    • B61L15/0058—On-board optimisation of vehicle or vehicle train operation

Definitions

  • 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.
  • 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.
  • a computational instance also known as a solver.
  • 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.
  • ATO Automated Train Operation
  • ATC Automatic Train Control
  • the ATC implements automatic functions in train operation that are safety-relevant. For example, the emergency braking of the vehicle when a safety risk is detected.
  • the ATO serves to optimize train operation with regard to travel times and the vehicle's energy consumption. These functions are not safety-relevant, as the modification of travel times and energy consumption does not trigger any safety risks.
  • Both the ATO and the ATC require cooperation between on-board (hereinafter also referred to as OB) computing instances, consisting of hardware and software components, and trackside (hereinafter also referred to as TS) computing instances, consisting of hardware and software components.
  • OB on-board
  • TS trackside
  • 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.
  • 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
  • the ATO-OB 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.
  • the solver 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).
  • ATO-OB Automatic Train Operator - Operational Control
  • 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.
  • TMS should be able to create updated timetables that are as realistic as possible in the shortest possible computing time.
  • the object of the invention is to solve the problems described in the prior art.
  • 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.
  • 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.
  • the trains may accelerate as they attempt to implement the fastest driving profiles.
  • 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).
  • 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.
  • 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.
  • a computing environment is an IT infrastructure consisting of functional components such as processors, memory units, and programs. and from data to be processed by the programs, which are used to execute at least one application that has a task to perform. Further functional components can consist of sensors and actuators that enable interaction between the computing environment and the outside world.
  • the IT infrastructure can also be organized as a network of the aforementioned functional components.
  • computing instances form functional units that can be assigned to applications (defined, for example, by a number of program modules) and can execute them.
  • these functional units form self-contained systems, either physically (e.g., computer, processor) and/or virtually (e.g., program module).
  • Computers are electronic devices consisting of several functional components and possessing data processing capabilities.
  • 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.
  • 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.
  • CPU central processing unit
  • microprocessor a microcontroller
  • 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.
  • 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).
  • RAM random-access memory
  • data storage devices hard disk or data carrier
  • 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 integrated into a single computer program. or be implemented 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.
  • 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.
  • Control parameters are based on the regular timetable and thus describe the scheduled train movements on the 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 the 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 considering safety requirements. Test parameters can even be specified that make determining the aforementioned parameters so difficult that creating a train 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. This means that if the train sends no message, the TMS assumes that the times are feasible. By specifying the aforementioned "impossible" test parameters, such a message is thus forced.
  • 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 providing the functionality of comparing the standard timetable and the actual timetable and, based on this, creating an updated timetable taking into account all vehicles in the transport network, the vehicle-side computing environment can consider current measured values that are generated in the vehicle due to the Requirements for its functionality must be determined anyway. 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.
  • the minimum possible travel time of a vehicle to a timing point of interest is required.
  • the ATO onboard system is used, according to the invention, by means of a simulated (i.e., manipulated/adjusted target timetable for the purpose of determining the minimum possible travel time) 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.
  • 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.
  • 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.
  • the ATO-OB is prompted by the ATO-TS to calculate a driving profile under test-oriented, "demanding" conditions.
  • “Demanding” conditions are understood to mean conditions that are predetermined by the parameters used for calculating the driving profile, whereby the parameters are assumed to have values that make it difficult for the ATO OB to calculate the driving profile and, in particular, are expected to make it impossible to comply with the actual timetable. This means calculating a driving profile that fulfills the requirements as closely as possible. Therefore, these are not parameters that are currently in effect, but rather parameters that simulate these "demanding" conditions.
  • the TMS can use empirical data stored in a memory unit of a suitable computing environment, or it can reduce the typical travel times for the relevant section of track (calculated either as an actual timetable or according to the standard timetable) to generate the test parameters, for example, by halving them.
  • 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.
  • 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.
  • 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.
  • the TMS uses the ATO-OB for precise travel time calculations before creating a new target timetable for the vehicle.
  • 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.
  • a trackside computing environment of a track-guided traffic network comprising at least one computer
  • 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.
  • a track-guided vehicle with a vehicle-mounted computing environment comprising at least one computer
  • 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.
  • a computer program product 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.
  • the invention provides that the method is carried out as described above.
  • a computer program product containing program modules with program instructions, 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.
  • a computer-readable storage medium containing data which is described as Data records are stored on the storage medium.
  • the invention provides that the data records make the computer program product described above, according to the last preceding claim, executable.
  • the provisioning device is, for example, a storage unit that stores the computer program and makes it available for retrieval.
  • 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.
  • 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.
  • a first test parameter consists of a driving time that the vehicle takes to cover a predetermined distance as a second test parameter or until a timing point is reached.
  • third test parameter or control parameter or deviation parameter may be required.
  • 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 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 if 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 can be implemented. Specifically, this means that a shorter route or a later time for reaching the timing point is planned in the simulated target timetable.
  • 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.
  • a fourth test parameter is derived from an actual timetable with an alternative route.
  • 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, i.e., 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 buffers.
  • ATO-OB calculates a driving profile which contains the shortest possible driving time achievable under the given conditions (also referred to as minimum technical driving time) and which can be taken into account in the final calculation of the alternative timetable by the TMS.
  • 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 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 This is subsequently more than compensated for by the optimized "real" driving profile. If the train is in conflict with other trains, it has to travel as fast as possible anyway. This means that in most cases it would receive a faster new driving profile, and the handling of the "incorrect” timetable would therefore have hardly any impact on energy consumption.
  • 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.
  • the third computing instance has a driving profile.
  • the third computing instance receives data regarding the test-calculated target timetable and A test driving profile is generated, which is solely intended to evaluate the technical reserves for achieving shorter travel times (as explained above).
  • the second processing instance immediately sends a message containing the still available, previously valid target timetable upon receiving the relevant message. This is then immediately converted back into a realistic, namely the "old,” driving profile by the third processing instance.
  • the TMS's consideration of the test-generated driving profile requires processing time in the range of seconds, which is bridged in this way.
  • 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.
  • the test parameters define the conditions within which a driving profile is to be simulated in such a way that these conditions are met.
  • 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 known per se and requires no further explanation here.
  • the effect according to the invention lies in the fact that the feedback of the simulated driving profile thus 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, which requires a travel time not below this minimum travel time.
  • FIG. 1 This 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.
  • a computing environment in which the method according to the invention takes place can be considered jointly by Figure 1 and Figure 2
  • the 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 The vehicle (FZ) and a satellite are connected 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).
  • the control center (LZ), the interlocking system (STW), and the vehicle (FZ) are networked via air interfaces, and the vehicle (FZ) can locate itself using satellite support.
  • 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).
  • FIG. 2 The 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 2 Each 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.
  • a first processor PR1 is connected to a first memory unit SE1 via an eleventh interface S11.
  • a sensor SN for example, a speedometer
  • a sensor SN is shown as an example in the vehicle FZ, which is connected to the first processor PR1 via a tenth interface S10.
  • a second processor PR2 is connected to a second memory unit SE2 via a twelfth interface S12.
  • a third processor PR3 is connected to a third memory unit SE3 via a thirteenth interface S13.
  • a fourth processor PR4 is connected to a fourth memory unit SE4 via a fourteenth interface S14.
  • FIG 3 The interaction of individual components of a train control system (TMS) is illustrated, taking into account the applicable timetables and driving profiles (FP).
  • RUTS trackside computing environment
  • RUOB vehicle-side computing environment
  • 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.
  • 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.
  • FPI actual timetable
  • 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.
  • 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.
  • a second computing instance, RI2 implements the ATO-TS.
  • 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.
  • 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.
  • the third computing instance RI3 also returns the driving profile FP to the second computing instance RI2.
  • the fourth computing instance, RI4 is the ATC-TS
  • 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.
  • a first step 1 the procedure is started both in the trackside computing environment RUTS and in the vehicleside computing environment RUOB (short: START).
  • FPI actual timetable
  • FPR standard timetable
  • 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.
  • an updated timetable (FPA, abbreviated SFPA) is simulated.
  • FPA updated timetable
  • SFPA train control system
  • a vehicle-specific target timetable (FPS) is created.
  • This target timetable (FPS) applies to the vehicle in question.
  • Vehicle FZ and is transmitted to the vehicle's computer FZ via the second interface S2.
  • a driving profile is created in the vehicle (FZ), i.e., a 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 are not shown.
  • 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).
  • 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.
  • 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.
  • 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).
  • FPA updated timetable FPA
  • This target timetable FPS is then transferred to the vehicle-side computing environment RUOB to generate a new driving profile FP.
  • this driving profile FP (abbreviated: FP) is generated.
  • This driving profile FP now replaces the current driving profile FP, which was still based on the simulated timetable.
  • 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.
  • the system 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 process proceeds to the thirteenth step 13.
  • step 13 a query is performed to determine whether the process should be stopped in the vehicle-side computing environment RUOB, for example, due to the end of service (STP). If not, 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.
  • STP end of service
  • 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.
  • RUTS trackside computing environment
  • step 15 the process is terminated (abbreviated: STOP).

Landscapes

  • Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Train Traffic Observation, Control, And Security (AREA)

Abstract

Folgender Gegenstand ist von der Erfindung umfasst: ein Verfahren zum Betreiben eines Zugleitsystems (TMS). Es ist vorgesehen, dass eine streckenseitige Rechenumgebung (RUTS) und eine fahrzeugseitige Rechenumgebung (RUOB) zum Einsatz kommen, wobei eine erste Recheninstanz (RI1) unter Berücksichtigung von Regelparametern eines Regelfahrplans (FPR) und von sich aus dem realisierten Istfahrplan (FPI) im Vergleich zum Regelfahrplan (FPR) ergebenen Abweichungsparametern einen aktualisierten Fahrplan (FPA) berechnet. Danach sendet eine zweite Recheninstanz (RI2) eine Nachricht, die einen individuellen Sollfahrplan (FPS) betrifft, in die fahrzeugseitige Rechenumgebung (RUOB). Danach erzeugt eine dritte Recheninstanz (RI3) unter Berücksichtigung des Sollfahrplans (FPS) ein Fahrprofil (FP) und sendet eine das Fahrprofil (FP) betreffende Nachricht an die streckenseitge Rechenumgebung (RUTS). Erfindungsgemäß ist vorgesehen, dass in der ersten Recheninstanz (RI1) eine Abfrageroutine implementiert ist, zur deren Durchführen die erste Recheninstanz (RI1) einen simulierten aktualisierten Fahrplan (SFPA) berechnet, danach die zweite Recheninstanz (RI2) eine Nachricht, die für das Fahrzeug (FZ) einen simulierten individuellen Sollfahrplan (FPS) beschreibt, in die fahrzeugseitige Rechenumgebung (RUOB) sendet, und danach die dritte Recheninstanz (RI3) in der fahrzeugseitigen Rechenumgebung (RUOB) unter Berücksichtigung des Sollfahrplans (FPS) ein Fahrprofil (FP) erzeugt und eine das Fahrprofil (FP) betreffende Nachricht an die streckenseitge Rechenumgebung (RUTS) sendet. Danach wird die Nachricht von der ersten Recheninstanz (RI1) für die Berechnung des aktualisierten Fahrplans (FPA) genutzt.

Description

    Technisches Gebiet
  • Von der Erfindung ist ein Verfahren zum Betreiben eines Zugleitsystems umfasst. Ferner ist von der Erfindung eine streckenseitige Rechenumgebung eines spurgeführten Verkehrsnetzes umfasst. Ferner ist von der Erfindung ein spurgeführtes Fahrzeug mit einer fahrzeugseitigen Rechenumgebung umfasst. Ferner ist von der Erfindung ein Computerprogrammprodukt, enthaltend Programmbefehle, umfasst. Ferner ist von der Erfindung ein Computerlesbares Speichermedium, enthaltend Daten, umfasst.
    • Technischer Hintergrund
  • Die Fahrzeitrechnung basiert in an sich bekannter Weise auf der Lösung von Bewegungsgleichungen durch eine Recheninstanz, die auch als Solver bezeichnet wird, wobei die eingesetzten Parameter im realen Zugbetrieb nur unzureichend genau bekannt sind (Zugwiderstände, Masse, Drehmassen, Windgeschwindigkeit, Windrichtung sind veränderliche Größen und abhängig von Betriebsbedingungen wie Wetter, Verschleiß und Beladungszustand). Die Parameter werden daher mit Näherungsformeln berechnet oder es werden Mittelwerte angenommen.
  • Aktuell wird eine Prognose für die Fahrzeit eines Zuges auf einer Strecke von Ort A nach Ort B in einem Zugleitsystem (im Folgenden auch als Train Management System, kurz TMS bezeichnet) durch einen Solver wie folgt berechnet:
    • Es wird das aktuelle Geschwindigkeitsprofil für die maximal mögliche Geschwindigkeit ermittelt von A-B.
    • Es wird ein Widerstandsprofil für die Strecke berechnet (Gradienten, Kurven, Tunnel)
    • Es wird für das Fahrzeug die Kraft-Geschwindigkeits-Kennlinie berücksichtigt.
    • Für die Wagen des Fahrzeugs werden Widerstandsparameter angenommen, wobei diese sich um den Faktor 10 unterscheiden können zwischen Gutläufer und Schlechtläufer
    • Basierend auf den oberen Parametern wird die Bewegungs-Differentialgleichung gelöst entweder als Integral von a(t)=F/m für den Gesamtverlauf oder als F(v) beim Beschleunigen und getrennt für konstante Fahrt und Bremsvorgang. Damit wird eine minimale technische Fahrzeit ermittelt.
    • Es können auch netzweit einheitliche Fahrzeitzuschläge von beispielsweise 2 - 3% dazu gerechnet werden, wobei dies meistens durch die Reduktion der V-max um 2 - 3 % geschieht und daraus folgend Brems- und Beschleunigungsvorgänge vernachlässigt werden.
  • Diese Vorgehensweise hat folgende Nachteile.
    • Die Fahrzeitrechnung (Prognose) innerhalb des TMS dauert relative lange (Rechenzeiten im Minutenbereich), ist komplex und basiert auf vielen Annahmen. Diese Annahmen müssen auf jeden Anwendungsfalls angepasst werden, um eine Ähnlichkeit mit dem realen Verkehr zu haben.
    • Es werden eine Vielzahl von Parametern benötigt (beispielsweise Zug-Kennlinien)
    • Viele Parameter müssen geschätzt bzw. gemittelt werden. Für die Jahresplanung wird zum Beispiel ein "mittel"-guter Zug mit bestimmter Formation von Wagen angenommen.
    • Es werden Annahmen bezüglich Windrichtung und -geschwindigkeit getroffen.
    • Eine Abhängigkeit von Widerstandsparametern von Außentemperatur wird ignoriert.
    • Es werden Annahmen bezüglich Zugbeladung getroffen.
    • Die Fahrzeitrechnung ist relativ komplex, die Software-Applikation damit verhältnismäßig aufwändig.
  • Zur Realisierung von durch TMS vorgegebenen Fahrplänen werden im Zugverkehr in bekannter Weise Verfahren zum automatisierten Zugbetrieb (im Folgenden auch Automated Train Operation oder kurz ATO genannt) eingesetzt und durch Verfahren zur automatischen Zugkontrolle (im Folgenden auch Automatic Train Control oder kurz ATC genannt) abgesichert. Die ATC realisiert hierbei automatische Funktionen im Zugbetrieb, die sicherheitsrelevant sind. Beispielsweise die Zwangsbremsung des Fahrzeugs, wenn ein Sicherheitsrisiko ermittelt wird. Die ATO dient der Optimierung des Zugbetriebs hinsichtlich Fahrzeiten sowie Energieverbrauch des Fahrzeugs. Diese Funktionen sind nicht sicherheitsrelevant, da die Modifikation von Fahrzeiten und Energieverbrauch keine Sicherheitsrisiken auslösen. Sowohl die ATO als auch die ATC bedürfen einer Kooperation von fahrzeugseitigen (im folgenden auch onboard oder kurz OB genannt) Recheninstanzen, bestehend aus Hardwarekomponenten und Softwarekomponenten sowie streckenseitigen (im Folgenden auch trackside oder kurz TS genannt) Recheninstanzen, bestehend aus Hardwarekomponenten und Softwarekomponenten.
  • Die Anforderungen an die Zertifizierung sicherheitsrelevanter Anwendungen beispielsweise in der Bahntechnik sind sehr hoch. Gemäß der internationalen Norm IEC 61508 beziehungsweise spezifisch für den Bahnbereich gemäß der europäischen Norm EN 50129 werden für Sicherheitsfunktionen vier Sicherheits-Integritätslevel oder Englisch Safety Integrity Level (SIL) beziehungsweise Sicherheits-Anforderungsstufen für die geforderte funktionale Sicherheit (Safety) unterschieden. Hierbei stellt der Sicherheits-Integritätslevel 4 die höchste und der Sicherheits-Integritätslevel 1 die niedrigste Stufe der Sicherheits-Integrität dar. Der jeweilige Sicherheits-Integritätslevel beeinflusst das Vertrauensintervall eines Messwertes dahingehend, dass das Vertrauensintervall umso kleiner ist, je höher der Sicherheits-Integritätslevel ist, der seitens der jeweiligen Vorrichtung zu erfüllen ist. Die Dimension der funktionalen Sicherheit der verschiedenen Sicherheits-Integritätslevel lässt sich anschaulich mit der zu erwartenden Häufigkeit eines Ausfalls des sicherheitsrelevanten Systems MTBF (Mean Time Between Failures) beschreiben, wobei dies in Jahren (a) angegeben wird. Diese liegt bei SIL-1 im Bereich von 10 ... 100 a, bei SIL-2 im Bereich von 100 ... 1000 a, bei SIL-3 im Bereich von 1000 ... 10000 a, und bei SIL-4 im Bereich von 10000 ... 100000 a.
  • Das TMS berechnet mittels eines Solvers ausgehend von einem Regelfahrplan, der die interagierenden Fahrzeuge in einem spurgeführten Verkehrsverbund berücksichtigt, einen individuellen Sollfahrplan für ein beispielsweise von einer Störung betroffenes Fahrzeug. Bei der ATO-OB ist vorgesehen, dass diese für einen übertragenen Sollfahrplan eine Prognose berechnet. Dies erfolgt basierend auf genauer Kenntnis des Fahrzeugs und dessen Umgebung (Widerstände, Masse, Drehmassen, Außentemperatur etc.), wobei die genannten Kennwerte im Fahrzeug beispielsweise durch Sensoren erfasst werden können.
  • Da der Solver die aktuellen Kennwerte des Fahrzeugs nicht kennt, sondern lediglich wahrscheinliche Annahmen dieser Kennwerte berücksichtigt, kann es passieren, dass ein durch den Solver berechneter Sollfahrplan durch das Fahrzeug bei Vorliegen unerwartet ungünstiger Bedingungen nicht umgesetzt werden können. Diese Situation kann durch die ATO-OB zurückgemeldet werden, um eine Neuberechnung des betroffenen Sollfahrplans und erforderlichenfalls des aktualisierten Fahrplans vorzunehmen. Dies ist jedoch mit einer weiteren Zeitverzögerung verbunden, welche die Fahrplansituation (beispielsweise entstanden durch Verspätungen) weiter zuspitzt.
  • Die Aufgabe der Erfindung liegt darin, dass mit einem TMS möglichst realitätsnahe aktualisierte Fahrpläne erstellt werden sollen - also ein Verfahren Betreiben eines Zugleitsystems, bei dem eine streckenseitige Rechenumgebung und auf einem Fahrzeug eine fahrzeugseitige Rechenumgebung zum Einsatz kommen, derart weiterzubilden, das die Berechnung eines aktualisierten Fahrplans aus einem Regelfahrplan die real verfügbaren Reserven möglichst weitgehend ausschöpfen kann und dabei möglichst schnell ein realisierbares Ergebnis in Form des aktualisierten Fahrplans liefert.
  • Aus dem erläuterten Stand der Technik ergibt sich das Problem, dass mit einem TMS möglichst realitätsnahe aktualisierte Fahrpläne in möglichst kurzer Rechenzeit erstellt werden sollen
    • Zusammenfassung der Erfindung
  • Die Aufgabe der Erfindung besteht darin, die beschriebenen Probleme im Stand der Technik zu beheben. Insbesondere ist es Aufgabe, dass ein Verfahren zum Betreiben eines Zugleitsystems, bei dem eine streckenseitige Rechenumgebung und auf einem Fahrzeug eine fahrzeugseitige Rechenumgebung zum Einsatz kommen, derart weiterzubilden, das die Berechnung eines aktualisierten Fahrplans aus einem Regelfahrplan die real verfügbaren Fahrzeitreserven möglichst weitgehend ausschöpfen kann und dabei möglichst schnell ein realisierbares Ergebnis in Form des aktualisierten Fahrplans liefert. Weiterhin ist es Aufgabe der Erfindung, ein Fahrzeug, ein Computerprogrammprodukt und ein computerlesbares Speichermedium anzugeben, mit dem das verbesserte Verfahren durchführbar ist.
  • Die Aufgabe wird gelöst durch ein Verfahren zum Betreiben eines Zugleitsystems, bei dem
    1. a) eine streckenseitige Rechenumgebung und auf einem Fahrzeug eine fahrzeugseitige Rechenumgebung zum Einsatz kommen, wobei die streckenseitige Rechenumgebung und die fahrzeugseitige Rechenumgebung Nachrichten austauschen, wobei
    2. b) eine erste Recheninstanz in der streckenseitigen Rechenumgebung unter Berücksichtigung von Regelparametern eines Regelfahrplans und von sich aus dem realisierten Istfahrplan im Vergleich zum Regelfahrplan ergebenen Abweichungsparametern einen aktualisierten Fahrplan berechnet (Dabei ermittelt die erste Recheninstanz besonders kritische Züge, die andere Züge behindern. Diese kritischen Züge sollten ihre tatsächlichen Fahrzeitreserven voll ausnutzen, um die Verspätungsausbreitung zu minimieren. Um die tatsächliche minimale Fahrzeit im betreffenden Bereich zu ermitteln, berechnet die erste Instanz für die kritischen Züge solch schnelle Fahrpläne, dass sie nicht fahrbar sind. Diese Fahrpläne werden an die zweite Recheninstanz geschickt),
    3. c) danach eine zweite Recheninstanz eine Nachricht, die einen den aktualisierten Fahrplan verwirklichenden, für das Fahrzeug individuellen Sollfahrplan betrifft, in die fahrzeugseitige Rechenumgebung sendet,
    4. d) danach eine dritte Recheninstanz in der fahrzeugseitigen Rechenumgebung unter Berücksichtigung des Sollfahrplans ein (vorzugsweise das schnellstmögliche) Fahrprofil erzeugt und eine das Fahrprofil betreffende Nachricht an die streckenseitge Rechenumgebung sendet.
  • Bei der Durchführung des Merkmals d) werden die Züge u. U. beschleunigt, da sie versuchen die schnellsten Fahrprofile umzusetzen. Sobald der schnellste Fahrprofil die zweite Recheninstanz erreicht hat, schickt diese den vorherigen Fahrplan an die dritte zugseitige Recheninstanz. Die erste Recheninstanz nutzt die schnellsten Fahrprofile, um einen konfliktfreien fahrbaren Soll-Fahrplan zu erzeugen. Dieser wird dann zur Umsetzung an die zweite Recheninstanz geschickt (hierzu im Folgenden noch mehr)
  • Die streckenseitge Rechenumgebung und die fahrzeugseitige Rechenumgebung sind getrennt voneinander organisiert, da sich das Fahrzeug in dem spurgeführten Verkehrsnetz bewegen muss. Genau genommen bildet jedes Fahrzeug, welches sich in dem Verkehrsnetz bewegt, eine eigene fahrzeugseitige Rechenumgebung aus. Die streckenseitige Rechenumgebung kann dabei für mehrere Fahrzeuge gleichzeitig eingesetzt werden. Bei der Ausführung des Verfahrens werden sowohl Rechenressourcen der fahrzeugseitigen Rechenumgebung als auch Rechenressourcen der streckenseitigen Rechenumgebung genutzt, wie im folgenden genauer ausgeführt wird. Dabei ist es notwendig, die in den Rechenumgebungen ablaufende Software in Form von geeigneten Programmmodulen auf die fahrzeugtechnikseitige Rechenumgebung und die streckenseitige Rechenumgebung aufzuteilen.
  • Rechnergestützt oder computerimplementiert ist eine Vorrichtung, wenn diese eine Rechenumgebung aufweist, oder ein Verfahren, wenn eine Rechenumgebung mindestens einen Verfahrensschritt des Verfahrens ausführt.
  • Eine Rechenumgebung ist eine IT-Infrastruktur, bestehend aus Funktionskomponenten wie Prozessoren, Speichereinheiten, Programmen und aus mit den Programmen zu verarbeitenden Daten, die zur Ausführung mindestens einer Applikation, die eine Aufgabe zu erfüllen hat, verwendet werden. Weitere Funktionskomponenten können aus Sensoren und Aktuatoren bestehen, welche eine Interaktion der Rechenumgebung mit der Außenwelt ermöglichen. Die IT-Infrastruktur kann auch als Netzwerk der genannten Funktionskomponenten organisiert sein.
  • Recheninstanzen bilden innerhalb einer Rechenumgebung funktionale Einheiten aus, die Applikationen (gegeben beispielsweise durch eine Anzahl von Programmmodulen) zugeordnet werden können und diese ausführen können. Diese funktionalen Einheiten bilden bei der Ausführung der Applikation physikalisch (beispielsweise Computer, Prozessor) und/oder virtuell (beispielsweise Programmmodul) in sich geschlossenes Systeme.
  • Computer sind aus mehreren Funktionskomponenten bestehende elektronische Geräte mit Datenverarbeitungseigenschaften. Computer können beispielsweise Clients, Server, Handheld-Computer, Kommunikationsgeräte und andere elektronische Geräte zur Datenverarbeitung sein, die Prozessoren und Speichereinheiten aufweisen können und über Schnittstellen auch zu einem Netzwerk zusammengeschlossen sein können.
  • Prozessoren können beispielsweise Wandler, Sensoren zur Erzeugung von Messsignalen oder elektronische Schaltungen sein. Bei einem Prozessor kann es sich um einen Hauptprozessor (engl. Central Processing Unit, CPU), einen Mikroprozessor, einen Mikrocontroller, oder einen digitalen Signalprozessor, möglicherweise in Kombination mit einer Speichereinheit zum Speichern von Programmbefehlen und Daten handeln. Auch kann unter einem Prozessor ein virtualisierter Prozessor oder eine Soft-CPU verstanden werden.
  • Speichereinheiten können auf computerlesbaren Speichern in Form von Arbeitsspeichern (engl. Random-Access Memory, RAM) oder Datenspeichern (Festplatte oder Datenträger) ausgeführt sein.
  • Programmmodule sind einzelne Software-Funktionseinheiten, die einen erfindungsgemäßen Programmablauf von Verfahrensschritten ermöglichen. Diese Software-Funktionseinheiten können in einem einzigen Computerprogramm
    oder in mehreren miteinander kommunizierenden Computerprogrammen verwirklicht sein. Die hierbei realisierten Schnittstellen können softwaretechnisch innerhalb eines einzigen Prozessors umgesetzt sein oder hardwaretechnisch, wenn mehrere Prozessoren zum Einsatz kommen.
  • Schnittstellen können hardwaretechnisch, beispielsweise kabelgebunden oder als Funkverbindung, oder softwaretechnisch, beispielsweise als Interaktion zwischen einzelnen Programmmodulen eines oder mehrerer Computerprogramme, realisiert sein und dienen einem Austausch von Daten vorzugsweise in Form von digitalen Datensätzen oder analogen Signalen.
  • Zur Vermeidung von Missverständnissen sei an dieser Stelle angemerkt, dass einzelne Anspruchsmerkmale mit kleinen lateinischen Buchstaben durchnummeriert werden, ohne dass dabei Rücksicht auf die Anspruchsnummerierung genommen wird. Dies bedeutet, dass jeder Buchstabe im gesamten Anspruchssatz nur einmal vorkommt, was eine eindeutige Adressierung der betreffenden Anspruchsmerkmale ohne Nennung der Anspruchsnummer ermöglicht. Deswegen kommt der Reihenfolge der Buchstaben jedoch keine Bedeutung zu.
  • Erfindungsgemäß ist vorgesehen, dass
    in der ersten Recheninstanz eine Abfrageroutine implementiert ist, zu deren Durchführen
    • e) die erste Recheninstanz einen simulierten aktualisierten Fahrplan berechnet, für den anstelle der Regelparameter und Abweichungsparameter zumindest zum Teil vorgegebene Testparameter verwendet werden,
    • f) danach die zweite Recheninstanz eine Nachricht, die einen den simulierten aktualisierten Fahrplan verwirklichenden, für das Fahrzeug individuellen Sollfahrplan beschreibt, in die fahrzeugseitige Rechenumgebung sendet,
    • g) danach die dritte Recheninstanz in der fahrzeugseitigen Rechenumgebung unter Berücksichtigung des Sollfahrplans ein Fahrprofil erzeugt und eine das Fahrprofil betreffende Nachricht an die streckenseitge Rechenumgebung sendet,
    • h) danach die Verfahrensschritte b), c) und d) unter zusätzlicher Berücksichtigung der das Fahrprofil betreffenden Nachricht durchgeführt werden.
  • Regelparameter basieren auf dem Regelfahrplan und beschreiben somit die fahrplanmäßig geplanten Zugbewegungen im Streckennetz (beispielsweise Abfahrtszeiten und Ankunftszeiten von Fahrzeugen an Timing Points). Abweichungsparameter beschreiben die Abweichungen von den Regelparametern (beispielsweise eine Verspätungszeit oder Zugausfälle). Testparameter beschreiben unter bestimmten Testbedingungen für den Zugverkehr, vorzugsweise erschwerten Bedingungen. Sie dienen dazu, die Regelparameter derart abzuändern, dass eine Bestimmung von geänderten Parametern eines Fahrprofils für einen geänderten Fahrplan voraussichtlich zumindest erschwert wird. Anders ausgedrückt bleibt weniger Spielraum, um den geänderten Fahrplan bei gleichzeitiger Berücksichtigung der Sicherheitsanforderungen zu erstellen. Es können sogar Testparameter vorgegeben werden, die die Bestimmung der oben genannten Parameter so weit erschweren, dass die Erstellung eines diese Parameter erfüllenden Fahrprofils unmöglich wird (hierzu im Folgenden noch mehr). Die ATO kann so konfiguriert werden, dass die ATO-OB nur dann eine Nachricht mit einer Prognose an die ATO-TS schickt, wenn die geforderten Zeiten nicht eingehalten werden. D.h. wenn der Zug nichts sendet, geht das TMS davon aus, dass die Zeiten fahrbar sind. Bei der Vorgabe der oben gennannten "unmöglichen" Testparameter wird eine solche Nachricht somit erzwungen.
  • Die erfindungsgemäße Lehre besteht darin, dass Rechenressourcen für die Durchführung des Verfahrens auf innovative Weise genutzt werden. Während die streckenseitige Rechenumgebung das TMS umsetzen kann, indem die Funktionalität eines Abgleiches zwischen dem Regelfahrplan und dem Istfahrplan und darauf aufbauend die Erstellung eines aktualisierten Fahrplans unter Berücksichtigung aller im Verkehrsnetz befindlichen Fahrzeuge ausgefüllt wird, kann die fahrzeugseitige Rechenumgebung aktuelle Messwerte berücksichtigen, die in dem Fahrzeug aufgrund der Anforderungen an dessen Funktionalität ohnehin ermittelt werden müssen. Diese Messwerte erlauben auch Rückschlüsse auf limitierende Faktoren für die Umsetzung des für das betreffende Fahrzeug geltenden Sollfahrplans, der aus dem aktualisierten Fahrplan abgeleitet wird.
  • In den Fällen, wo der Regelfahrplan modifiziert werden muss und vorhandene Fahrzeitreserven ausgenutzt werden sollen, wird die minimal mögliche Fahrzeit eines Fahrzeugs zu einem interessierenden Timing Point benötigt. Um an dieser Stelle nicht auf Erfahrungswerte zurückgreifen zu müssen, wird erfindungsgemäß die ATO-Onboard durch einen simulierten (d. h. zum Zwecke der Ermittlung der minimal möglichen Fahrzeit manipulierten/angepassten Sollfahrplan) dazu genutzt, schnell eine genaue Prognose in Form eines Fahrprofils (auch Journey Profile genannt, siehe unten) zu berechnen, ohne größere Auswirkungen auf den Betrieb.
  • Bei dem Betrieb der ATO wird auf dem Fahrzeug eine energieoptimierte Trajektorie (hierbei kann es sich um ein Geschwindigkeitsprofil handeln, wobei die Geschwindigkeit in Abhängigkeit von der verstreichenden Fahrzeit oder dem zurückzulegenden Fahrweg des Fahrzeugs bestimmt ist, im Folgenden allgemein auch als Fahrprofil bezeichnet) berechnet. Diese benötigt ein möglichst genaues Modell des Fahrzeugs und seines Verhaltens (beispielsweise Widerstands-/Antriebskoeffizienten), die außerhalb des Fahrzeugs nur grob geschätzt werden können. Realitätsnahe Modellparameter werden aber üblicherweise während der Fahrt durch die regelungstechnische Beobachtung onboard ermittelt. Sobald diese zur Verfügung stehen, können diese erfindungsgemäß dann auch zur Berechnung einer vergleichsweise genauen und aktuell für das Fahrzeug geltenden Fahrzeit für den simulierten Sollfahrplan verwendet werden. Dazu wird erfindungsgemäß die ATO-OB durch die ATO-TS veranlasst, ein Fahrprofil unter testweise "anspruchsvollen" Bedingungen zu berechnen. Unter "anspruchsvollen" Bedingungen sind Bedingungen zu verstehen, die durch die für die Berechnung des Fahrprofils verwendeten Parameter vorgegeben sind, wobei für die Parameter Werte angenommen werden, die eine Berechnung des Fahrprofils durch die ATO OB erschweren und insbesondere voraussichtlich unter Einhaltung des Istfahrplans unmöglich machen (was bedeutet, dass ein die Vorgaben möglichst weitgehend erfüllendes Fahrprofil berechnet wird). Es handelt sich somit nicht um Parameter, die im Augenblick tatsächlich gelten, sondern um Parameter, die diese "anspruchsvollen" Bedingungen simulieren. Hierbei kann das TMS auf Erfahrungswerte zurückgreifen, die in einer Speichereinheit einer geeigneten Rechenumgebung abgespeichert sind, oder die für den betreffenden Streckenabschnitt üblicherweise geltenden Fahrzeiten (selbst berechnet als Istfahrplan oder laut Regelfahrplan) zur Erzeugung der Testparameter verringern, beispielsweise halbieren.
  • Eine erfolgreiche Berechnung eines Fahrprofils bei den genannten "anspruchsvollen Bedingungen" gilt als Bestätigung, dass der Solver und die ATO-TS auf jeden Fall Parametersätze umsetzen können, welche insgesamt ein weniger kritisches Szenario abbilden (bei erschwerten, jedoch nicht unmöglichen Vorgaben). Wenn ein die Vorgaben erfüllendes Fahrprofil nicht erfolgreich berechnet werden kann (bei unmöglichen Vorgaben), wird die ATO-OB allerdings ein Fahrprofil berechnen, was zur Erreichung des mindesten einen Timing Points mit der kürzesten, unter den gegebenen Bedingungen möglichen Fahrzeit führt. Dies gilt als Obergrenze des unter den aktuellen Bedingungen Machbaren. Die Timing Points werden durch die ATO-OB entsprechend angepasst und in der das Fahrprofil betreffenden Nachricht an die Streckenseitige Rechenumgebung, insbesondere das TMS, zurückgemeldet. Daher kann bei der Berechnung des aktualisierten Fahrplans berücksichtigt werden, welche Grenzen für das betroffene Fahrzeug aktuell gelten.
  • Das als Test unter den "anspruchsvollen" Bedingungen berechnete Fahrprofil wird allerdings durch die ATO-OB erfindungsgemäß nicht für längere Zeit verwendet, weil es lediglich zur Bestätigung der fahrzeugseitig verfügbaren Reserven berechnet wurde. Es wird abgelöst, indem ein realistisches Szenario für den aktuellen Fahrplan durch den Solver zugrundegelegt und ein daraus berechneter Sollfahrplan an die ATO-OB gesendet wird. Dieser berechnet dadurch sofort einen neues Fahrprofil, welches die tatsächlichen Erfordernisse für den aktualisierten Fahrplan erfüllt.
  • Der Vorteil der Einbeziehung der ATO-OB liegt darin, dass diese die augenblicklich geltenden realen Bedingungen für das betreffende Fahrzeug berücksichtigen kann und somit weniger kritische Szenarien mit sehr hoher Wahrscheinlichkeit als Fahrprofil umgesetzt werden können. Anschließend kann der Solver bei erforderlichen Fahrplanänderungen Parametersätze auswählen, die die real vorliegenden Fahrplankonflikte möglichst optimal lösen und durch die ATO-OB zur Berechnung tatsächlich verwendeter Fahrprofile mit sehr hoher Wahrscheinlichkeit erfolgreich verwendet werden können. Die hierzu erforderlichen Fahrzeitreserven können wegen der besseren Ausnutzung der Streckenkapazitäten gering gewählt werden oder sogar ganz entfallen, wodurch das Verfahren effizienter angewendet werden kann.
  • Die ATO-OB und die ATO-TS können durch eine sog. SS126-Schnittstelle verbunden sein (benannt nach UNISIG Standard für ATO over ETCS Subset 126). Die SS126-Schnittstelle beinhaltet einen Rückkanal, in dem die ATO-OB als Antwort auf den Sollfahrplan eine Vorhersage zu den Timing Points, kurz TP, zurücksendet. Als Timing Points werden Orte in dem Streckenprofil bezeichnet, für die eine bestimmter Zeitpunkt spezifiziert ist, zu dem sich das Fahrzeug an dem betreffenden Ort befindet. Der Zeitpunkt kann eine Ankunftszeit (arrival time) oder eine Abfahrtszeit (departure time) sein, dann handelt es sich um einen sogenannten Stopping Point, oder ein Zeitpunkt der Vorbeifahrt (passing time), dann handelt es sich um einen sogenannten Passing Point. Diese Begrifflichkeiten stehen im Einklang mit dem UNISIG Standard für ATO over ETCS, beispielsweise Subset-125.
  • Die SS126-Schnittstelle sieht zwar vor, dass die ATO-OB eine Prognose berechnen und an die ATO-TS übertragen kann, aber die Nutzung der ATO-OB seitens des TMS als eine genaue Fahrzeitberechnung vor der Erstellung eines neuen Sollfahrplans für das Fahrzeug ist bisher nicht umgesetzt. Aktuell wird diese Information standardkonform nur (nachträglich) als Rückfallebene eingesetzt, falls das TMS einen nicht realisierbaren Sollfahrplan an das Fahrzeug übergibt. Mit anderen Worten ist es nicht bekannt, während des Betriebs Fahrplansituationen zu simulieren, um die schnellsten tatsächlich fahrbaren Fahrprofile zu ermitteln.
  • Beschrieben wird gemäß einem weiteren Aspekt der Erfindung eine streckenseitige Rechenumgebung eines spurgeführten Verkehrsnetzes, aufweisend mindestens einen Computer. Gemäß diesem Aspekt ist erfindungsgemäß vorgesehen, dass die streckenseitige Rechenumgebung eingerichtet ist, ein Verfahren wie vorstehend beschrieben mit auszuführen, daran also zumindest beteiligt zu sein.
  • Beschrieben wird gemäß einem weiteren Aspekt der Erfindung ein spurgeführtes Fahrzeug mit einer fahrzeugseitigen Rechenumgebung, aufweisend mindestens einen Computer. Gemäß diesem Aspekt ist erfindungsgemäß vorgesehen, dass die fahrzeugseitige Rechenumgebung eingerichtet ist, ein Verfahren wie vorstehend beschrieben mit auszuführen, daran also zumindest beteiligt zu sein. Die mit diesen Aspekten der Erfindung verbundenen Vorteile sind vorstehend bereits erläutert worden, wobei auf diese Vorteile verwiesen wird.
  • Beschrieben wird gemäß einem weiteren Aspekt der Erfindung ein Computerprogrammprodukt, enthaltend Programmbefehle, die gemeinsam durch eine streckenseitige Rechenumgebung eines spurgebundenen Verkehrsnetzes und eine fahrzeugseitige Rechenumgebung eines in dem Verkehrsnetz betriebenen spurgeführten Fahrzeugs ausführbar sind. Gemäß diesem Aspekt ist erfindungsgemäß vorgesehen, dass das Verfahren wie vorstehend beschrieben ausgeführt wird.
  • Gemäß der Erfindung wird somit ein Programmmodule enthaltendes Computerprogrammprodukt mit Programmbefehlen beschrieben, wobei die Programmmodule in derselben Recheninstanz oder mehreren Recheninstanzen der beiden Rechenumgebungen laufen können. Mittels des Computerprogrammproduktes, das ein Computerprogramm oder mehrere Computerprogramme umfassen kann, sind jeweils das erfindungsgemäße Verfahren und/oder dessen Ausführungsbeispiele ausführbar und mit der Ausführung werden die vorstehend beschriebenen Vorteile erreicht.
  • Beschrieben wird gemäß einem weiteren Aspekt der Erfindung ein computerlesbares Speichermedium, enthaltend Daten, welche als Datensätze vom Speichermedium gespeichert werden. Gemäß diesem Aspekt ist erfindungsgemäß vorgesehen, dass die Datensätze das vorstehend beschriebene Computerprogrammprodukt nach dem letzten voranstehenden Anspruch ausführbar machen.
  • Darüber hinaus wird somit eine Bereitstellungsvorrichtung zum Speichern und/oder Bereitstellen des Computerprogramms in Form eines computerlesbaren Speichermediums beschrieben. Die Bereitstellungsvorrichtung ist beispielsweise eine Speichereinheit, die das Computerprogramm speichert und zum Abruf bereitstellt. Alternativ oder zusätzlich ist die Bereitstellungsvorrichtung ein Netzwerkdienst, ein Computersystem, ein Serversystem, insbesondere ein verteiltes, beispielsweise cloudbasiertes Computersystem oder virtuelles Rechnersystem, welches das Computerprogramm auf einem computerlesbaren Speichermedium speichert und vorzugsweise in Form eines Datenstroms bereitstellt.
  • Die Bereitstellung erfolgt in Form von Programmmodule beschreibenden Programmdatensätzen als Datei, insbesondere als Downloaddatei, oder als Datenstrom, insbesondere als Downloaddatenstrom, des Computerprogrammproduktes. Das Computerprogrammprodukt wird beispielsweise unter Verwendung der Bereitstellungsvorrichtung in eine Rechenumgebung übertragen, sodass das erfindungsgemäße Verfahren in einer Recheninstanz oder mehreren Recheninstanzen dieser Rechenumgebung zur Ausführung gebracht werden kann.
    • Ausgestaltungen der Erfindung
  • Weiterbildungen der Erfindung beschreibende Varianten werden nachfolgend ohne Beschränkung des grundlegenden Gedankens der Erfindung erläutert.
  • Gemäß einer Variante sind die oben erklärten Aspekte der Erfindung dadurch bestimmt, dass ein erster Testparameter aus einer Fahrzeit besteht, die das Fahrzeug für die Bewältigung einer vorgegebenen Strecke als zweiten Testparameter oder bis zum Erreichen eines Timing Points als dritten Testparameter oder Regelparameter oder Abweichungsparameter benötigen darf.
  • Ein Vorteil dieser Variante besteht darin, dass durch Vorgabe einer fiktiven Fahrzeit für eine bestimmte Strecke bzw. durch Vorgabe eines fiktiven Zeitpunktes zur Erreichung eines Timing Points zur Simulation die Reaktion des Fahrzeugs sozusagen getestet werden kann. So kann geprüft werden, ob der testweise erstellte Sollfahrplan zu anspruchsvoll für die real im betreffenden Fahrzeug existierenden Bedingungen ist. In diesem Fall ist die Erstellung eines den Sollfahrplan erfüllenden Fahrprofils nämlich nicht möglich. So gelingt es, zu überprüfen, ob die Zeitreserven für die Erstellung des zunächst simulierten Sollfahrplans ausreichend sind. Lässt sich der simulierte Sollfahrplan umsetzen, gilt folgendes: Wird anschließend der reale Sollfahrplan erzeugt, lässt sich dieser voraussichtlich in eine Fahrprofil umsetzen, wenn die Vorgaben weniger kritisch sind, als die des simulierten Sollfahrplans. Lässt sich der simulierte Sollfahrplan nicht umsetzen, gilt folgendes: Es muss ein weniger anspruchsvoller Sollfahrplan simuliert werden, um zu prüfen, ob sich dieser Sollfahrplan umsetzen lässt. Konkret bedeutet dies, dass eine kürzere Strecke oder ein späterer Zeitpunkt des Erreichens des Timing Points in dem simulierten Sollfahrplan vorgesehen wird.
  • Das TMS übergibt "probeweise" vor der Abfahrt oder auch während der Fahrt beispielsweise ein lange dauerndes Fahrprofil (>30 Minuten) mit sehr kurzen geforderten Fahrzeiten. Die ATO-OB reagiert mit der Prognose für alle übertragenen Timing Points. Sobald die Prognose empfangen wurde, wird die ATO-TS neue realistische "fahrplanmäßige" Fahrprofile senden. Damit bekommt das TMS, insbesondere dessen Solver, zur Berechnung der realistischen Fahrprofile eine sehr genaue Fahrzeitrechnung ohne Annahmen zu dynamischen Parametern. Auf dieser Grundlage kann der optimale aktualisierte Fahrplan berechnet werden und an die ATO-OB der von Fahplankonflikten betroffenen Fahrzeuge gesendet werden.
  • Gemäß einer Variante sind die oben erklärten Aspekte der Erfindung dadurch bestimmt, dass ein vierter Testparameter aus einem Istfahrplan mit alternativer Streckenführung ist.
  • Ein Vorteil dieser Variante besteht darin, dass mit der Simulation auch eine alternative Streckenführung für ein bestimmtes Fahrzeug überprüft werden kann. Der Vorteil ist, dass auch die minimalen Fahrzeiten für eine alternative Streckenführung bestimmt werden können. Dies erhöht die Freiheitsgrade des Solvers beim Optimieren des Fahrplans. Eine andere Streckenführung liegt vor, wenn das betreffende Fahrzeug in dem Verkehrsnetz umgeleitet wird, d. h. eine von der ursprünglichen Route abweichende Route vorgeschrieben bekommt. Dies kann beispielsweise bei einer Streckensperrung erforderlich werden, oder, wenn die ursprünglich geplante Route aufgrund von Verspätungen von vorausfahrenden Fahrzeugen temporär blockiert ist. Lässt sich der simulierte Sollfahrplan umsetzen, gilt folgendes: Die alternative Streckenführung kann ausgewählt werden, um das betreffende Fahrzeug in kürzerer Zeit an sein Ziel (Timing Point) zu bringen. Allerdings werden hierbei die Fahrzeitreserven nicht vollständig ausgeschöpft. Lässt sich der simulierte Sollfahrplan nicht umsetzen gilt folgendes: Es wird seitens der ATO-OB ein Fahrprofil berechnet, welches die kürzest mögliche unter den gegebenen Bedingungen erfüllbar Fahrzeit enthält (auch als minimale technische Fahrzeit bezeichnet) und bei der endgültigen Berechnung des alternativen Fahrplans durch das TMS berücksichtigt werden kann.
  • Bei Konfliktlösungen gibt es Fälle, in denen minimale technische Fahrzeiten benötigt werden, um bestimmte Szenarien zu berechnen. Die ATO-OB sendet eine Antwort normalerweise innerhalb von 3 - 5 Sekunden. Falls der Zug dabei steht, kann seine Stehzeit für die Fahrzeit-Ermittlung genutzt werden ohne "Nebenwirkungen", dass das in der Testprozedur erzeugte Fahrprofil durch die ATO-OB umgesetzt wird, obwohl es nicht das reale Problem löst. Falls der Zug fährt, würde der Zug die 3 - 5 Sekunden nach dem Erhalt des im Rahmen der Testprozedur erzeugten Fahrprofils zum Beispiel maximal beschleunigen (falls die V-Max noch nicht erreicht ist) und dabei zusätzliche Energie verbrauchen. Dieser Energieverbrauch wird aber anschließend durch das optimierte "echte" Fahrprofil mehr als kompensiert. Wenn der Zug mit anderen Zügen in Konflikt steht, muss er sowieso möglichst schnell fahren. D.h. in den meisten Fällen würde er ein schnelleres neues Fahrprofil bekommen und die Abwicklung des "falschen" Fahrplans hätte damit kaum Auswirkungen auf den Energieverbrauch.
  • Gemäß einer Variante sind die oben erklärten Aspekte der Erfindung dadurch bestimmt, dass
    • i) die zweite Recheninstanz (RI2) die Nachricht nach dem oben genannten Merkmal c), die den vorher geltenden Sollfahrplan betrifft, versendet, sobald diese die Nachricht gemäß Merkmal g) empfängt,
    • j) danach die dritte Recheninstanz (RI3) eine Umsetzung des nach dem oben genannten Merkmal g) von Anspruch 1 erzeugte Fahrprofils (FP) beendet, sobald diese unter Berücksichtigung des vorher geltenden Sollfahrplans (FPS) ein Fahrprofil (FP) erzeugt hat und mit der Umsetzung dieses Fahrprofils beginnt,
    • k) danach die dritte Recheninstanz (RI3) eine Umsetzung dem oben genannten Merkmal j) erzeugte Fahrprofils (FP) beendet, sobald diese gemäß dem oben genannten Merkmal h) ein Fahrprofil (FP) erzeugt hat und mit der Umsetzung dieses Fahrprofils beginnt.
  • Ein Vorteil dieser Variante besteht darin, dass verhindert werden kann, dass das Fahrzeug aufgrund eines testweise erzeugten "falschen" Fahrprofils lange gesteuert wird. Als "falsches" Fahrprofil wird ein Fahrprofil verstanden, welches aufgrund eines simulierten Sollfahrplans erstellt wurde und daher nur zu Testzwecken. Dies könnte beispielsweise bedeuten, dass das Fahrzeug zur Einhaltung des simulierten Sollfahrplans stark beschleunigen muss, was in der Realität gar nicht erforderlich ist. Um zu verhindern, dass das Fahrzeug zu lange auf das "falsche" Fahrprofil reagiert, wird zwischenzeitig mit dem "alten" Fahrprofil gefahren.
  • Diese Variante der Erfindung kann man mit anderen Worten folgendermaßen zusammenfassen. Während der Fahrt verfügt die dritte Recheninstanz über ein Fahrprofil. Wenn die Abfrageroutine beginnt, bekommt die dritte Recheninstanz Daten bezüglich des testweise berechneten Sollfahrplans und erzeugt ein Fahrprofil, welches lediglich zur Evaluierung der technischen Reserven zur Realisierung kürzerer Fahrzeiten dienen soll (oben bereits erklärt). Damit dieses "falsche" Fahrprofil so kurz wie möglich umgesetzt wird, sendet die zweite Recheninstanz nach Empfang der diesbezüglichen Nachricht sofort eine Nachricht mit dem noch verfügbaren, vormals geltenden Sollfahrplan, der dadurch in der dritten Recheninstanz sofort wieder in ein realistisches, nämlich das "alte" Fahrprofil umgesetzt wird. Die Berücksichtigung des testweise erzeugten Fahrprofils durch das TMS beansprucht Rechenzeiten im Sekundenbereich, die dadurch überbrückt werden. Sobald jedoch ein neuer, nun realistischer Sollfahrplan zur Verfügung steht, wird dieser durch die ATO-TS an die ATO-OB gesendet, und das Fahrprofil wird wieder neu berechnet. Diese letzte Berechnung setzt dann den durch das TMS endgültig berechneten aktualisierten Fahrplan um. Sollten weitere Fahrplanänderungen erforderlich sein, startet das Verfahren von neuem.
  • Damit reagiert das Fahrzeug adäquat auf den realistischen Sollfahrplan durch Berechnung eines realistischen Fahrprofils. Selbst, wenn auch dieser erst zeitverzögert zum Einsatz kommt, steht normalerweise immer noch genug Zeit für die Umsetzung des korrigierten ("richtigen") Fahrprofils zur Verfügung. Als Zeitverzögerung kann beispielsweise ein Zeitraum von 5 Sekunden festgelegt werden. Dieser wird für die meisten Fälle ausreichend sein. Sollte die Berechnung des korrigierten Farbprofils einmal länger dauern, stellt dies kein Sicherheitsrisiko dar. Der Zug könnte höchstens in nicht energieoptimierter Weise kurzzeitig "falsch" auf die reale Situation reagieren, da das zum Einsatz kommende simulierte Fahrprofil nicht dem Betriebsoptimum entspricht.
  • Gemäß einer Variante sind die oben erklärten Aspekte der Erfindung dadurch bestimmt, dass gemäß Merkmal e) von Anspruch 1 vorgegebene Testparameter verwendet werden, deren Umsetzung bei der Erzeugung des Fahrprofils gemäß Merkmal g) von Anspruch 1 voraussichtlich nicht möglich sein wird.
  • Die Testparameter geben die Voraussetzungen vor, innerhalb derer ein Fahrprofil derart simuliert werden soll, dass diese Voraussetzungen erfüllt sind. Beispielsweise kann eine Fahrzeit vorgegeben werden, innerhalb derer ein real existierender Timing Point zu erreichen ist. Wird diese Fahrzeit absichtlich so vorgegeben, dass sich mit Blick auf die Gegebenheiten wie zulässige Höchstgeschwindigkeit auf der Strecke oder maximales Beschleunigungsvermögen sowie zulässige Höchstgeschwindigkeit des Fahrzeugs ein Erreichen des Timing Points in dieser Fahrzeit nicht verwirklichen lässt, so ist die ATO-OB gezwungen, ein Fahrprofil zu berechnen, was den kleinstmöglichen Zeitverlust mit Bezug auf die geforderte Fahrzeit bewirkt. Diese Funktionalität der ATO-OB ist an sich bekannt und erfordert an dieser Stelle keine weitere Erläuterung. Der erfindungsgemäße Effekt liegt darin, dass die Rückmeldung des simulierten Fahrprofils somit einen direkten Rückschluss darauf zulässt, welche minimale Fahrzeit sich bei den gegebenen Umständen, die auf dem Fahrzeug beispielsweise durch Sensoren ermittelt werden kann, verwirklichen lässt. Diese wird anschließend durch das TMS bei der Berechnung des aktualisierten ist Fahrplans dadurch berücksichtigen, dass für das betreffende Fahrzeug ein Timing Point vorgegeben wird, der eine Fahrzeit nicht unterhalb dieser minimalen Fahrzeit erfordert.
  • Gemäß einer Variante sind die oben erklärten Aspekte der Erfindung dadurch bestimmt, dass
    • i) eine vierte Recheninstanz in der streckenseitigen Rechenumgebung unter Berücksichtigung eines vorgegebenen Sicherheitslevels streckenseitige Steuerbefehle für den Zugbetrieb erzeugt,
    • j) eine fünfte Recheninstanz in der fahrzeugseitigen Rechenumgebung unter Berücksichtigung des vorgegebenen Sicherheitslevels fahrzeugseitige Steuerbefehle für den Zugbetrieb erzeugt,
    • wobei die Umsetzung des Fahrprofils durch die Steuerbefehle der vierten Recheninstanz und/oder der fünften Recheninstanz außer Kraft gesetzt werden, wenn die Umsetzung des Fahrprofils durch Steuerbefehle der dritten Recheninstanz zu einer Verletzung des vorgegebenen Sicherheitslevels führen würde oder durch die verfügbare Antriebsleistung oder Bremsleistung nicht gewährleistet werden könnte. Hierdurch werden die erforderlichen Sicherheitslevel immer gewährleistet, indem Steuerbefehle der ATC immer Vorrang vor denjenigen der ATO haben.
    Exemplarische Ausführungsbeispiele der Zeichnung
  • Weitere Einzelheiten der Erfindung werden nachfolgend anhand der Zeichnung beschrieben. Gleiche oder sich entsprechende Zeichnungselemente sind in den einzelnen Figuren jeweils mit den gleichen Bezugszeichen versehen und werden nur insoweit mehrfach erläutert, wie sich Unterschiede zwischen den einzelnen Figuren ergeben.
  • Bei den im Folgenden erläuterten Ausführungsbeispielen handelt es sich um bevorzugte Ausführungsformen der Erfindung. Bei den Ausführungsbeispielen stellen die beschriebenen Komponenten der Ausführungsformen jeweils einzelne, unabhängig voneinander zu betrachtende Varianten der Erfindung dar, welche die Erfindung jeweils auch unabhängig voneinander weiterbilden und damit auch einzeln oder in einer anderen als der gezeigten Kombination als Bestandteil der Erfindung anzusehen sind. Des Weiteren sind die beschriebenen Komponenten auch mit den vorstehend beschriebenen Varianten der Erfindung kombinierbar.
    • Figur 1 zeigt ein Ausführungsbeispiel der erfindungsgemäßen Vorrichtungen mit ihren Wirkzusammenhängen zwischen den zum Einsatz kommenden Funktionskomponenten schematisch.
    • Figur 2 zeigt ein Ausführungsbeispiel einer Rechenumgebung für die Vorrichtung gemäß Figur 1 als Blockschaltbild der einzelnen Funktionskomponenten und der zwischen diesen ausgebildeten Schnittstellen, wobei einzelne Recheninstanzen Programmmodule ausführen, die jeweils in einem oder mehreren der beispielhaft dargestellten Computer ablaufen können und wobei die gezeigten Schnittstellen demgemäß softwaretechnisch in einem Computer oder hardwaretechnisch zwischen verschiedenen Computern ausgeführt sein können.
    • Figur 3 zeigt eine schematische Darstellung des Zusammenwirkens von Programmmodulen bzw. Recheninstanzen jeweils in der streckenseitigen Rechenumgebung und der fahrzeugseitigen Rechenumgebung, wobei die Fahrpläne und das Fahrprofil berechnet bzw. modifiziert werden.
    • Figur 4 zeigt ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens als Flussdiagramm, wobei die gezeigten Verfahrensschritte einzeln oder in Gruppen durch Programmmodule verwirklicht sein können und wobei die Recheninstanzen und Schnittstellen gemäß Figur 2 beispielhaft angedeutet sind.
    Detaillierte Beschreibung der Ausführungsbeispiele
  • Die Figur 1 zeigt eine exemplarisch dargestellte Umgebung, in der ein Zugbetrieb gesteuert werden und erfolgen kann. Ein Streckennetz ist exemplarisch durch ein Gleis GL dargestellt, auf dem sich ein Fahrzeug FZ befindet. Am Gleis GL sind im Folgenden noch näher erläuterte Streckenelemente STE vorgesehen, die eine streckenseitige Infrastruktur bilden. Das Fahrzeug FZ bildet exemplarisch jeweils eine fahrzeugseitige Einheit (weitere nicht dargestellte Fahrzeuge FZ würden andere fahrzeugseitige Einheiten bilden) und ein Stellwerk STW und eine Leitzentrale LZ jeweils eine streckenseitige Einheit. Mit Blick auf den Ablauf des Verfahrens, der rechnergestützt abläuft, werden diese Einheiten auch als fahrzeugseitige Rechenumgebung RUOB und Streckenseitige Rechenumgebung RUTS bezeichnet.
  • Eine Rechenumgebung, in der das erfindungsgemäße Verfahren abläuft, kann einer gemeinsamen Betrachtung von Figur 1 und Figur 2 entnommen werden. Die zum Einsatz kommenden Recheninstanzen und Funktionskomponenten interagieren durch Schnittstellen miteinander. Durch eine erste Schnittstelle S1 sind das Fahrzeug FZ und das Stellwerk STW über Antennen AT miteinander verbunden. Durch eine zweite Schnittstelle S2 sind die Leitzentrale LZ und das Fahrzeug FZ über Antennen AT miteinander verbunden. Durch eine dritte Schnittstelle S3 sind das Fahrzeug FZ und ein Satellit zwecks Ortung mittels eines GNSS (d. h. global navigation satellite system, z. B. GPS) miteinander verbunden. Durch eine vierte Schnittstelle S4 sind die Leitzentrale LZ und das Stellwerk STW miteinander verbunden. Mit anderen Worten sind die Leitzentrale LZ, das Stellwerk STW und das Fahrzeug FZ über Luftschnittstellen miteinander vernetzt und das Fahrzeug FZ kann sich mittels Satellitenunterstützung orten.
  • Das Stellwerk STW weist überdies Verbindungen zu diversen Streckenelementen STE auf, um eine Steuerung der streckenseitigen Infrastruktur durchführen zu können. Dies wird exemplarisch durch die folgenden Komponenten angedeutet (reale streckenseitige Infrastrukturen weisen selbstverständlich weitaus mehr Streckenelemente STE und auch zusätzlich andere Streckenelemente STE auf). Durch eine fünfte Schnittstelle S5 sind das Stellwerk STW und ein Achszähler AZ miteinander verbunden. Durch eine sechste Schnittstelle S6 sind das Stellwerk STW und eine Balise BL miteinander verbunden. Durch eine siebente Schnittstelle S7 sind das Stellwerk STW und ein Controller CTL mit einem nicht dargestellten Prozessor eines Lichtsignals SG miteinander verbunden. Durch eine achte Schnittstelle S8 sind das Stellwerk STW und ein Weichenantrieb WA mit einem nicht dargestellten Prozessor für eine Weiche W miteinander verbunden.
  • Gemäß Figur 2 sind die jeweils Recheninstanzen bildenden Computer näher dargestellt. Das Fahrzeug FZ, die Leitzentrale LZ, das Stellwerk STW und ein Streckenelement STE, welches beispielsweise der Achszähler AZ, die Balise BL, der Controller CTL oder der Weichenantrieb WA gemäß Figur 1 oder auch ein anderes Streckenelement STE sein kann, sind in Figur 2 jeweils schematisch als Kasten dargestellt, die jeweils mindestens einen Computer enthalten. Selbstverständlich können die Aufgaben in den einzelnen Einheiten auch jeweils durch mehrere interagierende Computer bearbeitet werden. Bei einem ersten Computer CP1 ist ein erster Prozessor PR1 mit einer ersten Speichereinheit SE1 durch eine elfte Schnittstelle S11 verbunden. Überdies ist exemplarisch ein Sensor SN (zum Beispiel ein Tachometer) in dem Fahrzeug FZ dargestellt, der über eine zehnte Schnittstelle S10 mit dem ersten Prozessor PR1 verbunden ist. In gleicher Weise können weitere nicht dargestellte Sensoren zum Einsatz kommen. Bei einem zweiten Computer CP2 ist ein zweiter Prozessor PR2 mit einer zweiten Speichereinheit SE2 durch eine zwölfte Schnittstelle S12 verbunden. Bei einem dritten Computer CP3 ist ein dritter Prozessor PR3 mit einer dritten Speichereinheit SE3 durch eine 13. Schnittstelle S13 verbunden. Bei einem vierten Computer CP4 ist ein vierter Prozessor PR4 mit einer vierten Speichereinheit SE4 durch eine 14. Schnittstelle S14 verbunden. Ist im Rahmen dieser Erfindungsbeschreibung nur von Computern, Prozessoren, Speichereinheiten oder Schnittstellen die Rede, beziehen sich die Angaben allgemein auf alle der vorstehend im Einzelnen benannten Computer, Prozessoren, Speichereinheiten und weiteren Funktionskomponenten, die verbunden durch die Schnittstellen zur Bildung der Rechenumgebungen beitragen.
  • In Figur 3 ist das Zusammenwirken einzelner Komponenten eines Zugleitsystems TMS unter Berücksichtigung der geltenden Fahrpläne und Fahrprofile FP dargestellt. Unterschieden wird, wie bereits erläutert, zwischen der streckenseitigen Rechenumgebung RUTS und der fahrzeugseitigen Rechenumgebung RUOB. Zum Einsatz kommt in einer ersten Recheninstanz RI1 ein Solver SOV, der als Rechenprogramm eine Optimierung von Fahrplänen durchführt. Dieser hat Zugriff auf den Regelfahrplan FPR, der für das Verkehrsnetz gilt, in dem das Fahrzeug FZ, dessen fahrezeugseitige Rechenumgebung dargestellt ist, im Einsatz ist. Außerdem stehen dem Solver SOV Daten über den Istfahrplan FPI zur Verfügung, der den tatsächlichen Ablauf im Verkehrsnetz beschreibt und beispielsweise aufgrund von Verspätungen oder anderen Störungen von dem Regelfahrplan FPR abweicht.
  • Der Solver SOV in einer ersten Recheninstanz RI1 kann basierend auf eine Analyse der Abweichungen zwischen dem Regelfahrplan FPR und dem Istfahrplan FPI einen aktualisierten Fahrplan FPA berechnen, der zumindest auf Konflikte reagiert, die sich durch die festgestellten Abweichungen ergeben. Gleichzeitig wird sogar angestrebt, die Störungen zu kompensieren und den aktualisierten Fahrplan FPA möglichst weit wieder an den Regelfahrplan FPR anzunähern.
  • Außerdem kann der Solver SOV aus modellhaften Fahrplandaten, die in einer geeigneten, z. B. der ersten Speichereinheit SE1 zur Verfügung gestellt werden, einen simulierten aktualisierten Fahrplan SFPA berechnen, wobei die modellhaften Fahrplandaten gezielt so ausgewählt werden, dass diese eine "anspruchsvolle" Fahrplansituation simulieren. Beispielsweise können zur Korrektur sehr kurze zur Verfügung stehende Fahrzeiten bis zum nächsten Timing Point für das Fahrzeug FZ gewählt werden, welche sich voraussichtlich nicht realisieren lassen.
  • Eine zweite Recheninstanz RI2 setzt die ATO-TS um. Hier wird streckenseitig unter Interagieren mit einer dritten Recheninstanz RI3 im Fahrzeug FZ, die die ATO-OB umsetzt, ein Fahrprofil FP umgesetzt. Im Beispiel gemäß Figur 3 erfolgt die Übermittlung des Sollfahrplans FPS durch die ATO-TS und die Erzeugung des Fahrprofils FP in der ATO-OB. Im Ausführungsbeispiel gemäß Figur 3 gibt die dritte Recheninstanz RI3 das Fahrprofil FP auch an die zweite Recheninstanz RI2 zurück.
  • Als vierte Recheninstanz RI4 kommt die ATC-TS und als fünfte Recheninstanz RI5 die ATC-OB zum Einsatz. Im Zusammenspiel der vierten Recheninstanz RI4 mit der fünften Recheninstanz RI5 erfolgt eine sicherheitsrelevante Steuerung des Fahrzeugs FZ im Streckennetz. Dabei überprüft die fünfte Recheninstanz RI5 auch die Steuervorgaben der dritten Recheninstanz R13. Sobald sich eine Verletzung der Sicherheitsvorgaben ergibt, greift die fünfte Recheninstanz RI5 ein, wobei die Steuerfunktionen der fünften Recheninstanz RI5 vor denjenigen der dritten Recheninstanz RI3 Vorrang haben.
  • Im Folgenden soll das erfindungsgemäße Verfahren beispielhaft, wie im Flussdiagramm gemäß Figur 4 dargestellt, schrittweise erläutert werden. Rechnergestützte Schritte erfolgen in den nicht näher dargestellten Prozessoren. Das Auslesen und Speichern von Daten in die Speichereinheiten ist beispielhaft dargestellt. Soweit hierbei die Schnittstellen gemäß Figur 1 und 2 genutzt werden, sind diese auch in Figur 4 gekennzeichnet.
  • In einem ersten Schritt 1 erfolgt der Start des Verfahrens sowohl in der streckenseitigen Rechenumgebung RUTS als auch in der fahrzeugseitigen Rechenumgebung RUOB (kurz: START).
  • In einem zweiten Schritt 2 erfolgt eine Abfrage, ob der Istfahrplan FPI dem Regelfahrplan FPR noch entspricht (kurz: FPR=FPI?). Dies ist so lange der Fall, wie der Zugverkehr ungestört abläuft. Dies bedeutet, dass keine Verspätungen oder Zugausfälle auftreten. Andernfalls weicht der Istfahrplan FPI vom Sollfahrplan FPS ab. Wenn noch keine Abweichungen festgestellt werden können, wird die genannte Abfrage rekursiv wiederholt. Wird jedoch eine Abweichung festgestellt, geht es mit dem dritten Schritt 3 weiter.
  • Es ist vorteilhaft (nicht dargestellt) wenn durch das TMS eine Analyse erfolgt, welche Fahrzeuge von einer Störung des Regelfahrplans betroffen sind. Dies sind kritische Fahrzeuge. Es handelt sich zunächst Züge, die beispielsweise aufgrund von Verspätungen in Konflikt mit dem Fahrplan geraten. Weiterhin können kritische Fahrzeuge ermittelt werden, für die Folgekonflikte absehbar sind, weil deren Regelfahrplan aufgrund der bereits verspäteten Züge beeinträchtigt wird. Für die ermittelten kritischen Züge wird der folgende dritte Schritt 3 durchgeführt.
  • In einem dritten Schritt 3 erfolgt die Simulation eines aktualisierten Fahrplans FPA (kurz: SFPA). Hierbei werden bestimmte Vorgaben berücksichtigt, die beispielsweise in einer Datenbank abgespeichert sein können und insbesondere potenziell kritische Fahrplansituationen enthalten. Auf diese Weise wird das Zugleitsystem TMS sozusagen eine Überlappung des Fahrplans simuliert, dass nämlich das Fahrzeug FZ unter den gegebenen Bedingungen auf eine kritische Fahrplansituation nicht mehr adäquat reagieren kann (in der Erwartung, dass die reale Fahrplansituation weniger kritisch ist).
  • In einem vierten Schritt 4 erfolgt die fahrzeugindividuelle Erstellung eines Sollfahrplans (kurz: FPS). Dieser Sollfahrplan FPS gilt für das betreffende Fahrzeug FZ und wird über die zweite Schnittstelle S2 an den Computer des Fahrzeugs FZ übertragen.
  • In einem fünften Schritt 5 erfolgt im Fahrzeug FZ die Erstellung eines Fahrprofils, d. h. Geschwindigkeitsverlauf über die noch zurückliegende Wegstrecke oder die noch verbleibende Fahrzeit bis mindestens zum nächsten Timing Point (kurz: FP). Bei der Erstellung des Fahrprofils FP werden in nicht dargestellter Weise sensorische Messwerte, die im Fahrzeug FZ erzeugt wurden, berücksichtigt. Wenn die Erzeugung eines Fahrprofils FP abgeschlossen ist, geht es in dem Fahrzeug FZ (genauer in der fahrzeugseitigen Rechenumgebung RUOB) weiter mit dem achten Schritt 8. In der streckenseitigen Rechenumgebung RUTS geht es weiter mit dem siebenten Schritt 7.
  • In einem siebenten Schritt 7 erfolgt die Erstellung des eigentlichen aktualisierten Fahrplans FPA (kurz: FPA). Dieser kann nun unter Berücksichtigung des Ergebnisses des simulierten aktualisierten Fahrplans SFPA erzeugt werden. Dies bedeutet, dass innerhalb der Möglichkeiten, die durch die erfolgreiche Erzeugung des simulierten Fahrprofils FP auf Grundlage des simulierten aktualisierten Fahrplans SFPA ausgelotet wurden, der eigentliche aktualisierte Fahrplan FPA erzeugt werden kann und damit unter sehr hoher Wahrscheinlichkeit durch das Fahrzeug FZ auch umgesetzt werden können wird.
  • In einem achten Schritt 8 erfolgt eventuell bereits die Umsetzung des für das Fahrzeug FZ gerade geltenden Fahrplans (kurz: EXE-FP). Dies hängt damit zusammen, dass die fahrzeugseitige Rechenumgebung RUOB nicht zwischen simulierten aktualisierten Fahrplänen SFPA und den eigentlichen aktualisierten Fahrplänen FPA unterscheiden kann.
  • In einem neunten Schritt 9 erfolgt in der streckenseitigen Rechenumgebung RUTS die Erzeugung eines neuen Sollfahrplans FPS für das Fahrzeug FZ, basierend auf dem aktualisierten Fahrplan FPA (kurz: FPA). Dieser Sollfahrplan FPS wird nun an die fahrzeugseitige Rechenumgebung RUOB übertragen, um darauf basierend ein neues Fahrprofil FP zu erzeugen. In einem zehnten Schritt 10 erfolgt die Erzeugung dieses Fahrprofils FP (kurz: FP). Dieses Fahrprofil FP ersetzt nun das geltende Fahrprofil FP, welches noch auf dem simulierten Fahrplan beruhte.
  • In einem elften Schritt 11 erfolgt nun die Umsetzung des im letzten Schritt berechneten Fahrprofils FP (kurz: EXE-FP). Hierbei handelt es sich um jenes Fahrprofil FP, mit dem der aktualisierte Fahrplan FPA eingehalten werden kann.
  • In einem zwölften Schritt 12 erfolgt während der Abarbeitung des Fahrprofils FP wiederholt die Abfrage, ob ein das Fahrprofil FP vollständig abgearbeitet wurde (kurz: NW-EXE?). Ist dies nicht der Fall, wird mit der Umsetzung des bestehenden Fahrprofils FP (elfter Schritt 11) fortgefahren. Ist dies jedoch der Fall geht es weiter mit dem 13. Schritt 13.
  • In einem 13. Schritt 13 erfolgt eine Abfrage, ob das Verfahren in der fahrzeugseitigen Rechenumgebung RUOB gestoppt werden soll, beispielsweise wegen Betriebsende (kurz: STP?). Wenn dies nicht der Fall ist, wird in der streckenseitigen Rechenumgebung RUTS ein neues Fahrprofil FP angefragt. Anders gesagt wird der siebente Schritt 7 wiederholt. Es wird nach Aktualisierung des Fahrplans im neunten Schritt 9 ein neuer Sollfahrplan FPS für das betreffende Fahrzeug FZ erzeugt.
  • In einem 14. Schritt 14 erfolgt parallel zum 13. Schritt 13 eine Abfrage, ob das Verfahren in der streckenseitigen Rechenumgebung RUTS gestoppt werden soll (kurz: STP?). Ist dies der Fall, wird das Verfahren gestoppt. Ist dies jedoch nicht der Fall erfolgt eine Rekursion zum zweiten Schritt 2, um sicherzustellen, dass bei erneuten Fahrplanabweichungen das Verfahren zur Erstellung eines simulierten aktualisierten Fahrplans SFPA und anschließend eines (realen) aktualisierten Fahrplans wiederholt wird.
  • In einem 15. Schritt 15 erfolgt ein Beenden des Verfahrens (kurz: STOP).
    • Bezugszeichenliste
    • AT
    Antenne
    AZ
    Achszähler
    BL
    Balise
    CP1
    ersten Computer
    CP2
    zweiten Computer
    CP3
    dritten Computer
    CP4
    vierter Computer
    CTL
    Controller
    FP
    Fahrprofil
    FPA
    aktualisierter Fahrplan
    FPI
    Istfahrplan
    FPR
    Regelfahrplan
    FPS
    Sollfahrplan
    FZ
    Fahrzeug
    GL
    Gleis
    LZ
    Leitzentrale
    PR1
    erster Prozessor
    PR2
    zweiter Prozessor
    PR3
    dritter Prozessor
    PR4
    vierter Prozessor
    RI1
    erste Recheninstanz
    R12
    zweite Recheninstanz
    RI3
    dritte Recheninstanz
    RI4
    vierte Recheninstanz
    RI5
    fünfte Recheninstanz
    RUOB
    fahrzeugseitige Rechenumgebung
    RUTS
    streckenseitige Rechenumgebung
    S1
    erste Schnittstelle
    S10
    zehnte Schnittstelle
    S11
    elfte Schnittstelle
    S12
    zwölfte Schnittstelle
    S13
    13. Schnittstelle
    S14
    14. Schnittstelle
    S2
    zweite Schnittstelle
    S3
    dritte Schnittstelle
    S4
    vierte Schnittstelle
    S5
    fünfte Schnittstelle
    S6
    sechste Schnittstelle
    S7
    siebente Schnittstelle
    S8
    achte Schnittstelle
    SE1
    erste Speichereinheit
    SE2
    zweite Speichereinheit
    SE3
    dritte Speichereinheit
    SE4
    vierte Speichereinheit
    SFPA
    simulierter aktualisierter Fahrplan
    SG
    Lichtsignal
    SN
    Sensor
    SOV
    Solver
    STE
    Streckenelement
    STW
    Stellwerk
    TMS
    Zugleitsystems
    W
    Weiche
    WA
    Weichenantrieb

Claims (10)

  1. Verfahren zum Betreiben eines Zugleitsystems (TMS), bei dem
    a) eine streckenseitige Rechenumgebung (RUTS) und auf einem Fahrzeug (FZ) eine fahrzeugseitige Rechenumgebung (RUOB) zum Einsatz kommen, wobei die streckenseitige Rechenumgebung (RUTS) und die fahrzeugseitige Rechenumgebung (RUOB) Nachrichten austauschen, wobei
    b) eine erste Recheninstanz (RI1) in der streckenseitigen Rechenumgebung (RUTS) unter Berücksichtigung von Regelparametern eines Regelfahrplans (FPR) und von sich aus dem realisierten Istfahrplan (FPI) im Vergleich zum Regelfahrplan (FPR) ergebenen Abweichungsparametern einen aktualisierten Fahrplan (FPA) berechnet,
    c) danach eine zweite Recheninstanz (RI2) eine Nachricht, die einen den aktualisierten Fahrplan (FPA) verwirklichenden, für das Fahrzeug (FZ) individuellen Sollfahrplan (FPS) betrifft, in die fahrzeugseitige Rechenumgebung (RUOB) sendet,
    d) danach eine dritte Recheninstanz (RI3) in der fahrzeugseitigen Rechenumgebung (RUOB) unter Berücksichtigung des Sollfahrplans (FPS) ein Fahrprofil (FP) erzeugt und eine das Fahrprofil (FP) betreffende Nachricht an die streckenseitge Rechenumgebung (RUTS) sendet,
    dadurch gekennzeichnet, dass
    in der ersten Recheninstanz (RI1) eine Abfrageroutine implementiert ist, zu deren Durchführen
    e) die erste Recheninstanz (RI1) einen simulierten aktualisierten Fahrplan (SFPA) berechnet, für den anstelle der Regelparameter und Abweichungsparameter zumindest zum Teil vorgegebene Testparameter verwendet werden,
    f) danach die zweite Recheninstanz (RI2) eine Nachricht, die einen den simulierten aktualisierten Fahrplan (SFPA) verwirklichenden, für das Fahrzeug (FZ) individuellen Sollfahrplan (FPS) betrifft, in die fahrzeugseitige Rechenumgebung (RUOB) sendet,
    g) danach die dritte Recheninstanz (RI3) in der fahrzeugseitigen Rechenumgebung (RUOB) unter Berücksichtigung des Sollfahrplans (FPS) ein Fahrprofil (FP) erzeugt und eine das Fahrprofil (FP) betreffende Nachricht an die streckenseitge Rechenumgebung (RUTS) sendet,
    h) danach die Verfahrensschritte b), c) und d) unter zusätzlicher Berücksichtigung der das Fahrprofil (FP) betreffenden Nachricht durchgeführt werden.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein erster Testparameter aus einer Fahrzeit besteht, die das Fahrzeug (FZ) für die Bewältigung einer vorgegebenen Strecke als zweiten Testparameter oder bis zum Erreichen eines Timing Points als dritten Testparameter oder Regelparameter oder Abweichungsparameter benötigen darf.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass ein vierter Testparameter aus einem Istfahrplan mit alternativer Streckenführung ist.
  4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
    i)
    die zweite Recheninstanz (RI2) die Nachricht nach Merkmal c) von Anspruch 1, die den vorher geltenden Sollfahrplan betrifft, versendet, sobald diese die Nachricht gemäß Merkmal g) von Anspruch 1 empfängt,
    j)
    danach die dritte Recheninstanz (RI3) eine Umsetzung des nach Merkmal g) von Anspruch 1 erzeugte Fahrprofils (FP) beendet, sobald diese unter Berücksichtigung des vorher geltenden Sollfahrplans (FPS) ein Fahrprofil (FP) erzeugt hat und mit der Umsetzung dieses Fahrprofils beginnt,
    k)
    danach die dritte Recheninstanz (RI3) eine Umsetzung des nach Merkmal j) erzeugte Fahrprofils (FP) beendet, sobald diese gemäß Merkmal h) von Anspruch 1 ein Fahrprofil (FP) erzeugt hat und mit der Umsetzung dieses Fahrprofils beginnt.
  5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass gemäß Merkmal e) von Anspruch 1 vorgegebene Testparameter verwendet werden, deren Umsetzung bei der Erzeugung des Fahrprofils gemäß Merkmal g) von Anspruch 1 voraussichtlich nicht möglich sein wird.
  6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
    i)
    eine vierte Recheninstanz (RI4) in der streckenseitigen Rechenumgebung (RUTS) unter Berücksichtigung eines vorgegebenen Sicherheitslevels streckenseitige Steuerbefehle für den Zugbetrieb erzeugt,
    j)
    eine fünfte Recheninstanz (RI5) in der fahrzeugseitigen Rechenumgebung (RUOB) unter Berücksichtigung des vorgegebenen Sicherheitslevels fahrzeugseitige Steuerbefehle für den Zugbetrieb erzeugt,
    wobei
    die Umsetzung des Fahrprofils (FP) durch die Steuerbefehle der vierten Recheninstanz (RI4) und/oder der fünften Recheninstanz (RI5) außer Kraft gesetzt werden, wenn die Umsetzung des Fahrprofils (FP) durch Steuerbefehle der dritten Recheninstanz (RI3) zu einer Verletzung des vorgegebenen Sicherheitslevels führen würde oder durch die verfügbare Antriebsleistung oder Bremsleistung nicht gewährleistet werden könnte.
  7. Streckenseitige Rechenumgebung eines spurgeführten Verkehrsnetzes, aufweisend mindestens einen Computer, dadurch gekennzeichnet, dass die streckenseitige Rechenumgebung (RUTS) eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 7 auszuführen.
  8. Spurgeführtes Fahrzeug mit einer fahrzeugseitigen Rechenumgebung (RUOB), aufweisend mindestens einen Computer, dadurch gekennzeichnet, dass die fahrzeugseitige Rechenumgebung (RUOB) eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 6 auszuführen.
  9. Computerprogrammprodukt, enthaltend Programmbefehle, die gemeinsam durch eine streckenseitige Rechenumgebung (RUTS) eines spurgebundenen Verkehrsnetzes und eine fahrzeugseitige Rechenumgebung (RUOB) eines in dem Verkehrsnetz betriebenen spurgeführten Fahrzeugs (FZ) ausführbar sind, derart, dass das Verfahren nach einem der Ansprüche 1 - 6 ausgeführt wird.
  10. Computerlesbares Speichermedium, enthaltend Daten, welche als Datensätze vom Speichermedium gespeichert werden, derart, dass die Datensätze das Computerprogrammprodukt nach dem letzten voranstehenden Anspruch ausführbar machen.
EP24172886.4A 2024-04-29 2024-04-29 Verfahren zum betreiben eines zugleitsystems mit aktualisiertem fahrplan Pending EP4644210A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP24172886.4A EP4644210A1 (de) 2024-04-29 2024-04-29 Verfahren zum betreiben eines zugleitsystems mit aktualisiertem fahrplan

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP24172886.4A EP4644210A1 (de) 2024-04-29 2024-04-29 Verfahren zum betreiben eines zugleitsystems mit aktualisiertem fahrplan

Publications (1)

Publication Number Publication Date
EP4644210A1 true EP4644210A1 (de) 2025-11-05

Family

ID=90924505

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24172886.4A Pending EP4644210A1 (de) 2024-04-29 2024-04-29 Verfahren zum betreiben eines zugleitsystems mit aktualisiertem fahrplan

Country Status (1)

Country Link
EP (1) EP4644210A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6459964B1 (en) * 1994-09-01 2002-10-01 G.E. Harris Railway Electronics, L.L.C. Train schedule repairer
EP1764280A1 (de) * 1994-09-01 2007-03-21 Harris Corporation Planungsanlage und -verfahren
EP4082868A1 (de) * 2021-04-27 2022-11-02 Siemens Mobility GmbH Verfahren zum optimieren eines schienenverkehrs eines schienenverkehrsnetzes

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6459964B1 (en) * 1994-09-01 2002-10-01 G.E. Harris Railway Electronics, L.L.C. Train schedule repairer
EP1764280A1 (de) * 1994-09-01 2007-03-21 Harris Corporation Planungsanlage und -verfahren
EP4082868A1 (de) * 2021-04-27 2022-11-02 Siemens Mobility GmbH Verfahren zum optimieren eines schienenverkehrs eines schienenverkehrsnetzes

Similar Documents

Publication Publication Date Title
DE3930425C2 (de) Verfahren zum Steuern der Bewegung von Transportfahrzeugen
DE102018212025A1 (de) Verfahren zum Betreiben eines autonomen Fahrzeugs und autonomes Fahrzeug
DE102019108477A1 (de) Automatische navigation unter verwendung von deep reinforcement learning
EP3776515B1 (de) Verfahren und vorrichtung zur abstimmung von fahrmanövern zwischen einem fahrzeug und mindestens einem alius-fahrzeug
DE102018212733A1 (de) Erkennung einer nachlassenden Leistungsfähigkeit eines Sensors
EP3782869B1 (de) Verfahren zur steuerung eines zugs innerhalb eines zugsicherungssystems, zugsicherungssystem
DE102019201264A1 (de) Eine steuervorrichtung und ein verfahren zum verwalten von fahrzeugen
WO2019072524A1 (de) Verfahren zur kartierung eines streckenabschnitts
EP4126633B1 (de) Verfahren zur positionsüberwachung eines abgestellten schienenfahrzeugs und computerprogramm, insbesondere für zugsicherungssystem
EP3795451B1 (de) Verfahren zum orten eines fahrzeugs an einer für einen halt des fahrzeugs vorgesehenen station
DE102015115291A1 (de) Energiemanagementsystem und Verfahren für Fahrzeugsysteme
WO2020151844A1 (de) Verfahren zum fahrerlosen umsetzen eines fahrzeugs über eine strecke innerhalb eines abgeschlossenen geländes
DE102008036660A1 (de) Verfahren zum Steuern und/oder Regeln eines Betriebs eines automatisierten Speditions-, Betriebs- und/oder Logistikhofs für wenigstens ein autonom fahrbares Fahrzeug
EP3634828B1 (de) Steuerverfahren zum betreiben eines schienenfahrzeugs
DE112020000166T5 (de) Fahrzeugsteuervorrichtung und Fahrzeugsteuersystem
WO2023052333A1 (de) Verfahren zur ansteuerung einer vielzahl von türen in einem fahrzeug
EP4644210A1 (de) Verfahren zum betreiben eines zugleitsystems mit aktualisiertem fahrplan
EP4331943A1 (de) Verkehrsnetz und verfahren zum betreiben von schienenfahrzeugen in einem verkehrsnetz, bestehend aus einer kombination von streckenabschnitten mit und ohne zugsicherung
EP3768568B1 (de) Schienenfahrzeug mit steuereinrichtung
EP4082868A1 (de) Verfahren zum optimieren eines schienenverkehrs eines schienenverkehrsnetzes
DE102014002297B4 (de) Verfahren zum vorbildgerechten Betreiben von Modellfahrzeugen einer Modellbahnanlage
EP4717553A1 (de) Verfahren zum betreiben eines zugleitsystems
DE102020203635A1 (de) Verfahren zum Betreiben eines Schienenfahrzeuges
DE102019209050A1 (de) Verfahren zum zumindest teilautomatisierten Führen eines Kraftfahrzeugs
WO2021089242A1 (de) Verfahren und vorrichtung zum bestimmen von notfalltrajektorien und zum betreiben von automatisierten fahrzeugen

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

17P Request for examination filed

Effective date: 20251020