1845645006timetable Planning

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
WIT Press publishes leading books in Science and Technology.
Visit our website for the current list of titles.
www.witpress.com
WITPRESS
Timetable Planning
and Information Quality
This page intentionally left blank
Timetable Planning
and I nf or mat i on Qual i t y
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: witpress@witpress.com
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: infousa@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.
Editor: Ingo A. Hansen
Contents

Par t 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. Hbschen & 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

Par t B. Oper ations 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

Par t 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. DAriano....................................................... 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
Pr eface

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 Rhine-
Westphalia/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 sub-
process 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. DAriano & 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.
Part A
Timetabling
RailML a standard data interface for
railroad applications
A. Nash
1
, D. Huerlimann
1
, J. Schuette
2
& V. P. Krauss
2

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 applications 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.
Timetabling 3
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
datas 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
4 Timetable Planning and Information Quality
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 Technologys 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 partnerships 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.
Timetabling 5
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.


Figure 2: Examples of RailML data transfer.
4 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 documents root element is called <railml>. 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 </railml>. 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 <timetableentries>.
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).

Timetabling 7
<?xml version="1.0" encoding="UTF-8"?>

<railml xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-
instance" xsi:noNamespaceSchemaLocation="timetable.xsd">
<timetable version="0.95" scheduleformat="hh:mm:ss"
periodformat="s">
<train trainID="RX 100.2" type="planned"
source="opentrack">
<timetableentries>
<entry posID="ZU" departure="06:08:00" type="begin">
</entry>
<entry posID="ZWI" departure="06:10:30" type="pass">
</entry>
<entry posID="ZOER" arrival="06:16:00"
departure="06:17:00" minStopTime="9" type="stop">
</entry>
<entry posID="WS" departure="06:21:00" type="pass">
</entry>
<entry posID="DUE" departure="06:23:00" type="pass">
</entry>
<entry posID="SCW" departure="06:27:00" type="pass">
</entry>
<entry posID="NAE" departure="06:29:00" type="pass">
</entry>
<entry posID="UST" arrival="06:34:30" type="stop">
</entry>
</timetableentries>
</train>
</timetable>
</railml>
Figure 3: Example RailML document.

As Figure 3 illustrates, the RailML language is very similar to other XML-
based 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
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: RailML-logo.
6 Conclusions benefits for simulation and timetabling
The RailML projects 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] For more information on these programmes please see: www.opentrack.ch
www.irfp.de/fbs, www.viriato.ch, www.opentimetable.ch.
[2] All information about RailML can be found at www.railml.org.
[3] Fries, N., 2003, Modellierung und Abbildung einer Eisenbahn-
Infrastruktur auf ein Schema der XML-basierten Schnittstelle RailML
(Diplomarbeit, TU Dresden, Professur fr Verkehrssicherungstechnik,
Dresden).
[4] Hengartner, M., 2003, Grafikeditor fr RailML-basierte Infrastrukturdaten
(Diplomarbeit, ETH Zrich, Institut fr Verkehrsplanung und
Transportsysteme, Zrich).
[5] Hrlimann, D., 2002, Objektorientierte Modellierung von
Infrastrukturelementen und Betriebsvorgngen im Eisenbahnwesen, 2002,
Institut fr Verkehrsplanung und Transportsysteme, ETH Zrich,
Schriftenreihe des IVT, Nr. 125.
Timetabling 9
[6] 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.
3341.
[7] Hoffmann, R., Krauss, V.P., 2001, RailML als Datenaustauschformat fr
Eisenbahnsoftware (Projektbeschreibungen und -berichte sowie Konzepte,
Fraunhofer Gesellschaft e.V., Institut fr Verkehrs- und Infrastruktur-
systeme, Dresden).

Timetable stability - using simulation to ensure
quality in a regular interval timetable
J. Demitz
1
, C. Hbschen
2
& C. Albrecht
3

1
Rail Management Consultants Ltd., Germany
2
DB Regionalbahn Westfalen GmbH, Germany
3
Regionalleitung NRW Ressort Produktion, Germany
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-Westphalias 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
Timetabling 11
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
of North Rhine-Westphalia, Germany, was commissioned by Germanys 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 investigations 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.
Timetabling 13
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
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 delay-
burdened 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
Timetabling 15
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 Germanys 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

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.
Timetabling 17
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
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 Mnster. 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.
Timetabling 19
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.
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 on-
time 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

Timetabling 21
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.
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
trains 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.
Timetabling 23
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] http://www.rmcon.de.
[2] http://www.ive.uni-hannover.de.
[3] 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.
[4] Dispo: Optimised Vehicle Allocation http://www.ive.uni-hannover.de/
software/dispo/index_en.shtml.
[5] 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.
[6] Schumacher, Andreas, Monecke, Lars, Freiberger, Kai-Uwe; Modelling
constrains in automatic vehicle rostering - demands and possibilities
Proceeding of Comprail 2004.
[7] Hauptmann, Dirk: Automatic and non-discriminatory train path
allocation in railway networks of arbitrary size, Dissertation No.54,
02.02.2000.
[8] 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.
Crystal diagram: a technique for making
high-density diagrams
K. Katsuta
1
, T. Takano
1
, K. Oguma
1
, D. Watanabe
1
& T. Uemura
2

1
Hitachi Ltd, Hitachi Research Laboratory, Japan
2
Hitachi Ltd, Power & Industrial Systems Mito Transportation Systems
Product Div., Japan
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
Timetabling 25
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 high-
density 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.

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
Station-A
Station-B
Station-C
Pattern
Time
Periodic time
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.

Figure 2: Change in train interval.

3 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.
Time
Distance
Station
Train interval
Running curves

Timetabling 27
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.

Figure 3: The periodic time of schedule-A.

Figure 4: The periodic time of schedule-B.
Time
Distance
(1) Train-a arrives.
(2) Train-b departs.
Train-a Train-b
(3) Train-a departs.
(4) Train-b arrives.
Time
Distance
(1) Train-a arrives.
(2) Train-a departs.
(3) Train-b arrives.
(4) Train-b departs.
Train-a Train-b
Track layout Periodic time
Periodic time
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.

Figure 5: 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.
Track layout
Distance
Time
Track layout
Distance
Time
Running curve Minimum interval time
Timetabling 29
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.
The minimum interval time between all trains calculated above.
Schedule data which are stored data of schedules such as Schedule-
A 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.

Figure 6: 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.
Time
Periodic time
Minimum interval time
Track layout
Distance
(1) (2)
(3) (4)
(1) (3) (4) (1) (2)
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.

Figure 7: 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.
Periodic time = 230s
Distance
Track layout
(1) (2) (3) (4) (3)(5) (1)(4)
(6)(2)
(5) (6)
600m
300m
Time
Timetabling 31

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, <1>, <2> and <3> are
influenced by stopped time. On the other hand, <4> is not influenced by
it.
We can see that shortening stopped time at <4> is ineffective for raising
the train density more than it already is.
For the average interval time between trains, <3> is as large as <2>,
though <3> has more tracks than <2>.
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.

Figure 9: The average interval time of each station.

Table 1: The relation between the required time and the number of
instructions.
Instructions Permutation(*1) Required time
2-5 --- <<1s
6 1.2*10
2
(5!) 0.01s
7 7.2*10
2
(6!) 0.07s
8 5.0*10
3
(7!) 0.5s
9 4.0*10
4
(8!) 4s
10 3.6*10
5
(9!) 34s
11 3.6*10
6
(10!) 5m40s
12 4.0*10
7
(11!) 1h

CPU: 2.0GHz, Memory: 256MB.
(*1) Circular permutation by periodicity.
Depends on
stopped time
Depends on
switching time
Depends on
signal system
Depends on
track layout
144s
75s 77s
64s
<1> <2> <3> <4>
Timetabling 33
6 Future work
For the method to derive the crystal diagram, the required time increases
explosively as instructions to all trains in one period increase. The reason is that
we must calculate the periodic time of all permutations. We show the relations
between the required time and the number of instructions in table 1. In the future,
we must devise an algorithm by pruning, reducing in calculations, etc.
7 Conclusions
We have aimed at increasing train density, i.e., making a high-density diagram.
In this paper, we proposed the concept of a crystal diagram to refer to a pattern
and station diagram whose periodic time is shortest, on the assumption that
instructions to all trains in one period are fixed. We explained the method to
derive it. We derived the crystal diagrams for some model cases and obtained
effective results for operation planning, train dispatching and equipment design.
References
[1] T. Nagata, S. Murata, Y. Naka, O. Sakashita & N. Shimizu, A train
operating method with real time adaptability to performance variations of
rolling stock. Comprail 98 (Computer in Railways VI), pp. 793-804,
Lisbon 1998.
[2] H. Nakamura, Analysis of minimum train headway on a moving block
system by genetic algorithm. Comprail 98 (Computer in Railways VI), pp.
1013-1022, Lisbon 1998.
[3] G. Astengo, G. Cosulich & D. Marzullo, Introduction of a new high speed
line in a high density traffic area: a simulation exercise. Comprail 2000
(Computer in Railways VII), pp. 211-220, Bologna 2000.

State-of-the-art of railway operations research
I. A. Hansen
Abstract
The paper discusses the current state of research concerning the modelling of
stochastic train operations in order to optimise the use of capacity by means of
analytical methods and micro-simulation. Timetable quality is governed by
precise running and realistic recovery times, as well as optimal headway and
buffer times. Analytic (queueing) models and micro-simulation are used for
estimation of waiting times, while combinatorial models and stability analysis by
means of max-plus algebra technique are suitable for network timetable
optimisation. Operations quality can be modeled by the estimation of (admitted)
queue length and micro-simulation. A recently developed probabilistic model for
the estimation of delay propagation in stations and junctions based on the
stochastic variation of track occupancy times depending on conditional
probability distributions of hinder by headway constraints and route conflicts is
presented, while stochastic timetable optimisation may help to determine a more
efficient distribution of running time margins and to increase punctuality in large
networks.
Keywords: timetabling, waiting time, delays, rescheduling, level of service.
1 Introduction
So far, railway timetables are based on deterministic running, dwell and headway
times between stations. These times are mostly scaled in minutes and refer to a
virtual stopping point at the stations. Small variations of the service times are
compensated by standard running time and dwell time supplements, as well as
margins between the train paths. The amount of time supplements and margins
applied for scheduling, however, is mainly based on rules of thumb, sometimes
checked by simulation, and only seldom derived from statistical analysis of
real-world operations data.
Timetabling 35
Stochastic analytical approaches, like queueing models [15] assume the train
intervals and the service times to be independent random variables, which is
questionable in case of periodic timetables with high frequencies. The variation
of inter-arrival times and minimal headway times is modelled mostly on the
basis of assumed random distributions for inter-arrival and service times. The
estimated waiting time of a timetable is a function of the track occupancy and the
coefficients of variation of the scheduled headway and service times. Waiting
times generated by the stochastic variables of the timetable are clearly
distinguished from estimated knock-on delays during operations.
Optimisation models based on linear programming [6], in general, apply
deterministic variables for searching the optimal value of an objective function,
like minimisation of overall running times in large complex networks, at given
constraints e.g. minimal headway and transfer times between trains. The first
known stochastic optimisation approach for estimating the robustness of railway
timetables was recently presented by Vromans [7].
Micro-simulation models, like STRESI [8], RailSys [9], OpenTrack [10] or
ATTPS [11] are used to estimate the effect of exogenous random primary delays
on track occupation and consecutive delays of hindered trains. The induced
primary delays are drawn from assumed or empirical distributions for a given
timetable, track infrastructure and signal system. Kaminski [12] introduced a
heuristic limit for the buffer time distribution at bottlenecks in order to
compensate for 80% of the primary delays. Carey and Carville [13] presented a
heuristic approach for solving conflicts between train paths and routes and
simulation of random delays in order to test the reliability and robustness of
timetable options.
This paper will discuss the influence of basic stochastic variables for
timetable design and its impact on railway performance, as running and recover
time, minimal time headway and punctuality. A new approach for the estimation
of blocking times and buffer times at bottlenecks by means of blocking time
waves is presented. The paper concludes with the remaining issues for further
research and development.
2 Timetable quality
The evaluation of timetable quality must reflect the requirements of the different
stakeholders, as customers (passengers, shippers), infrastructure managers, train
operating companies and public authorities (government, passenger transport
executives). The timetable itself represents the transport supply, which should
comply best with the market demand. There exist numerous criteria to evaluate
the quality of railway services, which are more or less important for customers,
infrastructure provider, train operators and public authorities. The quality of
timetable design for a given traffic demand, rail infrastructure and train mix
depend mainly on:

