Originally a heuristic based on finding the first free platform as close as possible to the delayed train’s original platform was considered for comparison. Discussions with a Network Rail Station Master established that this technique is often used to reallocate delayed trains to platforms as it minimises passenger and crew disruption. However, it was found that often it was not possible to find a suitable gap for a delayed train, especially when trying to obey the timetable planning rules detailed in Section 6.2. Appendix B shows the algorithmic details of this heuristic and gives the results of running it with different frequencies and magnitudes of delay. As can be seen, in many cases no suitable free platform could be found.
Therefore, the performance of the ACO algorithms was compared with two al- gorithms based on local search, the TS and the VNS. Both these algorithms have previously been applied to the railway rescheduling problems. Corman et al. [54]
applied a TS while Sam`a et al. [10] applied a VNS. To make the comparison fair, in both TS and VNS the same novel best-so-far ant selection method detailed in Section 6.5 is used when selecting the solution to replace the incumbent. Both of these algorithms require the use of a local search technique, which is described in Section 6.6.1 for the reallocation sub-problem and Section 6.6.2 for the resequencing sub-problem.
6.6.1
Local Search for the Reallocation Problem
In the reallocation problem the local search solutions are created by randomly chang- ing the platform for each train in the set of trains passed to the algorithm. The trains are taken in turn, so that first train 1 is assigned a new platform to make local search solution one, then train 2 is assigned a new platform to make local search solution two. This is repeated for the number of trains in the current problem (N ) giving a total of N local search solutions.
6.6.2
Local Search for the Resequencing Problem
The issue with making local search solutions for the resequencing problem is that it is important to create a set of feasible local search solutions that ensure a train is not scheduled to leave the station before the train before it on the same platform. For this reason the solutions were created using the path-preserving local search described in Section 4.2.2. The technique runs a forward pass through the list of trains and then a backward pass to obtain a reshuffled train order that is guaranteed to be feasible.
6.6.3
Tabu Search (TS)
The procedure for the TS is shown in algorithm 7. In this case the incumbent, or best-so-far, solution is compared with the best solution found in the neighbourhood of the incumbent solution. If the neighbourhood solution is an improvement it replaces the current incumbent. Solutions that have been previously considered by the algorithm are placed in a tabu list so that they are not used again.
Identifying if a solution exists in the tabu list can be computationally expen- sive. To reduce computation time the solutions are first matched with the tabu list solutions on fitness. If there are no solutions in the tabu list that have the same fitness as the comparison solution then the comparison solution is not present in the tabu list. However, if there are solutions that match on fitness they are investigated
Algorithm 7 Tabu Search
1: Input neighbourhood . local neighbourhood search solutions
2: Input n . number of solutions in neighbourhood
3: Input tabuList . list of already visited solutions
4: Output incumbent . the current best Solution
5: incumbent ← selectRandomSolution(neighbourhood)
6: while (termination condition not satisfied) do
7: Input bestCandidate
8: for (i=0 to i=n-1) do
9: if (neighbourhood[i].fitness)<incumbent.fitness)and(neighbourhood[i] not in tabuList) then
10: bestCandidate ← neighbourhood[i] 11: end if 12: end for 13: if (bestCandidate.fitness)<(incumbent.fitness) then 14: incumbent ← bestCandidate 15: end if 16: tabuList.push(bestCandidate)
17: if (tabuList.size > maxTabuSize) then tabuList.removeFirst()
18: end if
19: end while
are compared to the solutions in the tabu list. As soon as a component is found that does not match the comparison solution it can be assumed to be different to that solution in the tabu list. However, if every component of the tabu list and the comparison solution is the same, the comparison solution is present in the tabu list and is discarded.
After a change neighbourhood local search solutions are recreated using the trains in the current time window and the tabu list is cleared ready for the new problem.
6.6.4
Variable Neighbourhood Search (VNS)
VNS was introduced by Mladenovi´c and Hansen [134]. The algorithm uses the concept of changing the neighbourhood during the search to avoid becoming trapped in a local optimum. It explores each neighbourhood in turn, if it does not find a solution in the current neighbourhood that improves the current incumbent solution it moves onto the next neighbourhood. The neighbourhoods are designed to be increasingly distant from the current incumbent solution.
The procedure for VNS is shown in algorithm 8. To begin, the neighbourhoods are created and a solution is chosen randomly from the first neighbourhood to be- come the current incumbent solution. The algorithm then cycles through each of
Algorithm 8 VNS
1: Input neighbourhoods . the local search neighbourhoods
2: Input k . number of neighbourhoods
3: Output incumbent . the current best Solution
4: incumbent = selectRandomSolution(neighbourhoods[0])
5: while (termination condition not satisfied) do
6: for (i=0 to i=k-1) do
7: randomSolution←selectRandomSolution(neighbourhoods[k])
8: candidate ← localSearch(randomSolution)
9: if (candidate.fitness)<incumbent.fitness) then
10: incumbent←candidate
11: i ← k; . exit the loop
12: end if
13: end for
14: end while
the neighbourhoods in turn picking a random solution, performing a local search and if the best solution from the local search is better than the current incumbent solution, it replaces the incumbent with this solution. If the incumbent is replaced with the best solution then the algorithm does not visit any of the other neigh- bourhoods. However, if a better solution is not found in the first neighbourhood, the algorithm moves on to the next neighbourhood. If a better solution is still not found, the algorithm continues visiting increasingly distant neighbourhoods until a new solution is found or there are no more neighbourhoods.
The local search for the reallocation problem is the same as that described in section 6.6.1, while the local search for the resequencing problem is that described in section 6.6.2.
The difference between VNS and TS is that TS uses only one neighbourhood structure. Using VNS raises the question of how the neighbourhoods should be created. The following sections describe the neighbourhood creation process for the reallocation and resequencing sub-problems.
Neighbourhood for the Reallocation Problem
In the reallocation problem the distinction between the neighbourhoods is based on how many trains in the current solution are assigned new platforms. If only one train is assigned a new platform, then this solution will be placed in neighbourhood one. If two trains are assigned a new platform the solution will be placed in neighbourhood two, and so on. The more trains that are assigned new platforms, the further away the new solution is from the original solution and the further away the allocated
Neighbourhood for the Resequencing Problem
The neighbourhoods for the resequencing problem are created using the path- preserving local search described in Section 4.2.2. In this case which neighbourhood the train is placed in depends on the number of trains that are swapped with other trains. If only one train is swapped with other trains, then this solution is placed in neighbourhood one. If two trains are swapped with other trains, then this train is placed in neighbourhood two, and so on.
It is possible that there may be no feasible solutions in one or more neighbour- hoods. If this is the case, then that neighbourhood is skipped and the algorithm moves onto the next neighbourhood.
The neighbourhoods are based on the current incumbent [134]. Therefore, at the end of an iteration the neighbourhoods are recreated based on the incumbent solution. This occurs for the reallocation sub-problem whether or not the incumbent has been replaced because randomly generating new platforms for set numbers of trains may result in a different neighbourhood in the next iteration. However, if the incumbent has not been replaced for the resequencing sub-problem, the neighbour- hood will not be remade as there would be no change in the local solutions within the neighbourhoods produced from the unchanged incumbent.
After a dynamic change the neighbourhoods are recreated using the trains in the current time window.