Timetable Planning and Information Quality
WITPRESS WIT Press publishes leading books in Science and Technology. Visit our website for the current list of titles. www.witpress.com
WITeLibrary Home of the Transactions of the Wessex Institute, the WIT electronic-library provides the international scientific community with immediate and permanent access to individual papers presented at WIT conferences. Visit the WIT eLibrary at http://library.witpress.com
This page intentionally left blank
Timetable Planning
and Information Quality
Editor: Ingo A. Hansen Delft University of Technology
Editor: Ingo A. Hansen Delft University of Technology
Published by WIT Press Ashurst Lodge, Ashurst, Southampton, SO40 7AA, UK Tel: 44 (0) 238 029 3223; Fax: 44 (0) 238 029 2853 E-Mail:
[email protected] http://www.witpress.com For USA, Canada and Mexico WIT Press 25 Bridge Street, Billerica, MA 01821, USA Tel: 978 667 5841; Fax: 978 667 7582 E-Mail:
[email protected] http://www.witpress.com British Library Cataloguing-in-Publication Data A Catalogue record for this book is available from the British Library ISBN: 978-1-84564-500-7 Library of Congress Catalog Card Number: 2010920856 The texts of the papers in this volume were set individually by the authors or under their supervision. No responsibility is assumed by the Publisher, the Editors and Authors for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions or ideas contained in the material herein. The Publisher does not necessarily endorse the ideas held, or views expressed by the Editors or Authors of the material contained in its publications. © WIT Press 2010 Printed in Great Britain by MPG Book Group. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the Publisher.
Contents Part A. Timetabling RailML – a standard data interface for railroad applications A. Nash, D. Huerlimann, J. Schuette & V.P. Krauss ..................................... 3 Timetable stability - using simulation to ensure quality in a regular interval timetable J. Demitz, C. Hübschen & C. Albrecht ........................................................ 11 Crystal diagram: a technique for making high-density diagrams K. Katsuta, T. Takano, K. Oguma, D. Watanabe & T. Uemura................... 25 State-of-the-art of railway operations research I.A. Hansen .................................................................................................. 35 A Decision Support System for railway timetabling (MOM): the Spanish case F. Barber, P. Tormos, A. Lova, L. Ingolotti, M.A. Salido & M. Abril ........ 49 Method and software tool for an optimized passenger orientated connection management M. Klemenz & A. Radtke ............................................................................ 59 Applying multiscaling analysis to detect capacity resources in railway networks A. Gille, M. Klemenz & Th. Siefer.............................................................. 73
Part B. Operations Analysis Simulation of disturbances and modelling of expected train passenger delays A. Landex & O.A. Nielsen........................................................................... 85
Evaluating stochastic train process time distribution models on the basis of empirical detection data J. Yuan, R.M.P. Goverde & I.A. Hansen ..................................................... 95 Development of a dwell time calculation model for timetable planning S. Buchmueller,U. Weidmann & A. Nash ................................................. 105 Evaluation of punctuality on a heavily utilised railway line with mixed traffic O. Lindveldt ............................................................................................... 115 Automated analysis of train event recorder data to improve micro-simulation models S. de Fabris, G. Longo & G. Medeossi ...................................................... 125
Part C. Rescheduling Optimal train control at a junction in the main line rail network using a new object-oriented signalling system model R. Takagi, P.F. Weston, C.J. Goodman, C. Bouch, J. Armstrong, J. Preston & S. Sone................................................................................... 137 Running time re-optimization during real-time timetable perturbations A. D'Ariano & T. Albrecht......................................................................... 147 An algorithm for train rescheduling using rescheduling pattern description language R C. Hirai, N. Tomii, Y. Tashiro, S. Kondou & A. Fujimori ........................ 157 The contribution of state resources in a constraint-based scheduling model for conflict solving at railway junctions J. Rodriguez ............................................................................................... 169 A Petri nets based decision support tool for railway traffic conflicts forecasting and resolution S. Ricci & A. Tieri ..................................................................................... 179 Comparing the effectiveness of two real-time train rescheduling systems in the case of perturbed traffic conditions S. Wegele, F. Corman & A. D’Ariano ....................................................... 189 A novel train rescheduling algorithm for correcting disrupted train operations in a dense urban environment K. Kumazawa, K. Hara & T. Koseki ......................................................... 199 Author index............................................................................................. 209
Preface This edition provides selected papers presented during the last three Conferences on Computer System Design and Operations in the Railway and other Transit Systems in 2004, 2006 and 2008. The papers, many of which have been updated for this edition, are divided into three parts, that is, Timetabling, Operations Analysis, and Rescheduling. The selection is made in order to emphasise the possibilities for closing the loop between computer-aided offline planning and design of scheduled railway services on one hand and online analysis of operations performance on the other. Feedback communication of deviations from service quality standards in real-time to customers combined with efficient information and decision support systems for railway staff enable a fast adaptation of traffic flows and schedules in case of disturbances and can increase customer satisfaction significantly. Part A starts with a brief description by A. Nash et al. about the standard interface RailML for railroad applications. The current simulation programs of railway timetable and operations suffers from a lack of a suitable format of data input that require specific interface programs for data transfer between different applications. By using the web-based eXtensible Markup Language XML the description of timetable, infrastructure and rolling stock data RailML produces export files that can, in principle, be used by any other application. This means less costs and time would be required for the preparation of input data for different software, while comparative cross-border network studies will become easier. In the second paper J. Demitz et al. estimate timetable quality in a very large and densely occupied railway network of North RhineWestphalia/Germany. Timetable alterations of running and dwell times according to different rolling stock characteristics are simulated simultaneously in order to compute train delays and to compare with observed punctuality during real operations. K. Katsuta et al. present Crystal diagrams as technique for the design of high-density train diagrams, which enables to calculate minimum headway between trains and period of schedules at (terminal) stations as function of track layout, signalling, speed, train length, track occupation and clearance in order to optimise the circulation of trains. The forth paper by I. Hansen gives an overview of the state-of-the-art of analytical and micro-simulation models for improving timetable and operations
quality, capacity estimation and delay propagation. A precise estimation of blocking times based on realistic train running times is considered the key to model well railway traffic and to increase infrastructure capacity, as well as punctuality of train services. F. Barber et al. present in the fifth paper a decision support system for railway planners developed recently in Spain. It offers assistance in train scheduling, while automatically identifying bottlenecks and providing support for conflict resolution: The sixth paper by M. Klemenz & A. Radtke describes a comprehensive model and tool for optimised passenger connection management in a network using graph theory. The costs emerging from additional travel times of all involved passengers and train schedules are minimised by searching the shortest path in a given network timetable. In the last paper of this part A. Gille et al. discuss the benefits of different levels of accuracy of infrastructure models and propose a multi-scaling approach for capacity analysis, which allows switching between micro-, meso- and macroscopic models by means of timetable file conversion. Part B comprises five papers with regard to analysis and simulation of train operations. In the first one A. Landex & O.A. Nielsen present an integrated analysis and simulation model for the estimation of trip times, rerouting of passenger flows and delays in case of disturbance in the suburban railway network of Copenhagen in order to evaluate the impact of infrastructure improvements. J. Yuan et al. evaluate the statistical fit of common probability distribution models for observed stochastic train process times in a major Dutch railway station. The best approximate models found are the log-normal distribution for arrival times and the Weibull distribution for non-negative arrival and departure delays, as well as dwell times of late arrivals of trains whose departure times are not connected to other lines. S. Buchmueller et al. describe detailed models for the estimation of subprocess dwell times of different rolling stock based on automatic passenger counting data of suburban railway trains in Switzerland. O. Lindveldt introduces a simulation model for initial delays, run times and dwell times of different types of trains on the Western main railway line in Sweden, which demonstrates a rather good matching with recorded punctuality. S. de Fabris et al. introduce a new tool for detailed analysis and simulation of real-life train movements depending on synchronised position data via GPS, signal status messages via balises and train dynamics from speedometer that are recorded on-board of Italian trains and transmitted via radio continuously. A case study of the traffic on the main line from Trieste to Venice shows the good fit of recorded and simulated data after accurate calibration of the braking and acceleration parameters of the micro-simulation tool OpenTrack. Part C compiles seven papers on recently developed rescheduling models of trains in Great Britain, Germany, Japan, France, Italy and the Netherlands. R. Takagi et al. present an optimisation routine embedded in an Object-Oriented Multi-Train Simulator, which uses a Genetic Algorithm for the order of route
setting according to different weights of passenger and freight trains at a railway junction on the Birmingham to Bristol line in case of incidents. A. D’Ariano & T. Albrecht develop a model for the estimation of optimised running times in order to minimise train delays and energy consumption in case of disturbance on a Dutch railway line. The headway conflict recognition and resolution adopts blocking time theory and train schedules are modelled as alternative graphs. C. Hirai et al. propose an algorithm for automatic analysis and selection of rescheduling patterns in case of disturbances, where the rules are written in a specific language so that dispatchers can easily understand the instructions. J. Rodriguez introduces a constraint-based scheduling model for the resolution of conflicts at railway junctions, where the individual train movements are described as jobs performing a sequence of activities that are linked by a set of precedence constraints. Optimal routes and corresponding track circuits for the resolution of conflicting train movements are assigned by means of a heuristic approach, which was validated on the infrastructure and scheduled trains of major railway junction North of Paris. S. Ricci & A. Tieri present a Petri net model for conflict forecasting and resolution, e.g. automatic overtaking of trains, which has been simulated in both un-perturbed and perturbed conditions on the high-density Italian railway line Roma-Formia. S. Wegele et al. compare the effectiveness of the two rescheduling tools ROMA developed in the Netherlands and GADis developed in Germany by testing their performance in simulated delay scenarios on a main Dutch railway corridor between Utrecht and Den Bosch. While ROMA solves the scheduling problem by means of a branch and bound algorithm and a train speed coordination procedure based on blocking time theory, the train paths in GADis are inserted heuristically one by one, reordered and varied by evolutionary genetic algorithms. The rescheduling performance of both models differs slightly, which is explained by different modelling of the signalling and automatic train protection system and its impact on train dynamics. Finally, K. Kumazawa et al. present a rescheduling system based on path search for train schedules by means of PERT, which are weighted by the estimated amount of passenger travel times, transfer passengers and passengers discomfort in trains due to overload, while the time needed for planning and execution of the rescheduling measures is considered in the model. Further progress in research and development of innovative methods and tools to (re)design efficient timetables that enable high capacity consumption provides reliable train services according to transport demand and are robust against regular disturbances. Fast real-time data mining and monitoring tools that exploit standard train detection, signalling and track occupation/clearance data will become more and more available and improve the quality of timetabling, performance of operations and passenger information. Computer-aided dynamic traffic management systems and fast, accurate semi-automatic rescheduling tools are needed to alleviate traffic controllers and dispatchers from routine tasks and offer effective decision support in complex networks.
This page intentionally left blank
Part A Timetabling
This page intentionally left blank
Timetabling
3
RailML – a standard data interface for railroad applications A. Nash1, D. Huerlimann1, J. Schuette2 & V. P. Krauss2 1
Institute of Transportation Planning and Systems, Swiss Federal Institute of Technology, Switzerland 2 Fraunhofer Institute for Transportation Systems and Infrastructure, Germany
Abstract The growing number of computer programs used to model different aspects of railway operations has created the need for a simple and efficient way to transfer data between applications. In the past, specialized interface programs have been developed to transfer data but this is an inefficient and time-consuming process. As the number of different railway simulation and operations programs increases, developing and maintaining individual interfaces will become impractical. RailML has been developed using the XML (eXtensible Markup Language) to simplify data transfer through the use of a common data structure. Programs using the RailML language produce export files with the RailML structure, these files can then be used directly by other RailML compatible programs. RailML is an open source project being supported and developed by a growing list of partners. The paper presents a more detailed description of RailML, outlines the application’s current status, and invites new partners to join the consortium. Keywords: railway simulation, timetabling, XML, RailML, data transfer, transportation data mark-up languages.
1
Introduction: problem and solution
RailML is an open source data structure that has been developed to simplify the transfer of data between various railroad simulation and operations computer programs. This chapter describes the RailML program and the problem it has been developed to address.
4 Timetable Planning and Information Quality 1.1 Railway data exchange problem Today, the computer has become a standard tool in the planning and operation of all businesses, and railroads are no exception. In the last few years the number of specialized computer programs designed to address all aspects of the railroad business from timetable construction to staff assignment to infrastructure planning has mushroomed. In most cases these programs have different data structures and protocols. As the number of programs and applications grows, the variety of different data structures becomes more and more unwieldy. In order to efficiently use several different applications for planning improvements to railroad operations together, data must be exported from one program and imported into another for further processing. This can be done by copying data between applications (a long and tedious process for programs with any significant amount of data) or by using an automatic data transfer program (transparent for the user). Several specialized interfaces between programs currently exist, but as the number of railway applications grows this solution becomes less efficient. Transferring data between two particular programs requires that two different interfaces be developed (one for each direction of transfer). As the number of programs increases the number of possible data transfers increases significantly. For example, assuming there are five programs, in theory twenty specialized interfaces need to be developed for full data exchange between all programs. In general terms, if the number of programs, n, increases linearly, the number of interfaces [n * (n-1)] increases quadradically. As the number of new technical solutions, such as Tracking & Tracing, real time estimates and adjustments, increases, so will the number of railway programs increase. Clearly, the number of new interfaces to be developed for these new applications represents a great challenge to the railroad industry. 1.2 Standard formats for efficient data exchange The situation in the railroad industry is not unusual, as computers become more ubiqueous in society there is a growing need for efficient data exchange. Today these types of data incompatibility problems are being addressed using "open and universally usable data formats". Such formats are generally developed using the eXtensible mark-up language (XML) as a basis (e.g. MathML for mathematical expressions and GML for geographical data). XML was developed by the World Wide Web consortium for use in WWW applications (the most well-known mark-up language is XHTML). XML is not an application language, but rather a set of rules that can be used to define other “mark-up” languages and therefore functions as a meta language. The major advantage of XML based documents is that they describe both data as well as the data’s structure. Therefore, XML was an ideal solution for transfer and storage of railroad data. The data transfer problem created as the number of applications increases can be solved by means of EAI (Enterprise Application Integration). EAI enables the collaboration of different programs by creating standard interfaces, which are
Timetabling
5
independent of any given application, but focus on the objects to be exchanged. The corresponding object descriptions are based on XML syntax. Effective data exchange between two applications requires that each program include a function for generating XML data (export) and a function for reading in and interpreting XML files (import). Due to both the widespread use of XML and the standardization caused by the World Wide Web, most computer application development platforms include pre-defined libraries and functions for the processing of XML based data, which substantially reduces the time needed to develop import and export functions for creating specialized applications such as for railroads. 1.3 Development of RailML In 2001, a group of railroad application developers formed a free partnership with the objective of developing an open source XML-based language for railroad applications that would be called RailML. The partnership was originally organized by researchers from the German Fraunhofer Institute for Transportation Systems and Infrastructure in Dresden (FhG-IVI) and the Swiss Federal Institute of Technology’s Institute for Transportation Planning and Systems (ETH IVT). The partnership is organized under the name RailML Consortium (www.railml.org) and has expanded to include researchers from several universities, railroad operating companies, private research institutes, and consulting firms. The Fraunhofer Institute serves as the partnership’s technical coordinator providing resources such as the web page and discussion forum. As a partnership, the development of RailML is based on suggestions, comments, and criticism of the partners. Individual application developers work together in a coordinated fashion to complete the actual work of developing elements of RailML. These developers form groups (open to all interested partners) based on individual interests and then communicate through moderated on-line user forums, newsgroups, and at regular meetings. As groups finish work on RailML elements, consortium members serving as technical coordinators finalize them and publish the standards (similar to the RFC for the Internet). In summary, RailML standards are developed in the context of technical discussions that are open to everyone interested in developing applications for the railroad industry.
2
RailML schemas
RailML is a generic language that can be used to describe railway-related data. The language has been divided into sub-formats (or schemas) for particular types of railway data. RailML consortium partners are currently developing data structures for the three main types of data files used in railroad simulation: timetable (schedule), infrastructure (with subsets for lines and stations), and rolling stock. Figure 1 illustrates the RailML schemas.
6 Timetable Planning and Information Quality At present the RailML timetable structure is most developed and has already been incorporated into several applications (e.g. OpenTrack, FBS, Viriato and OpenTimeTable [1]). A significant amount of work has been completed on both the infrastructure and rolling stock schemas, but these have not yet been finalized. Several additional schema have been suggested.
Figure 1:
Existing RailML schemas.
As a web-based development partnership, each schema has its own newsgroup open for discussion. The newsgroups' purpose is two-fold: first, newsgroup partners exchange information; second, knowledge and processing of definitions is discussed and archived. RailML.org also supports a newsgroup for general exchange and discussions that are not schema-related.
3
Data transfer with RailML
RailML is a simple and efficient way to transfer data between computer programs used to model different aspects of railroad operations. Programs using the RailML language produce export files with the RailML structure; these files can then be used directly by other programs. The receiving program parses the incoming file to obtain only the data it needs, which allows many different programs to use the same data file. RailML provides two ways for data exchange. The first consists of running applications separately and having them produce output files that are then used as inputs for other applications. The second approach, currently under development, consists of transferring data between two applications directly by means of interprocess communication (e.g. Web services via TCP/IP) to expenditure-exchange, i.e. without the detour of a file. Figure 2 illustrates the two forms of data transfer process.
Timetabling
Figure 2:
4
7
Examples of RailML data transfer.
RailML structure
This chapter describes the general structure of a RailML file using the timetable schema as an example. RailML is an XML-based language, this means that data files include both data and descriptions of the data that they contain. All XML derived languages use a very simple and flexible ASCII title format for their documents. In all cases the documents are hierarchical, they form of a tree layout, i.e. each document has a clear root element, from which navigation can start using the general document structure (common to all RailML documents) as a guide. The RailML document’s root element is called . The sub-schemas (infrastructure, rolling stock, and timetable), which contain the railway-relevant data, are then derived from this root structure. Using this flexible approach, each individual RailML compatible application determines which particular types of data should be used. The data in XML documents are organized and administered by means of elements and attributes. A RailML element begins with a start tag “< railml >”, and ends with an ending tag “”. An element can have attributes for more detailed description and may also contain additional elements. Figure 4 illustrates an example RailML document, which contains timetable data. Under the element “< timetable >” are listed the individual courses in the element “< train >”. The most important attribute of a course, the course number (trainID), is required; other attributes are optional. Every train running (course) contains as many timetable entries as desired “< entry >”, which are arranged listed under the element of “”. The individual timetable entries contain attributes such as station abbreviation (pos ID), arrival time (arrival), departure time (departure), or minimum station stopping time (min stop time).
8 Timetable Planning and Information Quality
Figure 3:
Example RailML document.
As Figure 3 illustrates, the RailML language is very similar to other XMLbased languages and therefore relatively easy to understand and use.
5
RailML consortium
As outlined above, RailML is being developed as open source data format by a group of railroad application developers who have joined together to form the RailML Consortium. Program development is being led by the Fraunhofer Institute and now includes many partners from academia and industry. As a partnership all development is based on suggestions, comments, and criticism of the partners. Partners have two main responsibilities; first, to help develop RailML; and, second to encourage the wide dissemination and application of RailML. New partners are welcome to join the consortium at any time [2]. There are two types of partners: Supportive Partners and Development Partners. Supportive Partners receive the copyright for XML schemas (according to the licensing terms and conditions) and are listed on the RailML web site with a link to their respective homepage. Development Partners take an active part in
Timetabling
9
developing schemas by providing suggestions, comments, and recommendations. Each schema has its own set of development partners. Today the use of the RailML-schemes by all partners is free, as long the formats and the copyright of railML.org are respected. Since autumn 2003, RailML is a registered trademark. Every application, which is be able to read or write RailML-data by a railML-scheme can be allowed to use the following RailML-Logo:
Figure 4:
6
RailML-logo.
Conclusions – benefits for simulation and timetabling
The RailML project’s objective is to simplify data transfer between the growing number of computerized rail simulation programs through the use of a common data structure. This is extremely beneficial in that it allows railroad planners and operators to easily use several different types of computer applications, using each to do what it does best. In the past, specialized interface programs were developed to transfer data between applications, but this is an inefficient and time-consuming process. Furthermore, as the number of applications increases, developing and maintaining these individual interfaces is becoming impractical. Already several different railroad applications include interfaces that use the RailML format to import and export timetable data between applications. These programs include: FBS, Viriato, OpenTrack, and OpenTimeTable.
References [1] [2] [3]
[4] [5]
For more information on these programmes please see: www.opentrack.ch www.irfp.de/fbs, www.viriato.ch, www.opentimetable.ch. All information about RailML can be found at www.railml.org. Fries, N., 2003, Modellierung und Abbildung einer EisenbahnInfrastruktur auf ein Schema der XML-basierten Schnittstelle RailML (Diplomarbeit, TU Dresden, Professur für Verkehrssicherungstechnik, Dresden). Hengartner, M., 2003, Grafikeditor für RailML-basierte Infrastrukturdaten (Diplomarbeit, ETH Zürich, Institut für Verkehrsplanung und Transportsysteme, Zürich). Hürlimann, D., 2002, Objektorientierte Modellierung von Infrastrukturelementen und Betriebsvorgängen im Eisenbahnwesen, 2002, Institut für Verkehrsplanung und Transportsysteme, ETH Zürich, Schriftenreihe des IVT, Nr. 125.
10 Timetable Planning and Information Quality [6]
[7]
Montigel, M., 2002, Time-triggered exchange of train route data between train control systems, in Computers in Railways, edited by J. Allan, R. J. Hill, C. A. Brebbia, G. Sciutto & S. Sone (WIT Press, Southampton), pp. 33–41. Hoffmann, R., Krauss, V.P., 2001, RailML als Datenaustauschformat für Eisenbahnsoftware (Projektbeschreibungen und -berichte sowie Konzepte, Fraunhofer Gesellschaft e.V., Institut für Verkehrs- und Infrastruktursysteme, Dresden).
Timetabling
11
Timetable stability - using simulation to ensure quality in a regular interval timetable J. Demitz1, C. Hübschen2 & C. Albrecht3 1
Rail Management Consultants Ltd., Germany DB Regionalbahn Westfalen GmbH, Germany 3 Regionalleitung NRW – Ressort Produktion, Germany 2
Abstract A regular interval timetable is characterised by train services that run in a fixed pattern, e.g. every 60 minutes. All trains of the pattern depart at the same station at the same minute during the whole day. To enable the passengers to reach all stations that cannot be connected by direct trains there are connections between several services at network nodes. The connection times are often short (generally less than 8 minutes). Therefore, there is a strong demand for a very good on time running in the network. Otherwise delays will be transferred between trains that do not interact directly or connections for passengers are lost. The 2003 passenger timetable was constructed from the concept worked out by North Rhine-Westphalia’s ministry of transport that is commissioner for the regional train services. This regional passenger concept had approx. 5,300 passenger train runs per day. It considered all political requests regarding service frequency, stopping patterns, etc.
1
Introduction
The 2003 regular interval timetable in North Rhine-Westphalia is designed to meet the following objectives in public transport politics: • Increasing the services in regional and long distance passenger services • Optimising the on-time-running of passenger services • Optimising track bound freight services Railway passengers demand short journey times and convenient connections between different services. To ensure the planned arrival at the destination the
12 Timetable Planning and Information Quality on-time-running level must be high. This requires a robust and reliable railway operation. To recover from delays reserves like running time allowances and buffer times between train runs have to be considered in a sensible way. A regular interval timetable has network wide dependences. On the one hand there are boundary conditions from the passenger flow, like connections between different trains at the network nodes. On the other hand there are operational constraints like track occupations from several trains within a short period of time. This becomes even more significant where fast and slow passenger trains and freight trains have to share the same track sections. These interactions need to be handled by an integrated examination of the whole network. The experiences during the first phase of the regular interval timetable in NRW (1998) showed that the robustness and reliability of the timetable was dependant on good planning. Therefore, the second phase of the timetable concept was investigated by a detailed timetable simulation before the services started in reality. This investigation performed by Rail Management Consultants Ltd. (RMCon) from Hanover, Germany [1] with the help of the railway simulation system RailSys. The main aim was to find out where operational weaknesses are and how they could be solved before the timetable was set into operation. The results showed that the timetable would be robust under the given circumstances like modern rolling stock, etc. As some of these conditions could not be met in reality further investigation was needed with regard to the changed circumstances. RMCon has developed the Timetable and Infrastructure Management System RailSys to perform operational investigations on large railway networks. Timetables can be constructed regarding the exact block occupation times of each train run in a detailed planning process. In the following simulation all train runs of the constructed timetable are modelled for the whole network. The consequences of delays obstructing other trains are modelled. This allows judging of interactions between different parameters such as delays, rolling stock parameters and signalling equipment.
2
Initial situation and objectives
The original 2003 timetable concept was based on several boundary conditions that could not be met at the beginning of the timetable period. On the one hand modern rolling stock was expected which has higher velocities, higher acceleration rates and allows shorter dwell times because of larger doorways. On the other hand several stops needed longer time than scheduled. These circumstances caused delays in the regular operation and the on-time-running performance was not as good as expected. The on time running performance measured in real operation did not meet the simulated figures from the investigation of the 2003 timetable concept done by Rail Management Consultants Ltd. (RMCon) from Hanover, Germany. There was the need to improve the database regarding the changed boundary conditions. This led into a new investigation of the whole NRW railway network. The investigation to increase the on time running of the 2003 timetable
Timetabling
13
of North Rhine-Westphalia, Germany, was commissioned by Germany’s largest regional train operator DB Regio AG. In the timetable there are a lot of connections between different regional services as well as between regional and long distance services. This requirement and a high frequency of trains, creates a lot of dependencies between the train runs. Problems in one network area are carried on to other areas of the network. The aim of the detailed investigation of the 2003 timetable was to find solutions for improving the on time running by adjusting the timetable to the changed boundary conditions. This included e.g. adaptations of scheduled running times and dwell times to reduce delays. The political requests (service frequency, stopping patterns, connections, etc.) in the timetable had to be kept up. The investigation’s aim was to find solutions to solve the described problems within the planned timetable concept. If alterations in services were needed the basic timetable concept always had to kept up. The results should prepare the registration of train paths at the German railway network provider, DB Netz AG.
Figure 1: Timetable and infrastructure management system RailSys.
14 Timetable Planning and Information Quality
3 Investigations to improve the on-time-running of the 2003 timetable in North Rhine-Westphalia 3.1 Work packages Within the examination the following work packages have been realised: • Establishing the model (timetable and infrastructure data import, adjustment of used rolling stock) • Evaluation of services with rolling stock and dwell time problems • Construction of timetable scenarios to solve problems • Simulation of two timetable scenarios to investigate the use of increased scheduled dwell times • Delivery of timetable modifications to DB Netz AG to be considered in the construction of the working timetable 3.2 Timetable and Infrastructure Management System RailSys The evaluation of the 2003 NRW railway timetable was done with the Timetable and Infrastructure Management System RailSys. RMCon and the Institute of Transport, Railway Construction and Operation (IVE) of the University of Hanover, Germany [2] developed this software for rail bound traffic. RailSys allows a very precise computer aided modelling of operational procedures in railway networks. All relevant safety systems and operational conditions are included. It is designed with the special ability to model large and complex railway networks on a microscopic base. The software runs on a standard Microsoft Windows PC as well as Unix/Linux Computers. The system architecture of RailSys software is shown in Figure 1. 3.2.1 Input data The model needs the following input data: • Infrastructure - Track layout (length, gradients, turnout locations, etc.) - Safety system (signal positions, signalling system, route setting times, etc.) • Operation - Vehicle data (traction units, train length, train mass, etc.) - Timetable data (arrival and departure times, planned running times, platforms used, etc.) • Simulation - Delays (entering the system late, dwell time delays, etc) - Dispatching rules (alternative platforms, priorities, etc.) 3.2.2 Timetable construction and simulation Timetables can be constructed with RailSys’ timetable manager. It calculates all block occupation times for each train run and automatically detects all conflicts between train runs across the whole network. The user can solve these conflicts
Timetabling
15
interactively with the help of an automatically generated timetable graph. All construction rules, like margins between trains, and running time reserves, such as general allowances or allowances for engineering works, can be displayed during the construction. Figure 2 shows RailSys’ graphical user interface for the timetable construction.
Figure 2: RailSys timetable construction user interface. Creating a conflict free static timetable does not suffice to prove whether a timetable will result in satisfying operational quality, or will generate a delayburdened operation that satisfies neither the operator nor the passenger [3]. Only an operational simulation can verify the operational program substantially and evaluate the operational quality before the timetable is launched. Therefore, in addition to the timetable construction, the operational simulation is the substantial component of RailSys. To check the robustness of an operational program several timetables representing a series of operational days are overlaid with various automatically generated perturbations (multiple simulation). These perturbations are normally based on real operations’ experience and are represented by probability distributions. Different distributions can be implemented for each train run at each station, or at other
16 Timetable Planning and Information Quality places in the network where perturbations can occur. Delays can also be added to trains as they enter the simulation area. In the multiple simulation each train run gets different perturbations from its distribution on each operational day. Integrated routing algorithms simulate the actions traffic controllers would take to influence the disrupted traffic flow. Thereby signalling rules and priority strategies are considered. Other possibilities of delay transfer are reversing or connected trains. If a train turns around at its ultimate destination, delays are transferred to the next train in the opposite direction. There can also be connections between different services in the network nodes representing trains held back to ensure the passengers’ flow from another train. Running time or dwell time allowances are taken into account, reducing the delays caused directly by perturbations or indirectly by delayed train runs. After the simulation, the average delays of all train runs over a period of several days or weeks are evaluated. This shows where operational problems exist in the network and visualises possible bottlenecks. If problems and/or bottlenecks occur there is the option of reducing the timetable requirements, or increasing the infrastructure capabilities. After the delay evaluation an iterative process starts to optimise the combination between the requested timetable and the required infrastructure. Additionally on-time-running figures and the percentage of kept or cancelled connections can be evaluated. 3.3 Database The investigation area covers the whole railway network of Germany’s state of North Rhine-Westphalia. The infrastructure and timetable data was delivered by DB Netz AG in digital format from the currently used timetable construction tool RUT. The data covers all details of railway infrastructure as signal position, turnout locations, gradients, speed limits, etc. Because of the complexity of the network the infrastructure data in RUT had to be divided into 12 independent partial networks. This data was imported into RailSys and connected to one network free of redundancies as shown in Figure 3. The 2003 timetable data was also imported into RailSys from the RUT system. This data was completed with extra information about platform working in the stations and reversing connections at the trains’ final destinations and the currently used rolling stock. 3.4 Timetable construction To construct a network-wide conflict free timetable as a base case, the different data sources had to be merged. This complete database allowed working out concepts to solve the operational problems. Therefore, several scenarios were constructed regarding the following problems: • Extension of scheduled dwell times in highly frequented stations for fast regional trains (RegionalExpress RE) within the existing timetable • Alternative timetable concepts for services using rolling stock with speed restrictions to reduce delays from extended running times
Timetabling
17
Figure 3: Entire railway infrastructure of North Rhine-Westphalia in RailSys. RailSys allows a very efficient timetable construction. If conflicts between trains occur because of alterations in the timetable they are detected on the whole network simultaneously. These conflicts can be solved using different platforms in stations or adjusting train runs following each other on the line. The original arrival and departure times from the imported timetable are available in RailSys as requested times. This allows analysing the deviation of the newly constructed train run from the original train run. To create a complete 24-hour timetable the trains can be constructed in a pattern structure. All trains of one service pattern can be modified in parallel. The whole timetable construction is done with regard to valid timetabling rules used by the DB AG. These rules cover basic running time allowances, special running time allowances for engineering works and buffer times between trains to avoid delay transfer. 3.4.1 Dwell-time extensions on RegionalExpress trains (RE) To ensure on-time departure at stations with higher passenger demand the scheduled dwell times on some fast regional trains (RegionalExpress RE) had to be extended. The longer dwell times extended journey times between the network nodes. This might cause conflicts with following trains on the same line section. Also connections to other services in the network nodes can get lost.
18 Timetable Planning and Information Quality This led into necessary alterations in the timetable. The timetabling rules of the DB Netz AG cover margins between train runs and running time allowances for engineering work, etc. If there are extra reserves in the timetable they can be used to recover from the scheduled dwell time extensions. If there are no extra reserves some station stops have to be cancelled. Another possibility is to alter other conflicting trains as well to ensure a conflict free timetable. An example of scheduled dwell time extensions can be seen in Figure 4.
Figure 4: Dwell time extensions on fast regional service (RegionalExpress). The results with all altered train runs were handed over to the DB AG to be considered within the alteration of the working timetable. 3.4.2 Timetable concepts due to speed-limited rolling stock In 2003 several regional services were taken over by modern electric multiple units. These units are designed for a maximum speed of 140 km/h. Due to braking problems they were limited to travel at 120 km/h. This speed limit produced on some services scheduled for 140 km/h very high delays. To ensure a better on time running even with the slower vehicles timetable alterations were discussed. In two areas in North Rhine-Westphalia the required adaptations caused alterations in the timetable concept. To find the best solutions several concepts were investigated by RMCon during a three-day conference with DB Regio. In this meeting running times, free train paths and the compliance with planned connections were evaluated. Due to the network wide conflict resolution in RailSys and the ability to
Timetabling
19
construct a whole-day service pattern at once final concepts could be worked out very fast. An example of what happens to the service when it runs at lower speed without alterations in the timetable was evaluated with the simulation (Figure 5).
Figure 5: Delays caused by speed limited rolling stock and disruptions with other trains. This example shows that the train gets delays from the speed limit and additional delays due to hinder by other trains. The delay is compared to the originally scheduled times. The total delay rose up to 10 Minutes at the terminus. To run the service scheduled at lower speed several alterations had to be done on a highly occupied line section. The alterations could be done sustaining the 2003 timetable concept with all stops and connections.
4
East-Westphalia network
A second area with speed limit problems was the region East-Westphalia around the cities of Hamm/Westf, Bielefeld, Paderborn and Münster. As there are several services using the above described speed-limited train sets, the required alterations led into a completely new timetable concept (Figure 6). This concept was worked out by DB Regio AG. RMCon investigated whether the services could be constructed conflict-free regarding the remaining passenger traffic. In addition to the alteration of the regional services’ train paths the complete platform working in the network node Hamm/Westf. had to be rescheduled. This station is characterized by a lot of services arriving and departing at the same time to ensure connections.
20 Timetable Planning and Information Quality On several lines the requested stops had to be allocated to other services. Also different rolling stock with higher velocity was used for several services to keep the requested running times between the network nodes. In some areas the planned concept concerning stops and connections had to be altered. This altered network concept was basis for a discussion with the ministry of transport of North Rhine-Westphalia who worked out the original concept.
Figure 6: East-Westphalia network investigated with RailSys. 4.1 Simulation of improvements In the timetable concepts worked out with RailSys, one topic was the extension of scheduled dwell times to cope with higher passenger demand in selected stations. This was evaluated for all fast regional services (RegionalExpress RE) in NRW. One result was that in some cases the extension could be done without changes in the timetable concept. In other cases adaptations were needed to sustain connections with other services.
Timetabling
21
4.1.1 Dwell-time extensions on RegionalExpress trains (RE) The impact of extended dwell times on the on-time-running performance was investigated with the help of RailSys’ operational simulation. Therefore, an investigation of passenger flows was done to categorize stations into highly, medium frequented and lowly frequented stations. In the simulation the trains got dynamic dwell time delays in these stations. The delay distributions are based on general figures provided by DB Netz AG because an evaluation of real delay figures was not possible during the project. The simulation results were used as a basis for discussions about the timetable concept with the commissioner of regional services, the ministry of transport of North Rhine-Westphalia. To examine the effects of extended scheduled dwell times two timetable scenarios were simulated and the results were compared: • Scenario 1: Original timetable with given dwell times • Scenario 2: Adapted timetable with extended scheduled dwell times In both scenarios the same delay distributions were used and the minimum dwell times were similar. The extended scheduled dwell times imply higher dwell time reserves to recover from delays. After simulating both scenarios, the evaluation of the resulting delays and ontime running figures was performed. The results were evaluated in two different ways. The major part was to examine the operational quality. This procedure was focussed on the trains’ average delays. Operational quality is defined as ‘good’ if the trains do not have increasing delays within the examined area. It is considered ‘insufficient’ if the trains’ delays increase within the investigation area. The second evaluation was the comparison of on-time-running figures in both timetable scenarios. The on time running measured in selected stations is a criterion for the service quality defined by the commissioner of local transport services and the railway operators. Trains that are delayed less than 5 minutes are considered on time. 4.1.2 Operational quality The evaluations regarding the operational quality were done separately for long distance passenger trains, local passenger trains, suburban trains and freight trains. The results of both scenarios were compared to detect changes within the operational quality. The examination of the average delays gives hints where operational problems exist and thereby helps locating bottlenecks within the network. The first analysis was done macroscopically with evaluations of delays within the network. For areas or lines with higher interest detailed evaluations have been executed subsequently. Arrival and departure delays dwell time delays or delays due to dispatching actions were evaluated separately. An example of average delays evaluated on a RE-service can be seen in Figure 7. In both scenarios the service shown has increasing delays on its route. Based on the definition the operational quality is insufficient. The comparison of both
22 Timetable Planning and Information Quality scenarios shows that with extended dwell times the average delay along the whole train run is lower than in the original timetable. After evaluating all adopted lines the evaluation showed in which stations the dwell time extension had positive effects and in which stations the dwell time extension achieved no improvement.
Figure 7: Example of an evaluation of operational quality (average delays).
Figure 8: Example of an On Time Running comparison.
Timetabling
23
4.1.3 On-time-running Analogous to the evaluation of the operational quality, comparisons have been made between the investigated on-time-running figures of the two scenarios. The results were then compared to on-time-running figures from the real operation. A comparison between the simulated on-time-running values in Figure 8 and the real values allows a validation between simulation and reality. A simulation working with general assumptions concerning the delays cannot provide exactly the same figures than real operation. But this example shows that the simulated on-time-running values in scenario 1 were generally quite close to the real figures. The improvement between the two scenarios could be recognized in the train’s terminus Hamm.
5
Conclusions
The insufficient on-time-running performance at the beginning of the 2003 timetable in North Rhine-Westphalia was due to rolling stock problems and too short dwell times. The investigations concerning adaptations in several services showed that there is still potential to increase the on time running. With RailSys’ ability to construct a network wide timetable including enclosed conflict detection several alterations could be performed. These were dwell time extensions on several services to reduce delays due to higher passenger flows. Also completely new concepts for services with additional speed limits were investigated and solutions were proposed to DB Regio and DB Netz. The results were possible alterations within the existing timetable or larger adaptations compliant with the timetable concept. The operational simulation verified sensible modifications in the timetable to reduce delays and to improve the on-time-running performance. The efficiency in constructing and simulating a network wide conflict free timetable shows that RailSys can be used successfully in short-term planning processes. A quick analysis to find out whether timetable concepts can be turned into a working timetable allows railway operators like DB Regio AG to build up coordinated concepts. The constructed timetable data can be used for the announcement of train paths of a railway network provider like DB Netz AG.
6
Perspective
RailSys is a timetable construction and simulation system that can be used on a regular Windows PC. It offers a lot of possibilities for future improvement in timetable construction and operational simulation. For railway operators competing in bidding processes for regional services it becomes more and more important that future timetable concepts are verified. This implies especially a conflict free construction and can be extended to evaluating the expected operational stability and robustness with the help of a simulation.
24 Timetable Planning and Information Quality Interfaces to different software systems allow the use of RailSys data in other processes. The timetable data e.g. can be handed over for the construction of a working timetable. Another interface can provide data for the vehicle allocation tool Dispo developed by IVE [4] or the network evaluation model Nemo [5]. RailSys can be used in ad-hoc planning processes during the operation. It is possible to adopt timetables due to temporarily track blockings or speed limits for engineering works. The connection between RailSys and Dispo [6] allows a quick review on rolling stock demands due to timetable changes. In general the modelling of large networks has improved RailSys’ functions to make the timetable construction and the statistical evaluation for more than 8,000 trains a lot more comfortable. For future investigations an automatic path detector is currently under development to find free train slots for additional trains in large networks [7,8].
References [1] [2] [3] [4] [5] [6] [7] [8]
http://www.rmcon.de. http://www.ive.uni-hannover.de. Rudolph, Raphaela: “Operational Simulation - A Tool to Manage Future Railway Performance”, Proceedings of the 9th World Congress on Intelligent Transport Systems, Chicago, USA, 14th to 17th Oct 2002. Dispo: Optimised Vehicle Allocation http://www.ive.uni-hannover.de/ software/dispo/index_en.shtml. Kettner, Michael, Sewcyk, Bernd: “A model for transportation planning and railway network evaluation”, Proceedings of the 9th World Congress on Intelligent Transport Systems, Chicago, USA, 14th to 17th Oct 2002. Schumacher, Andreas, Monecke, Lars, Freiberger, Kai-Uwe; “Modelling constrains in automatic vehicle rostering - demands and possibilities” Proceeding of Comprail 2004. Hauptmann, Dirk: “Automatic and non-discriminatory train path allocation in railway networks of arbitrary size”, Dissertation No.54, 02.02.2000. Radtke, Alfons, Hauptmann, Dirk: “Automated planning of timetables in large railway networks using a microscopic data bases and railway simulation techniques” Proceeding of Comprail 2004.
Timetabling
25
Crystal diagram: a technique for making high-density diagrams K. Katsuta1, T. Takano1, K. Oguma1, D. Watanabe1 & T. Uemura2 1
Hitachi Ltd, Hitachi Research Laboratory, Japan Hitachi Ltd, Power & Industrial Systems Mito Transportation Systems Product Div., Japan
2
Abstract We propose “crystal diagram” as a base for making high-density diagrams. In high-density railway sections such as metropolitan commuter lines, there is a great demand for increasing train density in order to relieve traffic congestion. However, it becomes more difficult to shorten train headway, as the track layout, train type and so on become more diverse. Therefore, making train diagrams needs the expertise of skilled specialists. In order to raise the train density, this paper aims to calculate the train minimum intervals between all trains within a certain accuracy and derive an original train diagram. It is a crystal diagram to refer to one cycle of the pattern and station diagram whose periodic time is shortest, on the assumption that instructions to all trains in one period are fixed. In practice, we obtain the effective results for operation planning, train dispatching and equipment design when we derive the crystal diagrams of model cases. Keywords: diagram, high-density, pattern, station, operation planning, train dispatching, equipment design.
1
Introduction
Making a train diagram is one of the most important tasks in railway businesses, because the train diagram controls the transportation power of the railway. Much work has focussed on calculating the basic data such as train running curve and train headway [1][2], making a train diagram from the basic data [3], and implementing train dispatching strategy by immediately changing a train diagram. What seems to be lacking, however, is work deriving a train diagram
26 Timetable Planning and Information Quality which raises train density in situations needing complicated train operation, e.g., when track form is complex, train type is diverse, etc. The purpose of this paper is to derive a high-density train diagram. To satisfy this purpose, we calculate the minimum train interval to secure safety and optimize the train schedule based on it. We explain approaches for making a high-density diagram in section 2, and present a diagram which we aim to derive in section 3, a method to derive it in section 4, and implementation results in section 5. The final two sections present some future work and our conclusions.
2
Key points
We begin by considering two train diagrams. The key points to derive a highdensity train diagram efficiently are explained. 2.1 Pattern diagram A pattern diagram is composed of the same short train diagrams, as shown in fig. 1. In Japan, many pattern diagrams are used in metropolitan commuter lines. The main reason is that they are very useful for passengers and they make timetables easy to remember. We emphasize that the scale of the train diagram can be small. Accordingly, it is efficient to consider periodicity for making a train diagram. Pattern Time Station-A
Station-C
Station-B Periodic time
Figure 1:
Example of a pattern diagram.
2.2 Station diagram We use the term “station diagram” to refer to a train diagram within station premises only. Train operation is restricted by the location of other trains basically. In the area between stations, the train interval seldom becomes small suddenly, because the change of train speed is small. Within station premises, on
Timetabling
27
the other hand, the train interval becomes small suddenly, because trains stop there (fig. 2). In practice the train density is always restricted by train turning operation at a terminal station where point switches are shared. Accordingly, it is enough to consider the station diagram in order to increase train density.
Running curves Distance Station
Train interval
Figure 2:
3
Time
Change in train interval.
Proposed diagram
3.1 Periodic time We use the term “periodic time” to refer to time required for one period of a pattern diagram. Even if instructions to all trains such as “depart from track-1” in one period are fixed, the periodic time is controlled by the schedule. The reason is that the values of the minimum interval time between trains vary. The minimum interval time is necessary for securing safety and it is dependent on the performance of the signaling system, the rolling stock and so on. We illustrate the periodic time in the following example case: • Track layout is shown in fig. 3. • Two trains turn in one period. • Instructions to trains • One train turns at track-1. • Another train turns at track-2. • Schedule-A: • (1) train-a arrives, (2) train-b which arrived in the previous period departs, (3) train-a departs, and (4) train-b’ which will depart in the next period arrives.
28 Timetable Planning and Information Quality • ⇒ ⇒ ⇒
Schedule-B: • (1) train-a arrives, (2) train-a departs, (3) train-b arrives, and (4) train-b departs. The periodic time of schedule-A is shown in fig. 3. The periodic time of schedule-B is shown in fig. 4. The former is shorter than the latter.
The following result is obtained by comparing the periodic time: • The key point to increase the train density is to operate one train on track-2 while another train is stopped on track-1. (4) Train-b arrives. (1) Train-a arrives. (2) Train-b departs. (3) Train-a departs.
Distance
Train-b
Train-a
Time Track layout
Periodic time
Figure 3:
Distance
The periodic time of schedule-A.
(4) Train-b departs. (1) Train-a arrives. (2) Train-a departs. (3) Train-b arrives.
Train-b
Train-a Time Periodic time
Figure 4:
The periodic time of schedule-B.
Timetabling
29
3.2 Crystal diagram We propose a crystal diagram to refer to one cycle of the pattern and station diagram whose periodic time is shortest, on the assumption that instructions to all trains in one period are fixed. By deriving the crystal diagram at the station where the train operation is most complex, we can make a high-density diagram using the following two steps. The first step is uniting the crystal diagram periodically, and the second step is making the whole diagram so that the united diagram may be fitted smoothly. The purpose of this paper can be realized by deriving the crystal diagram.
4
Deriving the crystal diagram
We must consider three steps in order to derive the crystal diagram. The first step is how to calculate the minimum interval time between trains. The second step is how to calculate the periodic time of schedules. The final step is how to derive the schedule which has the shortest periodic time.
Running curve Distance
Minimum interval time Distance
Time Track layout
Figure 5:
Time Track layout
Example of running curve (left) and minimum interval time (right).
4.1 Calculating the minimum interval time We explain how to calculate the minimum interval time between trains as follows. • Prepare the following data: • Track layout data which are stored data of the connection of track circuits etc. • Rolling stock data which are stored data of the deceleration of trains etc.
30 Timetable Planning and Information Quality • • • •
Equipment data which are stored data of the point switching time etc. • Routes data stored the sequences of circuit tracks where trains run. Make all train running curves, as shown in fig. 5 (left). Calculate the timing when shared point switches are available for the following train, from the running curve of the previous train. Calculate the minimum interval time between the trains based on the timing, as shown in fig. 5 (right).
4.2 Calculating the periodic time Next, we explain how to calculate the periodic time of a schedule as follows. • Prepare the following data: • The minimum interval time between all trains calculated above. • Schedule data which are stored data of schedules such as ScheduleA of 3.1. • Restriction data which are stored data of the necessary stopped time for passenger boarding etc. • Add the minimum interval time according to the schedule, as shown in fig. 6. • Correct the added time considering periodicity, stopped time, etc. Minimum interval time (1)
(2)
(3)
(4)
(1)
Distance (2) (4)
(1) (3)
Time Track layout
Figure 6:
Periodic time
A method to calculate the periodic time.
4.3 Deriving the schedule which has the shortest periodic time Finally, we explain how to derive the schedule which has the shortest periodic time as follows. • Prepare the following data:
Timetabling
31
•
Instruction data which are stored data of instructions to all trains such as Instructions of 3.1. Make the schedules considering all permutations. Calculate the periodic time of all schedules in the method of 4.2. Take the schedule which has the shortest periodic time.
• • •
5
Results
5.1 Deriving the crystal diagram We derive the crystal diagram in the following model case: • Track layout is shown in fig. 7. • Three trains turn in one period. • For all trains, the brake is controlled as a continuous curve. • Parameters: • Speed limit at point switches: 45km/h, switching time: 10s. • Train length: 160m, acceleration and deceleration: 3.0km/h/s. • Stopped time: 60s. ⇒ The crystal diagram of this model case is shown in fig. 7. ⇒ We can see that it is possible to turn three trains every 230s.
(6)(2) (3)(5) (1)(4) Distance
(1)
(2) (3)
(4)
(5)
(6)
300m
600m Track layout
Figure 7:
Periodic time = 230s
Time
The track layout and the crystal diagram of model case in 5.1.
This crystal diagram is an effective result for operation planning and train dispatching, because we can use it as a base for making a train diagram by efficiently adjusting the train density planned beforehand. Furthermore, the completed diagram has much time to spare, in short, it is robust against delays. We show a display from a tool to derive a crystal diagram in fig. 8.
32 Timetable Planning and Information Quality
Figure 8:
Display from a tool to derive a crystal diagram.
5.2 Comparing crystal diagrams Similarly we derive crystal diagrams in the model cases shown in fig. 9. Then, we calculate and analyse the average interval time between trains. Some effective results which we can obtain are as follows. • For the average interval time between trains, , and are influenced by stopped time. On the other hand, is not influenced by it. ⇒ We can see that shortening stopped time at is ineffective for raising the train density more than it already is. • For the average interval time between trains, is as large as , though has more tracks than . ⇒ We can see that the expansion of equipment from A to B is ineffective for raising the train density, because the speed limit section must be lengthened by moving the point switch forward. These results are effective for equipment design, because we can use them as bases for designing equipment by efficiently adjusting the train density planned beforehand.
Timetabling
33
144s
Depends on stopped time Depends on switching time
75s
77s
Depends on signal system
64s
Depends on track layout
Figure 9:
Table 1:
The average interval time of each station.
The relation between the required time and the number of instructions. Instructions 2-5 6 7 8 9 10 11 12
Permutation(*1) --1.2*102 (5!) 7.2*102 (6!) 5.0*103 (7!) 4.0*104 (8!) 3.6*105 (9!) 3.6*106 (10!) 4.0*107 (11!)
CPU: 2.0GHz, Memory: 256MB. (*1) Circular permutation by periodicity.
Required time ai and Ci ≤ Ai + 30
where, Ai and ai denote the actual and scheduled arrival time of train i at the platform track and Ci represents the clearance time of the outbound route of this train. The unit of these times is in seconds. Late arriving trains are selected by the former inequality and the latter inequality ensures that the chosen trains are not hindered by other trains at the station after a minimal dwell time of 30 s. It has been found that the Weibull distribution is the best approximate model among the candidate distributions for the free dwell times of late arriving trains in 16 of the total 18 studied cases. In addition, this distribution model has not been rejected by the K-S test in all the cases. Figure 7: and Figure 8: visualize
Operations Analysis
101
the goodness-of-fit of the Weibull distribution model with a shape parameter of 1.9 in case of the northbound interregional train series IR2200N. The fitted distribution matches well the kernel estimate for the empirical data and it has not been rejected by the K-S test. In conclusion, the Weibull distribution with a shape parameter larger than 1.0 is the best approximate model among the candidate distributions for the free dwell times of late arriving trains.
Figure 7: Weibll fit, kernel estimate and histogram for the free dwell times of late arriving trains of IR2200N.
Figure 8: Distribution differences plot for the Weibull fit and the free dwell times of late arriving trains of IR2200N.
3.4 Running times and track occupancy times The distribution of train running times and that of track occupancy times are required to estimate the propagation of train delays in a railway network. In this paper, we focus on statistical distribution of the running times of trains on the preceding block of The Hague HS station and that of the occupancy times of adjacent junctions around this station. In case of an approaching train, if the inbound route is released earlier than the time of the train arriving at sight distance of the approach signal, the train approaches the station at the free running speed. Otherwise, the train is hindered and has to decelerate and even stop on the preceding block of the station. To accurately estimate the knock-on delays caused by route conflicts in a station area, it is necessary to investigate the conditional distributions of inbound train running and track occupancy times in the case of different aspects of the approach signal and home signal of the station. For a departing train, if it is hindered due to outbound route conflicts, it dwells at the station for a longer time, but running on the next track sections will not be hindered again. In this case, the conditional distributions are not applicable. To model the conditional distributions of inbound train running and track occupancy times based on a statistical analysis of the empirical data, the first step is to classify the data observations. By comparing the arrival time of each train at the approach signal to the clearance time of the inbound route, we have extracted a data set suited for fitting the free train running and track occupancy
102 Timetable Planning and Information Quality time distributions in each studied case. A hindered approaching train may pass the home signal with reduced speed without a stop or with acceleration speed after a stop in front of this signal. Since the standstill of a train on track is not recorded, we cannot directly identify whether or not a hindered train stops before the home signal based on track occupancy and release records. Adopting the kmeans routine within the statistical analysis tool S-Plus [7], we have split the data sample of hindered trains for each studied train series into two separate parts which correspond approximately to the two cases mentioned in the above. However, for the hindered trains that stop before the home signal, it is still unknown when these trains stop. Therefore, we have lack of the running times of these trains on the preceding block of the station. For the free running times of trains on the preceding block of the station, most of the candidate distributions have been rejected by the K-S test. Both the Weibull and normal distributions have not been rejected by the K-S test in 2 of the total 13 studied cases. In addition, each of these distributions is the best approximate model among the candidate distributions in 5 of the 13 cases. For inbound junction occupancy times by the free passing trains, the Weibull distribution is the best approximate distribution model in 3 of the total 4 considered cases and has not been rejected by the K-S test. The normal and Weibull distribution is the best fit among the candidate distributions for outbound track occupancy times in 2 and 1 of the total 3 considered cases, respectively. In addition, both the distributions have not been rejected by the K-S test in 2 of the 3 cases. The goodness-of-fit of the Weibull and normal distributions for the above-mentioned train process times is shown in Figure 9: and Figure 10:, respectively.
Figure 9: Weibull fit, kernel estimate and histogram for inbound junction occupancy times of free running trains IC2100S.
Figure 10: Normal fit, kernel estimate and histogram for outbound junction occupancy times of IC1900N.
In the case of the hindered trains that do not stop before the home signal, the Weibull and normal distribution is the best approximate distribution model for the running times on the preceding block of the station in 2 and 1 of the total 6 considered cases, respectively. In addition, both of the distributions have not been rejected by the K-S test in the 6 cases. For inbound junction occupancy
Operations Analysis
103
times by the hindered trains, the normal and Weibull distribution is the best approximate distribution model in 2 and 1 of the 5 considered cases and these distributions have not been rejected by the K-S test in the 5 cases. In the case of the hindered trains that stop before the home signal, the inbound junction occupancy times fit best to the normal distribution in the two considered cases and this distribution has not been rejected by the K-S test in one of the two cases. The goodness-of-fit of the Weibull and normal distributions for the above-mentioned train process times is given in Figure 11: and Figure 12:, respectively.
Figure 11: Weibull fit, kernel estimate and histogram for inbound running times of hindered INT600S that do not stop before the home signal.
Figure 12: Normal fit, kernel estimate and histogram for inbound junction occupancy times of hindered INT600S that stop before the home signal.
In conclusion, it is difficult to find a good distribution for the conditional train running and track junction occupancy times in the case of different aspects of relevant block signals. This might be because of the big variation of train speed on the short track sections in the complicated station and junction area.
4
Conclusions
We have compared several commonly applied distribution models for train process times on the basis of empirical train detection data recorded at a Dutch railway station The Hague HS. It has been found that the log-normal distribution can be generally considered as the best approximate model among the candidate distributions for both the arrival times of trains at the platform and at the approach signal of the station. The Weibull distribution can generally be considered as the best approximate distribution model for non-negative arrival delays, departure delays and the free dwell times of late arriving trains. The shape parameter of the fitted distribution is generally smaller than 1.0 in the first two cases, whereas the shape parameter is always larger than 1.0 in the last case. For simplicity, the exponential distribution can be used as an approximate distribution model for non-negative arrival delays and departure delays if the density is decreasing.
104 Timetable Planning and Information Quality
Acknowledgement This publication is a result of the research programme Towards Reliable Mobility, carried out within the Transport Research Centre of Delft University of Technology.
References [1] [2] [3]
[4]
[5] [6] [7] [8] [9] [10]
Averill, M.L. & Kelton, W.D., Simulation Modeling and Analysis, McGraw-Hill, 2000. Goverde, R.M.P., Hooghiemstra, G. & Lopuhaä, H.P., Statistical Analysis of Train Traffic: The Eindhoven Case, DUP Science, Delft, 2001. Hermann, U., Untersuchung zur Verspätungsentwicklung von Fernreisezügen auf der Datengrundlage der Rechnerunterstützten Zugüberwachung Frankfurt am Main, PhD thesis, Technische Hochschule Darmstadt, 1996. Radtke, A. & Hauptmann, D., Automated planning of timetables in large railway networks using a microscopic data basis and railway simulation techniques, In: Allan, J. et al. (eds.), Computers in Railways IX, pp. 615625, WIT Press, Southampton, 2004. Ross, S. M., Introduction to Probability and Statistics for Engineers and Scientists, Elsevier, 2004. Schwanhäusser, W., Die Bemessung der Pufferzeiten im Fahrplangefüge der Eisenbahn, PhD thesis, RWTH Aachen, 1974. S-Plus, S-Plus 2000 Guide to Statistics, Vol. 2, Data Analysis Products Division, Mathsoft, Seattle, 1999. Steckel, J., Strategische Optionen für die Zufällige Fahrzeit im Eisenbahnbetrieb, PhD thesis, Hochschule für Verkehrswesen ‘Friedrich List’ Dresden, 1991. Wendler, E. & Naehrig, M., Statistische auswertung von verspätungsdaten, Eisenbahningenieurkalender EIK, pp. 321-331, 2004. Yuan, J. & Hansen, I.A., Optimizing Capacity Utilization of Stations by Forecasting Knock-On Train Delays, In: Hansen, I.A. et al. (eds.), Proceedings of 1st International Seminar on Railway Operations Modelling and Analysis, Delft, 8-10 June, 2005.
Operations Analysis
105
Development of a dwell time calculation model for timetable planning S. Buchmueller1, U. Weidmann1 & A. Nash2 1
Institute for Transport Planning and Systems (IVT), Swiss Federal Institute of Technology (ETHZ), Switzerland 2 Vienna Transport Strategies (VTS), Vienna, Austria
Abstract Accurately estimating station dwell time is critical for timetable planning. Its importance has increased as railways seek to improve timetable stability and network efficiency, while serving more passengers and different types of transport services. This research consisted of developing a station dwell time model in cooperation with the Swiss Federal Railways (SBB). The proposed model estimates dwell times based on the input parameters: vehicle type (number, position, width and level of doorways), infrastructure (platform level) and demand (number and distribution of passengers). The research divides dwell time into five sub-processes: door-unblocking, opening doors, passenger boarding/alighting, closing doors and train dispatching. Each sub-process was evaluated separately to understand its influence on dwell time. The SBB’s automatic passenger counting system was used to record the number of passengers boarding and alighting at each door and the beginning/ending time of each sub-process. During eight months over three million measurements were made on four different vehicle types operating on 20 different routes. These data were analyzed and used to develop the dwell time model. This paper describes the research methodology, the structure of the dwell time model, the data collection system and presents a summary of results including statistical distribution and influence factors of sub-process times. Keywords: timetable planning, dwell time, dwell process, boarding/alighting process, railway process times, S-Bahn train, regional train, automatic passenger counting system.
106 Timetable Planning and Information Quality
1
Introduction
1.1 Background Switzerland’s suburban railway (S-Bahn) systems have become a victim of their own success. Passenger growth is increasing rapidly due to improved service quality (patronage on some lines has doubled in last 15 years). Unfortunately, the increased number of passengers has also increased critical service times such as station dwell time. The S-Bahn systems are operated in mixed traffic, in other words long-distance, suburban, regional and freight trains all share the same infrastructure. Finally, the Swiss railway network is operating close to capacity. This combination of factors has increased the risk of reducing timetable stability on the entire network. One way of reducing this risk is to plan operations more precisely. An important part of this planning process is to accurately estimate station dwell time. Therefore, the Swiss Federal Railways (SBB) asked the IVT to develop a universal dwell time calculation model. 1.2 Research objectives The research objective was to develop a dwell time calculation model that allows planners to predict station dwell time (mean and spreading) by entering the following input parameters: vehicle type (number, position, width and level of doorways), station infrastructure (platform level) and demand (number and distribution of boarding and alighting passengers). The output of the dwell time calculation model was defined as the time needed for a given number of passengers to board and alight the train at a specific stop. The model does not include the time needed to compensate for timetable margins (scheduled buffer times) or operational delays. 1.3 Paper outline This paper is structured as follows: Section 2 describes the dwell process and its sub-processes. Section 3 describes the data collection system used to evaluate the dwell process. Section 4 presents results of the statistical evaluation of subprocess times and their influence factors. Section 5 presents conclusions including a description of the dwell time estimation tool and recommendations for further research.
2
Analysis of the station dwell process
A train’s station dwell time is determined by the combination of the passenger boarding/alighting process, the door control system processes, and actions taken by the train driver and infrastructure operator (compare [1, 2]). There are two main parts of the station dwell process: passenger service time and train dispatching time. In order to separate the influences of the different actors the station dwell process was divided into the 5 sub-processes shown in Table 1.
Operations Analysis
Table 1:
107
Dwell time sub-processes.
Sub-process Door-unblocking (DU) Door opening (DO)
Location 1 Doorway 1 Doorway
Process Begins Train arrival Begin door opening
Boarding/alighting (BA) Door closing (DC)
1 Doorway 1 Doorway
Train dispatching (TD)
Whole Train
First passenger through the doorway Last passenger through the doorway Last door closed
Process Ends Begin door opening First passenger through the doorway Last passenger through the doorway Door closed Train departure
As illustrated in Figure 1, since there are usually two or more doors per train, the first part of the dwell process – the passenger service time – can be understood as parallel sequences of the sub-processes DU, DO, BA and DC at each vehicle door (q.v. [1]). Due to unequal passenger distributions using vehicle doors and the stochastic spread of sub-process times, the last closing door determines the passenger service time. After the last door has been closed, the dwell process continues with the train dispatching sub-process.
Figure 1:
3
Dwell time sub-processes.
Data collection: dwell time process measurement
3.1 Data collection requirements In order to estimate station dwell time, it is necessary to accurately measure the time needed to complete each sub-process in the dwell process and the number of passengers. These measurements must be very exact, many measurements are needed and they must be made in the complex operating environment of real-life
108 Timetable Planning and Information Quality dwell processes. Finally, all these data must be recorded for each vehicle door separately. Given these stringent requirements, the SBB’s automatic passenger counting system (AFZ) was modified and used for data collection. 3.2 Automatic passenger counting system (AFZ) The SBB uses automatic passenger counting systems on most of its regional lines to gather passenger counts and to estimate ticket revenues. Approximately 30% of the fleet is equipped with AFZ (vehicles are rotated to cover all lines). In normal operations the AFZ system registers the number of boarding and alighting passengers at each stop. The AFZ consists of chains of directionsensitive infrared-sensors above each doorway. These sensor chains are connected to a vehicle-wide network controlled by a central unit, which collects and stores the count data for the whole train over the course of the day. When the train arrives at its overnight storage yard these data are transmitted over wirelessLAN to a central database.
Figure 2:
Automatic passenger counting system layout (above/left), infraredsensors over doorway (middle) and server unit (right) (Source [3]).
3.3 Measurement parameters The AFZ system software had to be modified to record additional parameters (i.e. timestamps for each of the sub-processes) to obtain the data needed for the dwell time estimation model. Table 2 presents the parameters measured by the modified AFZ system used in this research. Table 2:
Dwell time parameters measured by the modified AFZ-system.
Per train Station ID Train arrival (timestamp) Train departure (timestamp)
For each door of the train Number of boarding passengers Number of alighting passengers Begin door opening (timestamp(s)) End door closing (timestamp(s)) First passenger through doorway (timestamp(s)) Last passenger through doorway (timestamp(s))
Operations Analysis
109
3.4 Data collection and validation The modified AFZ software was installed on 74 vehicles of 4 different types at the beginning of the data collection period. During the 8-month study period approximately 3.04 million dwell processes were measured and recorded. Table 3 summarizes the data collection by vehicle type. Table 3: Vehicle type DTZ FLIRT GTW 2/6 GTW 2/8
Dwell process measurements by vehicle type. Type series / manufacturer RABe 514 / Siemens RABe 523 / Stadler Rail RABe 526 / Stadler Rail RABe 526 / Stadler Rail
Measured dwell processes 821’488 1’078’352 655’574 489’204
After collecting the data it was validated using a plausibility check in which the binary raw data were checked for error messages. Next, the files with valid raw data were transformed by software scripts and written into a database following a specifically defined data structure for use in the dwell time estimation model. Finally, the valid data were evaluated and analyzed; results of this analysis are presented in the following section.
4
Station dwell sub-process time evaluation
4.1 Door unblocking sub-process (DU) The door unblocking (DU) sub-process time consists of the time period between the vehicle stopping in the station, as recorded by the train’s central unit, and the beginning of door opening process, signalized by the local door control system and recorded by each door unit. The door opening process is considered to have begun when all the following conditions are met: (1) vehicle speed must be below a predefined value, (2) the train driver must have activated the pushbutton door opening controls at the vehicle doors and (3) door opening has been requested by the passengers. New rail vehicles are often equipped with extensions that slide out at the doors to minimize the gap between the vehicle entrance and platform. The process of sliding-out the extension is an additional part of the DU sub-process: Due to safety restrictions this process cannot begin before the vehicle has stopped and it must be completed before the door begins to open. Figure 3 presents the cumulative curves of door unblocking times for three different vehicle types under two scenarios (boarding + alighting passengers, and boarding passengers only). The following conclusions can be drawn from this data for the DU sub-process: – Sliding extensions (present on vehicle types DTZ and FLIRT) cause median DU sub-process time to increase by between 2.9 to 3.5 seconds compared to vehicles with conventional entrances (vehicle type GTW).
110 Timetable Planning and Information Quality – –
Vehicles without sliding extensions are allowed to start door opening shortly before the train stops. Therefore these vehicle types can have negative DU sub-process times. Dwell processes with both boarding and alighting passengers have shorter median DU sub-process times (0.6 to 1.2 seconds) than dwell processes where passengers are only boarding. This is because alighting passengers may request door opening prior to train arrival in the station, but boarding passengers need time to reach the push-button door controls after train arrival in the station.
Figure 3:
Cumulative frequency distribution of DU sub-process times.
4.2 Door opening sub-process (DO) The door opening (DO) sub-process is the time from the start of door opening until the first passenger passes through the doorway. Figure 4 presents the cumulative curves of door opening times for the three vehicle types and two scenarios. The following conclusions can be drawn about DO sub-process times: – The DO sub-process times are essentially determined by the door width and control system. The difference in DO sub-process time between the vehicle types evaluated in this study is less than 1 second (the vehicle door widths were between 1.3m and 1.4m). – Dwell processes with both boarding and alighting passengers have shorter median DO sub-process-times (by up to 0.8 seconds) compared to those with only boarding passengers. The main reasons are that alighting passengers are standing closer to the doorway than boarding passengers after they pushed the door-open buttons and that the infrared sensor are located just inside the vehicle doorway.
Operations Analysis
Figure 4:
111
Cumulative frequency distribution of DO sub-process times.
4.3 Boarding/alighting sub-process (BA) The boarding/alighting (BA) sub-process is the time period of passenger flows at the doorway. In order to obtain comparable values the BA sub-process was evaluated based on mean passenger flow rates (the ratio between the number of passengers and the BA sub-process time) calculated using the measured data.
Figure 5:
Passenger flow rates for FLIRT vehicles with vehicle occupancy of less than 90%: measured flow rate (points), calculated mean (straight line) and mean+/-2*standard deviations (dashed lines).
112 Timetable Planning and Information Quality Figure 5 presents the mean passenger flow rates through the doorway compared to the number of boarding/alighting passengers for the FLIRT vehicles (which have level boarding). In Figure 5, each point represents one boarding/alighting process at a vehicle door. The average flow rate values and the standard deviations shown in Figure 5 were calculated based on these measurements and are displayed as a function of the number of passengers boarding/alighting. The following conclusions can be drawn from the passenger flow evaluation: – The evaluation confirmed results of earlier research (e.g. Weidmann [1]) that passenger flow at vehicle doors can be considered a normally distributed variable. – The mean passenger flow rate through the doorway increases slightly with the number of boarding/alighting passengers per door. – The standard deviation of the passenger flow rate decreases as the number of passengers boarding/alighting at each door increases. – A further data evaluation showed that the passenger flow rate decreases continuously with occupancy once vehicle occupancy reaches 60% of seats occupied. This reduction is caused by the increasing number of conflicts between standing and moving passengers inside the vehicle and on the platform (Nash et al. [4], Lee et al. [5]). 4.4 Door closing sub-process (DC) The door closing (DC) sub-process begins with the passage of the last passenger through the doorway. After a predefined vehicle-specific time period with no passengers boarding or alighting (“door remains open time”), the door begins closing. The sub-process ends with the door-closed-signal generated by the door control system. Note that this sub-process does not include retracting the sliding extension, at this point in time the sliding extensions are still in their extended positions. Figure 6 presents cumulative curves of door closing sub-process time. The following conclusions can be drawn from the door closing evaluation: – The large difference in DC sub-process times between vehicle types is mainly the result of the different predefined “door remains open time” for different vehicles. This variation shows that the door closing process should be more carefully analyzed and adjusted to passenger behaviour. – Dwell processes with boarding and alighting passengers have shorter median DC sub-process times (up 1.2 seconds) compared to those with only alighting persons. This can be explained by the relative positions of the AFZ counting sensor and the door closing control sensor and the walking direction of the last passenger. 4.5 Train dispatching sub-process (TD) The train dispatching (TD) sub-process considers the whole train and consists of the time period between the moment when the last train door has closed and the train departure. The regional trains observed in this study were operated without
Operations Analysis
Figure 6:
113
Cumulative frequency distribution of DC sub-process times.
conductors and therefore used an abbreviated train dispatching process executed by the train driver. The TD sub-process duration is determined by the following factors (1) the process times for: door-blocking, retracting the sliding steps (if necessary) and starting-up the traction motors, (2) the waiting time for the scheduled departure time (if any), and (3) the delay caused by operational conflicts (if any). Since these factors are highly dependant on the specific station, the spreading of TD sub-process times also depends on the station. Therefore, the dwell time calculation model was developed for stations where dispatching time is not significantly influenced by operational considerations. Operational considerations can be added to the model as required for a specific station.
5
Conclusions and further research
This research project has shown that passenger train station dwell time is determined by several different sub-processes taking place at each of the vehicle doors on a train. The project’s data collection system made it possible to accurately measure a very large number of dwell sub-process times and additional parameters at all vehicle doors on a train. These measurement data made it possible to quantify and precisely model the sub-process times with respect to the relevant influence factors. These data were used to develop a user-friendly dwell time calculation tool. It allows timetable planners to more accurately estimate station dwell time and use this information to develop more precise schedules.
114 Timetable Planning and Information Quality While the research advances understanding of the station dwell time process, it also points up the need for further research, specifically: • Correlation between passenger flow rate and parameters including: (1) doorway width, (2) level differences between platform/train entrance, (3) vehicle occupancy, and (4) vehicle interior layout. • The relationship between the distribution of passengers using specific vehicle doors and the following parameters: (1) the distances between vehicle doors, and (2) the location of 1st and 2nd class compartments. • The relationship between the distribution of boarding passengers on the platform and the station layout (number and location of platform access points).
Acknowledgements This research project was completed with support from the SBB. The authors appreciate the assistance and cooperation provided by the SBB project team without which it would have been impossible to achieve the project results.
References [1] Weidmann, U., Grundlagen zur Berechnung der Fahrgastwechselzeit, Institute Report No. 106, Institute for Transport Planning and Systems, Swiss Federal Institute of Technology Zurich, Zurich, 1995 [2] Heinz W., Passenger service times on trains – theory, measurements, and models, Licentiate Thesis, Royal Institute of Technology, Stockholm, 2003 [3] Dilax Intelcom, Passenger Counting Systems, Functional principle, http://www.dilax.com/en/index.htm?pages/pages/produkte/gesamt.htm [4] Nash, A., Weidmann, U., Bollinger, S., Luethi, M. & Buchmueller, S., Increasing Schedule Reliability on Zurich’s S-Bahn Through Computer Analysis and Simulation, Transportation Research Record #1955, Transportation Research Board, Washington D.C., pp. 17–25, 2007 [5] Lee, Y., Daamen, W. & Wiggenraad, P., Boarding and alighting behavior of public transport passengers. In Proceedings of the 86th Annual Meeting. CDROM. Transportation Research Board, Washington, D.C., pp. 1–14, 2007
Operations Analysis
115
Evaluation of punctuality on a heavily utilised railway line with mixed traffic O. Lindfeldt Division of Traffic and Logistics, Department of Transport and Economics, Royal Institute of Technology, Stockholm, Sweden
Abstract The Western Main Line (450 km) between Stockholm and Gothenburg is heavily utilised for mixed rail traffic. High speed trains are mixed with regional, local and freight trains and the congestion clearly affects the overall punctuality. In order to evaluate the possible total effects of reduced primary delays, the high speed operator, SJ AB, took the initiative to perform an extensive simulation study in RailSys, which was carried out by the Royal Institute of Technology. As preparation for this simulation study delay data was compiled for all trains using the line. This paper briefly discusses the ideas of stochastic disturbances in the simulation of rail operation and also the compilation methods for primary delay distributions. The resulting distributions from the Western Main Line were then analysed. It was clearly shown that the primary delays are extensive and have a high degree of variability. The paper ends with a discussion about the validation of the simulation model and possibilities to develop methods for more accurate stochastic modelling. Keywords: simulation, delay distribution, perturbations, mixed traffic.
1
Introduction
The demand for rail passenger traffic and freight transport is steadily increasing in Sweden and the utilisation has now become troublesome in many sections of the railway network. The Western Main line (450 km), connecting Stockholm and Gothenburg, is one of the most heavily utilised lines. On this line the traffic consists of an unfavourable mix of high speed (200 km/h), regional and local
116 Timetable Planning and Information Quality passenger trains and freight trains. There are many level crossings and numerous junctions with connecting trains resulting in strong dependencies between trains. Primary delays are frequent and due to the congestion these are often propagated to other trains in the proximity. Several sections of the line have such high utilisation that overall punctuality is affected negatively. The high speed trains are particularly sensitive to all kinds of disturbances and this is clearly reflected in the delay statistics. The operator of the high speed trains, SJ AB, has paid special attention to the punctuality problems. In order to evaluate the overall effects of reduced primary delays caused by the operator itself, including vehicle failures, an extensive simulation project has been performed by the Royal Institute of Technology. The simulation, performed in RailSys, included all trains on the Western Main Line. A reference case was defined as the autumn 2006 timetable period with 105 weekdays with the same timetable. Delay data from this period was used to produce delay statistics for the simulation. This extensive preparation work, including initial delays, as well as delays on every line section and dwell time extensions, generated important results in itself. In this paper the simulation method is described briefly as a background to the delay evaluation that is then treated in more detail. A simple method for isolating primary delays from total delays is discussed and statistics for initial delays, dwell time extensions and run time extensions are presented. The paper ends with some conclusions and ideas for future work on heavily utilised railway lines with mixed traffic.
2
Method and modelling
The idea of the project was to evaluate the effect of reduced primary delays, first and foremost for the high speed trains. To do this, the infrastructure of the line was built up in RailSys and the reference timetable, with approximately 900 trains, was applied. 2.1 Model The delays in rail operation may be subdivided into groups according to the source. In Sweden delays are often divided into: • Infrastructure related delays • Operator related delays • Vehicle related delays • Other, not specified delays • Secondary delays These groups are used in the report system (TFÖR), where the causes of delays longer than four minutes are reported manually by the dispatchers. These reports were used to subdivide the delays (see the next section). In this project the first three groups were of special interest. Infrastructure failures cause primary delays to all types of trains, whereas operator and vehicle related delays primarily affect the trains of the operator concerned.
Operations Analysis
117
Stockholm Katrineholm Hallsberg Skövde
Flen
Järna
Laxå
Falköping Herrljunga
Alingsås
Göteborg Gothenburg
Figure 1:
Western main line.
All primary delays were modelled as independent perturbations in the simulation. However, this is a simplification compared to real situations and careful validation is therefore required, during which steering parameters such as dispatching rules etc are adjusted. In the simulation all kinds of deviations from the timetable were handled through disturbances generated by delay distributions. This means, for example, that all infrastructure sections (points, signals etc) were assumed to be available all the time. The effect of infrastructure failures was instead caught by run time extensions given by applied distributions. This type of indirect modelling naturally assumes that the applied distributions contain only primary delays. 2.2 Isolation of primary delays In the train operation database (TFÖR) all trains are registered at each station. The registered time is compared to the scheduled time and the deviation is stored in the database, making it possible to compile delay distributions and other statistics from historical data. This was done for all trains during the timetable period (autumn 2006). The passenger trains were treated in groups according to patterns given by basic interval timetables, whereas the freight trains were analysed individually in the first step and then grouped according to mean and variance. In order to distinguish between different types of delay causes, the reports of causes were used to separate different delay types. This work resulted in primary delay distributions for each group of trains. The method was also used to exclude selected parts of delays caused by infrastructure, operator and vehicle respectively. This was a preparation for the simulations that evaluated the effect of specific reductions of primary delays.
118 Timetable Planning and Information Quality This type of reduction of delay data faced two major problems: • Accuracy of the manual delay reports • Lack of reports for delays shorter than five minutes. No other sources of information about the delay causes were available and the reports were therefore accepted without further investigation. The lack of information about delays shorter than five minutes was handled in a special way. The secondary delays between three and five minutes were assumed to have the same proportion to the total delays as in the 5-9 minutes’ delay interval. All delays of 1-2 minutes were assumed to be primary. This way of estimating delays is probably a rough assumption that should be examined carefully before it is more widely used, but was assumed to be an acceptable first approximation.
3
Disturbances
The stochastic part of the rail operation was modelled in RailSys by three different types of disturbances: • Initial delays • Run time extensions • Dwell time extensions The first two were derived from historical delay statistics as described above, whereas dwell time extensions were estimated by measurements on platforms. 3.1 Initial delays Initial delays were compiled for all trains at their first station on the studied line. Trains belonging to the same basic interval timetable-concept were treated as a group. Fig. 2, 3 and 4 show the result when each distribution is represented by its mean and standard deviation values. 900 800
Standard deviation [s]
700 600 500 400
High speed trains Regional east
300
Regional west 200
Local east Local west
100 0 0
50
100
150
200
250
300
350
400
450
500
550
600
Mean [s]
Figure 2:
Characteristics of passenger trains’ initial delays.
Operations Analysis
119
Standard deviation [s]
1000
800
444
446
600
400
200 420, 424, 438 400
0
422
0
100
200
300
400
500
600
Mean [s]
Figure 3:
Characteristics of individual high speed trains. Each point represents one train. Some trains are labelled with their train number. 3000
Standard deviation [s]
2500
2000
1500
1000
500
0 0
500
1000
1500
2000
2500
3000
Mean [s]
Figure 4:
Characteristics of freight trains’ initial delays.
Fig. 2 shows that the high speed trains have the worst punctuality of the passenger trains. Both mean delay and standard deviation are high for the most important high speed train groups. A few high speed train patterns have better distributions, located closer to the origin. Unfortunately, most of these groups consist of single peak hour trains travelling to or originating from smaller cities near to the Western Main Line. Regional trains running on the eastern part of the line show high delays. This is partly explained by systematic vehicle problems during the timetable period,
120 Timetable Planning and Information Quality but also by congestion effects in the Stockholm area. Regional trains running on the western part of the line and local trains show less delay. In order to show that the trains within one and the same group behave differently the distribution for each individual train (105 observations) was compiled. Fig. 3 shows an example of this: up-going high speed trains from Gothenburg to Stockholm. Typically, trains running early (numbers 400 and 422-424) have less delay than trains running late (numbers 444 and 446). Possible explanations for this are accumulation of delays due to low time supplements and short turnaround times compared to the overall delay level combined with a higher capacity utilisation in the afternoon. In the simulation the whole group was represented by a distribution indicated by the larger diamond in the middle. The freight trains were evaluated individually, see fig. 4, and then grouped into six groups according to mean and standard deviation. In this compilation trains that arrived early were treated as on-time trains. As can be seen from the figure, some trains have clear punctuality problems. Only the first group, consisting of mail trains etc, show the same levels as the passenger trains. 3.2 Run times All kinds of primary delays occurring between ordinary passenger stops (origin and destination station for freight trains) were modelled as run time extensions. To apply this idea, the line was divided into 13 sections, each approximately 35 km long. For each section, direction and train type, a distribution for the extension was compiled from delay data. 1200
Standard deviation [s]
1000
800
600
400
High speed trains Other passenger trains
200
Freight trains
0 -50
0
50
100
150
200
250
300
Mean [s]
Figure 5:
Characteristics of run time extensions: 3 train types, 2 directions and 13 sections.
This was done through comparison of the arrival delay at the end station of each section and the departure delay at the first station. Delay cause reports were used to exclude secondary delays in the same way as described previously.
Operations Analysis
121
In some cases the mean extension was found to be negative, which means that the trains on these sections, on average, run faster than their timetabled run time. 3.3 Dwell times Different types of primary delays also occur in connection with ordinary passenger stops. To examine and model these effects SJ AB performed manual measurements of passenger stops for high speed trains. This empirical data was then fitted to lognormal distributions with quite good agreement. The dwell time may be subdivided into two parts: exchange time, i.e. the time that is needed for door opening, alignment and boarding, and technical time for door closing. Fig. 6 shows the resulting distributions for the exchange time. To this exchange time a shortest technical time must then be added, which is vehicle dependent and was measured to be 30 seconds for the high speed vehicle X2. The bold vertical line represents the remaining timetabled exchange time when the technical time is subtracted from the timetabled dwell time of two minutes. It is clearly seen that the stops at Skövde (Sk), having the highest mean and standard deviation values, often exceed the timetabled dwell time (30-35% of the cases), whereas the timetabled time is much better adjusted in Södertälje (Söö). At stations like Skövde, with a high variance in exchange time, it becomes quite difficult to choose a feasible timetable dwell time that works. 1 0.95
Söö down Söö up K down K up Sk down Sk up
0.9 0.85 0.8 0.75
Cumulative share
0.7 0.65 0.6 0.55 0.5 0.45 0.4 0.35 0.3 0.25 0.2 0.15 0.1 0.05 0
0
30
60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540 570 600
Exchange time [s]
Figure 6:
4
Distributions for passenger exchange time at three different stations.
Results and validation
Altogether, the compilation work resulted in 40 different empirical delay distributions that were used to validate the reference case. In the iterative
122 Timetable Planning and Information Quality validation process, simulated results were compared to real delay statistics for several stations along the line. The validation focused on the high speed trains. Adjustments were made regarding: • Dispatching priorities between different train types • Trains’ possibilities to make up delays by using timetabled supplements • The highest values of run time extensions. In Sweden a kind of “On-time-rule” is used when conflicts occur between different trains. This dispatching rule implies that a train that follows its timetable is to be prioritised over a delayed (conflicting) one. The high speed trains therefore also risk additional (secondary) delays once they are delayed. A general experience from simulations in RailSys is that trains often make up delays using timetable supplements. The idea of run time extensions is to balance this effect. Despite a large number of run time extensions the possibilities to make up delays had to be limited on some line sections to obtain an acceptable agreement. The highest values of run time extensions (> 30 minutes) turned out to be unrealistically high, causing more secondary delays in the simulation than in reality. Values over 30 minutes were therefore excluded from the run time extension distributions. 100%95%
95%
90%95%
94%
93%
92%
89%
89%
85%
90%
80%
84%
83%
84%
70%
80%
84% 83%
83%
83%
80%
81%
81% 77%
73%
78% 73%
72%
71% 71%
60% 50%
Real
40%
Simulated
30% 20% 10% 0%
G dep
Figure 7:
Sel dep
A dep
Hr dep
F dep
Sk dep
Lå Hpbg K dep dep dep
Fle dep
Gn dep
Söö dep
Flb dep
Cst arr
Example of validation results. Departure punctuality (≤ 5 min) for real and simulated up-going trains from Gothenburg (G) to Stockholm (Cst).
Fig. 7 shows an example of validation results. Despite calibration efforts the simulated result is significantly better than the real one. A sample of trains from other train groups was also tested in order to check that also these were also modelled properly.
Operations Analysis
5
123
Conclusions and further work
This work showed that it is possible to model most of the stochastic behaviour of rail operation using three types of disturbances: initial delays, run time extensions and dwell time extensions. This method means a gathered approach where all kinds of stochastic behaviour are represented by a few distributions. In order to examine the contribution of specific sources of disturbances it is therefore necessary to find out how different sources contribute to these collected distributions. This is a natural step for further evaluation. Such a separation was also performed within this project and the validated model was then used to examine effects of reduced primary delays. The main results from this examination was that the high speed trains constitute such a limited share of the total number of trains, that reduced primary delays for just these trains does not affect overall delays very much. The work also resulted in a deeper understanding of the delay situation on one of the most important lines in Sweden as regards both train groups and individual trains. A simplified validation method using only one point of the delay cumulative distribution function (5 minute delay level) was applied in this project. A natural way to make the validation more accurate is to compare several points of the distributions and/or to compare means and standard deviations. The validation should also involve more than one train type. A check of the slower freight trains would reveal how the model treats trains with different features in dispatching situations.
Acknowledgements This paper is an attempt to present some ideas for the important preparatory work with disturbance data which precedes all rail operation simulations. The simulation commissioned by SJ AB provided a good opportunity to learn more about delay statistics and compilation of disturbance data.
Reference [1] Nelldal, B-L.et.al., Förbättrad punktlighet på X2000 – analys med hjälp av simulering, KTH 2007
This page intentionally left blank
Operations Analysis
125
Automated analysis of train event recorder data to improve micro-simulation models S. de Fabris, G. Longo & G. Medeossi Department of Civil and Environmental Engineering, University of Trieste, Italy
Abstract In recent years, on board digital train event recorders have been developed: these devices allow the collection of very detailed data about train movements and signal status. The new Italian ATC SCMT on board subsystem is combined with the DIS (Driver Information System), which collects both kinetic behaviour and all signal and balises messages. Unfortunately, this large amount of data is normally stored, but not used except for failure and maintenance management. At the same time the use of micro simulation tools has been extended to large scale problems. As is known, a problem exists in the calibration and validation of these models. In this paper a new tool is presented. This tool allows the analysis of real-life collected data, to perform very detailed analysis of train movements, pointing out speed depending on position and signal aspects, acceleration, braking curves and dwell time graphically and by means of parameters. Train behaviour can also be connected to punctuality, to find out differences between on time and late running. This tool may be very useful for large scale model validation, definition of the stochastic behaviour of the system (travel time, dwell time, initial delay), calibration of braking and acceleration curves for various train types and acceleration percentage depending on different conditions. In other words, it allows a link to be set up between real data and micro simulation models. The tool has been tested in the north-eastern part of Italy. In this case study a significant precision increase in the stochastic simulation results has been reached. Keywords: railway simulation, railway planning, train event recorder.
126 Timetable Planning and Information Quality
1
Introduction
An efficient train operation is a primary success factor for all infrastructure managers since it allows operating a higher number of trains without significant infrastructure investments. In the last few years, railway simulators have become a very powerful instrument to support the different steps of the planning process: from the layout design to capacity investigations, and offer model validations. More recently, the possibility of an automatic import of infrastructure layouts and timetables has widened the application spectrum of micro-simulators to large nodes and to more detailed stochastic stability evaluations. Stochastic micro-simulators perform very detailed robustness analysis, considering all processes involved in rail traffic and comprehending not only its deterministic aspects, but also human factors and other stochastic phenomena. This is particularly relevant in order to simulate traffic under realistic conditions, considering variability at border (initial delay), various driving styles and stop times. All these parameters have to be calibrated using real-world collected data for single trains or train families, considering their different behaviour in the network and at its border. Infrastructure operators have developed various tools to analyze these operational data, considering all track circuits or only timetabling points. In both cases trains are checked at discrete points, not allowing a continuous reconstruction of train movements. In this way, on-board collected data represent an ideal input to investigate the behaviour of trains, from acceleration to braking and precise stop times. Stochastic micro simulation is being widely introduced in Italy by RFI, the infrastructure manager of most lines, to evaluate timetable robustness in future scenarios and during infrastructure improvement works in the busiest nodes, like Rome, Florence, Milan, Venice, Naples and Bologna. To improve the precision of input parameters a new tool has been developed that combines both timetabling point data and the on-board collected data, coming from the newgeneration train event recorder recently installed on all trains running on RFI network.
2
The driver information system (DIS)
To improve rail traffic security by a continuous collection of train behaviour data, in 1998 the Italian Ministry of Transportation decided to fund the development of a new generation train event recorder to be installed on all locomotives, trains and driving coaches. Prior requirement of the system was a very high precision in all records, comprehending not only speed and odometer, but also messages from the balises, GPS location and a large amount of data coming from the vehicle-bus. After an exhausting test and validation phase, the DIS has been installed since 2004, and is now fully operating on most lines. The system is formed by an on-board subsystem that collects data and sends them automatically to the depot subsystem when it passes by one of them, data are stored in a file system archive, accessible from authorised operators all over
Operations Analysis
Figure 1:
127
Scheme of the Driver Information System.
Italy. The on board subsystem is formed by a speedometer, an event recorder, a communication computer and an IEEE 802.11 transmission protocol radio and a simplified user interface. Using data collected from two odometers, the speedometer calculates the speed and the covered distance, taking into account the real wheel diameter. These data are continuously sent to the event recorder. Before starting a new service, drivers must insert their smartcards into the MMI and type train number, speed type, train length and braking weight percentage. These are used for both data collection and braking curve calculation in the ATC subsystem. Data coming from the speedometer, the GPS, the user Interface and the vehicle MVB Bus, coupled with GMT timing are stored in a solid-state-drive every 100 ms. When a train reaches a given GPS position nearby a depot, the communication computer starts a data link with the server and uploads the past files.
3
The “TRENO” tool
The large amount of data stored is actually only used by Trenitalia as a failure archive and for maintenance, or in the event of accidents. With TRENO (Timetable Reliability and Network Operations analyser), these archives may be used as very precise support to understand rail traffic. The tool is based on a POSTGRES SQL DBMS; it integrates track occupation data coming from the Infrastructure Manager RFI, the planned timetable of different scenarios and the DIS recordings. This integration allows a macroscopic analysis of train traffic and a microscopic focus on selected trains or stations; the planned timetable of the whole network is used to select different days and lines and as a basis for the export to Opentrack micro-simulator.
128 Timetable Planning and Information Quality
Figure 2:
Data flows to and from TRENO.
RailML stochastic simulation files can also be imported in the tool as new scenarios that can be stored and be analysed with the Macro-Analyser, in order to evaluate the robustness of different timetables, or the advantages of infrastructural improvements. Figure 2 shows TRENO’s structure. The “Planned” module allows one to import or create planned timetable scenarios. RFI data containing whole Italian network timetable can be coupled with user-defined scenarios. A simple Infrastructure model is also contained to support corridor analysis and to allow running time calculations. Timetables can be exported as RailML file for any line section and day/time. In the “Macro” module, conventional departure, travel time and stop time distributions can be plotted and analysed. Moreover their parameters may be calculated. Graphical timetable with various display options is another possible output. Simpler parameters like mean values, piecewise linear distributions or percentage areas are also shown to be used in micro simulation. Mean registered stop-time supplement to the planned one is automatically added to the RailML planned timetable file for each stop of the single train to be imported in the micro-simulator. Maximum supplement for the train family is estimated, since in the used micro-simulator stop time variability has at the moment no other inputs option than the stochastic combination of these parameters. The module is completed by a critical element search function that allows one to select trains, stations and line parts on the basis of given delay parameters. The “micro” module is widely presented in the next paragraph.
4
Microscopic analysis
The real life registered files can be used for a very wide range of detailed analysis of train movement, also considering signal status and system failures.
Operations Analysis
129
The very high precision of stored data and the large amount of additional information require a filtering process to point out failures and traffic perturbations that have influenced a train movement. Moreover, the 100ms interval between measurements has to be reduced to 1 second in order to obtain faster processing and easier data aggregation. This filtering process is performed automatically when files are imported in the database; failures are also stored in different tables as well as balises messages reporting signal status; speed limits and ATC-calculated braking curves are also archived to enable analysis in the event of maintenance speed reductions. ATC balises messages enable considering primary and secondary delays separately, since restrictive signal status are pointed out. At the moment, these have not been used to perform delay propagation analysis, since the study has focused on the behaviour of single trains or train families and not on traffic as a whole. In other words, excluding trains with failures or with non-free trajectories in the focus area is a basic principle to extract train trajectories as allowed by infrastructure and timetable and as required to calibrate motion equation parameters. The module can analyze stop times at each station, acceleration, full speed and braking phases separately. For each focus various two and three dimensional diagrams are provided, including statistic parameters representation or fitted density curves. 4.1 Stop times The use of event recorder data allows a precise definition of stop time from the speed profile; door opening and closing is also stored to estimate the train preparation time. A separation between punctual and delayed trains is also possible, to point out both minimum dwell time and departure imprecision, often significant in Italy. All distributions can be viewed in diagrams with optional aggregation intervals. Statistic parameters are calculated, and negative exponential, Weibull, log-normal and gamma density fits are performed. 4.2 Acceleration and full speed behaviour Acceleration is investigated by choosing a station, a trainset and a time/date interval and then by loading relative data on a diagram. Time speed, distance, time and acceleration can be selected on x- and y- axis; each single day train running is shown. To represent distributions better, these are shown in threedimensional diagrams. Since an automatic fitting has not been provided yet, the software is endowed with a running time calculator that integrates motion equation calculating the best acceleration curve based on the maximum tractive effort F for the train. This is reduced to its measured values by two coefficients, obtaining a new Fr:
F t =F× f 1 × f
2
(1)
130 Timetable Planning and Information Quality The curve based on F can be graphically fitted as upper bound of real ones, obtaining the best performance rate f1. Once this first value has been fixed, its variability as piecewise linear probability function is calculated, obtaining a second performance factor f2 , on the basis of running time distribution to cover a distance D. D and f2 intervals are defined by the user, the corresponding time values ti are calculated automatically. The resulting parameters and their distribution are stored in a table and compared for all stations. Acceleration analyser window is shown in Figure 3.
Figure 3:
Acceleration analysis.
Full speed behaviour is also investigated in a similar module. In this case, two stations or kilometre points must be chosen; this allows representing longer line sections. Realistic trajectories are obtained with f1f and f2f parameters to scale the maximum speed. Coefficients are calculated as in the acceleration module; and saved in the same table with acceleration factors to support the choice of parameters to be used in micro-simulation. 4.3 Braking behaviour In both running time and ATC braking curve calculation algorithms, only the BWP is used as input. In TRENO, braking behaviour of a train type can be aggregated and fitted to a linear function depending on BWP. To reproduce the real train behaviour better, a braking rate table can be defined. Braking actions can be analysed in a window similar to the ones used for acceleration and full speed; f1b and f2b parameters similar to f1 and f2 are calculated as braking performance parameters. Otherwise, using f1 and f2, BWP
Operations Analysis
131
or the braking rates are calculated. In this case, f1 and f2 can be used as performance factor for the complete motion modifying train braking formula.
5
A case study: Trieste – Venice
TRENO has been used to analyze the traffic in north-eastern Italy, on the Trieste – Venice line. The double track, electrified line is about 130 km long and plays an important role in regional transport and as a freight corridor between eastern Europe and Italy. Figure 4 shows a simple layout of the line; the analyzed network was extended to approximately 30 km on each branch line, obtaining totally 280 km line. After performing the macroscopic analysis, the study has focused on evaluating behaviour of trains in non-disturbed conditions, to estimate a standard performance percentage and a piecewise linear braking function for every train type. Performance variability has also been defined as piecewise linear by fitting it to real distributions, as well as initial delay for every train family. Since DIS data were not available before starting the study, on-board registered GPS speedtime data have been used, for testing purposes. Stop time, represented by a mean time and a variability range, as defined in RailML standard, has been automatically exported for every train and station. Udine
Treviso
Venezia
Casarsa
Portogruaro
Figure 4: Table 1:
Trieste
Cervignano
Simple topology of the Venice – Trieste line layout.
Comparison between stochastic simulations. Calibration parameters source: Scen. 1-4 timetabling points, Scen. 5 Collected data. Stochastic Parameters Initial Delay
Running Time
Stop Time
1
Yes (neg. exp)
No
No
2
Yes (neg. exp)
Yes
3
Yes (neg. exp)
4 5
Scenario
Slovenia
Udine
DIS calibrated Braking
Results 1’ [%]
3’ [%]
Mean [s]
No
14.1
11.3
68
No
No
12.8
9.5
59
Yes
Yes
No
9.8
7.2
51
Yes (pie.lin.)
Yes
Yes
No
7.2
5.3
40
Yes (pie.lin.)
Yes
Yes
Yes
5.3
2.9
22
132 Timetable Planning and Information Quality The results of 100 stochastic simulations have been analyzed with the Macro tool and compared real data referred to 100 days. Different simulation scenarios have been considered with growing calibration precision to point out the importance of various distributions and of micro and macroscopic analysis. In the first scenario only departure delay as negative exponential function per train family have been considered, then, in the second scenario, performance variability as empirically evaluated by timetable planners has been added. In a third phase stop time variability has come and in a fourth one departure delays have been modelled using a piecewise-linear function. Scenario results have been compared using three simple punctuality parameters, similar to quality indicators commonly used in performance measurements. For each train, the difference between the percentage arriving at each station within 1, within 3 minutes and the mean delay in real and simulated data has been calculated; the mean differences on all trains and for each indicator are shown in table 1. A significant precision increase has been obtained in each scenario, showing that: - Negative exponential initial delay can be used only as first step; - Departure variability at all stations is the most important parameter for stopping trains; since it’s often very different for various services and train types the automatic import function is very useful; - Running time variability is important for long distance and freight trains; On-board collected data effectively allow a better estimation of stop type and train performance parameters; even better results could be obtained by a recalibration of some more specific resistance factors. In fact trains accelerate with lower performances than expected and then they run very close to the speed limit, forcing to choose mean parameters that do not represent both situations at best. Moreover, some trains accelerate faster than estimated with the running time calculator, but brake with no more than 50% of their theoretic maximum. (Fig. 5, 6)
Figure 5:
Recorded speed v(s) profile at departure compared to calculated curves with different performance factors (smooth curves).
Operations Analysis
Figure 6:
6
133
Recorded speed profile v(t) at arrival compared to calculated curves with different performance factors (straight lines).
Conclusions and further research
TRENO has been developed to perform both macro and microscopic analysis of train traffic, as system investigation support and as semi-automatic calibration tool for many simulation parameters. On-board recorded data are the key element to increase precision of traffic studies, pointing out the behaviour of drivers and trains under real conditions. The case study has shown a significant improvement in the stochastic micro simulation output, demonstrating the importance of a precise parameter calibration especially regarding train braking and acceleration. A further improvement will come from the calibration of the motion equation parameters to fit the DIS data. The tool is being continuously upgraded, to make it easier to use and to improve statistic analysis on DIS data and to analyse complete train trips. New functions will also be inserted to enlarge the amount of used data. This regards both driving parameters coming from the vehicle bus (e.g. throttle, brake use) and signal status, to study driver behaviour in presence of restrictive signals and to calculate block occupancy.
References [1] Albrecht, T., R.M.P. Goverde, V.A. Weeda & J. van Luipen, “Reconstruction of train trajectories from track occupation data to determine the effects of a Driver Information System”. In: Allan, J., Hill, R.J., Brebbia, C.A., Sciutto, G., Sone, S. (eds.), WIT Press, Southampton, pp. 207-216, 2006.
134 Timetable Planning and Information Quality [2] Allotta B., Toni P., Malvezzi M., Presciani P., Cocci G., Colla V., “Distance and speed evaluation from odometric measurements,” Proc. of World Congress on Railway Research, Koeln 2001 [3] Goverde, R.M.P., Hansen, I.A.,“TNV-Prepare: Analysis of Dutch Railway Operations Based on Train Detection Data”, In: Allan, J., Hill, R.J., Brebbia, C.A., Sciutto, G., Sone, S. (eds.), Computers in Railways VII, WIT Press, Southampton, 779-788, 2000 [4] Huerlimann, D., Nash, A., “Railway simulation using Opentrack”, In: Allan, J., Hill, R.J., Brebbia, C.A., Sciutto, G., Sone, S. (eds.), Computers in Railways IX, WIT Press, Southampton, 45-54, 2004 [5] Huerlimann, D., “Object-oriented modelling in railways”; ETH Dissertation Nr. 14281; (in German), 2001 [6] Nash, A., Ullius M., “Optimizing railway timetables with OpenTimeTable”, In: Allan, J., Hill, R.J., Brebbia, C.A., Sciutto, G., Sone, S. (eds.), Computers in Railways IX, WIT Press, Southampton, 637-646, 2004 [7] Yuan J., Goverde R. M. P., Hansen I. A., “Evaluating stochastic train process time distribution models on the basis of empirical detection data”, In: Allan, J., Hill, R.J., Brebbia, C.A., Sciutto, G., Sone, S. (eds.), Computers in Railways X, WIT Press, Southampton, 631-640, 2006 [8] Malara V., “Security systems to support train drivers ” published by Collegio degli Ingegneri Ferroviari Italiani, Roma, 2005 (in Italian) [9] de Fabris S., Longo G., Medeossi G., “Stochastic analysis of train traffic to improve timetable planning”, ICTS 08 Conference Records, Portoroz, Slovenia, 2008
Part C Rescheduling
This page intentionally left blank
Rescheduling
137
Optimal train control at a junction in the main line rail network using a new object-oriented signalling system model R. Takagi1, P. F. Weston2, C. J. Goodman2, C. Bouch3, J. Armstrong4, J. Preston4 & S. Sone1 1
Department of Electrical Systems Engineering, Kogakuin University, Japan 2 Rail Research UK, School of Engineering University of Birmingham, UK 3 Rail Research UK, School of Engineering (Civil Engineering), University of Birmingham, UK 4 Rail Research UK, Transportation Research Group, School of Civil Engineering and the Environment, University of Southampton, UK
Abstract On a main line railway network with many junctions, the delay of a train is likely to cause delays to many other trains, especially because of conflicts at junctions. Optimising one junction, however, may have an adverse effect on other parts of the rail network because of the mixed-traffic situation of most main line railways. To approach the complicated problem of optimal re-scheduling in response to the delay of a train, an efficient algorithm must be sought. The authors have taken a junction as an example, and have performed numerical optimisation on a case when the services through this junction are disrupted. The objective criterion is the weighted sum of train times. The optimisation program uses the Object-Oriented Multi-Train Simulator (OOMTS) developed by Birmingham University, as an embedded simulator. In the optimisation routine, a Genetic Algorithm (GA) was used to optimise the order of route setting. In this paper, the authors give details of a model junction, and a brief explanation of the OOMTS. The authors then explain how a GA can be applied to solve this problem, especially the chromosomal expression of the problem. The results of numerical optimisations for different weighting parameters are shown based on which the authors discuss the feasibility of the proposed method. Keywords: object-oriented, multi-train simulator, railway signalling, junction, train pathing, optimisation, Genetic Algorithm.
138 Timetable Planning and Information Quality
1
Introduction
On a main line railway network with many junctions, the delay of a train is likely to cause delays to many other trains, especially because of conflicts at junctions. Junctions without flyovers, as are commonly seen in the British rail network, tend to make matters worse. Also, most main line railway lines run mixed traffic with a combination of fast and slow trains, making the junction management even harder. Therefore, controlling a junction in response to a disruption by minimising the accumulated delay over a sequence of trains at that point may still have serious adverse effects elsewhere in the rail network. Thus, the problem of optimal re-scheduling in response to a delay of a train is computationally a difficult task, and an efficient algorithm must be sought to approach this problem. In an attempt to address this problem, the authors have taken a junction as an example, and have performed numerical optimisation on a case when the services through this junction are disrupted. The junction that has been used for the study is Abbotswood Junction on the Birmingham to Bristol Line in the National Rail network of the UK. The optimisation program uses the ObjectOriented Multi-Train Simulator (OOMTS) developed by Birmingham University [1], as an embedded simulator. In the optimisation routine, a Genetic Algorithm (GA) is used to optimise the order of route setting.
2
OOMTS: an outline
The first version of the Object-Oriented Multi-Train Simulator (OOMTS) at the University of Birmingham was written by Siu [2] in the early 1990s. The logic of the program is based on a previous Fortran version [3], under constant development since 1973 and used by many rail operators and manufacturers around the world. The model implemented in OOMTS comprises of five “subsystem managers” [4], each containing data (or the instances of objects necessary for running the simulation) for a railway “subsystem”. The Simulation Manager is at the top of the structure, managing all these subsystem managers and the actual running of the simulation itself. The following are brief explanations of the five subsystem managers: 1. Network Manager: This subsystem manager holds instances of objects containing data for the topography and track profile (gradient, curve radius and line speed) of the rail network to be simulated. 2. Signal Manager: This subsystem manager holds instances of objects containing data for the signalling system. 3. Rolling Stock Manager: This subsystem manager holds data for the types of rolling stock to be used in the simulation. 4. Power Network Manager: This subsystem manager holds instances of objects for the electric power supply system. 5. Train Service Regulator: This subsystem manager holds instances of objects containing data for various aspects of train services, including timetable information.
Rescheduling
139
OOMTS was originally designed and tested for metro lines and suburban lines, for example the Island Line of Hong Kong's MTR Corporation, and has successfully been used by researchers at the University of Birmingham, latterly within Rail Research UK, the universities’ centre for railway systems research [5].
3
The model used in the optimisation
Abbotswood Junction, on the Birmingham to Bristol Line in the UK, is used as the model on which the optimisation was performed. DOWN GOODS LOOP DOWN MAIN
Route G26A Route G26B
ST E
R
UP
W OR
CE
ST
Route G126
Route G59A
ER
To Birmingham
CE
To Bristol
Route G59B UP MAIN
To
W
s ce or
ter
Abbotswood Junction
DN
W OR
Route G128
Figure 1:
Abbotswood Junction with six possible routes.
Figure 1: shows the schematic of the junction. The Birmingham to Bristol Line is double track, and a single track branch line from Worcester joins here. Another feature of this junction is the Down Goods Loop, which allows passenger trains from Birmingham to Bristol Line to overtake a freight train. There are six possible routes for trains, and no reversing of trains is allowed. The junction is modelled using the actual detailed data of the signalling system that is currently in use. This detailed data also covers the nearby part of the network, namely: 1) about five kilometres from Abbotswood Junction towards Birmingham, 2) about five kilometres from Abbotswood Junction towards Bristol, and 3) about 500 metres from Abbotswood Junction towards Worcester. For the optimisation study, ten kilometres of double-track have been added to both the Birmingham and the Bristol end of the Birmingham to Bristol Line track data, and one kilometre of double-track has been added to the Worcester end of the branch line data. Virtual stations are defined at the far ends of each of these tracks, and trains are assumed to travel between these stations.
140 Timetable Planning and Information Quality Figure 2: shows the assumed schedule of trains run through Abbotswood Junction. The trains involved are: one freight train on the Down Main track from Birmingham to Bristol; three passenger trains each for both Down and Up Main lines between Birmingham and Bristol; and three passenger trains each for both Down and Up Worcester tracks between Worcester and Bristol.
(for Worcester) Abbotswood Junc. (for Birmingham)
0
10
20
30
time [minutes] 40 50
60
70
80
Abbotswood Junc.
freight train
(for Bristol)
Figure 2:
Assumed schedule of trains including one freight and twelve passenger trains.
(for Worcester) Abbotswood Junc. (for Birmingham)
0
10
20
30
time [minutes] 40 50
60
70
80
delayed freight train Abbotswood Junc.
(for Bristol)
Figure 3:
Result of applying “first-come, first-served” junction control with a 30-minute delayed freight train.
Rescheduling
4
141
Assumed incident and the response by the non-optimal controller
The authors have assumed that the departure of the freight train is delayed for 30 minutes, causing the following Birmingham to Bristol passenger services to suffer reactionary delays. Figure 3: shows the result of applying “first-come, first-served” type control, which is by no means optimal in this situation. Because the freight train is not scheduled to use the Down Goods Loop at Abbotswood Junction, the slow freight train causes more delay to the subsequent passenger trains at their destinations. There is also room for improvement by re-ordering passenger trains. It is obvious that, provided the passenger trains have at least as high a priority as the freight train, the optimal solution must include the use of the Down Goods Loop by the freight train, which will enable one or more passenger trains to overtake the freight train. Then the decision must be made as to which of the following passenger trains should overtake the freight train.
5
Application of Genetic Algorithm
The authors have applied a Genetic Algorithm (GA) [6, 7] to identify the optimal control strategy for this situation. To apply a GA to any optimal control problem, one has to express the control inputs as a “chromosome”, for which an evaluation can be given. For the most basic variation of GA, known as Simple GA (SGA), a chromosome must be a fixed-length binary sequence. Also, one has to define genetic operators; in the case of SGA they are mutations, crossovers and selections. In the problem of train control at junctions, the control inputs are the setting of routes. The fitness of a particular routing sequence will be based on the time intervals between the scheduled departure times and the simulated arrival times, with weighting according to train priority. Here, it is assumed that the departure times and the performance of trains are given, which means that a set of control inputs can be defined as the order in which routes are set. One possible chromosomal expression, therefore, is the queue of routes; one example in the case of Figure 1: is (G26A, G26B, G128, G126, G59B …). However, using the queue of routes as the chromosomal expression has disadvantages. In the case of Figure 1:, if the head of the queue is G26A and the first train to arrive on the Down Main track from Birmingham is a passenger train (not allowed to go into the goods loop), then the system comes to a deadlock situation. Also, if there is already a train in the goods loop and the head of the queue is G26A, then the system comes to a deadlock situation because two or more trains are not allowed to be in the goods loop at the same time. To avoid these disadvantages, the authors propose the use of a state-space trajectory as the chromosomal expression. In terms of control of railway junctions, the state of the rail network can be expressed as the queue of trains on any of the tracks that connect junctions. In the model used in this paper, the order
142 Timetable Planning and Information Quality in which trains arrive at Abbotswood Junction is fixed, and the state expression can be simplified to a combination of four integers, as shown in Figure 4:. Using this state expression, a chromosome can be defined as a sequence of system states, starting from the initial state, (A, B, C, D) = (4, 3, 6, 0), and ending at the final state, (A, B, C, D) = (0, 0, 0, 0). A change from one state to another indicates that a route is set. For example, in Figure 1:, the change of state from (4, 3, 6, 0) to (3, 3, 6, 1) means that the route G26A is set. Taking constraints into consideration is easier; for example, the constraint that two or more trains cannot be in the Down Goods Loop at any one time can be easily expressed as D ≤ 1 .
D
A Abbotswood Junction (for Bristol) (for Birmingham)
(for Worcester)
Figure 4:
B
C
A ~ C: number of trains to come D: number of trains in goods loop (A, B, C, D): the state The state of the network.
A mutation operation can be defined as a partial change in the trajectory. Upon mutation the constraints can be taken into account so that the chromosome after the mutation is still a “feasible” solution. The probability of the occurrence of a mutation is to be higher when the mutation transforms an original chromosome to another one that has a smaller Levenshtein distance [8] to the original. A crossover operation between two chromosomes is possible only when there are one or more common states (other than the initial and the final states) in the chromosomes. If there are two chromosomes P (sequence SP, 1, SP, 2, …, SP, N) and Q (sequence SQ, 1, SQ, 2, …, SQ, M), and if SP, i = SQ, j, then the crossover of these two chromosomes at SP, i = SQ, j creates a new chromosome which has the sequence of either (SP, 1, SP, 2, …, SP, i, SQ, j+1, SQ, j+2, …, SQ, M) or (SQ, 1, SQ, 2, …, SQ, j, SP, i+1, SP, i+2, …, SP, N). If no common state is found in the sequences of P and Q except for the initial and final states, then the pair of chromosomes P and Q are called “infertile”. Using this chromosomal expression, the problem can be solved in broadly the same way as the SGA.
6 Optimisation results and discussion The authors have performed numerical optimisation on five different cases, using GA with the proposed chromosomal expression as explained in the previous section.
Rescheduling
143
For all cases, a weighted sum of train times is used to evaluate a chromosome. The only difference between cases is the values of the weighting coefficients for passenger and freight trains. All other conditions are unchanged, remaining as described in the earlier sections. Also, the parameters for the GA are common for all cases. There are 60 chromosomes per generation, and the algorithm terminates when 100 generations have been calculated. Given the population and evaluation of the current generation, the next generation of populations is determined as follows. 1) If the best evaluation among the current generation is worse than the very best which existed in the past, add the very best chromosome to the current generation population. 2) Create a group of 18 chromosomes by crossovers. One chromosome is created by the crossover between two parent chromosomes selected from the current generation, and is added to the new group. A chromosome in the current generation with better evaluation is assigned a higher possibility of being selected as one of the parents. If the selected pair is “infertile” and cannot create a crossover “child”, then mutation is applied to one of the pair and added to the new group instead. 3) Create the group of 42 chromosomes by selecting from the current generation of population, allowing the selection of the chromosome twice or more. The possibility that a chromosome in the current generation is selected is the same as the function used in 2). 4) Add the groups of chromosomes generated by 2) and 3) to create a group of 60 chromosomes. 5) Apply mutation to 80 per cent of the chromosomes in the group created in 4).
(for Worcester) Abbotswood Junc. (for Birmingham)
0
10
20
30
time [minutes] 40 50
60
70
80
delayed freight train Abbotswood Junc.
(for Bristol)
Figure 5:
Optimisation result (1) weight of passenger : freight trains = 6 : 1.
144 Timetable Planning and Information Quality
(for Worcester) Abbotswood Junc. (for Birmingham)
0
10
20
30
time [minutes] 40 50
60
70
80
delayed freight train Abbotswood Junc.
(for Bristol)
Figure 6:
Optimisation result (2) weight of passenger : freight trains = 6 : 3 or 6 : 6.
(for Worcester) Abbotswood Junc. (for Birmingham)
0
10
20
30
time [minutes] 40 50
60
70
80
delayed freight train Abbotswood Junc.
(for Bristol)
Figure 7:
Optimisation result (3) weight of passenger : freight trains = 6 : 12.
Figure 5: shows the case where the weightings of passenger : freight trains is 6 : 1, in which the freight train departs the Down Goods Loop after all passenger trains bound for Bristol have made their way through Abbotswood Junction. Cases for the weightings of 6 : 3 and 6 : 6 yield the same result, shown in Figure 6:, in which the freight train leaves the last two Bristol-bound passenger trains behind. Results for the 6 : 12 and 6 : 24 weightings (shown in Figure 7: and Figure 8:, respectively) show that, as the weight for the freight train increases, fewer passenger trains overtake the freight train at Abbotswood, with Figure 8: showing that no overtaking becomes the optimal solution. These results suggest
Rescheduling
145
that a change in the order of passenger trains and the freight train takes place when, as the weightings given for the freight train becomes larger, the disbenefit of holding the freight train is larger than the accumulated benefit of letting the passenger trains overtake at Abbotswood Junction. The calculation time required for the optimisation was nearly 5 hours using a personal computer with 1.4GHz Intel Pentium 4 CPU; although this is clearly too long to be practical, considering that a detailed dynamic multi-train simulator has been used embedded in the optimisation process, it does not necessarily mean the GA cannot be used for this kind of optimisation.
(for Worcester) Abbotswood Junc. (for Birmingham)
0
10
20
30
time [minutes] 40 50
60
70
80
delayed freight train Abbotswood Junc.
(for Bristol)
Figure 8:
Optimisation result (4) weight of passenger : freight trains = 6 : 24.
The different results presented in this section are generated only by changing the weighting coefficients. However, there are many parameters that have to be determined, such as the size of the population per generation, percentage of chromosomes to be created through crossovers or percentage of chromosomes to mutate. These parameters may depend on track topography, the train schedule and the disruption scenario.
7
Conclusion
A number of numerical optimisations of a railway junction control have been carried out using Genetic Algorithms and using OOMTS as an embedded simulator. A novel chromosomal expression for the problem has been proposed that enables the problem to be solved in a way very similar to that used by the Simple GA. The authors are looking at the application of the same idea to various other problems, especially railway networks with multiple junctions.
146 Timetable Planning and Information Quality
Acknowledgement This research was conducted within RRUK, the Universities’ Centre for Railway Systems Research, funded by the EPSRC, U.K. (GR/S12784/01).
References [1] [2] [3] [4] [5]
[6] [7] [8]
Takagi, R., et al.: “An Object-oriented Signalling System Model for the Study of Delay Minimization by On-line Train Control”, IRSE Aspect 2006, London, UK (March 2006). Siu, L. K.: “An Object-oriented Railway System and Power Network Simulator”, The University of Birmingham (PhD Thesis) (1995). Mellitt, B., Goodman, C. J. and Arthurton, R. I. M.: “Simulator for studying operational and power-supply conditions in rapid transit railways”, Proc. IEE, Vol. 125, No. 4, pp.298-303 (1978). Siu, L. K. and Goodman, C. J.: “An object-oriented concept for simulation”, Proc. COMPRAIL 1992 International Conference, Washington DC, USA (1992). Goodman, C. J.: “Promoting railway research in United Kingdom universities: the genesis of Rail Research UK”, Proc. of a Symposium on Research and Development in Railway Engineering, Dept. of Elec. Eng., Hong Kong Polytechnic University, 3.1.1 - 3.1.12 (2003). Nagao, T.: “Optimization Algorithms” (in Japanese), Shoko-do Publishing, Tokyo, Japan (2000), Chapters 10 – 12. Rothlauf, F.: “Representations for Genetic and Evolutionary Algorithms”, Physica-Verlag, Heidelberg, Germany (2002). National Institute of Standards and Technology (NIST): “Dictionary of Algorithms and Data Structures” (http://www.nist.gov/dads/ HTML/Levenshtein.html).
Rescheduling
147
Running time re-optimization during real-time timetable perturbations A. D’Ariano1,2 & T. Albrecht3
1 Transport and
Planning, Delft University of Technology, The Netherlands 2 Informatica e Automazione, Universit` a degli Studi Roma Tre, Italy 3 “Friedrich List” Faculty of Traffic and Transportation Sciences, Dresden University of Technology, Germany
Abstract In the Netherlands the railway network is heavily used by heterogeneous train traffic and characterised by short headway times. That is why even small initial delays may perturb the timetable causing consecutive delays. In such conflict situations, traffic controllers have the complicated task of deciding upon the optimal train schedule in real-time. They could be assisted by sophisticated conflict-solving systems. Optimal train running profiles can be designed that fit better to the new train order and allow the reduction of delays and energy consumption at the same time. This paper presents a formulation for this complex problem that makes it suitable for quantitative analysis and for optimizing actual running times at network scale. A conflict solution system is developed that models the train scheduling problem as an alternative graph. Adopting the blocking time model, safe headway distances between trains are assured by any real-time traffic control measure. The optimal solution from a network point of view can be improved by modifying the speed profiles locally for the individual train routes. A constructive heuristic algorithm for the dynamic modification of running times during operations is proposed that satisfies the timetable constraints of train orders and routes and guarantees the feasibility of the running profile, while taking into account the properties of the signalling and train protection systems in use. A realworld example from the Netherlands in the case of the Dutch signalling system NS54 is presented to demonstrate the benefits of the proposed methodology. Keywords: railway traffic management, train scheduling, delay minimization, train speed optimization, energy optimal train control.
148 Timetable Planning and Information Quality
1 Introduction The off-line development of detailed conflict-free timetables is a complex and recurrent problem, and typically requires many months. Since disruptive events are unpredictable time reserves are distributed over the timetable, preferably guided by past experience and empirical data [1]. During operations, however, unforeseen events may disrupt the timetable and cause conflicts between train paths that must be resolved in real-time. Moreover, the railway infrastructure is becoming more and more saturated by local delays, which are more difficult to manage and easily generate many consecutive delays (due to conflicts). Current operational traffic management is reactive: a train driver tries to adhere to the original schedule and responds to the signalling system when the route ahead happens to be occupied. Dispatchers only reschedule the route setting plan when trains have a considerable delay, and (network) traffic controllers become active when train traffic is already highly disrupted. Hence, improving the reliability of dense train traffic requires an advanced railway traffic management system that accurately monitors current train positions, predicts potential conflicts and reschedules trains in real-time such that consecutive delays are minimized [2]. Traffic monitoring Conflict detection
There will be conflicts in the future.
Conflict resolution
There won’t be conflicts, all trains can travel according to timetable.
Solution contains overlaps.
Speed optimization
To be transmitted to the trains.
Solution doesn’t contain overlaps.
Figure 1: Components of a proactive traffic management system. The introduction of computerized on-line decision support systems aims to prevent the decision maker from taking wrong decisions. Such systems should be designed to support operators to quickly re-schedule trains during real-time perturbations and typically contain the following components (cf. Fig. 1): 1. Traffic monitoring: Take as input the position, the speed and the planned timetable for each running train in the railway network. 2. Conflict detection: Given the current infrastructure status, actual timetable and current train delays and speeds, find potential conflicting train paths that require the same infrastructure element at the same time (conflicts): this will be prohibited by the safety system. 3. Conflict resolution: Given the current train delays and predicted conflicts, find an optimal solution by rescheduling and/or rerouting trains. This solution must respect the constraints of the signalling system in use: A train that gets too close behind another is forced to slow down by the signalling/ train protection system in use. Getting into such a situation corresponds to an overlap of blocking times according to blocking time theory [3].
Rescheduling
149
4. Speed optimization: Send new targets (time and advisory speed at key locations) to rescheduled trains with the aim of respecting punctuality and saving energy. Many consecutive delays can be prevented if traffic is proactively managed. Based on an accurate monitoring of actual train positions potential conflicting routes can be predicted in advance and resolved in real-time. The adjusted targets (location-time-speed) have then to be communicated to the relevant trains. Driver Assistance Systems [4] installed onboard can support the driver control its train best to reach the overall optimum. Such systems have to consider the behaviour of the safety system to avoid undesired safety braking, consequent slow downs and higher energy consumption of trains. They will allow not only more precise control of trains, but also effective train speed coordination on open tracks, securing time windows at junctions/crossings, or synchronizing arriving trains at stations in case of delays and expected route conflicts. The literature on traffic management focuses on conflict detection and resolution (CDR) systems (cf. [5] for an overview). Only few studies are known which take into account the possibility of speed coordination to improve the rescheduling solution: Asuka and Komaya [6] mainly focus on urban rapid transit with low speeds and short distances between stations. Huerlimann [7] focuses on speed optimization at a single junction. This paper presents an advanced traffic management system which is able to consider a complicated network for the CDR system and improve the obtained solution by speed optimization in network nodes afterwards. The paper is organized as follows: Section 2 introduces the CDR system. Section 3 deals with the optimal speed control in conflict situations. In Section 4 we describe a test case based on the Utrecht-Geldermalsen railway link. Finally, conclusions are drawn and future research is discussed.
2 Conflict detection and resolution system The aim of real-time rescheduling is to control the railway traffic in case of perturbations. The CDR system used here models the railway system as an alternative graph [8]. This graph represents the train paths of all trains in a given control area along with their precedence constraints (minimum headways computed using the blocking time model [3]). Moreover, special (alternative) arcs represent operational choices such as the train order at a crossing or merging section. A decision is made by selecting one of two alternative arcs which then fixes a precedence constraint between two trains at a potential conflict point. This alternative graph can be used to model different signalling systems and therefore is quite flexible [9]. In case of fixed block signalling each block signal corresponds to a node in the alternative graph and the arcs between nodes represent blocking times or headway times. A feasible schedule assigns passage times to each node such that all precedence constraints are satisfied. The CDR problem (or train scheduling problem) can then be defined as follows: For given initial delays find the shortest paths in the alternative graph and fix the corresponding selected alternative arcs. All trains are considered simultaneously with the aim to minimize the maximum
150 Timetable Planning and Information Quality consecutive delay in the network. D’Ariano et al. [10] developed an efficient branch and bound algorithm to find an optimal schedule using several speed ups exploiting the problem knowledge. The alternative graph model assumes deterministic blocking and waiting times and thus does not take deceleration and acceleration into account in case of hindrance. D’Ariano et al. [11] therefore developed a train management system that updates the speed profiles of trains according to the signal aspects. In each step of an iterative rescheduling procedure the CDR problem is solved and subsequently it is checked whether train paths overlap (yellow signals). If overlaps arise the speed profile of the second train (that passes a yellow signal) is updated and the blocking times are changed accordingly. In the next iteration possible new ’queueing’ conflicts are solved, which again may lead to slowing down of trains. The rescheduling procedure terminates in a finite number of iterations and gives a conflict-free timetable with admissible train dynamics.
3 Optimal speed control in conflict situations The solution of the CDR system may contain overlaps. That means in practice, that the concerned train will have to reduce its speed involuntarily. This may cause operational disadvantages: 1. Traditional ATP systems (like the Dutch ATB-EG) will force the train driver to decrease the speed of its train in any case in order to be able to reach a safe state before the next signal, which is expected to be the limit of movement authority but whose position is unknown to the onboard unit of the ATP system. 2. Train speed can only be increased again, if a signal upgrade has been recognised by the ATP system. Whereas modern ATP systems like ETCS level 2 can do so automatically in a safe manner, old systems rely on a nonsafe confirmation of the signal upgrade by the driver. At the time the conflict is over, the train will have a lower speed than originally planned in the timetable. In order to get back to its travelling speed it has to re-accelerate, which costs time in the first place (and therefore causes additional delay) and energy in the second place. In order to reduce those negative effects, a constructive heuristic algorithm is proposed for the computation of the optimal train trajectories. This algorithm is illustrated in Fig. 2. It is based on the idea that the train is slowed down slightly some time before the possible overlap, in order to be able to re-accelerate without being hindered and reach the conflict area with optimal distance behind the train causing the conflict. The train should then never have to pass a signal aspect that forces a modification of its optimal trajectory. Of course, the algorithm only has to be started in case that overlaps (speed decreases due to signal aspects) exist; assuming the train goes from its state it enters the corridor on its planned (energy-optimal) path. If that’s the case, step 1 of the algorithm (Fig. 2) consists of the computation of the fastest possible trajectory from the start state of the train (position, speed) to its target state (scheduled
Rescheduling speed
1 Compute time-optimal
trajectory
line speed limit 6
5
2 Find most critical
4
1 2
151
start 3 state
5
approach time subsequent crossing train that needs the same infrastructure to be respected in phase 3
position
red
yellow
release time switch/sight/ reaction time
overlap, compute target trajectory
target state
start trajectory signal upgrade not feasible times 1 from preceding train
3 Fix start state on start
trajectory with respect to following trains
4 Fix target state on
target trajectory
Max. cruising speed = max. speed between start and target state 5 Decrease max. crui-
sing speed and compute new trajectory
6 4 target
6
state
2 most critical
overlap and target trajectory
Target state yes reached before time? no
6 Shift target
state towards start state
time
yes
Trajectory influenced by signalling? no
7 Optimization
terminated, optimal trajectory found
Figure 2: Flow diagram and the algorithm steps illustrated in a theoretical example.
passing time) at the end of the corridor without regard of the signalling system. For this trajectory, the most critical conflict can be determined (biggest negative difference between passage time of the time-optimal trajectory and signal upgrade to undisturbed operation - green signal aspect). Step 2 consists of determining the so-called target trajectory by shifting the time-optimal trajectory in time in such a way, that it passes the critical conflict at the time of signal upgrade. It shall now be assumed that the arrival time of this trajectory is later than the planned arrival time, so this target trajectory is the only solution with minimal delay which does not have to pass a yellow signal (there may be other solutions with smaller delay at the end of the corridor, which necessitate passing a yellow signal once [12]). The next steps of the algorithm consist of finding the best transition between the expected trajectory of the train (1) and the target trajectory (2). It shall be computed according to the following criteria: • The train shall be slowed down the least possible, because every slowing down needs to be compensated by re-acceleration which costs energy. • The smaller the distance and the longer the time to the critical conflict, the more the train has to be slowed down. • The earlier a train diverges from its original trajectory, the later it will be at any given position before the conflict. Those delays may cause consecutive delays of subsequent trains.
152 Timetable Planning and Information Quality Those three factors have to be taken into account in the construction phase of the transition trajectory. In order not to hinder subsequent trains which partially use the same infrastructure, step 3 sets a start state on the original trajectory. The time the train may diverge from its trajectory can be computed using blocking time theory recursively (from the time the next train will need to use the infrastructure back to the required release time of the same infrastructure for the examined train). In step 4, the target state is fixed on the last point on the target trajectory, which theoretically would allow having the maximal distance between start and target state. Then, the transition trajectory must be computed (step 5). It must contain minimum three regimes and two switching points [12]. Here, three phases are proposed: A regime of braking/ acceleration, cruising at a given cruising speed and re-acceleration to the target speed. To find the switching points between the regimes, the maximal cruising speed between start and target state is successively reduced, the first and last phase are prolonged respectively. The arrival time at the target state increases and step 5 is repeated until the target state is reached on time. It must then be checked, whether the train can follow this transition trajectory with respect to the signalling system (step 7) or whether it had to brake involuntarily when following it. In the latter case, the target state is moved towards the start state (step 6). That generally leads to lower cruising speeds of the transition trajectory, where the risk of hurting the signalling constraints decreases. If the target state is moved too much towards the start state, it may be possible that no feasible solution for step 5 exists and the desired target trajectory can not be reached under the given constraints. Either the constraints have to be redefined (move start state towards section entrance, step 3) or the target trajectory moved forward in time and the optimization has to be re-started. In case the computed target trajectory arrives too early at the exit of the regarded corridor the available running-time reserve must be distributed either before or after the conflict. That may be done using Dynamic Programming [4].
4 Case study This section illustrates the influence of the effective railway traffic management system proposed in the previous sections by means of a real-word example. A node of the existing Dutch railway network between Utrecht and Geldermalsen (Fig. 3) is regarded. It is composed of a main corridor of around 14 km and includes Culemborg station. There are four trains in the network. Train A is a freight train, D 3
4
1
2
C B
Geldermalsen
5
A 6
9 10
11 12 13 14 15
7 8 Dordrecht
16 17 18 19 20 21 22
Culemborg
Figure 3: Utrecht - Geldermalsen railway link.
Utrecht
Rescheduling
153
going from Culemborg (block section 15) to Utrecht (block section 22). Train B and C are intercity passenger trains going from Geldermalsen (block section 1) to Utrecht. Finally, train D is a regional passenger train going from Geldermalsen to Dordrecht (block section 8). Train A shall be delayed and the running of the following trains on the corridor is influenced by the presence of permissive signals and signalling block constraints at the entrance of Culemborg station. Potential conflicts can also be found at the exit of Culemborg station. Trains A, B and C share block sections 15-22. Since trains B and C follow the same path they share all the block sections. Train D shares block sections 5 and 6 with trains B and C. Note that due to the initial position of trains, train C is not allowed to precede trains B and train A can not be surpassed, and therefore we have a priori order among those trains. The switching time to release or set the interlocking routes and signals is taken to be one second, on the basis of automatic signal blocks with electronic technology. Furthermore, sight and reaction times at sight distance of the approach signal are assumed equal to 14 seconds. The track speed limits are 80 km/h for the sections 1-8, 130 km/h otherwise. The signalling system consists of two speed levels in case of a conflict ahead (80 km/h, 40 km/h), which are signaled depending on the section lengths. The Dutch ATP-System ATB-EG requires immediate braking after entering a section, where the signaled speed is lower than track maximal speed, which is also taken into account in the simulation. 4.1 Conflict detection and resolution system solution The solution obtained by the branch and bound algorithm is given in Fig. 4. All train paths involved in the example are represented in terms of blocking times. Due to the large input delay of train A, re-timing decisions have been taken to obtain a feasible schedule with respect to headway and signalling constrains but the system solution presents the train ordering of the original timetable. In detail, trains B 0
2 3 4 5 6 78 9
10
60
11
12 13
14
15
16
17
18 19 20 21 22 DISTANCE (block section)
Train B
120
Train A
180 240 300 360
Train D
420 480 540 600 660
OVERLAPS
Train C
Train D
Train C
Train B
Train A
720 TIME (sec) 738
Figure 4: Blocking time plot of the CDR solution.
154 Timetable Planning and Information Quality and C interfere on block sections 15-17 as illustrated by the overlapping blocks. In this situation, the planned speed profiles of those trains can no longer be used in the CDR algorithm. They are adapted according to the iterative rescheduling procedure of D’Ariano et al. [11]. In this case, delayed trains run at their maximum allowed speeds and in case of a yellow (or red) signal aspect an ordinary driver behaviour is applied: At sight distance of the approach signal drivers are supposed to start decreasing train speed. Train D is not delayed in this example thus maintains its original speed profile. 4.2 Speed optimization system solutions For the example of Fig. 3, three different solutions in terms of train speed trajectories shall be discussed. The solution given by the CDR system and two variants of speed optimization are proposed in Fig. 5. In all three cases, train A runs at maximum speed, trains B, C and D adopt different speed profiles. The CDR solution presents feasible speed profiles for each train (Fig. 4). At the exit of the network train B (C) has a delay of 128 (167) seconds and train D is not delayed, in case the drivers are supposed to react to the current state of the signalling system only. The next solution represents a speed optimization which only takes into account the previous train and not subsequent trains. Here, step 3 of the algorithm in section 3 is not considered and trains B, C and D are optimized in the order that they pass the critical section. With the aim of minimizing energy consumption of the individual trains, trains B and C are slowed down as soon as they enter the corridor. As a consequence train D can not get out of the situation but delayed. In detail, with respect to the previous solution the energy consumption for all trains is reduced by 45%, whereas the sum of delays is about the same (reduced delay for trains B and C and increased for train D). For train D, this represents a deterioration of the solution quality compared to the CDR solution without speed optimization. A second speed optimization run is done, this time respecting the constraints given by train D when fixing the starting states of train C and B in step 3. The possibility of speed decrease of train C is limited to the sections, where it doesn’t influence train D. Train B must be re-optimized in order not to disturb train C. With this solution, the regarded trains B, C and D need 30% less energy than without speed optimization. Train D is not disturbed and therefore, overall delay can be reduced by 45 seconds. The two proposed speed optimization solutions are pareto-optimal: Min. energy consumption and min. delay respectively. Traffic operators must discuss which of the solutions fits their objectives during operations.
5 Outlook and conclusions This paper showed the effectiveness of an intelligent method to reduce consecutive delays by identifying potential conflicts, rescheduling train traffic and optimizing the speed trajectory of each train involved in a conflict/overlap situation. Such
Train D Train C 2500
5000
7500 10000 12500
0
2500
5000
7500 10000 12500
600
600
0
2500
5000
Train C: Arrival: 747 s Energy: 311.8 kWh 7500 10000 12500
position in m
Arrival: 376 s Energy: 34.4 kWh
Train B: Arrival: 588 s Energy: 244.8 kWh
Train D: 400 Arrival: 331 s
Energy: 9.7 kWh
500
600
Train C: Arrival: 723 s Energy: 181.5 kWh
700
800
7500 10000 12500
0
2500
5000
7500 10000 12500
Train C: Arrival: 723 s Energy: 192.8 kWh
700
800
0
2500
position in m
7500 10000 12500
position in m
155
Figure 5: Comparison of three variants of train speed trajectories.
5000
Rescheduling
Legend: yellow 80 700 yellow 40 red
time in s
time in s
500
5000
300
400 Train D:
500
2500
200
300
Train D: 400 Arrival: 331 s Energy: 9.7 kWh
0
100
Train B: Arrival: 588 s Energy: 146.3 kWh
200
300
140 120 100 80 60 40 20 0 0
100
Train B: Arrival: 608 s Energy: 332.9 kWh
200
800
Train D 0
0
100
time in s
140 120 100 80 60 40 20 0
speed in km/h
speed in km/h
speed in km/h
Train B
0
III) Constrained speed optimization
II) Top-down speed optimization
I) No speed optimization 140 120 100 80 60 40 20 0
156 Timetable Planning and Information Quality a system can be implemented in an advanced traffic management system which improves operations reliability with small investments compared to the alternative of building new infrastructure. A case study of the Utrecht-Geldermalsen railway link showed how the CDR system and the speed optimization can be adopted in order to react proactively when signal aspects change. The obtained solutions clearly indicate the need to develop on board driver support systems in order to improve punctuality and minimize energy consumption. In the future, it is planned to include the speed optimization into the iteration algorithm of the CDR system already to be able to better estimate the consequences of optimal speed control at network level.
References [1] Hansen, I.A., Increase of capacity through optimized timetabling. In: Computers in Railways IX, pp. 529–538, Southampton, 2004. WIT Press. [2] Ho, T.K., Norton, J.P. & Goodman, C.J., Optimal Traffic Control at Railway Junctions. IEE-Proc.-Electr. Power Appl., 144(2), pp. 140–148, 1997. [3] Pachl, J., Railway Operation and Control. VTD Rail Publishing, Mountlake Terrace, USA, 2002. [4] Albrecht, T. & Oettich, S., A new integrated approach to dynamic schedule synchronisation and energy-saving train control, In: Computers in Railways VIII, pp. 847–856, Southampton, 2002. WIT Press. [5] Oh, S.M., Hong S.H. & Choi, I.C., Railway conflict detection and resolution in the Korean railway system. In: Computers in Railways IX, pp. 675–684, Southampton, 2004. WIT Press. [6] Asuka, M. & Komaya, K., Automatic train operation using braking pattern transitional time. In: World Conf. on Railway Research, pp. 628–636, 2003. [7] Huerlimann, D., Objektorientierte Modellierung von Infrastrukturelementen und Betriebsvorg¨angen im Eisenbahnwesen. PhD Thesis, ETH Zurich, 2001. [8] Mascis, A. & Pacciarelli, D., Job shop scheduling with blocking and no-wait constraints. European Journal of Operational Research, 143(3), pp. 498– 517, 2002. [9] Giannettoni, M. & Savio, S., The European Project COMBINE 2 to Improve Knowledge on Future Rail Traffic Management Systems. In: Computers in Railways IX, pp. 695–704, Southampton, 2004. WIT Press. [10] D’Ariano, A., Pacciarelli, A. & Pranzo, M., A branch and bound algorithm for scheduling trains on a railway network. European Journal of Operational Research, 183(2), pp. 643-657, 2007. [11] D’Ariano, A., Pranzo, M. & Hansen, I.A., Conflict resolution and train speed co-ordination for solving real-time timetable perturbations. IEEE Transactions on Intelligent Transportation Systems, 8(2), pp. 208-222, 2007. [12] Albrecht, T., Energiesparende und versp¨atungsminimierende Zugsteuerung in Konfliktsituationen. Signal und Draht, 97(12), pp. 18–22, 2005.
Rescheduling
157
An algorithm for train rescheduling using rescheduling pattern description language R C. Hirai1, N. Tomii2, Y. Tashiro3, S. Kondou4 & A. Fujimori5 1
Transport Information Technology Division, Railway Technical Research Institute, Japan 2 Department of Computer Science, Chiba Institute of Technology, Japan 3 Kyushu Railway Company, Japan 4 West Railway Company, Japan 5 Hokkaido Railway Company, Japan
Abstract We propose an algorithm for automatic train rescheduling with a train rescheduling pattern language processing system. Intended for restoration from heavy train traffic disruption, our proposed algorithm has inherent abilities to make effective train rescheduling plans. While the previous algorithm tries to make a train rescheduling plan in small steps, the proposed one surveys the train timetable at first and applies “train rescheduling patterns” to prepare rescheduling plans. Applying actual train schedule data, we have confirmed that our algorithm works satisfactorily. The algorithm is helpful for preparation of adequate rescheduling plans for practical applications, especially for severe train traffic disruption caused by an accident requiring more than an hour suspending train operations, Keywords: train rescheduling, pattern description, train rescheduling pattern, train traffic disruption, train traffic control, framework of train rescheduling system.
1
Introduction
In Japan, since railways have a dominant share in urban transportation, the offer of an efficient service for a large volume of passengers is required. Train traffic, however, is sometimes disrupted when accidents, natural disasters or technical problems occur on railway lines. In order to restore disrupted services, railways
158 Timetable Planning and Information Quality continuously make a series of modifications to the current train schedules. Such a task is termed as train rescheduling [1]. It is quite important for railway companies to prepare an adequate train rescheduling plan hereinafter referred to as “the plan” whenever train traffic is disrupted. In particular, when the disruption is expected to last long, railway lines are normally tied up until the cause of the disruption is resolved. Because trains are running every couple of minutes especially in urban areas, a number of trains have to be cancelled. Then, the train-set and crew schedules have to be modified so that there is no lack of train-set or crew in the plan. Sometimes, railway companies try to cancel a part of train paths, so that passengers who do not pass the disrupted area are not inconvenienced. As can be imagined, careful modification of train-set and crew schedules have to be carried out successively. Train rescheduling, especially that following a large disruption, is such a complicated task. At present, expert train dispatchers are involved in train rescheduling. They constantly monitor daily train operations closely at their post. Once an accident that likely causes a disruption of transport services occurs, train dispatchers collect information about it and prepare “the plan” based on their previous experiences and intuitions. They take into account not only the future train traffic and the passenger density but also unforeseen problems. An algorithm for automatic train rescheduling is required to be introduced. In order to maintain stable transport services, railway companies require a mechanism which ensures the quality of “the plan”. Recently, computer algorithms to assist train dispatchers in charge of train rescheduling are reported [3-9]. These algorithms, however, lack many of the functions required for a large disruption, namely to cancel a number of trains and modify train-set and crew schedules automatically. In this paper, we propose an algorithm for automatic train rescheduling especially for a large disruption. Our algorithm based on a technique that applies experts’ knowledge as “train rescheduling patterns” hereinafter referred to “the patterns” to compute “the plan” automatically. Some railway companies recognize specifiable parts of the experts’ knowledge as “the patterns” to restore disrupted train traffic effectively. In order to build a practical algorithm for automatic train rescheduling, a use of “the patterns” is recommendable. On the other hand, we have to consider the fact that a mere use of “the patterns” is insufficient to prepare effective and practical plans. Due to the uncertainty of occurrences of accidents it is difficult to prepare complete train rescheduling patterns to suit every situation. Such a circumstance results in a need of a mechanism that modifies “the plan” prepared by only application of “the patterns”. For the sake of constructing an automatic train rescheduling algorithm we have to solve the following problems: 1. Establish a language to describe “the patterns”. 2. Develop a language processing system (an interpreter) to apply “the patterns”. 3. Construct a framework of an automatic train rescheduling system to modify the plan created by the interpreter.
Rescheduling
159
We have solved the above three problems, and implemented an algorithm for automatic train rescheduling. Applying actual train schedule data, we have confirmed that our algorithm works satisfactorily.
2
Train rescheduling pattern
2.1 Train rescheduling pattern Some railway companies recognize specifiable parts of the experts’ knowledge as “the patterns” to restore effectively disrupted train traffic. Each train dispatcher has his own strategy in preparation of “the plan”, which causes variations in “the plans”. For example, under the same conditions, a dispatcher adopts a plan by which disrupted traffic is restored as immediately as possible while another dispatcher selects a plan that maintains sufficient traffic capacity. In order to provide stable and punctual transportation services to the public, every train dispatcher needs to own common and compatible strategies for train rescheduling. Railway companies, accordingly, have taken steps under which every train dispatcher utilizes “the patterns”. 2.2 Examples of applying train rescheduling patterns Express train
Cancelled express train
Local train
Extra train
Station A
8 900 5
10
Station E Station F
(b) Resultant schedule
12
4
12
10
2
6
8 4
11
3 900
Time
9
(a) Initial schedule
1 900
Station D 1
1
Station F
3
11
9
3
2
Station C
Station E
15
Station B
13
15
13
Station C Station D
7
5
7
5
Station B
6
Station A
Cancelled local train
Time
Figure 1: Example of train rescheduling. Figure 1 shows examples of how “the patterns” are applicable when train traffic is disrupted. Figure 1(a) shows the initial schedule, while Figure 1(b) shows the resultant schedule. A thick diagonal line indicates an express train, and a thin diagonal line shows a local train. Express trains operated between station-A and station-E; and local trains between station-C and station-E. We assume that station-B and station-F have sufficient tracks to accommodate temporary train-sets. On the contrary, there is no extra track available at both station-C and station-E. Grey thick line indicates a location and an affected time interval of the accident where trains are inoperable. A broken diagonal line indicates a cancellation of the corresponding train.
160 Timetable Planning and Information Quality Figure 1(a) illustrates initial schedule that includes train cancellations immediately after the accident. We assume that trains encountered with the accident will be likely cancelled as initial operations. In Figure 1(a), the initially cancelled trains are train-5, train-7, train-2 and train-4. Figure 1(b) shows a resultant schedule after applying the following patterns. Figure 2 shows Train rescheduling pattern 1 (TRP-1). In the case where an express train-X is cancelled between station-A and station-E, the next express train-Y from station-E is cancelled. A train-set for an express train-X waits at station-A, and is operated as the next express train-Z. Figure 3 shows Train rescheduling pattern 2 (TRP-2). In the case where an express train-X is cancelled between station-C and station-E, the next express train-Y is cancelled between station-E and station-B. An extra train-W is set from station-C to station-B. A train-set for train-X is operated as a train-W and waits at station-B. After that, the train-set is operated as train-Y from station-B to station-A.
Station A
Y
Station B Station C
Station D
Station D
Station E
Station E
Station F
Z
d) ncelle X (Ca
Station C
Z
ed) ncell X (Ca
Station B
Y (Ca ncell ed)
Station A
Station F Time
(a) Initial schedule (Train X is cancelled)
Time
(b) Resultant schedule
Figure 2: Train rescheduling pattern 1 (TRP-1).
Station A
Station A
Station E
Y elled
elled
Station D
elled
Canc
Canc
Station D
Canc
Station C
W
Station B
Station C
Z
Z
Y
X
X
Station B
Station E
Station F Time
(a) Initial schedule (Train X is partially cancelled)
Station F
(b) Resultant schedule
Figure 3: Train rescheduling pattern 2 (TRP-2).
Time
Rescheduling
Z
led ) Ca nce l X(
Z
X(
) lled nce
Station E
Ca Y(
Station D
W
Y
Station E
W
Station D
Station C Ca nce lled )
Station C
161
V
Station F
Station F Time
(a) Initial schedule (Train X is cancelled)
(b) Resultant schedule
Time
Figure 4: Train rescheduling pattern 3 (TRP-3). Figure 4 shows Train rescheduling pattern 3 (TRP-3). In the case where a local train-X cancelled between station-E and station-C, the next local train-Y is cancelled between station-C and station-E. An extra train-V is set from station-E to station-F. A train-set for train-X waits at station-F until the next operation is decided. A resultant schedule in Figure 1(b) is derived from application of TRP-1, TRP-2 and TRP-3 to the corresponding cancellations respectively as shown in Figure 1(a). 2.3 Background of introducing train rescheduling patterns Based on our hearing investigation of several railway companies, we can summarize reasons to make use of “the patterns” as follows: a. Make the plan quickly. As described in section 1, to make “the plan” is quite a complicated and time-consuming task. Following “the pattern”, it becomes possible for dispatchers to make “the plan” quickly. b. Perform train rescheduling task smoothly. Train rescheduling operations involve many people; train dispatchers, drivers, conductors, station staff, etc. It is necessary for them to coordinate closely with each other to avoid any failure. Familiarized with the detail of the plan in advance, every staff involved in the work is capable of fulfilling their activities with confidence. c. Provide stable transport services. It is possible to reduce variations due to different strategies taken by each train dispatcher in preparation for train rescheduling tasks. d. Avoid unforeseen problems. A skilled train dispatcher has expertise to avoid unpredictable problems. Though it is not possible for them to explicitly explain the details of the problems, in many occasions there is covert information not disclosed to the public. Hence, we can incorporate the expertise into “the patterns” beforehand; train dispatchers are able to take advantages of expertise of other dispatchers. e. Realize train rescheduling operations that reflect a policy of a railway company. It is possible to incorporate the policy into “the patterns” beforehand. Considering the concept of railway companies mentioned above, we conclude that a practical algorithm for automatic train rescheduling should utilize “the patterns”.
162 Timetable Planning and Information Quality In addition, the utilization of “the patterns” creates a reduction of computing time. Our approach includes a simplified procedure; merely applying “the patterns” to the current schedule. In comparison with an algorithm that enables to compute “the plans” successively from the initial state, our approach enables to construct an algorithm by which “the plans” are prepared within a short period. 2.4 Problems to introduce train rescheduling patterns For the sake of constructing an automatic train rescheduling algorithm, we have to solve the following problems: 1. Establish a language to describe train rescheduling patterns: Up to now, “the patterns” are specified in a natural language or drawn graphically as shown in Figure 2, 3 and 4. Therefore, it is necessary to establish a language that enables to represent them in a computer-recognizable form. 2. Develop a language processing system (an interpreter) to apply “the patterns”: A mechanism applying “the patterns” to the current train schedule is essential. In other words, the following functions are required. ・ A function to find a location where “the patterns” is applicable to the current schedule: In Figure 2, cancelled train-X should be found to apply TRP-1. ・ A function to assign train names of the current train schedule to “the pattern”: In Figure 1(b) and Figure 4, it is necessary to assign train-2 and train-4 to train-X. ・ A function to output operation instructions: In Figure 1(b), the output should be cancellations of train-6, train-8, train-9 and train-11, settings of train-9005, train-9001 and train-9003, and related train connections. 3. Construct a framework of an automatic train rescheduling system to modify the plan created by the interpreter: The only use of “the patterns” is insufficient to prepare a practical rescheduling plan. It is difficult to prepare “the patterns” for every single case. Not all trains are applicable; therefore, a framework that modifies the results of applying “the patterns” is required. We have settled these problems. For each problem, our approach is as follows: 1. Introduce a pattern description language named “R”. 2. Develop a pattern description language processing system named “Rinterpreter”. 3. Construct a framework for comprehensive train rescheduling system.
3
Pattern description language R and R-interpreter
We introduce a language named “R” to describe “the patterns”. In addition, we have implemented a language processing system named “R-interpreter” to interpret descriptive contents written in R. We designate “the patterns” written in R “R-rule.” R-rule describes actions that are executed when an event occurs. An event corresponds to a change of train schedule, such as a train cancellation.
Rescheduling
163
Figure 5 illustrates operations of R-interpreter. R-interpreter handles events at Working Stage based on R-rule, train schedule data and the current states of Working Stage. When R-interpreter is not able to find any of R-rule applicable to the current state, R-interpreter aborts its operations. R-rule consists of three parts as below: (1) (for each) section Describe an event that behaves as a trigger of “the pattern”. Rinterpreter searches the initial schedule for the trigger. In the case that the trigger is found, R-interpreter will try to check the conditions described in (if_exists) section. (2) (if exists) section Describe conditions for actions. (3) (then) section Describe contents of actions. Schedule of Schedule of a train-set a train-set Schedule Schedule Schedule of a train of a train of a train
LOAD
Train Schedule Data Cancellation of a train Cancellation of a train
Schedule change of a train-set
LOAD MODIFY DELETE CREATE
R-interpreter
Working Stage
R-rule
Figure 5: Operations of R-interpreter. Figure 6 shows an example that describes TRP-1 as shown in Figure 2. This description includes Japanese characters (Kanji and Kana characters), readily usable for Japanese train dispatchers. It is obviously possible to modify Rinterpreter to deal with R-rule specified with only alphabetical characters. The descriptive content in the (for each) section in Figure 6 represents a cancellation of a train between station-A and station-E. This cancellation corresponds to that of train-X in Figure 2. The description in the (if exist) section represents conditions to be checked. In the (if exist) section in Figure 6, the following conditions are specified; ・ Existence of express train-Y that is operated from station-E to station-A (the same operating section as train-X’s but the opposite direction). ・ Existence of express train-Z that departs from station-A. The (then) section in Figure 6 specifies actions of TRP-1. These actions correspond to the resultant schedule in Figure 2 are as follows: ・ Cancellation of train-Y ・ A train-set for train-X is operated as train-Z
164 Timetable Planning and Information Quality begin Pattern_1 for_each ( 運転休止[始端駅 = A, 終端駅 = E] =: x in WS ) if_exist (列車駅[列車番号 = x.列車番号, 駅 = A, 列車種別 = 快速, 運転方向 = 下り] =: q, 列車駅[列車番号 = x.列車番号, 駅 = E, 列車種別 = 快速, 運転方向 = 下り] =: r, 列車[列車番号 = 後運用列車(x.列車番号)] =: w, 列車駅[列車番号 = w.列車番号, 駅 = E, 列車種別 = 快速, 運転方向 = 上り] =: s, 列車駅[列車番号 = w.列車番号, 駅 = A, 列車種別 = 快速, 運転方向 = 上り] =: t, 列車[列車番号 = 前運用列車(x.列車番号)] =: y, 列車駅[列車番号 = y.列車番号, 駅 = A, 列車種別 = 快速, 運転方向 = 上り] =: u, 列車[列車番号 = 後運用列車(y.列車番号)] =: z, 列車駅[列車番号 = z.列車番号, 駅 = A, 列車種別 = 快速, 運転方向 = 下り] =: v ) then (generate 運転休止 in WS ( 列車番号=y.列車番号, 始端駅=E, 終端駅=A ) generate 車両運用変更 in WS ( 前運用列車番号= y.列車番号, 後運用列車番号= z.列車番号 ) ) end Pattern_1
Figure 6: Description of TRP-1 in train rescheduling pattern language R.
4
Framework of a train rescheduling system
4.1 Framework of a train rescheduling system Train rescheduling is a complicated and large-scale task. A train rescheduling system, which supports train rescheduling tasks, should have a comprehensive structure. Figure 7 indicates a framework for a comprehensive train rescheduling system. The framework consists of five subsystems: Train scheduling subsystem, Trainset rescheduling subsystem, Train rescheduling (in the narrow sense) subsystem, Crew rescheduling subsystem and Shunting rescheduling subsystem. Each of the subsystems exchanges relevant information and prepares each scheduling plan in cooperation with other subsystems. It is necessary to distinguish operations that have different reasons. For example, a reason for a cancellation of a train is likely to be one of the following: a) In the case where a train is an express-service, a long delay loses its worth to arrive at a destiniation earlier. b) There is no train-set that can be assigned to the train. c) In order to restore the train traffic. Therefore, Train scheduling subsystem, Train-set rescheduling subsystem, Train rescheduling (in the narrow sense) subsystem have each cancellation operation.
Rescheduling
&DQFHOODWLRQRIDWUDLQ EHFDXVHRIEHFRPLQJXQZRUWK\
165
6HWDQH[WUDWUDLQEHFDXVHRI SDVVHQJHUGHPDQG 7UDLQVFKHGXOLQJVXEV\VWHP
&DQFHOODWLRQRIDWUDLQ EHFDXVHRIWUDLQVHWUHVFKHGXOLQJ
6HWDQH[WUDWUDLQ EHFDXVHRIWUDLQVHWUHVFKHGXOLQJ
7UDLQVHWUHVFKHGXOLQJ %HFDXVHRIDQRWKHUWUDLQVHWUHVFKHGXOQJ 7UDLQVHWUHVFKHGXOLQJVXEV\VWHP
&DQFHOODWLRQRIDWUDLQ WRGHFUHDVHSDVVHQJHUVಬFRPSODLQWV
&KDQJHRIWUDFN
7UDLQVHWUHVFKHGXOLQJ WRGHFUHDVHSDVVHQJHUVಬFRPSODLQWV
&KDQJHGHSDUWXUH VHTXHQFH
6WDWLRQVKXQWLQJ UHVFKHGXOLQJ 7UDLQUHVFKHGXOLQJ LQWKHQDUURZVHQVH VXEV\VWHP
&UHZUHVFKHGXOLQJ &UHZUHVFKHGXOLQJVXEV\VWHP
'HSRWVKXQWLQJ UHVFKHGXOLQJ 6KXQWLQJUHVFKHGXOLQJVXEV\VWHP
Figure 7: Framework of train-rescheduling system. 4.2 Train rescheduling algorithm We propose an algorithm based on the framework shown in Figure 7. With the example of Figure 1, operations of each subsystem are indicated as follows: [Train scheduling subsystem] Train scheduling subsystem determines cancellations of trains and creation of extra trains. In Figure 1(b), the following cancellations are determined based on usage of R-interpreter as shown in Section 2. ・ Between station-C and station-E, train-2, train-4, train-5, train-9 and train-11 are cancelled. ・ Between station-B and station-E, train-6 is cancelled. ・ Between station-A and station-E, train-7 and train-8 are cancelled. ・ Train-9001, train-9003 and train-9005 are created. [Train-set rescheduling subsystem] Train-set rescheduling subsystem prepares a train-set operating rescheduling plan. In Figure 1(b), no train-set is assigned to train-10 and train-12. Then, train-sets for train-9001 and train-9003 assigned to train-10 and train-12 respectively. A train-set rescheduling algorithm [10] is applicable in this instance. [Train rescheduling (in the narrow sense) subsystem] Employed a train reschedule algorithm [9], this subsystem solves the detailed problems like track conflicts. The following rescheduling operations are dealt with:
166 Timetable Planning and Information Quality Cancellation, Extra trains, Change of track, Change departure sequence, Change train-set operating schedule and etc. [Crew rescheduling subsystem] For the rescheduling plan, this subsystem enables to prepare a crew rescheduling plan with a crew rescheduling algorithm [11].
5
Results of experiments and evaluation of our algorithm
We have evaluated the effectiveness of our train rescheduling algorithm using actual train schedule data. For experiments, we selected a line that has 20 trains an hour. An accident that requires an hour train suspension assumed as indicated by a black thick line, therefore, trains heading for the downward direction are not able to go into the location for an hour. Table 1: Evaluation values of algorithms. Algorithm Without rescheduling (Figure 8(a)) Existing algorithm [6] Proposed algorithm (Figure 8(b))
Accident
Evaluation value 2138 686 331
Accident
Time (a) Disrupted schedule
Time (b) Resultant schedule
Figure 8: Disrupted schedule and Resultant schedule. As an index for evaluation, we employed “dissatisfaction index” proposed in [9]. This index indicates the level of passengers’ dissatisfaction, if the value is small; we regard the algorithm works satisfactorily. Table 1 indicates the result of the comparative evaluation. Because the value of the proposed algorithm is the smallest, we can conclude that the proposed algorithm has made a better rescheduling plan than the existing algorithm. While the existing algorithm tries to prepare a train rescheduling plan tardily from the
Rescheduling
167
beginning, the proposed algorithm can utilize appropriate rescheduling policies given as R-rule in advance. Since R-rule contains expertise of a skilful dispatcher, the proposed algorithm can prepare a practical rescheduling plan. In addition, we can find obvious differences between disrupted schedule (no operation is executed) shown in Figure 8(a) and the resultant schedule shown in Figure 8(b).
6
Conclusions
We proposed an algorithm for automatic train rescheduling with a train rescheduling pattern language processing system. Applying it to actual train schedule data, we have confirmed that our algorithm works satisfactorily, especially for heavy train traffic disruption caused by an accident requiring a train suspension for more than an hour, where the algorithm can produce a rescheduling plan suitable for practical use.
References [1] Tomii, N., Techniques to make train diagrams for punctuality (in Japanese), Seizando Publishing, pp. 124-173, 2005. [2] Goodman, C. J. & Takagi, R., Dynamic re-scheduling of trains after disruption, Computers in Railways IX, eds. J. Allan, C. A. Brebbia, R. J. Hill, G. Sciutto & S. Sone, WIT Press, pp. 765-774, 2004. [3] Nakamura, T. & Ihara, K., The present situation and problems of train traffic control systems (in Japanese), IEEJ Journal, 124(5), pp.279-283, 2004. [4] K. Ghoseiri, F. Szidarovszky, M. Asgharpour, A multi-objective train scheduling model and solution, Transportation Research Part B 38, 2004. [5] J. Tornquist, Computer-based decision support for railway traffic scheduling and dispatching: A review of models and algorithms, ATMOS2005, 5th Workshop on Algorithmic Methods and Models for Optimization of Railways, 2005. [6] W. Koch, RegiDisp, A Cost Effective Optimization of Regional Traffic – State of the Art and Future Possibilities, RailHannover 2007, 2nd International Seminar on Railway Operations Modelling and Analysis, Hannover, 2007. [7] A. D'Ariano, F. Corman, I.A. Hansen, Railway traffic optimization by advanced scheduling and rerouting algorithms, WCRR2008, World Congress on Railway Research, Seoul 2008. [8] S. Wegele and E. Schnieder, Dispatching of train operations using genetic algorithms, RailDelft2005: 1st International Seminar on Railway Operations Modeling and Analysis, Delft, the Netherlands, 2005. [9] Tomii, N., Tashiro, Y., Tanabe, N., Hirai, C. & Muraki, K., Train rescheduling algorithm which minimizes passengers’ dissatisfaction, Proc. 18th Int. Conf. on Industrial and Engineering Applications of Artificial Intelligence and Expert Systems (IEA/AIE 2005), M. Ali & F. Esposito eds., LNCS 3533, Springer, pp. 829-838, 2005.
168 Timetable Planning and Information Quality [10] Hirai, C. Tomii, N. & Tanabe, N., An algorithm for train set scheduling problems toward Cyber-Rail (in Japanese), Transportation and Electric Railway, TER-02-46, IEEJ, 2002 [11] Fujimori, A. & Tomii, N., A Crew rescheduling algorithm based on combinatorial auction model (in Japanese), Information Technology Letters, 3, LA-006, pp. 15-18, 2004.
Rescheduling
169
The contribution of state resources in a constraint-based scheduling model for conflict solving at railway junctions J. Rodriguez INRETS (Institut National de Recherche sur les Transports et leur Securite), ´ ´ Villeneuve d’Ascq, France
Abstract Scheduling is the process of allocating resources to activities over time. In a scheduling problem, resources are scarce and constrained in various ways (e.g. in the order of activities and the capacity of resources), and one is looking for a schedule of the activities that both satisfies the constraints and is optimal according to some criterion. Over the last decade, constraint-based scheduling (CBS) has become the dominant form of modelling and solving scheduling problems. This paper deals with a CBS model of real time management of train traffic through junctions, it focuses on the use of state resources to improve the model of conflicts between trains running in opposite directions.
1 Introduction The railway industry has to improve the quality of service provided in order to increase freight and passenger market-shares. One important parameter that affects the quality of service is the efficiency and the effective use of resources. To achieve this aim, one solution is the use of computer-aided systems in planning and traffic control. A significant part of these computer-aided systems involves the model and the solution method of the optimisation problem, associated with real situations and decisions to be taken. When traffic on connecting lines of a junction is heavy, the junction is likely to be a critical resource. As a consequence, small disruptions are amplified. A few seconds originally can quickly lead to a delay of more than 5 minutes. To limit this
.
170 Timetable Planning and Information Quality phenomenon, new tracks, points and fly-overs can be built. Space and investments are needed for such extensions. However, such solutions are unlikely to be feasible in the short or medium term or impossible to implement in urban areas. This provides the motivation for the study of new methods and models to optimise the use of scarce resources like rail junctions. Concerning traffic control at a junction, the operator must perform the following tasks : 1. Analyse and select relevant information coming from the field, 2. Compare data with planned schedules, 3. Detect or anticipate conflicts, 4. Select and evaluate alternative solutions that reduce delays caused by conflicts, 5. Choose and implement a solution. In this context, a computer-based assistance can be used for the first four tasks to improve the quality of the final solution. Task 4 can be formulated as an optimisation problem, the decision variables are the selection of the alternative routes and sequences for trains and the criterion is the sum of delays. This model and the solution method is part of the computer-aid system; nevertheless, the final decision must be left to the operator. During the last decade, the problem of railway traffic management has been many times addressed by using a constraint-based scheduling (CBS) approach. An earlier attempt was in [1]: the application was the compilation of a railway timetable i.e. to construct a schedule of trains arrival-departure at each station of a line. The arrival-departure times must satisfy a set of temporal constraints. Further to this contribution, constraint propagation and scheduling theory has been drawing the attention of researchers to solve railway traffic management problems. We can mention here some studies and applications : • The generation of timetables for the suburban railway network of Melbourne [2], • SAGITAIRE : a tool for the design of one day operation of the schedules, platform and route assignments of the trains for “Gare du Nord” station in Paris [3], • PRaCoSy : a project for the automation of the preparation and updating of the running map for a section of the Beijing-Guangzhou line in China [4], • CAPRES : a tool to analyse the capacity of railway networks with a saturation method [5], • The scheduling of trains on single track networks [6, 7], • COMBINE2 : a European project which aim was to define a conflict resolution model to use in control centres for fixed and moving block signalling systems [8], • A generic tool for the National Network of Spanish Railways which covers many functions such as analysing the capacity, identifying bottlenecks, providing alternative planning and real-time traffic control [9]. Our first CBS formulation of the traffic management problem at junction was in [10], the last updated and detailed description of the model was in [11].
Rescheduling
171
In this paper, we present an extension of the model of [11] by using state resource constraints. These kinds of constraint are redundant constraints. The state resource constraints allow a better management of conflicts between trains running in opposite directions in a section of track. The paper is organised as follows: our CBS formulation of the railway traffic management is introduced in section 2. Within the framework of this model, we define in section 3 the opposite direction conflicts and the state resources associated. In section 4 the constraints between the activities and the state resources are defined according to different value assignments of the decision variables. Finally, section 5 gives some preliminary results and issues.
2 Constraint-based scheduling model The basic idea of the model is that a train passing through a junction is a job. According to scheduling theory, the concept of job is a set of activities linked by a set of precedence constraints. The movement of a train is a sequence of activities. Each activity is an elementary movement of the train through a track circuit. This is illustrated in figure 1. As the train remains on track circuit until the next one becomes available for running, this limitation is named a “blocking constraint” in scheduling theory. Therefore our model is similar to that of blocking job shop scheduling problem [8, 12]. The constraints of our model will be roughly introduced, there is a more detailed formulation in [11]. The constraints of the problem can be formulated as follows: • As each track circuit is a resource, the choice of a route for a train is turned into resource assignments for a sequence of activities. A constraint enumerates the combination of tuples of values allowed for the route and track circuit variables. • The track circuits are modelled as unary resources, this leads to the constraint that two activities requiring the resource cannot overlap in time. • Within the duration of an activity, we distinguish the detection phase. For each train, a constraint links the route values with the earliest start and finish time of detection phase of each activity. • For each activity, a waiting time variable models the time spent when the next resource is not available. This time is added in the expression of the duration of the activity. • The headway constraint between successive trains due to the block signalling system is formulated with a “synchronisation constraint”. Let us consider a block signalling system with two aspects. In that case,a train enters a block if no train is detected inside. Therefore, to enter a block, all track circuits inside the block must be available at the same time. The start of each activity related to one block has to be synchronised with the start of the detection on the first track circuit of the block. For the general case of a block system with n aspects, the synchronisation is established with .
.
,
172 Timetable Planning and Information Quality
Figure 1: Train movement as a sequence of activities.
Figure 2: Gantt chart of activities for 3-aspect block signalling system. the entrance in the first track circuit of the n − 2th previous block (e.g. see hatched rectangles for n = 3 in figure 2). For train scheduling, the criterion frequently used is the sum of train delays caused by conflicts. This criterion is formulated with the sum of the waiting time variables.
3 Opposite direction conflicts Let us define a “conflict sequence” as a common sequence of track circuits requested by two trains. There will be a running conflict when both trains request one track circuit of the conflict sequence during a common time interval. To arbitrate the conflict, the train circulations are ranked on the conflict sequence, i.e. the corresponding activities are ranked according to the train rank decision. For the case of a conflict sequence between routes running in the same direction, a rank decision on one activity implies all ranks of the other activities. This propagation of the rank decision is due to the blocking constraint (see section 2). However, in the case of an opposite direction conflict, there is no propagation of the rank decision; all the activities of the conflict sequence have to be ranked. The search algorithm for a feasible schedule is based on rank decision of activities. When there are opposite direction conflicts, the search algorithm will slow down as it needs more backtracks to find feasible ranks.
Rescheduling
173
Figure 3: Example of 4 opposite conflict sequences.
cf 1 cf 2
cf 3 cf 4
Figure 4: The Hasse diagram of conflict sequences.
To propagate the rank decision along the activities of an opposite direction conflict, we suggest using a state resource. A state resource is characterised as follows: • It has an infinite capacity, • The state can vary over time. • Each activity may, during its execution, require it to be in a given state. • Two activities may not overlap if they require incompatible states. In the context of a railway traffic optimisation problem, a state resource models the allowed running direction during time along the conflict sequence. Therefore a state resource with 2 states (one for each direction) is associated with each opposite conflict sequence. The next section describes the constraints to post in order to obtain a correct propagation of rank decisions.
174 Timetable Planning and Information Quality
4 State resource constraints The state resource constraints that can be posted depend on the resource assignment variables chosen for extending a partial solution during the search. Two cases have been considered: route assignment and track circuit assignment. 4.1 Route assignment In this section we consider that the state resource constraints are posted after the routes are assigned to trains during a search algorithm. When a train is entering on the conflict sequence, the running direction will be constant from the start time of the first activities until the end time of the last activity. To satisfy this requirement, we define a constraint requiring that the state of the state resource has be constant during all the activities of the conflict sequence. To formulate the constraint, let Ct(t, cf i, state) be the constraint of the state resource of cf i in state state for a train t. This constraint is the conjunction of the state resource constraints of all activities of the conflict sequence i.e. : Ct(t, cf i, state) = activity(t, zj ).requires(cf i.resource, state) zj ∈cf i
To illustrate this constraint, let us consider the example of figure 3. The opposite direction of the routes R1 and R2 yields the conflict sequence cf 1 :< z1, z2, z3, z4 >. If a train is running on route R1, the state resource associated to cf 1 must be on the state E during the running through all the track circuits of cf 1 . The state constraint of the route R1 is then : Ct(t, cf 1 , E) = activity(t, z1 ).requires(cf 1 .resource, E) ∧ activity(t, z2 ).requires(cf 1 .resource, E) ∧ activity(t, z3 ).requires(cf 1 .resource, E) ∧ activity(t, z4 ).requires(cf 1 .resource, E) . The state resource of the route R2 is similar, but with the state W . The rank decisions to arbitrate a conflict between two trains t1 , t2 requiring any track circuit of cf 1 will be translated as one of the rank decisions : • activity(t1 , z4 ) ≺ activity(t2 , z4 ), • activity(t1 , z1 ) ≺ activity(t2 , z1 ). This results is obtained by the constraints Ct(t1, cf 1 , E) and Ct(t2, cf 1 , W ) which propagates the decision along the conflict sequence. 4.2 Track circuit assignment Let now consider the case of extending a partial solution of a problem with track circuits assignments to trains. The question is then : what are the sufficient conditions to post a state resource constraint ? To answer the question, let us consider again the example of figure 3. There are 4 conflict sequences : • cf 1 :< z1, z2, z3, z4 >,
Rescheduling
175
• cf 2 :< z1, z2 > , • cf 3 :< z2, z3, z4 > , • cf 4 :< z2 >. The conflict sequence set with the inclusion relation (symbol ⊆) is a partially ordered set. This order can be graphically displayed as a Hasse diagram. Figure 4 is the Hasse diagram of the conflict sequences of the example of 3. In the Hasse diagram, each conflict sequence is represented as a vertex and a line is drawn upward from cfi to cfj if cfi ⊆ cfj , and there is no cfk such that cfi ⊆ cfk ⊆ cfj , we say that cfj covers cfi . When a track circuit is assigned to a train, the following rules are used to post constraints: Rule 1: If a the track circuit zi is assigned to a train then post the state resource constraint of least conflict sequence which includes zi (noted lcs(zi )). Rule 2: For all conflict sequence cfi covered by lcs(zi ), post state resource constraint of cfi . To illustrate Rule 1, let us consider the example of figure 3, and the case of the assignment of track circuit z1 to a train in the E direction. According to the rule, the state resource constraint requiring the conflict sequence cf 2 in E direction is posted. Indeed, cf 2 is the lcs(z1), i.e. none of the conflict sequences which include z1 is a subset of cf 2 . Note that cf 1 includes z1, but it is not the lcs(z1) as cf 2 is one of the subsets of cf 1 (see the upward line of the Hasse diagram in figure 4). The second rule concerns the conflict sequence covered by the least conflict sequence. We can take the as an example the figure 3 and the case of the assignment of track circuit z1. As the resource of cf 2 is required by the train in direction E, to avoid inconsistencies, we must require the resource of the covered conflict sequence cf 4 in the same direction and during the same interval. So, after the assignment of z1 to the train, the state resources of cf 2 and cf 4 will be required in the state E, whatever the route assigned afterwards.
5 Results and conclusion The extension of our CBS model presented here has been implemented and successfully validated on the infrastructure of the Pierrefitte-Gonesse junction. Table 1 shows some preliminary results on a set of growing size problem instances. The column headings in the table have the following meanings: #t : Number of trains of the problem instance, CBS : CBS model of section 2 , CBS+SRC : CBS model with the state resource constraints extension, Crit : Criteria of the best solution found, CPU BT
: Computation time in CPU seconds to find the best solution, : Number of backtracks of the search algorithm.
176 Timetable Planning and Information Quality
Table 1: Computational results.
Inst. #t
CBS Crit CPUa
BT
CBS+SRC Crit CPU a
1
6
64
1.63
BT
206
64
1.91
138
2 3
8 8
64 66
1.75 2.4
631 721
64 66
2.42 3.1
322 304
4 5
10 12
161 161
33.42 68.66
8774 9848
161 161
22.33 43.91
1172 1286
6
14
313
339.6
27 323
258
832.12
13 646
7 8
16 18
350 498
704.93 24 789 955.67 9055
258 461
1199.3 646.02
14 379 7739
9 10
20 22
512 648
345.2 11 994 718.08 5084
498 609
1585.14 7611 1593.16 4135
a
In seconds using a 2.66GHz Pentium IV processor, Ilog Solver 5.3 and Ilog Scheduler 5.2
The bold face values show the improvements of the state resource constraints extension of the CBS model. For the problem instances used here, searching for an optimum value is not a realistic goal. In order to apply a resolution method and obtain good solutions within a limited time, an heuristic approach has been considered (see [11]). The two models have been tested with the same CPU limits. The first observation is that the number of backtracks has been significantly reduced for all instances. As we also obtain a better or the same criteria solution, this shows that the redundant constraints have pruned many branches of the search tree. For example in the instance #5, the number of backtracks has been reduced from 9848 to 1286 and the criteria has been reduced from 68.66 to 43.91. In what regards the criteria values, we remark that the improvements have been obtained with the large instances. This can been explained by the computational time needed to calculate the state resource constraints conditions (see section 4). This time increases very slowly with the instance sizes and therefore has more impact in small instances than in large instances. As a conclusion, the state resource constraints show very promising preliminary results in what regards the resolution performances. This first attempt of using these kinds of constraint need further researches. Some improvement issues have been identified regarding : • The reduction of the number of constraints needed, • The combination of assignment and scheduling heuristics of the solution algorithm, • The testing of the practical limits of some complete scheduling algorithms,
Rescheduling
177
• An interesting future task is also to study in depth the performances of different models and resolution methods as initiated in [13], having in mind the goal of the potential integrations of different approaches.
References [1] Fukumori, K. & Sano, H., Fundamental algorithm for train scheduling based on artificial intelligence. Systems and Computers in Japan, 18(3), 1987. [2] Gosselin, V., Train scheduling using constraint programming techniques. Charme Technical Bulletin, (3), 1993. [3] Poujade, M., Moyon, P. & J.F., P., Sagitaire: Allocation des quais de la gare Paris-Nord. Conf´erence IA’95, 1995. (in french). [4] Chiu, C.K., Chou, C.M., Lee, J.H.M., Leung, H.F. & Leung, Y.W., A constraint-based interactive train rescheduling tool. Second International Conference on Principles and Practice of Constraint Programming, pp. 104– 118, 1996. ´ [5] Hachemane, P., Evaluation de la capacit´e de r´eseaux ferroviaires. Th`ese ´ 1632, Ecole Polytechnique F´ed´erale de Lausanne, 1997. (in french). [6] Kreuger, P., Carlson, M., Olsson, J., Sj, T. & o Astr, Trips scheduling on single track networks - the tuff train scheduler. CP’97 Workshop on Industrial Constraint - Directed Scheduling, pp. 1–12, 1997. [7] Oliveira, E.S., Solving Single-Track Railway Scheduling Problem Using Constraint Programming. Ph.D. thesis, School of Computing - University of Leeds, 2001. [8] COMBINE2 project IST-2001-34705, Traffic regulation and co-operation methodologies. Deliverable D3, Univerita degli Studi Roma Tre, 2003. [9] Barber, F., Salido, M.A., Abril, M., Ingolotti, L., Lova, A. & Tormos, P., An interactive train scheduling tool for solving and plotting running maps. LNCS/LNAI, (3040), pp. 659–668, 2004. [10] Rodriguez, J. & Kermad, L., Constraint programming for real-time train circulation management problem in railway nodes. Computers in Railways VI, WITPress: Lisbonne-Portugal, 1998. [11] Rodriguez, J., A constraint programming model for real-time trains scheduling at junctions. Transportation Research Part B : Methodological, 2006. In press. [12] Mascis, A. & Pacciarelli, D., Job-shop with blocking and no-wait constraints. European Journal of Opera- tional Research, (143), pp. 498–517, 2002. [13] Delorme, X., Rodriguez, J. & Gandibleux, X., Heuristics for railway infrastructure saturation. Electronic Notes in Theoretical Computer Science 50 N1(2001) URL: http://www.elsevier.nl.locate/entcs/volume50.html, pp. 41– 55, 2001.
This page intentionally left blank
Rescheduling
179
A Petri nets based decision support tool for railway traffic conflicts forecasting and resolution S. Ricci & A. Tieri Department of Hydraulics, Transport and Roads (DITS), Sapienza - University of Rome, Italy
Abstract The full paper describes current results and applications of an ongoing research concerning the operational simulation of complex railway systems based on working criteria and operational rules of interlocking and line signalling systems. Modelling is based on object oriented approach by the Petri nets formalism, that allows high processing openness and modular building without breaking away from the safety systems logic. The development of a full model includes the integration of a Common module to be applied to any layout and interlocking technology, a Timetable module capable to simulate the operational program, a Movement Inspector module to manage traffic priorities automatically and finally a Top Level module where a specific layout and its routes are modelled. The software tool used is a specific software for extended Petri Nets development, validation and simulation (Faber©), that allows modularity in Petri nets definition and manages variables and types declaration, being endowed with a C language interpreter. The tool could be used both for regularity forecasting and in decision support systems for the management of conflict resolution. For these goals the model was largely tested on the Roma-Formia railway, an Italian high density traffic line. The tests include simulations of traffic regularity monitoring and forecasting in both un-perturbed and perturbed conditions, by generating delays of sets of trains along the line and by verifying the response of the system in comparison with measured delays. Keywords: Petri nets simulation, railway traffic management, automatic overtaking.
180 Timetable Planning and Information Quality
1
Introduction
The possibility to improve the capacity of railway lines, honouring the regularity levels fixed by the railway undertakings, may be verified or at least estimated with good approximation, during the planning phase through simulation models of railway operation capable to evaluate the potential criticalities, that obstruct the achievement of the above mentioned transport service levels. The models should usefully simulate the process with all boundary conditions imposed by infrastructure, signalling and control systems. Moreover they should be applicable for as large as possible sets of different railway systems, i.e. they should have high flexibility in the system representation. The research aims at building a model with described characteristics, joining in already achieved simulation modules of the operation of single elements of railway operation control systems (switches, track circuits, signals, etc.), through the reconstruction of their logical connections, using Petri nets graphic language. So far, with the software Faber© capable of drawing and simulating hierarchical, extended and coloured Petri nets, were built a complex station model based on ACC and relay interlocking systems and various line models. During the research, the same formalism was used to design a model for traffic regularity analysis, switching from a micro to a macro approach applied to railway operation. Final goal of this research is a simulation model structuring based on Petri nets for line capacity and railway operation regularity, capable to support the effectiveness and efficiency evaluation of infrastructural and/or operational improvements to the railway system.
2
Architecture of the railway model for regularity analysis
The model was built using Petri nets to represent elements of operation signalling and control systems according to an object oriented approach. The railway line (Roma-Formia double track high traffic line was used for model calibration), is divided in finite elements that, conveniently designed and assembled, can be repeated and composed to describe any railway system with similar signalling and control equipment [1]. Like shown in Figure 1, the model includes three modules (Common module, Movement Inspector and Timetable, inserted in a fourth module, the Top Level, in which is represented the infrastructure layout, with the objects of Common module and the route functions that trains will follow during their running over the railway line. 2.1 Common module All physical elements of the signalling and control systems are designed into the common module. The elements represented in the regularity model are: track circuit, switch, advanced signal, block signal.
Rescheduling
181
Top Level Common Module
Infrastructure Layout Timetable
MovInsp
Figure 1:
Route functions
Model structure.
These classes of objects are drawn through many subnets, each with a particular function. They are developed so that can have all possible options along the line; in this way it is possible to use the same class also for different situations, without redrawing objects for particular conditions. Therefore, for instance, the unique class Track circuit can be used indifferently in both traffic directions, last or intermediate track circuit of a route, in the operations of freedom check, route interlocking and running. Practically, the classes of objects are as much as possible “universal” and this fact allows the railway line representation simply “cloning” and linking with dedicated portsets the objects. 2.2 Timetable module In this module the subnets that manage the train departures according to desired operational timetable are drawn. It is possible to modify the timetable simply changing some parameters in a text file into the simulation environment of Faber©. This opportunity are very useful in the study of perturbed timetable, when, for instance, it is possible to impose on a train a fixed delay and to verify what happens to the global traffic on simulation. 2.3 Movement inspector module The model is equipped with an automatic overtaking function for different train types. The Movement Inspector module plays the role of manager of this overtaking system, comparing in prearranged line sections the train arriving before with those arriving after. Obeying to a structured priority order, this module commands to the first train a route change with stop in the first available station if the second train has a planned overtaking, but it cannot reach its operational speed due to the line occupation by the first train. The model the can also work in manual mode, i.e. not activating the Movement Inspector Module.
182 Timetable Planning and Information Quality Practically the model is thought like a decision support tool and for this reason the user can freely choose to manage the overtaking system both manually, like often happens in a real Movement Inspector, and automatically with a train category system, so that it is possible to compare real and simulated delays. 2.4 Top level The Top Level is the place where all the objects designed in the previous modules are stored. In this class there are two types of functions: • the first is to represent the physical layout of the railway line, with all the elements of the net; • the second is to draw the different route functions existing along the line and in the stations. 2.5 Used token types In order to allow the information movement across the model subnets, an important property of Extended Petri nets is used, i.e. a token can be defined like STRUCT variable becoming a real data record. This because in Faber© is possible to insert codes in C or C++ in each transition. This means the possibility to constrain the transition firing to come true of a programmed condition, one between usual types IF-THEN-ELSE, WHILE-DO, CASE-DO or, on the contrary, to perform a particular action, for instance to modify values of STRUCT variable represented by a token located in an input place of a transition when the same transition fires. In the model three types of tokens are represented: TRAIN, MA and NUL. The TRAIN token is used in the subnets of track circuits and switches that simulate the train running; it is a STRUCT variable defined by following simple variables: • ID_TRAIN, the ID code of train; • CAT, the category of train (high speed, national, regional, freight); • TIME, absolute time of running; • DIR, direction of traffic; • L, length of the block section where is the train; • PROG, progressive kilometre of the line where is the train; • DIST, distance from the next station; • SPEED, current speed of the train; • PR, priority order, binary variable that communicates to the train to give way to the train after, changing the first possible route and waiting for the next train with the right of way; • ITINxL, route in x station, left side; • ITINxR, route in x station, right side. Obviously, the number of simple variables needed to define the TRAIN token increases according to the number of stations increase.
Rescheduling
183
The MA token, i.e. the Movement Authority, enters in all subnets representing logical functionalities applied on train different from running. Therefore it is in the subnets representing freedom check of a route, route interlocking, release of route-locking, communication with signals, etc. Also MA is a STRUCT variable, defined by the following simple variables: • ID_TRAIN, the ID code of train; • DIR, direction of traffic; • ITINxL, route in x station, left side; • ITINxR, route in x station, right side. Therefore, if the number of station increases also increase the simple variables to insert in MA. The last type of token existing in the model is the simple variable NUL, used only to activate some transitions with logical conditions independent from train actions, but necessary for model functioning. 2.6 Model output The simulation environment has a visual simulator and an output text file. In the simulator it is possible to select every page or subnet and to check the tokens movements and the system evolving through the colours that are set up in phase of net building. In the text file there are the information desired by programmer and in particular the time of simulation, the ID object code, the action and the token. In Figure 2 it is possible to see a simulation window: a station (Torricola) during the running (fuchsia objects) of a train on a locked route (green objects).
Figure 2:
Simulation environment and output file.
At the right of the same figure there is the output text file: it reports the actions, in particular freedom check, interlocking, track occupation, running (column 3), of the train number 2381 (column 4) over each object (column 2), and the time of the action (column 1).
3
Model application to railway traffic conflict resolution
In comparison with the past models [1, 2] the subnets of different classes of objects have been modified to be able to interact with the new module Movement Inspector.
184 Timetable Planning and Information Quality To show better the potentiality of this new module as decision support tool for the increase of traffic regularity, some examples of possible applications, with or without the manager of automatic overtaking will be shortly described. Examples and figures concern the first model application on the RomaFormia, Italian railway line with 10 stations, many hundreds of routes, almost 700 elements between track circuits and switches and with 63 trains running in the morning peak period timetable from 7:00 to 10:00. The line was perfect for model calibration both for high criticality in terms of traffic regularity and because it has some morphological complexities (e.g. two branch single track lines towards Terracina and Nettuno and tracks run in both directions). Moreover, the model was tested on Roma Ostiense, large and complex station with 15 running tracks and a electronic interlocking system (ACC). 3.1 Standard mode In case of standard mode functioning, the possible traffic and stabling conflicts are solved through a simple ‘first in first out’. This mode may be useful in phase of timetable planning on new line or timetable upgrading on existing line with new traffic demand or to verify circulation criticalities. In fact it is possible to simulate the theoretical operation timetable forcing the trains entrance into the railway line and starting the simulation. Then it is possible the comparison between the output file and the theoretical timetable and to check/correct conflicts or border line situations. The flexibility of the output file makes available any information about logical states of railway elements and trains and allows the data transferring in graphical output and synthetic index usual for railway world (e.g. the representation of the graphical timetable on whole line, with possible warning of conflicts). In figure 3 a portion of a simulated timetable from Roma to Formia is shown. When all the conflicts are detected, ion this mode it is possible to solve them “manually”, i.e. to delay the retarding trains and to run the simulation, with an iterative process that stops itself when ever the timetable perturbation is considered acceptable. This operation is very complex and strongly dependent on “sensitivity” of the movement authority. To decrease the stochastic effects due to human factor, a system of automatic overtaking with criteria defined into the Movement Inspector class of object has been conceived. 3.2 Traffic conflict resolution mode The problem of traffic conflicts resolution in a generic line can be approached with a fixed goal (e.g. the minimization of mean delay) for the elimination of conflicts in each station of the line. This operation requires the preventive definition of the problem constraints, (e.g. a fixed priority order between different classes of train). The model is very useful because it allows to change constraints and goals, so far an optimized solution is found as a result of many simulation run.
Rescheduling
185
11.24.00 1
10.48.00
5
10.12.00
17
7 11 19 21
hh.mm.ss
9.36.00
23
9.00.00
25 27
8.24.00
29 31
7.48.00
33 35 41 49
7.12.00
53 57 61
6.36.00
63
125,000
120,000
115,000
110,000
105,000
95,000
100,000
90,000
85,000
80,000
75,000
70,000
65,000
60,000
55,000
50,000
45,000
40,000
35,000
30,000
25,000
20,000
15,000
5,000
10,000
6.00.00
m
Figure 3:
Part of graphic timetable from simulation results.
Should our goal be the minimization of the delay generated by the conflict between two trains entering the same platform of a station, the model can execute the algorithm in figure 4. This shows the following possible solutions: • solution 1: the trains do not change their routes, the train B does not delay, the train A is delayed as much as no other trains are delayed; • solution 2: the trains do not change their routes, the train B does not delay, the train A has the minimum delay and consequently other trains are delayed; • solution 3: the trains do not change their routes, the train A does not delay, the train B has the minimum delay and consequently other trains are delayed; • solution 4: the trains do not change their routes, the train A does not delay, the train B is delayed as soon as no other trains are delayed; • solution 5: the train A changes his platform, the train B does not change his route, the train A is delayed as much as no other trains are delayed; • solution 6: the train A changes his platform, the train B does not change his route, the train A has the minimum delay and consequently other trains are delayed; • solution 7: the train B changes his platform, the train A does not change his route, the train B has the minimum delay and consequently other trains are delayed; • solution 8: the train B changes his platform, the train A does not change his route, the train B delays as much as no other trains are delayed. 3.2.1 Example of automatic overtaking subnet When in the model is active the class Movement Inspector, it manages the automatic system of overtaking.
186 Timetable Planning and Information Quality
Solution 1
N Conflict: Train A vs Train B
Solution 3
Other trains delay
Other trains delay
Train A delay
Train B delay
Train A platform change
Train B platform change
Other trains delay
Other trains delay
Solution 6
Solution 7
Solution 4
Platform Change
Solution 5
Figure 4:
Solution 2
Solution 8
Decision making tree for conflict resolution between two trains.
In this module each train is compared with the train running before and after in order to verify if and when an overtaking is necessary. The track circuits corresponding to platforms of stations are linked to Movement Inspector, so that as soon as the TRAIN tokens exit from this track circuit and enter in the next one, they are intercepted and move in a subnet of Movement Inspector, that sorts the different TRAIN tokens in other subnets depending on direction an kilometric progressive of the line.
Figure 5:
Part of subnet ‘Overtaking TOR_POM’ of class Movement Inspector.
Rescheduling
187
These subnets, similar to that shown in figure 7, perform the comparison between trains. In particular the net in figure 7 manages all the train running between two stations (Torricola and Pomezia) in a direction (towards Formia). The TRAIN token intercepted in line arrives in the common place TOR_POM. In the TRENO_AVANTI02A place is the TRAIN token corresponding to the train ahead. At this point the three transitions make the comparison according to the following criteria: a. the transition NO_PREC02A fires if the train behind has not right of way; this event happens if the train ahead is of higher category, if it run with a higher average speed, or if it is going to run in the next station a secondary route, different from the main line; b. the transition NO_RAGG02A fires if, also with right of way, the train behind does not reach the train ahead before the next station; c. the transition PRECEDENZA02A fires if the train ahead has a right of way and is fast enough to reach it before the next station. The reaching condition of the train ahead by train behind is the following: 1 1 tb < t f + d × − v f vb
,
with tb transit time of the train behind in the interception section, tf transit time of the train ahead, d distance from interception section to the next section, vf average speed of the train forward, vb average speed of the train behind. The firing of one of the three transitions causes in the TRENO_AVANTI02A place the substitution of the TRAIN token with the token TRAIN that before was in the TOR_POM place; this last token is now ready for the comparison with the next train. The transition firing of PRECEDENZA02, like the figure 7 shows, creates also one TRAIN token in the output place of the class Movement Inspector named PRIORITY_TOR_POM. This token represents the train behind and has a value in the PR variable that means “give overtaking”. The output place is linked on the Top Level to the track circuit located immediately before the next station (in this case Pomezia). In the track circuit the new TRAIN token substitutes the other that arrives from the line running with the order of changing the routes inside the Pomezia station and waiting for the running of the train behind. So the automatic overtaking is carried out. This control mechanism is active on all the stations, in both directions and on two-way operated tracks. A last fundamental consideration is that overtaking criteria above described are ever modifiable; this means creating more scenarios with different automatic overtaking systems and it is possible to choose the better criteria, which minimizes the average delay of the trains or that reaches other goals.
188 Timetable Planning and Information Quality
4
Conclusion
The proposed model can be applied in the studies of railway traffic regularity, for example comparing real measured delays with those simulated by the model in the same traffic conditions and finding the causes of specific criticalities. The flexibility of outputs file allows the detailed analysis of each element of the line, so that it is possible to have an exhaustive framework of traffic problems depending on railway infrastructure. Moreover the model can be effectiveness used as decision support tool both in phase of planning of new line with new operation timetable and in phase of improvement of existing lines with changed traffic conditions. Finally the main model application with an automatic overtaking system is the support to traffic management decisions finalised to minimise the delays. In fact, using more criteria for setting up the system, in case of delays of each train it is possible to define a decisional tree to limit the perturbation on whole traffic. The proposed model has been applied on the test line Roma-Formia. The goal is to describe a decision procedure that, depending on delay of each train in each station, allows an optimised traffic management.
References [1] Ricci, S., Tieri, A., Railway traffic regularity monitoring and forecasting: the use of the Petri Nets models, Proc. of the 6th Symposium, 2007 FORMS/FORMAT 2007 – Braunschweig, 118–128. [2] Impastato S., Ricci, S., Tieri, A., Monitoring and forecasting of railway traffic regularity by a Petri nets model, Proc. of the 4th Conference Challenges in Transport and Communication – Pardubice, 57–63, 2006. [3] Malavasi, G., Raponi, P., Ricci, S., Spellucci, C., Simulation of a complex railway station with a Petri Nets based interlocking model, Proc. of the Workshop on software specification of safety relevant transportation control tasks – Braunschweig, 11–22, 2002. [4] Malavasi, G., Ricci, S., Railway Traffic Simulation by means of a Petri Net model. Computers in Railways VIII, WIT Press, Southampton, 407–415, 2002.
Rescheduling
189
Comparing the effectiveness of two real-time train rescheduling systems in the case of perturbed traffic conditions S. Wegele1 , F. Corman2 & A. D’Ariano2,3
1 Institute
for Traffic Safety and Automation Engineering, Technical University of Braunschweig, Germany 2 Transport and Planning, Delft University of Technology, The Netherlands 3 Informatica e Automazione, Universit`a degli Studi Roma Tre, Italy
Abstract Rescheduling train traffic in a busy and complex railway area is a challenging task, partly because of the high number of constraints to be taken into account, and partly because of the many variables involved. Currently this task is performed almost exclusively by human traffic operators. Previous attempts to provide an automated decision support system have been limited to identifying and solving train conflicts locally. Recently, innovative dispatching support tools have been presented that are able to cope with large (real-time) timetable perturbations, such as train delays and their propagation. However, there is a lack of computational studies that underline their additional practical value. This paper compares two advanced support systems for real-time rescheduling of train operations, developed for the German and Dutch railway networks. The research aim is to establish a bench mark for future co-operation and exchange of innovative solutions. A common test case from the Dutch railway network, the dispatching area between Utrecht and Den Bosch, and disturbed traffic conditions are studied to evaluate the two dispatching support tools in terms of delay minimization. Since these tools make use of different mathematical optimization techniques for the computation of running times and train sequences, a detailed comparison of the proposed rescheduling solutions is provided. The use of railway capacity is illustrated in order to enable an easy and fast detection of the train conflicts and to get precise information about their resolution by the different rescheduling techniques. Keywords: decision support, computer techniques, dynamic train regulations.
190 Timetable Planning and Information Quality
1 Introduction Railway traffic is currently operated according to a timetable designed months in advance. However, during operations unforeseen events generate conflicts or even deadlocks in the network and rescheduling is therefore needed to obtain feasibility and to minimize the propagation of delays. To cope with this problem, dispatchers have to take rescheduling decisions on the basis of their experience or of predetermined rules to manage disturbed traffic situations. As a consequence, rescheduling decisions may be sub-optimal since there is a lack of information about the impact of these decisions on the future evolution of traffic flow. Dispatching support tools have been proposed to help dispatchers in performing their task more effectively. Such tools perform a thorough search in the space of solutions, analyzing the effects of multiple rescheduling decisions and computing feasible solutions (i.e., conflict-free and deadlock-free schedules) in a short time. This paper presents a comparative study to assess the effectiveness of two decision support tools for optimal rescheduling of train operations, developed for the Dutch and German railway networks (see respectively D’Ariano [1] and Wegele et al. [2]). A comparison between the tools is achieved thanks to the availability of railway instances in digital format in order to establish a bench mark for future co-operation and exchange of innovative solutions. The paper is organized as follows. Section 2 describes briefly the two dispatching support tools, identifying similarities and differences. Section 3 presents the computational experiments on a common test case, a Dutch railway dispatching area, for small delay situations. The results obtained by the two tools are compared in terms of delay minimization. Section 4 then gives conclusions on the performance comparison between the two tools.
2 Dispatching support tools Existing support tools for real-time train rescheduling can be characterized by the general architecture shown in Figure 1. Reliable and accurate data about the positions and speeds of the trains running in the studied area, as well as the infrastructure status and deviations from the timetable, are used in order to evaluate a number of scheduling options, that comply with the constraints of safety system and the current dynamics of trains. The best solution found is reported to the dispatcher for approval and practical implementation. The dispatching task is based on the following rescheduling techniques: adjusting the running time of trains in open track corridors (re-timing), changing the train sequences at merging and crossing points (re-ordering), modifying the train routes (re-routing) or even cancelling train services in case of large delays. The schedule re-optimization makes use of the above rescheduling techniques and considers usually an explicit objective function, such as the minimization of a weighted sum of delays or other functions based on train priorities. In the current dispatching practice, straightforward rules like first-come-first-served are adopted since these are simple to be implemented while in the related literature advanced
Rescheduling
191
Figure 1: Architecture of a general dispatching support tool. heuristics and metaheuristics have been developed with more promising results. However, advanced algorithms still have to be implemented in a dispatching support tool connected with actual track occupation and release data in order to automatically detect delays, headway and route conflicts. The precise computation of train dynamics, needed to forecast the traffic flow in the network, can be performed by different degrees of accuracy, for instance by solving the motion differential equation or using approximated expressions. Note that safety systems and operating rules may vary greatly from one country to another, influencing the way traffic flow is managed. We next describe briefly the Dutch tool ROMA and the German tool GADis. 2.1 ROMA system The ROMA (Railway Optimization by Means of Alternative graphs) system [1] is a laboratory dispatching support tool that integrates advanced OR techniques to solve global conflict detection and resolution problems with a precise modeling of the train dynamics and coordination of train speeds (see Figure 2). In the ROMA system, the train traffic flow is modeled as a job shop scheduling problem and represented by means of alternative graphs. Innovative train scheduling and rerouting algorithms have been developed for the resolution of complex global conflict detection and resolution problems. In this paper, we make use of a state-of-the-art branch and bound algorithm which includes static and dynamic implication rules enabling to speed up the computation, advanced initial heuristics, empirical branching rules and a fast and tight lower bound [3].
192 Timetable Planning and Information Quality
Figure 2: Core structure of the ROMA system. After a feasible (optimal) schedule has been computed by the branch and bound algorithm, a train speed coordination procedure based on blocking time theory (see e.g. Hansen and Pachl [4]) checks whether the minimum required headway distance between consecutive trains is respected. Otherwise, the train dynamics are precisely re-computed by means of acceleration and braking tables and according to the Dutch signaling system NS54 and the ATB train protection system [5]. 2.2 GADis system The GADis (Genetic Algorithm Dispatching) system [6] bases the optimization of rescheduling decisions on the following hybrid optimization method. Trains are inserted one by one and the resulting decision tree of train sequences and routes is explored by a branch and bound search. The resulting solution quality depends on the insertion order of trains and the penalty estimation function used during the search. After inserting all trains, a local optimal solution is obtained. The insertion order of trains and the penalty estimation function are then varied by evolutionary genetic algorithms in order to get another local optimum, which may eventually be better than the already calculated one (see Figure 3). To enable the GADis system to simulate a Dutch network, the infrastructure had to be translated into the RailML-based format. Since the cab signalling and train protection system has implemented the default German PZB90 (Punktf¨ormige Zugbeeinflussung, point-wise train protection) system combined with the LZB (Linienzugbeeinflussung, continuous train control) system, the block sections of the Dutch ATB (Automatische Treinbe¨invloeding, automatic train protection) system were too short for PZB90 distant signals. The ATB system had therefore to be converted into the LZB system and the position of signals has been modified accordingly, i.e., each block section is around one km long. 2.3 Overview of the main differences between the two tools Figure 4 gives a schematic description of some important features characterizing the two dispatching support tools presented in this paper. ROMA is applied to the Dutch three-aspect fixed block signaling system. If the minimum required headway distance between two consecutive trains is not
Rescheduling
193
Figure 3: Core structure of the GADis system.
Figure 4: Comparing features of the two dispatching support tools.
respected, the following train encounters a yellow or even red signal aspect and has to start deceleration until its speed is reduced to 40 km/h or 0 km/h respectively. Nevertheless, if the block section ahead becomes available, the signal is cleared and the following train may re-accelerate. In the current implementation of GADis, the signaling and train protection systems are simplified as follows. Each train checks the aspect of the current signal at the beginning of the braking curve; if the next signal aspect is red, the train will stop. In other words, a train is committed to stop whenever its distance from a red signal aspect is equal to the actual braking distance. Due to this assumption, the train performs a stop and re-acceleration from standstill even if the red signal aspect is cleared during braking. As a result of the different modeling of the train dynamics in case of varying signaling aspect, GADis enables the trains to use the railway infrastructure capacity more generously, especially at short block sections.
194 Timetable Planning and Information Quality
3 Experimental results This section presents a common test case from a complex dispatching area in the Netherlands. For given traffic conditions, the two dispatching support tools are compared in terms of train dynamics and train rescheduling solutions. The use of railway capacity is also illustrated in order to enable an easy and fast detection of train conflicts and to get precise information about their resolution by the different rescheduling techniques. 3.1 Test case description The GADis and ROMA systems were tested on the Dutch dispatching area between Utrecht and Den Bosch. The network consists of a corridor around 50 km long with two main tracks, seven passenger stations, a dedicated stop for freight trains and several merging and crossing points along the network. Figure 5 shows a scheme of the dispatching area, where the station of Utrecht is just out of the left border, the Geldermalsen station is roughly in the middle of the area and the Den Bosch station is at the right end. A layout, at a similar scale, will also be adopted for the blocking time plots presented in this section.
Figure 5: Dispatching area between Utrecht (left side) and Den Bosch (right side). The computational experiments were made on the basis of a cyclic timetable for year 2007, that is characterized by heterogeneous traffic (intercity trains and local train services) and includes freight trains directed to Germany. In peak hours, 26 trains are scheduled in Geldermalsen and up to 40 trains in Den Bosch. The timetable includes recovery times and buffer times between the train routes. Recovery times can be utilized to recover from delays by running at maximum speed and shorten the scheduled train stops to a minimum dwell time. Buffer times prevent or reduce the delay propagation to other trains. 3.2 Comparison of train dynamics Since the two dispatching support tools compute the train dynamics with a different degree of approximation and use different signaling and train protection systems, we first compare the simulated schedules obtained in absence of delays. Figure 6 shows the blocking time plots by the two tools for the scheduled train sequence in the timetable. For both tools, the (total) travel time of all trains within the studied area is around 33000 seconds. In the unperturbed situation, ROMA has found no output delay. On the other hand, GADis reports headway conflicts. In the
Rescheduling
195
latter case, dispatching trains according to the timetable results in 68 seconds of total output delay. These are due to the shorter block signal spacing assumed and the automated booking of some train routes induced by LZB system.
Figure 6: Timetable solution computed by the two dispatching support tools (upper graph: GADis, lower graph: ROMA). We now consider a timetable perturbation generated by postponing the entrance of two trains in the network. For the given delay scenario, we compute a feasible schedule by each dispatching support tool by scheduling trains according to the sequence fixed in the timetable. In the blocking time plots of Figure 7, each of the two postponed trains, indicated as 2 and 4, has got an input delay of 600 seconds and causes a domino effect of delay propagation in the network. In fact, two trains, called 1 and 3, are more affected by trains 2 and 4. For those four trains, the scheduled train sequence is 2-4-3-1. If the train sequence is fixed as in the timetable, in the ROMA solution the total travel time is 35810 seconds, the number of disturbed trains is 11 and the total output delay is around 3000 seconds. GADis presents a different situation with 36030 seconds of total travel time, 9 disturbed trains and around 3700 seconds of total
196 Timetable Planning and Information Quality
Figure 7: Timetable sequence (no reordering of trains) for the given delay scenario (upper graph: GADis, lower graph: ROMA).
output delay. The larger number of delays is again explained by the different signaling and train protection systems and computation of train dynamics, resulting in an unequal use of railway infrastructure capacity. 3.3 Comparison of train rescheduling solutions The delay scenario introduced in the previous subsection has been used as an input to find an optimized solution by both dispatching support tools. A comparison between the rescheduling solutions is proposed in this subsection. Figure 8 shows the rescheduling solution found by each dispatching support tool using its corresponding optimization algorithms and refers to the four most delayed trains. Specifically, GADis proposes the train sequence 3-2-4-1 and a total travel time of 34070 seconds, while ROMA suggests 3-1-2-4 and a total travel time of 34370 seconds. In terms of total output delays, GADis generates 1250 seconds and ROMA only 1010 seconds. From the obtained values, it is interesting to compare the travel time against the output delays. Since ROMA is able to use the recovery times more effectively, its rescheduling solution exhibits less output delays but
Rescheduling
197
Figure 8: Solution of the rescheduling algorithms for the proposed delay scenario (upper graph: GADis, lower graph: ROMA).
larger travel times than GADis. In general, both tools improved significantly the solution obtained in the previous subsection. The GADis solution contains the following differences compared to the train orders fixed in the timetable. Trains 2 and 4 are now scheduled after train 3 and before train 1, even if the latter train has to stop repeatedly due to headway conflicts to preceding trains. This effect is more evident in Den Bosch (right side of Figure 8, upper graph) that is a rather complicated and densely occupied area. ROMA also changes the train sequence compared to the timetable. The blocking time graphs of trains 2 and 4 are shifted after those of trains 3 and 1 so that the delay propagation is minimized. In fact, the total output delay is even less than the sum of the input delays of trains 2 and 4. The existing network capacity reserve is thus exploited by ROMA such that the overall traffic flow remains stable.
198 Timetable Planning and Information Quality
4 Conclusions Two existing dispatching support tools have been tested on a real-world case study from the Dutch railway network. The dispatching solutions obtained by the two tools and their rescheduling algorithms have been compared in terms of detailed blocking time plots, output delays and travel time spent. The solutions present a different computation of train dynamics even for unperturbed traffic conditions because of different modeling of the signaling and train protection systems. A more balanced comparison of the performance of the two dispatching support tools can be achieved if the tools adopt the signaling and train protection systems with short headways between trains, especially in the neighborhood of stations. Despite the above limitations, demanding convertible infrastructure and digital timetable and rolling stock data should be enforced since this would provide a common setup for the evaluation of advanced rescheduling algorithms. To this end, international standard platforms, such as RailML, should be used to stimulate transferability of scheduling and dispatching support tools between different railway networks and countries.
Acknowledgements This work has been partially funded by the Dutch government, program TRANSUMO “Reliability of transport chains”, the Dutch foundation “Next Generation Infrastructures”, and the Italian Ministry of Research, Grant number RBIP06BZW8, project FIRB “Advanced tracking system in intermodal freight transportation”.
References [1] D’Ariano, A., Improving Real-Time Train Dispatching: Models, Algorithms and Applications. TRAIL Thesis Series T2008/6, The Netherlands, 2008. [2] Wegele, S., Slov´ak, R. & Schnieder, E., Real-time decision support for optimal dispatching of train operation. In: CD-ROM Proceedings of the 2nd International Seminar on Railway Operations Modelling and Analysis, Hannover, Germany, 2007. [3] D’Ariano, A., Pacciarelli, D. & Pranzo, M., A branch and bound algorithm for scheduling trains on a railway network, European Journal of Operational Research, 183(2), pp. 643-657, 2007. [4] Hansen, I.A. & Pachl, J., Railway timetable and traffic: Analysis, Modelling and Simulation, Eurail Press, Germany, 2008. [5] D’Ariano, A., Pranzo, M. & Hansen, I.A., Conflict resolution and train speed co-ordination for solving real-time timetable perturbations, IEEE Transactions on Intelligent Transportation Systems, 8(2), pp. 208-222, 2007. [6] Wegele, S., Slov´ak, R. & E. Schnieder, E., Automatic dispatching of train operations using a hybrid optimisation method. In: CD-ROM Proceedings of the 8th World Congress on Railway Research, Seoul, Korea, 2008.
Rescheduling
199
A novel train rescheduling algorithm for correcting disrupted train operations in a dense urban environment K. Kumazawa, K. Hara & T. Koseki Department of Electrical Engineering, Graduate School of Engineering, The University of Tokyo, Japan
Abstract Train rescheduling during disrupted service is a substantially significant task for urban railway operators. This task typically depends on the experiences and personal decisions of the professional operators. The operators use neither systematic methodologies for modifying train schedules nor quantitative criteria for measuring the quality of the rescheduled plans. Thus, operators have requested assistance in the form of a computer-aided train-rescheduling program. The authors have created a computer-aided train rescheduling system that seeks to minimize passenger inconvenience. The rescheduling algorithm calculates a value for the amount of inconvenience experienced by the passenger. In addition to a conventional passenger flow analysis, the authors’ algorithm considers passenger overflow, which is defined as waiting time experienced by a passenger while queuing on a platform. The proposed rescheduling method also introduces the idea that the time required to create, broadcast, and implement a new plan of train operation is itself a delay which must be accounted for in order to render a realistic passenger flow analysis during disordered operation. The causality of train system events after the initial event that caused the disruption of service is discussed for a realistic analysis of passenger flow. Keywords: train rescheduling, assistance system, evaluation.
1
Introduction
The rescheduling of train operations is often needed when a train operation is disordered by various malfunctions or accidents. The main tasks are presently
200 Timetable Planning and Information Quality undertaken by train dispatchers using their experience and intuition. It is very difficult, since there are many factors to be considered such as the location of trains and rolling stock, tracks and train layout, the location of drivers, passengers’ demands, and so on. Corresponding to a high-speed and high-density train operation, dispatchers have requested an assistance system in order to reschedule train operation plans quickly and precisely. The authors proposed a method to rate train operation plans quantitatively from the passengers’ point of view. Based on this, the authors formulate an assistance system that chooses an appropriate method to modify a train schedule (Nagasaki et al. [1]). In this paper, the authors propose a causality-based passenger flow estimation algorithm that reflects the altered behaviours of passengers during disrupted train operation. The passenger flow estimation algorithm calculates a value for the amount of inconvenience experienced by the passenger. In addition to a conventional passenger flow analysis, the authors’ algorithm considers passenger overflow, which is defined as the waiting time experienced by a passenger while queuing on a platform. Rescheduling train operation plans were assumed to be instantaneously made in a conventional model at the accident time. In fact, it takes time to make rescheduling train operation plans. In this paper, the authors propose a new passenger flow estimation method to obtain a realistic evaluation contents. This method also considers the time required to generate train rescheduling plans.
2
Composition of train rescheduling system
This computer-aided train rescheduling system makes a rescheduling plan based on the information of delay and various restrictions. The system consists of two main parts, one is creating a train plan and the other is evaluating the plan. In the part of creating a train plan, change of train diagram and determination of train arrival and departure are executed. In evaluating the plan, estimation of passengers’ behaviour and calculation of evaluation indices are carried out. The train rescheduling plan is made by repeating process of adoption judgment of a new modification based on the evaluation indices. And the train rescheduling plan is presented to the train dispatchers. Figure 1 shows a composition of the computer-aided train rescheduling system.
3 Creation of train operation plan Creating train operation plan in the system consists of application part of train rescheduling methods and decision part of arrival or departure time by simulating train operation. 3.1 Constrains for train operation There are various constrains for train operation. In the train operation simulation, it is necessary to decide arrival or departure times that fulfil all severe conditions.
Rescheduling
201
Information about delay
Train rescheduling methods are applied
Creating a train plan
Simulation of train operation Arrival and departure time
Simulation of passenger flow
Evaluating the plan
Number of passenger Passenger’ s loss calculation
No
Figure 1:
Accept?
Yes
Proposing to dispatcher
A composition of the computer-aided train rescheduling system.
The authors use graph structure to represent train operation. Nodes express departure and arrival of trains at each station. Links represent running and stopping of train, and constraints as follows. 3.1.1 Regular arrival or departure time The arrival or departure time of each train in each station is provided beforehand. This schedule is a regular schedule. A train must not run earlier than a regular schedule. 3.1.2 Regular running time To run between stations, a train requires longer time than regularly defined by the type of rolling stock, number of cars, stop or pass of stations, and so on. 3.1.3 Regular stopping time A train stops at the station longer than the defined time. If the train does not stop at the station, the weight of the link equals to 0. 3.1.4 Conflicting routes at a station A certain interval is required between trains whose routes conflict at a station or a yard. The weight of the link is time interval between departures and arrivals. 3.1.5 Blockages between stations Trains more than defined number cannot run at the same time between stations. 3.2 Simulation of train operation By finding the longest path to each node from the node expressing time origin, it is possible to obtain departure or arrival time of each train at each station as the length of the path. Also critical constraints in operating trains expressed by links framing the longest paths can be consequently obtained.
202 Timetable Planning and Information Quality Local St.A Dep
Express
Order of trains
Local Blockage
St.B Arr
Confliction of routes
St.B Dep
Regular running time Regular stopping time
St.C Arr St.C Dep St.D Arr St.D Dep St.E Arr Figure 2:
An example of a graph representing train operation.
The authors use PERT (Program Evaluation and Review Technique) for the longest path search (Abe and Araya [2]). It is necessary to change the information on nodes or links appropriately to express the application of train rescheduling techniques. Figure 2 shows an example of a graph representing train operation.
4
Evaluation of train operation plan
The total time of all trains’ delay has been used for the evaluation of the train rescheduling plan in practical use. Because the delay is vanished when all delayed trains are suspension of service, it is evaluated as a good train rescheduling plan in this criterion. However, the passenger overflow on the platform actually, it is clear that this rescheduling plan is not good. In order to avoid such stupid results, the authors has proposed a method to rate train operation plans quantitatively from passengers’ point of view. This section describes how to estimate passenger flow and evaluation indices. 4.1 Simulation of passenger flow The authors use graph and the shortest path search to decide lines and trains each passenger selects based on the models of passengers’ behaviour. A node of a graph for calculating passenger flow expresses departure or arrival of a train at a station. A link describes potential passenger flow between departure and arrival. Figure 3 shows an example of a graph representing passenger flow. 4.2 Graph for evaluating train operation plan from the passenger’s point of view The authors defined a criterion for passengers’ loss considering the following three evaluation indices, travelling time, burden of transfer, and congestion. These indices are calculated by using the result of simulation of passenger flow.
Rescheduling
Local
Express
Local
St.A Dep
Boarding
St.B Arr
Stop
St.B Dep St.C Arr St.C Dep
203
Transfer
St.D Arr St.D Dep St.E Arr Figure 3:
An example of a graph representing passenger flow.
4.2.1 Travelling time The most significant factor for passengers to evaluate train operation is amount of time required from the starting station to the destination. Travelling time is defined as follows. N
L1 = ∑ t i
(1)
i =1
where N is the number of passenger, ti is passenger i’s travelling time. 4.2.2 Transfers Transfer not only takes time but also imposes burden such as going upstairs. These burdens are calculated as passengers’ loss in addition to the real time for transfer. N
Mi
L2 = ∑∑ rij
(2)
i =1 j =1
where Mi is the number of transfers passenger i needs, rij is time equivalent to the burden of passenger i’s j-th transfer. 4.2.3 Congestion Congestion of trains is also evaluated as loss because passengers in a congested train feel discomfort. Congestion loss is defined as follows.
q L3 = ∑∑ f c ks q ks t ks k =1 s =1 c ks n −1 S k
(3)
where n is the number of stations, Sk is the number of trains which arrive at station k. qks, tks, and cks are the number of passenger in the train, the time required, and the capacity of the train between k-th and k+1-th stations respectively. fc is a nonlinear function to convert passengers’ discomfort in the congested train into equivalent time, as shown in Figure 4 (Mitani et al. [3]).
Congestion cost per minute
204 Timetable Planning and Information Quality 0.6 0.5 0.4 0.3 0.2 0.1 0 0
50
100
150
200
250
Congestion rate [%]
Figure 4:
Relationship between congestion rate and congestion cost per minute.
The evaluation criterion of a train operation is the sum of above-mentioned three types of loss.
L = L1 + L2 + L3 5
(4)
Passenger overflow caused by congestion
In the preceding study (Hara et al. [4]), passenger over flow by congestion was not considered. Therefore passengers could get on more than capacity of the train. This caused violence of causality. The passengers’ behaviour was not correctly estimated and evaluation criteria could not be accurately calculated. In this section, the authors model the process of passenger over flow by congestion. 5.1 Model of passenger overflow
Passenger overflow happens when there are more people on a platform waiting for a train than the rest capacity of next arriving train. For simplicity, the authors assume that all of the passengers on the platform are waiting in one line. This simplification is important for calculating the point in time ta when the number of waiting passengers exceeds the rest capacity of a next train. The point in time tb when overflow occurs is determined by summation of the number of passengers arriving at a station after the preceding train has left the station. The number of passengers getting off and changing trains is added to this number of waiting passenger. The ratio of passengers able to successfully get on next train versus total passengers arriving at stations is assumed to be constant for each Origin-Destination pair. Passengers arriving at the station after the threshold for overflow point has been reach cannot get on the train they initially planed to board. These passengers must change their travel plans after the next train leaves the station. Figure 5 shows an example of a model of passenger overflow.
Number of passenger
Rescheduling
205
Passenger overflow Waiting for Express 2 Transfer passenger from Local 1 Waiting for Express 2
tb
Express 1
Local 1 Figure 5:
ta
time Express 2
Model of passenger overflow.
5.2 Effect of passenger overflow caused by congestion
The authors have applied the proposed method to the diagram shown in Figure 6 in order to verify the effect. The capacity of each train is 800 people. Before the application of proposed method, there is the point where the number of the passengers exceeds the capacity of the train. This is not realistic. Applying the model of Figure 5, 70 passengers cannot take the train. These passengers take the next train. Figure 6 (b) is an application result of proposed method. Figure 7 shows passengers’ loss. Passenger overflow ultimately results in the numerical increase of passenger penalty function, as well increasing the individual passenger waiting time and inconvenience. This depends on the following reason, which passengers arriving at the station after the threshold for overflow has been reach cannot get on the train they initially planed to board. In detail, these passengers must adjust their travel plans after the next train leaves the station. So it takes more time to head for their destination. However, resolving some passenger overflow reduces the total passengers’ loss. The congestion penalty in heavily loaded trains decreases drastically.
6
Modelling of time necessary for planning and plan execution
The authors proposed a method to rate train operation plans quantitatively from the passengers’ point of view. Based on it, the authors formulated an assistance system that chooses an appropriate method to modify a train schedule. However, rescheduling train operation plans were assumed to be instantaneously made in a conventional model at accident time (Hara et al. [4]). In fact, it takes considerable time to make rescheduling train operation plans. In this section, the authors propose a new passenger flow estimation method to obtain a realistic evaluation index. This method considers also the time required to generate train rescheduling plans.
206 Timetable Planning and Information Quality
60 10
(a) Passenger overflow
Figure 6:
(b) Apply this method
The proposed method applied to a diagram.
1.25E+07 1.20E+07 1.15E+07 1.10E+07 1.05E+07 1.00E+07 Regular schedule
Not considered passenger overflow Travelling time
Figure 7:
Congestion
Proposed method
Transfers
Comparison of passengers’ loss.
6.1 Modelling of time for planning and plan execution
One needs a certain amount of time for planning and executing a new train schedule; it is impossible to realize a final rescheduling plan immediately after an operation disturbance. In order to take this planning time into consideration, the rescheduling algorithm is duelled into two instances beginning at two different points in time: the time when train service is initially disrupted and the
Rescheduling
207
time when the final rescheduling plan is started. A temporary train operation is inserted between the two times. This modification allows investigation of the effects of the time required for preparing the rescheduled plans. Figure 8 shows an example of a model of this method. Start of reschedule plan
St.A St.B St.C St.D St.E St.F
Regular schedule
Figure 8:
Operation Train suspension rescheduling plan
An example of a model of this method.
Operation suspension
Figure 9:
The proposed method applied to the diagram.
6.2 Effect of special consideration given to the necessary for planning and its execution
The authors have applied the proposed method to the diagram shown in Figure 9 in order to verify the effect. Operation suspension is done in a frame black in Figure 9. The time required to generate a train rescheduling plan can be expressible while operation suspension is done. By operation suspension being done, it turns out that passenger’s loss increases. This depends on passenger’s
208 Timetable Planning and Information Quality travelling time increasing. So this modification allows for the investigation of the effects of the time required for preparing the rescheduled plans.
7
Conclusion
Under a condition of rescheduling train operation plans were assumed to be instantaneously made in a conventional model at accident time (Hara et al. [4]), passenger overflow ultimately results in the numerical increase of passenger penalty function, as well increasing the individual passenger waiting time and inconvenience. However, in conjunction with the rest of the rescheduling system, allowing some passenger overflow reduces the total passenger penalty, including the congestion penalty, by decreasing congestion in heavily loaded trains. In order to take this planning time into consideration, the rescheduling algorithm is duelled into two instances beginning at two different points in time. The two times are the time when train service is initially disrupted and the time when the final rescheduling plan is started. In this algorithm, it is not considered passenger overflow. The authors assert that their modification results in a more realistic evaluation of the passenger flow. However, it turns out that passengers’ loss increases by passengers’ travelling time increasing. So it is necessary to improve the temporary train.
References [1] Nagasaki, Y., Eguchi, M. & Koseki, T., Automatic Generation and Evaluation of Urban Railway Rescheduling Plan. Proc. of Int. Symp. on Speed-up and Service Technology for Railway and Maglev Systems STECH ’03, Japan, 2003. [2] Abe, K. & Araya, S., Train Traffic Simulation using the Longest Path Method. Information Processing Society Journal, 1987 (in Japanese). [3] Mitani, K., Ieda, H. & Hatanaka, H., Evaluating Method of Congestion Cost by the Model of Passenger’s Boarding Behavior. Infrastructure Planning Review (in Japanese), no. 5, pp. 139–146, 1987. [4] Hara, K., Kumazawa, K. & Koseki, T., Causality-based Passenger Flow Estimation in Irregular Train Operation for a Computer-aided Train Rescheduling System. Scheduling Symposium, pp.185–190, 2007 (in Japanese).
Timetable Planning and Information Quality
209
Author Index Abril M. ..................................... 49 Albrecht C.................................. 11 Albrecht T. ............................... 147 Armstrong J. ............................ 137
Longo G. .................................. 125 Lova A. ...................................... 49
Barber F. .................................... 49 Bouch C. .................................. 137 Buchmueller S. ........................ 105
Nash A. ................................ 3, 105 Nielsen O. A. ............................. 85
Medeossi G. ............................. 125
Oguma K. .................................. 25 Corman F. ................................ 189 Preston J................................... 137 D’Ariano A. ..................... 147, 189 de Fabris S. .............................. 125 Demitz J. .................................... 11
Radtke A. ................................... 59 Ricci S. .................................... 179 Rodriguez J. ............................. 169
Fujimori A. .............................. 157 Gille A. ...................................... 73 Goodman C. J. ......................... 137 Goverde R. M. P. ....................... 95 Hansen I. A. ......................... 35, 95 Hara K...................................... 199 Hirai C. .................................... 157 Hübschen C................................ 11 Huerlimann D. ............................. 3
Salido M. A. .............................. 49 Schuette J. .................................... 3 Siefer Th. ................................... 73 Sone S. ..................................... 137 Takagi R. ................................. 137 Takano T. ................................... 25 Tashiro Y. ................................ 157 Tieri A. .................................... 179 Tomii N. .................................. 157 Tormos P. .................................. 49
Ingolotti L. ................................. 49 Uemura T. .................................. 25 Katsuta K. .................................. 25 Klemenz M. ......................... 59, 73 Kondou S. ................................ 157 Koseki T. ................................. 199 Krauss V. P. ................................. 3 Kumazawa K. .......................... 199
Watanabe D. .............................. 25 Wegele S. ................................. 189 Weidmann U. ........................... 105 Weston P. F. ............................ 137 Yuan J. ....................................... 95
Landex A. .................................. 85 Lindfeldt O. ............................. 115
This page intentionally left blank
...for scientists by scientists
Power Supply, Energy Urban Transport and the Environment Management and Catenary Problems in the 21st Century Urban Transport XV
Edited by: C.A. BREBBIA, Wessex Institute of Technology, UK The continuing requirement for better urban transport systems in general and the need for a healthier environment has led to an increased level of research around the world. This is reflected in the proceedings of this well-established meeting which demonstrates the steady growth and research into urban transport systems. The variety of topics covered by the conference are of primary importance for analysing the complex interaction of the urban transport environment and for establishing action strategies for transport and traffic problems. The fifteenth conference topics are: Urban Transport, Planning and Management; Transportation Demand Analysis; Intelligent Transport Systems; Land Use and Transport Integration; Air and Noise Pollution; Environmental and Ecological Aspects; Traffic Integration and Control; Transport Modelling and Simulation; Safety and Security; PublicTransport Systems. WIT Transactions on The Built Environment, Vol 107 ISBN: 978-1-84564-190-0 eISBN: 978-1-84564-367-6 Published 2009 672pp £255.00/US$510.00/€357.00
All prices correct at time of going to press but subject to change. WIT Press books are available through your bookseller or direct from the publisher.
Edited by: E. PILO, Pontifical Comillas University of Madrid, Spain In latter years, energy efficiency has become a crucial concern for every transportation mode, but it is in electrified railways where energy savings have shown a bigger potential due to (i) regenerative braking, that allows converting kinetic energy into electric power, and (ii) vehicle interconnection, that allows other trains to use regenerated power. Power supply and energy management will continue to develop in the future. This book gathers under a single cover several papers published in the Computer on Railways series (IX, X and XI) and focuses on power supply and energy management. Some of the discussed themes are: modelling, simulation and optimisation of AC and DC infrastructure, analysis of rolling stock consumption, and innovative approaches in power supply operation. This book will be invaluable to management consultants, engineers, planners, designers, manufacturers, operators and IT specialists who need to keep abreast of the latest developments in the field. ISBN: 978-1-84564-498-7 eISBN: 978-1-84564-499-4 April 2010 apx 208pp apx £85.00/US$170.00/€114.00
WITPress Ashurst Lodge, Ashurst, Southampton, SO40 7AA, UK. Tel: 44 (0) 238 029 3223 Fax: 44 (0) 238 029 2853 E-Mail:
[email protected] ...for scientists by scientists
Fundamentals of Road Design M.K. JHA, Morgan State University, USA and W. KUHN, University of Leipzig, Germany Currently there is no single textbook that addresses the fundamental geometric concepts of urban and rural road design. The traffic behavior has significantly changed over the last two decades and warrants newer methods for road design. Unlike the advances made in building, ship, and aircraft design, road design is still carried out in a traditional way which is more than fifty years old. Starting from the traditional design process this book introduces a 3-dimensional geometric design process of urban and rural road design. It will prove to be a valuable textbook for undergraduate and graduate university students as well as road planning and design practitioners. Interested readers may find this book a valuable resource in conjunction with the authors’ recently published book entitled “Intelligent Road Design”, which is written at an advanced level and addresses intelligent algorithmic applications in road alignment optimization. Series: Advances in Transport, Vol 20 ISBN: 978-1-84564-097-2 Forthcoming apx 350pp apx £120.00/US$240.00/€180.00
Find us at http://www.witpress.com Save 10% when you order from our encrypted ordering service on the web using your credit card.
Hybrid Vehicle Propulsion C.M. JEFFERSON, University of the West of England, UK and R.H. BARNARD, University of Hertfordshire, UK In this book, the authors review recent progress in the development of a range of hybrid vehicles and describe the results of field trials and operational experience. Numerous tables, graphs and photographs are included together with clear references. The volume will be of great interest to engineering and technical staff working in the road and rail vehicle industries, and final year undergraduates and postgraduates studying mechanical and automotive engineering. Series: Advances in Transport, Vol 10 ISBN: 1-85312-887-2 2002 176pp £69.00/US$107.00/€103.50
All prices correct at time of going to press but subject to change. WIT Press books are available through your bookseller or direct from the publisher.
WIT eLibrary Home of the Transactions of the Wessex Institute, the WIT electronic-library provides the international scientific community with immediate and permanent access to individual papers presented at WIT conferences. Visitors to the WIT eLibrary can freely browse and search abstracts of all papers in the collection before progressing to download their full text. Visit the WIT eLibrary at http://library.witpress.com
...for scientists by scientists
Advances in City Transport Case Studies Edited by: S. BASBAS, Aristotle University of Thessaloniki, Greece Highlighting the highly topical subject of transport and the environment and the closely related field of town planning, this book contains chapters concerning developments in the transportation systems of various cities all over the world. These include Singapore, São Paulo, Santiago, Bilbao, Eindhoven, Adelaide, Bangalore and Thessaloniki. The studies featured will be of interest to postgraduate researchers in transport and the environment, engineers and planners working within transport and environment ministries and local authorities, and consultants. Series: Advances in Transport, Vol 17 ISBN: 1-85312-799-X 2006 208pp £66.00/US$120.00/€99.00
How to Make Two-Lane Rural Roads Safer
scientific framework for the application of quantitative safety evaluation processes on two-lane rural roads. The methodology described will support the achievement of quantified measures of 1) design consistency, 2) operating speed consistency, and 3) driving dynamic consistency. All three criteria are evaluated in three ranges described as “good”, “fair” and “poor”. It has been proved that the results of these criteria coincide with the actual accident situation prevailing on twolane rural roads. By using the “good” ranges sound alignments in plan and profile, which match the expected driving behaviour of motorists, can be achieved. The safety criteria are then combined into an overall safety module for a simplified general overview of the safety evaluation process. The authors also encourage the coordination of safety concerns with important economic, environmental and aesthetic considerations. This book will be an invaluable aid to educators, students, consultants, highway engineers and administrators, as well as scientists in the fields of highway design and traffic safety engineering. ISBN: 1-84564-156-6 2006 144pp £48.00/US$85.00/€72.00
Scientific Background and Guide for Practical Application R. LAMM, A. BECK and T. RUSCHER, University of Karlsruhe, Germany, T. MAILAENDER, Mailaender Ingenieur Consult GmbH, Germany and S. CAFISO and G. LA CAVA, University of Catania, Italy In most countries two-lane rural roads make up about 90 percent of rural networks and account for about 60 percent or more of highway fatalities worldwide – 500,000 people per year. Based on new research and the demands of many design professionals this book provides an understandable
Find us at http://www.witpress.com Save 10% when you order from our encrypted ordering service on the web using your credit card.
...for scientists by scientists
Innovations in Freight Transport Editors: E. TANIGUCHI, Kyoto University, Japan and R.G. THOMPSON, University of Melbourne, Australia Highlighting new ideas and best practice, this book examines innovations in modern freight transport systems. Partial Contents: Intelligent Transport Systems; Vehicle Routing and Scheduling; Logistics Terminals; Intermodal Freight Transport; Underground Freight Transport Systems; E-Commerce and the Consequences for Freight Transport; Future Perspectives. Series: Advances in Transport, Vol 11 ISBN: 1-85312-894-5 2002 216pp £76.00/US$118.00/€114.00
Computers in Railways XII Computer System Design and Operation in the Railway and Other Transit Systems
signal and control engineers), designers of advanced train control systems and computer specialists. The COMPRAIL series has become the world forum for all major advances in this important field, and this latest conference volume highlights themes of great current interest. These are: Planning; Safety and Security; Advanced Train Control; Drivers Operations; Communications; Energy Supply and Management; Operations Quality; Timetable Planning; Level Crossing and Obstacle Detection; Computer Techniques; Dynamics and Wheel/Rail Interface; Maintenance; Rolling Stocks; Training Tools and Technology; Condition Monitoring; Asset Management; Maglev and High Speed Railway; Passenger Information Systems; Train Regulations; Metro and Other Transit Systems; Advanced Train Control. WIT Transactions on The Built Environment, Vol 114 ISBN: 978-1-84564-468-0 eISBN: 978-1-84564-469-7 Forthcoming /apx1000pp /apx£380.00/ US$760.00/€532.00
Edited by: B. NING, Beijing Jiaotong University, China and C.A. BREBBIA, Wessex, Institute of Technology, UK This volume features the proceedings of the Twelfth International Conference on Computer System Design and Operation in the Railway and other Transit Systems. This book updates the use of computer-based techniques, promoting their general awareness throughout the business management, design, manufacture and operation of railways and other advanced passenger, freight and transit systems. It will be of interest to railway managers, consultants, railway engineers (including
We are now able to supply you with details of new WIT Press titles via E-Mail. To subscribe to this free service, or for information on any of our titles, please contact the Marketing Department, WIT Press, Ashurst Lodge, Ashurst, Southampton, SO40 7AA, UK Tel: +44 (0) 238 029 3223 Fax: +44 (0) 238 029 2853 E-mail:
[email protected] 