Precise and realistic running times
Sufficient but not too large recovery times
Exact minimal headway times between different pairs of trains,
Estimated waiting time.
2.1 Running and recovery times
Stochastic train running times were first modelled by Steckel [14]. He performed
multiple simulations (# 400) with random input for different locomotive hauled
trains and found Weibull distributed running times independent from the route
and train characteristics with positive skew and parameter between 1.2 and 3.0.
The peak factor (ratio of pure running time plus margin/ pure running time
varied strongly due to route conditions and train mass (Fig. 1). An approximate
estimate of the superior value based on simple regression functions of the share
of acceleration time is used to calculate the necessary running time margin of a
certain route without intensive simulations.

Figure 1: Frequency of running time peak factors of passenger trains (source:
Steckel).
Empirical distributions of exact running times can be easily derived from
track occupation and release data which are recorded and saved automatically by
the existing signalling and safety system. As these data only contain the passing
times per train number at main signals and these are distant from the stopping
points at platforms the additional deceleration and acceleration time respectively
from and to the last (first) main signal needs to be estimated taking into account
the remaining distance between the last/first measuring point and the stop
location, as well as the train characteristics (length, weight, power, standard
deceleration/acceleration rate). At TU Delft the tools called TNV-Prepare and
TNV-Filter [15] have been developed by which the recorded passing times at
signals and insulation joints of any train can be filtered and the real running
times and delays per train series be computed automatically according to their
route, type and period of the day.
The statistical analysis of the precise running times per train line enables to
determine the percentile of running times within a certain level of probability
(Fig. 2). Furthermore, the true minimal running times per link can be revealed at
Timetabling 37
a precision of seconds by selecting only those trains that were delayed at the
preceding departure station and experienced no hinder.

Figure 2: Distributions of running speed of a train series in case of (no)
hinder North of the station The Hague HS (September 1999).
As the running times depend not only on the alignment, number of and dwell
times at intermediate stops, type, length and weight of rolling stock operated, but
also on the behaviour of the train drivers and the weather conditions, the specific
performance distributions can be sorted and used as information for quality
management and fed back to timetable designers and operations personnel.
The running time distributions per train line, thus, can be used for specifying
the amount of recovery time to be applied in timetables instead of using standard
supplements for all links and trains. The recovery times needed for achieving a
certain punctuality level of the train arrivals based on departure delay
distributions can be estimated numerically by means of convoluting the integrals
of the departure delays and running times per link and train line [16].
2.2 Minimal headway and buffer times
In practice, timetable designers mostly apply standard mean minimal headway
times (2 to 5 min) between train paths depending on the type of conflict and train
sequence. The existing buffer times in a conventional graphical timetable which
indicate only the train paths and headway times at a scale of minutes cannot be
determined sufficiently, because these do not indicate the precise start and end of
the capacity consumption according to the prevailing signalling an safety system.
The minimal time headway between two trains on a railway route is governed
by blocking times of trains and its speed differences [17, 18]. The blocking time
graph of a train represents the time instances that a train needs to run safely
without hinder at design speed over a sequence of track sections. The scheduled
train paths virtual as well as the track occupancy times are represented in a time-
distance diagram and indicate clearly the remaining buffer times. Any overlap
between the blocking times of different trains clearly indicates a timetable
conflict, which needs interaction in order to avoid a deceleration or stop of the
following train.
The blocking times depend not only from the signal spacing and train length,
but also from the actual train speed and deceleration rate. If the movement
authority for the train at sight distance of the distant signal is given late because
of insufficient headway to the preceding train, the following train would be
decelerated automatically, which means an increase of the blocking time. From
empirical analysis of train detection data at different Dutch railway stations
follows that the mean speed of trains approaching to a station is about 10 to 20 %
less than the design speed and may, in case of hinder, even be 50% less [19].
Furthermore, the scheduled dwell times are often exceeded during operations,
which lead to an increase of the blocking time of the routes serving the platform
tracks. The quality of timetable design would be enhanced considerably if the
estimated blocking times reflect well the variation of train speed and dwell times
in practical operations.
So far, the blocking times in timetables are assumed to be deterministic and
estimated with a precision of seconds. The arrival and departure times of trains
and the headway times between trains in most railway timetables, however, are
determined currently with a precision of minutes due to rounding-up of the
estimated running times and easy comprehension by the passengers. This
practice includes hidden scheduled waiting times, which could be exploited if the
determination of the arrival, departure and headway times (for in-company
planning and operation purposes) was done at a higher precision in steps of 5 to
10 sec (according to current practice in Japanese railways).

Figure 3: Division of an interlocking arrangement into route nodes [18].
For capacity estimation of heavily occupied routes in bottlenecks the track
infrastructure needs to be subdivided in individual route nodes: the smallest
track elements that can be used by one train at a time (Fig. 3). The variations of
time headway and train speed at heavily occupied junctions may lead to knock-
on delays and queueing of trains before network bottlenecks. On the routes
approaching to level crossings close to main stations we observed a significant
drop of the mean train speed by a bout 20 to 50% with regard to design speed
Timetabling 39
which means a clear reduction of infrastructure performance. This means the
scheduled speed and headway times must correspond better to real operations
and the train drivers need to be supported by dynamic speed advices in order to
avoid hinder to and by other trains at junctions. In fact, the blocking times are
stochastic, and not deterministic, and so are the remaining buffer times (Fig. 4).

Figure 4: Distribution of blocking times of a train series at the station The
Hague in case of (no) hinder (September 1999).
The probability density of the capacity consumption of the trains passing at
bottlenecks could be represented by stochastic blocking time waves. The range
of blocking times covered by the stochastic waves of each train line indicates the
extra use of capacity due to the variation of real operations in comparison with
the deterministic blocking time estimated on the basis of the scheduled running
time and possibly dwell time per train.
The total track occupancy and the remaining timetable slack of a given line is
estimated finally by means of a virtual compression of the blocking time graphs
according to the new UIC norm 406 capacity [20]. It recommends maximal track
occupancy rates of 75% during peak hours and 60% a day for lines used in
mixed traffic.
2.3 Waiting times
Any timetable comprises scheduled waiting times and generates, in practical
operations, non-scheduled waiting times. Scheduled waiting times result from
differences between the scheduled and desired travel, headway, departure or
arrival times. The latter depend on the market demand, track possession times
due to maintenance and conflicts between resulting different train graphs at
bottlenecks, whereas non-scheduled waiting times can emerge from technical
failures of track infrastructure or rolling stock, accidents, and train delays.
Scheduled waiting times may occur randomly and its amount is used as indicator
of timetable quality, whereas non-scheduled waiting times are experienced as
train delays during operations. The latter serve as indicator of operations quality.
The higher the reliability of tracks and rolling stock, the higher is their
availability for operations and the practical capacity. The total waiting time
during a certain time period, in general, increases exponentially with the number
of trains operated. The challenge is to find an optimal track occupancy that
enables a desired level of service, which can be defined by a certain amount of
waiting time.
Schwanhusser [1] developed already in 1974 a stochastic approach for the
estimation of the mean queue length as function of the distribution of primary
delays, buffer time, mean headway, train sequence and priority by a model of the
type M/D/1. This led e.g. to an estimated mean buffer time of 1 min in case of a
minimal headway of 2 min and all trains delayed (p. 59). As the assumed
Poisson distribution of train arrivals near bottlenecks could not be confirmed
later on, other queueing models of the type G/G/1 and M/G/1 have been
developed by Wakob [2] and Hertel [3] respectively.
Hertel developed further an analytical approach for the determination of the
optimal train intensity, which is situated between the minimal relative timetable
sensitivity (partial derivative of mean waiting time to track occupancy) and the
maximal traffic energy (defined as product of train intensity and speed). The
range of optimal use of track capacity as function of the waiting time, speed and
energy of the route, in general, lies at about 150 to 200 trains per day, while the
mean waiting time per train would be up to about 10 min.
Wendler [4] extended in 1999 the existing two-train queueing model to a
three-train model of type G/G/1 in order to estimate the impact of available time
lags between the headway times on the main track of a junction for intermediate
merging and crossing of trains. This approach is suitable for modelling the
process of independent random requests for infrastructure capacity from different
train operators and estimating the resulting waiting times due to timetable
adaptation of train paths, headways and synchronization.
The relative errors of the estimated waiting times by the different queueing
models with regard to the waiting times computed by micro-simulation in the
case of the railway node Mannheim/Ludwigshafen as a function of track
occupancy for exponential inter-arrival times are shown in Fig. 5. The 2-train
queueing model of Wakob (thin line) generates exponentially increasing errors
for individual l route nodes at higher occupancy rates of 0.7, whereas the Light-
Traffic approximation of the 3-train model (bold line) of Wendler performs best
up to 0.5 occupancy and the Heavy-Traffic approximation is the best analytical
estimation for occupancy rates between 0.6 and 0.8.
Kaminski [12] analysed the blocking and buffer times in the existing
timetable, as well as the recorded train delays for a large network of more than
2000 km in Germany and found a good fit of the buffer times with a negative-
exponential distribution. The available buffer time was less than 1 min (standard
minimal buffer time of Deutsche Bahn) in about 8% of the train sequences. He
investigated the impact the length of buffer times that correspond to 80% of the
recorded train delays at a number of stations by means of multiple simulation
Timetabling 41
while maintaining the train order. The results showed a mean consecutive delay
per delayed train of about 30 sec and a reduction of 9% of the estimated hinder
between trains. Thus, the expected operations quality could be improved by
means of tailored buffer times per route section as function of the distribution of
train delays.

Figure 5: Relative error of waiting time estimation by different queueing
models compared to micro-simulation (source: Wendler).
Microscopic simulation tools like STRESI [8], RailSys [9] OpenTrack [10]
respectively estimate the total waiting times of lines and networks by means of
computing the impact of multiple drawing of random primary delays from a
predefined distribution on total waiting times. The virtual hinder generated by
modification of the scheduled blocking time graphs is transformed automatically
into suitable conflict resolution measures (bending of train paths, increasing of
dwell times, change of train order and routing), while the impact is estimated by
the distribution of the total amount of delays, the kind and percentage of
hindered trains and the punctuality level.
The timetable slack of interconnected lines in networks with periodic
timetable depends not only on the buffer times of the individual lines, but also on
the buffer times between the scheduled train arrivals and departures at the
transfer stations. The following constraints for the design of an integrated
network timetable hold:
The round trip time of a line must be integer multiple of the headway,
The travel time between the nodes (sum of the running and dwell times)
must be an integer multiple of half of the cycle time (mostly 60 min),
The scheduled arrival and departure times of interconnected lines at the
nodes must overlap sufficiently,
The sum of the travel times on a circuit between three nodes must be an
integer multiple of the cycle time and of the time headway.
As these constraints lead to a great complexity of periodic timetables in large
networks with many nodes and lines, combinatorial methods by means of
mathematical programming have been developed to find an optimal solution for
integrated network timetables [6]. The network timetable problem is known as
NP-complete and requires the development of intelligent algorithms to solve
within a reasonable computation time if a solution for the given constraints
exists and/or to relax some timetable constraints in order to achieve an
approximate solution. The predefined minimal headway and transfer time
constraints applied in combinatorial models dont guarantee its practical
feasibility in complex junctions and need to be proven by a detailed analysis of
blocking times.
The existing buffer times and its distribution in periodic timetables of large
networks can be calculated analytically by means of the (max, +) algebra
approach, which is characterised by a transformation of the timetable constraints
into a set of simple recursive linear equations [21]. This approach enables to
identify the critical circuits within the network and to calculate the minimal cycle
time of the timetable, as well as the existing timetable slack. A tool for the
automatic transformation of conventional periodic network timetable constraints
into a (max,+) state matrix of the travel times, minimal headway times and
transfer times, for critical circuit and recovery time analysis has been developed.
The impact of an increase or decrease of travel times and buffer times on the
timetable slack and on the location of the critical circuit of periodic network
timetable can be estimated rapidly, as well as the propagation of train delays in
the network.
3 Operations quality
The operations quality can be assessed by means of different analytical
approaches and micro-simulation. A sufficient level of performance requires, of
course, that the basic timetable is feasible and the scheduled running times, dwell
times and headways are realistic, which means the timetable must not contain
any conflict between train paths proven by the absence of overlaps between the
blocking time graphs. The impact of primary delays on the robustness of train
services is expressed e.g. by the queue length, amount of knock-on delays, the
number of involved trains, links and stations, as well as the fading-out time.
Given a certain distribution of primary delays, the consecutive delays may not
grow steadily due to insufficient buffer times. The scheduled times and track
occupancy, thus, must allow for recovery.
3.1 Queueing model of RWTH Aachen
Schwanhusser [1] defined the smoothness of operation as the share of
unscheduled waiting trains at any location in order to proceed. He developed an
analytical approach for estimating the consecutive delays in case of hinder based
on queueing theory. The admitted level of hinder during operations was defined
empirically by a maximal queue length (equal the maximum total consecutive
delays per day), which is given by a simple exponential equation as function of
the share of passenger trains:
L
W
=
pP
e

L
W
: queue length [-]
, : coefficients
Timetabling 43
pP : probability of passenger trains
L
W
= 0.257
pP
e
3 . 1
(calibrated function for Deutsche Bahn AG).

Three different levels of quality of operations (0.5=very good, 1.0=satisfactory,
1.5=unsatisfactory) are defined by the ratio of the estimated length of queue
divided by the maximum admitted length of queue. The standard maximum
amount of knock-on delays to be expected due to operation of a certain number
of trains admitted by Deutsche Bahn is 130 min up to 300 min per day depending
on the share of passenger trains. These threshold values of maximum waiting
time, however, look somewhat arbitrary and seem to need further empirical
validation. The estimation of the scheduled and unscheduled waiting times as a
measure of operations quality of a given timetable, infrastructure and signalling
system is implemented in the software tool ANKE developed at RWTH
Aachen [22].
3.2 New probabilistic model of TU Delft
The weakness of queueing models in case of periodic timetables can be
overcome by an advanced probabilistic model of the process times of each train
line (running or arrival time, dwell time, departure time) as stochastic variables,
while the hinder due to signalling and route conflicts by delayed trains and its
priority are taken into account [16].
The approach is based on the stochastic variations of track occupancy times
e.g. the variations of train speed in case of different signal aspects with
conditional probability distributions. Distinction is made between
hindrance of approaching and departing train respectively by late
release of preceding block or route section and
Hindrance of approaching and departing train respectively by late
release of crossing (merging) of routes.
The model is solved on the basis of a numerical approximation of the Stieltjes
convolution of individual independent distributions.
The delay propagation to a train approaching to a station is modelled
depending on the actual signal aspects, which may force the train de decelerate
or even to stop. The arrival time distribution can be estimated by the probability
that the train experiences more or less hinder and the conditional probability of
the arrival time in case of each condition. This distribution is formulated as,
p
i
3
p p
i i
A
h 1
F (x) P[A x] P[(A x) | (Condition h)] P[Condition h]
=
= =

The departure of a train at station is modelled analogously as function of the
probability of dwell time extension and route conflicts and the distribution of
running times until release of the routes. For more details of the analytical model
see [16]. The calculation of the convolution is done numerically by applying the
composite trapezoidal rule. The proposed model has been validated by means of
train detection data recorded at The Hague HS station. To validate the model, we
obtained the required input distributions on the basis of empirical track
occupation and release data.
3.3 Stochastic timetable optimisation model of EU Rotterdam
Vromans [7] developed recently a timetabling model based on a Periodic Event
Scheduling Problem (PESP) approach and combined with a reliability evaluation
by means of simulation with a fixed order of events. The delay propagation is
calculated by performing a number of consecutive runs of the scheduled trains,
while these are perturbed by exogenous random disturbances and measuring the
resulting arrival delays. The objective of the linear programming model is to
minimise the mean arrival delay over all runs by means of an optimal allocation
of the running time supplements along the line. If the standard 7% running time
supplement of the Dutch Railways was distributed optimally instead of linearly,
the punctuality of the trains operated in the investigated cross-country corridor
Haarlem-Maastricht would be increased significantly.
3.4 Micro-simulation
The propagation of non-scheduled waiting times (delays) in large networks of
interconnected lines can be modelled also by micro-simulation. Watson [23]
compared the characteristics of current commercial simulation tools and
concluded that signal berth level tools are necessary for stochastic simulation.
Simulation tools mostly require interaction of the user in case of conflicts
between blocking time graphs or the application of a predefined automatic
conflict resolution strategy. For the evaluation of different dispatching
measurements on the stability margin and the location of network bottlenecks in
case of disturbance different options can be computed. The analysis of individual
link and train dependent recovery times would allow a variety of experiments to
estimate the robustness of different re-scheduling options (re-timing, re-ordering,
re-routing). The effectiveness of different conflict resolution strategies can be
evaluated on the basis of the amount of disturbance (primary delay, knock-on
delays, punctuality) and fading-out time.
4 Conclusions
The current methods and tools for railway timetable design enable a high
precision of the estimated travel times, headway times and time margins in order
to achieve high-quality conflict-free deterministic timetables for lines and
networks. Queueing models and micro-simulation tools have been applied
successfully to improve timetable quality and to estimate stochastic train delay
propagation on lines, in stations and networks. The key for high-quality
timetabling is a precise estimation of blocking times based on realistic running,
dwell and headway times taking into account the signal spacing and train
processing at critical route nodes and platform tracks. Statistical analysis of
empirical track occupation and release data in Dutch stations has revealed that
the trains mostly leave later and operate at speeds less than scheduled due to
drivers and conductors behaviour, lack of movement authority and routes still
locked for other delayed trains. Deterministic models for estimation of the
stability or optimisation of network timetables, like max-plus algebra technique
Timetabling 45
or linear programming, may not represent real operations and lead to suboptimal
solutions.
As queueing and simulation models for estimation of unscheduled delays in
daily traffic, too, do not reflect sufficiently the impact of speed variations and
behaviour of railway staff and may be based on invalid input distributions, new
stochastic analytical approaches have been developed recently in the
Netherlands. The probabilistic model of TU Delft enables an estimation of the
survival rate of knock-on delays at platform tracks and junctions based on the
distributions of the involved train pairs. It allows an estimation of the admitted
maximal number of trains and distribution of consecutive delays at a given
primary delay and level of punctuality. The stochastic timetable optimisation
model of EU Rotterdam helps to find an optimal distribution of running time
supplements along a line that may increase punctuality significantly.
Acknowledgements
This publication is a result of the research project Modelling and analysis of
operations in railway networks: the influence of stochasticity supported by the
Dutch research foundation STW and Transport Research Centre of Delft
University of Technology.
References
[1] Schwanhusser, W. (1974) Die Besessung der Pufferzeiten im
Fahrplangefge der Eisenbahn, Verffentlichungen
verkehrswissenschaftl. Institut RWTH Aachen, PhD thesis, H. 20
[2] Wakob, H. (1985) Ableitung eines generellen Wartemodells zur
Ermittlung der planmigen Wartezeiten im Eisenbahnbetrieb unter
besonderer Bercksichtigung der Aspekte Leistungsfhigkeit und
Anlagenbelastung, Verffentl. verkehrswissenschaftl. Institut RWTH
Aachen, PhD thesis, H.
[3] Hertel, G. (1992) Die maximale Verkehrsleistung und die minimale
Fahrplanempfindlichkeit auf Eisenbahnstrecken, Eisenbahntechn.
Rundschau ETR, 41, H. 10, 665-672
[4] Wendler, E. (1999) Analytische Berechnung der planmssigen
Wartezeiten bei asynchroner Fahrplankonstruktion, Verffentl.
verkehrswissenschaftl. Institut RWTH Aachen, PhD thesis, H. 55
[5] Huisman, T., Boucherie, R.J., van Dijk, N.M. (2002) A solvable
queueing network model for railway networks and its validation and
applications for the Netherlands, EJOR., 142, 30-51
[6] Cordeau, J.F., Toth, P., Vigo, D. (1998) A survey of Optimization
Models for Train Routing and Scheduling, Transportation Science, Vol
32, (4), 380-404
[7] Vromans, M.J.C.M. (2005) Reliability of Railway Systems, PhD thesis,
Erasmus University Rotterdam
[8] Schultze, K. (1985) Modell fr die asynchrone Simulation des Betriebes
in Teilen des Eisenbahnnetzes, Verffentl. verkehrswissenschaftl. Institut
RWTH Aachen, PhD thesis, H. 38
[9] Radtke, A., Hauptmann, D. (2004) Automated planning of timetables in
large railway networks using a microscopic basis and railway simulation
techniques, Computers in Railways IX, 615-625
[10] Nash, A., Huerlimann, D. (2004) Railroad simulation using OpenTrack,
Computers in Railways IX, 45-54
[11] Carey, M., Carville S. (2000) Testing schedule performance and
reliability for train stations, Journal of Operational Research Society,
Vol. 51, 666-682
[12] Kaminsky, R. (2001) Pufferzeiten in Netzen des spurgefhrten Verkehrs
in Abhngigkeit von Zugfolge und Infrastruktur, Wissenschaftl. Arbeiten
Institut fr Verkehrswesen, Eisenbahnbau und betrieb Universitt
Hannover, H. 56, PhD thesis, Hestra: Darmstadt
[13] Carey, M. , Carville S. (2003) Scheduling and platforming trains at busy
complex stations, Transportation Research, Part A, Vol. 37, 195-224
[14] Steckel, J. (1991) Strategische Optionen fr die zufllige Fahrzeit im
Eisenbahnbetrieb (Strategic options for the random running time in
railway operations), PhD thesis, Hochschule fr Verkehrswesen
Friedrich List, Dresden
[15] Goverde, R.M.P., Hansen, I.A. (2002) TNV-Prepare: Analysis of Dutch
Railway Operations Based on Train Detection Data, Computers in
Railways VII, 779-788
[16] Yuan, J., Hansen, I.A. (2005) Optimizing Capacity Utilization of
Statipons by Forecasting Knock-on Train Delays, 1st Int. Seminar on
Railway Operations Modelling and Analysis, Delft
[17] Wendler, E. (2001) Quality management in the operation planning
process by means of harmonized modeling, WCRR 25-29 Nov. Cologne,
paper no. 302
[18] Pachl, J. (2002) Railway Operation and Control, VTD Publishing
[19] Yuan, J., Goverde, R.M.P., Hansen, I.A. (2002) Propagation of train
delays in stations, in: Allan, J. et al. (ed.) Computers in Railways VIII,
WIT: Southampton, Boston, 975-984
[20] UIC Union International des Chemins de Fer (2003) Leaflet 405-1
Capacity
[21] Goverde, R.M.P. (2005) Punctuality of Railway Operations and
Timetable Stability Analysis, PhD thesis, TRAIL Thesis Series
T2005/10, Delft
[22] Vakhtel, S. (2002) Rechneruntersttzte analytische Ermittlung der
Kapazitt von Eisenbahnnetzen, Verffentl. verkehrswissenschaftl.
Institut RWTH Aachen, PhD thesis, H. 59
[23] Watson, R. (2005) Using stochastic simulation to predict timetable
performance status and developments in the UK, 1st Int. Seminar on
Railway Operations Modelling and Analysis, Delft
Timetabling 47
A Decision Support System for railway
timetabling (MOM): the Spanish case
1 2 2 1 1
& M. Abril
1

1
DSIC, Universidad Politcnica de Valencia, Spain
2
DEIOAC, Universidad Politcnica de Valencia, Spain
Abstract
Train timetabling is a difficult and time-consuming task, given the complexity
and number of constraints to be taken into account. A feasible train timetable
should specify the departure and arrival time of each train to each location of its
journey so that the line capacity and other operational constraints are met.
Traditionally, train timetables have been generated manually by drawing trains
on the time-distance diagram, where train schedules are manually adjusted so
that all constraints are fulfilled. This process can take a long time and it usually
stops once a feasible timetable is found. The difficulty of the process increases in
complex and high-loaded networks and the resulting timetabling may be far from
optimal. In this work, we present MOM: a friendly, flexible, computer-based
Decision Support System (DSS) whose main goal is to support the railway
planner to efficiently obtain optimized train timetables. The system generates
feasible and high quality timetables by considering the set of constraints of the
problem and optimization criteria related to the use of railway infrastructures and
operator requirements. The railway planner can obtain several solutions
automatically, by modifying certain parameters (departure interval, frequencies,
among others). Hence, the user can analyze them and take decisions about
conditions related to railway traffic and infrastructure. Furthermore, an important
feature of the DSS is the consideration of hard and soft constraints which makes
the search process more flexible and reaches better solutions. The developed
DSS offers assistance in train scheduling, conclusions about the maximum
capacity of the network, identifying bottlenecks, determining the consequences
of changes, providing support in the resolution of incidents, and alternative
planning in on-line scheduling for real traffic control. This DSS software is being
successfully used by the Spanish Manager of Railway Infrastructure (ADIF).
Keywords: Decision Support System, train timetabling, railway capacity,
on-line scheduling.
F. Barber , P. Tormos , A. Lova , L. Ingolotti , M. A. Salido
Timetabling 49
1 Introduction
European railways are undergoing a period of massive reforms that include the
separation of infrastructure management from operators, which involves the
open access to new operators competing for the use of the available
infrastructure. This new scenario requires an improvement in the use of existing
railway infrastructures, increased efficiency and the consideration of a more
customer-oriented view looking for increasing the quality of the services they
offer. The Spanish Manager of Railway Infrastructure (ADIF) is also involved in
this process and is continuing the direction started some years ago, which is
focused on the improvement of the use of the network capacity and the increase
in quality of the services offered to customers. The Spanish railway network
consists of 13,177 km of line that supports a heterogeneous traffic with around
5,000 daily trains, travelling a total of 494,230 km per day. The topology of the
Spanish network is radial and is managed taking into account the scheduling of
lines with few changeovers. Since is to make the best use of the available
resources, one of the specific goals of ADIF is the automatic generation of train
timetables that fulfil the existing constraints and optimize several quality criteria.
The MOM project is a long-term collaboration between the Polytechnic
University of Valencia and ADIF. The aim of the project is the development of a
Decision Support System that offers assistance in train scheduling, obtaining
optimized timetables, conclusions about the maximum capacity of the network,
identifying bottlenecks, determining the consequences of changes, providing
support in the resolution of incidents, providing alternative planning, and real
traffic control, etc.
There are several, useful software systems for railway planning management:
RAILSYS, DONS, PETER, ROMAN, VIRIATO, CAPRES, FASTA, AFAIG,
DEMIURGE, SISYFE, RAILCAP, OPENTRACK, OPENTIMETABLE,
VISION, CMS, TPS and MULTIRAIL among others [2, 4]. All these systems
have Infrastructure Management, Evaluation, and Simulation Management
modules. Some of them have capabilities of on-line scheduling, timetable
optimization, and capacity analysis. All these modules are integrated in MOM
with different levels of development. Therefore, MOM can be considered as one
of the most complete DSS software systems for railway timetabling, since it can
support managers of railway infrastructure, in the difficult decision-making
process they face.
2 Railway problem description
Given a railway line which may have both single and double-track sections, the
railway timetabling problem consists in adding new trains (periodic or non
periodic) to the line in such a way that the timetable assigned verifies the
existing constraints and optimizes a multi-objective function. The railway line
may be occupied by other trains whose timetables cannot be changed, and the
new trains may belong to different operators with different priorities. The
stations to be visited by each train may also be different from each other. The
objective of the system is to obtain a feasible and optimized timetable taking into
account: (i) the railway infrastructure topology, (ii) user requirements
(parameters of trains to be scheduled), (iii) traffic safety rules, (iv) traffic
previously scheduled on the same railway network, and (v) optimization criteria.
Table 1 shows the main constraints that are taken into account by MOM.
Table 1: Constraints considered by MOM.
Railway Timetable Constraints Type
Time Interval for the Departure of the First Station Operator
Time Interval for the Arrival to the Final Station Operator
Maximum Delay allowed Operator
Frequency (for a set of periodic trains) Operator
Commercial Stops in Stations Operator
Journey Times (for each track section) Operator
Avoidance of Crossings (in one-way track sections) Traffic
Avoidance of Overtaking on track sections Traffic
Delay for a non specified commercial stop Traffic
Reception/Expedition times in crossing/overtaking
operations.
Traffic
Avoidance of Simultaneous Departures in stations Traffic
Finite track capacity of stations for traffic operations Infrastructure
Station Closing Times for traffic operation Infrastructure
Headway Times Infrastructure
3 General Architecture of MOM
We have developed a flexible software system whose main goal is to assist the
railway planner to design high-quality train timetables with a reasonable
computational time. MOM generates feasible and high quality timetables by
considering both the set of constraints of Table 1 and the multi-objective
function specified. Moreover, the railway planner can also modify different
parameters (departure interval, maximum delay, closing time, number of tracks,
etc.) to adjust user/infrastructure requirements and obtain different solutions,
analyze them, and take decisions about both railway traffic conditions and the
available railway infrastructure.
Figure 1 shows the basic architecture of MOM. We have structured MOM in
two main components: the interface and the optimizer. The interface allows the
user to configure the scenario on which the optimization will be carried out; and
the optimizer is responsible for providing the planner with a feasible, high-
quality timetable according to the constraints specified and the user
requirements.
The interface module acquires the required railway infrastructure data directly
from standard databases. The optimizer implements advanced Constraint
Satisfaction and Optimization techniques to find feasible and high-quality
timetables. A detailed description of the scheduling methods integrated in MOM
Timetabling 51
is available in [1, 3, 5]. Once the first timetable is obtained, it is available to the
user in a graphical or textual format, together with a detailed report about its
main characteristics. Afterwards, MOM can obtain other successive and
alternative timetables.

Figure 1: Components of MOM Interface.
In the interface module of MOM, the user can establish parameters
corresponding to constraints, railway infrastructure, or trains. The main interface
functions are described in the following points.
3.1 Railway line and train selection
The user selects the railway line to be used and the trains that will be taken into
account by the optimizer. Some of these trains can be considered as trains in
circulation. Therefore, their timetables are fixed and will not have to be modified
during the solving process. The rest of the trains will make up the List of Trains
to be Optimized (LTO), that is, the trains that need to be made compatible with
the fixed trains over the given railway infrastructure.
3.2 Journey, train and traffic constraints
The main journey, train, and traffic constraints that the user can parameterize are
shown in Table 1: the time interval for the departure of the first station and/or
arrival to the final station for each train, the running time for each track section
MOM SYSTEM
Timetable
Database
INTERFACE
SELECT RAILWAY LINE
SELECT TRAINS
CONFIGURE
OPTIMIZER
PARAMETERIZE
CONSTRAINTS
DISPLAY
RESULTS
SAVE
SOLUTION
Infrastruture
Manager Database
OPTIMIZER
OPTIMIZE
Railway
Operator
Database
corresponding to the journey of each train in the LTO, maximum delay allowed
for each train, the headway time between consecutive trains in the same
direction, the reception and expedition times for crossing or overtaking
operations, minimal time interval between consecutive departures in stations,
the finite track capacity of stations, the closing time in stations for traffic
operations, the frequency for periodic trains, the time intervals for infrastructure
maintenance, the selection of locations for technical stops of some trains, and the
delay for a non specified commercial stop due to unexpected acceleration and
braking times. The main interface of MOM is shown in Figure 2.

Figure 2: Main interface of MOM.
3.3 Optimizer configuration
The optimizer module uses a multi-objective function to assess the quality of
feasible timetables. This function is composed by several weighted criteria: the
average delay for each train, the number of traffic operations, the balance of the
delay between upward and downward trains, etc. The weight assigned to each
criterion is determined by user. According to the weight given to each criterion,
the process searches for the solution that best fulfils the considered objective
function. Furthermore, the user can bound the computational burden allowed for
optimization. Hence, the obtained timetable will always be feasible, and it will
be the best possible timetable according to the weighted optimization criteria and
the allowed computational time. In this way, MOM can also be used as an any-
time scheduler.
Timetabling 53
4 Main capabilities of MOM
MOM can optimize existing timetables, schedule and obtain automatically
optimized timetables for new periodic and/or non-periodic trains and make them
compatible with the existing scheduled trains. The system can also be used to
reschedule timetables according to disruptions and delays in on-line, real-traffic
management as well as validate and perform capacity analysis.
4.1 Off-line railway planning
MOM obtains optimized railway timetables in accordance with commercial/user
requirements, railway infrastructure, traffic constraints, and optimization multi-
criteria. MOM is mainly configured as a computer-based support system for
railway scheduling. Hence, the user can easily adjust several parameters (traffic
constraints, infrastructure data, train data, journeys, etc.) and obtain correct and
optimized timetables with different properties, allowing the user to make the
final best selection. In addition, a given timetable could be interactively modified
by the user, which can use MOM in order to validate its correctness.
4.1.1 Flexible optimization
MOM implements two optimization modes Standard Mode and Flexible
Optimization Mode, which can be selected by the user in each optimization
process. Standard Optimization (which is the default mode) implies the
satisfaction of all the operator, traffic, and infrastructure constraints. In the
Flexible Optimization mode, some constraints are considered as Soft Constraints,
so that they can be relaxed if the resulting timetable is considerably improved.
For instance, the travel time of a given train between two stations would be
diminished by 3% in order to avoid a crossing operation with a train going in the
opposite direction. Alternatively, the reception time could be relaxed 30 seconds
in that station.
The constraints that can be relaxed in the flexible optimization mode are: the
running time of a train in sections, and the temporal margins for reception,
expedition, and headway. The user establishes the allowed relaxation bounds for
these constraints.
The flexible optimization is applied by MOM if and only if (i) the user selects
the Flexible Optimization mode, and (ii) the relaxation of the allowed soft
constraints is justified with the improvement achieved in the timetable. After a
flexible optimization is performed, a set of constraints is proposed to be relaxed.
The user can select to validate all of the relaxed constraints, a subset, or none of
them, according to viability of the proposed relaxations and the achieved
improvement. All the relaxed constraints in a final timetable have to be validated
by the user.
Figure 3a, illustrates a feasible timetable obtained by an expert planner, with a
total travel time of 46:41:30. This timetable has been automatically optimized by
applying the flexible optimization module of MOM. The total travel time is
reduced by 5:36:05, (total travel time: 41:05:00) by relaxing some constraints
(Figure 3b).
(a) (b)
Figure 3:
4.2 On-line railway planning
MOM can be used to reschedule traffic timetables according to disruptions and
delays in on-line and real-traffic management. The system supports the user in
the decision making when disruptions occur. Two objectives can be selected in
order to obtain an updated timetable after disruptions: (i) the minimization of the
difference between the original timetable and the new timetable for each station
and (ii) the minimization of the difference in scheduled arrival time of trains to
the final station of their journeys. Figure 4 shows four incidences in a sample
instance: two trains that are behind schedule and two trains that are ahead of
schedule. After the application of the on-line railway planning module of MOM,
the original timetable is updated taking into account the new situation.

Figure 4: On-line scheduling.
4.3 Railway capacity analysis
Optimizing the use of railway infrastructure is a complex and difficult task.
Questions such as What part of extra traffic can be absorbed by the existing
(a) A Standard-Optimized timetable. (b) Improved timetable using
Flexible-Optimization.
Timetabling 55
infrastructure?, How much investment will be required for new
infrastructure? are important and difficult questions to answer.
The goal of capacity analysis is to determine the maximum number of trains
that would be able to operate on a given railway infrastructure during a specific
time interval, given the operational conditions. MOM can validate and perform
capacity analyses of railway infrastructures. The systems can perform both
theoretical and practical capacity analyses. In the first case, an analytical study
is carried out, whereas the practical analysis is based on simulation (Figure 5). In
both cases, if operational conditions and/or railway infrastructure change, the
system is able to efficiently update the results of the analyses.
Figure 5: Analysis of line capacity.
5 Some computational issues
MOM is a very efficient software tool. The computational effort to obtain a
satisfactory optimized solution depends on the number of trains, the railway
infrastructure and its capacity (tracks in stations, single/double-way tracks), the
required traffic operations due to the load of the network, etc.
Typically, the computational time required for very complex and real
problems varies between a few seconds and 2-5 minutes. For instance, a railway
timetabling problem that implies the scheduling of 95 new trains, with 37 trains
already in circulation (with fixed timetables), on a line of 271.1 Kms, with 51
single-way track sections is optimized by MOM in less than 60 seconds. This
scheduling problem implies the solution of 136 crossing conflicts. In this case,
the search space is composed of 8.7 E+40 possible solutions. In order to reduce
the search space, MOM makes use of several pre-processes, Operations Research
techniques, and powerful, intelligent heuristics [3]. Moreover, several levels of
optimization can be selected by the user. The minimum level obtains in a few
seconds a feasible but middle-optimized timetable, so that the user can easily and
efficiently evaluate different scheduling parameters and alternative timetables.
The maximum optimization level obtains higher quality timetables when the
computational time is longer. Figure 6 shows the optimization level with respect
to the computational running time of three similar examples to the previous one.

86
88
90
92
94
96
98
100
3
0
7
5
1
2
0
1
6
5
2
1
0
2
5
5
3
0
0
3
4
5
3
9
0
4
3
5
4
8
0
5
2
5
5
7
0
6
1
5
6
6
0
7
0
5
7
5
0
Computational Time (seconds)
%

o
f

O
p
t
i
m
a
l
i
t
y

Figure 6: Optimization level vs computational time.
6 Conclusions
A Railway DSS is presented in this work. The system has three main scheduling
modules:
i) Off-line Railway Planning, where the system solves and obtains
optimized railway timetables in accordance with: commercial/user
requirements, railway infrastructure, traffic constraints, and
optimization criteria,
ii) On-line Railway Planning, which reschedules traffic timetables when
disruptions, incidences, or delays occur, and
iii) Railway Capacity Analysis, which validates and performs capacity
analyses of railway infrastructure.
MOM can be integrated in existing computer-based tools and obtains the
required data from standard databases and friendly interfaces. This system is
currently being used successfully by the Spanish Manager of Railway
Infrastructure (ADIF) for obtaining off-line timetables. Currently, MOM is being
improved adding the consideration of the analysis of the robustness and the
stability of timetables generated. Further features of MOM can be obtained from
http://www.dsic.upv.es/users/ia/gps/MOM.
This work has been partially supported by the research projects TIN2004-06354-
C02- 01 (Min. de Educacin y Ciencia, Spain-FEDER), FOM-70022/T05 (Min.
A feasible solution is obtained
Acknowledgements
Timetabling 57
de Fomento, Spain) and FP6-021235-2, IST-STREP (UE). We appreciate the
assistance of Jose Estrada (Spanish Administration of Railway Infrastructure -
ADIF).
References
[1] Barber, F., M. A.Salido; L. Ingolotti; M. Abril; A. Lova; P. Tormos., An
InteractiveTrain Scheduling Tool for Solving and Plotting Running Maps.
Current Topics in Artificial Intelligence. Lecture Notes in Computer
Science/LNAI Series. Springer-Verlag. Vol. 3040, pp. 646-655, 2004.
[2] Hrlimann, D., Object oriented modelling of infrastructure elements and
business processes in railways. Ph D. Thesis. ETH Zurich.Switzerland,
2001.
[3] Ingolotti,L., F.Barber, P. Tormos, A. Lova , M. A. Salido, M. Abril, An
Efficient Method to Schedule New Trains on a Heavily Loaded Railway
Network. Advances in Artificial Intelligence. Lecture Notes in Computer
Science/LNAI Series. Springer-Verlag Vol. 3315. pp. 164-173, 2004.
[4] Middelkoop, D. Bouwman, M. Train network simulator for support of
network wide planning of infrastructure and timetables. In: Computer in
Railways VII, WIT Press, pp. 267-276. 2000.
[5] Salido, M.A., M. Abril , F. Barber, L. Ingolotti, P. Tormos, A. Lova.,
Topological Constraints in Periodic Train Scheduling. Frontiers in
Artificial Intelligence and Applications. Planning, Scheduling and
Constraint Satisfaction: From Theory to Practice. Frontiers in Artificial
Intelligence and Applications. IOS Press. Vol. 117, pp. 11-20, 2005.
Method and software tool for an optimized
passenger orientated connection management
M. Klemenz & A. Radtke
Institute of Transport, Railway Construction and Operation,
Leibniz University of Hannover, Germany
Abstract
The trust of customers in adherence to their expectation to a transport service
determines the modal split of passenger transport. Therefore, it has to be a goal
for each public transport operation company to maintain and to improve the
customers trust. An important service criteria by a customer accepted public
transport offer is travel time. The travel time depends not only on the running
time, the dwell time, etc., but also on the number of transfer procedures and the
transfer waiting time. One of the essential research problems in the surroundings
of the connection planning is the question of under which condition it is
appropriate for the planning of a connection. An important aspect to answer this
question is the evaluation of the additional total travel time for all involved
passengers in consideration of an achieved (additional travel time for transit
passengers in the connecting vehicle) or not achieved (additional travel time for
transfer passengers in the feeder vehicle) connection.
This paper develops a new method of optimized passenger orientated
connection management during the planning process (scheduled timetable). The
goal is to minimize the additional travel time in consideration of a planned or not
planned connection based on the number of all involved passengers. At first it is
necessary to identify all influencing variables. After that, all boundary conditions
will be modelled by using the graph theory. With an adequate shortest path
algorithm it is possible to generate connection strategies specific for stations,
lines or whole networks. The particularities of railway operation (e.g. turnaround
times, operating fleet, timetable interval, conflicts, infrastructure bottlenecks)
have also been considered in the model.
For practical use the software tool ANPLA was developed, which is helpful
for operating companies or for timetable construction and is used to solve the set
Timetabling 59
of problems in the surroundings of the connection management. Furthermore, the
paper includes approaches for a web based application.
Keywords: connection management, timetable construction, transit and transfer
passenger, graph algorithms, minimized travel time.
1 Introduction
In the surroundings of connection planning there is one essential research
question:
Under which condition is it appropriate to plan or not to plan a connection?
An important aspect to answer this question is the evaluation of the additional
total travel time for all involved passengers in consideration of an achieved or
not achieved connection.
If passengers can reach their final destination only by transferring from one
train into another train, the travel time increases according to the transfer time
(minimum transfer time and transfer waiting time). The holding of a connection

