A coupled flood-agent-institution modelling (CLAIM) framework for urban flood risk
management
Abebe, Yared Abayneh; Ghorbani, Amineh; Nikolic, Igor; Vojinovic, Zoran; Sanchez, Arlex
DOI
10.1016/j.envsoft.2018.10.015
Publication date
2019
Document Version
Final published version
Published in
Environmental Modelling and Software
Citation (APA)
Abebe, Y. A., Ghorbani, A., Nikolic, I., Vojinovic, Z., & Sanchez, A. (2019). A coupled flood-agent-institution
modelling (CLAIM) framework for urban flood risk management. Environmental Modelling and Software,
111, 483-492. https://doi.org/10.1016/j.envsoft.2018.10.015
Important note
To cite this publication, please use the final published version (if applicable).
Please check the document version above.
Copyright
Other than for strictly personal use, it is not permitted to download, forward or distribute the text or part of it, without the consent of the author(s) and/or copyright holder(s), unless the work is under an open content license such as Creative Commons. Takedown policy
Please contact us and provide details if you believe this document breaches copyrights. We will remove access to the work immediately and investigate your claim.
This work is downloaded from Delft University of Technology.
‘You share, we take care!’ – Taverne project
https://www.openaccess.nl/en/you-share-we-take-care
Otherwise as indicated in the copyright section: the publisher
is the copyright holder of this work and the author uses the
Dutch legislation to make this work public.
Contents lists available atScienceDirect
Transportation Research Part C
journal homepage:www.elsevier.com/locate/trc
A connected driver advisory system framework for merging freight
trains
Pengling Wang
a,b,⁎, Rob M.P. Goverde
a, Jelle van Luipen
caDepartment of Transport and Planning, Delft University Technology, Delft, the Netherlands bIVT-Institute for Transport Planning and Systems, ETH Zurich, Zurich, Switzerland cInnovatie and Ontwikkeling, ProRail, Utrecht, the Netherlands
A R T I C L E I N F O
Keywords:
Freight train transport Driver advisory system Train traffic prediction Optimization
A B S T R A C T
This paper proposes an approach to facilitate smooth merging of freight trains into a stream of passenger trains with short headways, to help drivers better control freight trains and avoid red signals. An algorithm architecture is proposed for Driver Advisory Systems (DASs) to compute time/speed advice for freight train drivers. The framework includes four parts: buffer stairway prediction, freight train movement prediction, merging window detection and merging optimi-zation. The basic idea is to predict the traffic state in the merging area regularly and find the feasible merging time window. Proper advice can be presented to freight train drivers and help them to merge smoothly, by comparing the freight train movement to the feasible merging window. The performance of the proposed algorithms is illustrated on examples of merging freight trains in the Meteren and Kijfhoek areas on the Dutch railway network. The experimental results show the efficiency and quality of the proposed algorithms on real world size problems.
1. Introduction
In the Netherlands there is a large demand of rail freight transportation for delivering goods between the Netherlands and neighbouring countries. In 2017, the total number of kilometers passed by freight trains achieved 9 million according to a report from the Dutch infrastructure manager ProRail (van Leijen, 2018). Given that railway freight transportation is taking an important share in sustainable transport, it is essential to optimize the freight trains’ usage of the railway infrastructure. In practice, a lot of freight trains share railway lines with passenger trains. However, high-frequency passenger train operations leave little buffer for merging freight trains. We observe a large amount of conflicts near the junctions where freights trains merge from dedicated freight yards or corridors into the mixed traffic lines. Unnecessary braking and re-accelerating of heavy freight trains should be avoided as much as possible due to the energy and time losses involved. Likewise for the passenger trains and moreover, the passenger trains should not be subject to delays and long stops since they have to respect prescribed timetables.
To help drivers better control freight trains and avoid unplanned stops in rear of red signals, a methodology to facilitate smooth merging of freight trains into a stream of passenger trains with relative short headways is proposed in this paper. This work was motivated by a test of advising freight trains during the merging process in the Amsterdam Westhaven area, to explore methodologies and tools to aid the freight train drivers in other more complex locations and situations of merging freight trains.
In the Amsterdam Westhaven area, a concept for advising freight trains departing from standstill is now accepted using the
https://doi.org/10.1016/j.trc.2019.05.043
Received 31 October 2018; Received in revised form 2 April 2019; Accepted 30 May 2019
⁎Corresponding author at: IVT-Institute for Transport Planning and Systems, ETH Zurich, Zurich, Switzerland.
E-mail addresses:pengling.wang@ivt.baug.ethz.ch(P. Wang),R.M.P.Goverde@tudelft.nl(R.M.P. Goverde), Jelle.vanLuipen@prorail.nl(J. van Luipen).
Available online 07 June 2019
0968-090X/ © 2019 Elsevier Ltd. All rights reserved.
countdown tool AftelAPP (seeFig. 1). In the test location, the freight trains depart from the Amsterdam harbour yard and merge into a dense passenger train corridor directly. In order to avoid unnecessary stops and delays of freight trains, AftelAPP is designed to aid in the merging process: AftelAPP starts a countdown after the leading passenger train passes a trigger point. The trigger point is a reference location on the leading train’s route. After the leading train passes the trigger point, the freight train can start accelerating without being hindered by the leading train. In this way, the right time for merging is provided to drivers which helps them merging safely and smoothly.
A lesson learned from this test is that such simple driver advisory systems (DASs) are helpful to avoid unplanned braking in rear of red signals. By using AftelAPP, 19 out of 20 freight trains did not experience conflicts in the merging process. ProRail, the Dutch railway infrastructure manager, together with DB Cargo, being the main freight operator of the Amsterdam harbour, want to explore applications of this successful experience to other areas. The current AftelAPP’s function is relatively simple. AftelAPP is designed for freight trains from standstill, but can not provide advice for moving trains. AftelAPP only monitors one specific passenger train’s movement (the target passenger train in front). It is useful for the specific case in the Amsterdam Westhaven area, however, is hard to implement in other areas. For instances, in the Meteren area, running freight trains merge between running passenger trains, while the frequency of passenger trains is very high (10 trains per hour). In the Kijfhoek area, multiple freight trains merge from standstill between moving passenger trains (seeFig. 2). The traffic in the two cases are much more complicated than the Amsterdam Westhaven case, which requires more advanced tools to help freight train drivers.
ProRail has cooperated with Delft University of Technology to develop a methodological framework to approach this problem. This paper presents our solutions to this problem. Contributions of this paper, to the existing literature, are highlighted as follows. 1. We specify the basic requirements for merging DAS functionalities and propose a C-DAS architecture with four intelligent
functions to achieve a merging DAS.
Currently, there are no mature DASs that can be used to help drivers in merging a train from side tracks into a stream of passenger trains. This article is motivated by the practical requirements of reducing conflicts during the merging process. A C-DAS archi-tecture with four intelligent functions is designed for the merging DAS. The four intelligent functions are respectively: (a) buffer stairway prediction, which estimates the gap between the release of the blocks from the merging section by the train in front and the reservations by the train behind; (b) freight train movement prediction, which predicts the time-distance path of the freight train to and after the merging; (c) merging window detection, which detects the feasible available time-distance paths for mer-ging; and (d) merging optimization, which produces time/speed advice for drivers.
2. We develop algorithms for the merging DAS. The proposed algorithms provide driving advice which can be used to facilitate smooth merging and avoid unnecessary unplanned stops.
In order to predict available buffer stairways for merging, a train traffic model is constructed based on an event graph with dynamic arc weights. The graph topology is built and updated based on the actual process plan and current positions of trains on the network. A running/dwell/clearing time estimation method is presented to estimate dynamic arc weights for the event graph. A real-time event time prediction module is built to predict event times over the event graph. A trajectory optimization algorithm implemented for speed advice is proposed for predicting the time-distance path of the freight train. A linear programming method is developed to find the earliest/latest conflict-free merging time, i.g. the feasible time window at the merging point. Driving advice can be found with comparing the predicted freight trains movement with the advised feasible merging window. 3. The proposed algorithms are fast, as demonstrated in the case studies, which allows their on-line application in the future.
The proposed merging DAS algorithms are tested with realistic merging freight train scenarios from two cases in the Meteren and
Kijfhoek areas. The results show that the algorithms produce reliable merging windows. Application of the algorithm in real-time is possible due to its short computation times and reliable results.
This paper is organized as follows: Section2gives an introduction to the basic terminology and a literature review related to this topic. Section3summaries the requirements for DAS functionalities. An algorithm architecture and algorithms to facilitate smooth merging are developed. Section4analyses data in order to assess the current problem of merging freight trains in the Meteren and Kijfhoek area. Section5illustrates the approach with case studies, and finally Section6ends the paper with conclusions.
2. Terminology and literature review
2.1. Terminology
The railway infrastructure can be represented in terms of block sections. In general, a block section starts and ends with a trackside signal. Rail lines are divided into block sections for the purpose of safe train separation. The blocking time is the total time that a block section is allocated exclusively to a train movement and therefore blocked for other trains (Hansen and Pachl, 2014). The blocking time of a block section begins when the approach route is setup, and ends after the train has cleared the section and all signalling appliances have been released so that a movement authority can be issued to another train to enter the same section. In general, the blocking time of a section consists of the following time components (Fig. 3(a)): the setup time of the route in the block and clearing the signal; the sight and reaction time for the driver to respond on the signal aspects; the approach time between the signal that provides the approach indication and the signal at the entrance of the block section; the running time between the block signals; the clearing time for the entire train to move out of the block; and the release time to unlock the block. For each train the time-distance
path represents the train’s running time along its routes. Drawing the blocking times over all block sections in a time-distance diagram
leads to the so-called blocking time stairway. The blocking times are displayed as boxes over the successive block sections. The upper bounds are the reservation times of the block sections. The lower bounds are the end times of the block sections. For a block section, a
conflict occurs when two blocking times overlap each other. In this case, the following train will meet a yellow approach signal and
has to brake, and possibly stop, in rear of the block signal until the block is released. If there is no overlap, the slot between the
blocking times of two successive trains is called the buffer time. A buffer stairway is a specific stairway pattern in the buffer area as indicated inFig. 3(b).
2.2. Literature review
Merging freight trains on shared-use rail corridors has been widely studied and it remains a topic that continues to interest many researchers. The current research focus is on planning the routes and schedules of freight trains, while researchers from different countries face different challenges. Rail transportation in countries like the United States consists primarily of freight shipments, while passenger services play a limited role as compared to transportation patterns in many other countries. Therefore, researchers often consider freight and passenger trains together and make timetables for them jointly.Kuo et al. (2010)addressed the multi-line freight trains scheduling problem that considers elasticity of demand and perspectives of both shippers and carriers for use in forward markets in the United States. A train slot selection model based on multi-commodity network flow concepts was developed for determining freight train timetables along multiple interconnected routes. The model is solved with a column generation-based methodology.Talebian and Zou (2015)developed a strategic level train planning model for mixed operations on shared-use rail corridors. The work takes into account priority of passenger trains and proposed a two-level modeling framework to sequentially determine passenger and freight train schedules.Liu and Dessouky (2017)studied the joint problem of scheduling passenger and freight trains for US railway networks, where the objective is to minimize the tardiness of passengers at station stops and the delay of freight trains. The problem is modelled as a mixed integer linear program and a two-step decomposition heuristic is proposed to solve the problem. The heuristic first vertically decomposes the train schedules into a passenger train scheduling phase and then a freight train scheduling phase. In the freight train scheduling phase, a train-based decomposition is used to iteratively schedule each freight train.
On the other hand, rail transportation in some European countries can have extremely dense passenger traffic. There are very few time slots that can provide a conflict-free route from the point of origin to the destination available for freight trains. That raises challenges in adding freight trains in shared-use rail corridors.Cacchiani et al. (2010)studied the problem of inserting new freight trains on railway networks while the passenger trains have a prescribed timetable that can not be changed. An integer linear pro-gramming formulation and a Lagrangian heuristic were proposed in order to introduce as many new freight trains as possible.Bach et al. (2015)presented a model to solve the problem of creating a yearly timetable for a freight railway operator using the available infrastructure paths. The objective is to minimize costs while adhering to constraints regarding infrastructure usage, demand cov-erage, and engine availability. The model is solved by a column generation scheme where feasible engine schedules are designed in a label setting algorithm with time-dependent cost and service times.Ursavas and Zhu (2017)developed analytical models for in-frastructure managers to allocate tracks and compute the optimal pricing levels and dispatching times for shared-used corridors in the Netherlands. The proposed models are used by ProRail in the Netherlands to decide which choice of track (dedicated or shared-rail track) is optimal by evaluating the benefits of shared track in terms of what freight traffic on the shared corridor would allow, while at the same time meeting the schedules of the passenger trains.
Passenger and freight trains operate according to the pre-designed timetables, which specify the route allocation of the trains through the infrastructures and regulate the precise time slots of departure and arrival. However, there are always some unavoidable disturbances causing deviation from the original timetable, which calls for more effective real-time traffic management (TMS) (Cacchiani et al., 2014; Corman and Meng, 2015; Corman et al., 2018). The real time traffic management needs to deal with possible conflicts resulting from delayed trains requiring access to tracks that were allocated to another train. It finds adjustments to the train schedule before execution, and aims at bringing the traffic status back to the normal timetable as soon as possible and limiting the economic loss caused.
Chen et al. (2010)focused on the real-time train rescheduling in junction areas. The work does not take into account freight trains. They show that in bottleneck sections, the margin time in the timetable and recovery time for trains are very limited.Caimi et al. (2012)proposed a model predictive control framework for a complex central railway station area. The closed-loop discrete-time model reschedules trains according to solutions of a binary linear optimization model. The model assigns precomputed blocking-time stairways to trains while respecting resource-based clique constraints, connection constraints, platform related constraints and consistency constraints with the objective of maximizing customer satisfaction. They adopted a case study with all freight and passenger trains of a complete day serving or passing through the central railway station Bern to test the proposed dispatching system. The results show that their model is capable of considering many alternative routing possibilities and departure timings.
Pellegrini et al. (2014)proposed a mixed-integer linear programming formulation for managing traffic perturbations in complex junctions. They solve instances in which the infrastructure is represented with fine granularity. Through the granularity, the for-mulation can model either the route-lock sectional-release or the sectional-release route locking and the route-release route-locking principles. The model selects feasible routes and schedules on the blocking time level.
At the current stage, most researches on rail traffic management do not distinguish passenger trains and freight trains. All trains are taken as the same in terms of value of time or travel time reliability. However, passenger and freight trains should be dis-tinguished because they differ a lot in the organization of train operations (Qu et al., 2015).Mazzarello and Ottaviani (2007)
developed a TMS architecture to optimize fluency in railway networks. The proposed TMS is based on layered system architecture, which takes into account the different types of traffic (e.g. passengers vs. freight, international vs. regional or local), the different traffic regulation objectives (e.g. minimum travel time vs. punctuality with respect to the timetable or energy consumption reduction) and the different management approaches characterizing different types of lines. Potential conflicts can be predicted in advance and solved in real time, by managing the order of trains, or using alternative routes, and by issuing proper speed recommendations to train drivers. The proposed TMS is implemented in a green wave case study with a pilot of merging freight trains in the Netherlands.
Corman et al. (2011)proposed a microscopic model to cope with the passenger and freight train rescheduling, using priorities. At each step, the procedure focuses on the current priority class, preserving solution quality from the higher priority classes and ne-glecting the lower priority classes in the optimization of train orders and times. The iterative process is implemented from the highest one to the lowest one until a new network disposition timetable is finished. They use the alternative graph and a B&B algorithm to solve the multiclass rescheduling problem.
Apart from advanced rescheduling systems, new ICT-tools for the support of train drivers in order to improve train operation efficiency have been developed recently. These systems are called Driver Advisory Systems. DAS provides drivers with additional driving advice to keep the train at the optimum speed by improving the control of traction and braking. DAS is an automation level between GoA 1 and GoA 2 (UITP, 2011). The DAS architecture can be classified into three types (Panou et al., 2013; Luijt et al., 2017):
•
Stand alone - Driver Advisory System (S-DAS): has all data downloaded to the train at or prior to the train starting.•
Networked - Driver Advisory System (N-DAS): is capable of communicating with one or more control centers, thus enabling provision of data to the train, including updates for schedule or routing information, though these are generally not in near real time.•
Connected - Driver Advisory System (C-DAS): has a real-time communication to the control center in each controlled area in which the train operates. These systems are still at a conceptual stage. AF (Montigel, 2009), ADL, CATO (Lagos, 2011) and ZLR are typical examples of this category.There are several DASs on the market.Panou et al. (2013)provide a detailed review of the methods and features of existing DASs. However, currently there are no mature DASs that can be used to help drivers in merging a train from side tracks into a stream of passenger trains. Even though freight trains have pre-designed timetables, freight trains are often less punctual, and their movements are often adjusted, especially when merging into shared-use corridors, according to real-time circumstances. Freight trains are predominantly controlled by drivers, who can be supported by a DAS. Energymiser (Pudney et al., 2011; Albrecht et al., 2011; Zhou et al., 2013) is a well-known S-DAS for freight trains for iron ore trains in Africa (up to 2.5 km long and 17,000 tonnes), and freight trains in Australia. It provides optimized and precise advice to drivers of mainline diesel, electric and hybrid trains to help minimize energy consumption and maintain correct schedules on long-distance corridors with none or marginal passenger trains. Energymiser, as an S-DAS, is not able to take into account other trains’ influences and does not support in merging freight trains.
Among the three categories of DAS architectures, the C-DAS connects every single train to a rail traffic management system and has access to real-time monitored traffic states (Quaglietta et al., 2016), which is the most advanced type that can be adapted for advising drivers during merging. The architecture of a C-DAS depends on the allocation of the intelligence between the control center and the train. Three main different ways of distributing the DAS intelligence can be identified (Panou et al., 2013; Rao et al., 2016):
•
DAS-Central: the optimal speed profile computation and advice definition are done in the track-side units (TSUs). The onboard functionality is limited to displaying the prepared advice to the driver.•
DAS-Distributed: the optimal speed profile is computed in the TSUs and sent onboard. The onboard functionality includes the advice definition and display.•
DAS-Onboard: the onboard functionalities include optimal speed profile computation, advice definition and display.The following section presents a C-DAS architecture, that is designed to help drivers in merging freight trains. The distribution of DAS functionalities is also discussed.
3. Methodology
In this section, we first briefly describe the basic requirements for merging DAS functionalities. Then an algorithm architecture is proposed to compute time/speed advice for freight train drivers. Every module and algorithm within the proposed framework is explained in detail.
3.1. Requirements for merging DAS functionalities
This paper focuses on advising freight train drivers. Three realistic assumptions are made:
•
The passenger trains are observable but not controllable. It is assumed that the passenger trains’ location/speed are monitored in real-time. But the freight train DAS can not command passenger train drivers.•
The freight trains are observable and controllable. It is assumed that the freight trains’ location/speed are monitored in real-time. Driving advice can be presented to freight train drivers and guide them in train control.•
The train sequence is known in advance. The target trains in front and after the merging are known to the freight train DASs. The DAS advises freight train drivers while assuming the passenger trains are observable but not controllable. This means that the merging DAS is a C-DAS, which should be connected to a traffic management system that minors all traffic and communicates the relevant information to the onboard DAS of the freight train. This is because the DAS should be aware of the traffic environment, especially the trains in front and behind the freight train in the merging area. The merging freight train problem aims at merging a freight train into a mixed traffic corridor and run smoothly preventing hindering or being hindered by other trains as much as possible. The freight train can make use of the buffer stairway between its leading and following trains. For conflict-free merging, the blocking time stairway of the merged train cannot overlap the blocking time stairway of other trains. Especially, unplanned stops of freight trains should be avoided (if possible) since it is time- and energy-consuming to re-accelerate a freight train. In some cir-cumstances, the buffer is not big enough for conflict-free merging, especially when the passenger trains are affected by delays/ disruptions. In this case it is not possible to merge without hindering the following passenger (or freight) train. If the freight train would meet yellow signals it has to slow down and the odds are high that following passenger trains will be hindered. An alternative would be to wait for the next slot with better opportunities for a smooth merging. For a starting train from stand-still this is reasonable. For a running train this means that the proper target train pair should be selected well in advance, so that the freight train may slow down to merge at the right time; this works for freight corridors where the frequency is not that high.3.2. Algorithm architecture
To facilitate smooth merging of a freight train into a stream of passenger trains, the DAS should be able to look ahead and predict the train traffic state in order to detect the available buffer stairways for merging. The DAS should be able to predict the freight train movement and find the right time for merging to provide proper advice.Fig. 4presents the algorithm architecture for a merging DAS to compute time/speed advice for freight train drivers. The architecture integrates the following four main functions:
•
Buffer stairway prediction: estimates the buffer stairway between the target trains in front and behind the freight train in themerging area within a prediction horizon.
•
Freight train movement prediction: predicts the running times, as well as the blocking time stairway, of the freight train.•
Merging window detection: computes the feasible merging window at the merging point if possible.•
Merging optimization: computes time/speed advice for drivers.The merging DAS must be a C-DAS, which includes two parts, one part is installed on the track side while the other is installed on board. A possible allocation of the four functions between track-side units and on-board units (OBUs) is that the buffer stairway prediction module is performed on the TSUs, while the other three functions are executed on the OBUs. The track-side DAS is directly
connected with a TMS in order to receive the real-time monitored traffic state. The real-time traffic state is required to predict the traffic and estimate the buffer stairway for merging. The estimated buffer stairway is transmitted from the TSUs to OBUs at a regular time interval. The OBUs use the information to find proper merging advice according to a DAS-onboard architecture.
3.3. Buffer stairway prediction
The buffer stairway prediction module detects the available buffer stairway for merging. The buffer stairway consists of the buffer times between the trains in front and behind the freight train in the merging area. The methodological framework for the buffer stairway prediction is presented inFig. 5.
A train traffic model is constructed based on an event graph with dynamic arc weights. With the event graph, the individual and global train movements and interactions can be modelled for a given look-ahead horizon. The graph topology is built and updated based on the actual process plan (train orders, routes and timetable) and current positions of trains on the network. The running/ dwell/clearing time estimation module estimates dynamic arc weights for the event graph. Arc weights represent the estimated process (running/dwell/clearing) times which are computed based on the actual (predicted) traffic state and processed historical data. The real-time event time prediction module predicts event times over the event graph using a critical path method. The buffer stairway calculation module computes the blocking time stairways based on the predicted event times, and uses the predicted blocking time stairways to compute the buffer stairway for merging freight trains.
3.3.1. Traffic model construction
The train traffic is modelled as an event graph for events associated to trains that share tracks with the freight train. The model is an adapted version ofKecman and Goverde (2015a). In the event graph, each event is modelled by a node. An event refers to a train entering a block section. An example of the event graph formulation is presented inFig. 6. Denote the event graph by =G ( , )N A, where N is a set of nodes and A is a set of arcs. A includes two types of arcs: train arcs and headway arcs. For events belonging to the same train, the train arcs connect all events. The arc weights represent the process (running/dwell) times in the corresponding block sections. Arcs of type ‘headway’ separate the successive occupations of a block section or a station route by different trains. If two train routes have a block section in common, a headway arc is constructed between the corresponding events to prevent the second train from entering the block section (route) until it has been released by the first train.
The weights of arcs in the event graph are considered as dynamic values that depend on the actual traffic state. The weights of train arcs are equal to the running (and dwell) times in the block sections.Kecman and Goverde (2015a)use the TROTS data, combined with the real-time monitored traffic state information, to estimate the running/dwell times. The running/dwell time estimation is based on the method presented inKecman and Goverde (2015b)and introduced in Section3.3.2. TROTS is a train describer system in the Netherlands, which keeps track of train movements at discrete point in the network and registers the state of infrastructure elements such as track sections, signals and switches (Kecman and Goverde, 2013, 2015a). TROTS generates train number messages and infrastructure messages and logs them into data files. The following information on track occupations is contained: train number, train routes, km position of last section, km position of next section, and time stamp (section entering or releasing times), element type (section, signal, switch).
The weights of headway arcs are the minimum times that are needed to separate trains and avoid conflicts. The weight of a headway arc equals the clearing time and the release time to unlock the block of the front train plus the setup, sight and reaction time of the following train. The clearing times depend on train lengths and speeds. The method for estimating clearing times is presented in Section3.3.2. Note that the approach and running time that usually are included in a signal headway time are not included because the headway arcs are here defined between different signals. The other times are assumed as constant values in this paper. Given
=
G ( , ), the dynamics of railway traffic can be simulated with the following constraintN A
+ t , u v, N u v, ( , ) A.
v u uv (1)
Constraint(1)defines the precedence relation between the tail and the head event of an arc, where u v, represent two nodes,( , )u v is
an arc from u to v, uand vrepresent the event times of u and v and tuvis the weight of arc( , )u v.
The graph G is constructed for real-time event time prediction using a critical path algorithm over this graph. In the initialization phase, all the events are marked as ‘unvisited’. The initial event times are estimated with the minimum event time. That is =v vmin,
where vis the event time ofv Nand vminis the minimum value of v. In case that the node, such as a departure or arrival event,
has a scheduled time, the minimum event time equals the scheduled time in order to respect the timetable constraint. Otherwise, the minimum value is determined by historical data. The graph is constructed based on the given train routes, relative train orders and timetables. We assume that the actual route plans of all the involved trains are continuously provided by traffic control for the duration of the prediction horizon. The arcs in the event graph are fixed for each critical path computation. Each update of the actual plans or information from real-time operations, i.e., changing the relative order of trains, adding or cancelling trains, modifying train routes, and removing passed events, results in an update of the graph topology. The graph topology is continuously updated with new information over the rolling prediction horizon. With each update of train positions, the nodes describing events from the past and their incoming and outgoing arcs are removed from the graph, thus keeping the size of the graph stable within a certain time interval.
3.3.2. Running/dwell/clearing time estimation
The running/dwell/clearing time estimation is based on the local robust linear regression method proposed byKecman and Goverde (2015b). It estimates the running/dwell/clearing time of trains from the same line over a particular block. This work uses the same data source, TROTS data, for running/dwell/clearing time estimation.
The running/dwell/clearing time of a train depends on the current delay and peak-hours. Correlation between running/dwell/ clearing times with actual delays is determined using least trimmed squares robust linear regression (Rousseeuw and Van Driessen, 2006). A separate time series model is used to incorporate the effect of extended dwell times during peak hours. Departure delay is used as the main explanatory variable for running/clearing time estimation. Delayed trains may run with full speed in order to use the running time supplements to reduce the delay. On the other hand, trains running on time or ahead of their schedule may run at in a lower speed thus avoiding early arrivals and achieving energy efficient driving. Dwell times of trains in stations may depend on arrival delay. Since trains cannot depart from a station before the scheduled departure time, early trains have longer dwell times than scheduled in order to avoid early departures. On the other hand, trains with a positive arrival delay depart after a minimum dwell time in order to reduce the departure delay. Dependence of dwell time duration on peak-hours is used to explain the dwell time variability of delayed trains.
3.3.3. Real-time event time prediction
The event time prediction module predicts the event times of every node in the event graph. The module starts with the current traffic state (activity times and positions), and then goes through the event graph to predict the event times of every node in the event graph. A Breadth First Search (BFS) algorithm is adopted to traverse the graph G.Kecman and Goverde (2015a)adopted a Deepth First Search for the event time prediction since they focused on exploring how deep the delay can propagate in the network, while we use BFS algorithm since we need all related train states within a time horizon. BFS starts traversing from a selected node (source or starting node), traverses the graph by exploring the adjacent nodes (nodes which are directly connected to the traversed node), and
then moves towards the next node. The pseudocode of the event time prediction algorithm is presented inTable 1.
The input of the prediction algorithm is the event graph G and a set of observed nodes S with observed event times
v S
{ vmonitored, }, referring to the latest monitored block entry events. The main loop of the prediction algorithm starts with in-troducing an empty queue Q in line 1. The queue Q is used to store nodes that will be explored successively. Lines 2–6 inserts the observed nodes in S to Q and marks the observed nodes as ‘visited’. In the recursive search process (line 7–18), the algorithm traverses every node within Q. Each search loop starts with the first node of queue Q, represented as node v in the following text (line 8). The algorithm explores the adjacent nodes of v (line 9–16) and removes v from Q (line 17). Line 10–13 insert the adjacent nodes of v in Q and marked the nodes as visited if the nodes have not been visited yet. Line 14 computes the predicted weights of the neigbour arcs using the procedure described in Section3.3.2. Line 15 updates the event time by
+ t
max{ , },
w w v vw (2)
where vrefers to the predicted time of event v, w is the predicted event time of w, and tvw refers to the weight of the arc that
connects v and w. Eq.(2)ensures Constraint(1)is satisfied.The prediction algorithm repeats lines 7–17 until all the nodes within Q are traversed. The algorithm then returns the predicted times of all events.
3.4. Buffer stairway calculation
The buffer stairway calculation module identifies the buffer stairway for merging. Some notation is defined for later use (Table 2): For a train p P in block b Bp, the blocking time can be calculated as:
= tp b tp b t t t , b AB p b p b p b , BT , enter , run , sight , set p b, (3) = + + + tp bBT, tp b tp b tp b tp b , , enter , run , clear , release (4) where tp bset,,tp bsight, , and tp brelease, are considered as constant variables. tp benter, ,tp brun, , and tp bclear, are predicted/estimated by the real-time event
time prediction module and the running/dwell/clearing time estimation module. Note that in multiple-aspect block signalling or progressive speed signalling, like the Dutch NS’54 signalling system, the approaching distance may cover more than one block in rear of a block. Therefore we consider the set ABp b, of approaching block sections before block b along the route of train p. For a 3-aspect
block signalling system this set is just the previous block. Eq.(4)computes the end time for a block on the open track and merging blocks at junctions. In interlocking areas, when a route is set up, all track sections within the route are blocked at the same time. After the train has entered the route, several track sections within a block are released together after the passeage over a clearing point for partial route release, the end time of the last section in block b is computed as
= + + + tp b tp b t t t . b IB p b p b p b , BT , enter , run , clear , release p b, (5)
With Eqs.(3) and (4), the blocking time stairways of all involved trains are computed:
=
BTp {( ,b tBTp b,,tp bBT,),b Bp}, p P. (6)
Table 1
Pseudocode of the event time prediction algorithm. EventTimePrediction
Input: event graph G, set of observed nodes S with observed event times{ vmonitored,v S}
Output: event times
1: set Q as an empty queue 2: for each v S 3: mark v as visited 4: insert v to end of Q 5: v vmonitored 6: end
7: whileQ is not empty 8: set v to first element of Q 9: for each node w adjacent to v
10: if mark w is not visited then
11: mark w as visited 12: insert w to end of Q 13: end 14: compute weight tvw 15: w max{ ,w v+ tvw} 16: end
17: delete first element from Q 18:end
For a freight train f, the trains in front and behind the freight train in each block b pre f b, ( , )and post f b( , ), are known, since we assume that the train order is determined. The buffer stairway for freight train f along its route can be then computed as
= = BPf {( ,b tf b,tf b)}b b b , BP , BP f s f e , where = =
tf bBP, tpre f b bBT( , ),, and tBPf b, tpost f b bBT( , ),. (7)
In order to merge freight train f without causing conflicts, the following conditions must be satisfied
…
tf bBT, tBPf b,, and tBTf b, tBPf b,, b { , , }.bsf bfe (8)
3.5. Freight train movement prediction
The freight train movement prediction module aims at predicting the time-distance path of the freight train, so that the DAS can understand the freight train’s current and future movements. If the freight train has a DAS, it would make sense that it already has a trajectory optimization algorithm implemented for speed advice, which could then be used for predicting the time-distance path.
The train trajectory optimization algorithm first finds an optimal speed trajectory that maintains the timetable and saves energy consumption, then computes speed advice based on the optimized trajectory. The optimized trajectory provides detailed information about the train’s speeds, running times and distances in a look-ahead horizon, and therefore, can also be used for predicting the train movement. In previous work (Wang and Goverde, 2016, 2017), we developed a multiple-phase optimal control method for single-/ multiple- train trajectory optimization, which can be used for the freight train trajectory optimization and prediction. An extensive literature review of other models can be found inScheepmaker et al. (2017). A detailed process of implementing the method in a DAS system can be found inWang et al. (2017).
3.6. Merging window detection
The merging window detection module computes a feasible merging time window at the merging point. For the freight train f, the
earliest conflict-free merging time is the time at which train f merges into the line without being hindered by trains in front. The latest conflict-free merging time is the time when train f merges in without causing conflicts to the following trains. The slot between the
earliest and latest conflict-free merging time is called the feasible merging window at the merging point. There should be no conflicts with other trains if the freight train merges within the time window. In case that the buffer stairway is big enough to fit in the freight train’s blocking time stairway, it is always possible to find a feasible merging window.
A linear programming (LP) problem can be used to find the earliest/latest conflict-free merging time. The LP problem formulation is presented inEq. (9)–(14)for a single merging freight train f.
Table 2
Notation.
Symbols Definitions
f freight train that merges from side tracks;
P p, P is a set of trains that share some tracks with freight train f p, is an indicator of a train within P;
B bk, Bkis a set of block sections along the route of train k P { }f in the prediction horizon, b is an indicator of a block section; pre f b( , ) train which is scheduled in front of freight train f in block b;
post f b( , ) train which is scheduled behind freight train f in block b;
tk benter, time for train k P { }f to enter block b;
tk bset, time for setup signals before train k P { }f entering block b;
tk bsight, time for the driver to view the signal aspects before train k P { }f entering block b; tk brun, running time of block b for train k P { }f;
tk bclear, clearing time of block b for train k P { }f;
tk brelease, release time to unlock block b after train k P { }f leaving block b;
tk bBT, reservation time of block b for train k P { }f ;
tk bBT, end time of block b for train k P { }f;
tf bBP, earliest possible time for train f to reserve block b;
tf bBP, latest possible time for train f to release block b;
bfs merging block of freight train f b, B
f s f;
bfe last block of freight train f in the prediction horizon, b B f e f;
ABk b, set of approaching block sections before block b along the route of train k P { }f;
IBk b, set of track sections s within block b along the route of train k P { }f;
BTk blocking time stairway, set of blocking times for traink P { },f BTk={( ,b tk b k bBT,,tBT,), b Bk}; and
BPf
t min/maxf benter,fs (9) … t t b b b subject to f bBT, bBP, { , , },fs fe (10) … tf bBT, tbBP, b { , , },bfs bfe (11) = … tf b tf b t t t , b { , , },b b b AB f b f b f b fs fe , BT , enter , run , sight , set f b, (12) = + + + …
tf bBT, tf benter, trunf b, tf bclear, tf brelease, , b { , , },bfs bef (13)
= + …
+
tf benter, 1 tf benter, trunf b, , b { , ,bfs bef 1}. (14) In the LP problem formulation, tf benter, are the decision variables. tf bBT, andtf bBT, are provided by the buffer stairway prediction module.
trunf b, and tf bclear, are estimated with the same method presented in Section3.3.2. tsetf b,,tf bsight, , and tf brelease, are assumed constant values.
For the freight train f, the earliest conflict-free merging time can be found by minimizing the objective function(9), while the latest conflict-free merging time can be found by maximizing function(9). Eq.(9)refers to freight train f’s entering time of the merging block. Constraints(10) and (11)are to avoid conflicts by ensuring the freight train’s blocking time stairway stays within the buffer stairway for merging. Constraints(12) and (12)compute the blocking time for blocks on train f’s route. Constraint(14)
represents that the block entering time of the next block is equal to the block entering time of the current block plus the running time in the current block.
YALMIP and GUROBI were adopted for modelling and solving the LP problems in Matlab. If it is not able to find a feasible solution with the proposed LP model, feedback is sent to the TMS so that the TMS may need to adjust train orders/times to solve the conflicts, and in particular re-allocate the merging to the next train pair.
3.7. Merging optimization
The merging optimization module aims to find proper time/speed advice for drivers in order to optimize the freight train merging process. The merging window detection module produces a feasible merging window at the merging point. In order to avoid conflicts, the freight train should merge within the time window. With the predicted time-distance path of the merging freight train, provided by the freight train movement prediction module, we can check whether the freight train can merge within the feasible window or not. In general, there are three possibilities:
•
The predicted merging time is within the feasible merging window.If the predicted merging time is within the feasible merging window, the freight train shall not conflict with other trains. A suggestion to maintain the actual train plan can be presented to the freight train driver.
•
The predicted merging time is before the feasible merging window.If the predicted merging time is before the feasible merging window, the freight train will be hindered by the train in front and meet yellow/red signals. In order to avoid such a situation, a suggestion of delaying the departure can be sent to the driver if the freight train is waiting for departure (seeFig. 7(a)). Otherwise, an advice for slowing down can be presented to the driver if the train is running (seeFig. 7(b)).
•
The predicted merging time is after the feasible merging window.If the predicted merging time is after the feasible merging window, the freight train will hinder the following train. In order to
avoid such a situation, an advice of departing earlier can be sent to the driver if the freight train is standing (seeFig. 8(a)), and alternatively an advice of speeding up can also be presented to the driver if the train is running (seeFig. 8(b)).
4. Data analysis of real-word merging cases
In this section, TROTS data provided by ProRail (the TROTS log files of January 2018 for the Meteren Case and September 2017 for the Kijfhoek Case) are adopted to identify bottlenecks of merging freight trains in the Meteren and Kijfhoek area.
4.1. Meteren case
As shown inFig. 2, the freight trains from Betuweroute Meteren (Brmet) merge into a passenger corridor just before station Geldermalsen (Gdm) and head towards station Utrecht Centraal (Ut). The passenger corridor between Gdm and Ut is one of the busiest corridors among the Dutch rail network. Every half hour, five passenger train services, 6000, 6900, 800, 3500 and 3900, move in the direction from Gdm to Ut. The 6000 and 6900 are sprinters (local trains) while the 800, 3500 and 3900 are intercity trains. The
Fig. 8. Advisory information in case that the predicted merging time is after the feasible merging window.
6000 and 6900 are respectively overtaken by the 3500 and 800 at station Gdm.Fig. 9top presents a track occupation state of the merging area near station Gdm at a microscopic level. The freight trains merge from side tracks and pass signal 412 and 166, then go through station Gdm without stops. The intercities (800, 3500 and 3900) use the same station routes as the freight trains and do not stop at Gdm either. The sprinters (6000 and 6900) come from station Zaltbommel (Zbm) and Tiel Passewaaij (Tpsw) and stop at platform 3. The sprinters use different station routes than the freight trains and intercities. After station Gdm, freight trains share the same tracks with all passenger trains.
An example of the blocking time stairways and the time-distance paths for the five passenger train services is shown inFig. 9. For conflict-free operation, the boxes of a block section must not overlap. In order to let freight trains merge into the stream of the passenger trains, there should be enough buffer times between successive passenger trains to allow the merged freight trains’ blocking time stairways not to overlap with the passenger trains’ blocking time stairways (as the example shown inFig. 9). According to the TROTS data of January 2018, we found that about 1–2 freight trains merge into the passenger train corridor every day between 9 o’clock and 16 o’clock. As the statistical results show inFig. 10, 62% of the freight trains go between the train service 3900 and 6900, 12% between the 800 and 3500, 6% between the 3500 and 6900, and 6% between the 3500 and 3900 (the 6000 is not taken into account in the analysis because the 6000 come from Tpsw instead of Zbm). In order to know whether there is enough buffer between successive passenger trains for merging the freight trains, a statistical analysis of the buffer times at the block between signal 166 and the station switch at Gdm is made. The statistical results are presented inFig. 11andTable 3. The block section is the first block that the freight trains use after merging. The block is called the merging point in the following description. We observe the following.
•
Most of the freight trains (62%) merge after the intercity 3900 and before the sprinter 6900, which seems to be a smart choice since the 6900 are slower than the 3900 and are overtaken by the intercity 800 in Gdm. The scheduled headways between 3900 and 800 are around 10 min, which provides enough buffer for the freight trains to move in-between. The bottleneck of merging between the 3900 and 6900 is at the merging point around signal 166, where the buffer times between the 3900 and 6900 are relatively small (the median value is 266 s (4 min 26 s)).•
We did not observe freight trains merging between the 6900 and 800 in the data. It is not recommended to merge freight trains between the 6900 and 800, because the 6900 are overtaken by the 800 in Gdm and the buffer times between the two type of passenger trains at the merging point are too small (the median value is 78 s (1 min 18 s)).•
12% freight trains merge between the 800 and 3500. The buffer times between the 800 and 3500 at the merging point are relatively long (the median value is 534 s (8 min 54 s)). However, it must be noticed that the sprinter 6900 run between the 800 and 3500 after station Gdm. The bottleneck of merging freight trains between the 800 and 3500 occurs after Gdm.•
6% freight trains merge between the 3500 and 6900. The buffer times between the 3500 and 3900 at the merging point are long (the median value is 508 s (8 min 28 s)). But after station Gdm the sprinter 6000 run between the 3500 and 6900, which reduces the buffer stairway for merging freight trains. The merging bottleneck occurs after Gdm.Fig. 10. Passenger trains before and after merging freight trains.
InFig. 10, we observed that 6% freight trains merged between the 3500 and 6900 (2 times in one month). The 6900 are not scheduled after the 3500. There might be disruptions that changed the train orders before Zdm. InFig. 11, we observed some outliers below the first quartiles (lower bound of the boxes in the upper subgraphs). Those outliers represent short buffer times between successive trains. Such short buffer times are usually caused by delays and it raises challenges in merging freight trains with such short buffers.
In general, we can get a couple of conclusions:
•
Unlike the Amsterdam Westhaven case, it is not enough just to monitor one preceding passenger train at the merging point. Because the passenger train order changes at station Gdm and there are other passenger trains (6000) merging into the corridor. Instead, all related passenger trains must be monitored or predicted for better awareness of available buffer for merging.•
The bottlenecks of merging freight trains not only occur at the merging point, but also in other locations. Therefore, it is necessary to look further and check whether the buffer stairway between successive passenger trains is big enough for conflict-free merging.4.2. Kijfhoek case
FromFig. 2, it can be seen that the freight trains from Kijfhoek merge into the passenger corridor between Rotterdam Centraal (Rtd) and Dordrecht (Ddr). The corridor has two regular passenger train services, that move from Rtd to Ddr and use the same tracks as the freight trains: 2200 and 9200. The 2200 are intercity trains, which run every half hour. The 9200 are international trains, which repeat every one hour. There are also a few other trains running on those tracks, such as shunting trains and freight trains from Rtd. Their frequency is low, so this analysis does not take them into account.
Fig. 12demonstrates the track occupation state between Zwd and Ddr at a microscopic level. The freight trains merge into the stream of the 2200 and 9200 before station Zwijndrecht (Zwd), then go through Zwd and Ddr without stops. The freight trains use the same tracks as the passenger trains except that the 2200 and 9200 stop at platform 5 in Ddr, while the freight trains use different station routes and do not stop in Ddr. The blocking time stairways and the time-distance paths of the 2200 and 9200 are shown in
Fig. 12. Within one hour, passenger trains run in a sequence of 2200, 9200, and 2200.
Table 3
Statistic results about the buffer times between successive passenger trains at signal 166.
3900 ≺ 6900 6900 ≺ 800 800 ≺ prec 3500 3500 ≺ 3900
IQR [s] 65 78 72 78
median [s] 266 152 534 508
min [s] 128 -2 392 359
max [s] 387 308 670 650
According to the TROTS data of September 2017 (day time between 9 o’clock and 16 o’clock), there are 138 freight trains merging from side tracks into the passenger train corridor within one month. 40% of the freight trains merge between the train service 2200 and 2200, 12% between the 800 and 3500, 11% between the 9200 and 2200, and 25% between the 2200 and shunting trains (Fig. 13).Fig. 14andTable 4present statistical results of the buffer times between every pair of successive passenger trains at the merging point (the block between signal 1352 and 1326). The buffer time between successive 2200 is around 1739 s (28 min 59 s), between 2200 and 9200 it is around 923 s (15 min 23 s), and between 9200 and 2200 it is around 754 s (12 min 34 s). The buffer times provide quite large space for merging freight trains. Besides, the passenger trains run sequentially and their order do not change. That makes it easy to add one or more freight trains in the passenger traffic stream without causing conflicts.
We observe in some circumstances, more than one freight trains merging into the stream of two successive passenger trains, mostly between two successive 2200 (as the example inFig. 12). To merge conflict-freely, the buffer stairway between successive passenger trains must be big enough to fit in all the merged freight trains’ blocking time stairways. Meanwhile, enough headway must be kept between freight trains in order to avoid conflicts between freight trains. For an individual freight train, the buffer stairway for merging is the time slot between the train in front and behind, while the train in front and behind can be a freight train or a passenger train. It is necessary to know both passenger and freight trains orders ahead of time to predict the buffer stairway for merging.
5. Numerical experiments
This section selects four realistic merging freight train scenarios from two cases in the Meteren and Kijfhoek areas to illustrate the performance of the proposed algorithms. The four cases are: (a) a freight train merged between a 3900 and a 6900 in the Meteren area on 02-01-2018 (around 14:00 o’clock); (b) a freight train merged between a 3900 and a 6900 in the Meteren area on 07-01-2018 (around 14:00 o’clock); (c) a freight train merged between a freight train and a 2200 in the Kijfhoek area on 28-09-2017 (around 13:50 o’clock); and (d) a freight train merged between a 2200 and a 9200 in the Kijfhoek area on 02-09-2017 (around 10:10 o’clock). The proposed merging DAS algorithms are applied in the four cases to find the advised merging windows, which are then compared with the realized merging times in order to show how the proposed algorithms can help the merging process.
The EventTimePrediction algorithm from Section3.3is applied to predict the time-distance paths of trains around the merging area. The prediction is performed before the freight trains merge in the mixed-traffic corridors. The accuracy of the prediction relies
Fig. 13. Trains before and after merging freight trains.
on the process time estimation module. The (running/dwell/clearing) process time estimation includes two parts: off-line and on-line processes. The off-line process uses a set of training data for regression analysis. The training data set consists of train describer log files for one month of traffic in the two traffic areas. The data of hindered trains and conflicts are filtered out. The dependencies of process times on current delays, as well as the necessary percentiles to model the lower bounds of running, dwell and clearing times, are computed. For a detailed analysis on the performance of the off-line regression method, we refer toKecman and Goverde (2015b). The off-line regression results are adopted for on-line estimation of process times. With the predicted time-distance paths, the blocking time stairways of all involved trains are computed with the method from Section3.4. Meanwhile, the advised feasible merging windows are computed with the LP method given in Section3.6.
Figs. 15 and 16shows two Meteren cases, while FifuresFigs. 18 and 17correspond to the Kijfhoek cases. The feasible merging windows, as well as the predicted time-distance paths and the blocking time stairways for the four cases are presented on the left. The right plots present the comparisons of predicted paths (dashed lines) with the realized train paths (solid lines). The realized train paths are made with the recorded TROTS data. Different train types are represented with different colors: the sprinter trains (6900 and 6000) are in black, the intercity trains (3900, 800, 3500 and 2200) in blue, the international trains (9200) in green and the freight trains in red.
InFigs. 15 and 17, the freight train merged within the predicted feasible window and did not have conflicts with other trains in real-life. However, inFig. 16, the freight train merged after the predicted feasible window and affected the following spinter train in real-life. Similarly, inFig. 18, the freight train merged before the predicted feasible window and met a yellow signal after station Ddr. In theory, the conflicts can be eliminated if the freight adjust its movement in advance and merges within the suggested window. For the case inFig. 16, we can advise the freight train to move faster before the merging point in order to avoid such conflicts). For the case inFig. 18, we can advise the freight train to departure later (the freight train is standing still on Kijfhoek).
We compare the predicted event times with the realized times to analyze the prediction error by using the proposed event time prediction algorithm. The average/maximum prediction errors of the four cases are respectively, 18.60 s/79 s, 73.25 s/298 s, 16.42 s/ 57 s and 15.68 s/66 s. Big prediction errors occur in the case of a merging freight train in the Meteren area on 07-01-2018 (Case b). The realized data show that the freight train merged in too late and caused conflicts to the sprinter train behind (around 14:15 o’clock). The sprinter train met red signals before getting in station Gdm and got delayed. The delay was not predicted since the prediction model does not take into account the merged freight train. If the freight train merged in earlier, the passenger trains would not be hindered and the prediction error for this case would reduce. The computation times of the on-line prediction and merging window detection in the case studies are very short (less than 1 s). The proposed method is therefore suitable for real-time appli-cations with regular updates of current train positions.
Table 4
Statistic results about the buffer times between successive passenger trains at signal 1352.
2200 ≺ 2200 2200 ≺ 9200 9200 ≺ 2200
IQR [s] 117 99 135
median [s] 1739 923 754
min [s] 1548 733 507
max [s] 1930 1100 1008
6. Conclusions
This paper analysed the bottlenecks of merging freight trains in the Meteren and Kijfhoek area based on real-life data. An algorithm architecture was proposed for a connected DAS to compute time/speed advice for freight train drivers. The framework includes four parts: buffer stairway prediction, freight train movement prediction, merging window detection and merging opti-mization. The basic idea is to predict the traffic state and the feasible merging window regularly. With the predicted feasible merging window, proper advice can be presented to freight train drivers and help them smoothly merging in.
The proposed algorithm was demonstrated in four examples and compared with realized situations. The case study shows that the algorithm produces reliable merging windows. Application of the algorithm in real-time is possible due to its short computation times and reliable results. The approach can be used to different situations than the AftelApp that was focused on countdown advice for a standing train.
Future work will focus on the following three aspects. (a) The stochastic effects are implicitly considered in the (robust and adaptive) prediction process while estimating the running/dwell times of passenger/freight trains (Kecman et al., 2015; Kecman and Goverde, 2015b). Moreover, we explicitly compute the buffer time on top of the computed minimum headway time to the following and leading train by computing both the earliest and latest conflict-free merging time in the merging window detection: the
Fig. 16. Comparison of predicted paths (left) with realized paths (right) in Meteren area (07-01-2018).
difference is the buffer time. Cleary, the bigger the buffer time, the more robust is the merging movement. For very tight buffer times, the real-time train control becomes challenging and the situation may then be considered as not feasible, which could be reported back to the TMS. (b) This paper assumed that the passenger trains are not controllable. However, it would be more beneficial for the merging process if it is possible to present advice to all involved trains. To achieve that, advance traffic management algorithms are required with Connected DAS to all trains. (c) Presenting more comprehensive speed advice can assist drivers in a better way. An advanced train trajectory optimization method is required to achieve this target.
References
Albrecht, A., Koelewijn, J., Pudney, P., et al., 2011. Energy-efficient recovery of delays in a rail network. Aust. Transp. Res. Forum.
Bach, L., Gendreau, M., Wøhlk, S., 2015. Freight railway operator timetabling and engine scheduling. Eur. J. Oper. Res. 241 (2), 309–319.
Cacchiani, V., Caprara, A., Toth, P., 2010. Scheduling extra freight trains on railway networks. Transp. Res. Part B: Methodol. 44 (2), 215–231.
Cacchiani, V., Huisman, D., Kidd, M., Kroon, L., Toth, P., Veelenturf, L., Wagenaar, J., 2014. An overview of recovery models and algorithms for real-time railway rescheduling. Transp. Res. Part B: Methodol. 63, 15–37.
Caimi, G., Fuchsberger, M., Laumanns, M., Lüthi, M., 2012. A model predictive control approach for discrete-time rescheduling in complex central railway station areas. Comput. Oper. Res. 39 (11), 2578–2593.
Chen, L., Schmid, F., Dasigi, M., Ning, B., Roberts, C., Tang, T., 2010. Real-time train rescheduling in junction areas. Proc. Inst. Mech. Eng. Part F: J. Rail Rapid Transit 224 (6), 547–557.
Corman, F., DAriano, A., Hansen, I.A., Pacciarelli, D., 2011. Optimal multi-class rescheduling of railway traffic. J. Rail Transp. Plann. Manage. 1 (1), 14–24.
Corman, F., Meng, L., 2015. A review of online dynamic models and algorithms for railway traffic management. IEEE Trans. Intell. Transp. Syst. 16 (3), 1274–1284.
Corman, F., Quaglietta, E., Goverde, R.M.P., 2018. Automated real-time railway traffic control: an experimental analysis of reliability, resilience and robustness. Transp. Plann. Technol. 41 (4), 421–447.
Goverde, R.M.P., Bešinović, N., Binder, A., Cacchiani, V., Quaglietta, E., Roberti, R., Toth, P., 2016. A three-level framework for performance-based railway time-tabling. Transp. Res. Part C: Emerg. Technol. 67, 62–83.
Hansen, I.A., Pachl, J., 2014. Railway Timetabling & Operations. Eurailpress, Hamburg.
Kecman, P., Corman, F., Meng, L., 2015. Train delay evolution as a stochastic process. In: 6th International Conference on Railway Operations Modelling and Analysis-RailTokyo.
Kecman, P., Goverde, R.M.P., 2013. Process mining of train describer event data and automatic conflict identification. Comput. Railways XIII, WIT Trans. Built Environ. 127, 227–238.
Kecman, P., Goverde, R.M.P., 2015a. Online data-driven adaptive prediction of train event times. IEEE Trans. Intell. Transp. Syst. 16 (1), 465–474.
Kecman, P., Goverde, R.M.P., 2015b. Predictive modelling of running and dwell times in railway traffic. Public Transp. 7 (3), 295–319.
Kuo, A., Miller-Hooks, E., Mahmassani, H.S., 2010. Freight train scheduling with elastic demand. Transp. Res. Part E: Logist. Transp. Rev. 46 (6), 1057–1070.
Lagos, M., 2011. Cato offers energy savings. Railway Gazette Int. 167 (5).
Liu, L., Dessouky, M., 2017. A decomposition based hybrid heuristic algorithm for the joint passenger and freight train scheduling problem. Comput. Oper. Res. 87, 165–182.
Luijt, R.S., van den Berge, M.P., Willeboordse, H.Y., Hoogenraad, J.H., 2017. 5 years of dutch eco-driving: managing behavioural change. Transp. Res. Part A: Policy Pract. 98, 46–63.
Mazzarello, M., Ottaviani, E., 2007. A traffic management system for real-time traffic optimisation in railways. Transp. Res. Part B: Methodol. 41 (2), 246–274.
Montigel, M., 2009. Operations control system in the lotschberg base tunnel. Railway Tech. Rev. 2, 42.
Panou, K., Tzieropoulos, P., Emery, D., 2013. Railway driver advice systems: evaluation of methods, tools and systems. J. Rail Transp. Plann. Manage. 3 (4), 150–162.
Pellegrini, P., Marlière, G., Rodriguez, J., 2014. Optimal train routing and scheduling for managing traffic perturbations in complex junctions. Transp. Res. Part B: Methodol. 59, 58–80.
Pudney, P., Howlett, P., Albrecht, A., Coleman, D., Vu, X., Koelewijn, J., et al., 2011. Optimal driving strategies with intermediate timing points. Ph.D. thesis. International Heavy Haul Association.
Qu, W., Corman, F., Lodewijks, G., 2015. A review of real time railway traffic management during disturbances. In: International Conference on Computational Logistics. Springer, pp. 658–672.
Quaglietta, E., Pellegrini, P., Goverde, R.M.P., Albrecht, T., Jaekel, B., Marlière, G., Rodriguez, J., Dollevoet, T., Ambrogio, B., Carcasole, D., et al., 2016. The on-time
real-time railway traffic management framework: a proof-of-concept using a scalable standardised data communication architecture. Transp. Res. Part C: Emerg. Technol. 63, 23–50.
Rao, X., Montigel, M., Weidmann, U., 2016. A new rail optimisation model by integration of traffic management and train automation. Transp. Res. Part C: Emerg. Technol. 71, 382–405.
Rousseeuw, P.J., Van Driessen, K., 2006. Computing lts regression for large data sets. Data Min. Knowl. Discov. 12 (1), 29–45.
Scheepmaker, G.M., Goverde, R.M., Kroon, L.G., 2017. Review of energy-efficient train control and timetabling. Eur. J. Oper. Res. 257 (2), 355–376.
Talebian, A., Zou, B., 2015. Integrated modeling of high performance passenger and freight train planning on shared-use corridors in the us. Transp. Res. Part B: Methodol. 82, 114–140.
UITP, 2011. International association of public transport, a global bid for automation: Uitp observatory of automated metros confirms sustained growth rates for the coming years.
Ursavas, E., Zhu, S.X., 2017. Integrated passenger and freight train planning on shared-use corridors. Transp. Sci.
van Leijen, M., 2018. Netherlands saw plunge in rail freight traffic 2017. <https://www.railfreight.com/business/2018/03/02/netherlands-saw-plunge-in-rail-freight-traffic-2017/>(accessed March 2).
Wang, P., Goverde, R.M.P., 2016. Multiple-phase train trajectory optimization with signalling and operational constraints. Transp. Res. Part C: Emerg. Technol. 69, 255–275.
Wang, P., Goverde, R.M.P., 2017. Development of a train driver advisory system: ETO. In: 2017 5th IEEE International Conference on Models and Technologies for Intelligent Transportation Systems (MT-ITS). IEEE, pp. 140–145.
Wang, P., Goverde, R.M.P., 2017. Multi-train trajectory optimization for energy efficiency and delay recovery on single-track railway lines. Transp. Res. Part B: Methodol. 105, 340–361.
