Train Control Timetable Updates Through Vehicle-Side Driving Profiles
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing train control systems face challenges in calculating realistic and efficient updated timetables due to insufficient precision in parameter estimation, leading to time-consuming and resource-intensive calculations, and potential delays in implementing target timetables under varying real-world conditions.
Innovation Solution
A method utilizing a trackside and vehicle-side computing environment to exchange messages, where the trackside environment calculates an updated timetable considering actual deviations and critical trains, and the vehicle-side generates a driving profile to optimize travel times, ensuring feasibility and efficiency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If traditional solver-based travel time calculation is used, then comprehensive parameters can be considered, but calculation time becomes too long (minutes) and system resources are excessively consumed
Solution Approach 1:
The patent segments the timetable calculation process into two distinct parts: a fast pre-calculation phase that computes baseline travel times using simplified assumptions, and a subsequent optimization phase that refines these results using actual measured parameters. This segmentation allows the system to avoid performing complex calculations from scratch, thereby reducing overall computation time while maintaining accuracy.
Solution Approach 2:
The patent performs preliminary calculations of travel times using standard assumptions and average parameters before actual train operations begin. These pre-computed values serve as initial estimates that are later adjusted based on real-world measurements. This preliminary action eliminates the need to perform full complex calculations in real-time, significantly reducing computational burden during operation.
2Reliability
If uniform travel time allowances are added to compensate for parameter uncertainties, then safety margin is improved, but maximum speed must be reduced by 2-3% which decreases productivity
Solution Approach 1:
The patent implements a feedback mechanism where actual train operation data (acceleration, braking, resistance parameters) is continuously measured and fed back into the calculation system. This feedback allows the system to dynamically adjust travel time predictions and speed profiles based on real-world performance, eliminating the need for conservative uniform allowances while maintaining timetable reliability through data-driven adjustments.
Solution Approach 2:
The patent changes the approach from using fixed uniform time allowances to using dynamically adjusted parameters based on actual measurements. By continuously updating resistance parameters, mass values, and performance characteristics based on real train data, the system can optimize speed profiles without applying blanket speed reductions, thereby maintaining productivity while ensuring reliability.
3Device complexity
If many parameters are estimated or averaged for annual planning, then calculation complexity is reduced, but the results do not closely resemble real-world traffic conditions
Solution Approach 1:
The patent transitions from static averaged parameters to dynamic measured parameters. Instead of using fixed annual planning averages, the system continuously updates parameter values based on real-time sensor data from actual train operations. This dynamic approach maintains calculation simplicity while dramatically improving accuracy by reflecting actual traffic conditions rather than theoretical averages.
Solution Approach 2:
The system uses the train's own operational data to self-calibrate and improve its predictions. By measuring actual performance parameters during operation and using this data to refine future calculations, the system eliminates the need for external complex modeling while achieving high accuracy through self-generated real-world data.
4Measurement precision
If target timetable is recalculated after delays occur, then updated schedule accuracy is improved, but further time delays are caused by the recalculation process
Solution Approach 1:
The patent performs preliminary calculations of critical path trains and potential delay propagation scenarios before disruptions occur. When delays happen, the system can immediately apply pre-computed adjustment strategies to critical trains rather than performing full recalculation, thereby maintaining accuracy while minimizing additional time loss.
Solution Approach 2:
The patent applies different levels of calculation detail to different trains based on their criticality. Instead of uniformly recalculating all timetables, the system focuses computational resources only on critical path trains that actually affect overall schedule performance. This localized approach maintains accuracy for what matters while avoiding unnecessary calculations that would cause further delays.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The invention encompasses the following: a method for operating a train control system (TMS). It provides for the use of a trackside computing environment (RUTS) and a vehicle-side computing environment (RUOB), wherein a first computing instance (RI1) calculates an updated timetable (FPA) taking into account control parameters of a standard timetable (FPR) and deviation parameters derived from the actual timetable (FPI) compared to the standard timetable (FPR). Subsequently, a second computing instance (RI2) sends a message concerning an individual target timetable (FPS) to the vehicle-side computing environment (RUOB). Following this, a third computing instance (RI3) generates a driving profile (FP) taking the target timetable (FPS) into account and sends a message concerning the driving profile (FP) to the trackside computing environment (RUTS).According to the invention, a query routine is implemented in the first computing instance (RI1). To execute this routine, the first computing instance (RI1) calculates a simulated updated timetable (SFPA). The second computing instance (RI2) then sends a message to the vehicle-side computing environment (RUOB) describing a simulated individual target timetable (FPS) for the vehicle (FZ). The third computing instance (RI3) then generates a driving profile (FP) in the vehicle-side computing environment (RUOB), taking the target timetable (FPS) into account, and sends a message concerning the driving profile (FP) to the trackside computing environment (RUTS). The message is then used by the first computing instance (RI1) to calculate the updated timetable (FPA).