Figure 1: Case study for additional waiting times.
means an extension of the travel time for the passing through passengers (PTP).
The no holding of a connection increases the travel time of the transfer
passengers (TP). The travel time extension of the PTP in the connecting train and
of the TP in the feeder train is normally anti-proportionally. The amount of the
additional travel time for all concerned passengers depends of the difference
between the arrival time of the feeder train and the departure time of the
connecting train (figure 1). Additional dwell times only appear, if the technical
minimum departure time of the connecting train is less than the amount of arrival
time of the feeder train and the minimum transfer time (cases 1 and 4).
2 Influencing factors
The method for an optimized passenger orientated connection management and
the influencing additional total travel depends on several influencing factors:
- Number of transfer passengers.
- Number of passing through passengers.
- Arrival time of the feeder train.
- Minimum transfer time of the feeder train to the connecting train.
- Departure time of the connecting train.
- Departure time of an alternative connecting train (service interval of the
connecting train).
3 Determination of number of passengers
The method for an optimized passenger orientated connection management
requires information about the modal split, the demand matrix and the time or
date of a travel. For the determination of these values different resources are
applicable (e.g. statistical evaluation of tickets, interview and count of
passengers, positioning with handy ticketing, etc.).
4 Method for the optimized passenger orientated
connection management [7]
To minimize the additional dwell times in the planning process, it is necessary to
develop a method in consideration of the difference between the arrival time of
the feeder train and the earliest departure time of the connecting train, required
transfer times, the frequency of the connecting train (the earliest departure time
of an alternative connecting train) and the number of concerned passengers.
4.1 Single connection management
The developed method will be demonstrated at first for a two train model (Figure
2), with transfer passengers from the feeder train to the connecting train
(application: connection station is final destination of the feeder train).
Timetabling 61

Figure 2: Two train model.
Required data input:
- Number of passing through passengers (PTP).
- Number of transfer passengers (TP).
- Number of boarding passengers at connection station, without transfer
passengers (BP).
- Number of on the way boarding passengers (OBP).
- Distance between the amount of the arrival time of the feeder train and
the minimum transfer time and the technical minimum departure time of
the connecting train.
- Technical minimum departure time of an alternative connecting train.
This data allows the calculation of the break even point, which defines the
time distance between the arrival time of the feeder train (incl. the minimum
transfer time) and the departure time of the connecting train. With concern to a
minimized extension of travel times, time distance values below the break even
point involve a planning of the connection. Time distance values above the break
even point entail no planning of the connection.

Figure 3: Calculation of the break even point.
Figure 3 shows an abstract of the break even point calculation in correlation
of the proportion of the number of transfer passenger and the sum of the number
of passing through passengers, boarding passengers and on the way boarding
passengers and in correlation of the service interval of the connecting train.
The break even point calculation provides a comprehensive spectrum of
applications for the scheduling of timetables:
- Determination of the maximum allowed time distance between the
arrival time of the feeder train (incl. minimum transfer time) and
departure time of the connecting train.
- Determination of the required service interval of the connecting train in
cases of no planed connection strategy.
- Determination of required passing through passengers in cases of a no
planed connection strategy.
- Determination of required transfer passengers in cases of a planned
connection strategy.
- Determination of required minimum transfer time in cases of a planned
connection strategy.
4.2 Multiple connection management
In the next step the developed method will be advanced for a station specific n-
train model (Figure 4), with transfer passengers between all involved trains. The
model for a station specific connection management depends on graph

Figure 4: Graph of a station specific n-train model.
Timetabling 63
algorithms. Each graph represents a station with several train connections. The
starting node (source) is the pull into a station and the ending node (sink) is
the exit of the station. Each involved train has a connection link between source
and the second node. This second node represents the arrival time of this train
(tan). A waiting link connects the arrival time with a possible departure time
(tab) of this train. The number of different waiting time links depends on the
number of involved trains. Each waiting time link includes costs and is
representing a certain connection strategy of a train. The costs will be calculated
based on the additional travel time of all involved passengers. The last link
connects the possible departure time with the exit of the station (sink).
To detect an optimal connection strategy it is necessary to compare all the
possible waiting links of a train. The link with the lowest costs and therewith
the lowest additional waiting time for the concerned passengers is representing
the optimal connection strategy. Each train has only one optimal waiting link.
The calculation or selection of a waiting link of one train has no influence of the
detection of the waiting links of the other trains. This means that the calculation
of the optimal connection strategy is for a station specific n-train model for each
train independent. The optimal connection strategy for the whole station is the
sum of all calculated optimal waiting time links.
To identify the optimal connection strategy it is necessary to calculate the costs
of each waiting link (HK) of a train. Therefore two equations (1+2) are necessary:

Equation 1:
Costs of the waiting link Train xo without additional waiting time:
)) tan ( ( *
) ( ) )( ( ) (
1
) ( ) )( ( xo xo x x
n x
xo x
xo xo x
xo
xo
tab tmz T U HK + =

=
+ =

with xo = 1,, (n-1) and with x > xo
if xo = n HK = 0

Equation 2:
Costs of the waiting link Train xo is waiting for train x
( )
( )
( )
( ) )) tan ( ( *
)) (tan ) ((tan *
) (tan *
) (tan *
) ( ) )( 1 ( ) 1 (
1
) ( ) )( 1 (
) )( ( ) ( ) )( ( ) (
1
1
) )( (
) ( ) )( ( ) (
1
1
) )( (
) ( ) )( ( ) ( ) (
xo xo x x
n x
x x
xo xo x
xo z z xo x x
x z
xo z
xo z
xo xo x x
xo y
y
xo y
xo xo x x xo
x
xo
tab tmz T U IV
tmz tmz U III
tab tmz U II
tab tmz D I
HK
+
+ + +
+ +
+ +
=
+ +
=
=
+
=
+ =
=
=

with x = xo+1,...,n
Description:
(I): Additional travel time for passing through passengers of train xo
(II): Additional travel time for transfer passengers from train y (which
arrives earlier than train xo) into train xo
(III): Additional travel time for transfer passengers from train z (which
arrives later than train xo, but earlier than train x) into train xo
(IV): Additional travel time for transfer passengers from train x+1 (which
arrives later than train x) into train xo

U(x)(xo): Transfer passengers from train x to train xo
T(xo): Departure time of the next connecting train (service interval)
tan (x): Arrival time of the feeder train
tab (xo): Departure time of the connecting train
tmz (x)(xo): Minimum transfer time from train x to train xo
D (xo): Passing through passengers of train xo
x
xo
HK
Waiting link: Train xo is waiting for train x
Equation 3:
The link with the minimal costs (K Min Zug xo) is representing the optimal
connection strategy per train.
{ }
x
xo
xo
xo xo Min
HK HK Min Zug K ; =

Equation 4:
The sum of all minimal costs (K Min) is representing the station specific optimal
connection strategy:
=
=
=
n xo
xo
xo Min Min
Zug K K
1

4.3 Track specific connection management
In the last step the developed method will be advanced for an n-train model for
several stations (Figure 5), with transfer passengers between all involved trains.
The detection of an optimal connection strategy for several stations is distinctly
more complicated and complex than the detection of a station specific optimal
connection strategy. The determination of a path with minimal costs cannot be
done station by station. It must be done simultaneously. The required model also
depends on the graph algorithm. To model the connection management for
several stations it is useful to use a reference train (yo), which is driving through
all involved stations. The graph is representing the whole research area. The
source represents the first station of the reference train. The final node represents
the destination of the reference train. Links, constrained of the number of
possible connection strategies, connect the source with the following nodes.
These nodes are representing the new arrival time of the reference train at the
following station. The arrival time depends on the chosen connection strategy at
Timetabling 65
the predecessor station. Waiting time links are connecting these nodes with the
new arrival times at the next stations. At the last node all possible connection
paths are running together. Each waiting link is a possible connection strategy of
a train. The costs emerge from the additional travel times of all involved
passengers. The detection of the minimum costs overall cannot be calculated
train by train. Rather the costs have to be calculated for all influenced trains
together. Each possible waiting link of a train at a station will be combined with
all possible waiting links at the other stations. The link path (per station only one
link) with the minimal additional waiting time or travel time for all passengers is
representing the optimal connection strategy for the reference train and for all
influenced trains. For the calculation the Dijkstra [1, 2 and 3] algorithm will be
used (shortest path or path with minimal costs).
After the detection of an optimal connection strategy follows the verification
of the feasibility related to operational aspects. Not conflict free connection
strategies must be rejected. Their paths will be blocked and a new calculation
will follow.
Figure 5 shows two examples of an abstract of a possible graph model.
Example one is a very simple graph model. The connection strategies of the
reference train yo and the other trains yo+1(a1), yo+2 (a1) and yo+1 (a2) are
independent. They can be calculated by their own.

Figure 5: Example of a graph for the n-station and n-train model.
Example two shows that the connection strategy of train yo is directly
connected with the connection strategy of train y-1(a2). The detection of an
optimal connection strategy for the reference train yo is providing at the same
time the connection strategy of train yo-1(a2). The connection strategies of other
trains yo+1(a1) and yo+1 (a2) can be calculated by their own.
The connection strategy of a train, which scheduled departure time at a station
occurs earlier than the departure time of the reference train, depends on the
chosen connection strategy of the reference train at predecessor stations.
Example 2 in Figure 5 illustrates these dependencies: A reference train (train
yo) has fixed arrival times at the stations a1 and a2 depending on the chosen
connection strategy at the predecessor station. At station a1 train 1 has 2 options:
It can continue its journey without holding a connection or it can hold a
connection to train yo+1(a1). Therefore, the arrival time of train 1 at station a2
depends on the chosen strategy at station a1. At station a2 train yo-1(a2) has a
scheduled departure time which is located earlier than the possible arrival times of
train yo. This means that the waiting time costs of train yo-1(a2) depend on the
chosen connection strategy of train yo at station a1. If train yo-1(a2) is not waiting
for train yo, the additional travel time of transfer passengers of train yo increase.
This additional time is independent of the chosen connection strategy at station
a1. If train yo-1(a2) is waiting for train yo different additional waiting time costs
(depending on the chosen strategy in a1) for the passing through passenger in
train yo-1(a2) occur. This waiting time increase depending on postponed arrival
time of train yo. To find the minimal additional waiting time for all involved
passengers it is necessary to combine all possible connection strategies.
5 Software tool for the optimized passenger orientated
connection management
For the application of the method of a passenger orientated connection
management were developed the software tool ANPLA (Figure 6). ANPLA [7]
is based on the software and algorithm technology successfully used for the
implementation of Dispo [2, 3 and 6], the railway vehicle allocation tool of IVE.
ANPLA calculates for
n-trains,
n-stations and
n-connections
depending on
the number of concerned passengers,
the minimum transfer time,
the service interval of the connecting train and
the scheduled arrival and departure times
the optimized connection strategy of each train.
The user has, with ANPLA, a tool which could answer the question to plan
or not to plan a connection fast and reliably. ANPLA is a proper tool during the

Rescheduling 67

Figure 6: Screenshot: ANPLA.
timetable construction process to evaluate possible connections, to plan intervals
and to define the use of the platforms. Additionally, ANPLA is a useful tool
during the operation process and especially for the dispatcher to evaluate, if the
connecting train should hold the connection to a delayed feeder train. All railway
particularities (e.g. turnaround times, operating fleet, timetable interval, conflicts,
infrastructure bottlenecks) are considered in the method of an optimized
passenger orientated connection management. But, as well, the system is
applicable for all other public transportation systems (e.g. bus, ship or air traffic).
6 Workflow and web based application
After the first stand-alone tests phase of ANPLA the integration into the
RailSys
-Enterprise environment to support the timetable request and

construction process will be the next step. Figure 7 illustrates an adequate
modern workflow between different Train Operating Companies (TOC) and a
Railway Infrastructure Undertaking (RIU).
The TOC request train slots and other information from the RIU. In the past,
this process in general was a time consuming manual task using telephone, pen
and paper or simple spreadsheets. The web based RailSys
-CRM (Customer
Relation Management) solution for the Hamburg Port Authority (HPA) offers far
more possibilities to support this process taking into account the increased time
pressure for the planning tasks. TOC and RIU can save time of unnecessary
(multiple) data entry and, therefore avoid mistakes. Furthermore, the streaming
less flow of data enables the RUI to perform the time table construction on the


Figure 7: Timetable management workflow and application of ANPLA.

Figure 8: Example of the web interface of RailSys
-CRM.
Timetabling 69
bases of the original requests and follow up changes in a much better quality to
construct a non discriminating timetable. Using this technology, the RIU can
provide all necessary information to rail regulation authorities to prove the non
discriminating timetable construction according to the agreed timetable
construction rules. Figure 8 shows an example of the web interface of the
RailSys
-CRM [4, 5] module.

The integration of timetable construction and railway operation simulation
enables the RIU to analyse the performance and stability of the timetable before
setting the timetable into operation. Analogous to the railway operation
simulation, ANPLA will be integrated in this process to perform the planning of
various TOC driven passenger orientated strategies. For this task, the TOC
should submit their strategies or parts of their strategy regarding the passenger
connection in stations to the RIU. These additional requests would enable the
RIU to consider the TOC demands in a further dimension to construct timetables
in a much better quality.
7 Results and implementation
The overall result is the construction of a timetable with optimized total travel
times and dwell times at connection stations in correlation of the service interval
and the number of concerned passengers. The potentials for implementation and
the impacts for the railway business are for the timetable construction for train
operating companies and for an improvement of the service quality of the
transport offer by reducing the total travel time.
The new method of a passenger orientated connection management during the
planning process and the software tool ANPLA
- will reduce the transfer time,
- will arise the proportion of direct connections,
- will minimize the travel time of all concerned passengers,
- can be integrated into the complex timetable planning environments,
- are applicable for single, multiple or track specific connections, and
- are adaptive for all public transport systems.
References
[1] Ahuja, R., Magnati, T., Orlin, J. Network Flows, Prentice Hall, Upper
Saddle River, New Jersey, 1993
[2] Radtke, A., Software tools to model the railway operation, Habilitation at
the Institute of Transport Railway Construction and Operation, Leibniz
University of Hannover, 2005
[3] Schumacher, A., A hybrid method for vehicle allocation in rail traffic,
Dissertation at the Institute of Transport Railway Construction and
Operation, Leibniz University of Hannover, 2004
[4] Radtke, A., Timetable management and operational simulation:
methodology and perspectives, presentation of COMPRAIL 2006, Prag,
Czech Republic, (2006), proceedings page 579 589
[5] Timetable Construction and Simulation Tool RailSys
Enterprise and
RailSys
CRM: www.rmcon.de
[6] Loco Allocation Tool Dispo: www.ivembh.de
[7] Klemenz, M., Method of an optimized passenger orientated connection
management during the planning process, Dissertation at the Institute of
Transport Railway Construction and Operation, Leibniz University of
Hannover, 2008
Timetabling 71
Applying multiscaling analysis to detect
capacity resources in railway networks
A. Gille, M. Klemenz & Th. Siefer
Institute of Transport, Railway Construction and Operation,
Leibniz Universitt Hannover, Germany
Abstract
A substantial part of railway engineering is modeling of the real track
infrastructure and train operation processes in computer applications. The
electronic data created can be analysed and evaluated for research purposes.
Depending on the aim of the research, three different models can be used which
differ in their level of itemisation. Macroscopic models have a relative low level
of accuracy, mesoscopic a medium and microscopic models have the highest.
The Institute of Transport, Railway Construction and Operation (IVE,
Hannover) researches computing solutions to deliver the data in the requested
level of detail. This is then used for generating and providing infrastructure and
train operation data such as timetable data, running times of trains or block
occupancy times. The Multiscaling Analysis offers the opportunity to use the
appropriate model depth (level of detail) for each request and enables work to
progress efficiently.
For tasks like long term capacity planning in railway networks no high detail
level data is required normally, so macroscopic models can be initiated. To
verify if train paths of a timetable, developed on a macroscopic or mesoscopic
railway infrastructure, can actually be arranged without conflicts within the
block occupancy times or the headway, a more detailed microscopic model is
required. Therefore trains with only a low detail level of information like their
route, stopping locations and stopping times can be mapped onto a microscopic
infrastructure model to prove the feasibility and to determine capacity resources.
Keywords: infrastructure, capacity resources, networks, microscopic model,
mesoscopic model, macroscopic model, RailSys, NEMO.
Timetabling 73
1 Itemisation of railway infrastructure models
The detail level of a railway infrastructure or a railway operation model depends
on the quality and accuracy requirements for generating appropriate results, and
on the availability of the basic data. For some purposes high accuracy data is
non-existing or cannot be provided on time. Also formal and legal reasons might
prohibit free access to high detailed infrastructure data [1].
1.1 Microscopic model
Whenever high detailed data is available, microscopic models should be used to
produce results with high quality, especially for timetable planning with an exact
running time calculation.
In railway business, microscopic models are used for the exact reproduction
of the infrastructure network and train operation. A microscopic infrastructure
model consists of a node-link system with an accuracy of, for example one
meter. It contains all necessary characteristics and parameters of the real
infrastructure. The links represent the tracks and cover information about the
length, gradient and maximum speed of a track section. The nodes represent the
railway equipment and contain information about signalling systems,
accessibility within block sections and can carry the function of a signal, switch,
speed indicator or a release contact for instance. Whenever one parameter of two
links is different, a node has to be set too. Microscopic models are indispensable
for running time calculation, timetable calculation and simulation of railway
operation processes because of the high level of itemisation that is necessary for
these tasks (Figure 1).

Figure 1: Microscopic model of railway infrastructure [2].
1.2 Mesoscopic model
The mesoscopic model is an intermediate stage between the micro- and
macroscopic model. It reduces the data complexity and storage capacity
compared to a microscopic model. Mesoscopic models are used when
microscopic data is not available. If detailed results are required, but only
macroscopic data is available, it is necessary to transform the approximate
information into data with a higher level of accuracy. An established knowledge
of the rationalities and habits in railway construction and operation is the
precondition for putting these processes into computer algorithms to generate the
required data automatically. The differences and the advantages to the
macroscopic simple node link model include obtaining more detailed
information for the station characteristics like accessibility and exclusion routes.
This information is a basic requirement for an estimate railway capacity analysis
(Figure 2).

Figure 2: Mesoscopic model of railway infrastructure [2].
1.3 Macroscopic model
Within a macroscopic model each link only contains information about the
number of tracks, the average speed, the average block length and the length of
the track sections on the whole. Each node only represents, for example, the
location of a station or the location of a branch. For some purposes like vehicle
circulation planning, long term traffic planning and strategic infrastructure
planning it is adequate to use macroscopic models or if necessary to transform
microscopic data into macroscopic models. For purposes such as these, high
accuracy data is not required.

Figure 3: Macroscopic model of railway infrastructure [2].
Timetabling 75
2 Limits of adopting macroscopic infrastructure models
In most cases macroscopic models are used for long-term traffic planning or
calculating average values for train running times. An exact modelling of train
runs for running time calculation or the determination of line or station capacities
is only possible through working with a detailed microscopic database including
the exact positions of infrastructure elements and line parameters. Especially the
gradient, which has a wide influence on the train running times. Using a
macroscopic model only average gradient values can be applied. To detect every
single gradient change a detailed microscopic model is necessary. The
determination of running times using macroscopic infrastructure models does not
fulfil the requirements of an accurate running time calculation and can be
declared as a running time approximation.
Particularly in station areas, the imperfection of macroscopic models is a
problem. The internal dependencies of a station require an accurate model. In
addition, it is not possible to consider train route exclusions, accessibilities,
connections or the consequences of the release contacts, speed boards or
stopping boards position for the headway in an adequate way. In some cases the
stopping board might be positioned in the influence area of the signalling system,
so that a train can only travel with reduced velocity after stopping at this position
until it reaches the next block section. Due to this the running time of a train can
lengthen significantly. Hence microscopic or mesoscopic models must be used
for more detailed planning.
The following example should clarify the exigency of detailed infrastructure
modelling.
2.1 Example (route exclusion)
In this example two trains coming from the same direction, but from different
tracks arrive in a station. In real train operation no simultaneous route setting
would be possible because of a route exclusion for train 1 and train 2 through
this arrangement. Such a dependency cannot be considered in a sufficient way
using a macroscopic model (Figure 4).

Figure 4: Necessity of detailed infrastructure modelling.
3 Transformation of different infrastructure models
With the information provided through a considered model, the Multiscaling
Analysis is able to generate the missing information for either a higher detail
level or a lower detail level. For example when only rough results are required,
but microscopic data is existing, the data can be transformed into a macroscopic
model. Therefore average values are calculated for the track sections and no
relevant nodes are neglected (Figure 5).
When detailed results are required, but only macroscopic data is existing, it is
necessary to generate data with high-level accuracy out of low-level accuracy
infrastructure information. The requirement to transform data in this direction is
an established knowledge of the rationalities and habits in railway construction
and operation. With this knowledge, logical connections can be put into the
algorithms of computer models using the Multiscaling Analysis to generate the
required data automatically.

Figure 5: Transforming detail level of railway infrastructure models [3].
For purposes where mesoscopic modelling is sufficient to gather adequate
results or no microscopic infrastructure data is available the macroscopic
infrastructure manager of the program RailSys
[8] can be used to generate a

mesoscopic infrastructure from a macroscopic infrastructure. The following
chapter deals with an explanation of the main components of the macroscopic
infrastructure manager of RailSys
.
3.1 Construction of a mesoscopic network
The first step for constructing mesoscopic from macroscopic networks is to edit
nodes and links to model the railway infrastructure. The nodes represent the
stations or branches (operating points) of the railway network as usual in
macroscopic models (Figure 3).
Timetabling 77
The macroscopic model becomes a mesoscopic model through conducting the
following steps:
1) Approaches
To model the different train routes in a station, approaches from station
to the free track (or the reverse) need to be in place. This means the
infrastructure must carry the information as to which platforms can be
reached from which track. Through this the switch areas are mapped.
(Figure 6)
2) Route exclusions
To complete the modelling, route exclusions have to be defined to make
sure that no train runs can take place simultaneously on the same switch
or track.

Figure 6: Accessibilities in a mesoscopic network [2].
Now the program is able to generate the missing information for timetabling
and feasibility confirmations automatically, and produce an artificial microscopic
railway infrastructure model through setting entry and exit signals, timing points,
release contacts, speed boards and block sections for station and line areas.
4 Timetable feasibility confirmation and capacity analysis
The Multiscaling Analysis has already been applied in the project Railway Slot
Allocation [4]. In this project a macroscopic infrastructure is used for
calculating an optimised timetable referring to running time approximations. To
prove if the approximated running times can be confirmed, and the train paths
are feasible without conflicts, the macroscopic timetable must be mapped onto a
high accuracy infrastructure model. In this case a mesoscopic infrastructure
model with detailed station areas was built from the macroscopic model because
no microscopic data was available. Before the feasibility confirmation of the
macroscopic timetable, it must be mapped onto the mesoscopic infrastructure.
Therefore the macroscopic timetable must be converted into an accurate
timetable format. This can be arranged with the program Slot Allocation-
Converter of RailSys
(Figure 7).
The feasibility of the originally macroscopic timetable can be certified under
consideration of buffer times, or minimum headways, within the mesoscopic
model. As an example, when conflicts from super-imposed block occupation
times of two trains are remaining, a conflict protocol is produced from the Slot
Allocation-Converter. Thus the macroscopic model can be adjusted, for example,
through changing the allowed headway times.

Figure 7: Timetable file conversion using the Slot Allocation-Converter
[4].
4.1 NEMO-RailSys

- Data exchange between macroscopic and microscopic
railway infrastructure models
Another approach is the transformation from microscopic to macroscopic
infrastructure without using the mesoscopic level of itemisation. This approach is
initiated for long term traffic and capacity planning purposes with the program
NEMO [7] in association with RailSys
. NEMO is a strategic planning tool for

the evaluating infrastructure and train operation in guided transport systems. It
can disclose saving possibilities and capacitive and operational bottlenecks.
Because complex microscopic infrastructure data is existing no mesoscopic
model is required. The possibility for adopting a mesoscopic infrastructure
model within NEMO-RailSys
is not yet verified but possible [9].

Figure 8 shows the interaction between NEMO

and RailSys
. For identifying
bottlenecks and evaluating transport supply and demand NEMO uses a
macroscopic network database. This macroscopic database is generated from a
microscopic network in RailSys
. Also running times and minimum headways

are calculated on the microscopic infrastructure before adopting the macroscopic
NEMO evaluation. After scenario selection and determination of the required
train paths to fulfil the demand is done with NEMO the remaining line capacity
can be calculated on the microscopic RailSys
network. The capacity

determination in RailSys
is made by means of UIC data sheet 406 (Capacity)

[10].

Timetabling 79

Figure 8: Workflow NEMO - RailSys
[7].
5 Results, impact on railway business and conclusions
Due to working with the Multiscaling Analysis, railway engineers are able to
generate missing information with a higher detail level from a lower level source
on the one hand, and reduce the data complexity from a microscopic to a
macroscopic level on the other hand. For many tasks in railway business
including vehicle scheduling, traffic generation and assignment and long term
capacity planning, no high level data is required. It is possible to work with
macroscopic computer models with a low detail level. For tasks such as running
time calculation, simulation of train operation and short-term capacity planning
of infrastructure projects microscopic or at least mesoscopic models are required.
It is inherent that the more detail with which the data is mapped, the more and
better results are possible (Figure 9). But, with a higher accuracy, the data
complexity rises and it gets more difficult to obtain the data. For example, in
many cases detailed track information cannot be obtained from a countries
railway infrastructure operating company easily due to formal or legal reasons
and must be gathered in another way.
The Multiscaling Analysis can already work with requests concerning train
operation feasibilities. For instance, it can be used to verify if macroscopic
planned train paths can indeed be arranged within the structure of current train
paths. Therefore the trains timetable can be mapped onto a mesoscopic
infrastructure when no high detailed microscopic data is available. With the
mesoscopic or high detailed microscopic infrastructure model running time and
block occupancy time calculations can be done. Through this conflicts between


Figure 9: Opportunities for using Multiscaling Analysis [3].
train paths can be found or train paths can be seen as realisable. The Multiscaling
Analysis is a useful method to transform data between micros-, mesos- and
macroscopic level, considering the dependencies in railway traffic.
References
[1] Hansen, I., Pachl, J., Radtke, A.: Railway Timetable & Traffic Analysis,
Modelling, Simulation (Chapter 3: Infrastructure Modelling). Publisher:
Eurail press Hamburg, Germany (2008)
[2] Graphic export from RailSys

(version 6) http://www.rmcon.de/englisch/
uber_railsys.html
[3] Radtke, A.: Software tools to model the railway operation, Habilitation at
the Institute of Transport, Railway Construction and Operation (No. 64),
Leibniz Universitt Hannover (2005)
[4] Siefer, Th., Gille, A.: Development of a Slot Management Computer
System. Research project for Germanys Federal Ministry of Economics
and Technology, Leibniz Universitt Hannover (2007)
[5] Klemenz, M., Schultz, S.: Modelling Aspects of a Railway Slot Allocation.
Paper at the IAROR-Congress RailHannover 2007, 2nd International
Seminar on Railway Operations Modelling and Analysis, 28.03.-
30.03.2007, Hannover
[6] Dynamis, computer program http://www.ivembh.de/dynamis/index.en.htm
[7] NEMO, computer program http://www.ivembh.de/nemo/index.en.htm
[8] RailSys, computer program http://www.rmcon.de/englisch
/uber_railsys.html
[9] Sewcyk, B., Radtke, A., Wilfinger, G.: Computing Microscopic and
Macroscopic Infrastructure Planning Models. Paper at the IAROR-
Timetabling 81
Congress RailHannover 2007, 2nd International Seminar on Railway
Operations Modelling and Analysis, 28.03.-30.03.2007, Hannover
[10] UIC UNION INTERNATIONALE DES CHEMINS DE FER: UIC
CODE 406 Capacity, Paris (06/2004)
Part B
Operations Analysis
Simulation of disturbances and modelling of
expected train passenger delays
A. Landex & O. A. Nielsen
Centre for Traffic and Transport,
Technical University of Denmark, Denmark
Abstract
Forecasts of regularity for railway systems have traditionally if at all been
computed for trains, not for passengers. It has only relatively recently become
possible to model and evaluate the actual passenger delays. This paper describes
how it is possible to use a passenger regularity model to estimate the actual
passenger delays. The combination of the passenger regularity model with
railway simulation software is described, demonstrating the possibility of
predicting future passenger delays. The described passenger regularity model is
run daily to calculate the passenger delays of the Copenhagen suburban rail
network the previous day. The results obtained with the passenger regularity
model used together with the simulation software are very similar to the daily
calculated passenger regularity of the Copenhagen suburban network. As the
combined method includes simulation software and reflects the actual passenger
regularity, it is possible to use a combination of a passenger regularity model and
simulation software to evaluate and compare future scenarios.
Keywords: railway planning, timetable, regularity, simulation, passenger delay.
1 Introduction
Relatively recently has it become possible to model and evaluate the actual
passenger delay on large scale railway networks. The method used to model and
evaluate actual passenger delays was presented in 2004 by Nielsen [2] and has
since been optimised and evaluated [3, 4]. In the planning process, the passenger
delays are often calculated by assuming that no passengers transfer to other
trains or update/change their route choice when delay or cancellations occur.
This assumption does not reflect the passengers travel behaviour.
Operations Analysis 85
The first part of the paper briefly describes how to model passenger delays
based on a comparison of realised timetables to planned timetables. A passenger
strategy is presented, in which passengers plan their route according to the
planned (announced) timetable, but start reconsidering their route within a
certain threshold after a delay or cancellation of a train [4]. The route choice
model, obtained from the passenger strategy, is run each night to evaluate
passenger delays in the Copenhagen suburban rail network the previous day [5]
and evaluates the impact of train delays on passengers. The model has shown
that, due to delays caused by e.g. passenger/door interactions when timetables
are stressed and when trains carries more passengers in the rush hours, passenger
delays are greater than train delays [4].
Although the model presented in the first part of the paper is used to evaluate
the already run timetable, the model can also be used for planning purposes. The
second part of the paper describes how the model can be combined with railway
simulation software such as RailSys, making it possible to predict the expected
passenger delays for different timetable alternatives. The simulated timetables
are exported to the passenger delay model for comparison with the planned
timetable.
The last part of the paper demonstrates that a detailed timetable based
passenger delay model together with railway simulation software can be used to
evaluate different timetables in the planning process. The evaluation can estimate
the expected train delays as well as the daily passenger delays. Furthermore, the
model can be used to evaluate in which part of the network passenger delays
pose problems.
2 Calculating passenger delays
The core idea of the model is modelling passenger delays by assigning a
time-space trip matrix on the realised timetable. This is compared to a
calculation where passengers were assigned on the planned timetable (the
announced official timetable).
It is assumed that passengers plan their optimal desired route according to the
planned timetable. If delays occur, exceeding a certain threshold, passengers are
assumed to reconsider the route at that point in time and space along the route. If
a train is completely cancelled, passengers reconsider their choice without a
threshold.
As a benchmark (minimal passenger impact due to the delays), an optimal
all-or-nothing route choice model can also be used on the realised timetable. This
model assumes passengers to have full knowledge of future delays at the
beginning of their trip and to choose optimally in accordance to this knowledge.
The difference between the solutions obtained with the two methods (the
optimistic and pessimistic) is a measurement of the additional loss of missing
passenger information, combined with slow passenger responses to changes in
the schedule.
3 Calculating passenger delays by simulation
Calculating passenger delays of the actual performed operation is of interest to
evaluate the train company and to identify aspects or routines that could be
improved. If it is possible to predict or estimate the future passenger delays, it is
possible to evaluate changes in the infrastructure and/or the timetables already
when deciding new infrastructure and/or timetables. To evaluate infrastructure
changes and timetables it is common to evaluate train delays by simulation. It
would thus be obvious and interesting to calculate passenger delays in the same
procedure.
To calculate the passenger delays by ordinary railway simulation software
such as RailSys, it is necessary to build up the infrastructure and the timetables
to be simulated. The rules of operation are then set up together with a set of
delay distributions to simulate disturbances in the operation. It is now possible to
run a simulation of the train operation with the chosen delay distributions. After
running the simulation, it is possible to evaluate the infrastructure and the
timetable whereupon improvements can be considered. The work process of the
simulations can be seen in figure 1; the arrow describes the workflow.

Figure 1: Principles of workflow in rail simulation projects.
Calculation of the passenger delays requires result data from the simulation to
contain information of both the planned and all the realized/simulated timetables
for all arrivals and departures. The RailSys output file Fahre++.pro contains this
information. These results must be transferred from the railway simulation
software to the passenger delay model by a simple import-export tool developed
in VB.Net.
Calculation of passenger regularity is initiated by coding the infrastructure
and creating the timetable. The rules of operation and the set of delay
distributions are then defined. To ensure that the model reflect the real life
operation, simulations are run and changes made in the rules of operations and
the setup of delay distributions. When the model has been calibrated, the
simulation is run. It is now possible to evaluate the train delays. However, to
evaluate the passenger delays it is necessary to export the simulation data (the
Fahre++.pro file in RailSys) to the passenger delay model before running the
model. The workflow of calculating the passenger delays can be seen in figure 2.
The simulation of operation, export to passenger delay model and calculation of
passenger delays simulates the impacts of one simulated day of operation. To
calibrate the model and to obtain a delay distribution, it is therefore necessary to
repeat the third step a number of times before the evaluation.

Figure 2: Workflow of simulating disturbances and modelling expected train
passenger delays.
4 Simulating disturbances on a large scale network
The entire Copenhagen suburban rail network, including 85 passenger stations,
was used for the simulations. The route network contains of 4 lines (A, B, C and
E) running in 10 minutes service during the day (between 05:30 and 19:00 hours)
and 20 minutes service during the rest of the day. 2 other lines (G and H) run in
20 minutes service, and 1 line (F) run in 5 minutes service in the daytime and 10
minutes service the rest of the day. Some of the departures on line C are
shortened. The route network is seen in figure 3.


Figure 3:
5 Results of simulating disturbances on large a scale network
The RailSys model was run with 110 simulations, of which 2 contained
deadlocks where trains blocked the way for each other. The remaining
108 simulations were used for further calculations and evaluations.
The Copenhagen suburban network, fall 2007.
The results show that the regularity of the trains is higher than the regularity
of the passengers, cf. figure 4. The traditional way of calculating passenger
regularity (multiplying the delay of the train and the expected getting off the
train) is demonstrated to result in higher passenger regularity than when
calculated by the passenger regularity model. The differences between the
regularity between trains and passengers are due to different numbers of
passengers in the trains through the day. Furthermore, some passengers have to
change from one train to another under the risk of missing the other train.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
E
a
r
l
i
e
r

t
h
a
n

p
l
a
n
n
e
d
A
t

t
i
m
e
3
0
s

d
e
l
a
y
e
d
6
0
s

d
e
l
a
y
e
d
9
0
s

d
e
l
a
y
e
d
1
2
0
s

d
e
l
a
y
e
d
1
5
0
s

d
e
l
a
y
e
d
1
8
0
s

d
e
l
a
y
e
d
2
1
0
s

d
e
l
a
y
e
d
2
4
0
s

d
e
l
a
y
e
d
2
7
0
s

d
e
l
a
y
e
d
3
0
0
s

d
e
l
a
y
e
d
3
3
0
s

d
e
l
a
y
e
d
3
6
0
s

d
e
l
a
y
e
d
3
9
0
s

d
e
l
a
y
e
d
4
2
0
s

d
e
l
a
y
e
d
4
5
0
s

d
e
l
a
y
e
d
4
8
0
s

d
e
l
a
y
e
d
5
1
0
s

d
e
l
a
y
e
d
5
4
0
s

d
e
l
a
y
e
d
5
7
0
s

d
e
l
a
y
e
d
6
0
0
s

d
e
l
a
y
e
d
1
5
0
0
s

d
e
l
a
y
e
d
3
0
0
0
s

d
e
l
a
y
e
d
Regularity of trains * passengers
Regularity of trains
Optimistic regularity of passengers
Pessimistic regularity of passengers

Figure 4:
Train delays do not necessarily cause passenger delays. Some passengers may
even benefit from train delays. If a passenger arrives late to the station, a train
delay may allow the passenger to catch an earlier train than expected. If the train
catches up the delay, the passengers in the train may arrive on time. A similar
situation may occur when a passenger changes from one line to another. If the
train on the other line is delayed, it is possible to catch an earlier train than
planned, thereby reducing the total travel time. In fact many passengers arrive
earlier than planned (20 to 25 %), cf. figure 4 and figure 5.
From figure 4 it is seen that the optimistic regularity of passengers in general
is higher than the pessimistic regularity of passengers. The difference can be
explained by the passengers knowledge of the delays. In the optimistic
calculations, full knowledge of the delays in the entire rail network is assumed
to the extent that passengers have the information before the actual occurrence of
the delays. In the pessimistic calculations passengers are assumed to follow a
desired optimal route according to the timetable and only reconsider their route
after a certain delay. Both principles of calculations have a certain error since
passengers do not have full knowledge and passengers for some journeys choose
the first train in their direction without waiting before reconsidering their route.
Regularity of trains and passengers at all stations.
Thus, the true regularity of passengers is between the optimistic and the
pessimistic values.
The distribution of arrivals at stations according to the planned journey (cf.
figure 5 (a)) once again shows that some passengers arrive before scheduled
(negative delays). However, it is difficult to see a difference between the result
of the optimistic and pessimistic calculation of the passenger delays. This
difference is seen in figure 5 b, illustrating a lesser tendency to delay and more
passengers to arrive ahead of schedule when evaluated by the optimistic method
rather than by the pessimistic method.

0,0%
5,0%
10,0%
15,0%
20,0%
25,0%
30,0%
35,0%
40,0%
45,0%
-20 -15 -10 -5 0 5 10 15 20
Optimistic evaluation
Pessimistic evaluation
-0,5%
-0,4%
-0,3%
-0,2%
-0,1%
0,0%
0,1%
0,2%
0,3%
0,4%
-20 -15 -10 -5 0 5 10 15 20
a b
0,0%
5,0%
10,0%
15,0%
20,0%
25,0%
30,0%
35,0%
40,0%
45,0%
-20 -15 -10 -5 0 5 10 15 20
Optimistic evaluation
Pessimistic evaluation
-0,5%
-0,4%
-0,3%
-0,2%
-0,1%
0,0%
0,1%
0,2%
0,3%
0,4%
-20 -15 -10 -5 0 5 10 15 20
a b

Figure 5: Distribution of arrivals according to the planned journey at all
stations (a) and difference between optimistic and pessimistic
evaluation of passenger regularity (b).
6 Discussion
Today, the passenger regularity model is run each night to evaluate passenger
delays in the Copenhagen suburban network during the previous day [5]. The
model has shown that passenger delays are larger than train delays [4], in
accordance with the results presented in this paper. Other results (not published)
show great similarity between the daily evaluation of delays and the simulated
passenger delays.
Even though the RailSys model reproduces the results in Copenhagen quite
well, the results can be improved. To do this and to improve reproducibility of
the results, the RailSys model must be further calibrated to make the resulting
delay at all stations similar to the daily operation. The RailSys model used in this
paper has only been calibrated on an overall level so that the average delay for
all stations is equal to the daily operation. It is very time-consuming,
approaching the impossible, to gain exactly the same delay distribution as for the
daily operation and the calibration should thus only be at the same level as
(and not exact) the regularity of the daily operation [1].
When the RailSys model is calibrated, it is possible to evaluate the regularity
of both trains and passengers at isolated stations as shown in figure 6. Beyond
that, the passenger regularity model can be used for evaluating (and ranking)
infrastructure improvements. The benefits for the passengers in terms of travel
time and delays can be estimated and compared with the construction costs in,
e.g., a cost-benefit analysis. Furthermore, different candidate timetables can be
evaluated and compared in the process of developing the best possible timetable
for the passengers.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
E
a
r
l
i
e
r

t
h
a
n

p
l
a
n
n
e
d
A
t

t
i
m
e
3
0
s

d
e
l
a
y
e
d
6
0
s

d
e
l
a
y
e
d
9
0
s

d
e
l
a
y
e
d
1
2
0
s

d
e
l
a
y
e
d
1
5
0
s

d
e
l
a
y
e
d
1
8
0
s

d
e
l
a
y
e
d
2
1
0
s

d
e
l
a
y
e
d
2
4
0
s

d
e
l
a
y
e
d
2
7
0
s

d
e
l
a
y
e
d
3
0
0
s

d
e
l
a
y
e
d
3
3
0
s

d
e
l
a
y
e
d
3
6
0
s

d
e
l
a
y
e
d
3
9
0
s

d
e
l
a
y
e
d
4
2
0
s

d
e
l
a
y
e
d
4
5
0
s

d
e
l
a
y
e
d
4
8
0
s

d
e
l
a
y
e
d
5
1
0
s

d
e
l
a
y
e
d
5
4
0
s

d
e
l
a
y
e
d
5
7
0
s

d
e
l
a
y
e
d
6
0
0
s

d
e
l
a
y
e
d
1
5
0
0
s

d
e
l
a
y
e
d
3
0
0
0
s

d
e
l
a
y
e
d
Regularity of trains * passengers
Regularity of trains
Optimistic regularity of passengers
Pessimistic regularity of passengers

Figure 6: Regularity of trains and passengers at Copenhagen central station
(Kbenhavn H).
Apart from the RailSys model, the passenger regularity model itself can be
improved. According to the passenger regularity model, passengers will not
change their route of travelling until a certain threshold of delay has been
reached. However, on some stations or OD-relations, passengers will just take
the first train in their direction. This phenomenon is characteristic for short
journeys with high train frequency and is observed in the central Copenhagen
between sterport and Vesterport (cf. figure 3) with a train frequency of 2
minutes in each direction. The phenomenon might, however, also be observed at
OD-relations with a lower frequency i.e. Lyngby-Nrreport (cf. figure 3).
Further work is necessary to estimate the correct threshold of delay to make
passengers reconsider their route.
7 Conclusions
We have shown that it is possible to calculate the expected passenger delays by
simulation of large scale networks and that there is a significant difference
between train regularity and passenger delays.
The difference between the train regularity and passenger delays is due to the
different number of passengers in the trains during the day and the fact that the
passengers (to some extent) will change routes due to delays. Furthermore, there
is a higher risk of delays in the rush hours due to more passengers and more
trains.
The evaluation of passenger obtained with a simulation software, RailSys,
and the passenger regularity model is comparable to the daily operation of the
Copenhagen suburban network. Using a well calibrated RailSys model it will be
possible to compare travel times and delays for different future scenarios for
changes in infrastructure as well as in timetables. In this way it will be possible
to choose the best possible scenario.
Even though the results in this paper are very similar to what has been
observed on the Copenhagen suburban rail network, the results can be improved
both by better calibration of the RailSys model and estimation of the correct
threshold of delay before reconsidering the route.
Acknowledgements
Rapidis Aps is thanked for the programming the passenger delay model. Rail Net
Denmark (Banedanmark) is thanked for providing the infrastructure data for the
Copenhagen urban rail network and discussions on the RailSys model. DSB S-
tog (the train company of the Copenhagen suburban rail network) is thanked for
providing the future timetables and OD-matrices for the travel patterns. Stephen
Hansen and Kenneth Christensen, Centre for Traffic and Transport at the
Technical University of Denmark, is thanked for developing the import-export
tool from RailSys to the passenger delay model and the evaluation tool used.
References
[1] Kaas, A. H., Punctuality model for railways. Proc. of the 7
th
International
Conference on Computers in Railways, eds. J. Allan, R. J. Hill, C. A.
Brebbia, G. Sciutto & S. Sone, pp. 853-860, 2000
[2] Nielsen, O. A., A large scale stochastic multi-class schedule-based transit
model with random coefficients. Schedule-Based Dynamic Transit
Modelling Theory and Applications. In Schedule-Based Dynamic Transit
Modelling: theory and applications, eds. Wilson, N. and Nuzzolo, A. Kluwer
Academic. pp. 51-77, 2004
[3] Nielsen, O. A. & Frederiksen, R. D., Optimisation of timetable-based,
stochastic transit assignment models based on MSA. Paper accepted for
Annals of Operations Research special issue on Optimisation in
Transportation. Forthcoming, Elsevier, 2006
[4] Nielsen, O. A. & Frederiksen, R. D., Modelling train passenger delays.
Symposium on The Reliability of Travelling and the Robustness of Transport
Systems, eds. van Zuylen, H.J., pp. 137-156, 2005
[5] Seest, E., Nielsen, O. A. & Frederiksen, R. D., Calculating passenger
regularity in the Copenhagen suburban network. Proc. of Trafficdays, 2005
(in Danish).
Evaluating stochastic train process time
distribution models on the basis of empirical
detection data
J. Yuan, R. M. P. Goverde & I. A. Hansen
Faculty of Civil Engineering and Geosciences,
Delft University of Technology, The Netherlands
Abstract
This paper evaluates several commonly applied probability distribution models
for stochastic train process times based on empirical data recorded in a Dutch
railway station, The Hague Holland Spoor. An initial guess of model parameters
is obtained by the Maximum Likelihood Estimator (MLE). An iterative
procedure is then followed, in which large delays are omitted one by one and the
distribution parameters are estimated correspondingly using the MLE method.
The parameter estimation is improved by minimizing the Kolmogorov-Smirnov
(K-S) statistic where of course the empirical distribution is still based on the
complete data set. A local search is finally performed in the neighbourhood of
the improved model parameters to further optimize the estimation. To evaluate
the distribution models, we compare the K-S statistic among the fitted
distributions with optimized parameters using the one-sample K-S goodness-of-
fit test at a commonly adopted significance level of = 0.05. 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 it is always larger than 1.0 in the
last case. These distribution evaluation results for train process times can be used
for accurately predicting the propagation of train delays and supporting timetable
design and rescheduling particularly in case of lack of empirical data.
Keywords: train delays, running and dwell times, track occupancy times,
statistical distribution, the K-S test.
1 Introduction
Modelling the distribution of train process times is an important research topic.
Arrival and departure delay distributions reflect the punctuality level of trains at
stations. Based on the distribution of input delays of trains at the boundary of a
railway network and the distribution of primary delays within this network, the
distribution of knock-on delays and that of the resulting exit delays can be
estimated, which supports timetable design and operations management [10].
Train process time distributions are often assumed based on experiences from
real operations and limited literature [2], [3], [6], [8], [9] exists with respect to
statistical inference of the distributions using empirical data observations. Track
occupation and release records show the total delays of trains and may include
knock-on delays. Therefore, data filtering is necessary to fit the distribution of
primary delays on the basis of train detection data [9]. To the best of our
knowledge, there is no publication that evaluates the conditional train running
and dwell and track occupancy time distributions in the case of different aspects
of relevant block signals, which can be used for estimating knock-on delays
more accurately [10].
This paper evaluates several commonly applied distribution models for
stochastic train process times on the basis of empirical traffic data recorded in a
Dutch railway station The Hague Holland Spoor (The Hague HS). The
evaluation of distribution models is performed not only for the arrival times
(delays), non-negative arrival delays and departure delays of trains at the station,
but also for the arrival times of trains at the boundary of the local railway
network and the train running, dwell and track junction occupancy times within
the local network. This paper is structured as follows. Section 2 outlines the
distribution models to be evaluated and the evaluation method. The results of the
distribution evaluation for the process times of trains are then discussed in
Section 3. Finally, the main conclusions are drawn in Section 4.
2 Distribution models and the evaluation method
A variety of theoretical probability distributions, including the normal, uniform,
exponential, gamma, beta, Weibull, and log-normal distributions [5], have been
adopted in the literature to model the stochasticity of train process times. Given a
continuous distribution model, the parameters are estimated on the basis of
empirical data using e.g. the maximum likelihood method. The resulting fit can
be tested using the Kolmogorov-Smirnov (K-S) goodness-of-fit test. This test is
based on the K-S statistic, defined as the maximum absolute difference between
the empirical and fitted cumulative distribution function [5]. However, the
estimated parameters are generally sensitive to outliers in the data set. We
therefore used an iterative parameter estimation method. An initial guess of the
model parameters is obtained using the Maximum Likelihood Estimator (MLE)
of the complete data set. Next, the large delays in the original data set are
omitted iteratively one by one estimating the distribution parameters
correspondingly using the MLE method. In each iteration, we compute the K-S
statistic where of course the empirical distribution is still based on the complete
data set. The iterative procedure terminates if the K-S statistic cannot be
decreased any more. After the iterative procedure, we apply a local search in the
neighbourhood of the parameter estimate to further optimize the parameter
estimation by minimizing the K-S statistic. It should be mentioned that the
location parameter of each distribution model except for the normal distribution
was taken as the minimum value of the empirical data observations.
To evaluate the candidate distributions, we compare the K-S statistic among
the fitted distributions with optimized parameters using the one-sample K-S test
[5] at a commonly adopted significance level = 0.05. To visualize the quality
of distribution fitting for the process times of trains, we compare the fitted
distribution density curve with the kernel estimate and empirical histogram [7]
and apply the distribution differences plot [1] for the fitted distribution and the
empirical one.
3 Evaluation results
The distribution of train process times may depend on the types and routes of
trains. We hence evaluate the distribution models for the process times of trains
per train series in both the southbound and northbound directions at The Hague
HS railway station.
3.1 Arrival times
The modelling of train arrival time distribution is a prerequisite for predicting the
propagation of train delays at stations. To incorporate the impact of the knock-on
delays caused by route conflicts in a delay propagation model, we need to
distinguish the arrival times of trains at the station platform from that at the
approach signal of the station. Early arriving trains are often considered as
punctual trains in some delay propagation models [4], where the distribution of
non-negative arrival delays is of the main concern.
It has been found that the location-shifted log-normal distribution is the best
approximate model among the candidate distributions in 9 and 11 of the 14
considered cases for both the arrival times of trains at the approach signal of the
station and at the platform track, respectively. This distribution model has not
been rejected by the K-S test in 9 and 10 of the 14 cases for both the arrival
times. The optimized parameters and the K-S test results for the log-normal
distribution are given in Table 1, where and represent the mean and standard
deviation of the underlying normal distribution and p denotes the p-value [5] of
the K-S test.
Figure 1: shows the optimized log-normal distribution density curve, kernel
estimate and empirical histogram for the arrival times of the northbound intercity
train series IC2100N at the approach signal of the station. The corresponding
distribution differences plot is shown in Figure 2:, where the two dotted
horizontal lines represent the critical error bounds for the K-S test. In both
figures, the reference time is defined at the scheduled arrival time of the studied
train series at the station. The optimized log-normal fit matches well the
empirical data. In this case, the distribution differences plot does not cross the
error bounds, therefore the location-shifted log-normal distribution has not been
rejected by the K-S test.
Table 1: Optimized parameters and the K-S test results of the log-normal fit
for the arrival times of trains in The Hague HS.
Train At the approach signal At the platform track
Series Best p Best p
IR2200S 4.6 0.6 0.03 4.8 0.6

0.16
IC2100S 4.3 0.7

0.61 4.5 0.7

0.38
IC2400S 4.2 0.8

0.25 4.4 0.9

0.42
INT600S 4.9 0.7 0.18 5.0 0.5

0.20
HST9300S 4.8 0.9 0.01 4.8 0.9 0.00
AR5000N 4.7 0.4

0.00 4.7 0.5

0.00
AR5100N 4.5 0.5

0.00 4.6 0.5

0.00
IR2200N 4.6 0.4 0.00 4.5 0.5 0.00
IC1900N 4.9 0.6 0.15 5.1 0.5 0.16
IC2100N 5.0 0.7

0.55 5.0 0.7

0.14
IC2400N 4.8 0.6

0.31 4.9 0.6

0.79
IC2500N 4.8 0.6

0.13 4.9 0.5

0.15
INT600N 4.8 0.7

0.26 4.9 0.6

0.22
HST9300N 4.6 0.7

0.38 4.6 0.8

0.30

Figure 1: Log-normal fit, kernel
estimate and histogram for
the arrival times of IC2100N
at the station approach signal.

Figure 2: Distribution differences plot
for the log-normal fit and the
arrival times of IC2100N at
the station approach signal.
We have also evaluated the candidate distributions for non-negative arrival
delays of trains at the platform track. The Weibull distribution is the best fit
among the candidate distributions in 7 of the total 18 studied cases. This
distribution model has not been rejected by the K-S test in 17 of the 18 cases.
Since the exponential distribution has been widely used to model the
stochasticity of non-negative arrival delays [2], [6], [9], we visualize the
goodness-of-fit of both the Weibull and exponential distributions in Figure 3:
and Figure 4: for the northbound intercity train series IC2100N. The non-
negative arrival delays fit to the Weibull distribution with a shape parameter of
0.8 overall better than the exponential distribution especially at the range of
larger delays. Both the distributions have not been rejected by the K-S test in this
case.

Figure 3: Fitted density curves and
histogram of non-negative
arrival delays of IC2100N.

Figure 4: Distribution differences plots
for non-negative arrival
delays of IC2100N.
In conclusion, the log-normal distribution can be generally considered as the
best 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
matches well non-negative arrival delays. For simplicity, we may use the
exponential distribution, which is a special type of the Weibull distribution, to be
as an approximate distribution model for non-negative arrival delays if the
density is decreasing.
3.2 Departure delays
Departure delays are non-negative since trains are not allowed to depart from the
station earlier than the scheduled departure time. The distribution of departure
delays can be used to predict the distribution of outbound track release times and
the distribution of train arrival times at the following stations.
It has been found that the Weibull distribution is the best approximate model
among the candidate distributions for the departure delays of trains in 11 of the
total 18 studied cases. The exponential distribution is the best approximate
model in 2 of the 18 cases. In addition, both the distributions have not been
rejected by the K-S test in 10 of the total 18 cases. Figure 5: and Figure 6:
visualize the goodness-of-fit of both the Weibull and exponential distributions
for the departure delays of the southbound intercity train series IC2400S. Early
arriving trains usually do not depart very late and some trains may arrive at and
depart from the station very late, which results in a very steep histogram of the
departure delays. The Weibull fit with a shape parameter of 0.8 matches the
delays overall better than the exponential fit. In this case, the former distribution
has not been rejected while the latter distribution has been rejected by the K-S
test. Thus, we can generally consider the Weibull distribution to be as the best
approximate model among the candidate distributions for departure delays. Just
like for non-negative arrival delays, the exponential distribution can be
considered as an approximate distribution model for departure delays if the

Figure 5: Fitted density curves and
histogram of departure
delays of IC2400S.

Figure 6: Distribution differences plots
for departure delays of
IC2400S.
3.3 Dwell times
The dwell times of trains are the difference between the arrival and departure
times. Early arriving trains generally have much longer dwell times and they are
not of our main concern. To estimate the knock-on delays and departure delays
of trains at stations, it is critical to obtain the distribution of the free dwell times
for late arriving trains [10]. The free dwell time of a train is defined as the
necessary dwell time for passenger alighting and boarding in the absence of
hindrance from other trains.
We fit the free dwell time distribution for late arriving trains per train series in
one direction using the dwell time observations of the trains that satisfy

and 30
i i i i
A a C A > +

where, A
i
and a
i
denote the actual and scheduled arrival time of train i at the
platform track and C
i
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
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
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 k-
means 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
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
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
running times of hindered
INT600S that do not stop
before the home signal.

Figure 12: Normal fit, kernel estimate
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
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] Averill, M.L. & Kelton, W.D., Simulation Modeling and Analysis,
McGraw-Hill, 2000.
[2] Goverde, R.M.P., Hooghiemstra, G. & Lopuha, H.P., Statistical Analysis
of Train Traffic: The Eindhoven Case, DUP Science, Delft, 2001.
[3] Hermann, U., Untersuchung zur Versptungsentwicklung von
Fernreisezgen auf der Datengrundlage der Rechneruntersttzten
Zugberwachung Frankfurt am Main, PhD thesis, Technische Hochschule
Darmstadt, 1996.
[4] 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. 615-
625, WIT Press, Southampton, 2004.
[5] Ross, S. M., Introduction to Probability and Statistics for Engineers and
Scientists, Elsevier, 2004.
[6] Schwanhusser, W., Die Bemessung der Pufferzeiten im Fahrplangefge
der Eisenbahn, PhD thesis, RWTH Aachen, 1974.
[7] S-Plus, S-Plus 2000 Guide to Statistics, Vol. 2, Data Analysis Products
Division, Mathsoft, Seattle, 1999.
[8] Steckel, J., Strategische Optionen fr die Zufllige Fahrzeit im
Eisenbahnbetrieb, PhD thesis, Hochschule fr Verkehrswesen Friedrich
List Dresden, 1991.
[9] Wendler, E. & Naehrig, M., Statistische auswertung von
versptungsdaten, Eisenbahningenieurkalender EIK, pp. 321-331, 2004.
[10] 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.

Development of a dwell time calculation
model for timetable planning
S. Buchmueller
1
, U. Weidmann
1
& A. Nash
2

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 SBBs 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.
1 Introduction
1.1 Background
Switzerlands 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 sub-
process 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 trains 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.
Table 1: Dwell time sub-processes.
Sub-process Location Process Begins Process Ends
Door-unblocking (DU) 1 Doorway Train arrival Begin door opening
Door opening (DO) 1 Doorway Begin door opening First passenger
through the doorway
Boarding/alighting
(BA)
1 Doorway First passenger
through the doorway
Last passenger
through the doorway
Door closing (DC) 1 Doorway Last passenger
through the doorway
Door closed
Train dispatching (TD) Whole Train Last 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: Dwell time sub-processes.
3 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
dwell processes. Finally, all these data must be recorded for each vehicle door
separately.
Given these stringent requirements, the SBBs 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 direction-
sensitive 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 wireless-
LAN to a central database.

Figure 2: Automatic passenger counting system layout (above/left), infrared-
sensors 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 For each door of the train
Station ID
Train arrival (timestamp)
Train departure (timestamp)
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))
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: Dwell process measurements by vehicle type.
Vehicle type Type series / manufacturer Measured dwell processes
DTZ RABe 514 / Siemens 821488
FLIRT RABe 523 / Stadler Rail 1078352
GTW 2/6 RABe 526 / Stadler Rail 655574
GTW 2/8 RABe 526 / Stadler Rail 489204

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 trains 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 push-
button 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).
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.

Figure 4: 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).
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

Figure 6: 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 projects 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.
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 1
st
and 2
nd
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 Zurichs S-Bahn Through Computer
Analysis and Simulation, Transportation Research Record #1955,
Transportation Research Board, Washington D.C., pp. 1725, 2007
[5] Lee, Y., Daamen, W. & Wiggenraad, P., Boarding and alighting behavior of
public transport passengers. In Proceedings of the 86
th
Annual Meeting. CD-
ROM. Transportation Research Board, Washington, D.C., pp. 114, 2007
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
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 (TFR), 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.
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 (TFR) 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.
Stockholm
Gteborg
Katrineholm
Flen
Herrljunga
Jrna Hallsberg
Lax
Falkping
Skvde
Alingss
Stockholm
Gteborg
Katrineholm
Flen
Herrljunga
Jrna Hallsberg
Lax
Falkping
Skvde
Alingss
Gothenburg
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.

0
100
200
300
400
500
600
700
800
900
0 50 100 150 200 250 300 350 400 450 500 550 600
Mean [s]
S
t
a
n
d
a
r
d

d
e
v
i
a
t
i
o
n

[
s
]
High speed trains
Regional east
Regional west
Local east
Local west

Figure 2: Characteristics of passenger trains initial delays.
0
200
400
600
800
1000
0 100 200 300 400 500 600
Mean [s]
S
t
a
n
d
a
r
d

d
e
v
i
a
t
i
o
n

[
s
]
446
420, 424, 438
400 422
444

Figure 3: Characteristics of individual high speed trains. Each point
represents one train. Some trains are labelled with their train
number.
0
500
1000
1500
2000
2500
3000
0 500 1000 1500 2000 2500 3000
Mean [s]
S
t
a
n
d
a
r
d

d
e
v
i
a
t
i
o
n

[
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,

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.

0
200
400
600
800
1000
1200
-50 0 50 100 150 200 250 300
Mean [s]
S
t
a
n
d
a
r
d

d
e
v
i
a
t
i
o
n

[
s
]
High speed trains
Other passenger trains
Freight trains

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.
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 Skvde (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 Sdertlje (S).
At stations like Skvde, with a high variance in exchange time, it becomes quite
difficult to choose a feasible timetable dwell time that works.

0 30 60 90 120 150 180 210 240 270 300 330 360 390 420 450 480 510 540 570 600
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0.5
0.55
0.6
0.65
0.7
0.75
0.8
0.85
0.9
0.95
1
Exchange time [s]
C
u
m
u
l
a
t
i
v
e

s
h
a
r
e

S down
S up
K down
K up
Sk down
Sk up

Figure 6: Distributions for passenger exchange time at three different
stations.
4 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
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.

95%
94%
90%
84%
83%
84%
80%
83%
80%
81%
78%
73%
72%
71%
95% 95%
93%
92%
89%
85%
84%
83% 83%
81%
77%
73%
71%
89%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
G
dep
Sel
dep
A
dep
Hr
dep
F
dep
Sk
dep
L
dep
Hpbg
dep
K
dep
Fle
dep
Gn
dep
S
dep
Flb
dep
Cst
arr
Real
Simulated

Figure 7: 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.
5 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., Frbttrad punktlighet p X2000 analys med hjlp av
simulering, KTH 2007
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.
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 new-
generation 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


Figure 1: 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.


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 TRENOs 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.
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 three-
dimensional 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 F
r
:

F
t
=F f
1
f
2
(1)

The curve based on F can be graphically fitted as upper bound of real ones,
obtaining the best performance rate f
1
. Once this first value has been fixed, its
variability as piecewise linear probability function is calculated, obtaining a
second performance factor f
2
, on the basis of running time distribution to cover a
distance D. D and f
2
intervals are defined by the user, the corresponding time
values t
i
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 f
1f
and f
2f
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; f
1b
and f
2b
parameters similar to f
1
and f
2
are
calculated as braking performance parameters. Otherwise, using f
1
and f
2
, BWP
or the braking rates are calculated. In this case, f
1
and f
2
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 speed-
time 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.

Venezia Portogruaro Cervignano Trieste
Udine Treviso Casarsa Udine
Slovenia

Figure 4: Simple topology of the Venice Trieste line layout.
Table 1: Comparison between stochastic simulations. Calibration parameters
source: Scen. 1-4 timetabling points, Scen. 5 Collected data.

Stochastic Parameters

DIS
calibrated
Braking

Results

Scenario
Initial
Delay
Running
Time
Stop
Time
1
[%]
3
[%]
Mean
[s]
1 Yes
(neg. exp)
No No No 14.1 11.3 68
2 Yes
(neg. exp)
Yes No No 12.8 9.5 59
3 Yes
(neg. exp)
Yes Yes No 9.8 7.2 51
4 Yes
(pie.lin.)
Yes Yes No 7.2 5.3 40
5 Yes
(pie.lin.)
Yes Yes Yes 5.3 2.9 22
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 its 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 re-
calibration 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).

Figure 6: Recorded speed profile v(t) at arrival compared to calculated curves
with different performance factors (straight lines).
6 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.
[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
Optimal train control at a junction
in the main line rail network using
a new object-oriented signalling system model
R. Takagi
1
, P. F. Weston
2
, C. J. Goodman
2
, C. Bouch
3
,
J. Armstrong
4
, J. Preston
4
& S. Sone
1

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.
Rescheduling 137
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 Object-
Oriented 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.
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.

Abbotswood
Junction
To Birmingham
To Bristol
T
o

W
o
r
c
e
s
t
e
r
Route G26B
Route G26A
Route
G59A
Route G59B
Route G126
Route G128
DOWN MAIN
UP MAIN
DOWN GOODS LOOP
U
P

W
O
R
C
E
S
T
E
R
D
N

W
O
R
C
E
S
T
E
R
Abbotswood
Junction
To Birmingham
To Bristol
T
o

W
o
r
c
e
s
t
e
r
Route G26B
Route G26A
Route
G59A
Route G59B
Route G126
Route G128
DOWN MAIN
UP MAIN
DOWN GOODS LOOP
U
P

W
O
R
C
E
S
T
E
R
D
N

W
O
R
C
E
S
T
E
R

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.
Rescheduling 139
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.

Abbotswood Junc.
(for Birmingham)
Abbotswood Junc.
(for Worcester)
(for Bristol)
0 10 20 30 40 50 60 70 80
time [minutes]
freight
train
Abbotswood Junc.
(for Birmingham)
Abbotswood Junc.
(for Worcester)
(for Bristol)
0 10 20 30 40 50 60 70 80
time [minutes]
freight
train

Figure 2: Assumed schedule of trains including one freight and twelve
passenger trains.
0 10 20 30 40 50 60 70 80
time [minutes]
Abbotswood Junc.
(for Birmingham)
Abbotswood Junc.
(for Worcester)
(for Bristol)
delayed freight train
0 10 20 30 40 50 60 70 80
time [minutes]
Abbotswood Junc.
(for Birmingham)
Abbotswood Junc.
(for Worcester)
(for Bristol)

Figure 3: Result of applying first-come, first-served junction control with a
30-minute delayed freight train.

4 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
Rescheduling 141
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 1 D .

Abbotswood Junction
(for
Birmingham)
(for
Bristol)
(for Worcester)
A
B
C
D
A ~ C: number of trains to come
D: number of trains in goods loop
(A, B, C, D): the state
Abbotswood Junction
(for
Birmingham)
(for
Bristol)
(for Worcester)
A
B
C
D
A ~ C: number of trains to come
D: number of trains in goods loop
(A, B, C, D): the state

Figure 4: 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 S
P, 1
, S
P, 2
, , S
P, N
)
and Q (sequence S
Q, 1
, S
Q, 2
, , S
Q, M
), and if S
P, i
= S
Q, j
, then the crossover of
these two chromosomes at S
P, i
= S
Q, j
creates a new chromosome which has the
sequence of either (S
P, 1
, S
P, 2
, , S
P, i
, S
Q, j+1
, S
Q, j+2
, , S
Q, M
) or (S
Q, 1
, S
Q, 2
, ,
S
Q, j
, S
P, i+1
, S
P, i+2
, , S
P, 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.
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).

0 10 20 30 40 50 60 70 80
time [minutes]
Abbotswood Junc.
(for Birmingham)
Abbotswood Junc.
(for Worcester)
(for Bristol)
0 10 20 30 40 50 60 70 80
time [minutes]
Abbotswood Junc.
(for Birmingham)
Abbotswood Junc.
(for Worcester)
(for Bristol)

Figure 5: Optimisation result (1) weight of passenger : freight trains = 6 : 1.
Rescheduling 143
0 10 20 30 40 50 60 70 80
time [minutes]
Abbotswood Junc.
(for Birmingham)
Abbotswood Junc.
(for Worcester)
(for Bristol)
0 10 20 30 40 50 60 70 80
time [minutes]
Abbotswood Junc.
(for Birmingham)
Abbotswood Junc.
(for Worcester)
(for Bristol)

Figure 6: Optimisation result (2) weight of passenger : freight trains = 6 : 3 or
6 : 6.
0 10 20 30 40 50 60 70 80
time [minutes]
Abbotswood Junc.
(for Birmingham)
Abbotswood Junc.
(for Worcester)
(for Bristol)
0 10 20 30 40 50 60 70 80
time [minutes]
Abbotswood Junc.
(for Birmingham)
Abbotswood Junc.
(for Worcester)
(for Bristol)

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
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.

0 10 20 30 40 50 60 70 80
time [minutes]
Abbotswood Junc.
(for Birmingham)
Abbotswood Junc.
(for Worcester)
(for Bristol)
0 10 20 30 40 50 60 70 80
time [minutes]
Abbotswood Junc.
(for Birmingham)
Abbotswood Junc.
(for Worcester)
(for Bristol)

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.
Rescheduling 145
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] 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).
[2] Siu, L. K.: An Object-oriented Railway System and Power Network
Simulator, The University of Birmingham (PhD Thesis) (1995).
[3] 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).
[4] Siu, L. K. and Goodman, C. J.: An object-oriented concept for
simulation, Proc. COMPRAIL 1992 International Conference,
Washington DC, USA (1992).
[5] 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).
[6] Nagao, T.: Optimization Algorithms (in Japanese), Shoko-do
Publishing, Tokyo, Japan (2000), Chapters 10 12.
[7] Rothlauf, F.: Representations for Genetic and Evolutionary Algorithms,
Physica-Verlag, Heidelberg, Germany (2002).
[8] National Institute of Standards and Technology (NIST): Dictionary of
Algorithms and Data Structures (http://www.nist.gov/dads/
HTML/Levenshtein.html).
Running time re-optimization during real-time
timetable perturbations
A. DAriano
1,2
& T. Albrecht
3
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 Trafc and Transportation Sciences,
Dresden University of Technology, Germany
Abstract
In the Netherlands the railway network is heavily used by heterogeneous train
trafc and characterised by short headway times. That is why even small initial
delays may perturb the timetable causing consecutive delays. In such conict
situations, trafc controllers have the complicated task of deciding upon the
optimal train schedule in real-time. They could be assisted by sophisticated
conict-solving systems. Optimal train running proles can be designed that
t 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. Aconict solution systemis 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 trafc
control measure. The optimal solution from a network point of view can be
improved by modifying the speed proles locally for the individual train routes.
A constructive heuristic algorithm for the dynamic modication of running times
during operations is proposed that satises the timetable constraints of train orders
and routes and guarantees the feasibility of the running prole, while taking into
account the properties of the signalling and train protection systems in use. A real-
world example from the Netherlands in the case of the Dutch signalling system
NS54 is presented to demonstrate the benets of the proposed methodology.
Keywords: railway trafc management, train scheduling, delay minimization, train
speed optimization, energy optimal train control.
Rescheduling 147
1 Introduction
The off-line development of detailed conict-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 conicts 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 difcult to manage and easily
generate many consecutive delays (due to conicts).
Current operational trafc management is reactive: a train driver tries to adhere
to the original schedule and responds to the signalling systemwhen the route ahead
happens to be occupied. Dispatchers only reschedule the route setting plan when
trains have a considerable delay, and (network) trafc controllers become active
when train trafc is already highly disrupted. Hence, improving the reliability
of dense train trafc requires an advanced railway trafc management system
that accurately monitors current train positions, predicts potential conicts and
reschedules trains in real-time such that consecutive delays are minimized [2].
Traffic
monitoring
Conflict
detection
There will
be conflicts
in the future.
There wont be conflicts,
all trains can travel
according to timetable.
Conflict
resolution
Solution
contains
overlaps.
Speed
optimization
Solution doesnt
contain overlaps.
To be transmitted
to the trains.
Figure 1: Components of a proactive trafc 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. Trafc monitoring: Take as input the position, the speed and the planned
timetable for each running train in the railway network.
2. Conict detection: Given the current infrastructure status, actual timetable
and current train delays and speeds, nd potential conicting train paths that
require the same infrastructure element at the same time (conicts): this will
be prohibited by the safety system.
3. Conict resolution: Given the current train delays and predicted conicts,
nd 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].
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 trafc is proactively managed.
Based on an accurate monitoring of actual train positions potential conicting
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 allownot 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 conicts.
The literature on trafc management focuses on conict 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 opti-
mization at a single junction. This paper presents an advanced trafc 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 conict 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 Conict detection and resolution system
The aim of real-time rescheduling is to control the railway trafc 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
xes a precedence constraint between two trains at a potential conict point. This
alternative graph can be used to model different signalling systems and therefore is
quite exible [9]. In case of xed 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 satised. The CDR problem(or train scheduling
problem) can then be dened as follows: For given initial delays nd the shortest
paths in the alternative graph and x the corresponding selected alternative arcs.
All trains are considered simultaneously with the aim to minimize the maximum
Rescheduling 149
consecutive delay in the network. DAriano et al. [10] developed an efcient
branch and bound algorithm to nd 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. DAriano et al. [11] therefore developed a train management system
that updates the speed proles 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 prole 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 conicts are solved, which again may lead to slowing down of trains.
The rescheduling procedure terminates in a nite number of iterations and gives a
conict-free timetable with admissible train dynamics.
3 Optimal speed control in conict 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 non-
safe conrmation of the signal upgrade by the driver. At the time the conict
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 rst 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 conict area with optimal distance behind the train
causing the conict. The train should then never have to pass a signal aspect that
forces a modication 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 thats 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
Compute time-optimal
trajectory
Find most critical
overlap, compute
target trajectory
Fix start state on start
trajectory with respect
to following trains
Fix target state on
target trajectory
Max. cruising speed =
max. speed between
start and target state
Decrease max. crui-
sing speed and com-
pute new trajectory
Target state
reached before time?
Trajectory
influenced by
signalling?
Optimization
terminated, optimal
trajectory found
Shift target
state
towards
start state
1
2
3
4
5
no
yes
no
yes
position
speed
time
1
start trajectory
not feasible
2 most critical
overlap and
target trajectory
y
e
l
l
o
w
r
e
d
signal
upgrade
times
from
preceding
train
3
start
state
subsequent
crossing
train
that needs
the same
infrastructure
to be
respected
in phase 3
release
time
switch/sight/
reaction
time
approach
time
line speed limit
4
target
state
1
2
5
5
4 target
state
6
7
6
6
6
Figure 2: Flowdiagramand the algorithmsteps 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 conict 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 conict 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 nding 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 conict, 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 conict. Those delays may cause consecutive
delays of subsequent trains.
Rescheduling 151
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 fromits 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 xed 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 nd the switching points between the
regimes, the maximal cruising speed between start and target state is successively
reduced, the rst 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 involun-
tarily 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 redened
(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 conict. That
may be done using Dynamic Programming [4].
4 Case study
This section illustrates the inuence of the effective railway trafc 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 kmand includes
Culemborg station. There are four trains in the network. Train A is a freight train,
6
5
8
4
2
3
1
7
9 10 11 12 13 14 15 16 17 18 19 20 21 22
A
D
B C
Culemborg
Utrecht Geldermalsen
Dordrecht
Figure 3: Utrecht - Geldermalsen railway link.
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 inuenced by the presence of permissive signals
and signalling block constraints at the entrance of Culemborg station. Potential
conicts 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 conict 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 Conict 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
60
120
180
240
300
360
420
480
540
600
660
720
738
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 22
TIME (sec)
DISTANCE (block section)
2 21
OVERLAPS
Train D Train C
Train A Train B
Train D
Train B
Train A
Train C
Figure 4: Blocking time plot of the CDR solution.
Rescheduling 153
and C interfere on block sections 15-17 as illustrated by the overlapping blocks.
In this situation, the planned speed proles of those trains can no longer be used
in the CDR algorithm. They are adapted according to the iterative rescheduling
procedure of DAriano 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 prole.
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 proles.
The CDR solution presents feasible speed proles 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 algorithmin 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 Dcan 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 xing 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 doesnt
inuence 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. Trafc operators must discuss which of
the solutions ts their objectives during operations.
5 Outlook and conclusions
This paper showed the effectiveness of an intelligent method to reduce consecutive
delays by identifying potential conicts, rescheduling train trafc and optimizing
the speed trajectory of each train involved in a conict/overlap situation. Such
5000 7500 10000 12500
5000 7500 10000 12500
0 2500 5000 7500 10000 12500
0
100
200
300
400
500
600
700
800
0 2500 5000 7500 10000 12500
0
20
40
60
80
100
120
140
0 2500 5000 7500
0
100
200
300
400
500
600
700
800
0 2500 5000 7500
0
20
40
60
80
100
120
140
position in m position in m position in m
Train D:
Arrival: 331 s
Energy: 9.7 kWh
Train C:
Arrival: 747 s
Energy: 311.8 kWh
Train B:
Arrival: 608 s
Energy: 332.9 kWh
Train D:
Arrival: 376 s
Energy: 34.4 kWh
Train C:
Arrival: 723 s
Energy: 181.5 kWh
Train B:
Arrival: 588 s
Energy: 146.3 kWh
Train D:
Arrival: 331 s
Energy: 9.7 kWh
Train C:
Arrival: 723 s
Energy: 192.8 kWh
Train B
Train C
Train D
Train D
yellow 80
yellow 40
red
I) No speed optimization II) Top-down speed optimization III) Constrained speed optimization
t
i
m
e
i
n
s
s
p
e
e
d
i
n
k
m
/
h
t
i
m
e
i
n
s
s
p
e
e
d
i
n
k
m
/
h
0 2500
0
100
200
300
400
500
600
700
800
0 2500
0
20
40
60
80
100
120
140
10000 12500
10000 12500
t
i
m
e
i
n
s
s
p
e
e
d
i
n
k
m
/
h
Legend:
Train B:
Arrival: 588 s
Energy: 244.8 kWh
Figure 5: Comparison of three variants of train speed trajectories.
R
e
s
c
h
e
d
u
l
i
n
g

1
5
5
a system can be implemented in an advanced trafc 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 mini-
mize energy consumption.
In the future, it is planned to include the speed optimization into the iteration
algorithmof the CDRsystemalready 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: Com-
puters in Railways IX, pp. 529538, Southampton, 2004. WIT Press.
[2] Ho, T.K., Norton, J.P. & Goodman, C.J., Optimal Trafc Control at Railway
Junctions. IEE-Proc.-Electr. Power Appl., 144(2), pp. 140148, 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. 847856, Southampton, 2002. WIT Press.
[5] Oh, S.M., Hong S.H. & Choi, I.C., Railway conict detection and resolution
in the Korean railway system. In: Computers in Railways IX, pp. 675684,
Southampton, 2004. WIT Press.
[6] Asuka, M. & Komaya, K., Automatic train operation using braking pattern
transitional time. In: World Conf. on Railway Research, pp. 628636, 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 Trafc Management Systems. In: Computers in
Railways IX, pp. 695704, Southampton, 2004. WIT Press.
[10] DAriano, 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] DAriano, A., Pranzo, M. & Hansen, I.A., Conict 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 Koniktsituationen. Signal und Draht, 97(12), pp. 1822, 2005.
An algorithm for train rescheduling using
rescheduling pattern description language R
C. Hirai
1
, N. Tomii
2
, Y. Tashiro
3
, S. Kondou
4
& A. Fujimori
5

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
Rescheduling 157
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.
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

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.

7

1
5
1

2

9

1
0

3

4

1
1

1
2
Station A
Station B
Station C
Station D
Station E
Station F

1
3

8

5

6
Time

7

1
5
1

2

9

1
0

3

4

1
1

1
2
9
0
0
3
Station A
Station B
Station C
Station D
Station E
Station F

1
3

8
9
0
0
5

5

6
9
0
0
1
Time
Cancelled express
train
Cancelled local train

Express
train
Local train Extra train
(a) Initial schedule (b) Resultant schedule
Rescheduling 159
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.

Figure 2: Train rescheduling pattern 1 (TRP-1).


Time Time
(a) Initial schedule (Train X is cancelled) (b) Resultant schedule

X

(
C
a
n
c
e
l
l
e
d
)

Z
Station A
Station B
Station C
Station D
Station E
Station F

Y

X

(
C
a
n
c
e
l
l
e
d
)

Z
Station A
Station B
Station C
Station D
Station E
Station F

Y

(
C
a
n
c
e
l
l
e
d
)
Time Time
(a) Initial schedule (Train X is partially cancelled) (b) Resultant schedule
Station A
Station B
Station C
Station D
C
a
n
c
e
l
l
e
d

Z

X

Y
C
a
n
c
e
l
l
e
d
Station A
Station B
Station C
Station D
Station E
Station F
C
a
n
c
e
l
l
e
d

Z
W

X

Y
Station F
Station E


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.
Time Time
(a) Initial schedule (Train X is cancelled) (b) Resultant schedule

W
X

(
C
a
n
c
e
l
l
e
d
)

Y

Z
Station C
Station D
Station E
Station F

W
X

(
C
a
n
c
e
l
l
e
d
)

Y

(
C
a
n
c
e
l
l
e
d
)

Z
V
Station C
Station D
Station E
Station F
Rescheduling 161
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 R-
interpreter.
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.
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. R-
interpreter 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.

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 R-
interpreter 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-Xs 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
Working Stage
Cancellation
of a train
Schedule change
of a train-set
Schedule
of a train
MODIFY
DELETE
CREATE
R-rule
LOAD
Schedule of
a train-set
Train Schedule Data
LOAD
Schedule
of a train
Schedule
of a train
Schedule of
a train-set
Cancellation
of a train
R-interpreter
Rescheduling 163

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, Train-
set 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.

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

