Using A* for Optimal Train Routing on Moving Block Systems
Abstract
Modern control systems based on Moving Block allow for shorter headways and higher capacity on existing railway infrastructure. At the same time, few algorithms for optimal routing on networks equipped with such modern control systems exist. Previous methods rely on Mixed Integer Linear Programming (MILP) and face a trade-off between model size and accuracy, especially considering comparably complex and nonlinear headway constraints as well as train dynamics. With this work, we propose a complementary approach based on A*. Under a reasonable and easy assumption on train driver behavior, we propose a solution encoding and state space that is flexible concerning the choice of search algorithm and the modeling detail. The applicability is showcased on a small benchmark set. The implementation is available open-source as part of the Munich Train Control Toolkit (MTCT) on GitHub at https://github.com/cda-tum/mtct.
Keywords and phrases:
ETCS, Train Routing, Moving Block, A*, Munich Train Control ToolkitCopyright and License:
2012 ACM Subject Classification:
Applied computing TransportationSupplementary Material:
Software (Source Code): https://github.com/cda-tum/mtct [4]archived at
swh:1:dir:9eb5851e7f0b80f88dc6f09a8c9c54b58d15ee5b
Editors:
Jonas Sauer and Marie SchmidtSeries and Publisher:
Open Access Series in Informatics, Schloss Dagstuhl – Leibniz-Zentrum für Informatik
1 Introduction
Railway traffic plays a vital role in the future of sustainable transportation. Due to long braking distances, trains cannot operate on sight (if they should travel at a reasonable speed). Instead, signaling systems are needed for safe separation. In the past, these systems have been specified on a national level. With increasing international rail traffic, control systems have been unified across Europe, leading to the European Train Control System (ETCS). Other common systems are the Chinese Train Control System (CTCT), and Positive Train Control (PTC) [12] as well as Communication Based Train Control (CBTC) for metro systems [16].
Today, many railway lines operate at their capacity limit. Building new infrastructure is costly and time-consuming. Complementary to that, the specifications of control systems have been improved. Modern versions (e.g., based on Hybrid Train Detection or Moving Block) allow for shorter headways. However, the capacity can only be used if they are adequately considered in the infrastructure planning process. To cope with the additional degree of freedom, new design tasks arise [5].
Secondly, modern headway concepts need to be considered when creating a timetable. Most research on timetable optimization and train routing focuses on networks equipped with classical control systems [1]. Only limited research considers modern Moving Block systems [15, 11, 7]. Engels and Wille [8] show that these solutions can also be used as part of an optimization pipeline for design tasks [5] within the context of Hybrid Train Detection systems.
Previous methods are mainly based on Mixed Integer Linear Programming (MILP). There is always a trade-off between efficiency and accuracy when creating a model. Usually, sensible headway constraints are the most complex to model. For this, discretization and linearization techniques are used.
In this work, we propose an alternative, complementary approach to train routing on Moving Block systems that can operate at an arbitrary level of detail. Any (black-box) simulator can be used to evaluate train movements. Our proposed approach is based on A*. It has already been successfully applied to different areas within the design automation community, e.g., in Nanotechnologies [10]. Even within the rail domain, first solutions based on A* exist [13]. However, their approach cannot easily be generalized to consider train movements and headways at sensible levels of detail due to the choice of solution encoding. With this work, we propose a different approach that incorporates the complex constraints already in the encoding. Because of this, more complex relations can be incorporated without further complicating the A* search.
The remainder of this work is structured as follows. Section 2 reviews the relevant concepts of train control systems and A* search. Under an additional but sensible assumption, a solution encoding is proposed in Section 3. Sections 4 and 5 showcase how this can be used to design an optimization algorithm for train routing. Section 6 provides a proof of concept. Finally, Section 7 concludes this work.
2 Background
This section reviews the relevant concepts of train control systems and informed search algorithms such as A*.
2.1 Train Control Principles
Classically, railway networks are separated into fixed blocks. To detect the status of a given block, tracks are equipped with Trackside Train Detection (TTD) hardware, e.g., axle counters. A train may only proceed into the next section if the entire block is unoccupied.
Example 1 ([7]).
Consider two trains following each other on a single track as depicted in Figure 1(a). Train can only move until the end of . It cannot enter because it is still occupied and, hence, might have to slow down in order to be able to come to a full stop before entering the occupied block section.
Trains equipped with a Train Integrity Monitoring (TIM) system can safely report their position. In that case, trains can follow each other at absolute braking distance without the need for any block sections222At the same time, we allow the existence of some TTD sections. They can be used to, e.g., provide basic flank protection around switches.. Moving Block control systems make use of this concept and are already implemented on some metro networks.
Example 2 ([7]).
In contrast to Example 1, consider a moving block control implemented in Figure 1(b). Because trains operate at the ideal absolute braking distance, can move up to the actual end of (minus a little buffer). In particular, it can already enter what has been previously. Hence, trains can follow each other more closely.
2.2 Train Routing
This work considers time-optimal train routing on railway networks equipped with a Moving Block control system. For this, we are given general timetable requests. Routing is the task of deciding on which specific track to use and when trains are moving; all constraints of the signaling system need to be fulfilled. In particular, we consider the tasks on a microscopic level. In theory, many different objectives are possible. We aim to optimize the respective travel time.
Problem 3 (Optimal Train Routing (on Moving Block Systems)).
Given:
-
A railway network with vertices and (directed) edges as described in Appendix A.
-
A set of trains, where denotes the weight of importance of train
-
Demands for every train consisting of:
-
–
an entry node together with a desired entry time interval and initial velocity ,
-
–
an exit node together with a desired exit time interval and exiting velocity , as well as,
-
–
a list of stations together with stopping requests, i.e., a latest arrival time , an earliest departure time and a minimal stopping time .
-
–
Task: Find a routing satisfying every train’s demand, obeying the constraints imposed by a moving block control system, and minimizing the (weighted) exit times.
Example 4.
Consider the railway network in Figure 2. It consists of one train station (with two edges and one platform333Of course, the station could also consist of multiple parallel platforms), as well as two TTD sections to prevent collisions on the respective railway switches. Two trains ( and ) enter at and traverse toward , whereas travels in opposite direction. Assume that has to stop at the train station, i.e., stop on edge or . Hence, it will travel on the bottom line. Depending on the timings, might follow the same path, allowing to pass in the opposite direction on the upper track. If travels at an earlier or later time, the upper track could also be used for to overtake in an alternative solution.
2.3 A*-Algorithm
A* is an informed search algorithm (classically designed to find shortest paths on directed graphs). It functions similarly to Dijkstra’s algorithm but expands toward the destination more quickly by making use of a heuristic approximation of the remaining distance.
Let be a weighted graph, an initial vertex (also called state in this context), as well as a set of terminal states . The task is finding the shortest path from to any vertex in . A* explores the graph starting from . For every vertex , it keeps track of the shortest path from to found so far. We denote the length of this path by . Dijkstra would expand on the vertex with the smallest . However, A* uses a different evaluation function. For every , we apply an efficiently computable heuristic function approximating the shortest (remaining) distance from to . A* then explores the neighbors of the vertex with the smallest combined value . By doing this, the exploration is guided toward goal states.
In theory, we can use any heuristic function . However, A* is only guaranteed to return optimal values if the heuristic meets certain conditions, namely, that never overestimates the actual cost. If satisfies a triangle-like inequality, A* can safely be terminated as soon as the first terminal vertex is explored (as specified in Algorithm 1).
Definition 5 (Consistent Heuristic [9]).
A heuristic is consistent if for every , and for every .
Theorem 6 ([9]).
If is consistent, then Algorithm 1 returns a minimal path.
Hart et al. [9] show Theorem 6 for the case of -graphs, i.e., if there exists a such that for every . However, this condition is only used to show termination in a weaker case, when is just admissible but not consistent. It is easy to verify that Algorithm 1 is optimal even for arbitrary (including negative444Note that cannot have negative cycles if there exists a consistent heuristic.) edge weights, see, e.g., [2, Theorem 2.9].
3 Solution Encoding
When solving any problem, one must decide on the underlying modeling and its consequences on possible algorithms. A classical approach is to model optimization problems as linear or nonlinear constraints and use general and well-developed solvers for the respective problem class. Often, it is possible to formulate Mixed Integer Linear Programs (MILP). E.g., Problem 3 in the presented or similar forms were considered in [15, 11, 7]. Finding detailed and efficient models is difficult. With respect to train routing tasks, it is usually most challenging to model adequate headway times induced by the underlying signaling system. To linearize these constraints, previous MILP approaches consider a velocity-extended graph and model simplistic headways only at the vertices of the railway network and do not enforce headways in between. Hence, one must always trade-off between performance and accuracy when choosing the discretization levels.
Previously, A* was proposed as a different approach to solve design tasks within the infrastructure planning process [13]. At the same time, their approach is also closely related to train routing as described in Problem 3. Peham et al. use a state space discretized by time, hence encountering similar problems. Train dynamics and headways were not properly considered. It is unclear how they could be easily incorporated into their approach since these rather complex constraints would have to be considered while determining possible successor states.
Hence, we propose a fundamentally different encoding, which flexibly incorporates most constraints already at this stage. By doing so, it is also more natural to apply Algorithm 1 on the so-defined states. For this, we reconsider what the relevant decisions to be made by the solution algorithm are. Previous solutions leave much freedom for trains to accelerate and decelerate anytime and anywhere on the network. To reduce the search space, we make an assumption on the behavior of trains.
Assumption 7 (Greedy Train Driver Assumption).
Trains always move as fast as the control system allows; they do not slow down unless forced to do so.
Of course, this assumption changes the feasible region of Problem 3, at the same time, arguably almost only cutting off suboptimal solutions. However, there is no theoretical guarantee because one could design situations in which it is beneficial (also with respect to time) to slow down, e.g., in order not to rear-end slow trains before they might exit the main track. At the same time, under Assumption 7, deciding on the train positions at every time step is no longer necessary. Instead, the train behavior is uniquely determined by the following:
-
1.
the edges (track sections) used by each train,
-
2.
the order of trains on each border vertex and TTD section555the order on single edges can be induced from that, and
-
3.
the stop positions of every train within the respective stations.
If this information is decided upon, the train movements can be simulated to determine the objective (or decide that no valid train movements are possible using the predetermined information). Any such fully determined state (in which the simulation succeeds) is a feasible solution to Problem 3, hence, a terminal state (see also Section 2.3).
Example 8.
Again, consider Example 4 and the corresponding network depicted in Figure 2. We might specify:
-
and use ; uses .
-
Order on and : ; order on and : .
-
stops in the station at the end of .
Simulating under Assumption 7 might lead to the following movement of trains: and enter the network at their respective vertices. moves all the way to as fast as possible, stops for the time specified in the timetable request, and continues to its exit vertex . enters the network some time after and follows as close as possible at absolute braking distance. moves all the way to and stops (even though it does not have a scheduled stop). Only after has cleared will it continue to its exit vertex .
4 Optimization using A*
Having established the relevant decisions in Section 3, we can construct a specific A* approach for Problem 3 under Assumption 7. For this, we need to establish a state space, i.e., a graph on which Algorithm 1 is applied to and sensible heuristic estimates .
4.1 State Space
To use search algorithms, it does not suffice to encode only terminal states. Instead, we must also encode partial solutions that might lead to feasible solutions encoded by terminal states.
Definition 9 (Partial Solution).
A partial solution is given by information on every train consisting of
-
a list of adjacent edges , possibly empty666 is possible, with if and
-
a list of specific stop positions in stations for the first stations777hence, no stops in stations are specified in this case.
Moreover, the train orders are specified on every TTD section with more than one train traveling on, as well as on the entry and exit vertices.
In contrast to terminal states (i.e., fully specified movements), and are possible. When simulating, it is assumed that, in such a case, trains stop at the end of their last specified edge and end their journey on the network. In the objective, the exit time of is replaced by the time it reaches the end of with velocity 0. The state space, i.e., the “vertices” of the graph used in Section 2.3, is then given by the set of all (partial) solutions.
Example 10.
Again, consider Example 4 and the corresponding network depicted in Figure 2. In contrast to Example 8 the train routes are only specified partially, e.g.,:
-
uses ; uses no edges; uses .
-
Order on and : ; order on and : .
In this scenario, enters at , moves to the end of as fast as possible, and stops there permanently; similarly, moves to . does not enter the network at all.
Assumption 11.
We are given a (possibly black-box) simulator that can (under Assumption 7) determine the unique train movements given a partial solution (Definition 9) or return that no feasible trajectory exists (e.g., due to a deadlock situation).
4.2 Transitions
It remains to define transitions between states, i.e., the “edges” of the graph used in Section 2.3. Naturally, the initial state is given by the empty state, i.e., no train enters the network, with objective value 0. The target states are all fully specified states corresponding to feasible train movements that respect all timetable requests.
The main idea is to traverse the state space edge by edge. Given any (partial) state , we obtain possible successor states by one of the following:
-
1.
Any single train stops at its current route end (if the respective edge is part of the next scheduled station).
-
2.
Any single train moves to any succeeding edge on the network.
-
3.
Any single train enters the network from outside.
The respective TTD- and vertex-orders are induced by the order in which these transitions were chosen to reach from the initial state. If a TTD is entered, the train is appended to the respective TTD-order; analog for entry and exit vertices.
Example 12.
Consider the state depicted on the left of Figure 3(a) with three trains. and have already entered the network, whereas ’s route is still empty. There are five possible successor states:
-
(orange) can either use the current route end to stop in the train station or move onward to the next edge. In this case, first enters , hence, the train order on (which was empty before) is now given by .
-
(blue) can move one edge. Due to the switch, it can either stay on the main track or divert to the left. Since it was already in , no adjustments to the order are needed, and the order on is still given by .
-
(purple) can enter the network on the right, hence, the order on is now given by .
Following this strategy, many intermediate states are created, even if there is only one plausible decision to continue with. Note that trains cannot overtake or cross on single-track lines without turnouts. Hence, train movements of more than one edge can be safely assumed until the next switch is reached. Doing so can reduce the number of states explored by skipping unnecessary intermediate steps.
Example 13.
Consider the state depicted on the left of Figure 3(b) with a single train that has already traversed the first edge. If the train continues, it enters TTD1. Since no other train can enter TTD1 before has left, we can move it all the way to the end of the TTD section without skipping any relevant state. The train can either move left or right. Given that decision, there is no routing choice until the next switch, so we can move the train all the way to just before TTD2. We cannot safely extend ’s route into TTD2 because another train might still enter TTD2 before without producing a deadlock. Finally, there are two more possible successors because might stop at any of the two possible stop positions of the station.
4.3 Suitable Heuristic
For any state , we can simulate the movements of each train (Assumption 11). Let be the time at which either exits the network or reaches the end of its route as specified by the (partial) state . We define
| (1) |
Note that for any terminal state , coincides with the objective value of the corresponding feasible (but not necessarily optimal) solution to Problem 3. Furthermore, its value does not depend on specific state transitions but is the same regardless of which path was taken to reach a particular state, as all relevant information for simulation is contained in the state itself. We do not define the transition costs explicitly, but they are implicitly given by
| (2) |
Usually, will hold. However, for terminal , is theoretically possible because the train is not forced to stop at the exit vertex in contrast to the end of partial routes in intermediate states. However, this is not a problem because we will handle this by choosing a sensible heuristic .
To guide the search algorithm, we need suitable edge weights and an optimistic heuristic estimating the lowest cost from any state to the nearest terminal. For this, we estimate the remaining time for every individual train with . If a train has already reached its exit vertex, we have . Otherwise, let be the minimal running time for between any two points888not necessarily vertices on the railway network , ignoring headway constraints induced by other trains. Let be an optimistic approximation, i.e., , which still fulfills the triangle inequality
| (3) |
For a natural and easy to compute choice is
| (4) |
i.e., assuming a train always moves at the maximum speed, disregarding constraints on acceleration and deceleration. In general, we can induce any as the quickest path from to by using the edge timings defined in Equation 4.
Example 14.
Consider the network with edge length and maximal velocities depicted in Figure 4(a). Assume, we have two trains, with maximal velocity , and with maximal velocity . Using defined in Equation 4, the quickest path of from to is via and
| (5) |
whereas the quickest path of is via and with
| (6) |
However, we do not use directly as a heuristic. Recall that should estimate and be optimistic. However, in state , might be forced to slow down because it has to stop at the end of its partially defined route. This is not the case in a terminal state , so the actual travel time difference can be less than . However, this can easily be incorporated into the heuristic. Consider Figure 4(b) and assume that at point and time , a train starts to decelerate only because it has to stop at the end of its partial route. While braking, it traverses vertices and finally stops at at time . These values can be easily returned from the (black-box) simulator while determining (Equation 1). In a terminal state, might not be forced to slow down at , but could potentially follow the orange speed profile in Figure 4(b). Because of this, it would reach earlier than in this terminal state, and the final exit time might be less than . We need to adjust for the time that could reach earlier than in any terminal state reachable from . This can be achieved by defining
| (7) |
Finally, we combine these individual heuristics into the final used in Algorithm 1:
| (8) |
Lemma 15.
defined in Equation 8 is consistent.
Proof.
W.l.o.g., assume that we use the simple successor state exploration since the multi-edge version can be seen as traversing multiple transitions in one iteration. Let be any state and be any successor state. Then and differ by a single action on a single train . Let and be the times at which either exits the network or reaches the end of its route in state and , respectively. Then
| (9) |
and
| (10) |
If the transition relates to stopping in a station, we have
| (11) |
where denotes the stopping time in the respective station.
Otherwise, let be the path of in state . Hence, is its path in state . Let be the braking point in state and in state respectively, see Figure 5. Let () be the first vertex after and () be the first vertex after .
Then
| (12) |
By optimality of the quickest path, we obtain
| (13) |
Moreover, the adjustments made to due to early braking nicely cancel out to
| (14) | |||
| (15) | |||
| (16) |
assuming (analog if ). Hence, we obtain
| (17) | ||||
| (18) | ||||
| (19) |
where we use that , because the constraint to stop at affects only after reaching point , hence, the train behavior up to are identical in states and . Similarly, one can easily show that also holds for the edge cases when a train enters or exits the network. Overall
| (20) |
proving that is consistent.
Theorem 16.
Algorithm 1 together with defined in Equation 1 and defined in Equation 8 outputs an optimal solution to Problem 3 under Assumption 7.
Proof.
4.4 Extending the Heuristic
The heuristic presented in Section 4.3 can be further extended to approximate the remaining time more accurately by using more information provided by Problem 3. Note that the train has to visit a specified list of stations before leaving the network, so it might not be possible for a train to take the quickest route anyway. Assume that in state , has not stopped in stations yet, i.e., in Definition 9, then we can update Equation 7 to
| (21) |
where
| (22) |
is the natural extension of to distances between sets.
Moreover, Problem 3 provides information on the earliest departure times. Since the train is not allowed to leave before that time, we can already incorporate this into the heuristic. For this, set
| (23) |
For any future station, we can already incorporate the earliest departure times of the previous station by
| (24) |
and, finally,
| (25) |
Corollary 17.
The heuristics induced from Equations 21 and 25 are consistent and, hence, Algorithm 1 outputs an optimal solution to Problem 3 under Assumption 7.
Proof.
Analog to the proof of Lemma 15. Equation 11 changes to
| (26) |
The main ideas of the proof carry over.
5 Evaluation of Objective Value using Simulation
For implementation, it remains to have access to a simulator for evaluating (Assumption 11). To showcase the proposed method, we implement a simulator based on Assumption 7 and simple laws of motion, i.e., every train has a constant maximal acceleration and deceleration . In theory, one could use any simulation tool at hand and, e.g., even incorporate more exact braking curves.
5.1 Principles
For simplicity, we use a time discretization of , which seems to be the standard time between two consecutive train position reports [3, Section 7.5.1.143]. For every time step , we keep track of the velocity and position999The position refers to the front of the train. The rear end can be directly induced from its length. of each train. In between, we assume linear movement; hence,
| (27) |
Assume that at time , the signaling system allows a train to move at most a distance (moving authority). Using basic laws of motion, the braking distance of a train at speed is given by , hence,
| (28) |
and, thus,
| (29) |
In general, we will set by Assumption 7 unless there are further constraints on the maximal velocity (see Section 5.3).
5.2 Moving Authority
There are four main reasons why the moving authority may be restricted. They are exemplarily depicted in Figure 6(a).
A train may only advance to the rear of a preceding train, its next scheduled stop position, or the beginning of a TTD section, which the preceding train has not fully cleared yet. In order to enforce speed constraints on future edges (that are not reachable within one timestep101010refer to Section 5.3 in that case), we restrict the moving authority by the point at which the train would stop if it decelerates at full rate just after entering the edge at its speed limit.
5.3 Restrictions on Maximal Velocity
Finally, there are some cases where it is more natural to restrict the speed directly instead of incorporating it into the moving authority, in which case we might not be able to set . Naturally, the speed is restricted by the speed limit of the current edge (and any edge that can be reached within one timestep) as well as the train’s maximal velocity. Moreover, by maximal acceleration, The most complex restriction is to ensure that a train can leave the network at its target velocity, but only at a time . In that case, a train might need to slow down in order not to arrive at the exit too early but still have enough distance left to accelerate to the target exit velocity before leaving the network. Assume that is fixed, then it is easy to calculate the maximal possible runtime to the exit node by assuming that the train decelerates until the point where it has to accelerate again to reach the target velocity at exit. Trying difference values for , they can either lead to an exit at time (green lines in Figure 6(b)), at time (orange lines) or the target velocity cannot be attained at exit (red lines). Using binary search, we choose the largest value for that still leads to an exit at time .
6 Case Study
To test the proposed method, we implement Algorithm 1 together with the transitions described in Section 4.2, the heuristics in Section 4.4, and the simulator in Section 5. All code is available open-source as part of the Munich Train Control Toolkit (MTCT) available on GitHub at https://github.com/cda-tum/mtct. The user can choose among different strategies when executing the A* algorithm.
-
Dijkstra-like: This setting makes use of the single-edge transitions described in Section 4.2 and does not use a heuristic, i.e., . However, in order to remain consistent, the heuristic amends for the time “lost” by braking at the end of its partial route, i.e., .
-
Single-Edge: This setting combines the single-edge transitions described in Section 4.2 together with the heuristic defined in Equation 21, i.e., future stations are considered in the approximation, however not the earliest exit times defined in the problem instance.
-
Single-Edge with Earliest Exit: Same as “Single-Edge”, but using Equation 25 for the heuristic, instead, i.e., also considering minimal runtimes due to the constraints on earliest departure in the problem description.
-
Multi-Edge and Multi-Edge with Earliest Exit: Same as above, but using the multi-edge transitions described in Section 4.2
We tested these strategies on an Intel(R) Xeon(R) W-1370P system using a 3.60GHz CPU (8 cores) and 128GB RAM running Ubuntu 20.04. We use the benchmark network from [6]. Additionally, we use the random timetables generated by [7] on two of the networks, including Munich’s S-Bahn Stammstrecke. We compare runtimes to the MILP-approach [7].
The results are plotted in Figure 7, and raw data is provided in Appendix B. On the x-axis, we denote the runtime in seconds111111Note that the scale is logarithmic. The y-axis corresponds to the fraction of instances solved within that time (or faster). Hence, a line to the left/top is generally better. By design, all lines are monotonically increasing, and the left ends of each “step” are the runtimes of some instance. From the horizontal distance between the lines, one can approximately121212assuming that the order of instances solved is identical for every algorithm, which is, of course, not guaranteed read off the runtime difference on that instance.
We can see a clear trend. Reducing the size of the explored solution space by skipping states with only one sensible successor significantly reduces the runtime. Additionally, using as much information as possible already in the heuristic is beneficial, i.e., the one induced by Equation 25. This trend suggests that there is still significant performance potential if both transitions and guiding heuristics are improved. Instead of using Equation 4 for runtime approximation, one could, e.g., use the minimal runtimes in [15], incorporating simple acceleration and deceleration limitations.
7 Conclusions
In this work, we have proposed an algorithm based on A* (Sections 3, 4, and 5) that can find optimal train routings on networks equipped with moving block control systems (Problem 3) under a reasonable assumption on driver behavior (Assumption 7) and showed its applicability to benchmark instances (Section 6). It is designed in such a way that any arbitrary black-box function can be used to evaluate the arising states. Because of this, our algorithm can, e.g., be used with any arbitrary detailed simulation tool that might consider more detailed braking curves or headways than reasonable to model within a MILP framework.
It is not unexpected that the increased accuracy (while still guaranteed to be optimal) comes with a downside in runtime. At the same time, Section 6 shows the general applicability of our approach and how the choice of the guiding heuristic and transition strategy affects the overall runtime and number of solvable instances. By simple extensions to these, we were able to improve the efficiency notably, even if the runtime of previous MILP approaches could not be reached yet on larger instances.
At the same time, our approach is model-agnostic and flexible. It is not limited to being used within an (exact) A* method. Instead, any search algorithm can be applied. In particular, approximative approaches might have the potential for further significant performance gains. The simplest choice might be a weighted version of A* that guides the search quicker towards terminal states [14]. However, we are not limited to variants of A*, but one could, e.g., also consider genetic algorithms, local search, reinforcement learning, and more.
Overall, this work provides a valuable basis for applying general and well-established search algorithms to routing tasks on railway networks. The modeling can be arbitrarily exact by using any (possibly black-box) evaluation methods, such as simulation. Research on improved guiding of the search algorithms and exploring the potential of approximative search algorithms on the presented encoding is left to future work.
References
- [1] Ralf Borndörfer, Torsten Klug, Leonardo Lamorgese, Carlo Mannino, Markus Reuther, and Thomas Schlechte, editors. Handbook of Optimization in the Railway Industry. Springer International Publishing, 2018. doi:10.1007/978-3-319-72153-8.
- [2] Stefan Edelkamp. Heuristic search. Morgan Kaufmann, Waltham, MA, 2012. doi:10.1016/C2009-0-16511-X.
- [3] EEIG ERTMS USERS GROUP. ERTMS/ETCS System Requirements Specification, SUBSET-026. European Union Agency for Railways, 2023.
- [4] Stefan Engels. Munich Train Control Toolkit (MTCT). Software, swhId: swh:1:dir:9eb5851e7f0b80f88dc6f09a8c9c54b58d15ee5b (visited on 2025-08-27). URL: https://github.com/cda-tum/mtct, doi:10.4230/artifacts.24436.
- [5] Stefan Engels, Tom Peham, Judith Przigoda, Nils Przigoda, and Robert Wille. Design tasks and their complexity for the European Train Control System with hybrid train detection. EURO Journal on Transportation and Logistics, 14:100161, 2025. doi:10.1016/j.ejtl.2025.100161.
- [6] Stefan Engels, Tom Peham, and Robert Wille. A symbolic design method for ETCS Hybrid Level 3 at different degrees of accuracy. In Daniele Frigioni and Philine Schiewe, editors, 23rd Symposium on Algorithmic Approaches for Transportation Modelling, Optimization, and Systems (ATMOS), volume 115 of OASIcs, pages 6:1–6:17. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2023. doi:10.4230/OASIcs.ATMOS.2023.6.
- [7] Stefan Engels and Robert Wille. Comparing lazy constraint selection strategies in train routing with moving block control. In Marek Bolanowski, Maria Ganzha, Leszek A. Maciaszek, Marcin Paprzycki, and Dominik Slezak, editors, Proceedings of the 19th Conference on Computer Science and Intelligence Systems (FedCSIS), volume 39 of Annals of Computer Science and Information Systems, pages 585–590. Polish Information Processing Society, 2024. doi:10.15439/2024F3041.
- [8] Stefan Engels and Robert Wille. Towards an optimization pipeline for the design of train control systems with hybrid train detection (short paper). In Paul C. Bouman and Spyros C. Kontogiannis, editors, 24th Symposium on Algorithmic Approaches for Transportation Modelling, Optimization, and Systems (ATMOS), volume 123 of OASIcs, pages 12:1–12:6. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2024. doi:10.4230/OASIcs.ATMOS.2024.12.
- [9] Peter E. Hart, Nils J. Nilsson, and Bertram Raphael. A formal basis for the heuristic determination of minimum cost paths. IEEE Trans. Systems Science and Cybernetics, 4(2):100–107, 1968. doi:10.1109/TSSC.1968.300136.
- [10] Simon Hofmann, Marcel Walter, and Robert Wille. A* is born: Efficient and scalable physical design for field-coupled nanocomputing. In 2024 IEEE 24th International Conference on Nanotechnology (NANO), pages 80–85. IEEE, 2024. doi:10.1109/nano61778.2024.10628808.
- [11] Torsten Klug, Markus Reuther, and Thomas Schlechte. Does laziness pay off? - A lazy-constraint approach to timetabling. In Mattia D’Emidio and Niels Lindner, editors, 22nd Symposium on Algorithmic Approaches for Transportation Modelling, Optimization, and Systems (ATMOS), volume 106 of OASIcs, pages 11:1–11:8. Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2022. doi:10.4230/OASIcs.ATMOS.2022.11.
- [12] Jörn Pachl. Railway Signalling Principles: Edition 2.0. Universitätsbibliothek Braunschweig, 2021. doi:10.24355/dbbs.084-202110181429-0.
- [13] Tom Peham, Judith Przigoda, Nils Przigoda, and Robert Wille. Optimal railway routing using virtual subsections. In Simon Collart Dutilleul, Anne E. Haxthausen, and Thierry Lecomte, editors, Reliability, Safety, and Security of Railway Systems. Modelling, Analysis, Verification, and Certification (RSSRail), volume 13294 of Lecture Notes in Computer Science, pages 63–79. Springer International Publishing, 2022. doi:10.1007/978-3-031-05814-1_5.
- [14] Ira Pohl. Heuristic search viewed as path finding in a graph. Artificial Intelligence, 1(3):193–204, 1970. doi:10.1016/0004-3702(70)90007-X.
- [15] Thomas Schlechte, Ralf Borndörfer, Jonas Denißen, Simon Heller, Torsten Klug, Michael Küpper, Niels Lindner, Markus Reuther, Andreas Söhlke, and William Steadman. Timetable optimization for a moving block system. Journal of Rail Transport Planning & Management, 22:100315, 2022. doi:10.1016/j.jrtpm.2022.100315.
- [16] Lars Schnieder. Communications-Based Train Control (CBTC). Springer Berlin Heidelberg, 2021. doi:10.1007/978-3-662-62876-8.
Appendix A Railway Network
In this paper, we use the formal model of a railway network introduced in [5]. In general, a railway network is given as a directed graph, i.e., there might be restrictions on travel direction. If and , we sometimes use undirected edges for illustration purposes. Every edge has a specified length as well as a maximal speed . Because turnouts (i.e., vertices with ) do not allow arbitrary transitions in general, we are given a successor function for every vertex. If , the railway network allows a train to move from edge to via . Moreover, a set of border vertices is specified at which trains can enter and leave the railway network with predefined headway times. Finally, even though we consider moving block control systems, some TTD sections with classical train separation are given to model basic flank protection around turnouts.
Definition 18 (Railway Network).
A railway network is defined by
-
a directed graph with vertices being the set of points of interest and edges being the railway tracks between the aforementioned points of interest,
-
a mapping denoting the length of each edge such that for every pair of edges 131313For , .,
-
maximal velocities for every ,
-
a family of mappings , where represents the valid movements over , and
-
border vertices together with headway times .
We refer to [5] for more details and examples.
Appendix B Raw Data
| MILP | Dijkstra-like | S1ngle-Edge | SE with Earliest Exit | Multi-Edge | ME with Earliest Exit | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Instance | t[s] | t[s] | #it | t[s] | #it | t[s] | #it | t[s] | # | t[s] | #it |
| High Speed Track (02 Trains) | 0.03 | 0.00 | 4 | 0.00 | 4 | 0.00 | 4 | 0.00 | 4 | 0.00 | 4 |
| High Speed Track (05 Trains) | 0.02 | 0.07 | 177 | 0.01 | 32 | 0.01 | 26 | 0.01 | 32 | 0.01 | 26 |
| Overtake | timeout | 4.43 | 36141 | 1.02 | 8267 | 0.54 | 4700 | 0.19 | 1091 | 0.10 | 597 |
| Simple 2-Track Station | 0.40 | 0.39 | 4586 | 0.15 | 1872 | 0.11 | 1364 | 0.06 | 449 | 0.04 | 319 |
| Simple Network | 1.56 | 178.30 | 357054 | 18.70 | 37810 | 10.99 | 25890 | 2.61 | 4796 | 1.46 | 2971 |
| Simple Network (03 Random Trains) | 1.20 | 5.85 | 24065 | 0.83 | 3706 | 0.83 | 3706 | 0.17 | 625 | 0.17 | 625 |
| Simple Network (06 Random Trains) | 9.21 | timeout | 1622725 | timeout | 1333013 | 402.94 | 376782 | 192.57 | 153066 | 53.34 | 45160 |
| Simple Network (09 Random Trains) | 9.18 | timeout | 1420517 | timeout | 1318516 | timeout | 1216819 | timeout | 853380 | timeout | 791987 |
| Simple Network (12 Random Trains) | 17.82 | timeout | 802635 | timeout | 874964 | timeout | 814870 | timeout | 498327 | timeout | 495954 |
| Simple Network (15 Random Trains) | 99.43 | timeout | 606614 | timeout | 536984 | timeout | 573502 | timeout | 396691 | timeout | 386992 |
| Simple Network (18 Random Trains) | 47.15 | timeout | 433182 | timeout | 362013 | timeout | 356877 | timeout | 262670 | timeout | 264495 |
| Simple Network (21 Random Trains) | timeout | timeout | 302300 | timeout | 241350 | timeout | 290107 | timeout | 185869 | timeout | 182279 |
| Simple Network (24 Random Trains) | timeout | timeout | 209872 | timeout | 176201 | timeout | 179720 | timeout | 114616 | timeout | 100410 |
| Simple Network (27 Random Trains) | 222.51 | timeout | 177386 | timeout | 150395 | timeout | 145467 | timeout | 105765 | timeout | 98356 |
| Simple Network (30 Random Trains) | 432.38 | timeout | 126364 | timeout | 99878 | timeout | 109218 | timeout | 72243 | timeout | 72950 |
| Single Track With Station | 0.04 | 0.01 | 114 | 0.00 | 44 | 0.00 | 39 | 0.00 | 32 | 0.00 | 28 |
| Single Track Without Station | 0.05 | 0.00 | 4 | 0.00 | 4 | 0.00 | 4 | 0.00 | 4 | 0.00 | 4 |
| Stammstrecke (01 Random Trains) | 0.35 | 0.00 | 57 | 0.00 | 23 | 0.00 | 23 | 0.00 | 9 | 0.00 | 9 |
| Stammstrecke (02 Random Trains) | 1.03 | 3.08 | 30576 | 0.18 | 1221 | 0.18 | 1221 | 0.07 | 289 | 0.07 | 289 |
| Stammstrecke (03 Random Trains) | 1.04 | 513.15 | 2695389 | 4.80 | 19278 | 4.67 | 19278 | 0.97 | 2392 | 0.94 | 2392 |
| Stammstrecke (04 Random Trains) | timeout | timeout | 7748178 | 85.95 | 245384 | 84.14 | 245384 | 5.37 | 10642 | 5.31 | 10642 |
| Stammstrecke (04 Trains) | 0.89 | timeout | 8110539 | 251.52 | 501466 | 242.45 | 501466 | 24.66 | 31872 | 24.16 | 31872 |
| Stammstrecke (05 Random Trains) | 7.11 | timeout | 5186928 | 383.87 | 817560 | 374.54 | 817560 | 22.94 | 35648 | 22.57 | 35648 |
| Stammstrecke (08 Trains) | 1.94 | timeout | 3758144 | timeout | 2528215 | timeout | 958400 | timeout | 1277847 | timeout | 572097 |
| Stammstrecke (16 Trains) | 6.91 | timeout | 1521604 | timeout | 748951 | timeout | 230370 | timeout | 597978 | timeout | 142532 |
