Optimization model for selection of switches at railway stations

(1)

Optimization model for selection of switches at

railway stations

Department of Mathematics, Linköping University Sam Olsson

Credits: 32 Level: A

Supervisor: Tomas Lidén,

Department of Science and Technology, Linköping University Examiner: Elina Rönnberg,

Department of Mathematics, Linköping University Linköping: 2021

(2)

(3)

Abstract

The goal of this project is to implement and verify an optimization model for finding a min-cost selection of switches and train paths at railway stations. The selected train paths must satisfy traffic requirements that commonly ap-ply to regular railway traffic. The requirements include different combinations of simultaneous and overtaking train movements. The model does not rely on timetables but does instead utilize different path sets that are produced via al-gorithms based on a network representation of the station layout.

The model has been verified on a small test station and also on the real station layout at Katrineholm. These tests show that the model can solve the prob-lem for mid size stations with through traffic. In addition, we have performed a literature study regarding maintenance problems for switches and crossings. We have also looked at articles regarding the scheduling and routing of trains through railway stations. Finally we present some possible ways to further improve the model for more realistic experiments.

Keywords:

Railway station design, Optimization, Integer programming

(4)

(5)

Sammanfattning

Målet med detta projekt är att implementera och verifiera en optimeringsmodell för val av spårväxlar och tågvägar med minimal kostnad på järnvägsstationer. Tågvägarna ska uppfylla en uppsättning vanligen förekommande trafikkrav som gäller för normal järnvägstrafik. Dessa krav inkluderar kombinationer av sam-tidiga tågrörelser och förbigångar. Modellen utgår inte från tidtabeller utan använder istället vägar som produceras med hjälp av algoritmer baserade på en nätverksrepresentation av stationen.

Modellen har verifierats på en mindre teststation och även den riktiga stationen i Katrineholm. Dessa tester visar att modellen kan lösa problemet för medelsto-ra stationer med genomfartstmedelsto-rafik. Utöver detta har vi utfört en littemedelsto-raturstudie om underhållsproblem rörande spårväxlar. Vi har också tittat på artiklar gällan-de schemaläggning och spårtillgällan-delning av tåg genom järnvägsstationer. Slutligen presenterar vi ett par utvidgningar av modellen som kan användas för mer rea-listiska experiment.

Nyckelord:

Design av järnvägsstationer, Optimering, Heltalsprogrammering

(6)

(7)

Preface

Firstly I want to thank my supervisor Tomas Lidén for his enthusiasm in helping me with this project and also introducing me to the subject of railway traffic. I also want to thank my examiner Elina Rönnberg for taking on the project on such short notice. Thank you to Martin Jirenius for always being available with technical support and words of wisdom. Lastly I want to thank Filippa Daniels-son for always believing in me and making life during a pandemic bearable.

(8)

(9)

Introduction

Railway traffic is steadily expanding in both Europe and in Sweden. Increasing traffic flow means that planning and scheduling of traffic also must adapt with new research and more effective methods. This is also true for maintenance since more traffic means more strain on individual elements of the railway. One way of reducing maintenance costs of railway stations is to reduce the amount of switches that need maintenance. This is a problem that takes careful planning considerations since most switches are needed to maintain the traffic flow. Optimization is an important tool that can be used to help plan production, transportation, design, or to make other complex decisions. In this project we will be implementing and testing an optimization model that chooses the minimum amount of switches needed to uphold certain traffic requirements.

1.1 Background and motivation

This project is based on results presented in the STAPLA-F research report [5], conducted by Linköping University and Trafikverket. The report recommended to study methods that from given traffic requirements and an existing station layout can identify the most promising or even optimal simplifications and re-designs of mid-size and large railway stations.

The report shows that the yearly maintenance cost for switches in Sweden is about 100 KSEK/switch. It also shows that there is a great potential to reduce the amount of switches in some networks. It is stated that maintenance spend-ing on switches and crossspend-ings could be reduced by about 10%, which would

(12)

2 Chapter 1. Introduction

translate to 70-80 MSEK/year. The frequency for delay causing failures was also shown to be higher for switches than for both track and catenary failures. Methods for finding redundant switches at railway stations is an area that has not previously been explored in the research literature. A model that can per-form this task would be beneficial both when planning new railway stations and when analysing older stations.

1.2 Purpose

The aim of the project is to implement an optimization model for selection of switches at railway stations and to test the model on various problem instances.

1.3 Limitations

This project only considers one small example network and the network for Katrineholm. The reason for choosing Katrineholm is because it is a mid size station where many different traffic requirements can be performed.

We do not allow trains to change direction on the station. Every track is able to house exactly one train, which means that the lengths of the tracks are not considered. No timetables are used and the station layouts do not consider distances, only connections between switches. Furthermore the model is only tested visually on the smaller station and Katrineholm.

1.4 Approach

The implementation of the model is done in Python/Gurobi and particular points of interest are input formats, generation of paths, visualisation and val-idation of the solution. A number of computational experiments with varying test instances are done in order to test the implementation and to analyze the real station Katrineholm. A literature study is also performed to find other approaches to address the problem description.

1.5 Contributions

An optimization model for deciding a min-cost selection of switches and train paths is implemented and verified. To implement the model we create algorithms

(13)

1.6. Overview 3

that can find all path sets necessary as input for the optimization model. These algorithms use a node-based network representation together with a set of traffic requirements to create and sort the paths into different sets.

1.6 Overview

Chapter 2 states the problem description and the traffic requirements we have chosen to focus on. We take a look at some aspects of decision making at railway stations and optimization as a tool. In Chapter 3 we present a liter-ature study regarding approaches to maintenance related questions at railway stations. We also look at different ways to schedule traffic and route trains through stations. Chapter 4 focuses on the mathematical representation of the network and presents the algorithms created for finding paths through a net-work. In Chapter 5 we present the input data and optimization model developed and implemented during the project. Chapter 6 contains verification tests on a smaller station and the conducted experiments for the station of Katrineholm. Lastly, Chapter 7 contains the conclusion of the project and also suggestions for future work.

(14)

(15)

Chapter 2

Railway station design

In this chapter we explain the terminology related to railway stations. We look at the network representation of Katrineholm and discuss different problems with removal of switches and evaluation of stations. The chapter then presents the problem description related to different traffic requirements. This is followed by a view into optimization as a decision support tool.

2.1 Stations and their usage

Railway stations are facilities where passenger and freight trains stop to pick up and drop off passengers and goods. One can say that they act as interaction points for passengers, goods and trains. There are different kinds of stations including starting stations, ending stations and junctions. They can be smaller and quite simple with only one platform. They can also be big with multiple platforms and combinations of tracks to reach them, and also multiple connect-ing lines. What they all have in common is that they can be explained through networks consisting of tracks and switches.

A track is a structure made of rails that enables trains to move. Switches are used to allow trains to pass from one line of tracks to another. There are many different kinds of switches including slip switches, crossovers, three-way switches and more. In this project we will be looking at three-way switches which means that a switch is a connection point between three different tracks. A simple illustration of how tracks interact with three-way switches can be seen in Figure 2.1.

(16)

6 Chapter 2. Railway station design

Figure 2.1: An example of how tracks and switches are connected. An example of a railway station can be seen in Figure 2.2. This is a network representation of the station in Katrineholm which is connected to the lines towards/from the cities Flen, Hallsberg and Norrköping. Katrineholm also has a railway yard which is a collection of tracks for storing, sorting, or loading and unloading freight wagons.

Figure 2.2: Schematic network structure of Katrineholms railway station. Railway stations usually have many trains passing through every day. This puts pressure on maintenance, which is not always easy to perform since you need to stop traffic on segments to replace or service old parts. Maintenance could

(17)

2.1. Stations and their usage 7

instead be done during the night when there is less traffic. This would however increase the maintenance cost.

An alternate way of reducing maintenance is to reduce the amount of objects that need maintenance. It was shown by the STAPLA-F research report [5] that there is a potential cost reduction to be gained by removing certain switches from the network of Katrineholm. This means that there is less need for main-tenance which in turn means that there is less need for interruption in traffic. The problem is how to determine whether or not removal of redundant switches is possible and also how to find potential switches that could be removed. One must also remember that removing switches reduces the flexibility of the traf-fic flow. Some switches are needed to reach certain platforms or uphold certain connections for trains. Other switches may be used for managing disturbed situ-ations where one or more switches are unavailable because of failure or scheduled maintenance. There may however exist switches that are redundant and seldom used during traffic.

Decisions like these could either be made during construction of new stations or evaluation of old stations. Design of new stations occurs rarely but offer more flexibility which means that we can evaluate many different layouts. The layout chosen will most likely remain for a long time which means that the evaluation step is important. Older stations are harder to change since we do not want to lose our old routes. It is still motivated to look at older stations since there may exist potential for improvement. According to Trafikverkets web page [20] the planning period for transport infrastructure is twelve years with revision of the plan every four years. This means that it could take several years to remove a switch after deciding that it is redundant.

Another important consideration is the life length of individual switches. Switches are removed and changed after a specific time that varies between different switches. Trafikverket [21] state that a general life length for switches is about 10-30 years depending on the type of switch and also other factors like strain and maintenance. They also show that the proposed yearly cost for changing switches during the time period 2013-2022 was between 400-600 MSEK. If some switches are close to being removed due to planned life length then that might be a good time to change the structure of the station as well.

Station design is first and foremost decided by the traffic requirements that the station should be able to handle. It is therefore important to have a model that can describe these requirements well.

(18)

Traditionally, timetables are used when analysing traffic flow. We are how-ever looking at design changes that will take effect more than 5 years into the future and for switches that will be used for 10-30 years. This means that we do not have a timetable to look at. However, we can make predictions of the train traffic patterns and flows, which will pass through the station during these years. This prediction can then be used to find switches that will be used more regularly than others.

2.2 Problem description

In Figure 2.3, we illustrate the layout of a small example station. The locations are start- and end nodes in the network, denoted Li ∈ {L1, L2, L3, L4}. They

represent different ways to enter and exit the station. A switch is, as stated before, a node that connects three different tracks. One of these three tracks is what we call a diverging direction, denoted dk ∈ {d1, d2, d3, d4, d5, d6, d7, d8}.

They refer to the tracks that are used to guide a train in a new direction. We can now define a path as an ordered set of nodes from a start node to

Figure 2.3: The example layout for a small station.

an end node. Another way to describe a path is an ordered set of tracks from a start node to an end node, but we will not be using this second definition in this project. These two different definitions are however both valid. We have chosen the node definition because it made it easier to get a visual understanding of the network early on in the project.

(19)

2.2. Problem description 9

A traffic relation is a pair of locations indicating an entry and exit point for a particular train. The requirements that can be imposed on a railway station when trains enter and exit are applied over these traffic relations. Some re-quirements only refer to single relations while others refer to pairs of relations. This could be applied further with triple pairs of relations and so on but we will limit ourselves to the following five requirements (labelled as traffic requirement A-E), summarised in Table 2.1.

Traffic requirement A handles basic relations, which means that a train must be able to enter the network from a start node and leave the network at an end node. This is illustrated in Figure 2.4a where a train enters the network from n1 and leaves the network in n19.

Traffic requirement B handles overtaking relations, which means that one train needs to be able to pass the other train when both trains originate from the same start node and leave through the same end node. This means that the two paths need at least one differing element so that one train can stop while the other train passes by. This is illustrated in Figure 2.4b where two paths enable an overtaking from n1 to n19.

Traffic requirement C handles simultaneous relations, which means that it should be possible for traffic to run on two relations without interfering with each other. This is illustrated in Figure 2.4c where we create a path from n2 to n20 and

another one from n19 to n1. Two paths are seen as simultaneous if they share

no element.

Traffic requirement D handles overtaking with simultaneous relation, which merges the previous requirements. We say that two trains need to be able to perform an overtaking on one relation while a third train passes by simul-taneously to both trains on another relation. This is illustrated in Figure 2.4d where we perform an overtaking on the relation starting from n19and ending in

n1at the same time as a train simultaneously passes by on the relation starting

from n2 and ending in n20.

Finally, traffic requirement E handles overtaking with simultaneous overtak-ing, which takes requirement D one step further. Here we say that two trains need to be able to perform an overtaking on one relation while two other trains perform an overtaking on another relation. These two overtakings also need to be completely simultaneous to each other. This is illustrated in Figure 2.4e where we perform two overtakings with different start- and end nodes and with no common elements between the two relations.

(20)

(a) Basic relation. (b) Overtaking relation. (c) Simultaneous relations.

(d) Overtaking with simultaneous relation.

(e) Overtaking with simultaneous overtaking.

(21)

2.2. Problem description 11

Table 2.1: Different traffic requirements.

A. Relation coverage, i.e. at least one path must be selected for each traffic relation.

B. Overtaking possibilities, which means that for a given overtaking relation there must be at least two paths selected that have the same origin and destination but differing intermediate parts. The intermediate parts must be of sufficient length to allow for a train to stop along one path and be overtaken by a train on the other path.

C. Simultaneous traffic relations, which means that for a given rela-tion pair there must be at least one path for the first relarela-tion that has no overlapping segments with a selected path for the other relation.

D. Combined overtaking and simultaneous relation, which means that at least two paths in the overtaking relation are required to be non-overlapping with one path in the simultaneous relation. E. Combined overtaking and overtaking, which means that at least two paths in the first overtaking relation are required to be non-overlapping with at least two overtaking paths in the other rela-tion.

The problem description can now be stated as follows. Given

• a network representation of a railway station (locations, switches and di-verging tracks),

• a set of traffic relations (between locations), and

• all possible paths (over switches) for these traffic relations,

decide a min-cost selection of switches and paths such that all traffic require-ments are satisfied. The goal is to minimize the amount of switches used and the reason for stating it as a min-cost problem is that it enables us to introduce different weights. We could for example say that older switches are worth less since they may be replaced soon. We could also test the importance of individ-ual switches by raising their weight and see if the model still chooses them. Note however that we are not considering the scheduling order of train paths which will be done in a timetable. One could calculate the time for specific relations and overtaking relations in the networks and use this to create a schedule for all relations. We will however not consider time in this project.

(22)

2.3 Optimization

Optimization [6] is an important tool that can be used to help plan production, transportation, design, or to make other complex decisions. Examples include min- and max flow problems in networks that can be used to decide how many resources to send from point A to point B in a graph. Another common example is the Chinese postman problem where we want to find the shortest path that uses every edge in the network and also returns to the starting point.

Some practical applications of optimization are route planning for trucks, large-scale production problems, or more closely related to railways, distribution of empty freight wagons. In the last example the problem consists of choosing where to send the empty freight wagons and what trains to use for transporta-tion. Points of interest are of course the timetable and the capacity of the trains, but also the upcoming need for redistribution in the coming days. There are of course many more examples of how optimization can be used to solve everyday problems for companies and people everywhere.[7]

Optimization can handle complex problems with big search spaces that are too hard to solve manually. It can also be used to model intricate constraints that are hard to grasp intuitively. Katrineholm is not a big station and we can find redundant switches with manual analysis. With optimization however, we can prove that the solution we find is the best possible one. A model that can be used on Katrineholm can also be used, or at least modified to be used, on bigger and more complex stations.

(23)

Chapter 3

Literature study

The problem description originates from the need to find switches that can pos-sibly be removed from our networks. One reason, as explained earlier, is because of maintenance of these switches which is costly and also closes down part of the network during the maintenance work.

In Section 3.1 we look at different approaches to address switch maintenance problems. These articles use different methods to produce maintenance strate-gies and also reduce the need for maintenance on switches and crossings. Sec-tion 3.2 presents different ways to schedule traffic and route trains through stations. These articles use optimization, graph theory and simulation. Most of them also use existing timetables as input data.

3.1 Switches and crossings

The literature provides different discussions on lifetimes and design strategies for switches and crossings (S&C). These previous works show that there is a current discussion on how to reduce the need for maintenance on S&C. There are also several articles discussing how to improve maintenance methods. In Rama Andrews (2013) [8] we see an attempt to find efficient and cost-effective asset management for individual S&C components based on historical failure data. The goal was among other things to find cost-effective and efficient maintenance strategies for S&C. They found that ineffective maintenance can be considered a strong influence on possible early life failures.

(24)

14 Chapter 3. Literature study

We find further discussion on maintenance for switches in Bukhsh et al. (2019) [9]. This article proposes machine learning as a way to predict maintenance need for railway switches. Multiple models were trained and evaluated to predict, among other things, the need for maintenance. The best model managed to correctly predict the need for maintenance in 86% of the attempts. It is stated that future work could include developing regression models in order to also estimate the best time to perform maintenance.

We find another line of arguments in Hegedüs et al. (2018) [10] where it is stated that rather than scheduling maintenance actions based on operating hours or service volume, actions should be taken when it is is really needed. Current state-of-the-art maintenance is usually performed as preventative maintenance carried out at given periodical intervals. This article proposes that development of new maintenance systems, including monitoring and diagnostic technologies, will play a key role in the improvement of railway safety operations. The ar-ticle also suggests some tool sets for data collection, processing and presentation. Another way to reduce the need for maintenance of S&C is of course to im-prove their design. This is discussed in the PhD thesis by Pålsson (2014) [11]. In this thesis Björn A. Pålsson develops and demonstrates different methods for simulation-based optimization of the design of S&C. The impact force at crossings during through routes is noted to be an important problem and the possibilities to optimize crossing geometry are investigated.

3.2 Traffic planning

A common subject in the literature is how to schedule and reschedule trains entering and leaving railway stations. Some of them try to increase flexibility in the traffic while others try to find time effective methods to solve the problem. These methods typically involve different kinds of optimization or simulation, but also graph theory. We can also read about the term robustness which has varying definitions but is used as a measure of traffic delays when talking about timetables.

In the book Handbook of Optimization in the Railway Industry [13] we are introduced to the concept of periodic timetabling. This means that for a cer-tain stretch of time during a day, all events are planned to recur periodically. A big reason for scheduling this way is because of the dependability for the

(25)

cus-3.2. Traffic planning 15

tomers. The book also introduces the standard optimization model for periodic timetabling, called Periodic Event Scheduling Problem (PESP). It then goes on to show how PESP can be modelled and solved for multiple lines at different periods which shows how mathematical optimization can be used for day to day scheduling. PESP is however meant to be used on more cyclic time schedules like the one used in subway systems. Cyclic schedules can be found in railway systems but not in the timetable of Sweden as a whole.

In Dewilde et al. (2013) [14] the authors aim to increase robustness of rail-way systems by focusing on the potential of the available capacity. They look at routing of trains through complex station zones, timetabling and also plat-form assignments. Three algorithms, or modules, are used in order to find the most robust solution and the goal is to find one where none of the modules can find any new improvement. Simulation is then used in order to see if and how much the performance has changed.

In Caimi et al. (2011) [12], the authors look at microscopic models, which are detailed networks of smaller railway segments. They introduce a new model to reduce the computation time for solving train-scheduling problems to opti-mality. They do this by selecting one path for each train as efficiently as possible without creating conflicts. This is done by introducing a resource tree where each train has a start- and end point and includes all possible ways to travel between them. The trick is to combine all trains and give them a route. This is done using an Integer Linear Programming optimization model.

An example of the use of graph theory can be found in Jovanovic et al. (2020) [18]. This article presents an optimization model that provides a theoretical capacity for railway stations in cases where there are no details regarding train sequences or timetables. The model constructs a route incompatibility matrix which rep-resents train routes that can not be performed simultaneously. This matrix creates a graph such that every train route is presented as a vertex connected to routes that share at least one common element of the infrastructure. The goal is to color all vertices of the graph using a minimal number of colors. This ensures the shortest infrastructure occupation time from the running times of all routes. This method is stated to be useful for comparing different conceptual designs for railway stations.

In Lusby (2006) [15] the problem of routing trains through complex railway networks is modelled as a set packing problem. It can then be solved by updat-ing the dual problem with violated cuts and removal of unnecessary constraints. The method was deemed to be computationally efficient and very promising,

(26)

16 Chapter 3. Literature study

and they also presented a number of different directions for future work. Another article related to both maintenance and rerouting is Vansteenwegen et al. (2016) [16]. This article focuses on cases where planned maintenance interventions cause unavailable tracks. It presents algorithms for rerouting, re-timing and cancelation of trains in order to obtain a robust schedule, or minimize the decrease in service level to the passengers. A simulation model was used to measure different performance indicators. One mentioned weakness is that the impact of cancelations is not considered in the algorithm which can produce sub-optimal solutions from the perspective of the railway company.

Finally, in Zwaneweld et al. (2001) [17] we find an example of a branch-and-cut algorithm. The article improves on a previous model for routing trains through train stations by including shunting decisions and preferences of trains. This is done for both platforms and routes. The algorithm in question solves the prob-lem to optimality and the article also describes several preprocessing techniques for reducing the problem size. A description of different operational processes at railway stations is also provided.

