Train Scheduling with Hybrid Answer Set Programming††thanks: This is a substantially extended and revised version of (Abels et al. 2019).††thanks: This work was partially funded by DFG grants SCHA 550/9 and 11.
Abstract
We present a solution to real-world train scheduling problems, involving routing, scheduling, and optimization, based on Answer Set Programming (ASP). To this end, we pursue a hybrid approach that extends ASP with difference constraints to account for a fine-grained timing. More precisely, we exemplarily show how the hybrid ASP system clingo[DL] can be used to tackle demanding planning-and-scheduling problems. In particular, we investigate how to boost performance by combining distinct ASP solving techniques, such as approximations and heuristics, with preprocessing and encoding techniques for tackling large-scale, real-world train scheduling instances.
1 Introduction
Densely-populated railway networks transport millions of people and carry millions of tons of freight daily; and this traffic is expected to increase even further. Hence, for using a railway network to capacity, it is important to schedule trains in a flexible and global way. This is however far from easy since the generation of railway timetables is already known to be intractable for a single track [Caprara et al. (2002)]. Moreover, hundreds of train lines on a densely connected railway network lead to complex inter-dependencies due to connections between trains and resource conflicts.
We take up this challenge and show how to address real-world train scheduling with hybrid Answer Set Programming (ASP [Lifschitz (1999)]). Our hybrid approach allows us to specifically account for the different types of constraints induced by routing, scheduling, and optimization. While we address paths and conflicts with regular ASP, we use difference constraints (over integers) to capture fine timings. Similarly, to boost (multi-objective) optimization, we study approximations of delay functions of varying granularity. This is complemented by domain-specific heuristics aiming at improving feasibility checking. Moreover, we introduce preprocessing techniques to reduce the problem size and search space, and provide redundant constraints improving propagation. This lifts our approach to a level that allows us to create high quality train schedules spanning six hours for a portion of Switzerland within minutes.
In current practice, train schedules evolve by only minor adjustments year-over-year. The basic structure of the schedule has been shown to be more or less feasible in practice. The current scheduling tools offer limited support for conflict detection and no support for automatic conflict resolution. When additional trains are ordered by railway companies during the year, or when capacity is reduced because of maintenance work, it is up to the professional experience and ingenuity of the planner to find a producible schedule or to reduce the number of services if no feasible solution can be found. In a first step, the solution described in this paper are intended to be used by the industrial partner in a decision support system providing planners with conflict-free schedules for adding additional trains into an existing schedule structure. The planner only has to enter the commercial requirements for the additional train, everything else shall be taken care of by the system. In later steps, it is hoped that our solution can be scaled to eventually generate complete, conflict free schedules from scratch for the whole country and also continually optimize them during operations to account for deviations and disruptions.
We implement our approach with the hybrid ASP system clingo[DL] [Janhunen et al. (2017)], an extension of clingo [Gebser et al. (2019)] with difference constraints. To begin with, we introduce in Section 3 a dedicated formalization of the train scheduling problem. This is indispensable to master the complex inter-dependencies of the problem. We present our solution in terms of hybrid ASP encodings, including a detailed description of preprocessing, encoding and heuristic techniques in Section 4. Finally, we evaluate our approach on real-word instances in Section 5.
2 Background
We rely on a basic acquaintance with ASP. The syntax of our logic programs follows the one of clingo [Gebser et al. (2015)]; its semantics is detailed in [Gebser et al. (2015)].
The system clingo[DL] extends the input language of clingo by (theory) atoms representing difference constraints. That is, atoms of the form
where are symbolic terms and is a numeral term, represent difference constraints such as ‘’, where serve as integer variables and stands for an integer.111Strictly speaking, we had to distinguish the integer from its representation. For instance, assume that ‘&diff{e(T)-b(T)} <= D’ stands for the condition that the time between the end and the beginning of a task T must be less or equal than some duration . This may get instantiated to ‘&diff{e(7)-b(7)} <= 42’ to require that e(7) and b(7) take integer values such that ‘’. Note that can be arbitrary terms. We exploit this below and use instances of pairs like (T,N) to denote integer variables. Among the alternative semantic couplings between (theory) atoms and constraints offered by clingo[DL] (cf. [Janhunen et al. (2017), Gebser et al. (2016)]), we follow the defined, non-strict approach (i) tolerating theory atoms in rule heads and (ii) enforcing their corresponding constraints only if the atoms are derivable. Hence, if a theory atom is false, its associated constraint is ignored. This approach has the advantage that we only need to consider difference constraints occurring in the encoding and not their complements. Obviously, one great benefit of using such constraints is that their variables are not subject to grounding.
For boosting performance, we take advantage of clingo’s heuristic directives of form
#heuristic :. [,sign] |
where is an atom and is a body; is a numeral term and sign a heuristic modifier, indicating how the solver’s heuristic treatment of should be changed whenever holds. Whenever is chosen by the solver, sign enforces that it becomes either true or false depending on whether is positive or negative, respectively. See [Gebser et al. (2013), Gebser et al. (2015)] for a comprehensive introduction to heuristic modifiers in clingo.
3 Real-world train scheduling
3.1 Problem introduction
The train scheduling problem can essentially be divided into three distinct tasks: routing, conflict resolution and scheduling.
First, train lines are routed through a railway network. One such network is given in Figure 1. By and large, it is a directed graph containing nodes 1 through 12 with edges in between, for instance, and . Given this directed graph, we assign paths through the network to three train lines, viz. , and . Each train line is assigned an acyclic subgraph capturing its travel trajectory. In our example, the subgraphs for , and are indicated by solid, dotted and dashed edges, respectively. Note that belongs to the subgraph of both and . We see that has several different start nodes, viz. 1 and 2, and end nodes, viz. 11 and 12, whereas and have no alternative routes. One possible solution to the routing task in Figure 1 is represented by edges colored blue, red and green marking valid paths for , and , respectively
Second, edges in the network are assigned resources representing, for example, the physical tracks or junctions that can only be passed by a single train at once. Whenever two train lines share edges assigned the same resource, a decision has to be made which train line passes first. In our example, we assume that each edge is assigned a resource representing the physical track. Furthermore, we have two junctions, and , that are assigned five edges each. More precisely, is assigned to and , and to and . The junctions highlight a common structural property of train scheduling instances on which we rely heavily to reduce the amount of decisions that have to be made to resolve resource conflicts. Let us focus on and the resource conflicts of the three train lines in edges and . Instead of deciding each pair of edges with shared resources individually, we can decide which train line enters a set of edges assigned first. More precisely, we decide in which order , and enter , and , respectively. This is possible because train lines using the same resource cannot overtake each other once they are within these sets of edges. We call such sets resource areas. Note that while it is obvious in our example what said areas are (they are equal to the full set of assigned edges for each resource and train line), this may not be the case in general. For instance, there are many alternative paths in complex train stations, and thus shared resources might be visited several times enabling train lines to overtake one another.
Finally, a schedule has to be created that assigns each train line an arrival time at all nodes in its path. A valid schedule has to respect a variety of timing constraints, ranging from earliest and latest arrival times at nodes, traveling and waiting times on edges, resource conflicts between train lines, to connections between train lines.
Figure 2 shows the earliest and latest arrival times for nodes of the valid paths of Figure 1. This is indicated by the light blue, red and green areas for train lines , and , respectively. For instance, may arrive at node 10 at the earliest at time point 0 and at the latest at time point 360 or at node 5 between 360 and 660. Furthermore, Figure 2 shows a valid schedule for train lines , and as indicated by the blue, red and green lines, respectively. This schedule results from the decisions that and enter before and, conversely, that enters before . Each resource conflict is resolved by a timing constraint indicating that the following train line enters the resource only after the preceding train line has left it plus a safety period. In our example, this safety period, as well as the travel time for each edge, is 60 seconds. This is reflected in the schedule since starts at 0 in node 10 and proceeds to node 7 at 60, and only enters at node 2 a minute after has left it at node 6.
In our example, there are three connections. Our concept of connections captures transfer of passengers and cargo in various contexts, as well as the transfer of physical trains between train lines. The latter enables us to express cyclic train movements as can be seen with the connection of to on edges and . We call such a connection collision-free since resource conflicts are disregarded on all connected edges that share the same resource, and the connection furthermore requires both train lines to arrive at node 3 at the exact same time point. This connection expresses that the same physical train is used for train line and and seamlessly transitions at node 3.222For simplicity, we assume that collision-free connections are already given with a transitive closure of all adjacent edges of the same resource and all possible other collision-free connections of other trains of that resource. The results are reflected in the connected paths in Figure 1 and the same arrival time at node 3 in Figure 2. The two other connections from to on either edges and or and , on the other hand, capture a possible transfer of passengers or cargo from train line to . The connection requires not to arrive at 12 before has arrived by at least one minute at 10 so that a transfer is possible. Since this connection does not disable resource conflicts, this can only be achieved if precedes through which makes wait between nodes 6 and 9 until has left.
After obtaining a valid routing and scheduling, the solution is evaluated regarding the delay of the train lines and the quality of the paths they have taken. The former is calculated by summing up the delay of each train line at each node in their paths. For that purpose, a time point is defined after which the train line is considered delayed at a node. In Figure 2, these time points are indicated by lines and . For instance, is delayed at nodes 9, 10 and 12, thus accumulating a penalty of . For the quality of the routes, penalties are assigned to edges and accumulated for every train line traveling that edge. Such penalties may indicate tracks that can manage less workload, are in need of maintenance, or are known to be a detour, and therefore to be avoided if possible. In our example, only edge is assigned a penalty of one, other edges are assumed to have a penalty of zero, therefore our routing is optimal and accumulates no routing penalties.
3.2 Problem formalization
We formalize the train scheduling problem as a tuple having the following components:
-
•
stands for the railway network , where
-
–
is a directed graph,
-
–
is a set of resources,
-
–
assigns the minimum travel time of an edge,
-
–
associates resources with edges in the railway network, and
-
–
gives the time a resource is blocked after it was accessed by a train line.
-
–
-
•
is a set of train lines to be scheduled on network .
Each train in is represented as a tuple , where
-
–
is an acyclic subgraph of ,
-
–
gives the earliest time a train may arrive at a node,
-
–
gives the latest time a train may arrive at a node, and
-
–
is the time a train has to wait on an edge.
Note that all functions are total unless specified otherwise and we use seconds as time unit.
-
–
-
•
contains connections requiring that a certain train line must not arrive at node before another train line has arrived at node for at least and at most seconds.
More precisely, each connection in is of form such that and , , , , , and either or , as well as, either or .
-
•
Finally, contains collision-free resource points for each connection in .
We represent it as a family .
Each resource point in is of form and expresses that two train lines and are allowed to share the same resource on edges and . Connections removing collision detection are used to model splitting (or merging) of trains, as well as reusing the whole physical train between two train lines. More importantly, this allows us to alleviate the restriction that subgraphs for train lines are acyclic, as we can use two train lines forming a cycle that are connected via such connections. This can be observed in Figure 1, where and are connected like so.
We suppose the following conditions
These assumptions ensure that adjacent edges sharing the same resource are always collision-free resource points for that connection, because otherwise the connections could not be made if resources span over several edges. To illustrate this, consider two trains lines and that reuse one physical train. All edges have a minimal travel time of six seconds and the same resource with a block time of ten seconds. To facilitate a seamless transition from one train line to another, a connection is used where both train lines blend into each other. As both train lines ought to use the same physical train, a collision-free point is needed to allow the connection at the given edges. This collision-free point alone is not sufficient, since would have to wait for four seconds at edge for the release of the resource , blocked by at edge . This is due to the fact that the blocked time of ten seconds is larger than the minimal travel time of six seconds. Therefore, the collision-free point is necessary to correctly execute the connection as intended, that is, modeling one physical train among multiple train lines.
For our example in Figure 1 and Figure 2, the train scheduling problem is defined as
-
•
,
-
–
,
-
–
,
-
–
and for ,
-
–
,
-
–
,
-
–
for ,
-
–
- •
-
•
with
-
–
,
-
–
,
-
–
,
and
-
–
-
•
where and .
A solution to a train scheduling problem is a pair consisting of
-
1.
a function assigning to each train line the path it takes through the network, and
-
2.
an assignment of arrival times to each train line at each node on their path.
A path is a sequence of nodes, pair-wise connected by edges. We write and to denote that node or edge are contained in path , that is, whenever for some or this and additionally , respectively.
A path for has to satisfy:
(1) | |||
(2) | |||
(3) |
where and give the in- and out-degree of a node in graph , respectively. Intuitively, conditions (1) and (2) enforce paths to be connected and feasible for the train line in question and Condition (3) ensures that each path is between a possible start and end node.
An assignment is a partial function , where is undefined whenever . Given path function , an assignment has to satisfy the conditions in (4) to (8):
(4) | ||||
(5) | ||||
(6) |
for all and such that ,
either
(7) |
for all with whenever for all such that , we have ,
and finally
(8) |
for all if and .
Intuitively, conditions (4), (5) and (6) ensure that a train line arrives at nodes neither too early nor too late and that waiting and traveling times are accounted for. Furthermore, Condition (7) resolves conflicts between two train lines that travel edges sharing a resource, so that one train line can only enter after another has left for a specified time span. This condition does not have to hold if the two trains use a connection that defines a collision-free resource point for the given edges and resource. Finally, Condition (8) ensures that train line connects to at node and , respectively, within a time interval from to . Note that this is only required if both train lines use the specific edges specified in the connections. Furthermore, note that it is feasible that and are visited but no connection is required since one or both train lines took alternative routes.
For our solution in Figure 2, we have
-
•
, , and , and
-
•
,
, and
.
To determine the quality of a solution, both the aggregated delay of all train lines as well as the quality of the paths through the network are taken into account. For that purpose, we consider two functions: the delay function and route penalty function . Given a train line and a node , returns the time point after which the train line is considered late at node . Note that . Given an edge , is the penalty a solution receives for each train line traveling edge . With this, the quality of a solution is determined via the following pair:
(9) |
Since delay is the more important criteria, optimization of the quality amounts to lexicographic minimization considering delay first and route penalty second. As mentioned, our example has an accumulated delay of 360 and 0 route penalty and therefore a quality of .
4 An ASP-based solution to real-world train scheduling
In this section, we present our hybrid ASP-based approach for solving the train scheduling problem. It relies on dedicated preprocessing techniques to reduce the problem size as well as additional constraints and domain-specific heuristics to reduce the search space and improve solving performance. This constitutes a significant improvement over our previous approach [Abels et al. (2019)] that, while similar in principle, does not scale to the largest instances available. We start by presenting said preprocessing techniques that mainly exploit redundancy in the resource distribution in the railway network. Following that, we describe the actual hybrid encoding that makes use of this preprocessing and furthermore reduces the amount of timing constraints by using a compressed representation of the graph. Finally, we present optional constraints and domain-specific heuristics aiming at further improving solving performance.
4.1 Preprocessing
We present two techniques that reduce the complexity of the problem at hand. While resource subsumption detects redundant resources that can safely be removed, resource areas are used to simplify conflict resolution on resource conflicts.
4.1.1 Resource subsumption
An analysis of real-world instances revealed that resources are often contained within others, thus posing redundant constraints. In a preprocessing step, we detect such subsumed resources and remove them from the problem specification. Given a railway network , a resource is subsumed by another resource , if and for all and , and there is no collision-free resource point for any .333If several resources are exactly the same, we keep one of them. Intuitively, subsumed resources are contained within another resource that induces the same or stronger timing constraints due to higher or equal blocked time and no conflict-free resource points in the overlapping area. In our example, we can safely remove resources as each of them is subsumed by . Note that we cannot remove any resources covered by , as it is used in the collision-free resource point of . The collision-free resource point disables conflict resolution on for the trains and , hence, conflicts for other resources topologically contained within are not redundant and have to be taken into account individually.
4.1.2 Resource areas
As seen in our example, resources covering several edges can be exploited by identifying areas, for which it is enough to determine the order of train lines passing through (rather than doing pair-wise conflict resolution on edges, as done in [Abels et al. (2019)]). We call them resource areas. Every train line has its own set of resource areas. It is required that every possible path through the resource area contains only edges assigned the original resource. More precisely, a resource area over resource and train line is a maximal set of edges such that there is no path in with but between two edges . Intuitively, this means that a resource area can only be occupied by one train at a time independently of their chosen paths through the resource area. Thus, other train lines using the same resource may only enter once the entire area is free. Note that there may exist several resource areas for a resource and a train.
We define a resource coverage as a set of resource areas over resource and train line such that and for . A resource coverage over sets of resources and train lines is defined as . Intuitively, a resource coverage distributes resource areas so that every edge is covered and no edge is in two resource areas per resource and train line.
In our example, we have the resource coverage
where and are the train lines and resources of the example in Figure 1, respectively.
We have three non singleton sets in the coverage. Given the train lines , and resource from our example, we have to decide whether enters first or enters first. Without the use of resource areas, we would need to make a decision for every element in the cross product , leaving us with 6 decisions instead of one. Note that there is no unique resource coverage for every graph, but different maximal subsets could be chosen.
To determine resource areas, we use the greedy algorithm in Figure 3 for every resource and train line . We incrementally create a resource area by adding yet unused edges to it in Line 3. The function in Line 3 checks that no path in between edges in contains edges not assigned . Intuitively, this means that once a train line entered a resource area, it is not able to leave it and reenter it again. If this is the case, is added to in Line 3. This is repeated until we cannot add further edges to the current resource area and then restart the procedure creating a new area in lines 3 and 3 until we achieve full resource coverage.
4.2 Fact format
A train scheduling problem with is represented by the facts
for each and .
For every , we add
Additionally, either
is added, if or in , respectively. We assign unique terms to each train line for identifiability.
For example, the facts
express that train line t1 may travel between nodes 1 and 3 taking at least 60 seconds, waiting on this edge for 0 seconds, and arrives between time points 240 and 540 at node 1, which is a possible start node.
Furthermore, we add
for and . Akin to train lines, resources are assigned unique terms to distinguish them.
For example, facts
assign resource sw1 to edges and and the resource is blocked for 60 seconds after a train line has left it.
Finally, we add
for all , where acts as an identifier, and
for all .
For instance, the transfer of the physical train from train line t2 to t3 at node is encoded by connection(1,t2,(4,3),t3,(3,6),0,0,3,3). This requires both train lines to be at node 3 at the exact same time. Thus, we have to additionally provide the fact free(1,t2,(4,3),t3,(3,6),sw1) to allow for a shared use of the resource, so that the train lines can connect. This can be done safely since in reality only one train exists for both train lines, which rules out collisions.
For a resource area , we generate facts
for , resource and train line . We assign a unique term to distinguish resource areas for the same resource and train line. Furthermore, for every resource area , we add
where and to represent the earliest entry and latest exit times for that resource area. In our example, the earliest entry time for resource area is 0, while the latest exit time is 660.
Given delay and route penalty functions and , we add
for with to evaluate a solution.
4.3 Encoding
In the following, we describe the general problem encoding. We separate it into three parts handling path constraints, conflict resolution and scheduling.
The first part of the encoding in Listing 1 covers routing. First, exactly one valid start node is chosen for each train line to be visited (Line 1). From a node that is visited by a train line and is not an end node, an edge in the relevant subgraph is chosen as the next route (Line 3). The new route in turn leads to a node being visited by the train line (Line 4). This way, each train line is recursively assigned a valid path. Since those paths begin at a start node, finish at an end node and are connected via edges valid for the respective train lines, conditions (2) and (3) are ensured.
The next part of the encoding shown in Listing 2 detects and resolves resource conflicts. Basically, a resource conflict exists, if two train lines each have an edge in their respective subgraph that is assigned the same resource, and time intervals overlap in which the train lines enter and leave the edges in question, extended by the time the resource is blocked. We improve upon this edge-centric conflict resolution via resource areas. In lines 5–14, we first compute entry and exit nodes leading in and out of a resource area (depending on the chosen route). A conflict is possible, if two train lines each have a resource area in their respective subgraph that is assigned the same resource, and the time intervals overlap in which the train lines may enter and leave the areas in question, extended by the time the resource is blocked (lines 21–25). We resolve the conflict by making a choice which train line passes through this area first (lines 27 and 29).
As a collision-free resource point does not trigger a resource conflict, we prevent the involved resource areas and with and from creating conflicts by deriving collision-free resource areas in lines 16–19. It is safe to do so, as it is necessary for a collision-free connection that all edges adjacent to or with the same resource are also collision-free resource points (recall Section 3.2). We exclude these areas from the conflict resolution in Line 22.
Note that we require much less decisions for resolving resource conflicts by using resource areas. It is possible that several or even all edges in two resource areas with the same resource induce a conflict. Naively, a decision would have to be made for all possible combination of those edges. Instead of having this quadratic blowup, we only have to resolve the resource conflict between entire resource areas. For our example, this reduces the number of decisions necessary to resolve all possible conflicts from 15 to 5.
To represent the arrival time of a train line at node , we project the graph to a possibly smaller version of it using a topological ordering. In essence, instead of assigning an arrival time to each possible node a train line could visit, we assign the arrival time to the progress the train line has made relative to its subgraph. For that purpose, we utilize the height of a node that indicates the maximum number of edges the train line has to travel to reach this node, (or, in other words, in an acyclic graph, the height of a node is the length of the longest path from any root node to this node). Obviously, several nodes can have the same height whenever they are on parallel paths through the subgraph. Formally, the height of a node for train line is defined as follows:
The arrival times are now represented using integer variables designated by pairs of form (,) indicating arrival time of train line at height 444Cf. Section 2 on using pairs as identifiers. This reduces the number of variables and difference constraints needed whenever trains are routed over nodes with the same height. For the running example, nodes 1 and 2 from train line now collapse to one variable , as only one of the two nodes can be used in a final routing of the train line. Instead of introducing arrival times for node 1 and 2, we only introduce an arrival time where , independent of the chosen path. The number of integer variables for the arrival times of is therefore reduced from 8 to 6 in contrast to using node names such as (,).
Note that we use ground terms in the remainder of this paper to describe our rules, while their actual encoding uses variables. Also, we sometimes mix mathematical notation for train lines and nodes (italic) and their identifying terms in the encoding (typewriter) and use them interchangeably.
Listing 3 displays the encoding of scheduling via difference constraints. An atom h(,,) assigns a node its height for train line and is computed in lines 30 and 32. Note that we use pairs as names for integer variables whose values indicate the arrival time of train at height . The next part of the encoding ensures that earliest and latest arrival times, viz. and , for a train line on a node are respected by setting lower and upper bounds for the integer variable (,) (lines 40-43). Even though, the lower and upper bound of variable (,) depend on the node that is actually visited as there possibly exist several nodes on alternative paths with the same height (the same maximum path length from a root node), we can take advantage of the height-based naming scheme by setting the lower and upper bound of variable (,) to and , respectively, independently of the chosen route. For all nodes with a greater time for the earliest arrival (lesser time for the latest arrival), an additional constraint is derived depending on whether such a node is visited. This restricts the search space in two ways. First, constraints for earliest and latest arrival times are independent of routing for nodes with a minimal earliest or maximal latest arrival time, second, regardless of routing, a constraint is added constituting the lower bound of the earliest (upper bound for the latest) arrival time at a certain height. Lines 34 to 37 compute said minimal and maximal arrival times for a train line at a certain height. Difference constraints representing these upper and lower bounds are derived in lines 38 and 39 and are independent of the chosen route. More precisely, for train line at height , we derive
where and . For nodes , where and , we therefore ensure and in turn condition (4) and (5). In case train line visits a node for which either or , we have to additionally derive
This again ensures and in turn condition (4) and (5) to hold.
The next part of the encoding guarantees the travel and waiting time between two nodes for a train line . We call adjacent heights exclusively connected, if there is no edge such that and or and . For these heights the minimum of the travel plus waiting time can be set independently of the chosen route. An exclusively connected pair represents a set of edges of which at most one edge can be visited by a train line. The minimum of travel plus waiting time of these edges can therefore be guaranteed independently of routing, as it constitutes a lower bound. For any edge , where either the travel plus waiting time is greater than the minimum across all edges for exclusively connected heights , or is not exclusively connected, the constraint for minimal distance between and depends on the routing. In the worst case, no exclusively connected heights exist and all constraints are dependent on the routing. In our running example, edges and for train line result in the same pair of exclusively connected heights . This means that the condition holds independently of routing, as 60 is the minimum of travel plus waiting time for these edges. If edge had a waiting time , the condition needs to hold additionally, if edge is visited. Note that the route independent constraint only poses a lower bound on the relation of the two arrival times and is therefore subsumed by this new constraint. Given a train line , lines 45–52, first, compute the travel plus waiting time for all edges , secondly, the minimum of travel plus waiting time for all exclusively connected heights , and finally, the difference constraint atom
is derived in Line 53. For any edge , where either holds, or are not exclusively connected, the difference constraint atom
is derived, whenever the train line is actually routed over edge (lines 54–57). For all exclusively connected heights , the condition is provided. This satisfies Condition (6) for all edges , where , and . As the minimum time is a lower bound, no constraints are violated if these edges are not visited. For all visited edges where , and or is not exclusively connected, condition for all visited edges has to hold. This ensures Condition (6). As for the earliest and latest arrival times above, by using a formulation based on heights, we may either gain a lower bound or provide timing constraints independently of the routing, thus restricting the search space.
The rule in lines 59–62 in Listing 3 utilizes conflict detection and resolution from Listing 2. We derive the difference constraint atom
expressing that leaves the resource area using a node before enters via a node , given the blocked time of a resource and the decision that train line on resource area takes precedence over on resource area . As all edges in these resource areas have the same resource , and once inside a resource area a train cannot leave the resource area again, the order of passing all edges is the same. Therefore, this constraint supersedes all constraints for all edges , , and captures Condition (7).
4.4 Optimization
As mentioned above, we use instances of potlate/4 to indicate when a train line is considered late at a node and how to penalize its delay. For this purpose, we choose sets whose elements act as thresholds for arrival time of train line at node . Given delay function , for every , train line and . We create facts potlate(,,,) for with such that there is no with . We add potlate(,,,) for . Intuitively, we choose the penalty of a potential delay as the difference to the previous potential delay, or, if there is no smaller threshold, the difference to the time point after which the train is considered delayed. This way, the sum of penalties amounts to a lower bound on the train line’s actual delay in seconds. For example, for and , we create facts potlate(,,6,1), potlate(,,10,4) and potlate(,,14,4). Now, if arrives at at 12, it is above thresholds 6 and 10 and should receive a penalty of 5. This penalty is a lower bound on the actual delay of 7, and we know that the value has to be between 5 and 9 since the next threshold adds a penalty of 4. This method approximates the exact objective function in (9) in two ways. First, we do not divide by 60 and penalize in minutes since this would lead to rounding problems. Second, our penalty only gives a lower bound to the actual delay if thresholds are more than one second apart. While our method allows us to be arbitrarily precise in theory, in practice, creating a threshold for each possible second of delay leads to an explosion in size. We employ two schemes for generating sets given , and delay function .
4.4.1 Binary approximation
Binary approximation detects if a train is a second late and penalizes it by one, therefore, only the occurrence of a delay is detected while its amount is disregarded.
We set .
4.4.2 Linear approximation
Linear approximation evenly distributes thresholds seconds apart across the time span in which a delay might occur. Here, if train line arrives at or after at , we know that the real delay is between and for . We also add to detect solutions without delay.
Accordingly, we set with .
4.4.3 Encoding
Given thresholds for all train lines and nodes and the corresponding instances of predicate potlate/4, Listing 4 shows the implementation of the delay minimization. The basic idea is to use regular atoms to choose whether a train line is delayed on its path for every potential delay (Line 74 in Listing 4). In lines 76–79, we order the given thresholds for every train line and node. By enforcing downwards adjacent thresholds to hold as well (being late for 4 minutes implies being late for 3 minutes which in turn implies being late for 2 minutes etc.), we immediately exclude solutions where this semantic condition fails, thus improving propagation. Originally, the semantics of the late atoms (being late for minutes) is only given via the difference constraint atom introduced later. By directly encoding the implicit ordering of natural numbers using regular ASP atoms, we leverage the efficient Boolean constraint solving techniques of the ASP solver. Line 81 adjusts the late atoms to the topological ordering. In our example, this means that train line being late 1 minute on node 11 uses the same variable as being late 1 minute on node 12 thus reducing the amount of variables that are needed to capture delay. Finally, we derive difference constraint atoms expressing this information (lines 83–86), and ultimately using the regular atoms in a standard minimize statement (Line 88). In detail, for every atom potlate(,,,), an atom late(,,,) can be chosen if visits . For every late(,,,) we derive topo_late(,,,). If topo_late(,,,) is chosen to be true, a difference constraint atom &diff{0-}<= is derived expressing and, therefore, that is delayed at the visited node at threshold . Otherwise, &diff{-0}<= becomes true so that holds. The difference constraint atoms ensure that if the truth value of a late atom is decided, the schedule has to reflect this information. The minimize statement then sums up and minimizes the penalties of the late atoms that are true.
Finally, Line 89 shows the straightforward encoding of the routing penalty minimization. The minimize statement merely collects the paths of the train lines, sums up their penalties, and minimizes this sum. This is done on a lower level than delay minimization leading to lexicographic optimization minimizing delay first and route penalty second.
4.5 Optional Constraints and Heuristics
While the above encoding can be used as is, additional constraints can be added to further restrict the search space in the hope of improving solving performance. To this end, we rely on the fact that clingo[DL] consists of a Boolean search engine (clingo) and a dedicated difference constraints propagator. While some atoms are purely Boolean, others have a semantics in terms of difference constraints. In the following, we transfer the knowledge represented in these difference constraints (such as transitivity and acyclicity) back to the logic program, thereby improving the search in the ASP part of the problem. Finally, a domain-specific heuristic is represented that prefers sequences of train lines reducing the likelihood of conflicts.
4.5.1 Resource overlap I
Resource areas with different resources overlap if both contain at least one common edge. If two train lines are each routed over such an overlap, the sequence of entering the respective pairs of resource areas has to be the same since it is not possible for trains to overtake each other throughout both overlapping resource areas. We exploit this by detecting such overlaps and using them to add constraints that remove solution candidates for which the sequences do not match, thus reducing the search space. More precisely, given two resources and , train lines and , and resource areas , , , and , if train line leaves resource area before train enters its resource area , visits an edge and visits and edge from (i.e. both trains use the overlapping areas), then train also has to leave resource area before train enters resource area .
As an example, we use a straight line of three tracks, where nodes are ordered adjacently from left to right. Consider train lines , and over nodes , and edges , and . Furthermore, let and , meaning that forms a resource area covering the left and middle part of the graph while forms a resource area covering the middle and right part of the graph. The resources overlap in the middle on edges and . Consider train line entering resource area via edge , using resource , before train line enters this edge; it immediately follows that also has to enter edge before train line . Given that edge is also in the resource area , it is impossible for train line to overtake , and the sequence of entering these resource areas is the same. The same holds for train lines and . Once enters resource area before enters resource area , it follows that also has to enter resource area before train line can enter resource area , as both trains cannot get past each other because their respective resource areas overlap.
In Listing 5, we first compute pairs of resource areas that overlap in lines 86 and 87 by deriving atoms ra_overlap(,,,,) representing that for a train line , resource areas and share at least one edge for distinct resources and . Note that and are used as identifiers for resource areas and , respectively. The integrity constraint in lines 88–96 enforces that train lines routed over an overlap have the same sequence over both pairs of resource areas. Lines 90–93 require that both train lines visit at least one edge that is shared by the overlapping resource areas. We ensure that the sequence is only enforced, if a resource conflict is possible between these two train lines in lines 94–96. The predicate decided is used to extend this constraint to other cases, where we can exploit overlap to reduce the search space. We examine such a case in the following section.
4.5.2 Resource overlap II
We improve the optional overlap constraint from Listing 5 in Listing 6 by additionally considering sequences over resource areas which can be determined before search.
Given a resource , the sequence how two different trains and leave and enter their respective resource areas and is already decided if either
- 1.
- 2.
For the latter case, we use precomputed atoms set(,(,)) to denote edges that are already set to be in every path of a train line . Reconsider our previous example with train lines and where and . Given that , it is already decided that train line leaves resource area before enters this resource area. By deriving this information in Listing 6, Listing 5 ensures that the same sequence is used for resource area .
No matter which case holds, we derive the atom decided(,,,,) to state that train line leaves resource area before train line enters resource area . Converting these atoms into sequences in Line 102 enhances propagation of the rules in Listing 5, as these already decided sequences can be used in the integrity constraint in Line 88 to derive the truth value of additional sequences. Note that since the additional instances of the seq/ predicate serialize resource areas where the time intervals do not overlap, solutions of the encodings in listings 2 and 3 remain unchanged.
4.5.3 Sequence acyclicity
Whenever more than two train lines have to be serialized on a resource, the resulting sequence can never be cyclic. In more detail, given a resource and three train lines , , and , if leaves resource area before enters resource area , and leaves resource area before enters resource area , it follows that leaves area before enters area as well. This is guaranteed by the constraints in Condition (7) and realized by the difference constraint atoms in Listing 3 lines 59–62.
While this condition would be eventually derived by the difference constraints propagator, we immediately restrict the search space by providing this explicit constraint, realized in Listing 7. Furthermore, by expressing this timing-related condition in terms of regular ASP atoms, we can leverage the propagation mechanism of state-of-the-art ASP solving technology, which is currently faster and more sophisticated compared to the one used in the difference constraints propagator.
4.5.4 Sequence heuristic
The heuristic in Listing 8 attempts to order conflicting train lines by their possible arrival times at the areas where the conflict is located. In essence, we analyze how the time intervals of the train lines are situated and prefer their sequence accordingly. Given two train lines and with intervals and at the conflicting areas, respectively, we calculate to determine whether should be scheduled before . If is positive, the preferred sign of the sequence atom is also positive, thus preferring to go before , if it is negative, the opposite is expressed. In detail, is positive if may arrive later than thus making it more likely that can go first without delaying . Similarly, if is negative, may leave later, suggesting to go first. If the results of both expressions have the same sign, one interval is contained in the other and if the difference is positive, the center of the interval of is located earlier than the center of the interval of . For example, in Figure 2, we see that and share resource in Node 3 and the time intervals in which they potentially arrive at those edges are and , respectively. Given that , we prefer to be scheduled before , which in the example is clearly the correct decision, since precedes without delaying .
5 Experiments
We evaluate our train scheduling solution using the hybrid ASP system clingo[DL] v1.1, which is built upon the API of clingo 5.3.555Both are development versions available on https://github.com/potassco/{clingoDL,clingo}/ with commit hashs #f1a185e and #f8a51134, respectively. As benchmark set, we use 25 real-world instances crafted by domain experts at Swiss Federal Railways (SBB). The instances capture parts of the railway network between three Swiss cities, namely Zürich, Chur and Luzern, and vary in number of train lines, size and depths of railway network and timing constraints. The biggest instances contain the whole railway network and up to 467 train lines taken from long distance, regional, suburban and freight traffic between these three cities. Thus, we tackle instances with approximately six hours of the full train schedule on a railway network covering approximately 200 km. For brevity, we omit slight grounding and propagation optimizations in the encoding presented in Section 4; the full encoding and instance set is available at https://github.com/potassco/train-scheduling-with-hybrid-asp/. We use the best optimization configuration determined in [Abels et al. (2019)]. In detail, we use two threads, one running with a model-guided optimization strategy iteratively producing models of descending cost until the optimum is found, and the other with a core-guided optimization strategy [Andres et al. (2012)] relying on successively identifying and relaxing unsatisfiable cores until a model is obtained. Furthermore, the delay minimization is modeled by setting for each train line at node , thus, there are six thresholds in total, one if there is any delay at all, and five with a distance of 180 seconds in between with the last one being at 15 minutes. We use lexicographic optimization minimizing delay first and route penalty second.
As a preliminary step, we benchmark each domain-specific heuristic and optional constraints individually, and removed the ones that did not yield any improvement compared to clingo[DL]’s default setting. 666In particular, we dropped two heuristics proposed in [Abels et al. (2019)] since they did not improve solving performance with the new resource area and height-based encoding. This might be either due to the fact that the search space was too drastically reduced and as such less impact can be achieved by the branching heuristics, or that the switch to lexicographic optimization made some heuristics obsolete.
In total, we examined four optional encoding parts, one domain-specific heuristic and three optional constraints, and all their combinations. More precisely, we consider the sequence heuristic (hs), resource overlap I (ol1), resource overlap II (ol2), and sequence acyclicity (ac), and all seven possible combinations (given that ol1 is contained in ol2). We compare the results to clingo[DL]’s default settings without optional encoding parts and domain-specific heuristic (def).
All benchmarks ran on Linux with a Xeon E3-1260L quad-core 2.9 GHz processors and 32 GB RAM; each run limited to 3 hours and 32GB RAM. For all our experiments, we asked clingo[DL] to return one optimal solution, and we then validate feasibility and quality via an external tool provided by SBB.777https://github.com/potassco/train-scheduling-with-hybrid-asp/.
Table 5 shows the average runtime (t) over all 25 instances, which includes grounding and solving, grounding time (gt), choices (ch) and conflicts (co) for individual domain-specific heuristics and optional constraints; their combinations are given in Table 5. The best results in a row are marked bold. Note that for all configurations and instances, clingo[DL] was able to find an optimal solution, thus, no time- or memory-outs blur average time as a means for comparing the performance of the different configurations. Grounding the largest instances within the time limit is enabled by our preprocessing and the height-based naming scheme for the integer variables, due to their significant impact on reducing grounding size.
conf | t | gt | ch | co |
---|---|---|---|---|
def | 550 | 45 | 242516740 | 9135 |
hs | 162 | 45 | 51933286 | 7363 |
ol1 | 118 | 53 | 13003796 | 4038 |
ol2 | 105 | 62 | 8377540 | 3530 |
ac | 435 | 46 | 116873540 | 8755 |
We clearly see in Table 5 that ol2 by itself improves solving performance the most, drastically reducing choices and conflicts compared to def and displaying the lowest average runtime overall. This is closely followed by ol1. The heuristic hs still clearly improves the solving performance while optional constraint ac only slightly improves upon the default. We can observe that grounding time is higher for all optional constraints, especially for ol2. This is to be expected as additional rules and integrity constraint are added to the encoding. The improvement in solving performance through the reduced search space vastly outweighs the decrease in grounding performance though.
As for the composite configurations in Table 5, we observe that all of them are an improvement over the individual heuristics and optional constraints. The largest combinations also yield the best performance overall. Here, we see that, while hs/ol2/ac traverses the search space most effectively (yielding least choices and conflicts), hs/ol1/ac has a slightly better runtime performance due to lower grounding time. This shows, first, that the combination hs/ol1/ac alleviate some weaknesses compared to the individual configurations, as ol1 alone was slower than ol2. And second, that both composite configurations might prove useful in the future since for harder instances the improvement in terms of the search might outweigh the decrease in grounding performance. The last row vbs displays the virtual best solver that averages the best performance regarding runtime among all configurations. We see that the performance of vbs is close to the best configurations and as such choosing one among hs/ol1/ac, hs/ol2/acand hs/ol1 should be a good choice as default configuration for most instances.
In the following, we analyze the 25 real-world instances in detail and highlight the best results that we could achieve using the different configurations of our train scheduling solution. This information is presented in Table 5. Row ins contains the names of the 25 instances. Instance names starting with p are the nine instances originally used in [Abels et al. (2019)] that were published by SBB; they only contain part of the railway network between Zürich, Chur and Luzern. Two instances among them are marked with r and are reduced versions of the largest instance, viz. p9. Instances starting with t, on the other hand, cover the whole test area between the three cities. Furthermore, instance names containing s and l cover a shorter (about two hours) or longer time span (about six hours), respectively, which is reflected in the amount of train lines. With our problem formulation, one can express different settings of the train scheduling problem. Normally, all train lines are considered as new and to be taken into account evenly. Another problem variation is the rescheduling after adding or changing one extra train line. This is achieved by closely restricting earliest and latest arrival times around the old schedule for existing and unchanged train lines, while the extra train line is given more freedom. Instances containing an e are such rescheduling instances. Similarly, most instances have a uniform time span between the point after which a train line is delayed and the latest possible arrival time. Unlike this, for names including i, this time span is different for each train line, i.e., different train lines have different capacities for delay. Instances of the same class mostly vary in the depths of the railway network, i.e., how many alternative routes are available to each train line, but also slightly in number of train lines, resources and timing constraints.
The following nine columns analyze structural attributes of the instances, and how much preprocessing and encoding techniques reduce the instance size and search space. Column #tl shows the number of train lines for each instance. Column #r gives the number of resources, and Column #sr the number of subsumed resources. Subsumed resources can be observed in all instances and constitute on average 34%, which can then be safely removed. Column #rtl sums up resources on each edge in each subgraph of all train lines, which essentially constitutes the basis for resource conflicts using the edge-based conflict resolution. Column #ra then shows into how many resource areas those individual edges could be distributed. The difference from #rtl to #ra is on average 83%, thus drastically reducing resource entities that might induce conflicts. The following columns #ec and #rac display the number of resource conflicts based on single edges and resource ares, respectively. They highlight the benefit of introducing resource areas. We reduce the number of resource conflicts, and thus the decisions that have to be made to serialize the train lines, on average by 92%. Finally, #vnn and #vhn shows the number of integer variables needed using node- and height-based naming scheme, respectively. We save 25% of variables on average switching to the height-based naming scheme.
In the last three columns, we present the virtual best results regarding runtime across all configurations presented in Table 5 and 5. In more detail, we show the runtime per instance in Column t, and the approximated and exact quality as a pair of delay penalty in minutes and route penalty in Columns aqu and Column qu, respectively. The approximated quality amounts to the value returned by the ASP system, which is optimal for all instances, while the exact quality is returned by a tool of SBB. We were able to solve all instances with a maximum time of about 3 minutes. We calculated solutions without any delay for all instances where this was possible. For instances where this was not the case, experts at SBB deemed the incurred delay as close to optimal. Of course, we are not able to prove true optimality in all cases since we use an approximation of the delay function. Note that, for example for instance tl10, we have a rather high difference between approximated delay and actual delay of about 11 minutes. This is due to the fact that the ASP system only considers a lower bound on delay. If the approximated optimal value is for example 3 seconds, this could mean that there are three instances of delay. The amount of delay though could be as much as seconds since the next threshold is at 180 seconds in our configuration of the approximation. Completely avoiding this drawback of the approximation is currently only possible by introducing a threshold for every second, which deteriorates solving performance. We judge our current solution to be a good trade-off between solving performance and quality, since the quality of the results is sanctioned by Swiss Federal Railways and we are able to solve all real-world instances within minutes.
6 Discussion
At its core, train scheduling is similar to classical scheduling problems that were already tackled by ASP. Foremost, job shop scheduling [Taillard (1993)] is also addressed by clingo[DL] and compared to other hybrid approaches in [Janhunen et al. (2017)]; solutions based on SMT, CP and MILP are given in [Janhunen et al. (2011), Bofill et al. (2012), Baptiste et al. (2012), Liu et al. (2012)]. In fact, job shop scheduling can be seen as a special case of our setting, in which train paths are known beforehand. Solutions to this restricted variant using MILP and CP are presented in [Oliveira and Smith (2000), Rodriguez (2007)]. The difference to our setting is twofold: first, resource conflicts are not known beforehand since we take routing and scheduling simultaneously into account. Second, our approach encompasses a global view of arbitrary precision, i.e., we model all routing and scheduling decisions across hundreds of trains lines down to inner-station conflict resolution and allow for expressing complex connections that also accommodate cyclic train movements. Furthermore, using hybrid ASP with difference constraints gives us inherent advantages over pure ASP and MILP. First, we show in [Gebser et al. (2016)] that ASP is not able to solve most shop scheduling instances since grounding all integer variables leads to an explosion in problem size. We avoid this bottleneck by encapsulating scheduling in difference constraints and, hence, avoid grounding integer variables. Second, while difference constraints are less expressive than linear constraints in MILP, they are sufficient for expressing the timing constraint needed for train scheduling while being solvable in polynomial time. Finally, routing and conflict resolution require Boolean variables and disjunctions for which ASP has effective means.
In this work, we contribute a flexible and holistic ASP-based encoding of the train scheduling problem based on a precise formalization. On the one hand, since we produce timetables from scratch, our train scheduling approach can be characterized as tactical scheduling [Törnquist (2006)]. On the other hand, without changing encoding or problem formalization, we can easily accommodate problem variations like rescheduling without loosing performance, as we show for three instances in our empirical evaluation.
As seen in Section 5, all instances available to us can be solved within minutes. These instances represent sections of a test area in Switzerland, with the largest one capturing a complex, interconnected railway network spanning in length about 200 km and involving up to 467 train lines with local, regional and cargo railway traffic among them. This is possible in part due to dedicated preprocessing techniques, such as resource subsumption and resource areas, that exploit structural redundancies within the railway network as well as graph compressing methods, which drastically reduce the size of the problem representation. Furthermore, we reduce the search space and leverage advanced propagation mechanisms of our state-of-the-art ASP solving technology by transferring implicit knowledge about difference constraints into the logic program. Some of these techniques may also be candidates to improve performance for other scheduling problems like the related job shop scheduling.
To advance our approach, multi-shot solving [Gebser et al. (2019)] can be used to incrementally increase train line intervals or dynamically replan schedules by adding or removing train lines. While our hybrid ASP approach already tackles some real-world instances that are on the larger side, scalability, for example, to the entirety of Switzerland is still an issue. For that purpose, we are looking into decomposition techniques, so that smaller areas using our approach can be combined to solutions for entire countries.
References
- Abels et al. (2019) Abels, D., Jordi, J., Ostrowski, M., Schaub, T., Toletti, A., and Wanko, P. 2019. Train scheduling with hybrid ASP. In Proceedings of the Fifteenth International Conference on Logic Programming and Nonmonotonic Reasoning (LPNMR’19), M. Balduccini, Y. Lierler, and S. Woltran, Eds. Lecture Notes in Artificial Intelligence, vol. 11481. Springer-Verlag, 3–17.
- Andres et al. (2012) Andres, B., Kaufmann, B., Matheis, O., and Schaub, T. 2012. Unsatisfiability-based optimization in clasp. In Technical Communications of the Twenty-eighth International Conference on Logic Programming (ICLP’12), A. Dovier and V. Santos Costa, Eds. Vol. 17. Leibniz International Proceedings in Informatics (LIPIcs), 212–221.
- Baptiste et al. (2012) Baptiste, P., Pape, C. L., and Nuijten, W. 2012. Constraint-based scheduling: applying constraint programming to scheduling problems. Vol. 39. Springer Science+Business Media.
- Bofill et al. (2012) Bofill, M., Palahí, M., Suy, J., and Villaret, M. 2012. Solving constraint satisfaction problems with sat modulo theories. Constraints 17, 3, 273–303.
- Caprara et al. (2002) Caprara, A., Fischetti, M., and Toth, P. 2002. Modeling and solving the train timetabling problem. Operations Research 50, 851–861.
- Gebser et al. (2015) Gebser, M., Harrison, A., Kaminski, R., Lifschitz, V., and Schaub, T. 2015. Abstract Gringo. Theory and Practice of Logic Programming 15, 4-5, 449–463. Available at http://arxiv.org/abs/1507.06576.
- Gebser et al. (2015) Gebser, M., Kaminski, R., Kaufmann, B., Lindauer, M., Ostrowski, M., Romero, J., Schaub, T., and Thiele, S. 2015. Potassco User Guide, 2 ed. University of Potsdam.
- Gebser et al. (2016) Gebser, M., Kaminski, R., Kaufmann, B., Ostrowski, M., Schaub, T., and Wanko, P. 2016. Theory solving made easy with clingo 5. In Technical Communications of the Thirty-second International Conference on Logic Programming (ICLP’16), M. Carro and A. King, Eds. OpenAccess Series in Informatics (OASIcs), vol. 52. Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, 2:1–2:15.
- Gebser et al. (2019) Gebser, M., Kaminski, R., Kaufmann, B., and Schaub, T. 2019. Multi-shot ASP solving with clingo. Theory and Practice of Logic Programming 19, 1, 27–82.
- Gebser et al. (2013) Gebser, M., Kaufmann, B., Otero, R., Romero, J., Schaub, T., and Wanko, P. 2013. Domain-specific heuristics in answer set programming. In Proceedings of the Twenty-Seventh National Conference on Artificial Intelligence (AAAI’13), M. desJardins and M. Littman, Eds. AAAI Press, 350–356.
- Janhunen et al. (2017) Janhunen, T., Kaminski, R., Ostrowski, M., Schaub, T., Schellhorn, S., and Wanko, P. 2017. Clingo goes linear constraints over reals and integers. Theory and Practice of Logic Programming 17, 5-6, 872–888.
- Janhunen et al. (2011) Janhunen, T., Liu, G., and Niemelä, I. 2011. Tight integration of non-ground answer set programming and satisfiability modulo theories. In Proceedings of the First Workshop on Grounding and Transformation for Theories with Variables (GTTV’11), P. Cabalar, D. Mitchell, D. Pearce, and E. Ternovska, Eds. 1–13.
- Lifschitz (1999) Lifschitz, V. 1999. Answer set planning. In Proceedings of the International Conference on Logic Programming (ICLP’99), D. de Schreye, Ed. MIT Press, 23–37.
- Liu et al. (2012) Liu, G., Janhunen, T., and Niemelä, I. 2012. Answer set programming via mixed integer programming. In Proceedings of the Thirteenth International Conference on Principles of Knowledge Representation and Reasoning (KR’12), G. Brewka, T. Eiter, and S. McIlraith, Eds. AAAI Press, 32–42.
- Oliveira and Smith (2000) Oliveira, E. and Smith, B. 2000. A job-shop scheduling model for the single-track railway scheduling problem. LU SCS RR 21, University of Leeds, School of Computer Studies.
- Rodriguez (2007) Rodriguez, J. 2007. A constraint programming model for real-time train scheduling at junctions. Transportation Research Part B: Methodological 41, 2, 231–245.
- Taillard (1993) Taillard, E. 1993. Benchmarks for basic scheduling problems. European Journal of Operational Research 64, 2, 278–285.
- Törnquist (2006) Törnquist, J. 2006. Computer-based decision support for railway traffic scheduling and dispatching: A review of models and algorithms. In Proceedings of Fifth Workshop on Algorithmic Methods and Models for Optimization of Railways (ATMOS’05), L. G. Kroon and R. H. Möhring, Eds. OpenAccess Series in Informatics (OASIcs), vol. 2. Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik.