Acta Polytechnica CTU Proceedings doi:10.14311/APP.2017.11.0031 Acta Polytechnica CTU Proceedings 11:31–34, 2017 © Czech Technical University in Prague, 2017 available online at http://ojs.cvut.cz/ojs/index.php/app RAILWAY TRAFFIC OPTIMIZATION Dušan Kamenický∗, Tomáš Brandejský, Vít Fábera, Valerii Gopak Faculty of Transportation Sciences, Czech Technical University in Prague, Konviktská 20, 110 00 Praha 1 ∗ corresponding author: kamendus@fd.cvut.cz Abstract. The article focuses on analysis of possibilities of operatic control of railway traffic and its automatization and its support by information systems. Conditions, necessary pieces of input information like infrastructure description are discussed. RailML format is mentioned as suitable format for description in railway area. Optimization criterion and use of evolutionary techniques are suggested. The system is modeled in Railway Laboratory of the Faculty of Transportation Sciences, CTU in Prague. Keywords: railway traffic optimization, RailML, evolutionary techniques, prediction. 1. Railway Traffic Optimization Trends Increasing demands to railway capacity require to build new railway lines and to apply new approaches like information technologies supporting railway traffic to use effectively given infrastructure. Train running is controlled and checked by inter- locking systems (and by operations over the devices) that evaluates the state of the infrastructure (mainly occupancy of track sections is detected using track circuits or axle counters), controls infrastructure ele- ments (switches), transmits instructions how to move through signals or automatic train stopping device. There are several trends of rail operation control. Firstly, the way of control is shifted from distributed system spread over stations to centralized one in all Europe. The most railway lines in the Czech Republic should be controlled from two offices in Přerov and Prague. The centralization of the operation control gives spread view of the situation and more informa- tion to the operator. On the other hand, there is a disadvantage of this approach. Information quantity to evaluate increases if the area is large. It is clear the information capacity of each human operator is limited and different. Moreover, operator is negatively influenced by rotes. Secondly, next modern trend (especially in Switzer- land, Belgium and Germany) is a separation of strat- egy control (route planning from daily to annual inter- val) from operative control (conflicts solution caused by deviations from regular time-table due to infras- tructure or vehicle faults) and from direct control (safety device operation, shunting). Each level of operation control architecture process specific functions and it needs IT support. This ar- ticle is focused especially on operative control and its IT support, strategy control is mentioned only marginally. It is supposed that output of the strategy level support is a scheduled daily time table with valid and conflict-free train routes (really realizable with respect to the route capacity). Operative control IT support should react to deviation from planed daily time table; it monitors actual trains routes and solves potential conflicts with others trains in advance (from minutes to hours). The output is modified conflict- free time table – specific route plan transmitted to direct control level (realized by human operator or automatic system). The direct control level is freed from searching the sequence of runs if the planned time-table is disturbed and processes of the direct control level are focused on safety device operations and guarantee of rail operation safety. 2. IT support of operative control IT support of operative control was missed out in the Czech Republic for a long time. Today systems only shows planned timetable which is modified based on information about actual train position entered by operators in stations. They reflect neither train properties (parameters) nor infrastructure properties. It depends only on abilities and experiences of opera- tors (dispatchers) if they are able to predict potential conflict and to suggest appropriate solution. More- over, todays systems are not able to transfer such modified timetable to the direct level operating on the plant-interlocking devices. To increase capacity of railway traffic and effectivity by optimization of operative control, it means to solve several partial problems that are very difficult: pre- diction of train paths, conflicts detection and optimal solution of these conflicts. The necessary premise to be able to search auto- matically optimal solution is to predict train path. Some problems hamper to solve this problem satis- factory. Above all, it is necessary to dispose enough description of the infrastructure. The description must contain the information related to the construction of time table (position and height of platform edges, line parameters affecting train resistance – slope, curves, tunnels, ...) and related to the interlocking system (track sections and their dependencies ensuring safety 31 http://dx.doi.org/10.14311/APP.2017.11.0031 http://ojs.cvut.cz/ojs/index.php/app D. Kamenický, T. Brandejský, V. Fábera, V. Gopak Acta Polytechnica CTU Proceedings running). The prediction is also affected by actual train parameters and their correctness, especially by type of motive power and its traction characteris- tic, train weight, braking ability of the train (both parameters can change in dependence of weather), eventually coefficients of train resistances. The strat- egy of run is important as well – ratio of times of thrust/coasting/braking. If the trains are manually controlled by engine drivers the strategies can be dramatically different. The application of ATO (Au- tomatic Train Operation) brings the improvement in this area, when strategies became more stable (but the strategies can be different within several ATO systems depending on producers). Very stochastic quantity is time of stop in stations (getting on and off, operations on train). One possibility to eliminate partially randomness is to collect long-term statistics. Dependencies between trains are necessary to take into account – connections, locomotives, coaches and train crew turnround cycles. Completeness and up-to dateness of data stored in IS are necessary. Train routes conflict detection is highly dependent on the interlocking systems. Each infrastructure op- erator has different equipment and it works with dif- ferent set of risks and their consequences. Due to this reason, each operator defines different functional requirements for interlocking systems and procedures to guarantee safety of traffic. Different requirements can affect conditions for compatible routes. Condi- tions depend not only on infrastructure but also on equipment of rolling stocks. It is not sufficient to consider only occupation of track sections but locking of sections which are running – before running and after running during defined interval. Route locking can have time and space aspect. The specific case is such running conflict when one train run through the station or it is coming to the platform and the arrival to the second platform is at the same level (there is no subway or upperbridge). If a conflict is detected it must be solved. While previous phases (train path prediction and conflict detection) can be defined, modeled and computer relatively exactly, the definition of the optimization criterion by conflicts solution is complicated and "soft". One criterion can be "accuracy of planned time timetable", i.e. minimum of total sum of train delays. Afterwards, weights of several trains and stations must be defined (delay of IC train has greater impact). But, weight assignment trenches offering politics of carriers. Energetic criterion can be more objective and better definable. Power consumption is possible to be good computed. The final criterion function can be multicriterial and be of the weight sum form. Requirement to minimize time of closing level-crossing can be included to the criterion function. The set of situation is large that can happen. Mod- ern systems are able to solve only several situations au- tomatically and sophistically. It is always considered a human operator and automatic system cooperation. Own intervention can be realized not only by time shift of train path but also/or by change of train route – only within the station (to the different line) or the new whole path. In the case of new path there are new constraints as knowledge of line by driver, ability to pass new line by the train, operation of stations, ... 3. Implementation in Railway Laboratory Railway Laboratory was founded at the Faculty of Transportation Sciences which serves as a place to simulate train traffic control and interlocking system. The laboratory is equipped by interlocking devices typically used in the Czech Republic – from the oldest (mechanical) ones up to modern (computer based) ones. So, the level of direct control is modeled real- istically. The laboratory is extended by higher lev- els traffic control architecture, namely on operative level. Applications are developed which reflect mod- ern trends of rail traffic control, focusing on train path prediction, conflicts detection and their solution. The topology of model railway in Railway Labora- tory was selected as infrastructure on which applica- tions will be developed and tested. We analyzed current concepts of infrastructure de- scription used in reality. The way used in the Czech Republic prefers time-table point of view. This way is not compatible with the format representing infras- tructure from the interlocking architecture point of view. The RailML.org initiative [1] tries to uniform the infrastructure description and defines RailML stan- dard. The RailML standard is based on XML format which is generally used nowadays to store structured data. It is a text format consisting of elements that can be nested; element is a block bounded by tags enclosed in <>. Typically, configuration files, some database files have XML structure (HTML file are types of XML too). The version RailML 2.3 was released, the specification RailML 3 is in progress – the version 3.0 is released only for internal use in ini- tiative, the version 3.1 is supposed to be released in autumn 2017. The RailML defines several subschemas to describe and store information of various railway subsystems and parts: Timetable and Rostering, In- frastructure, Rollingstock, Interlocking and Common. A fragment of RailML Code 2.3 describing track is shown bellow (the complete example is available at [2]) – Fig. 1. Experiences show that extraction of infrastructure and connections from RailML 2.X is not so clear es- pecially due to separate description of elements and their connections. The RailTopoModel project exists concurrently to the RailML and it is a logical object model to standardize the representation of railway infrastructure-related data and it uses RailML 3.X; the schema RailML 3.X is different from 2.X and much better. Nevertheless, version 3, as mentioned above, is still in progress. Therefore research team decided to utilize existing own XML format describing 32 vol. 11/2017 Railway Traffic Optimization Figure 1. Description of connection using RailML 2.X (source [2]). Figure 2. Optimization system and its inputs. infrastructure which is used for interlocking devices configuration in Railway Laboratory [3]. Optimization of the timetable is understood dy- namic change of timetable (including time shift and route changes) to solve conflicts in our conception, not creation of the new (for example, daily, annual timetable) one. Let’s summarize inputs of the opti- mization system (Fig. 2): infrastructure description, train description, timetable description. Infrastructure of Railway Laboratory is described by own XML format, as mentioned above. The net is composed from several types of elements like: tracks sections, signals, insulated rail joints, switches. The model contains other elements which are omitted in our application due to irrelevancy: power supplies, derailers, track circuits. Elements and their bindings are read from the file and an oriented graph is con- structed in the computer memory. Own library was implemented in C++ programming language due to its speed and effective work with pointers. The base of own XML parser to read infrastructure description is an open-source library. There are many general freeware libraries for XML format analysis. We chose Xerces library which is also written in C++ and it holds DOM (Document Object Model) in its internal structures. It is supposed that RailML will be widely applied in real railway in the future. Similar parser of RailML format can be created and it is not a big problem to program such software module (library) "RailML Parser" containing functions for the analysis of the RailML files – just due to existence of free general XML parsers like Xerces. Train description has our proprietary format. Pa- rameters of specific trains are stored to compute their traction and another physical characteristics (maximal speed) allowing modeling of train move and change it: increment or decrement train speed as one possible solution of collisions. Naturally, the RailML format concept calculates to store rolling-stock description in XML. Timetable is stored in MySQL Server in Railway Laboratory (the future is RailML format as well) and software library to read the timetable was created. The database contains only stations passed through and arrival and departure times. Amount of infor- mation is insufficient. It is not possible to derive uniquely train path (there exist more paths between stations very often) and times of track sections occu- pancy. The identification of collision is not possible without knowledge of this piece of information. The time-table database has to be extended to contain sequence of track sections passing by trains and in- tervals of occupancy. Each track section is labeled during simulation if it is free, occupied or locked. Con- flicts are searched like intersections of time intervals. If conflict is detected time intervals can be changed (shifted, shortcut, stretched) by the change of the train speed with using train characteristics. Conflict solution can be implemented by some heuristic (evo- lutionary technique). If the change of travelling time doesn’t lead to the conflict solution an alternative paths can be used (which can generate unfortunately additional conflicts). Alternative path searching can be implemented by evolutionary technique too. The technique of travelling time change can be applied to alternative paths. The conflict is solved by the path change of one train in the simplest case. If it is not solved the area of changes is spread (to other trains). It is evident the task is very complicated and it must be solved in reality by parallel computation. 4. Conclusion The effective railway traffic optimization and follow- ing control is very difficult task. It is necessary to have enough described infrastructure, time table and rolling stock and store the data in information sys- tems. Prepared RailML format and RailTopoModel appears to be very perspective. To optimize railway traffic dynamically, especially when unexpected events happen, it needs to predict train runs, search conflict and solve them, for example to shift runs in timetable or to plan alternative paths. The optimal solution can be searched by evolutionary techniques where op- timization criterion can be to minimize total sum of train delays or minimize power consumption. Parallel computation is supposed to be applied. References [1] RailML.org. Initiative [online]. [cit. 2017-03-08] "http://www.railml.org". 33 D. Kamenický, T. Brandejský, V. Fábera, V. Gopak Acta Polytechnica CTU Proceedings [2] Railtopomodel [online]. [cit. 2017-03-08] "http://www.railtopomodel.org". [3] P. Koutecký. Electronic signal box for CTU transport lab, diploma thesis. Faculty of Electrical Engineering, 2011. 34 Acta Polytechnica CTU Proceedings 11:31–34, 2017 1 Railway Traffic Optimization Trends 2 IT support of operative control 3 Implementation in Railway Laboratory 4 Conclusion References