3.3 Summary of the literature study

We have seen that maintenance scheduling of S&C is a subject with several different approaches. The articles use historical data to analyse reliability of S&C and predict the future need for maintenance. Both the cost-efficiency and asset management for individual S&C are mentioned as motivation for doing research in this area. The literature also mentions the need for maintenance by changing the design of S&C. However, none of the articles in Section 3.1 mention reducing the need for maintenance by removing redundant switches. In Section 3.2 we look at different ways to schedule and route trains through railway stations. The literature is related to our idea of routing trains through a station according to different relations, although many of them rely on timeta-bles to describe the traffic flow. In our case, we want to be able to choose exactly what relations to look at in order to see what switches are necessary for every route. The exception is Jovanovic et al. (2020) [18] where we see a model that constructs a train route matrix for routes that can be performed simultaneously. This is done without the need of train sequences or timetables. This method could potentially be used to compare different designs for railway stations with respect to removed switches. Another discovery is that simulation often is mentioned as a tool for testing and evaluating the models. This could

(27)

3.3. Summary of the literature study 17

also work for our problem and is a potential alternative to our optimization approach.

The literature study shows us that our problem is previously unexplored. Our goal is to find an evaluation tool for analysing the importance of individual switches at railway stations. We also want to be able to do this without having to rely on specific timetables, as opposed to what is mostly found in the research literature.

(28)

(29)

Chapter 4

Path generation

This chapter first describes the chosen network representation for railway sta-tions. Then we describe the algorithms for finding all paths in the network and sorting them into sets used in the optimization model.

4.1 Network representation

To understand the proposed path-finding algorithms we need to look at the network representation. In graph theory it is common to represent a graph network as an adjacency matrix. In the book Graphs and Matrices (R.B Bapat) [1] we find the following definition.

Let G be a graph with V (G) = {1, . . . , n} and E(G) = {e1, . . . , em}.

The adjacency matrix of G, denoted by A(G), is the n × n matrix defined as follows. The rows and the columns of A(G) are indexed by V (G). If i 6= j then the (i, j)-entry of A(G) is 0 for vertices i and j nonadjacent and the (i, j)-entry is 1 for i and j adjacent. The (i, i)-entry of A(G) is 0 for i = 1, . . . , n.

We have chosen to define the network as a directed zero-one adjacency matrix where a non-zero element Nij indicates a directed edge i, j ∈ V (G). This may

seem like an odd choice since tracks can be used in both directions. However, in this project we have limited the tracks to one direction per relation which means that trains can not change direction on tracks while travelling from one location to another. After the paths in one direction have been found we simply invert them to obtain the paths for the opposing direction.

(30)

20 Chapter 4. Path generation

In this simple example with five nodes {n1, n2, n3, n4, n5}we have the matrix

      0 1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0       ,

which is also illustrated in Figure 4.1. The first row indicates that you can travel from n1 to n2 or n3. The second row only contains zeros which means that we

can not travel anywhere from n2. We can however travel from n3 to n4. Node

n5is disjoint so we can not travel to it or from it. We can use these matrices as

input data to create paths between locations. To make the data format more compact we use the equivalent representation

      {2, 3} {} {4} {} {}      

where each element is a set that includes all nodes that can be reached from node i, i ∈ V (G). In the case where you can not travel anywhere the element is empty. This way of looking at a network works fine when considering simpler stations. To find the paths in the opposite direction we can simply invert all paths. In Figure 4.1 for example we see that the paths go from left to right which makes inverting the network easy. However, there are stations where this representation falls short. This problem is illustrated in Figure 4.2.

There, we want to find all paths in both directions of the network. More

specif-Figure 4.1: An illustration of a directed graph.

ically, we want to find the paths for the relations {n2 → n8, n8 → n2, n1 →

(31)

4.2. Path generating algorithms 21

and n8 we can invert them to find the corresponding paths from n7 and n8.

But this would mean that we miss the path from n1 to n2 and n2 to n1. If we

instead try to find the paths from n1 to n2and n7 we miss out on the paths to

and from n8. This is a problem that arises when using a directed network. Our

solution is simply to create two networks for the station, as shown in Figure 4.3, and inverting them both to find all paths. This simple solution may however be insufficient for larger and more complex stations. A discussion on this will follow in Chapter 7.

Figure 4.2: A problematic network.

Figure 4.3: Two networks to describe a station.

4.2 Path generating algorithms

To create all path sets necessary for the optimization model we first need to create the set P of all paths. The set P can then be used to create the rest of the path sets. The procedure of finding all paths in a network is presented in

(32)

22 Chapter 4. Path generation Algorithm 1. Algorithm 1: GetPaths Input: n, N P athsF romHere = [ ] if N (n) = ∅ then return n end for connection ∈ N (n) do

P aths = GetP aths(connection, N ) for p ∈ P aths do

add n + p to P athsF romHere end

end

return PathsFromHere

The algorithm GetPaths is called once for every start node in the network N. The first if-statement checks if the current node has any connections. This is the break condition which indicates that an end node has been found. In the case where the if-statement is false, the algorithm iterates over all connections and keeps looking for an end node by going deeper into the network. When it finds a node nk without connections the path becomes pk= nk. The algorithm

then goes back to the previous node and explores all the remaining possible connections. This procedure will continue until every connection related to the start node has been explored. This is illustrated in Figure 4.4 where GetPaths tries to find all paths from the previous example network. It is important to always initiate the algorithm in a known start node since we otherwise might end up with incomplete paths. When all start nodes have been examined we simply merge the different path sets and invert all paths to create P .

(33)

(a) Step 1: The al-gorithm is initiated in the start node n1.

(b) Step 2: The first connecting node n2is

found. The path [n2]

is created since n2 is

an end node.

(c) Step 3: The previous node is added which creates the path [n1, n2].

(d) Step 4: The sec-ond connecting node n3 is found. This

is not an end node which means that the algorithm keeps look-ing for connections.

(e) Step 5: The connecting node n4

is found. This is an end node which means that the path [n4] is created.

(f) Step 6: The previous node is added which creates the path [n3, n4].

(g) Step 7: The start node is added which creates the path [n1, n3, n4].

(34)

This is known as depth-first search (DFS) [2]. A DFS finds one path from the start node to an end node and then backtracks to find the rest of the paths. Another method would be breadth-first search (BFS) [2]. A BFS instead finds all neighbors to the start node before going to the next depth level. If we were only looking for one path from start to end then DFS would probably perform better since BFS would have to go through most of the graph before finding the end nodes. If we instead were looking for a path to a specific node somewhere in the network then the choice becomes harder depending on the structure of the graph. In our case we always want to explore the graph completely which means that all paths must be found. According to the book Introduction to Algorithms (T.H. Cormen) [2], the running time for both BFS and DFS is linear and since we always want to explore the whole network the choice between them comes down to an implementation preference.

Once we have acquired P we can begin organizing the data into a couple of subsets that are used in the optimization model (see Table 5.2). We begin with Algorithm 2 which creates the set Pdiv_{. This is a set that contains one subset}

for each diverging direction. Each subset contains all paths that use this spe-cific direction. A diverging direction d ∈ D = {d1, . . . , dk} is a set of one or

two switches represented as nodes. The algorithm uses the fact that paths are ordered sets of nodes to see which diverging directions d they contain.

Algorithm 2: FindDivergingPaths Input: D, P Pdiv = [ ] for d ∈ D do paths = { } for p ∈ P do

if all elements in d belong to p then add p to paths

end end

add paths to Pdiv

end

Next we have Prel_{, which is a set of paths organized by the relation each path}

be-longs to. It originates from traffic requirement A in Section 2.2. Every relation r is a pair containing a start node and an end node. All paths containing these two nodes belong to the relation. An example could be Prel _{= [ {p}

1, p2}, {p3, p4}]

where we have R = [r1, r2]and P = [p1, p2, p3, p4]. In this case the paths p1

(35)

in p1 and p2. The set Prel is derived from Algorithm 3.

Algorithm 3: FindPathsForRelation Input: R, P Prel_{= [ ]} for r ∈ R do if length(r) = 0 then add { } to Prel continue end paths = { } for p ∈ P do

if start- and end nodes in r are found in p then add p to paths

end end

add paths to Prel

end

The set Pover _{is structured in the same way as P}rel _{and originates from traffic}

requirement B in Section 2.2. This means that it has subsets for each overtaking relation. In reality, an overtaking needs to account for the length of the tracks used in the overtaking to make sure that the trains fit. This restriction will not be accounted for in this project, which means that all paths from the same relationship can be used to perform an overtaking. This is seen in Algorithm 4 where the necessary path sets are simply copied from Prel_.

Algorithm 4: FindOvertakingPaths Input: Prel, Rover

Pover = [ ] for r ∈ Rover do if length(r) = 0 then add { } to Pover continue end

add Prel_(r)_{to P}over

end

The simultaneous set Psim_{, originating from traffic requirement C in Section 2.2,}

is instead structured after the set P . Every subset represents one path p and it contains all paths that can run simultaneously as p. The routine for finding

(36)

these simultaneous paths is shown in Algorithm 5. The algorithm considers both the nodes in the paths and whether or not the tracks cross each other at some point. Every crossing is a subset of Fsim _{that contains the two nodes}

from both crossing tracks. An example of this can be seen in Figure 4.5 where Fsim _{= [{d}

1, d2}, {d3, d4}] = [{(n3, n6), (n4, n5)}, {(n7, n10), (n8, n9)}]. The

algorithm says that path i is simultaneous to path j if none of the nodes found in i can be found in j, and if the paths do not cross each other.

Figure 4.5: An example of crossing tracks in a network. Algorithm 5: FindSimultaneousPaths Input: Fsim, P Psim_{= [ ]} breakcounter = 0 for p ∈ P do Simpaths = { } for psim_{∈ P do}

if any element in p belong to psim then continue

end

for combo ∈ Fsim _do

if combo(1) or combo(2) ∈ psim _then

if combo(1) or combo(2) ∈ p then breakcounter = 1 break end end end if breakcounter = 1 then breakcounter = 0 continue end

add psim _{to Simpaths}

end

add Simpaths to Psim

(37)

Chapter 5

Optimization model

This chapter presents the input data and optimization model developed and im-plemented during the project. The inspiration is a path-based approach, similar to Paluch (2015)[4], which states the problem as a "railway network reduction problem". We have chosen to turn the model into a switch based representation. First, the introduction of section 5.2 introduces the coupling constraints be-tween the different variable types. Then the traffic requirements A-C and D-E are presented. This is followed by some improvements to the the model in the form of a new decision variable and accompanying coupling constraints. This new decision variable is then used to improve the constraints for traffic require-ment D and E. Finally some variations of the objective function are discussed. The full model can be viewed in Appendix A

5.1 Input Data

This section describes the input data used in the optimization model. Section 2.2 describes the different traffic requirements that we consider. These requirements are handled by introducing different relation sets that control exactly what combinations of relations we want to include in the model. These relation sets are shown in Table 5.1. We also need the path sets presented in Chapter 2. These sets are defined in Table 5.2.

(38)

28 Chapter 5. Optimization model

Table 5.1: The relation sets. R The set of relations.

Rsim

i The set of simultaneous relations for relation i ∈ R.

Rover The set of relations where overtaking is possible.

Rsim,over_i The set of relations that should be possible to run simultaneously with overtaking relation i ∈ Rover_.

Rover,over_i The set of overtaking relations that should be possible to run

simultaneously with overtaking relation i ∈ Rover_.

Table 5.2: Derived path sets. P The set of all paths.

P_irel The set of all paths for relation i ∈ R. Pdiv

k The set of all paths that use diverging direction k ∈ D.

Psim

j The set of all simultaneous paths for path j ∈ P .

Pover

i The set of all overtaking paths for overtaking relation i ∈ Rover.

5.2 Model

The model is a binary integer problem. This is evident from Table 5.3 where both of the introduced decision variables are binary. The variable zj is equal

to 1 if the model chooses to use path j and the variable yk is equal to 1 if the

model chooses to use diverging direction k.

Table 5.3: Decision variables. zj (binary) = 1 if path j ∈ P is selected, 0 otherwise.

(39)

5.2. Model 29

The first constraints are used to link these variables together.

yk ≥ zj ∀k ∈ D, ∀j ∈ Pkdiv (5.1)

X

j∈Pdiv k

zj ≥ yk ∀k ∈ D (5.2)

Constraint (5.1) ensures that if path j that uses diverging direction k is chosen, then corresponding diverging direction indicated by variable yk must also be

chosen. Constraint (5.2) ensures that yk only takes the value 0 when all

corre-sponding paths are inactive.

These next three constraints concern traffic requirements A-C.

X j∈Prel i zj≥ 1 ∀i ∈ R (5.3) X j∈Pover i zj≥ 2 ∀i ∈ Rover (5.4) X j0_∈Psim j ∩Pi0rel zj0 ≥ z_j ∀i ∈ R : ∃Rsim_i ; j ∈ P_irel, i0∈ Rsim i (5.5)

Constraint (5.3) represents traffic requirement A and enforces that at least one path is chosen for every basic relation in the input data. A similar structure is seen in Constraint (5.4) where at least two overtaking paths are chosen for every overtaking relation. This corresponds to traffic requirement B. The third one, Constraint (5.5), is a bit more complicated. It represents requirement C, which is the simultaneous relation. The constraint represents that if a path j belonging to relation i is chosen, then at least one path must be chosen that is simultaneous to j and also belongs to relation i0_{, which is simultaneous to}

relation i.

(40)

Constraints (5.6) and (5.7) respectively. X

j00_∈Psim

j ∩Pj0sim∩P rel i0

zj00≥ z_j+ z_j0− 1 ∀i ∈ Rover: ∃Rsim,over_i ;

j, j0 ∈ Pover i : j 6= j0, i0∈ Rsim,over_i (5.6) X j00_∈Psim j ∩Pj0sim∩P rel i0

zj00≥ z_j+ z_j0 ∀i ∈ Rover: ∃Rover,over_i ;

j, j0 ∈ Pover i : j 6= j

0_,

i0∈ Rover,over_i (5.7)

These two constraints work in similar ways. Constraint (5.6) says that if two overtaking paths from overtaking relation i are chosen then at least one path j00that is simultaneous to both previous paths must also be chosen. It also has to belong to a relation i0 _{that is simultaneous to relation i. Constraint (5.7)}

similarly says that if two overtaking paths are chosen from overtaking relation ithen at least two paths that are simultaneous to both previous paths must be chosen. In this case, both paths chosen in the sum need to belong to a relation i0 that is simultaneous to relation i.

It was however revealed through testing that these two constraints are not suf-ficient to fulfill traffic requirement D and E. Constraint (5.4) will enforce that at least one overtaking is chosen but there is no guarantee that an overtaking path pair which corresponds with sim/over Constraints (5.6) and (5.7) will be chosen. One solution to this is to introduce a new variable zover

j,j0 that tracks the

chosen overtaking path pairs and then enforce that at least one overtaking with simultaneous paths for every relation is chosen according to the requirements. This variable is seen in Table 5.4.

Table 5.4: Additional decision variable. zover

j,j0 (binary) = 1 if path pair j, j0 ∈ P_irel, i ∈ Rover is selected, 0

otherwise.

(41)

5.2. Model 31

correct path choices for overtakings with simultaneous paths/overtakings.

z_j,jover0 + 1 ≥ zj+ zj0 ∀i ∈ Rover;

j, j0∈ Pover i : j 6= j

0 _(5.8)

zoverj,j0 ≤ zj ∀i ∈ Rover;

j, j0∈ Pover i : j 6= j

0 _(5.9)

zover_j,j0 ≤ zj0 ∀i ∈ Rover;

j, j0∈ Piover : j 6= j0 (5.10) X j,j0_∈Pover i :Pjsim∩Pj0sim∩P rel i0

zover_j,j0 ≥ 1 ∀i ∈ Rover : ∃R

sim,over i ; j 6= j0, i0∈ Rsim,over_i (5.11) X j,j0_∈Pover i :Pjsim∩Pj0sim∩P rel i0

zover_j,j0 ≥ 1 ∀i ∈ Rover : ∃Rover,over_i ;

j 6= j0, i0∈ Rover,over_i (5.12)

Constraints (5.8), (5.9) and (5.10) connect the new variable to zj. Constraints

(5.11) and (5.12) ensure that at least one overtaking couple is always chosen for every overtaking relation with simultaneous relations/overtaking relations. Another problem that can arise in Constraint (5.7) is when an overtaking only has one possible simultaneous path. If one of the overtaking paths is chosen in another constraint then the path originating from the sum has to be chosen to fulfill the constraint. The solution is that Constraints (5.7) and (5.12) only will be defined when the left hand sums contain at least two elements. For con-sistency Constraints (5.6) and (5.11) are only defined when the left hand sums contain at least one element. Constraints (5.6) and (5.7) are also changed to use the new variables zover

j,j0 in the right hand side. This will further make use of

(42)

Constraints (5.13)–(5.16) now use the sets defined in Table 5.5. X

j00_∈Psim,over j,j,0 i0

zj00≥ zover_j,j0 ∀i ∈ Rover : ∃R

sim,over i ; j, j0∈ Piover : j 6= j0, i0 ∈ Rsim,over_i : len(P_j,j,sim,over0_i0 ) > 0 (5.13) X j00_∈Psim,over j,j0 ,i0

zj00≥ 2z_j,jover0 ∀i ∈ Rover : ∃R

over,over i ; j, j0∈ Pover i : j 6= j0, i0 ∈ Rover,over_i : len(P_j,jsim,over0_,i0 ) > 1 (5.14) X j,j0_∈Pover i

zoverj,j0 ≥ 1 ∀i ∈ Rover : ∃R

sim,over i ; j 6= j0, i0 ∈ Rsim,over_i : len(P_j,jsim,over0_,i0 ) > 0 (5.15) X j,j0_∈Pover i

zover_j,j0 ≥ 1 ∀i ∈ Rover : ∃Rover,over_i ;

j 6= j0, i0 ∈ Rover,over_i :

len(P_j,jsim,over0_,i0 ) > 1 (5.16)

Table 5.5: The new sets for paths related to traffic requirements D and E. P_j,jsim,over0_,i0 The set of all paths that are simultaneous to paths j and j0 while

also belonging to relation i0_{. This is defined as the combined set}

of Psim

j ∩ Pjsim0 ∩ P_irel0 , ∀i ∈ Rover : ∃R

sim,over

i ; j, j0 ∈ P over

i j 6=

j0, i0 ∈ Rsim,over_i .

P_j,jover,over0_,i0 The set of all paths that are simultaneous to paths j and j0 while

also belonging to overtaking relation i0_{. This is defined as the}

combined set of Psim

j ∩P

sim

j0 ∩P_irel0 , ∀i ∈ Rover: ∃R_iover,over; j, j0∈

(43)

5.2. Model 33

Finally the objective function is introduced. The goal is to fulfill all traffic requirements with as few switches as possible. However, yk represents diverging

directions and they use either one or two switches each. Therefore a weight that can be seen in Table 5.6 is introduced. This weight represents the amount of switches used in every diverging direction.

Table 5.6: The input data related to diverging tracks. wk The weight for diverging track k ∈ D.

F1=

X

k∈D

wkyk (5.17)

The original objective function in Equation 5.17 is designed to allow multiple uses of individual switches without a penalty cost. This means that the resulting path sets may produce extra paths that are not explicitly necessary to fulfill the traffic requirements. Two other ways of expressing the objective function would be to either find the minimum selection of paths that fulfills the traffic require-ments or the maximum amount of paths that can be chosen without changing the solution. The first alternative, in Equation 5.18 gives a solution with a min-imum amount of paths that fulfill the traffic requirements. The second one, in Equation 5.19, is interesting from a traffic planning perspective when you might be interested in alternate routes. These new functions will be referred to as the min/max-paths objective functions.

These new objective functions use a second weight to either punish or reward the model every time it chooses a new path. We want a hierarchic cost structure so that the amount of switches always trump the amount of paths. We therefore define c ≥ len(P ). All three objective functions should be minimized.

F2= X k∈D wkyk+ 1 c X j∈P zj (5.18) F3= X k∈D wkyk− 1 c X j∈P zj (5.19)

(44)

(45)

Chapter 6

Model verification

A couple of different tests have been performed to verify the optimization model. These tests have been performed on both the smaller station and the Katrine-holm station with all three objective functions. In Section 6.1 we present the verification tests and results for the smaller station. Section 6.2 contains the experimental setting for Katrineholm and the different experiments were be performed. A discussion of the results from the experiments performed for Ka-trineholm is found in Section 6.3.

We will show the optimal value for the LP-relaxation in the root node (LP-value), the final optimal value for the integer program (IP-(LP-value), the number of paths used (NOP) and the solve time. In Section 6.2 we have also looked at the number of rows, columns and non-zeros both before and after presolve. All values have been given with a maximum of two decimals. There are also figures showing the visualisation of the solution. These figures have weighted tracks which means that the tracks get thicker for every path that uses them.

Gurobi 9.0.3 [19] was installed and run on an Intel 2.1 GHz CPU and 8.0 GB RAM at 2304 MHz with the models formulated in Python 3.7. The parameter Poolgap, which determines how large a gap is tolerated in stored solutions, was set to 0.0. This means that the program stores all solutions that reach the opti-mal objective value. The search for heuristic solutions as well as presolve were also enabled.

(46)

36 Chapter 6. Model verification

6.1 Verification on small station

Tests 1.1–1.6, seen in Table B.1, were performed for the smaller station. The relations in question are R = [r1, r2, r3, r4] = [n1 → n19, n1 → n20, n2 →

n19, n2→ n20]. One important part of this station is that neither r2 or r3 can

perform any simultaneous relation with any other relation.

Test 1.1 is a verification of traffic requirement A where a train should be able to travel from a start node to an end node. Test 1.2 is a verification of traffic requirement B where overtakings are performed on all possible relations. Test 1.3 is a verification of traffic requirement C where we state that relations r1

and r4should be simultaneous to each other. Test 1.4 is a verification of traffic

requirement D in the same way as Test 1.3 but by also stating that relation r1

should be an overtaking relation. Test 1.5 is a verification of traffic requirement E as in Test 1.4 by stating that both r1and r4 should be overtaking relations.

Test 1.6 performs all possible requirements on all relations.

The results from these tests can be seen in Tables B.2– B.7 and Figures 6.1– 6.6. The complete visualisation of Tests 1.1–1.6 can be found in Appendix D. The first thing we need to look at is whether or not the model can fulfill the traf-fic requirements. NOP for F2 should be the number of relations used plus the

number of overtaking relations used. Tables B.2– B.7 show us that this is the case for all tests. We also need to look at the visual representation. In Figures 6.1–6.6 we see that the model manages to find solutions without breaking any traffic requirements. This is true for all three objective functions which means that the model has passed all our verification tests.

The LP-value and IP-value were identical for all tests for all objective func-tions except for Test 1.1 and Test 1.3 where the LP-value was slightly lower. The LP-value represents the lower bound of the solution when we relax the in-tegrality requirements. This means that our model is strong and often capable of finding the integer solution without using branch and bound. The solve time is almost always lower than 0.1 seconds. These results are to be expected from such a small station layout.

(47)

6.1. Verification on small station 37

(a) F1. (b) F2. (c) F3.

Figure 6.1: Visualisation of the chosen paths for Test 1.1.

(a) F1. (b) F2. (c) F3.

(48)

(a) F1. (b) F2. (c) F3.

6.2 Experimental setting

Tests 2.1–2.6 were performed for Katrineholm, illustrated in Figure 6.7. The first five tests are meant to check the performance of the model when applied to a more complex station. These tests can be seen in Tables C.1, C.2 and 6.1.

(49)

6.2. Experimental setting 39

Figure 6.7: Schematic network structure of Katrineholms railway station.

In Tests 2.1–2.4 we test different combinations of simultaneous overtakings and regular through traffic to see if the model can produce correct solutions. We also want to see if the solution time increases when the model is applied to a more complex station than in Tests 1.1–1.6. Another point of interest is how the size of the problem varies depending on what kind of requirements are used. In Test 2.5 we try to simulate a situation where maintenance is being per-formed on the tracks used to enter Katrineholm from Flen. This means that the traffic that enters Katrineholm from Flen and exits from Katrineholm to Flen must use the same node, n43. In Test 2.6 we use all possible relations in

(50)

Table 6.1: Relations used in Tests 2.1–1.5. Test 2.1 Hallsberg → Flen

Flen → Hallsberg

Test 2.2 Railway yard → Norrköping Norrköping → Hallsberg

Hallsberg → Flen

Flen → Hallsberg

Test 2.3 Norrköping → Hallsberg

Hallsberg → Flen

Flen → Norrköping

Test 2.4 Hallsberg → Flen

Flen → Norrköping

Hallsberg → Railway yard Test 2.5 Railway yard → Norrköping

Hallsberg → Flen

Flen → Hallsberg

6.3 Results and Discussion

First we need to verify that the solutions are correct. We do this by analysing the IP-value of F1and the NOP-value of F2for every test in Table 6.2. The

IP-value of F1 represents the number of switches used. The NOP-value of F2 tells

us the amount of paths in the minimum selection of paths that fulfills the traffic requirements. It should be equal to the number of relations and overtaking relations chosen for each individual test. We then verify visually in Figures 6.8–6.13 that the IP-value is correct and that all chosen traffic requirements are upheld.

(51)

6.3. Results and Discussion 41

Table 6.2: Results from Tests 2.1–2.6.

Test Function LP-value IP-value NOP Solve time

2.1 F1 5.00 5.00 4 0.46s F2 5.02 5.02 4 0.16s F3 4.96 4.96 4 0.17s 2.2 F1 12.00 12.00 7 0.43s F2 12.03 12.03 7 0.24s F3 11.90 11.90 7 0.13s 2.3 F1 8.00 8.00 5 0.37s F2 8.02 8.02 5 0.20s F3 7.93 7.93 5 0.22s 2.4 F1 11.63 12.00 5 0.22s F2 12.02 12.02 5 0.15s F3 11.87 11.87 5 0.17s 2.5 F1 8.04 9.00 6 0.53s F2 9.03 9.03 6 0.54s F3 8.93 8.93 6 0.62s 2.6 F1 23.00 23.00 17 0.19s F2 23.08 23.08 17 0.23s F3 22.60 22.60 27 0.17s (a) F1. (b) F2. (c) F3.

(52)

(a) F1. (b) F2. (c) F3.

(53)

(a) F1. (b) F2. (c) F3.

The model gives us the correct answer in every test and for every objective function. This means that we have verified that the model can minimize all ob-jective functions while upholding the traffic requirements. The LP-values and IP-values have a tendency to be the same as noted in Section 6.1. They do however vary for F1in Test 2.4 och 2.5. If the LP-solution is integer in the root

node then we do not need to use any branching methods.

The solve times are higher for these tests than for Tests 1.1–1.6 but still tend to be in the range of 0.2-0.5 seconds. One important thing to note in these tests is that our use of the railway yard is unrealistic. For example, performing an overtaking on the way out of the railway yard is never really done in practice. These tests are however mainly for testing the model and that is the reason why we have kept these unrealistic traffic requirements.

Now we want to look at the size of our problem both before and after presolve. This can be viewed in Table 6.3.

(54)

Table 6.3: Constraints, variables and non-zeros generated before and after pre-solve in Tests 2.1–2.6.

Test State Constraints Variables Non-zeros

2.1 Before presolve 3102 1029 7788 After presolve 2847 974 7091 2.2 Before presolve 4617 1035 15273 After presolve 2961 971 7405 2.3 Before presolve 3088 939 8539 After presolve 2814 922 7281 2.4 Before presolve 3035 939 8387 After presolve 2870 934 7771 2.5 Before presolve 5608 1245 18592 After presolve 3893 1241 10777 2.6 Before presolve 6619 1135 23107 After presolve 2934 1014 7183

We see that the number of constraints generated for Tests 2.1, 2.3 and 2.4 are around 3000. They do however increase for bigger test instances with the largest number being 6619 for Test 2.6. Since Test 2.6 uses all possible traffic require-ments it is natural that it also generates the largest amount of constraints and variables. Presolve manages to decrease this number to the range of 2800-3000 for all tests except for Test 2.5 where the number goes from 5608 to 3893. By looking at Table C.2 and Table C.3 and comparing them the number of con-straints generated in each test we see that the number of overtaking relations seem to have a big impact on the number of constraints generated.

The number of variables do not change as much, except for Test 2.6 where we see a jump from 1135 to 1014. After presolve however we see that Test 2.5 is the biggest instance with 3893 rows and 1241 columns. Test 2.5 also has the longest solve time with some margin. This could mean that the task of routing trains through the same start- and end nodes is more complex than using the normal routing options. It could also be because Test 2.5 uses fewer relations than the other tests which means that it is a more open problem.

Table 6.4 shows us how many solutions with the same optimal value that can be found for Tests 2.1–2.6. We only looked at F1 which means that the only

(55)

2.5 we only find 1 or 2 solutions which shows us that there are limited best solutions to this problem. This could also mean that some switches have higher utility than others when we look at simultaneous relations. In Test 2.6 we find 7 solutions. This means that the visualisation of F1in Figure 6.13a may be

insuffi-cient when establishing potentially removable switches. However, when looking at the different solutions we see that the unused switches in Figure 6.13a are unused in all seven solutions. This means that we can remove certain switches without breaking any traffic requirements. The unused switches are highlighted in Figure 6.14.

Table 6.4: Number of solutions found with F1in Tests 2.1–2.6.

Test 2.1 Test 2.2 Test 2.3 Test 2.4 Test 2.5 Test 2.6

Solutions 1 1 1 2 2 7

Figure 6.14: Switches found to be redundant when fulfilling all traffic require-ments on Katrineholm in Test 2.6.

(56)

(57)

Chapter 7

Conclusion and future work

In this project we have studied an optimization model for deciding a min-cost selection of switches at railway stations. This model has been implemented in Python with Gurobi as optimization solver and it has been verified with a series of tests on both a smaller station and the station in Katrineholm. We have also presented path finding algorithms that can be used to find the path sets necessary for the optimization model. Some improvements to the model have been proposed as well as two additional objective functions.

The tests show us that the model is sufficient for both the smaller example station and Katrineholm. All traffic requirements are upheld and the model manages to find the minimum amount of switches necessary. We also find a num-ber of switches that potentially could be removed without immediately breaking any traffic requirements in Katrineholm. It is however important to note that these switches may be crucial during maintenance or other disturbed situations. Recall also that Katrineholm is a mid size station with through traffic. Big-ger and more complex station layouts may require additional revisions of the model. For example, if we wish to include more traffic requirements we also need to include more constraints. Some examples of additional requirements would be parking-, or reversal of trains.

Parking means that we let a train occupy one or more tracks for a certain amount of time. In our case this would mean that one track becomes unavail-able which would have to be accounted for in the network representation by removing that specific track. The model would not be able to handle a train stopping and remaining on a track without additional constraints that handles

(58)

48 Chapter 7. Conclusion and future work

occupied tracks. This would mean that a number of paths become unavailable in the same way that some paths are unsuitable for simultaneous overtakings. Reversal of trains is the act of changing direction of a train so that it faces the direction from which it came. This is often done at triangular junctions or balloon loops and should be possible for the model to handle as long as we define the points where the train changes direction as locations.

Another interesting thought concerning the size of the model is to relate the number of switches and traffic requirements to the size of the generated prob-lem. This could be done by choosing a station and systematically increasing the number of traffic requirements used in the model. One could also try removing some switches in the network for a set number of traffic requirements.

We have only verified the model visually in these tests and this might not be possible when examining larger and more complex stations. A mathematical validation of the constraints could therefore be considered before application on new stations. This could be done similar to Kalinowski et al. (2020) [22] where they validate their Mixed Integer Problem mathematically before implementing it.

We have used two networks to represent Katrineholm. This may be unnec-essary and could result in tedious work when looking at bigger stations with more conflicting segments. It is recommended to instead find a new method for network representation that can fit the whole station into one network.

Another thing that could be implemented is track length. In this project we have not looked at whether or not trains actually have room to do an overtaking. This could be done by simply stating that shorter track combinations are not eligible for overtakings, but it could also be done by finding real data for station track lengths. Another interesting extension would be to add platform relations to the problem. This means that locations would be added at each platform and it would result in cases where we can allow trains to change direction at the station. Both of these additions would allow for more realistic tests. Further additions would be to make a more varied use of the weights in the objective functions. One could for example test removal of individual switches by adding large weights to them. These switches would then only be used if the model finds them necessary to uphold certain relations. One could also add a new objective function that includes a penalty for the model every time direction of a switch is changed. If we have used the straight direction of a switch three times and the diverging direction two times then the switch must

(59)

49

be operated at least one time and at most five times. This could be used to test the strain of individual switches resulting from usage.

(60)

(61)

Appendix A

Full model

Minimize F1= X k∈D wkyk (A.1) Minimize F2= X k∈D wkyk+ 1 c X j∈P zj (A.2) Minimize F3= X k∈D wkyk− 1 c X j∈P zj, subject to (A.3) yk ≥ zj ∀k ∈ D, ∀j ∈ Pkdiv (A.4) X j∈Pdiv k zj ≥ yk ∀k ∈ D (A.5)

zover_j,j0 + 1 ≥ zj+ zj0 ∀i ∈ Rover;

zover_j,j0 ≤ zj j, j0∈ Piover : j 6= j 0 zover_j,j0 ≤ zj0 (A.6) X j∈Prel i zj ≥ 1 ∀i ∈ R (A.7) X j0_∈Psim j ∩Pi0rel zj0 ≥ z_j ∀i ∈ R : ∃Rsim_i ; j ∈ P_irel, i0∈ Rsim i (A.8) X j∈Pover i

zj ≥ 2 ∀i ∈ Rover (A.9)

Optimization model for selection of switches at railway stations

Optimization model for selection of switches at

railway stations

Abstract

Sammanfattning

Preface

Contents

Chapter 1

Introduction

1.1

Background and motivation

1.2

Purpose

1.3

Limitations

1.4

Approach

1.5

Contributions

1.6

Overview

Chapter 2

Railway station design

2.1

Stations and their usage

2.2

Problem description

2.3

Optimization

Chapter 3

Literature study

3.1

Switches and crossings

3.2

Traffic planning

3.3

Summary of the literature study

Chapter 4

Path generation

4.1

Network representation

4.2

Path generating algorithms

Chapter 5

Optimization model

5.1

Input Data

5.2

Model

Chapter 6

Model verification

6.1

Verification on small station

6.2

Experimental setting

6.3

Results and Discussion

Chapter 7

Conclusion and future work

Appendix A

Full model