Description of a decision support tool aimed at advanced Real Time Network Management and requirements for a demonstrator

(1)

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

(2)

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

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

(6)

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

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

(8)

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

(9)

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

(10)

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

(11)

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.

(12)

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.

(13)

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.

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

(15)

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

(16)

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:

(17)

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,

(18)

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

(19)

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.

(20)

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.

(21)

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

(22)

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

(23)

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.

(24)

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

(25)

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

(26)

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

(27)

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

(28)

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

Description of a decision support tool aimed at advanced Real Time Network Management and requirements for a demonstrator

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

Table of Contents

1. Executive Summary

2. Abbreviations and acronyms

3. Introduction

3.1.

Motivation

3.2.

Outline

4. General concepts for an advanced real time network management

demonstrator

4.1.

Scope and objective of demonstrator

4.2.

Actors

4.3.

Components of a general demonstrator

4.3.1.

Digital Graph

4.3.2.

Deviation Handler (DH)

4.3.3.

Train Management System (TMS)

4.3.4.

Virtual railway

4.3.5.

Driving Simulator

4.3.6.

Driving Advisory System (DAS/C-DAS)

4.3.7.

Yard Operations Planner

4.3.8.

Demonstrator Management Tool

4.4.

Principal usage of demonstrator

4.5.

Related work

5. Concrete proposal for demonstrator

5.1.

Proposed components

5.1.1.

STEG – Electronical graph

5.1.2.

Disturbance management module (DMM)

5.1.3.

EBICOS 900/Ebisim

5.1.4.

BEST

5.1.5.

VTI train simulator

5.1.6.

C-DAS/CATO

5.1.7.

Yard Coordination System (YCS)

5.1.8.

RANPLAN Classification planning tool