Shunting rescheduling subsystem Crew rescheduling subsystem
Depot shunting
rescheduling
Crew rescheduling
Train scheduling subsystem
Cancellation of a train
because of becoming unworthy
Set an extra train because of
passenger demand
Train-set rescheduling subsystem
because of train-set rescheduling
Set an extra train
because of train-set rescheduling
Train-set rescheduling
Because of another train-set reschedulng
Train rescheduling (in the narrow sense) subsystem
to decrease passengers complaints
Train-set rescheduling
to decrease passengers complaints
Change of track
Change departure
sequence
Station shunting
rescheduling

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:
Rescheduling 165
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
Evaluation value
Without rescheduling (Figure 8(a)) 2138
Existing algorithm [6] 686
Proposed algorithm (Figure 8(b)) 331

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
Accident
(a) Disrupted schedule (b) Resultant schedule
Time
Time
Accident
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: 1
st
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.
18
th
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.
Rescheduling 167
[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.
The contribution of state resources in a
constraint-based scheduling model for conict
solving at railway junctions
J. Rodriguez
INRETS (Institut National de Recherche sur les Transports et leur

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 satises 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 trafc
through junctions, it focuses on the use of state resources to improve the model of
conicts 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 efciency and the effective use of resources. To achieve
this aim, one solution is the use of computer-aided systems in planning and trafc
control. A signicant 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 trafc on connecting lines of a junction is heavy, the junction is likely to
be a critical resource. As a consequence, small disruptions are amplied. A few
seconds originally can quickly lead to a delay of more than 5 minutes. To limit this
.
Securite), Villeneuve dAscq, France
Rescheduling 169
phenomenon, new tracks, points and y-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 trafc control at a junction, the operator must performthe following
tasks :
1. Analyse and select relevant information coming from the eld,
2. Compare data with planned schedules,
3. Detect or anticipate conicts,
4. Select and evaluate alternative solutions that reduce delays caused by
conicts,
5. Choose and implement a solution.
In this context, a computer-based assistance can be used for the rst four tasks
to improve the quality of the nal 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 nal
decision must be left to the operator.
During the last decade, the problem of railway trafc 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 trafc 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 dene a conict
resolution model to use in control centres for xed 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 trafc control [9].
Our rst CBS formulation of the trafc management problem at junction was in
[10], the last updated and detailed description of the model was in [11].
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 allowa better management of conicts between trains running
in opposite directions in a section of track.
The paper is organised as follows: our CBS formulation of the railway trafc
management is introduced in section 2. Within the framework of this model,
we dene in section 3 the opposite direction conicts and the state resources
associated. In section 4 the constraints between the activities and the state
resources are dened 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 gure 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 nish
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 rst track circuit of the block. For the general case
of a block system with n aspects, the synchronisation is established with
. . ,
Rescheduling 171
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 rst track circuit of the n 2
th
previous block (e.g. see
hatched rectangles for n = 3 in gure 2).
For train scheduling, the criterion frequently used is the sum of train delays
caused by conicts. This criterion is formulated with the sum of the waiting time
variables.
3 Opposite direction conicts
Let us dene a conict sequence as a common sequence of track circuits
requested by two trains. There will be a running conict when both trains request
one track circuit of the conict sequence during a common time interval. To
arbitrate the conict, the train circulations are ranked on the conict sequence, i.e.
the corresponding activities are ranked according to the train rank decision. For the
case of a conict 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 conict, there is no propagation of the rank
decision; all the activities of the conict sequence have to be ranked. The search
algorithm for a feasible schedule is based on rank decision of activities. When
there are opposite direction conicts, the search algorithm will slow down as it
needs more backtracks to nd feasible ranks.
Figure 3: Example of 4 opposite conict sequences.
cf1
cf2 cf3
cf4
Figure 4: The Hasse diagram of conict sequences.
To propagate the rank decision along the activities of an opposite direction
conict, we suggest using a state resource. A state resource is characterised as
follows:
It has an innite 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 trafc optimisation problem, a state resource models
the allowed running direction during time along the conict sequence. Therefore a
state resource with 2 states (one for each direction) is associated with each opposite
conict sequence. The next section describes the constraints to post in order to
obtain a correct propagation of rank decisions.
Rescheduling 173
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 conict sequence, the running direction will be constant from the start time of
the rst activities until the end time of the last activity. To satisfy this requirement,
we dene a constraint requiring that the state of the state resource has be constant
during all the activities of the conict sequence.
To formulate the constraint, let Ct(t, cfi, state) be the constraint of the state
resource of cfi in state state for a train t. This constraint is the conjunction of the
state resource constraints of all activities of the conict sequence i.e. :
Ct(t, cfi, state) =
z
j
cfi
activity(t, z
j
).requires(cfi.resource, state)
To illustrate this constraint, let us consider the example of gure 3. The
opposite direction of the routes R1 and R2 yields the conict sequence cf1 :<
z1, z2, z3, z4 >. If a train is running on route R1, the state resource associated
to cf1 must be on the state E during the running through all the track circuits of
cf1. The state constraint of the route R1 is then :
Ct(t, cf1, E) = activity(t, z
1
).requires(cf1.resource, E)
activity(t, z
2
activity(t, z
3
activity(t, z
4
).requires(cf1.resource, E) .
The state resource of the route R2 is similar, but with the state W.
The rank decisions to arbitrate a conict between two trains t
1
, t
2
requiring any
track circuit of cf1 will be translated as one of the rank decisions :
activity(t
1
, z
4
) activity(t
2
, z
4
),
activity(t
1
, z
1
) activity(t
2
, z
1
).
This results is obtained by the constraints Ct(t1, cf1, E) and Ct(t2, cf1, W)
which propagates the decision along the conict 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 sufcient
conditions to post a state resource constraint ? To answer the question, let us
consider again the example of gure 3. There are 4 conict sequences :
cf1 :< z1, z2, z3, z4 >,
cf2 :< z1, z2 > ,
cf3 :< z2, z3, z4 > ,
cf4 :< z2 >.
The conict 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 conict sequences of the example of 3. In the Hasse
diagram, each conict sequence is represented as a vertex and a line is drawn
upward fromcf
i
to cf
j
if cf
i
cf
j
, and there is no cf
k
such that cf
i
cf
k
cf
j
,
we say that cf
j
covers cf
i
.
When a track circuit is assigned to a train, the following rules are used to post
constraints:
Rule 1: If a the track circuit z
i
is assigned to a train then post the state resource
constraint of least conict sequence which includes z
i
(noted lcs(z
i
)).
Rule 2: For all conict sequence cf
i
covered by lcs(z
i
), post state resource
constraint of cf
i
.
To illustrate Rule 1, let us consider the example of gure 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 conict sequence cf2 in E direction
is posted. Indeed, cf2 is the lcs(z1), i.e. none of the conict sequences which
include z1 is a subset of cf2. Note that cf1 includes z1, but it is not the lcs(z1)
as cf2 is one of the subsets of cf1 (see the upward line of the Hasse diagram in
gure 4).
The second rule concerns the conict sequence covered by the least conict
sequence. We can take the as an example the gure 3 and the case of the assignment
of track circuit z1. As the resource of cf2 is required by the train in direction
E, to avoid inconsistencies, we must require the resource of the covered conict
sequence cf4 in the same direction and during the same interval.
So, after the assignment of z1 to the train, the state resources of cf2 and cf4
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 Pierrette-Gonesse junction.
Table 1 shows some preliminary results on a set of growing size probleminstances.
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 : Computation time in CPU seconds to nd the best solution,
BT : Number of backtracks of the search algorithm.
Rescheduling 175
Table 1: Computational results.
CBS CBS+SRC
Inst. #t Crit CPU
a
BT Crit CPU
a
BT
1 6 64 1.63 206 64 1.91 138
2 8 64 1.75 631 64 2.42 322
3 8 66 2.4 721 66 3.1 304
4 10 161 33.42 8774 161 22.33 1172
5 12 161 68.66 9848 161 43.91 1286
6 14 313 339.6 27 323 258 832.12 13 646
7 16 350 704.93 24 789 258 1199.3 14 379
8 18 498 955.67 9055 461 646.02 7739
9 20 512 345.2 11 994 498 1585.14 7611
10 22 648 718.08 5084 609 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 rst observation is that the number of backtracks has been signicantly
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 rst attempt of using
these kinds of constraint need further researches. Some improvement issues have
been identied 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,
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 articial 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 IA95, 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. CP97 Workshop on Industrial
Constraint - Directed Scheduling, pp. 112, 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, Trafc 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. 659668, 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. 498517, 2002.
[13] Delorme, X., Rodriguez, J. & Gandibleux, X., Heuristics for railway infras-
tructure saturation. Electronic Notes in Theoretical Computer Science 50
N1(2001) URL: http://www.elsevier.nl.locate/entcs/volume50.html, pp. 41
55, 2001.
Rescheduling 177
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.
Rescheduling 179
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.
Infrastructure
Layout
Route
functions
Top Level
Common Module
Timetable
MovInsp

Figure 1: 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 re-
drawing 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.
Rescheduling 181
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.
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.
Rescheduling 183
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 Roma-
Formia, 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.
6.00.00
6.36.00
7.12.00
7.48.00
8.24.00
9.00.00
9.36.00
10.12.00
10.48.00
11.24.00
5
,
0
0
0
1
0
,
0
0
0
1
5
,
0
0
0
2
0
,
0
0
0
2
5
,
0
0
0
3
0
,
0
0
0
3
5
,
0
0
0
4
0
,
0
0
0
4
5
,
0
0
0
5
0
,
0
0
0
5
5
,
0
0
0
6
0
,
0
0
0
6
5
,
0
0
0
7
0
,
0
0
0
7
5
,
0
0
0
8
0
,
0
0
0
8
5
,
0
0
0
9
0
,
0
0
0
9
5
,
0
0
0
1
0
0
,
0
0
0
1
0
5
,
0
0
0
1
1
0
,
0
0
0
1
1
5
,
0
0
0
1
2
0
,
0
0
0
1
2
5
,
0
0
0
m
h
h
.
m
m
.
s
s
1
5
7
11
17
19
21
23
25
27
29
31
33
35
41
49
53
57
61
63

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.
Rescheduling 185
Platform Change
Solution 1 Other trains delay
Train A delay
Train A
platform change
Other trains delay
Other trains delay
Solution 2
Other trains delay
Conflict:
Train A
vs
Train B
Solution 4
Solution 3
Solution 5 Solution 8
Solution 6 Solution 7
N
Train B delay
Train B
platform change

Figure 4: 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.
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:
+ <
b f
f b
v v
d t t
1 1
,
with t
b
transit time of the train behind in the interception section, t
f
transit time of
the train ahead, d distance from interception section to the next section, v
f

average speed of the train forward, v
b
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.
Rescheduling 187
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, 118128.
[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, 5763, 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, 1122, 2002.
[4] Malavasi, G., Ricci, S., Railway Traffic Simulation by means of a Petri Net
model. Computers in Railways VIII, WIT Press, Southampton, 407415,
2002.
Comparing the effectiveness of two real-time
train rescheduling systems in the case of
perturbed trafc conditions
S. Wegele
1
, F. Corman
2
& A. DAriano
2,3
1
Institute for Trafc 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 trafc 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 trafc operators. Previous attempts to provide an
automated decision support system have been limited to identifying and solving
train conicts 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, devel-
oped for the German and Dutch railway networks. The research aim is to estab-
lish 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 trafc 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 compu-
tation 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 conicts and to get precise
information about their resolution by the different rescheduling techniques.
Keywords: decision support, computer techniques, dynamic train regulations.
Rescheduling 189
1 Introduction
Railway trafc is currently operated according to a timetable designed months in
advance. However, during operations unforeseen events generate conicts 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 predeter-
mined rules to manage disturbed trafc 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 trafc ow.
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., conict-free and deadlock-free schedules) in a short time.
This paper presents a comparative study to assess the effectiveness of two deci-
sion support tools for optimal rescheduling of train operations, developed for the
Dutch and German railway networks (see respectively DAriano [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 briey the two dispatch-
ing 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 com-
pared 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 posi-
tions and speeds of the trains running in the studied area, as well as the infrastruc-
ture status and deviations fromthe 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: adjust-
ing 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 rst-come-rst-served are adopted
since these are simple to be implemented while in the related literature advanced
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 sup-
port tool connected with actual track occupation and release data in order to auto-
matically detect delays, headway and route conicts.
The precise computation of train dynamics, needed to forecast the trafc ow
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, inuencing the way trafc ow is managed.
We next describe briey 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 conict 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 trafc ow is modeled as a job shop scheduling
problem and represented by means of alternative graphs. Innovative train schedul-
ing and rerouting algorithms have been developed for the resolution of complex
global conict 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].
Rescheduling 191
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
Zugbeeinussung, point-wise train protection) system combined with the LZB
(Linienzugbeeinussung, continuous train control) system, the block sections of
the Dutch ATB (Automatische Treinbe
invloeding, automatic train protection) sys-

tem 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 modied
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 xed block signaling system. If
the minimum required headway distance between two consecutive trains is not
Figure 3: Core structure of the GADis system.
Figure 4: Comparing features of the two dispatching support tools.
respected, the following train encounters a yellowor 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 sys-
tems are simplied 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.
Rescheduling 193
3 Experimental results
This section presents a common test case from a complex dispatching area in the
Netherlands. For given trafc 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 conicts and to get precise information about their resolution by the different
rescheduling techniques.
3.1 Test case description
The GADis and ROMAsystems were tested on the Dutch dispatching area between
Utrecht and Den Bosch. The network consists of a corridor around 50 kmlong 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 trafc (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 minimumdwell 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 dif-
ferent degree of approximation and use different signaling and train protection
systems, we rst 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 conicts. In the
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 xed 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 xed 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 out-
put 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
Rescheduling 195
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 sig-
naling 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 nd 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. Specically, 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
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 signicantly the
solution obtained in the previous subsection.
The GADis solution contains the following differences compared to the train
orders xed 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 conicts
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 trafc ow remains stable.
Rescheduling 197
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 trafc 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 digi-
tal 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 stimu-
late 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 TRAN-
SUMO 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] DAriano, 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 opti-
mal dispatching of train operation. In: CD-ROM Proceedings of the 2nd
International Seminar on Railway Operations Modelling and Analysis, Han-
nover, Germany, 2007.
[3] DAriano, 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 trafc: Analysis, Modelling
and Simulation, Eurail Press, Germany, 2008.
[5] DAriano, A., Pranzo, M. & Hansen, I.A., Conict resolution and train speed
co-ordination for solving real-time timetable perturbations, IEEE Transac-
tions 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.
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
Rescheduling 199
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.
Figure 1: 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.
Accept?
Train rescheduling methods are applied
Arrival and departure time
Simulation of train operation
Number of passenger
Passenger s loss calculation
Information about delay
Creating a train plan
Evaluating the plan
No
Proposing to
dispatcher Yes
Simulation of passenger flow
Rescheduling 201
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 passengers
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.
St.A Dep
St.B Arr
St.B Dep
St.C Arr
St.C Dep
St.D Dep
St.D Arr
St.E Arr
Order of trains
Blockage
Confliction
of routes
Local Express Local
Regular running time
Regular stopping time
St.A Dep
St.B Arr
St.B Dep
St.C Arr
St.C Dep
St.D Dep
St.D Arr
St.E Arr
Order of trains
Blockage
Confliction
of routes
Local Express Local
Regular running time
Regular stopping time
St.A Dep
St.B Arr
St.B Dep
St.C Arr
St.C Dep
St.D Dep
St.D Arr
St.E Arr
Local Express Local
Transfer
Boarding
Stop
St.A Dep
St.B Arr
St.B Dep
St.C Arr
St.C Dep
St.D Dep
St.D Arr
St.E Arr
Local Express Local
Transfer
Boarding
Stop

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
i
i
t L
1
1
(1)
where N is the number of passenger, ti is passenger is 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
i
M
j
ij
i
r L
1 1
2
(2)
where Mi is the number of transfers passenger i needs, rij is time equivalent to the
burden of passenger is 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.
ks ks
n
k
S
s
ks
ks
c
t q
c
q
f L
k
= =

=
1
1 1
3
(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]).
Rescheduling 203
0
0.1
0.2
0.3
0.4
0.5
0.6
0 50 100 150 200 250
Congestion rate [%]
C
o
n
g
e
s
t
i
o
n

c
o
s
t

p
e
r

m
i
n
u
t
e

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.
3 2 1
L L L L + + = (4)
5 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.
Figure 5: 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.
Express 1 Express 2 Local 1
Passenger overflow
N
u
m
b
e
r

o
f

p
a
s
s
e
n
g
e
r
time
Waiting for Express 2
Transfer passenger from Local 1
t
a
t
b
Express 1 Express 2 Local 1
Passenger overflow
time
Transfer passenger from Local 1
t
a
t
b
Rescheduling 205

Figure 6: The proposed method applied to a diagram.

Figure 7: 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
60
10
60
10
(a) Passenger overflow (b) Apply this method
1.00E+07
1.05E+07
1.10E+07
1.15E+07
1.20E+07
1.25E+07
Regular schedule Not considered passenger
overflow
Proposed method
Travelling time Congestion Transfers
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.

Figure 8: An example of a model of this method.

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 passengers loss increases. This depends on passengers
St.A
St.B
St.C
St.D
St.E
St.F
Regular
schedule
Operation
suspension
Train
rescheduling plan
Start of reschedule plan
Operation suspension
Rescheduling 207
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 Passengers Boarding Behavior. Infrastructure Planning
Review (in Japanese), no. 5, pp. 139146, 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.185190, 2007 (in
Japanese).
Author Index

Abril M. ..................................... 49
Albrecht C. ................................. 11
Albrecht T. ............................... 147
Armstrong J. ............................ 137

Barber F. .................................... 49
Bouch C. .................................. 137
Buchmueller S. ........................ 105

Corman F. ................................ 189

DAriano A. ..................... 147, 189
de Fabris S. .............................. 125
Demitz J. .................................... 11

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
Hbschen C. ............................... 11
Huerlimann D. ............................. 3

Ingolotti L. ................................. 49

Katsuta K. .................................. 25
Klemenz M. ......................... 59, 73
Kondou S. ................................ 157
Koseki T. ................................. 199
Krauss V. P. ................................. 3
Kumazawa K. .......................... 199

Landex A. .................................. 85
Lindfeldt O. ............................. 115

Longo G. .................................. 125
Lova A. ...................................... 49

Medeossi G. ............................. 125

Nash A. ................................ 3, 105
Nielsen O. A. ............................. 85

Oguma K. .................................. 25

Preston J. .................................. 137

Radtke A. ................................... 59
Ricci S. .................................... 179
Rodriguez J. ............................. 169

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

Uemura T. .................................. 25

Watanabe D. .............................. 25
Wegele S. ................................. 189
Weidmann U. ........................... 105
Weston P. F. ............................ 137

Yuan J. ....................................... 95

Timetable Planning and Information Quality 209
...for scientists by scientists
WITPress
Ashurst Lodge, Ashurst, Southampton,
SO40 7AA, UK.
Tel: 44 (0) 238 029 3223
Fax: 44 (0) 238 029 2853
E-Mail: witpress@witpress.com
Urban Transport XV
Urban Transport and the Environment
in the 21st Century
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
Power Supply, Energy
Management and Catenary
Problems
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
Edited by: C.A. BREBBIA,
Wessex Institute of Technology, UK
Edited by: E. PILO,
Pontifical Comillas University of Madrid,
Spain
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.
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
Save 10% when you or der fr om our encr ypted
or der ing ser vice on the web using your cr edit
card.
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
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.
ISBN: 1-85312-887-2 2002 176pp
69.00/US$107.00/103.50
Find us at
Save 10% when you or der fr om our encr ypted
or der ing ser vice on the web using your cr edit
card.
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, So 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.
ISBN: 1-85312-799-X 2006 208pp
66.00/US$120.00/99.00
How to Make Two-Lane
Rural Roads Safer
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
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 two-
lane 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
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.
Par t ial Cont ent s: 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.
ISBN: 1-85312-894-5 2002 216pp
76.00/US$118.00/114.00
We ar e now able to supply you with details of new
WIT Pr ess titles via
E-Mail. To subscr ibe to this free ser vice, or for
infor mation on any of our titles, please contact
the Mar keting Depar tment, WIT Pr ess, Ashur st
Lodge, Ashur st, Southampton, SO40 7AA, UK
Tel: +44 (0) 238 029 3223
Fax: +44 (0) 238 029 2853
E-mail: mar keting@witpr ess.com
Computers in Railways XII
Computer System Design and
Operation in the Railway and Other
Transit Systems
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
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 /apx380.00/
US$760.00/532.00
Edited by: B. NING, Beijing Jiaotong
University, China and C.A. BREBBIA,
Wessex, Institute of Technology, UK

1845645006timetable Planning

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1845645006timetable Planning

Uploaded by

Copyright:

Available Formats

WITeLibrary

Home of the Transactions of the Wessex Institute, the WIT electronic-library

(calibrated function for Deutsche Bahn AG).

-Enterprise environment to support the timetable request and

-CRM [4, 5] module.

[8] can be used to generate a

. NEMO is a strategic planning tool for

is not yet verified but possible [9].

. Also running times and minimum headways

network. The capacity

is made by means of UIC data sheet 406 (Capacity)

), that allows modularity in Petri

capable of drawing and simulating

is possible to insert codes in C or C++ in each

invloeding, automatic train protection) sys-

You might also like