description of decision support tool
TRANSCRIPT
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 1 | 85
Description of decision support tool
Deliverable D3.2 of project Fr8Rail II
Description of a decision support tool aimed at advanced Real Time Network Management and requirements for a demonstrator
Reviewed: yes
Project acronym: FR8RAIL II
Starting date: 01/08/2018
Duration (in months): 39
Call (part) identifier: H2020-S2R-CFM/OC-IP/CCA-201X-0X
Grant agreement no: 826206
Due date of deliverable: 31/08/2020
Actual submission date: 20/11/2020
Responsible/Author: Martin Joborn, RISE
Dissemination level: PU
Status: Revised after audit by JU
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 2 | 85
Document history
Revision Date Description
1 2020-08-31 First issue, sent to TMT of Fr8Rail II for review.
2 2020-09-17 Updated after comments from TMT. Final version. Sent to JU.
3 2020-11-06 Updated after comments from JU.
Report contributors
Name Beneficiary Short Name
Details of contribution
Martin Joborn RISE Editor of report, general contributor + Appendix A
Johanna Törnquist Krasemann
BTH General contributor + Appendix B
Birgitta Thorslund VTI General contributor
Sai Prashanth Josyula BTH Appendix B
Zohreh Ranjbar RISE Appendix A
Tomas Lidén VTI General contributor
Magnus Wahlborg TRV General contributor
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 3 | 85
Table of Contents 1. Executive Summary ................................................................................................................ 5
2. Abbreviations and acronyms .................................................................................................. 6
3. Introduction ............................................................................................................................ 7
3.1. Motivation ........................................................................................................................... 8
3.2. Outline ............................................................................................................................... 10
4. General concepts for an advanced real time network management demonstrator ........... 12
4.1. Scope and objective of demonstrator .............................................................................. 12
4.2. Actors ................................................................................................................................ 13
4.3. Components of a general demonstrator .......................................................................... 14
4.3.1. Digital Graph .............................................................................................................. 15
4.3.2. Deviation Handler (DH) .............................................................................................. 16
4.3.3. Train Management System (TMS) ............................................................................. 16
4.3.4. Virtual railway ............................................................................................................ 16
4.3.5. Driving Simulator ....................................................................................................... 17
4.3.6. Driving Advisory System (DAS/C-DAS) ....................................................................... 17
4.3.7. Yard Operations Planner ............................................................................................ 18
4.3.8. Demonstrator Management Tool .............................................................................. 19
4.4. Principal usage of demonstrator ....................................................................................... 19
4.5. Related work ..................................................................................................................... 21
5. Concrete proposal for demonstrator ................................................................................... 24
5.1. Proposed components ...................................................................................................... 24
5.1.1. STEG – Electronical graph .......................................................................................... 24
5.1.2. Disturbance management module (DMM) ............................................................... 25
5.1.3. EBICOS 900/Ebisim .................................................................................................... 25
5.1.4. BEST ........................................................................................................................... 26
5.1.5. VTI train simulator ..................................................................................................... 26
5.1.6. C-DAS/CATO ............................................................................................................... 27
5.1.7. Yard Coordination System (YCS) ................................................................................ 27
5.1.8. RANPLAN Classification planning tool ....................................................................... 28
5.2. Principal Use cases ............................................................................................................ 29
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 4 | 85
5.2.1. UC1: Set up demonstrator ......................................................................................... 29
5.2.2. UC2: Handle deviation in traffic ................................................................................ 29
5.2.3. UC3: Adapt yard planning .......................................................................................... 30
5.3. Development roadmap: Requirements and recommendations....................................... 31
5.3.1. A modular demonstrator ........................................................................................... 31
5.3.2. Data, computer environment and information security ........................................... 33
5.3.3. Modularity and automation ...................................................................................... 34
5.3.4. Usage requirements for training tools vs research tools .......................................... 34
6. Conclusions ........................................................................................................................... 36
7. References ............................................................................................................................ 38
8. Appendix A: Real time yard management: A case study about relation between yard operations and departure time ....................................................................................................... 40
9. Appendix B: A framework for systematic performance assessment of train re-scheduling algorithms for disturbance management and its application ......................................................... 57
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 5 | 85
1. Executive Summary In this report we outline a conceptual demonstrator for advanced real time network management for freight rail traffic. The focus is on the coordination between traffic control, train drivers and yard management, three essential parts in the real time management of a rail freight network. The intention is that the demonstrator can support multiple purposes, such as education and training, demonstrating research advancements, and enabling feedback between practitioners, system developers and researchers. The proposed demonstrator has a focus on the interaction between different systems and between humans using these systems, but also on the rail freight system perspective by the inclusion of the connection between the line and the yard. We present a generic architecture and propose existing components that could be combined to such a demonstrator. Thus, even though the demonstrator may seem complex and visionary, the existence of these components makes the realization of the demonstrator realistic. The development roadmap for the demonstrator proposes both a step-wise implementation plan of the complete demonstrator, as well as several partial packages that provide useful sub-demonstrators by themselves. The appendices of the report include contributions to the continued development of two of the components that are part of the demonstrator. Firstly, in order to also better understand the type of situations that yard managers need to handle in operations and what implications these have on the traffic on the line, a Swedish case study has been conducted and the results are presented in Appendix A. More specifically, the case study analyses the factors that influence the departure time deviation for freight trains and how these can be used for predicting the actual departure time. These predictions can be used in a decision support system for yard planning at larger marshalling yards. A conclusion is that no single factor can fully explain the departure time deviation, but many different factors contribute to it, like destination, time of day, train load, number of wagons on the yard, connection time for wagons, and connection time for locomotives. Secondly, to support the traffic controllers and dispatchers with an advanced decision support tool
for deviation handling, a selection of different functionalities and algorithms may be required. In
Appendix B, two different approaches for disturbance management are presented. Approach 1
(ALG1) is a heuristic, parallel algorithm, while the second approach (ALG2) is an exact algorithm
based on state-of-the-art commercial optimization software. In order to classify and evaluate
alternative algorithms for train re-scheduling and disturbance management, an assessment
framework is also proposed in Appendix B. Based on this framework, the overall strengths and
shortcomings of the two mentioned train rescheduling algorithms are assessed while applied on a
set of 30 simulated disturbance scenarios of various complexity. The results show that typically,
ALG2 obtained good rescheduling solutions for all 30 disturbances, but compared to ALG1, ALG2
is slow in obtaining solutions.ALG1 is good at quickly finding solutions with less passenger delays
while it is less effective when it is used to solve disturbances associated with an infrastructure
failure. The strength of ALG2 is its ability to reschedule the traffic during infrastructure failures. A
detailed presentation of the evaluation is found in Appendix B.
This deliverable concludes Task 3.2 of project Fr8Rail II, WP 3.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 6 | 85
2. Abbreviations and acronyms
Abbreviation / Acronyms Description
FRU Freight Rail Undertakings
IM Infrastructure Manager
MGB “Malmö Godsbangård”, the marshalling yard in Malmö, Sweden.
RTTP Real Time Traffic Plan, i.e. the operational timetable updated by the train controllers at the traffic centres. Includes all trains, shunting movements, track possessions for maintenance works, etc., and is updated according to deviations from (original) timetable.
TM Terminal Manager, the role responsible for the operations at a multimodal terminal.
YM Yard Manager, the role responsible for the operations at a marshalling yard.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 7 | 85
3. Introduction The present document constitutes the Deliverable D3.2 “Description of decision support tool aimed at advanced Real Time Network Management and requirements for a demonstrator” in the framework of the Shift2Rail IP5 project Fr8Rail II/WP 3, corresponding to tasks T3.2.2 and T3.2.3. The main purpose of T3.2.2 and T3.2.3 is to outline a demonstrator for advanced real time network management, with a specific focus on the conditions for freight rail traffic. Furthermore, this deliverable also presents some of the planned research work outlined in Deliverable D3.1 (Peterson et al., 2019), in particular regarding the identified research gaps that are related to computational support for real time railway traffic management1. The primary aim of this document is to outline a proposal for a demonstrator of selected concepts and tools supporting advanced real-time railway network management. The starting point for the demonstrator is that there already exist several components and decision support tools that are aimed to support real time planning and control in the railway area in different ways. In particular, Trafikverket (the Swedish Transport Administration) has developed tools for their own internal use, or supported development within the research community, as part of their strategy to enable an increased digitalization and improved operations. Some components and tools are already used operationally in production, while other are research prototypes. Several of the components in focus are either developed without the possibility to be tested and demonstrated in a practical context, or they are used separately from other related components. Hence, by enabling demonstrations of such components in an integrated setting, they would form a more complete demonstrator for Real Time Railway Network Management, capturing the interplay between different roles and support systems. Performing an efficient real time network management of freight rail traffic requires an efficient coordination between several actors that are spread over different organizations. Data sharing between these actors and organizations is essential to achieve an improvement in the coordination. Therefore, also the demonstrator includes several actors that are spread over different organizations. Hence the demonstrator can support studies on how to improve the coordination between these actors and organizations, which is an important aspect. Sharing relevant types of data is consequently also necessary in order to make such a demonstrator useful and relevant, as illustrated by Figure 1.
1 Please note that work related to the research gaps identified in D3.1 will also be presented in deliverables D3.3 and D3.4 from the Fr8Rail II WP3 project.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 8 | 85
Figure 1: Value and levels of decision support with shared data. Source: Trafikverket.
The real time network management demonstrator proposed in this document is a “vision”. This document proposes a roadmap for future development, including requirements for such a demonstrator. The requirements are of different form: the scope of a demonstrator for advanced real time network management of freight rail traffic and requirements on the components that such a demonstrator should include. We also suggest existing software components to include in the demonstrator. These components are of different maturity level. Some of them are already in use in operations at Trafikverket, while other components are modular research prototypes for supporting decision-making during operations, including disturbance management. In D3.1, research gaps related to some of the components (research prototypes) were identified, and this document also provide input to cover these research gaps. In the next section we will further motivate the focus and intention of the proposed demonstrator.
3.1. Motivation As mentioned in the introduction, the proposed demonstrator includes and combines several important operational activities in real time network management of a rail freight transport system: train driving, train dispatching including deviation handling and yard management and – in particular – the communication and coordination between the actors involved. Chapter 6, 11 and 12 of the Deliverable D3.1 (Peterson et al. 2019) discussed the potential benefits and challenges of employing decision support tools aimed at advanced Real Time Network Management and the recent development in the area. The demonstrator described in this
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 9 | 85
document has multiple purposes, like education and training, demonstrating research advances, getting feedback between practitioners and developers and researchers, etc. The needs that motivate the demonstrator include:
• Need for better coordination and improved understanding of each other’s work situation among
train drivers, traffic controllers and yard managers.
• Need for testing and evaluation of new modules, systems and concepts in realistic environments.
• Need for evaluation of automation in realistic settings.
• The introduction of system-changing systems such as ERTMS or new TMS-systems.
• Possibilities to lift prototype systems to higher TRL-levels without making field experiments.
• Need for education and training in realistic settings.
• Need for creating a “network management perspective” of the railway operations with better
coordination between yards and lines, in contrast to separating line dispatching, train driving and
yard operations from each other.
• Improved training possibilities to handle different kind of deviations.
D3.1 also mentioned the need to discuss what kind of support and automation that is motivated in different situations suggesting a simple distinction between (1) “normal” conditions, (2) smaller disturbances and (3) larger disruptions, where small disruptions are defined as deviations that the infrastructure manager can decide about by themselves, while the RU must be involved in the decisions about larger disruptions. Figure 2 illustrates the distribution of deviations from the scheduled departure time for freight trains from Malmö in 2019 (see Appendix A for more details). The median is that trains depart 4 minutes before scheduled departure time, 47% of the trains depart more than 5 minutes before scheduled departure and 23% depart more than 5 minutes after scheduled departure, and 30% of the departures deviate 5 minutes of less. This shows that a frequent occurrence of smaller deviations may be considered “normal conditions” in some contexts, in particular for the rail freight traffic. Thus, it is extremely important that there are good possibilities to educate, train, evaluate and improve the railway system’s ability to handle the traffic that is not “perfectly on time”.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 10 | 85
Figure 2: Distribution of departure times from MGB, divided in 5-minute intervals. Left y-axis is number of departures, right y-axis is percent of departures.
Since real-time rail network traffic management is a complex interplay between several organizations, even small but frequent deviations may result in a significant extra workload for the responsible traffic controllers, traffic information staff as well as for train drivers, yard managers and transport managers. A related aspect is the importance of education and training to be able to master the different professions and maintain a strong, competent work force within each organization. By enabling platforms and tools for evaluating and demonstrating how these roles interact and how different functionalities can support the different roles we can gain an increased knowledge on how to move forward with the development (organizational as well as technical) in this area.
3.2. Outline This document presents the work carried out within the mentioned two tasks T3.2.2 and T3.2.3 of WP3 of project Fr8Rail II. First, we present a more general overview (in chapter 4) of the context the demonstrator is targeting. The actors and the application of the demonstrator is described along with its building blocks, which we denote components. The components are in Chapter 4 described in generic terms, including a description of other relevant work in Chapter 4.5, while in Chapter 5 there is a proposal for a selection of (existing) components that could be included in a demonstrator implementation. The demonstrator and its usage are described on a high-level, aiming at describing how the components of the demonstrator function together rather than describing the details of each component (which are described in other referenced sources of
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 11 | 85
information). Chapter 5 is concluded with a proposed roadmap for the development of the demonstrator. In the work of T3.2.2 and T3.2.3, we have also had a particular focus on functionalities and components that could support real-time re-scheduling of railway traffic during delays and other situations when the trains deviate from the timetable. Those components are referred to as “Deviation Handler” and “Yard operations planner”. As mentioned in section 3.1, many different situations and scenarios occur during “normal” railway operations and handling of freight trains that deviate from the originally planned timetable is very common. In order to also better understand the type of situations that yard managers need to handle in operations and what implications these have on the traffic on the line, a Swedish case study has been conducted and the results are presented in Appendix A. More specifically, this case study analyses the factors that influence the departure time deviation for freight trains and how these can be used for predicting the actual departure time, which can be used in a decision support system for yard planning at larger marshalling yards.
In order to support the traffic controllers and dispatchers in situations like the use cases of the
demonstrator describe, a selection of different functionalities and algorithms may be required. In
order to classify and evaluate alternative algorithms for train re-scheduling and disturbance
management, a framework is proposed in Appendix B. This framework is also applied to evaluate
the performance of two alternative disturbance management approaches on a set of 30 different
disturbance scenarios in a Swedish setting. The results of this performance evaluation are also
presented in Appendix B.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 12 | 85
4. General concepts for an advanced real time network management demonstrator
In this chapter we make a conceptual description of the demonstrator and its usage. The scope of the demonstrator is outlined together with the actors and roles that are involved. The demonstrator consists of components that by themselves represent separate systems that are often referred to in the railway business or research. The scope of these components is described as well as how the components are connected to each other in the demonstrator. The chapter is concluded by a review of related work.
4.1. Scope and objective of demonstrator As described in the introduction, there are several different kinds of needs that motivate the development of the demonstrator. As mentioned, the demonstrator consists of several components, of which some have a purpose of their own while others are modules intended to be used in an integrated environment. By enabling an integration of the related components, their application can be studied and analysed in a more realistic setting. Furthermore, their full potential as well as possible shortcomings, can also be evaluated and discussed with developers and potential users. Operations of freight rail traffic is the focus of the demonstrator. The demonstrator includes traffic control, train driving and yard management – three important activities in freight rail traffic management:
• Traffic control and handling of deviations from the original timetable is enabled, including the
traffic controllers’ construction of new real time traffic plans with and without advanced decision
support tools. This also includes the communication between traffic control and train driver in case
of deviations.
• Train driver simulation and training is enabled by providing a simulated environment including
interaction between the driver, the train and potential driver advisory systems (DAS), the signalling
system and traffic controller(s).
• The coordination between line planning and yard planning, in particular in case of deviations from
the original timetable, by decision support and information sharing between actors.
The demonstrator can also be used for studying and simulating other kind of railway traffic, but since freight traffic is in focus, this motivates e.g. that operational yard planning is included while passenger behaviour is beyond the scope of this demonstrator. The main objectives of the demonstrator are to serve as a platform and environment for:
• Training, education, process development and testing of components in a larger setting, supporting
communication and interaction between researchers and practitioners.
• Evaluating the application of decision support tools for real time traffic management like deviation
handling, line planning, train driving and operational yard planning in a realistic setting, including
the interaction with surrounding systems and actors.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 13 | 85
• Demonstrating for domain experts (traffic controllers, yard managers, train drivers) research
concepts and prototypes in a realistic setting.
• Supporting research related to e.g. the interaction between system actors (train drivers, traffic
controllers) and complex systems.
The structure of the proposed conceptual demonstrator and its components is described in more detail in the following chapters.
4.2. Actors The demonstrator includes the following actors, that are essential in performing freight rail traffic: Traffic controller: A traffic controller2 (TC) monitors the traffic, identifies deviations from the current real-time traffic plan (RTTP), detects and resolves potential conflicts in cooperation with the train drivers by re-timing and re-ordering trains as well as allocating alternative tracks and platforms to enable re-scheduled meetings and overtakings and synchronize passenger transfers. A special role for a traffic controller is to coordinate with the Yard Managers about arrivals and departures to/from yards. In many occasions (at least in Sweden) a dedicated traffic controller is responsible for the disposition and track allocation planning at the arrival and departure yards of larger marshalling yards. Train Driver: The train driver serves as the driver of a train, which also means being responsible for safety in connection with the train journey. The train must be driven safely and at the right speed. The train driver coordinates with the traffic controller indirectly via the signaling system (controlled by the traffic controller) and more directly via a phone or via a connected driver advisory system. Yard Manager: The yard manager (YM) is responsible for the marshalling activities at a major marshalling yard. The YM can be from a separate organization (not the same as the IM nor the FRU). The YM coordinate all marshalling activities within the yard, also if the wagons and transports handled at the yard belong to several FRUs. One important task of the YM is to control the activities for dissembling arriving trains, sorting wagons, and building departing trains. Part of the yard is a shared resource between the line and the yard, the arrival and departure yard, and these are often controlled by a traffic controller from the IM. Therefore, the coordination between the YM and TC is important to achieve smooth operation of both yard and line. For more information about the YM-role, see (Gestrelius, et al., 2018). Demonstrator supervisor: The Demonstrator supervisor (DS) is a special actor in the demonstrator. The DS is leading the usage of the demonstrator but is not part of the activities and concepts that should be demonstrated or evaluated. The DS is responsible for setting up the scenario that is to be used in the demonstration. The DS can also interact with the demonstrator and control the events, like introducing a disturbance in the infrastructure or in the traffic. The DS
2 The role denoted ”traffic controller” in this document is often denoted as train dispatcher or train traffic controller. The exact tasks for this role may differ between countries.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 14 | 85
can also act as a proxy for roles and actors not included in the demonstration and provide information that these should supply. There are other roles that are of relevance for the real time network management that are considered as out-of-scope in the proposed demonstrator. These excluded roles are e.g. the operational control of the FRUs, the operations control for maintenance and power regulation, other staff on trains and yards.
4.3. Components of a general demonstrator In this section we make a general description of the components of the demonstrator and their purpose. As noted above, there already exists several implementations of suitable components, and in Chapter 5 we propose existing components that could be included in an implementation of the demonstrator. In actual implementations, the distinction between the components of the demonstrator can be somewhat different than how we describe them here. The functionality of several (generic) components can be included in one component in an actual implementation, or one generic component may be divided into several other components. As an example, the components “Digital graph” and “Deviation handler” might be considered as modules of a modern TMS (Traffic Management System), but we describe them here as separate entities. The reasons for doing so are that few such tools have been put into practical use, but that they are recognized as an important improvement area and therefore actively studied by both researchers and practitioners. Consequently, the demonstrator setup should support structured experimental studies of the functionality and integration of Digital graphs and Deviation handlers into the working environment of traffic controllers. A demonstration may include just a few of the components/actors or the complete demonstrator. It is also possible to either make a stepwise implementation or to separate the complete demonstrator into separate units, as explained in the development roadmap (see section 5.3).
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 15 | 85
Figure 3: Generic components of the demonstrator and the actors.
4.3.1. Digital Graph The planning work with the Real Time Traffic Plan (RTTP) that traditionally is done on paper is transferred into a computerized environment with the introduction of the Digital graph. The purpose of the Digital graph is to be the authoritative source for the RTTP, which includes:
• To be the master planning tool for operational planning and control of rail traffic on the lines; the
Digital graph is the planning tool for traffic controllers for keeping the RTTP up-to-date.
• To visualize the RTTP for an appropriate time frame into the future, typically one or several hours
(depending on traffic intensity, geographic area and user selection), as well as the possibility to
view historic time to show the background to the current traffic status.
• To alert the user of situations that calls for action, such as conflicts in the RTTP regarding timings,
track allocations etc.
• To enable re-planning actions for train paths, track possessions and all types of other activities that
request access to the railway infrastructure.
• To be a common information source when communicating the current RTTP and changes to it to
all involved stake holders (train operators, train drivers, traffic information, maintenance
contractors, track workers, other traffic controllers, etc.).
• To enable automatic execution of route setting commands via the TMS or interlocking systems.
• To store the different RTTP changes and archive the final RTTP version including the outcome of all
traffic and track activities for future reference and post-execution tracing, replay and analysis.
The Digital graph may also include presentation and follow-up of performance indicators and operational statistics that help the traffic controllers to monitor the usage of the railway system (both past, current and planned outcome).
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 16 | 85
4.3.2. Deviation Handler (DH) The Deviation handler (DH) serves to support the real-time dispatching and train traffic control and it has
three main purposes:
• To detect deviations from the current real-time traffic plan (RTTP).
• To detect actual and potential conflicts (Conflict detection, CD) where a conflict refers to that two
(or more) trains are scheduled to physically occupy or reserve the same track resource during
overlapping time periods. It may be any kind of physical network resource such as a
switch/crossing or a complete platform track. A conflict is detected when the train path of two (or
more) trains are violating the constraints imposed by the signaling and automatic train protection
system.
• To resolve conflicts (Conflict Resolution, CR) which in the base case is done by means of
1) re-timing trains (adjusting departure, arrival and running time),
2) performing local re-routing (allocating alternative tracks and platforms),
3) re-ordering trains (altering the order in which trains are scheduled to possess a specific
resource. The result of the conflict resolution is a new RTTP (or a set of alternative RTTPs).
Depending on how the DH module is supposed to be used in the train traffic control process, the
new RTTP is either selected by the DH based on some criteria or it is suggested to the human
decision-makers (i.e. traffic controllers) who may accept it with/without modifications. In
Appendix B, some examples of how a DH module in different ways can be used to assist train
traffic control, are presented.
4.3.3. Train Management System (TMS) The TMS is the communication interface to the physical railway infrastructure, via the interlocking, object controller and train control systems. The TMS supervises a large geographic area and communicates with several interlocking systems, which can be of varying types (relay based, computerized, radio blocking etc), possibly from different manufacturers. The standard features of a TMS are:
• To show a logical view of the track layout and display the current (or last known) situation of all
object statuses, route settings and track occupancies.
• To partition the complete train management area into smaller traffic control areas, which defines
the responsibility of different traffic controllers.
• To correctly assign identification to trains, other vehicles, work forces etc (including necessary
operational information), and to map commands as well as interlocking events to these id’s.
• To receive route setting and object control commands, either as manual input from the traffic
controllers or from preprogrammed automatons or a Digital graph tool, and to transform/transmit
these commands to the appropriate subsystems / interlockings.
Here we assume a centralized traffic control, where the TMS controls all interlockings directly. Decentralized setups are also possible, in which case communication is made with local dispatching centers that in turn will take care of interlocking, object and train control.
4.3.4. Virtual railway A virtual railway is a digital representation of the railway system and its state, where interlocking systems are simulated at the individual level and connection can be made to arbitrary traffic management systems. Features of a virtual railway can be for example to simulate:
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 17 | 85
• Railway infrastructure’s behavior with respect to trains running in the system,
• infrastructure’s response (signals and switches) to traffic controllers’ commands,
• driving behavior, traction and braking,
• temporarily speed reductions with restrictions for speed, brake effect and traction.
The purpose of a virtual railway is simulating the performance and operations of different parts of the system which is useful when for example:
• Educating train controllers or operators,
• testing train management systems,
• testing or evaluating infrastructure designs,
• testing configurations of operation site.
The simulation system Best at Trafikverket is a basis for such a virtual railway, and with few extensions it
could provide the needed functionality for the demonstrator.
4.3.5. Driving Simulator A driving simulator is simulating the driving environment of a vehicle (i.e. a train in this context). This
commonly includes the driver seat, instrument cluster and a view of the situation outside the vehicle. There
are several levels of fidelity and depending on the objective, a more advanced (e.g. moving base, several
screens) or less advanced (e.g. transportable) simulator is preferable. The main advantages of using driving
simulators compared to real driving environments are safety, cost efficiency and repeatability. Features of
a train driving simulator are for example simulation of:
• Train and track characteristics,
• signal systems,
• specific rare events,
• weather or other external factors.
Examples of common purposes of using a driving simulator are:
• Training or education,
• research on driving behavior,
• testing of systems or infrastructure.
For the demonstrator, a train driving simulator can be included to enable an interaction between the train
driver and the rest of the railway system.
4.3.6. Driving Advisory System (DAS/C-DAS) A train driver can have different kinds of supporting systems. In the demonstrator we include a
driving advisory system (DAS). An important functionality of the DAS is to provide a
communication channel between traffic control center and the train driver on which the driver is
informed about changes in the traffic plan. This means that the DAS-system should be connected
to the traffic control, so that it is a connected driving advisory system (C-DAS). Scheduling, routing
and speed restriction updates are communicated to the train in real time, while information from
the train enhances traffic regulation decisions at the traffic control center. Advantages of C-DAS
include fewer stops at red signals, improved recovery from disruption, improved train regulation,
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 18 | 85
lower energy consumption, reduced wear-and-tear on rolling stock, improved driver guidance and
incident investigation, and reduction in operational incidents (Barrow, 2018). The C-DAS has the
following main purposes:
• To provide a communication channel to the train driver regarding updates in the real time traffic
plan.
• To support the driver in driving the train in a way that is both energy efficient and enhances
punctuality.
• To support the train driver with relevant traffic information.
• To give feedback to the traffic controller that train drivers can follow the RTTP.
More information about DAS-systems can be found in e.g. (Panou, K., et al. 2013; Gotelli, G., et al.
2020).
4.3.7. Yard Operations Planner Taking the yard into consideration is important to get a complete network management
perspective for rail freight traffic. The activities at a major marshalling yard are complex and
resource intensive. A large marshalling yard consist of several subyards. The arrival and departure
yards are crossways of the interests of several actors in the rail freight system: The traffic
controllers of the IM, the Yard Manager of the yard operating company, a possible Terminal
manager of a multimodal terminal, the operational lead and the train drivers of the FRU:s are all
dependent on that the track resources of the arrival/departure yard is efficiently planned and
operated. On the other hand, the marshalling operations and the usage of the classification bowl
is internal to the yard operating company.
One of the major operations at a larger marshalling yard is classifying the wagons into departing
trains by pushing the wagons over the hump into the classification bowl. These marshalling
operations are tightly connected to the status of the arrival yard since many of the resources are
in common: tracks, locomotives, personnel and wagons. Therefore, the classification bowl
planning is interlinked with the planning of the arrival and departure yards.
More information about activities and planning at a marshalling yard can be found in
(Himmelspach, R., et al. 2017; Gestrelius, S., et al. 2018).
The Yard operations planner is a coordination and decision support tool that enhances information
sharing between the actors and provides decision support in the operational planning of the yard
resources and activities. A Yard operations planner provides the following features:
• A platform for information sharing regarding train arrivals and departures to/from the yard.
Information can be shared between different actors (Traffic controller, Yard Manager, Terminal
manager, Train driver, transport operations center) from several organizations (IM, FRU, Yard
operator, Terminal operator).
• A planning tool and decision support for track assignment of the yard. Track assignment includes
the usage of each track (which train or wagons that are planned to be placed on the track) and the
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 19 | 85
start time and end time for the track usage. The track assignment can be made for both arrival and
departure yards as well as for the classification bowl.
• A planning tool and decision support for other yard resources like staff and locomotives. • A tool for estimating the ready time of the trains (i.e., the time when a train is ready for departure).
From that, the actual departure time can be estimated (which may be before or after the scheduled
departure time).
• A planning tool for the movements at the yard, like roll-in, roll-out, pull-backs and other shunting
activities.
Since very many of the deviations in the rail freight traffic originates from that freight trains depart
outside the scheduled timetable slot (both early and late), it is essential that this estimation is
made as god as possible in order to achieve higher predictability of the freight traffic. In Appendix
A, we present the results from a study of which factors that significantly influence the departure
time deviations of particularly freight trains, and how the departure time can be forecasted.
4.3.8. Demonstrator Management Tool The demonstrations are controlled via a Demonstrator management tool (DMT). This component is not a part of the demonstration per se (i.e. not part of the scenario that is demonstrated) but is used by the Demonstrator Supervisor to set up and control the demonstrated scenario. The DMT is used to turn components on and off, select scenario and control scenario progress. In case a scenario need input from an external actor (not included in the demonstrator) is controlled from the DMT. The Demonstrator management tool is also used to control the time in the demonstration (virtual time), in some scenarios it is needed to speed up sections of the elapsed time. Since the DMT is not part of the actual demonstration, it is not included in Figure 3.
4.4. Principal usage of demonstrator In section 4.1 above, we described what the demonstrator primarily is intended to be used for and its benefits, while in this section we make a high-level description of how the demonstrator can be used. The demonstrator can serve multiple purposes and hence be used in various ways by different users, and the objective with the usage descriptions in this document is to give an idea of its principal use without being complete in the descriptions. A demonstration follows a scenario which is defined by the user. There can exist many different scenarios. A scenario includes the “cast and outline” of what event that triggers the demonstration and the rules for how the situation should evolve in a demonstration. The content of the scenario also depends on the intention of the demonstration. The scenario includes a specification of the demonstration setup regarding e.g.:
• The selected part of the modelled railway network and yards, including the operational
prerequisites and constraints.
• The railway traffic to be included, including the train characteristics and their timetable.
• The components and actors to be included.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 20 | 85
• The deterministic or stochastic source of event(s) that may trigger and affect the demonstration.
Below is an outline of a typical usage of the demonstrator. In practice, the usage of course depends on the selected scenario and the intention of the demonstration.
1. Demonstrator supervisor uses the Demonstration management tool to select and initiate
the scenario that is going to be used in the demonstration. The Demonstrator supervisor
turns components on and off according to the needs of the scenario and instructs the
actors in the demonstration. The Demonstrator supervisor initiates the Virtual railway
with the relevant railway traffic.
2. The Traffic controller uses the Digital Graph to set routes in the TMS. The Virtual railway
responds to the route-setting in an appropriate way. In particular, the routes are set for
the train that the Train driver uses in the scenario.
3. A Train driver uses the Driving simulator and starts driving a freight train from one
departure yard to one arrival (marshalling) yard.
4. A disturbance occurs at an intermediate station, leading to that the freight train
(operated by the Train driver in the Driving simulator) becomes delayed. The disturbance
can be e.g. that a railway switch in the Virtual railway does not respond, leading to that
the heavy and long freight train gets a red light which forces it to slow down and make a
full stop. The fault is solved after a few minutes, but the train is by then already
significantly delayed.
5. The Traffic controller observes the delayed freight train in the Digital graph. The traffic
forecast includes one or more unresolved conflicts caused by the delay.
6. The Deviation handler computes a proposal for a new RTTP (Real Time Traffic Plan), i.e. a
revised operational timetable, with conflicts solved in a way that optimally handles the
deviation to avoid knock-on effects and to restore the timetable for the affected train(s).
The proposed RTTP is communicated to the Traffic controller via the Digital graph.
7. Using the Digital graph, the Traffic controller assesses the new RTTP proposed by the
Deviation handler and may make minor modifications to it (using the Digital graph).
8. The Traffic controller accepts the new RTTP in the Digital graph.
The new RTTP might e.g. include some new overtakings by passenger trains and that one
or more freight train arrivals to the destination yard is delayed.
9. The Train driver is informed about the new driving plan via the Driver advisory system.
Train driver continues to drive the freight train in the Driving simulator.
10. The Digital graph sends information about the updated RTTP to the Yard operations
planner. The Yard Manager is notified about the delayed arrival to the marshalling yard.
11. The Yard Manager uses the Yard operations planner to adjust the track allocation of the
yard and calculate new yard operation plans that fit to the updated RTTP.
12. The Yard manager calculates if the updated RTTP gives any implications also to the
departing trains, as a result from that arriving wagon are delayed. Departure times are
estimated in the Yard operations planner. Any deviating departure times are
synchronized between the Yard operations planner (Yard manager) and Digital graph
(Train controller).
13. The scenario continues until Demonstrator supervisor is satisfied...
14. Demonstrator supervisor ends the demonstration.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 21 | 85
The scenario most likely includes several other trains than the one performed by the Train driver. The other trains are simulated within the Virtual railway and gives input to the TMS and to the Digital graph and might interact with the train performed by the Train driver in the Driving simulator. The other trains can also be rescheduled by the Traffic controller in the Digital graph, and also be shown to the Train driver in the Driving simulator. There are several variations to this basic scenario. For example, an important variation in the freight traffic setting is trains running ahead of the planned timetable. This may be initiated by the Train driver asking for permission from the Traffic controller to depart from origin yard ahead of time, or that the freight train runs faster than its scheduled timetable. Some components may be turned off in a scenario. For example, in some scenarios the connection to the yard can be disregarded (no Yard operations planner/Yard Manager), or all trains can be simulated by the Virtual railway (no Driving simulator/Train driver). The exclusion of a component can also be part of the evaluation of a scenario. For example, the exclusion of the DAS-component may be used to evaluate the effect of having the DAS and how communication with Train driver should be performed, and the exclusion of the Deviation handler may be used to evaluate the value that the Deviation handler brings.
4.5. Related work In order to move forward with the technology developments, it is critical to evaluate the
implications and benefits of new concepts, tools and integrated systems before these are put into
practice. A mentioned above, one purpose of the conceptual demonstrator for advanced real-time
traffic management proposed in this project is to enable experimental evaluations and
demonstrations of different components for supporting train traffic management, with or without
a human in the loop. A second purpose is to allow training and study the interaction between
humans as well as humans and the supporting systems. A number of projects and initiatives have
similarly aimed at proposing, developing and using demonstrations. Below we have summarized
the focus and scope of related work in some of the most recent and related projects and initiatives.
The demonstrator includes several components that are decision support systems on their own,
and the referenced work includes both other real-time traffic management demonstrators as well
as references to some related components. However, the intention of the related work description
is not to give a complete overview of references that are related to the components of the
demonstrator, but to a few of the most relevant.
The EU-project ON-TIME (Optimal Networks for Train Integration Management across Europe),
that was running during 2011-2014 (TRIMIS, 2020), aimed to develop, apply and demonstrate an
integrated set of concepts, procedures and algorithms with the objective to maximize the available
capacity on the European railway network and alleviate network bottlenecks. The project focused
on concepts and solution approaches to improve both the timetabling as well as the real-time
traffic management. Regarding the latter perspective, focus was on real-time conflict detection
and conflict resolution during traffic disturbances. Tests were performed using two different re-
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 22 | 85
planning algorithms (referred to as the ROMA approach and the RECIFE approach) in three
different case studies (Quaglietta et. al., 2016): A part of the East Coast Main Line in the UK, the
Dutch corridor Utrecht–Eindhoven–Tilburg–Nijmegen as well as a stretch of the Iron Ore line
corridor between Narvik–Svappavaara at the border between Sweden and Norway. The first two
case studies focused on minimizing delays in the mentioned passenger traffic lines, while the
Swedish case study involved mixed traffic on a single-tracked line where the freight traffic
dominates and there are significant limitations on where the trains can meet (and overtake). In
order to enable the demonstrations and tests, a demonstration platform was developed. The
platform consists of a webb-based service-oriented architecture connecting a set of stand-alone
modules using a standard railML interface for the input/output data of the modules. In the tests,
the simulation environment HERMES (Graffica, 2020) simulated the railway network and traffic
movements, while the two different algorithms re-scheduled the trains in a closed-loop manner
with no human interaction. That is, the simulation involved no human decision-making regarding
train driving and train dispatching. See (Quaglietta et. al., 2016) for further details.
In the same project, an interview study for the Swedish case was conducted, see (Hellström et. al.,
2014). The study aimed to identify and structure the main factors that hampers the on-time
performance in the Swedish railway network and an effective real-time traffic management. Some
conclusions are that train drivers have a lack of knowledge about the real time traffic plan and
upcoming meetings in the single line railway network, and therefore they cannot adapt their
driving to the actual timetable, resulting in non-optimal train driving. Further, the train often does
not follow their timetable (especially freight trains). Hence, the interaction and coordination
between different decision-makers (e.g. the train drivers and the traffic controllers) is important
to analyze and improve. The research on the tasks for and the cooperation between train drivers
and traffic controllers has been highlighted and intensified the last years, see e.g. (Andreasson et.
al., 2019). Examples of ongoing projects that conduct field studies and surveys with the Swedish
setting are F-AUTO and FTTS2, see (KAJT, 2020) for more information (in Swedish). The purpose of
the project F-AUTO, which runs during the period 2018-2022, is to identify traffic situations and
work situations in the Swedish railway traffic management that are associated with a particularly
high cognitive work-load, and analyze how automation and algorithms can be used to support the
traffic controllers.
Another task in the current FR8RAIL II-project is to develop a demonstrator for short-term timetable planning. This demonstrator is described in (Joborn et al., 2020). The focus of the demonstrator is to handle (minor) modifications to the timetable, like changed departure time of a freight train or addition of one train, while minimizing the impact on the other trains. This demonstrator is under development and will be finally reported in 2021. In the Shift2Rail-project FR8RAIL III WP2, a demonstrator is developed for operational planning and coordination of the activities (arrivals, departures, other shunting movements) at a combined arrival/departure yard at a major marshalling yard. The Swedish marshalling yard Malmö Godsbangård (MGB) is in focus, and the demonstrator is built to represent this yard. This is work-
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 23 | 85
in-progress and the demonstrator will be finished in 2022. Driving advisory systems for train drivers are a rather mature market and several vendors provide systems. However, to make full usage of the advisory system, it should have an on-line connection to the traffic control center so that the actual operational train driving conditions are a base for the driving advisories. Such systems are denoted connected driving advisory systems (C-DAS) and are much less common in practical usage in the railway market. However, commercially available products do exist. In (Gotelli et al., 2020) the current status of such systems is described together with experiences from a first C-DAS installation in Sweden. VDJ (Verklighetslabb digital järnväg / Reality lab digitized railway) is a large research R&D project run by Trafikverket and Luleå Technical University since 2017 (Söderholm et al, 2019). The focus is on large-scale collection and analysis of operational data concerning both infrastructure and vehicles, with the purpose of creating a digital twin that enables better knowledge of the status of different system components. The goal is to achieve better maintenance planning and better cooperation among the different stake holders. Apart from technical and IT platform issues, the project also studies organizational changes and effects, contractual and legal issues and developments for a more pro-active surveillance and maintenance handling. VDJ addresses the health monitoring of the physical systems and components of the railway system, and the principal users are technicians and maintenance planners. To conclude: Above we have mentioned several different initiatives and projects with related aims. The difference between the above-mentioned projects and the demonstrator presented in this document, is that the other projects aim to develop and build new demonstrators for specific purposes, while we propose a conceptual demonstrator for multiple purposes based on a number of existing software components. Some of the components relates to well-studied research topics on their own, while other are more unique and novel topics. Experience and results from the previously developed and build demonstrators are therefore highly relevant to review and incorporate when a future multi-purpose demonstrator is to be build. In the next chapter, we propose (existing) components to build the demonstrator upon.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 24 | 85
5. Concrete proposal for demonstrator Given the generic description of the demonstrator and its components in Chapter 4, in this chapter we propose existing components to build the demonstrator upon. The selection of components is based on components that are available for Trafikverket. As commented, a design idea of the demonstrator should also be that components are (to some extent) interchangeable in order to evaluate alternative implementations of components. In Chapter 4, there are generic descriptions of the modules of the demonstrator, and those are complemented by the descriptions of the components made in this chapter. Even though this chapter takes a standpoint from Trafikverket perspective, the collected component descriptions should hopefully make it possible to transfer the demonstrator outline to the prerequisites of another infrastructure manager.
5.1. Proposed components In this section we revisit the general demonstrator and propose which concrete components that should be included. In Figure 4, the overall architecture of the components is illustrated. Please note that the currently available components may not be fully included in an “as-is” status but may have to be adapted and enhanced to function in the demonstrator.
Figure 4: Proposed components in a demonstrator implementation. The implementation may be performed stepwise by including more and more components (see Section 5.3).
5.1.1. STEG – Electronical graph STEG (Styrning av Tågtrafik genom Elektronisk Graf/Controlling Train traffic with Electronical Graph) is a tool for planning and visualizing the RTTP (Real Time Traffic Plan). STEG replaces the paper graph, which is an important tool for traffic controllers. The idea is a working method allowing for planning and foresight. The RTTP is a central concept for STEG, with the main idea of one single updated plan to which train controllers, train drivers and communicators should stick to. STEG and RTTP are two parts of a new way of working, called operative re-planning. At the
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 25 | 85
organizational level, the concepts from STEG have become central parts of the requirements specification of how the new train traffic management system in Sweden (NTL) should work (Arweström Jansson, 2017). STEG also includes “execution” of the plans, i.e., STEG sends control commands to the TMS-system (EBICOS) to set routes. STEG is in operational use at two of Trafikverket’s eight traffic control centers in Sweden. It is currently being implemented at all traffic control centers, but without the “execution” of TMS-commands. The implementation of STEG at all traffic control centers is a pre-step in the implementation of the new national TMS-system to assist in the introduction of new planning concepts.
5.1.2. Disturbance management module (DMM) As chapter 3.1 stipulates, depending on the traffic situation many different kinds of conditions may occur, which require different actions by the traffic controller to handle actual and future deviations from the RTTP and potential conflicts. Hence, any decision-support needs to be flexible and offer different functionalities that can satisfy the specific needs that the situation requires. In the project deliverable D3.1 (Peterson et. al., 2019), a survey and analysis of state-of-the-art and state-of-practice is presented. It shows the wide range of alternative approaches and methods, all developed with a specific context in mind. For example, there are optimization-based approaches minimizing final delays and maximum consecutive delays which are effective for congested lines dominated by passenger trains, while other approaches have partially other objectives to better capture the context-specific priority principles of the country or the mixed-traffic. In order to facilitate the assessment and comparison of alternative, complementary approaches, a structured classification and evaluation framework has been developed and can be found in Appendix B, where its application also is demonstrated by comparing two alternative algorithmic approaches for managing disturbances in a Swedish context. In the demonstrator setting, the DMM is one sub-component supporting the DH (Deviation Handler)-functionality and is intended as a “plug-in” into STEG, calculating and proposing ways to handle disturbances in the scheduled timetable during operations. In Appendix B, two alternative components that could serves as a DMM to support the real-time traffic management of minor disturbances, are presented and their applicability is analysed and discussed.
5.1.3. EBICOS 900/Ebisim EBICOS 900 is a commercial traffic management system (TMS), which contains all standard
features of such systems. This is the traffic management system used at a majority of traffic control
centers in Sweden. In the demonstrator setup STEG cannot connect directly to the virtual railway
but needs to connect via EBICOS 900. Furthermore, this enables testing of the communication
between these two systems.
The EBICOS system also contains a simulator called Ebisim, which can work as a virtual railway. All
traffic control centers and Trafikverksskolan are equipped with an Ebisim, which function is to
simulate interlockings, objects and train movements. A training site usually includes a number of
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 26 | 85
operator computers for students as well as a specific teacher desk with access to both the
controller station and computer running the Ebisim. The main use of the simulator is to practice
operating with EBICOS 900 in a simulated traffic situation but can also be used to test for example
driving plans. The three functions of Ebisim are: Answering actions initiated by operator
commands and generate indications for all objects in the geography; Simulating objects out of
control; Simulate trains. Ebisim copies geography data from EBICOS 900. The normal operator
interface of EBICOS 900 is not affected by Ebisim (Bombardier, 2019).
5.1.4. BEST BEST (Bana El Signal Tele) is an implementation of a Virtual railway that is used by Trafikverket. BEST simulates the railway infrastructure’s behavior with respect to trains running in the system and traffic controllers’ commands to control the infrastructure (signals and switches). The realistic vehicle simulation includes driving behavior, traction and braking. There are also restrictions for speed, brake effect and traction to simulate temporarily speed reductions. The simulator is compatible with EBICOS and SNTL (Simulator for National train control). Timetables/traffic plans are simulated resulting in trains stopping and pausing according to the plan. BEST is supplied by a commercial actor providing the tools for simulation. BEST is operational at Trafikverket, and it is initially constructed for testing and evaluating the new TMS system in Sweden (NTL). Trafikverket is currently investigating complementary usages of BEST, for example training and connecting it to other systems that Trafikverket utilizes. Railway data is entered and maintained by Trafikverket. All physical objects for each interlocking installation in Sweden are included, also objects that cannot be seen. For example, each lamp can be configured, which is necessary for a correct signaling behavior. There is also a graphical interface where all details can be built or adjusted. The train editor of BEST is used for building train configurations including vehicle set and driver profile with parameters like length, weight, rolling resistance, electrical or diesel traction. The user interface includes start, stop, and pause of simulation as well as increasing or decreasing the simulation speed. Objects can be included or excluded and manipulated, such as switching main signal to “go”. Fault or defects like for example damaged turnout can be introduced, which can be useful practice for train controllers. Regarding the vehicles, for example train number, train set, driving manners, ATC/ERTMS, direction can be controlled and diving mode can switch between simulated/automatic or manual driving. Train position can be displayed for each meter of the track, which also is useful for education. Restrictions like limitations in the power distribution can also be introduced, as well as wheel slip due to leaves or oil spill on the rails. The driver logic in the BEST simulation follow the traffic regulations. Driving behavior can also be adjusted choosing parameters like for example alert, sleepy and slow, which makes the simulation more realistic.
5.1.5. VTI train simulator The VTI train simulator is used by train operators and train driver educators in Sweden, for safe
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 27 | 85
and efficient education and training. Since 2015, a scheme for development of train simulators, based on the same proprietary simulator software and with existing Swedish tracks represented, has been successfully developed, based on user involvement and needs, with a main application in train driver education. The simulator is developed and maintained by VTI, and a large user group is engaged in the planning for new features. A freight train model with a possibility to select the number of wagons, weight, braking characteristics and alter other parameters was included as a result from a project financed by Trafikverket (Andersson et al., 2017). As a result, 4 different types of simulators are now available, all based on actual Swedish rail data, each being subjectively regarded to be of high international standard, after being validated in use by many train drivers. Based on requests from the user group, the common simulator software has been made available in several different physical configurations, ranging from a generic laptop PC version equipped with one or two control levers (accelerator and brake), to authentically mimicking the real driving environments of both a “Regina” passenger train ( Figure 5) and of a Traxx™ control panel for freight trains (Thorslund, Rosberg & Lindström, 2019).
Figure 5: Two variants of VTI train simulator, to the left a complete “Regina” environment and to the right a portable freight train configuration.
5.1.6. C-DAS/CATO There exists several commercial or prototype systems that provide C-DAS functionality, see (Gotelli et al., 2020) for an overview. In Sweden, the C-DAS systems CATO (Joborn et al, 2011; Joborn et al. 2012) provided by Transrail have been used in experimental real-world setups. The demonstrator is a goods testbench for evaluating this and other C-DAS systems. Since CATO is a rather mature system, this is a first-hand choice for the implementation of the DAS component in the demonstrator.
5.1.7. Yard Coordination System (YCS) The Yard operations planner component in the generic demonstrator is suggested to be implemented by two separate components: the Yard Coordination System (YCS) corresponds to the planning of the arrival and departure yards (or a combined arrival+departure yard) and the
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 28 | 85
RANPLAN Classification planning tool corresponds to the planning of the classification bowl (see next section). Organizationally, (in Sweden) one of the Traffic controllers of the IM is responsible for allocating the track resources to the arriving and departing trains at the arrival/departure yard. In practice, it is a joint work between the Traffic controller and Yard manager (and possibly also by a Terminal manager) since their interests and track needs are shared. In (Gestrelius et al., 2018) the needs and challenges with respect to the arrival/departure yard are described. The Yard Coordination System (YCS) is a demonstrator for information sharing and track allocation of the combined arrival/departure yard MGB in Malmö in southern Sweden. The YCS is being developed within the Shift2Rail-project Fr8Rail III WP2 by Trafikverket, Indra and RISE. A generalization of that demonstrator is a very relevant component for the demonstrator implementation proposed in this report. The YCS includes the following aspects of the yard planning:
• Information sharing between Traffic controller, Yard manager and Terminal manager regarding
e.g. (actual) arrival times, (actual) departure times, need for shunting activities, hazardous goods.
• Allocation of tracks to different track needs. A track need may represent an arrival, a departure, a
pull-back or some other shunting operations. Track can also be needed for parking of locomotives
or the track can be closed for maintenance.
• Estimation of departure times, i.e. estimation of the handling times at the yard and the process
time to build outgoing trains. The estimation is in the basic implementation made by the Yard
Manager, but in more advanced implementations it could be calculated by the decision support
tool itself.
• Identification of planning conflicts.
As mentioned above, any planning of the departure times from the yard is dependent on good estimations on the processing times at the yard. Such estimations also have great impact on the planning of the lines. Estimations can be made manually by experienced planners or by a decision support system. As pointed out in (Peterson et al., 2019), there is a large variability in the handling times at the yard and in the departure times, and it is unclear how all factors that may influence the departure time interact. In Appendix A, we present an investigation how the situational circumstances at the yard influence the departure time, and also some first results from a departure time prediction algorithm based on machine learning.
5.1.8. RANPLAN Classification planning tool The second part of of the generic component Yard operations planner is fulfilled by RANPLAN Classification planning tool developed by RISE (Gestrelius et al., 2017). RANPLAN is a prototype decision support tool for operational planning of the marshalling activities at the classification bowl. The purpose of RANPLAN is:
• Allocation of tracks to departing trains and wagon mixes at the classification bowl.
• Determining times for roll-in (from arrival yard) and roll-out (to departure yard).
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 29 | 85
• Determining times for pull-backs.
• Minimizing the total operational cost and delays.
Algorithms are based on optimization and heuristics. Today, RANPLAN is a standalone prototype, but by including it in a more comprehensive demonstration environment, it is possible to further study the interactions between the train operations, arrival yard and classification operations, and to increase the understanding in the way they depend on each other.
5.2. Principal Use cases The proposed demonstrator can be used in many ways for different purposes. In this section we outline a few high-level use cases. The objective is to describe how the demonstrator can be used and the interaction between the actors and the system. Of course, several more use cases can be constructed, and these can also be broken down into details including the interaction with each component. However, the aim here is to provide a high-level idea of the demonstrator usage, therefore only few use cases are presented and without any details regarding the interaction between the actors and the systems. To describe the usage of the demonstrator we form three principal use cases: UC1: Set up demonstrator. Actor: Demonstrator supervisor. Involved component: Demonstrator management tool. UC2: Handle deviation in traffic. Actors: Train driver, Traffic controller. Components: VTI train simulator, C-DAS, STEG, Disturbance management module, BEST UC3: Adapt yard planning. Actors: Yard Manager, two Traffic controllers (one Traffic controller responsible for line and one responsible for arrival/departure yard). Components: Yard Coordination System, RANPLAN, (STEG), (BEST).
5.2.1. UC1: Set up demonstrator Starting condition: A demonstration is to be performed.
1. Demonstrator supervisor determines which scenario to demonstrate. The scenario includes
specification of which actors and components that are involved in the demonstration, geography
and railway line, timetable, etc.
2. Demonstrator supervisor loads the scenario into the Demonstrator management tool.
3. Demonstrator supervisor determines the virtual time used in the demonstration.
4. Demonstrator supervisor determines which type of disturbance that shall occur in the
demonstration (if any).
5. Demonstrator supervisor initiates the demonstration and instructs the other actors.
5.2.2. UC2: Handle deviation in traffic Starting condition: Demonstrator supervisor has initiated a demonstration.
1. Traffic controller gives clearance in STEG for starting to drive the train by setting the route. Route
execution commands are sent to EBICOS so that signals, etc., are activated in BEST.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 30 | 85
2. Train driver receives starting command (green signal) and starts driving the train in the VTI train
simulator.
3. Some disturbance occurs according to the scenario. Trains are delayed.
4. The Traffic controller is, via STEG, informed about delayed trains and the deviations from RTTP.
5. The RTTP is updated based on the new forecast on train movements (either the STEG makes this
calculation automatically or the traffic controller makes the updates manually). The update
involves only updated times and no changed train order or new crossings – it is just a shift of
trains in time according to updated forecast of arrival/departure times. This shift in time may
result in unresolved conflicts. Unresolved conflicts are indicated in STEG.
6. Traffic controller inspects the RTTP in STEG and detects that the RTTP can be improved if it is
changed, either because there is a conflict or that a delay can be reduced.
7. Traffic controller uses STEG to acquire a proposal for updated RTTP from the Disturbance
management module.
The Traffic controller can control how big changes to the RTTP that the Disturbance management
module is allowed to do to the RTTP. Also, the Traffic controller can provide fixed parts of the
RTTP (that must not be changed), priorities and objective with RTTP-update.
8. The Disturbance management module calculates a new RTTP according to the specifications and
limitations and sends it to STEG where it is illustrated in the user interface (digital graph).
9. Traffic controller uses STEG to assess the proposed new RTTP.
Traffic controller adjusts the RTTP and confirms the usage of the new RTTP.
10. Train driver is informed about (relevant parts of) the new RTTP via the C-DAS.
11. Train driver adapts his/her driving according to the updated timetable for the train and continues
to drive the train in VTI train simulator.
Of course, there are very many variants of this use case. As an example of a refinement, in step 6-8 there can be different levels of automations in the interaction between the STEG and the Disturbance management module, all the way from automatic adjustment of arrival/departure/meeting times based on current deviation (a minor automation) up to that the train order of several trains in the network are adjusted to minimize the total deviation.
5.2.3. UC3: Adapt yard planning Starting condition: Demonstrator supervisor has initiated a demonstration and a freight train has a deviation in its transport plan. The deviation can for example be an early or a late departure from the origin yard or that a freight train gets a deviation during its transport. (Note that there are two different Traffic controllers involved in the use case: one responsible for line management and another responsible for the arrival yard.)
1. The Traffic controller responsible for the line management uses STEG to inspect the RTTP and
detects that the arrival time of a freight train is deviating from the original timetable.
In case the train has not yet departed from the origin yard, the departure is put on hold until the
use case is finalized and an agreed arrival time to the destination yard is agreed between the
Traffic controller for the line and Traffic controller for the yard.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 31 | 85
2. The Yard Coordination System receives information from STEG about the deviating arrival time.
Information about expected arrival time is updated in Yard Coordination System.
3. The Traffic controller that is responsible for the arrival yard notices the updated arrival time in the
Yard Coordination System. Traffic controller makes any relevant updates to the track allocation
plan in the Yard Coordination System.
4. The Yard Manager is via the Yard Coordination System updated about the changed arrival time
and track allocation.
5. Yard Manager makes any necessary updates to the classification plan in RANPLAN to
accommodate the changed arrival times. Yard Manager uses RANPLAN to calculate new track
assignment, pull-back times and roll-out times and other shunting and yard operations.
6. Yard Manager updates track need on arrival/departure yard in the Yard Coordination System.
7. Traffic controller for yard checks for any conflicts in the plans for arrival/departure yard in the
Yard Coordination System and resolves these by either changing track reservations or negotiate
with Yard Manager.
8. If no good plan for the yard can be found (in step 3-7), the Traffic controller for the yard requests
an updated arrival time for the freight train by providing a time window in which the train should
arrive. Reasons for this can e.g. be that the arrival yard cannot accommodate more trains at the
planned arrival time or that too large delays are imposed on the departing trains. In this case, the
Traffic controller for the line should provide an updated arrival time for the freight train, and the
use case is restarted.
5.3. Development roadmap: Requirements and recommendations The set-up, management and maintenance of the type of demonstrator we propose in chapter 5.1 imposes several requirements. In this chapter, we start by outlining a stepwise approach to the development of the demonstrator. We then pinpoint some general aspects that are important to keep in mind.
5.3.1. A modular demonstrator Depending on the objective, a functional development roadmap for such an environment can be described in different ways. Not all parts have to be included at the same time. Meaningful parts can also be accomplished by just combining two systems. The complete, proposed demonstrator is rather complex. Therefore, we suggest a stepwise approach to the development, where the result from each step is valuable and usable (and not dependent on later additional developments to make a usable, partial demonstrator), as illustrated in Figure 6. The first step is to integrate STEG, EBICOS and BEST. These three components together will provide a valuable and powerful training module for Traffic controllers. Step 2 is to add the VTI train simulator, and after step 2 the result would be a realistic train driver environment in which we can have realistic interaction with the Traffic controller. Adding a C-DAS to this (in step 3), would make the communication between Train driver and traffic control modern, and provide possibilities for C-DAS evaluation. The fourth step is to add Disturbance Management Module so that advanced
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 32 | 85
and realistic interplay between a Traffic controller and an advance decision support for RTTP-adjustments. The final steps are to include the yard aspects in the demonstrator in order to get the complete freight network management perspective; step 5 is to add the Yard Coordination System, in which the line management and yard management meets, and the final step is to also include RANPLAN Classification planner to capture the internal yard planning aspects.
Figure 6: Stepwise connection of systems for the demonstrator.
Training or research can also be performed on an isolated part of the complete demonstrator, for example on how the driver interacts with STEG or how the traffic controller works with DMM or BEST. Another example is to include a driver using the VTI Train simulator in the BEST simulator and let that driver interact with a train controller. Furthermore, in a simulation, roles can either be supported by tools or replaced by modules. For example, the Disturbance management module can support a traffic controller but can also act as a traffic controller. Thus, an alternative approach to the roadmap of the development is to split it into several smaller demonstrators. Below we provide examples of some relevant partial systems, see Figure 7.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 33 | 85
Figure 7: Five suggestions for partial demonstrators.
1. STEG+EBICOS+BEST: Connecting STEG with EBICOS and BEST will provide a valuable and powerful
training module for Traffic controllers. This is also a basis for realistic demonstration, training and
education, that can be extended in several ways.
2. 1.+VTI train simulator+C-DAS: Adding a train simulator and a C-DAS to the basis of
STEG+EBICOS+BEST would create a realistic train driver environment in which we can have
realistic interaction with the Traffic controller and evaluate concepts for C-DAS.
3. 1.+DMM: Adding the Disturbance Management Module to the basis of STEG+EBICOS+BEST would
create a realistic evaluation environment for decision support tools aimed at deviation handling
and the human interactions with these systems.
4. 1.+YCS: The dependencies between yard and line can be studied, evaluated, and improved by
complementing the STEG+EBICOS+BEST-basis with the Yard Coordination Module.
5. YCS+RANPLAN: The yard operations can be studied, and planning modules evaluated, by building
a demonstrator consisting of Yard Coordination System and RANPLAN Classification planner.
5.3.2. Data, computer environment and information security The demonstrator is dependent on a lot of data. Data must be consistent, accurate and realistic so that actors/users of the demonstrator get the sense that the demonstrations are relevant. Thus, access to good data is crucial for making a good demonstrator. Keeping data consistent for the whole demonstrator in the different scenarios will be important and non-trivial. Handling a lot of infrastructure and operational data will impose IT-security restrictions on the system in several ways. The computer and program architecture must provide relevant level of information security and the data used in the demonstrator must be handled in ways that is supported by the information security standards. The information security may place requirement
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 34 | 85
on the design and content of the demonstrator that must be investigated at an early stage. It is vital that a clear receiver of the demonstrator is defined already at an early development stage. The receiver of the demonstrator must also have interests in having the system up-to-date and with good quality, both regarding the computer system and the data it is loaded with.
5.3.3. Modularity and automation The demonstrator should be modular in two different ways. Firstly, the dependencies between the component should be kept as low as possible so that the demonstrator makes sense and is usable with only a few of the components installed. Some components will be necessary in nearly all usages (like the Virtual railway) while other components should be possible to turn-off (like Yard operations planner and Driving simulator). In training and educational scenarios, it will be very relevant to only involve one actor, like the Train driver or the Traffic controller. Some components should also be possible to switch to alternative implementations. For example, it will be very relevant to - in a plug-in-manner – switch between different DAS-implementations or between different implementations of Deviation handler. One important usage of the demonstrator is to evaluate decision support that includes different levels of automation. Several of the components can be designed for purely manual planning or include less or more automation. The system should be built in a way that supports the evaluation of automation including which parts that should be automated, how interaction with human operators should be designed and how to keep man-in-the-loop in a system with (partly) automated decision making.
5.3.4. Usage requirements for training tools vs research tools The main objective for training is that the users´ skills progresses towards the learning goal. Training requires feedback and various levels of difficulty. There is also a need for variation within the same degree of difficulty. This means that the tools need to be flexible and adjustable. Of high importance is that the training provided by the tool is pedagogical and less important is that it is identical for all participants. There is a need for good feedback, to both user and instructor, which should be clear in describing what has been achieved, progress over time, and where further training is needed. The realism in the demonstrator usage has to be sufficient, not perfect, but enough to meet the demands of the specific training level. However, this is not only created by the technical tools, but also by the scenario description. A main goal within research is to examine effects of something on something, for example effects of training, implementation of a DAS-system or a changed speed profile on efficiency or punctuality. Thus, research requires a controlled environment with possibility to repeat the same scenario for numerous participants and record large amount of anonymous data. Receiving correct data for effect measures is of high importance and to be able to summarize or compare between groups or systems. Being able to change functionality is a valuable feature for research while changing prerequisites is more relevant for training.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 35 | 85
Both in training and research, the simulated environment needs to be at a certain reality level, depending on the specific situation and purpose. An environment too advanced for the requirements, would be too expensive and may also limit the possibility to interact with the system. Also, an environment too simplified may not give the realism needed for a realistic behavior. The requirements for training and research stated above, indicates that a flexible environment supporting both purposes is achievable. Some of the aspects to consider when setting up an environment supporting both training and research are the following:
• Systems to include,
• interactions between systems,
• functionality to implement and support,
• GDPR/identification,
• (eye) tracking, recording,
• instructions,
• output data,
• data processing,
• analysis,
• feedback.
One strategy to create such an environment is to allow for choosing either training or research mode once the set-up of the scenario is made. Suggested parameters to adjust within the selected mode are for example: integrity, functionality, feedback, instructions, and output data. Close collaboration with future users and stakeholders is recommended during the design and development process.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 36 | 85
6. Conclusions and discussion In this report we have outlined an advanced demonstrator for real time network management for freight rail traffic. The aim is the coordination between traffic control, train drivers and yard management, three essential parts in the real time management of a rail freight network. The intention is that the demonstrator can support multiple purposes, like education and training, demonstrating research advances, and getting feedback between practitioners, system developers and researchers. This kind of demonstrator is also very useful when evaluating the consequences of larger system changes, like new signalling systems or running longer trains in the railway network. The modularity of the demonstrator should make it possible to adapt the demonstrator more easily to the alternative transportation system characteristics. Compared to previous related initiatives discussed in chapter 4.5, the proposed demonstrator has a clearer focus on the interaction between different systems and between humans using these systems, and also on the complete rail freight perspective by the inclusion of the connection between the line and the yard. Thus, even though the demonstrator is a vision, the existence of the components makes the realization of the demonstrator realistic. We present a generic architecture and propose existing components that could be combined to such a demonstrator. We have also outlined a number of more general requirements related to the development of the demonstrator. One key aspect is that it is critical to have a clear receiver of the demonstrator defined already at an early development stage. The receiver of the demonstrator must also have interests in having the system up-to-date and with good quality, both regarding the computer system and the data it is loaded with. A primary usage field of the proposed demonstrator is education and training. The VTI train simulator is already to some extent used in train driver training. During 2021, further possibilities to connect the VTI train simulator with the virtual railway BEST will be investigated as well as possibilities for further extended usage of VTI train simulator in driver training. In Shift2Rail, running (freight) trains of length up to 1500 meters is of special interest. Standard maximum length in Sweden is today 630 meters, and extended train lengths can be, for example, 750, 850, 1000 or 1500 meters. The different extension levels will result in various large implications in the railway system in many different aspects, e.g., infrastructure, timetabling, signalling, traffic control, train driving, train performance and marshalling. The demonstrator can be used to evaluate pros and cons, effects and principles for extending the trains’ length. Since the demonstrator includes many important operational aspects and roles, the demonstrator can be a bases for understanding and handling the system changes that are necessary for different train lengths. Of course, some of the modules may have to be extended to capture all aspects of running longer trains, but using a demonstrator will still be a much more efficient way of preparing the railway system for such changes than directly making them in the real world railway system. Several of the components of the demonstrator are advanced decision support systems, today available as prototypes. In the appendices to report, there are contributions to their continued development.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 37 | 85
As this deliverable concludes Task 3.2, continued development of the demonstrator will be performed in upcoming projects (not yet determined). The continuation of the Fr8Rail II WP3 project, including deliverable D3.3 and D3.4, will continue the research and development outlined in D3.1 as part of Task 3.1. Some components will also be developed in the project Fr8Rail III WP2 (primarily the Yard Coordination System).
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 38 | 85
7. References Andersson, A., Lidström, M., Peters, B., Rosberg, T., Thorslund, B., (2017). Framtagning av
loktågsmodell för VTI:s tågsimulator. VTI notat 26-2017, LiU-Tryck, Linköping 2017. Andreasson, R., Jansson, A, Jessica Lindblom, J. (2019), The coordination between train traffic
controllers and train drivers: a distributed cognition perspective on railway, Cognition, Technology & Work (2019) 21, pp. 417–443, Springer. https://doi.org/10.1007/s10111-018-0513-z.
Arweström Jansson, A., (2017). Vad är det trafikledarna gör som automationen inte klarar? : Tågtrafikstyrning med människan i centrum. Retrieved from http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-335144.
Barrow, K. (2018). C-DAS: taking driver advisory systems to the next level. IRJ, Sept 2018. https://www.railjournal.com/in_depth/c-das-taking-driver-advisory-systems-to-the-next-level.
Bombardier. (2019). Teknikerhandbok EBICOS 900. Document number: 3NSS004160D0105 Gestrelius, S., Aronsson, M., Joborn, M., Bohlin, M., (2017), Towards a comprehensive model for
track allocation and roll-time scheduling at marshalling yards, Journal of Rail Transport Planning & Management 7 (3), 157-170, 2017.
Gestrelius, S., Joborn, M., Wahlborg, M., Lucke, H-J, (2018) Description of business processes of a network management system and the interactions/interfaces with a Realtime Yard Management System, Project report (Delivery 2.2) from project ARCC, 2018.
Gotelli, G. et al. (2020) Requirements & concept of C-DAS functions, Delivery 4.2 of project FR8RAIL II, 2020.
Graffica (2020), HERMES and the ON-TIME project, https://www.graffica.co.uk/rail-traffic-management/case-studies/hermes-and-the-on-time-project/ (last accessed 20200602).
Hellström, P., Sandblad, B., Andersson, A., Tschirner, S., Goverde, R., Wahlborg, M., Emery, D. (2014), Problems in the integration of timetabling and train traffic control, Technical report from the ON-TIME project, Uppsala University, ISSN 1404-3203. https://www.it.uu.se/research/publications/reports/2014-002/2014-002-nc.pdf
Himmelspach, R., Gunter, A., Streicher, T., Wahlborg, M., Lucke H., Albrecht, T., Kordnejad, B., Joborn, M., Gestrelius, S. (2017), Real-time yard management - Description of automation/optimisation requirements and capabilities of decision making process in Marshalling yards and Terminals, 2017. Project report (Delivery 2.1) from project ARCC, 2017.
Joborn, M., Gestrelius, S., Kjellin, M., Wahlborg, M., Peterson, A., Häll, C.-H., Schmidt, C., Kordnejad, B., Johansson, I., Warg, J., (2020), Demonstrator concept and first prototype for improved timetable planning, Project report (Milestone MS6) from project FR8Rail II, 2020.
Joborn, M., Hammarberg, P., Engelbert, T., Leander, P., Lidén, T., (2012), On-time performance and energy efficiency for trains, 19th ITS World Congress, 2012.
Joborn, M., Leander, P., Lidén, T., Nordmark, T., (2011), Energy efficiency and on-time performance for heavy haul trains, International Heavy Haul Association Conference, 2011.
KAJT (2020), ”Projektkatalog”, March 2020. https://www.kajt.org/onewebmedia/KAJT-katalog_2020.pdf (in Swedish, last accessed 20200603).
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 39 | 85
Lucke, H-J, Gestrelilus, S., Joborn, M., Wahlborg, M. (2018), Modelling Requirements and Interface Specification to Yard Simulation System, Project report (Delivery 2.3) from project ARCC, 2018.
Lucke, H-J, Gestrelilus, S., Joborn, M., Wahlborg, M. (2019), Description of demonstration scenarios for a Real-time Yard Management System, Project report (Delivery 2.4) from project ARCC, 2019.
Panou, K., Tzieropoulos, P. and Emery, D., (2013). Railway driver advice systems: Evaluation of methods, tools and systems. Journal of Rail Transport Planning & Management, 3(4), pp.150-162.
Peterson, A., Wahlborg, M., Häll, C-H., Schmidt, C., Kordnejad, B., Warg, J., Johansson, I., Joborn, M., Gestrelius, S., Törnquist Krasemann, J., Josyula, S.P., Palmqvist, C-W., Lidén, T., (2019), Analysis of the gap between daily timetable and operational traffic, Project report (Deliverable 3.1) from project FR8Rail II, Linköping University. Full-text link: http://www.diva-portal.org/smash/get/diva2:1391876/FULLTEXT01.pdf.
Quaglietta, E., Pellegrini, P., Goverde, R., Albrecht, T., Jaekel, B., Marlière, G.,Nicholson, G. (2016). The ON-TIME real-time railway traffic management framework: a proof-of-concept using a scalable standardised data communication architecture. Transportation Research Part C: Emerging Technologies, 63, pp. 23-50.
Rodriguez, J., et. al., (2011), Tools for real-time perturbation management including human machine interface, On-Time project deliverable D4.2.
Söderholm, P., Carolin, A., Eriksson, L., Forsberg, M., Granström, R., Jägare, V., Karim, R. (2019). Verklighetslabb digital järnväg - Förmåga för ökad digitalisering och hållbarhet. Trafikverket rapport 2019:210, ISBN 978-91-7725-558-1, http://trafikverket.diva-portal.org/smash/record.jsf?pid=diva2%3A1386051, 2019-11-28.
Thorslund, B., Rosberg, T., Lindström, A. (2019). User-centered development of train driver simulator for education and training. 8 th International Conference on Railway Operations Modelling and Analysis (ICROMA 2019). Norrköping, Sweden, June 17-20, 2019.
TRIMIS (2020), ON-TIME project information, https://trimis.ec.europa.eu/project/optimal-networks-train-integration-management-across-europe#tab-results. Last update 02/06/2020. Last accessed 20200602.
Törnquist Krasemann, J., (2016). Slutrapport för delstudie 1 i projektet FLOAT. Full-text link: https://www.bth.se/wp-content/uploads/2017/12/Slutrapport-studien-MalmbananFLOAT-final-version-inkl.-bilaga-1.pdf.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 40 | 85
8. Appendix A: Real time yard management: A case study about relation between yard operations and departure time
From a marshalling yard, there is a large variability in the departure times: many freight trains depart before or after the scheduled departure time (at least in Sweden). In the previous report D3.1 from the current Fr8Rail II-project (Peterson et al., 2019) the situation at the Swedish major marshalling yard Malmö Godsbangård (MGB) was described and analysed, both with respect to its physical prerequisites and traffic situation. An interview study was made with staff involved in the operations of the yard to find factors and causes to the deviating departure times. The conclusion of the interview study correspond to the reported knowledge gaps with respect to departure times from the yard: 1) There are many different factors that cause and contributes to deviations in the departure times, but it is not clear which factors that are most important or how relevant the different factors are. 2) It is not known how these factors interact. 3) It is very hard to (manually) predict if a departure will be early, on-time or delayed. The aim of this chapter is to start covering the knowledge gaps mentioned above by analysing yard and train data from MGB. Also, the Yard Operations Planner (see section 4.3) is dependent on good estimations of the throughput time at the yard. Therefore, covering the knowledge gaps above is also important for a successful implementation of a Yard Operations Planner. To understand the principal behaviour of the yard and the departure times, it may be good enough to have realistic estimations of statistical measures of departure delay distributions, but to understand and improve the precision of the prediction of individual train’s departure time, a deeper knowledge about the causes to departure time deviation is necessary. In this section we will present a quantitative analysis of which factors that affect the deviation of the departure time from the marshalling yard MGB. Data in the study comes from the major FRU in Sweden, Green Cargo. Data represent most3 departures from MGB during 2019 (7299 departing trains). In Figure 8 the distribution of departure times from MGB is illustrated. The median is that trains depart 4 minutes before scheduled of the departure time, 47% of the trains depart more than 5 minutes before schedule departure and 23% depart more than 5 minutes after scheduled departure, and 30% of the departures deviate 5 minutes of less. The aim of the study in this section is to investigate what factors concerning the operations and status at the yard that contribute to that train departures are before or after the scheduled slot.
3 Some trains (about 1%) were excluded due to inconsistencies in the data. Also trains that arrived and departed MGB without changing its wagon configuration was excluded (even if the train number was changed), since the departure time of such trains are less dependent on the operations and status inside the yard. Data only includes trains from Green Cargo - there are also freight trains from other FRUs departing from MGB, but the Green Cargo trains are in clear majority.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 41 | 85
Figure 8: Distribution of departure times from MGB, divided in 5-minute intervals. Left y-axis is number of departures, right y-axis is percent of departures.
From previous studies it has been concluded that the following factors may be of importance for the deviation of the departure time:
• Train destination,
• train type,
• day of week,
• time of day,
• direction (northbound or southbound train),
• time when train is ready for departure (denoted “K-report-time”),
• weight of train,
• length of train,
• number of wagons in the train,
• load of the yard in the sense of number of wagons,
• load of the yard in the sense of number of simultaneous trains,
• load of the yard in the sense of “fan-in”,
• connection time of wagons,
• connection time for locomotives.
In this study, all the above factors and their implication on the departure time deviation have been analysed. Of course there are also other factors that may have an implication on departure deviation that are not included in the study, like weather, personnel situation, number of arriving trains, situation on the connecting lines, interaction between different FRU:s on the yard, etc., –
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 42 | 85
the influence of these factors still remains to be studied.
8.1. Destination and departure time Figure 9 illustrates the dependence between train destination and departure time deviation. Remember that the average of all departure times is -4, this shows that the median departure deviation for each respective destination is varying between -13 and + 18. The figure also illustrates the number of departures towards each destination.
Figure 9: Departure time deviation for different destinations. Median departure deviation (in minutes) in blue bars (left y-axis), number of trains as the orange line (right y-axis).
It was suspected that the direction of the train (northbound or southbound) would have a large implication on departure, since these train types are handled in different ways on the yard. In median, southbound train departed 3 minutes before schedule, while northbound departed 5 minutes before schedule. However, since northbound and southbound trains are handled in different ways, in several of the following diagrams we separate between northbound and southbound trains. In total, 35% of the departures are southbound and 65% are northbound. In the data, we could differentiate between a few different train types: long-distance wagon load trains, short haul feeder trains, system trains (carrying post). There were no significant different between these groups, except for that system trains (in median) depart 9 minutes before schedule while the other departs 3-4 minutes before schedule (in median). The frequency of freight train departures varies over the day. The frequency of passenger trains on the line outside the yard varies even more, with peaks in the mornings and in the afternoon. Therefore, it was expected that delayed departures should be more common in the time periods
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 43 | 85
when there is more passenger traffic since it is harder to get access to a slot on the line. This is confirmed in Figure 10, where we see that the medians of the departure time between 5 and 11 and between 17-19 are less early than during the rest of the day.
Figure 10: Deviation of departure time during different hours of the day. Red bars represent southbound trains, blue northbound.
The freight traffic varies over the week with less departures during the weekend. The only time of the week when the yard is closed and non-operational is the night towards Sunday. As seen in Figure 11, there is not a big difference in the median deviation during the week, except that Sundays have earlier departures. Looking into the details (not shown in the diagram) northbound train on Sundays are earlier than other days, but southbound departs later than other days.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 44 | 85
Figure 11: Deviation of departure time during different days of the week. Blue bars represent median departure time deviation (left y-axis), orange line is number of departures (right y-axis).
8.2. Train load In Figure 12, the dependency between train weight and departure time deviation is illustrated. In this diagram, we separate between trains that are early (purple bars) (i.e. departs more than 5 minutes before schedule), late (red) (departs more than 5 minutes after scheduled departure) or on time (yellow) (departure time deviation is 5 minutes or less). On the x-axis there is different train weights (tons), on the y-axis there is percentage of all departures. The diagram shows that for lighter trains, up to about 300 tons, early departure is much more common than late. Intermediate heavy trains, 500 to 1500 tons, have a “standard behaviour” with early trains more common than late, while for heavy trains, 1600 tons or more, early and late trains occur almost similarly often. Figure 13 illustrates a related measure as Figure 12, the dependency between departure time deviation and the number of wagons in the trains, and the result is similar: trains with few wagons are much more common to be early than trains that hold many wagons. Also, the dependency on train length have a similar behaviour, see Figure 14.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 45 | 85
Figure 12: Frequency of early and late trains depending on train weight.
Figure 13: Frequency of early and late trains depending on number of wagons in the train.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 46 | 85
Figure 14: Departure time deviation as a function of train length (in meters).
8.3. Ready-to-go-time (“k-report”-time) As soon as a train is ready to depart, the train driver makes an announcement to the traffic control; this is called that the driver makes a “k-report4” When the k-report is made, the train should be really ready for departure, e.g. all brake-checks should be finished. According to the directives, the k-report should be made 5 minutes before the scheduled departure. The k-report is most often made as soon as the train is ready – even if the train is ready before the scheduled departure time the k-report is made directly (i.e. the driver does not wait until a suitable departure slot before making the k-report). Figure 15 illustrates the correlation between time for k-reports and departure time deviation. Each dot in the diagram is one or more observations, the darker, the more overlapping observations. The histogram in the top of the figure represent the number of observations of different deviation of departure time. The figure shows that the average time from K-report to departure is about 5 minutes, regardless if the train departs too early or is delayed – indicated as the solid blue line in the diagram. The correlation between k-report and departure time is very strong with a separation of 5 minutes. Thus, regardless of the trains being ready early or late, the trains most often depart 5 minutes after they are ready. The dashed line in Figure 15 separates early trains from late trains, observations to the left of the line represent early departures. The dash-dotted diagonal line separates k-reports that are made on-time (at least 5 minutes before scheduled departure) from delayed k-reports. There are several observations when the K-report is made “on-time” (i.e. 5 minutes or more before scheduled departure) but the train is still delayed. However, the number of such occasions is not larger than
4 ”K-report” is a translation of the Sweden term ”k-rapport” which means ”ready-report”.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 47 | 85
that the median time from k-report to departure is still 5 minutes.
Figure 15: Time for K-report (y-axis: minutes from k-report to departure) vs. departure time deviation (x-axis). Each dot is one or more observations, the darker dot, the more overlapping observations. The trendline (blue) illustrates that the average time from K-report to departure is about 5 minutes, regardless if the train departs before or after the scheduled time.
8.4. Connection time At Green Cargo they use a wagon booking system for freight wagons, meaning that already before a wagon starts its journey, the wagon has a reservation in all trains that it is planned to be transported in (Himmelspach et al., 2017). The planned minimum connection time at the yards are considered when making the reservations so that the connections between trains shall be possible (even if marshalling is needed). If an incoming train to the yard is delayed there is a risk that the wagon will miss its connection, therefore the wagon may be rebooked to a later departure. There is also a risk that a delayed arrival will have implications on the departing trains and that delays of incoming trains are “transferred” to departing trains. In Figure 16 and Figure 17 this is investigated in two different ways. For each departure, we have found the wagon in the train with the smallest connection time, (i.e. lead time from wagon arrival to wagon departure) and relates this to the median deviation of the departure time. Each bar represents a 1-hour lead-time interval (1-2 hours lead time, 2-3 hours, and so on). In Figure 16 the bars (x-axis) represent the planned lead time according to the timetable of the trains the wagon was transported in; we can see that short
Earl
y d
epar
ture
s
Del
ayed
dep
artu
res
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 48 | 85
(planned) connection times slightly decrease the earliness of the train departures. In Figure 17, the bars represent the time from the actual arrival to the planned departure; we can see that short (actual) connection times have an implication on the departure time deviation and that the earliness of the train is clearly reduced when the connection time is under 4 hours.
Figure 16: Dependency between lead times (hours) for wagons and departure time deviation (minutes) - according to timetable.
Figure 17: Dependency between lead times (hours) for wagons and departure time deviation (minutes) - according actual arrival times (i.e., including consideration to early/late train arrivals).
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 49 | 85
The locomotive circulations are planned well in advance, meaning that when a locomotive arrives at the yard it is in advance planned in which train the locomotive should depart (unless it is going into a workshop). The connections between arriving and departing trains are planned so that the locomotive should be able the make the connection. However, in case of a delayed arrival, this may have effects on the departure time as the lead time may become too short. In Figure 18 the dependency between locomotive lead time and departure time deviation is illustrated. The lead time (in minutes) is calculated from the actual locomotive arrival (w.r.t. delays and early arrivals) and the scheduled departure times5. The figure illustrates that if the connection time is short, the median of the departure time delay increases.
Figure 18: Dependency between lead times (minutes) for locomotives and departure time deviation (according the actual arrival times).
8.5. Load of the yard Next, we investigate how the load of the yard correlates with departure time deviation. The load of the yard can be measured in several ways and in this section we use three different ways: number of wagons on the yard, number of simultaneous trains on the yard and size of “fan-in” of the departing trains.
5 The lead time can be calculated in several ways: From scheduled arrival to scheduled departure, from actual arrival to scheduled departure or from actual arrival to scheduled departure. Here we illustrate the second version: from actual arrival to planned departure. The reason for using this version of lead time interpretation is partly that it gave clear results, short connection times (which may be a result of delayed arrival) can have an effect on the departure time, and partly because this interpretation can be used to predict the departure delay, in difference to the third version, which have a direct dependency on the departure delay and can therefore not be used in any prediction.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 50 | 85
Figure 19 illustrates the correlation between number of wagons on the yard and early/late trains 6. Each group of bars represents an interval of number of wagons. The purple bars represent early trains, red is delayed trains and yellow is trains that are on-time, and the length of the bars represent the percentage of all departures. The diagram show that for yard loads up to 175 wagons, the early departures are most common, but for yard loads over 200 the early departures are less common, and for yard loads of 250 and more late departures are as usual as early departures.
Figure 19: Number of wagons on the yard and early/late trains.
The second way we investigate the load of the yard is by studying the number of concurrent departing trains on the yard. This is calculated by studying at all wagons that are on the yard and find the departing trains that they are booked in. The number of concurrent trains is calculated as the number of departing trains that all the wagons on the yard are planned to depart in. Figure 20 illustrates the correlation between number of concurrent trains and the departure time deviation (median). The diagram shows that the departure time deviation does not seem to depend on the number of concurrent trains. For very large number of concurrent trains (more than 35) there is an increase of the delay. However, these are very infrequent and in those cases it is also questionable what is the root cause – is the train late as a result of the number of concurrent trains, or is the high number of concurrent trains a result that there are large delays (caused by e.g. problems on the line outside the yard)?
6 The number of wagons includes the total number of wagons both in classification bowl and in arrival/departure yards.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 51 | 85
Figure 20: Dependency between number of concurrent trains on the yard and departure time deviation. Blue bars represent median departure time deviation (left y-axis) and orange line represent number of observations (right y-axis).
The third way we investigate the yard load is by studying the size of “fan-in” of the departing trains. The size of the fan-in is the number of arriving trains that contribute with wagons to a departing train. Figure 21 illustrates the correlation between size of fan-in and the departure time deviation. We see that there is a tendency that trains with very small fan-in are earlier. This is very likely related to the same factors that we showed in Figure 12 and Figure 13, namely that the train departure depends on the train load.
Figure 21: Dependency between size of fan-in and departure time deviation. Blue bars represent departure time deviation for different sixes of fan-in (left y-axis), orange line is number of observations (right y-axis).
In general, the correlation between load of the yard and the departure time deviation is not as
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 52 | 85
clear as expected. There can be several causes for this. Firstly, the yard is planned to be able to handle a certain amount of traffic, and as far as the yard is not operated close to its limits, the load does not matter for the departure time. Secondly, in occasions with high load, the staff at the yard adapt their working strategies so that the yard loads can be handled without an increase of the average departure delay.
8.6. Predicting departure time with machine learning To analytically study the relation between the input factors and the resulting departure time deviation we made two experiments. Firstly, we calculated the statistical correlation between input factors, and secondly, we made a prototype of a machine learning algorithm to predict the departure times. An interesting side result from the machine learning algorithm is also a quantitative measure indicating how much the input factors influence the departure time deviation. The pairwise correlations between all factors are displayed in Figure 1. The correlation values are between +1 and -1, values closer to 0 indicate weak correlations, while values closer to +1 or -1 indicate strong positive or negative correlations. Thus, stronger green or red boxes represent stronger correlation, while more yellowish represent weaker correlations. The top row (and first column) represents the departure time deviation, and the other columns are the input factors. (The diagonal is the correlation with the factor itself, which is of course very strong.) As seen in Figure 1, there is a very strong correlation between the time for k-report and the departure time deviation, as already illustrated in Figure 15. However, the correlations between departure time deviation and other input factors are rather weak. An explanation to this can be that this correlation measure only captures the pairwise correlation, while the dependency between the input factors and the departure time deviation is more complex. Another explanation is that several of the factors seem to have a threshold behavior on the departure time, as illustrated in several of the diagrams in this report. For example, in Figure 18 we illustrated the dependency between locomotive lead time and departure time deviation, and there it seemed to be a strong dependency if the lead time is very short, but for longer lead times, there was no dependency at all. Very likely, the pairwise correlation analysis made here could not capture such threshold effects.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 53 | 85
Figure 22: Correlation between time deviation for departure time and all other factors
Using all the factors described in this report, we trained a machine learning (ML) algorithm to predict the departure time deviation. As a first experiment we chose Random Forest Regressor7 which is a decision tree-based ML method. We have used scikit-learn library in Python to apply the Random Forest Regressor and split the data into a training set and an evaluation set. Training was performed on 80% of data and the evaluation was made on 20%. The purpose of training a ML model is to find a connection between the variables/features and train departure deviation. In the next stage the trained model was tested using the testing data to determine its accuracy.
7 See https://medium.com/datadriveninvestor/random-forest-regression-9871bc9a25eb
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 54 | 85
Figure 23 illustrates preliminary results from the prediction algorithm. The x-axis represents different departures and the y-axis represent the departure time deviation. By observation, we can see that the algorithm to some extent could predict the actual departure deviation time, but the algorithm had problems to predict the large deviations. More evaluation of the machine learning algorithm will be made in the future. One method to improve a ML algorithm is to understand feature/factor importance to the output. There are different approaches to interpreting feature importance for different ML algorithm. Figure 24 Illustrates the impact of different factors on the departure time when using machine learning to predict the departure deviation. We have used the mean of SHAP (SHapley Additive exPlanations) (Lundberg and Lee, 2016) to rank the factors importance in descending order. Each bar represents one factor, and the length of the bar represent the average impact in minutes to the deviation time. The diagram shows that the connection time for locomotives, time of day, destination and train weight were among the factors giving the largest impact.
Figure 23: Predicting departure time with machine learning. Blue line represents actual departures, red line represents predicted departure deviations.
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 55 | 85
Figure 24: Weight of different factors when predicting departure time with machine learning. The longer bar, the more impact does the factor have.
The machine learning algorithm for predicting departure time deviation is an introductory experiment that is to be refined in future work.
8.7. Conclusion In this study we have investigated several factors that have an implication on the deviation of the departure times from the yard. By inspecting diagram illustrating this, a conclusion is that the departure time deviation is more strongly dependent on some of the investigated factors, like destination, time of day, k-report time, train load, number of wagons on the yard, connection time for wagons, connection time for locomotives. A future work is to continue the dialog with the staff at the yard to get feedback regarding the results and to find if the results can be used to improve the processes at the yard. The statistical correlations between departure time deviation and the factors are generally very weak, except from that time for k-report is very correlated to the departure time (both for early and late trains). Most likely, the week statistical correlation is a consequence from that there are too many factors that concurrently have implications on the departure time and the threshold effects the many factors seem to have. We have made experiments using a machine learning algorithm to predict departure time deviation based on all different factors. Initial experiments indicate that this method to some extent can predict departure time, but the method has difficulties in predicting large deviations. Using feature importance method, we could rank the impact of different factors on the predicted deviations. The preliminary result shows the connection time for locomotives and time of day have
G A 8 2 6 2 0 6 F R 8 2 - W P 0 3 - D - T R V - 0 0 5 - 0 2 P a g e 56 | 85
largest impact on departure time. The results with the machine learning algorithm for predictions is promising and should be refined in future work.
8.8. References Himmelspach, R., Gunter, A., Streicher, T., Wahlborg, M., Lucke H., Albrecht, T., Kordnejad, B.,
Joborn, M., Gestrelius, S. (2017), Real-time yard management - Description of automation/optimisation requirements and capabilities of decision making process in Marshalling yards and Terminals, 2017. Project report (Delivery 2.1) from project ARCC, 2017.
Lundberg, S. M., Lee, S-I. (2016), A unified approach to interpreting model predictions. Advances in Neural Information Processing Systems, 2017.
Peterson, A., Wahlborg, M., Häll, C-H., Schmidt, C., Kordnejad, B., Warg, J., Johansson, I., Joborn, M., Gestrelius, S., Törnquist Krasemann, J., Josyula, S.P., Palmqvist, C-W., Lidén, T., (2019), Analysis of the gap between daily timetable and operational traffic, Project report (Deliverable 3.1) from project FR8Rail II, Linköping University. Full-text link: http://www.diva-portal.org/smash/get/diva2:1391876/FULLTEXT01.pdf
≤ 3 > 3
t
t
Höör (Hö)
Stehag (Sg)
Ronne
by (Rb)
Mörrum (M
ru)
Mellby (Mlb)
Attarp (Atp)
Tjörnarp (Tö)
Önnes
tad (Ö
nd)
Vätteryd (Väd)Sösdala (Söla)
Sandbäck (Sak)Fjälkinge (Fki)
Bräkne-H
oby (
Bhb)
Karlskrona C (Ck)
Vinslö
v (Vö
v)
Bergåsa (Båa)
Nättraby (Nät)Ång
sågs
mossen (
Åmn)
Malmö C (M)
Lund
C (L
u)
Eslöv (E)
Karlsh
amn (
Kh)
Bromölla (Bml)Sölvesborg (Sög)
Hässleholm (Hm)
Gullberna (Gua)
Vekerum (Vru)Blekingeku
stbanan
Skånebanan
SH
HH
H
M
M
Stillerydshamnen
Nymölla (Nym)
KristianstadWestern Skåne
Karpalund (Kap)Kristianstad C (Cr)
Kristianstad
GBG (Crgb)
Kristianstads dp
Kristianstad
50
60
70
80
90
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Perc
enta
ge o
f on-
time
train
s
Disturbance scenario number
ALG1 ALG2
[3, 10)
[10, 30)
≥ 30∗∗
∗
≥
≥≥
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
≤
di u
d = 16 d = 8i = 2 i > 10
i = 28 u = 4i = 14 u = 1 u = 7
d u i
≥ 10
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
≤
>
≥ 25 ≥ 4
