Abstract

Software tools using computer simulations are frequently used in the research and optimization of railway transport systems. Such simulations serve to examine different railway traffic scenarios (which typically reflect different timetables and railway infrastructure configurations). During the simulation experiments, it is necessary, among other things, to solve tasks related to the determination of track routes along which individual trains or parts of train sets are moved. Many simulation tools require the basic and alternative permissible track routes to be manually specified before starting the simulations, which is a relatively tedious and time-consuming process. Classical graph algorithms cannot be applied to solve the problem of automatic calculation of the routes because they are unable to take into account the length of the object being moved or recognise changes in the direction of its movement. This article presents original innovative algorithms focused on automated dynamic search of track routes (applying an appropriate optimization criterion), which is performed during simulation experiments within simulators working at the mesoscopic level of detail. The algorithms are based on a mathematical model (represented by a specifically designed weighted digraph) that appropriately reflects the actual track infrastructure. The dynamic calculation of each specific track route for a train or a group of railway vehicles considers both the total train set length and the current railway infrastructure occupancy, including blocked parts of the infrastructure due to intervention of the interlocking system. In addition, the places where the train set movement direction is changed can be identified on each route found. Applications of the algorithms and of the mathematical model of the track layout are demonstrated on a model track infrastructure.

1. Introduction

The research method of computer simulation is frequently used to examine and optimise the operation of railway systems. In this context, software simulators, or simulation tools, specialized to simulate railway traffic are used with advantages. Such tools require decisions associated with various types of operational tasks/situations to be automatically taken during the simulation experiments. Examples include decision on the assignment of alternative platform tracks to arriving delayed trains, search for admissible train routes available for train set shunting in a currently occupied trackage, and train selection (from a set of more than one waiting train) for permission to enter a specific line track.

This article is mainly devoted to automated dynamic computations of track routes required to relocate rail vehicles on a rail infrastructure, intended for inclusion into traffic simulations. Addressing this problem was primarily motivated by efforts to improve the capabilities of current rail-traffic simulators, which often enable static specification of the above track routes to be made only manually (before starting the individual simulation experiments). The possibility of including dynamic computations of track routes for relocating objects (having a given length) into the run of a simulation experiment has a high potential to facilitate (and shorten) the process of simulation experiment parameterization. The dynamic track route computation procedures are based on original algorithms that clearly represent new (as yet unused) solutions in the rail-traffic simulation domain.

For a simulator to be classified as a credible tool for practical uses, the traffic and decision processes used within the simulation experiments must be such that the simulation should approach the real railway system operation as best as possible. In other words, it is very important that the automated solutions implemented in the simulator should be based on suitable models and methods providing results applicable in real traffic situations.

The present article describes an innovative automated solution of one type of operational problems, namely, determination of the train route topology or shunting route topology for relocation of a train/train set within the railway infrastructure. Information for the specification of the relocation encompasses the relocation object length, starting and final positions (tracks), and current railway yard occupation. The solution has been developed for use in rail-traffic simulators working at the mesoscopic level of detail.

2. Literature Review

The operation of railway systems is examined and optimized by employing a number of different methods and techniques that are supported by various software tools. The main goal of such optimizations is to find such solutions which can be used to help ensure quality traffic. The term quality traffic can be interpreted (with some simplifications) as traffic that (i) basically (with minor deviations) follows the timetable and (ii) uses the service resources economically, i.e., means of transport (such as shunting locomotives), elements of infrastructure (on which rail vehicles are moved), and human resources (e.g., technical personnel working in the field of rail yards). A number of specific optimization tasks can be identified in the complex of provisions to ensure quality traffic, and each task may use suitable models of the infrastructure and models of the traffic and traffic management systems.

One of the important optimization tasks consists in solving the train routing problem. This extensive problem includes, for instance, the following partial tasks: rail line assignment to trains within the extensive areas of railway networks [1, 2]; coordinated assignment of track routes to more than one train in the railway station [3–6]; and identification of suitable track routes for rail vehicle shunting [7]. Among the relevant factors playing a role when solving such problems is the configuration of the specific infrastructure on which the traffic takes place. This implies that one should seek to select the best-fitting track infrastructure model and use the most suitable algorithms for each specific type of examination.

Mathematical structures of the graph type (and their specific implementations), which fall in the graph theory domain, are frequently used when describing a particular track infrastructure. Infrastructure models can be constructed both on directed graphs (digraphs) and on undirected graphs. Original track layout models built on the double vertex graph [8] and polar graph [7, 9] concepts make possible distinction between track segments of switches and station track segments.

Among typical tasks addressed by using graphs is the search for admissible (potentially shortest) track routes on which rail vehicles are shunted. The concept of the original Dijkstra’s algorithm [10–12], which is primarily aimed at searching for the single-source shortest paths on a weighted directed graph, can be used with advantage for such purposes. Numerous modifications of this algorithm have also been used when examining railway systems [13–15].

One of the important methods used to investigate and optimise railway systems is computer simulation [16]. Different track layout models are used within software tools specialized to simulate rail traffic [7, 8, 14, 15]. Examples of relevant simulation tools in this domain include OpenTrack [17], RailSys [18], Villon [19], MesoRail [20], NEMO [21], and PULSim [22]. Such tools always apply the same level of detail—microscopic, mesoscopic, or macroscopic. On the contrary, different approaches can apply distinct levels of detail within different parts of a simulator—such simulations are referred to as multiscale simulations [23] or hybrid simulations [24, 25]. The existence of software platforms for combined traffic simulations, capable of examining interactions of different traffic modes (e.g., [26]), is also worth mentioning.

In order to work, the above software tools require data description of the rail infrastructure, which can be available in various formats of the configuration files. A standard exists for this purpose, viz. railML [27, 28] (open-source railway markup language). This standard defines a recommended format of the files for the exchange of data for railway applications. The RailTopoModel [29, 30] is also available: this is a logical object model designed for standardization of the representation of railway infrastructure-related data.

Continuation of that part of the research, the results of which were published in [7], was motivated by the need for specialized functions to be applied in the new simulation tool named MesoRail, serving rail-traffic simulations and working at the mesoscopic level of detail. Among such functions was automated computation of the topologies of the track routes on which relocation objects (such as trains and locomotives) will be moved within the track infrastructure model. For this, the appropriate original algorithms (which, however, have never been published so far) were redesigned and implemented. The algorithms were then tested with success within MesoRail for use in dynamic track route calculations. The track layout model used and the algorithms working on it make up original solutions that have never been used elsewhere (according to the available literature).

3. Models of the Rail Infrastructure

Automated dynamic search for train routes and shunting routes within the railway infrastructure uses a mathematical model, reflecting the track layout examined. The construction of such a model consists of 2 stages.

3.1. Primary Model

Stage 1 includes the creation of a primary model using an undirected edge-weighted graph as specified in Table 1. The edges in the graph represent the individual tracks (or their parts) as well as the track segments of the switches. The edges reflecting the tracks are referred to as destination edges, while the remaining edges are referred to as connecting edges.

This terminology mirrors the fact that tracks can be viewed as targets for rail vehicle relocation whereas switches and track crossings cannot. The graph vertices represent the contact points of the track segments reflected by the edges.

Where switches and crossings are modelled, their different types determining how they can be technically transited must be differentiated. Some examples of how different switches or crossings are represented in graph G₀ are illustrated in Figure 1. Admissible transits in Figure 1 are specified in Table 2.

(a)

(b)

(c)

(d)

(a)
(b)
(c)
(d)

Figure 1 

The models of switches and crossings applied within undirected graphs.

Each edge in graph G₀ has a weight assigned, expressing the metric length of the track segment. An example of a primary model mirroring a demonstration railway yard (total track length: 3049 m) is shown in Figure 2.

(a)

(b)

(a)
(b)

Figure 2 

Prototype track infrastructure—a primary model based on an undirected graph G₀.

When a specific rail vehicle relocation within the rail infrastructure is required, the starting and final positions are assumed to be associated with specific tracks (represented by appropriate edges in graph G₀). In order to make it possible to distinguish between the opposite track ends, either end of each edge in the graph can be assigned either the plus sign (+) or the minus sign (−). This enables us, for instance, to specify that end of the finish track through which the rail vehicle should reach the finish position. Such edge end labelling can also be interpreted as an alternative labelling of the vertex that is incident with the specific end of the specific edge. For example, the notation  =  =  can be used in Figure 2. The assignment of the signs to the opposite edge ends can be based on a rule (for instance, if the graph is placed in the two-dimensional coordinate system, then that track end having a lower value of coordinate x is assigned the plus sign, the opposite end, the minus sign).

The use of this marking was partly inspired by the polar graph concept [7, 9]. Each vertex in a graph of this type is composed of two poles—the plus pole and the minus pole—and each edge incident with a vertex can be classed in one of the following two categories: edges incident with the plus pole and edges incident with the minus pole of the vertex. This principle was loosely applied to the marking of the opposite ends of the undirected edges in graph G₀. Figure 2(b) also illustrates the graphical encapsulation of the groups of edges corresponding to the switch objects (designated with symbol S_i, i = 1, …, 6).

3.2. Final Model

Stage 2 includes transformation of the primary model G₀ into the final model (Figure 3), which is represented by a specific weighted digraph G. The specification of this graph is presented in Table 3. If the transformation is used, an ordered pair of appropriate vertices  ∈ V(G), i = 1, 2, is formed for each edge e_x ∈ E(G₀) (that is, the bijective transformation function τ: E(G₀) ⟶ {[, ] | ,  ∈ V(G),  ≠ , [, ], [, ] ∉ E(G)} is applied). The two vertices representing a track in the digraph G mirror the fact that the track can be entered/left in two opposite directions.

Figure 3 

The final infrastructure model based on digraph G.

Furthermore, the vertices in digraph G can be categorised according to whether they can represent the relocation targets or not. Hence, we distinguish between destination vertices (represented by full circles in Figure 3) and connecting vertices (represented by empty circles).

Edges in the digraph G can be categorised as transit edges (shown as full lines in Figure 3) and reverse edges (shown as dashed lines). Transit edge expresses the possibility of transiting through the track modelled with a vertex (that represents a starting point of the transit edge) to adjacent tracks. Reverse edge expresses the fact that a train can change the direction of its motion (=reversal) on the track that is modelled by the starting vertex of the reverse edge.

Two transit edges representing the possibility of transiting between the tracks in 2 directions are constructed in graph G for each pair of adjacent edges (the edge construction methods are explained in Table 4). Reverse edges can start from destination vertices solely. Here, it is assumed that the whole relocation object stops on one track during the reversal operation. A situation where a train can occupy more than one track during reversal is not modelled in the digraph G. This simplification can be applied within simulators operating at the mesoscopic level of detail.

Applying the rule specified in Table 4, a reverse edge is constructed for each transit edge whose end vertex is a destination vertex. For example (referring to the graph in Figure 2), the reverse edge [, ] is formed to the transit edge [, ].

Digraph G is both vertex-weighted and edge-weighted, and the vacancies are preserved for the vertices. The following rules are applied to the weights and vacancies:(i)The weights of the vertices in digraph G (expressed through function ω) represent the metric lengths of the track segments corresponding to the weights of the respective edges in graph G₀.(ii)The weights of transit edges (expressed through function ε) in digraph G are identical with the weights of the vertices they proceed from. The weight of a specific transit edge represents the distance run by the relocation object by transiting the track that mirrors the starting vertex of that edge.(iii)The weights of reverse edges (expressed through function ε) are identical for all those edges and do not attain fixed values: instead, they are set (to value L) always before running the computing algorithm searching for a given train or shunting route (for a relocation object whose length is L). This weight is interpreted so that if the relocation object stops on a certain track (corresponding to the starting vertex of a reverse edge) for a time and then continues by moving in the opposite direction, then the used part of the track is that part whose length is identical with that of the relocation object (i.e., L).(iv)Furthermore, every vertex in digraph G has an available vacancy (expressed through function κ), expressing the metric free capacity of the respective track. Since each track in digraph G is modelled with a pair of vertices, the vacancies of the vertices express the metric lengths of the vacant parts of the track from the two opposite ends. Function κ can be used to express the rail infrastructure occupation by rail vehicles and also the blocking if its parts are unreachable due to the operation of the interlocking system (for instance, if a certain track x is blocked, then the equation κ () = κ () = 0 holds for the graph vertices , ∈ V(G)).

Examples of particular weight and vacancy values belonging to selected elements in digraph G are shown in the following (Example 1).

4. Algorithms Focused on Searching Train Routes

Now, after the final railway infrastructure model has been introduced, the algorithms for calculating train routes or shunting routes can be described. The search of the routes was based on the optimization principle consisting in minimisation of the distance run by the relocation object in question.

Dijkstra’s algorithm [10, 11] for searching the shortest routes between the vertices on an edge-weighted graph was selected as the starting algorithm. However, it had to be appreciably modified for use in the calculation of the relocation trajectories for trains or train sets (having a defined length) on the railway infrastructure.

As mentioned earlier, the railway infrastructure was modelled by digraph G, specified in Table 3.

Now, additional auxiliary sets, row vectors, and subroutines/functions to be used in the algorithms must be specified in order to enable the algorithms to be formalized. The specifications are listed in Tables 5 and 6. The subroutines/functions utilise parameters applying the following convention: the symbol “↓” denotes an input parameter, symbol “↑” denotes an output parameter, and double symbol “↓↑” denotes an input-output parameter.

4.1. Basic Algorithm

The basic algorithm (formalized as Algorithm 1) searches for the shortest route in the track layout from a specific start vertex to a specific finish vertex. The start vertex represents the end of the start track transited by the train (whole length is L) when starting its relocation procedure, while the finish vertex represents the end of the finish track transited by the train when approaching the finish position.

The main function, Shortest_Path, calculates the shortest relocation route for an object (whose length is L), given the start vertex (from the set S_V) and finish vertex (from the set F_V). The topology of this route is available through the parameter Topol. For Algorithm 1, the sets S_V and F_V include one vertex each. Further modifications of this algorithm, however, will permit one or two vertices to be included in either set.

The following procedures are carried out within the subroutines/functions (called from the main function Shortest_Path).

First, the function Start_Finish_Test tests admissible combinations of the input parameter values for the route calculation. For the combination to be acceptable, the weight of the start vertex must not be lower than the relocation object length (L), and the finish vertex must have a sufficient vacancy. Furthermore, the Boolean expression (x = y ∧ i ≠ j) must not hold true for the start vertex and finish vertex (the above expression describes a situation where the start and finish vertices refer to the same track from which the relocation procedure is started and which is entered by transiting the same end).

Furthermore, the function General_Init is used for initialisation of the marks of distances and the marks of predecessors (through vectors D and P) for all vertices in the graph. The distance marks of all vertices in the digraph G are set at the value d^∞ (which is larger than the longest distance between any vertices in the digraph G). The marks of predecessors are set at none for all vertices in the digraph G. The set T_V of temporarily marked vertices and the set U_V of ultimately marked finish vertices are initialised as empty sets.

Additional initialisation procedures associated with the start and finish vertices are subsequently run (through the function Start_Finish_Init). The start vertex is assigned a distance mark whose value is 0 (i.e., the length of the current shortest route is zero for the start vertex). Now, the set of forbidden vertices is constructed. The vertices from this set must not lie on the shortest route being sought. When the concept of forbidden vertices is applied, the relocation trajectory must not pass through vertices describing those ends of tracks over which it is inadmissible to reach the finish track (with respect to the input requirements for relocation).

Next, the admissible successors of the start vertices that can be reached through transit edges are remarked (through the function Start_Mark). These vertices-successors are assigned (i) distance marks with a value of 0 (through vector D) and (ii) marks of predecessor (in vector P) referring to the start vertex. The remarked vertices are also inserted into the set T_V.

The complex of initialisation procedures is followed by a computation cycle involving selection of a vertex (through the function Vert_Select) for processing in the current iteration step and the marking of all its admissible successors which is potentially changed (through the function Succ_Mark). This computation cycle is terminated if all the appropriate finish vertices have been ultimately marked or if T_V—the set of temporarily marked vertices—is empty.

The Vert_Select function always selects that vertex from the set T_V that has the lowest value of the distance mark . The Succ_Mark function changes the marking of the accessible successors of the selected vertex if those successors (i) have an available adequate vacancy; (ii) they are not members of the set of forbidden vertices; and (iii) the current values of their distance marks are higher than the new values mirroring their reaching through another route (via vertex ). Moreover, the Boolean expression (κ () = ω ()) must hold true for the transit successors to be accessible from the vertex . This expresses the condition that the track to which the vertex refers must be fully available for transiting. This means that the vacancy of the vertex must be equal to the weight of that vertex.

If the shortest route has been found, its topology is obtained through the function Get_Path. The topology is constructed stepwise from the finish vertex to the start vertex by using marks about the vertex predecessors (saved in the row vector P) on the shortest route.

At this point, the following comments should be added concerning the implementation of the above algorithm, transformation of its results, and an alternative view upon the start and finish points of the relocation trajectories:(i)In view of the nature of the algorithm, a data structure called forward star [31] was used for implementation of the digraph G. The forward star structure consists of two basic arrays: a primary array that stores information on the graph vertices and a secondary array that stores information on the directed edges that start from the vertices (saved in the primary array). The secondary array is sorted by the starting edge vertices. This makes it possible for each vertex from the primary array to rapidly access (through its reference to the secondary array) the group of all its successors (which are always stored in the continuous part of the secondary array). For an effective work with the set T_V, the Fibonacci heap [11], as a very efficient realization of a priority queue, was chosen for its implementation. The priorities of the elements (or vertices in the digraph G) expressed the values of the respective marks from the row vector D (the higher the priority of an element, the lower the value of its distance mark).(ii)The configuration of the railway infrastructure can be specified for the needs of the MesoRail simulator [20], for example, within the TrackEd editor [24]. This editor stores infrastructure description in the XML format, which uses templates inspired by the railML standard [27, 28].(iii)For the implementation approaches used (applying Dijkstra’s algorithm concept), the asymptotical computational complexity of Algorithm 1 can be specified as O(m + n log n) [12], where m = |E(G)| and n = |V(G)|. Nevertheless, for typical track routes that are not searched for long distances in real operational conditions, the relevant computations (within rail-traffic simulators) are concentrated on subgraphs (of the digraph G) that are usually not very extensive.(iv)The result of Algorithm 1 computations for the shortest route found in the digraph G can be reversely transformed into the primary model, that is, into the undirected graph G₀. This means that the shortest route in the digraph G corresponds to the shortest walk in the graph G₀. The walks are outlined graphically in Figures 4–6, illustrating the solution of Examples 1–3 (see later).(v)In standard parameterisation of the Shortest_Path function within Algorithm 1, the start and finish positions of the relocation procedure are assumed to be represented by vertices in the digraph G. This, in fact, means that the relocation object (whose length is L) is located “precisely” at the end of the respective track both at the beginning and at the end of the relocation operation. If it is required that the relocation operation starts and/or finishes on another part of the track, then Algorithm 1 must be slightly modified. The modification will encompass both the marking of the start vertex (and potentially its transit successors as well) and the ultimate marking of the finish vertex. The values of the distance marks assigned to the vertices within the Start_Finish_Init and Start_Mark functions will be set at a value different from 0 (denoted, e.g., reloc₁) describing the metric length of relocation to the postulated end of the start track. On the contrary, the value of the ultimate mark of the finish vertex of the relocation (denoted, for instance, val, and indicating the length of the shortest route found) will not describe the length of the relocation object trajectory precisely (denoted, for instance, dist). In fact, the length of the trajectory can be obtained as dist = val + reloc₂, where reloc₂ refers to the metric length of relocation from the postulated end of the finish track to the end position on that track.

(a)

(b)

(a)
(b)

Figure 4 

Train route related to Example 1.

(a)

(b)

(a)
(b)

Figure 5 

Train route related to Example 2.

(a)

(b)

(a)
(b)

Figure 6 

Train route related to Example 3.

4.2. Examples of Using the Basic Algorithm

A few examples of the application of the basic algorithm (Algorithm 1) to the computation of various relocation actions are shown in the following. The first example concerns the transfer of a complete train between two station tracks.

Example 1. Computation of a shunting route topology for the train relocation (L = 120).
Figure 4 shows two models of a demonstration railway yard represented by graphs G and G₀. There is one train 120 m long (relocation object O₁) on track #5 (reflected by edge e₅ in graph G₀) of the yard. The train stands at the track end, referred to as . The requirement is to find a route for transferring the object O₁ onto track #4 (represented by edge e₄ in graph G₀). The object O₁ should leave track #5 via the track end referred to as and enter track #4 via its end referred to as . This setup reflects a situation where track #5 should be made available for other trains and the train in question should be transferred to track #4, so it can leave the yard in the direction to a rail line accessible via track #11.
Parameterization of the algorithm for the track route computation (shortest route in the digraph G) is as follows:(i)S_V = {}, F_V = {}, and L = 120The weights are given for selected vertices and edges of the relevant graphs, and current vacancies are quantified for selected vertices in the digraph G:(i)ω () = ω () = 280, κ () = κ () = 280, ,  ∈ V(G), ε (e₄) = 280, e₄ ∈ E(G₀)(ii)ω () = ω () = 259, κ () = 0, κ () = 139, , ∈ V(G), ε (e₅) = 259, e₅ ∈ E(G₀)(iii)ε ([, ]) = ε ([, ]) = 280, ,, ,  ∈ V(G), [,], [,] ∈ E_trans (G)(iv)∀ [, ] ∈ E_rev (G): ε ([, ]) = 120The topology of the train route found (which corresponds to the shortest route in the digraph G and can be retransformed into the shortest walk in the graph G₀) is as follows: e₄(350) ← e₁₉(316) ← e₇(276) ← e₂₁(238) ← e₈(118) ← e₂₁(80) ← e₇(40) ← e₂₀(0) ← e₅(0)The numbers in parentheses (following each member of the walk) are the metric lengths of the relocation object’s trajectory to the points representing the input ends of the edges/tracks reached. The total length of the train’s trajectory during the relocation is 470 m. The value for the last member of the walk is additionally increased by L = 120 due to the fact that the relocation operation must be finished by a partial transfer of the whole object to the finish track (edge). For the computed shortest route in the digraph G, the figure shows the ultimate values of the distance marks for the relevant vertices.
Moreover, the reduced distance matrix (RDM) (for L = 120) between all the admissible couples of the destination vertices in the digraph G is shown in Table 7 (beyond the scope of Example 1). The RDM contains the results of differently parameterized computations made by using Algorithm 1. The matrix reflects the fact that, apart from the relocation object, which is always present on a different start track, the railway yard is entirely empty. The RDM is obtained by simple transformation of the complete distance matrix (CDM). This transformation removes from the CDM those rows and columns whose all elements attain only the d^∞ value (i.e., no shortest routes for the given parameter L exist between relevant vertices).
The next example concerns the motion of a shunting engine along a rather complex route for attachment to a specified end of a train set.

Example 2. Computation of a shunting route for the locomotive relocation (L = 20).
Figure 5 shows diagrams of graphs G₀ and G, which represent infrastructure models analogous to those in Figure 4. A 120 m-long train (object O₂) stands on track #5 of the yard; a 100 m-long train set (object O₃) stands on track #4; and a 20 m-long shunting locomotive (object O₁) stands on track #10. This locomotive is to be moved to end A of train set O₃; in other words, it must enter track #4 by transiting its end .
The track route computation algorithm (identifying the shortest route in the digraph G) is parameterized as follows:(i)S_V = {}, F_V = {}, and L = 20The weights are given for selected vertices and edges in the graphs, and current vacancies are quantified for selected vertices in the digraph G:(i)ω () = ω () = 280, κ () = 160, κ () = 20, ,  ∈ V(G), ε (e₄) = 280, e₄ ∈ E(G₀)(ii)ω () = ω () = 259, κ () = 139, κ () = 0, , ∈ V(G), ε (e₅) = 259, e₅ ∈ E(G₀)(iii)ω () = ω () = 175, κ () = 155, κ () = 0, ,  ∈ V(G), ε (e₁₀) = 175, e₁₀ ∈ E(G₀)(iv)∀ [, ] ∈ E_rev (G): ε ([, ]) = 20The topology of the train route found is as follows: e₄(1635) ← e₁₇(1601) ← e₃(1581) ← e₁₄(1543) ← e₁₅ (1501) ← e₂(1481) ← e₁₅(1439) ← e₁₆(1396) ← e₆(669)  ← e₂₄(629) ← e₁₂(609) ← e₂₃(573) ← e₉(271) ← e₂₂ (230) ← e₇(210) ← e₂₁(172) ← e₈(33) ← e₂₅(0) ← e₁₀(0)The total length of the locomotive’s relocation trajectory is 1655 m. The value given for the last member of the walk is increased by L = 20.
In the last example, shown in the following, a shunting locomotive should be moved from one end of a train set to the other end of that train set.

Example 3. Computation of a shunting route for reapproaching the same train set (L = 20).
A group of wagons, 200 m total length (object O₂), stands on track #5 of the yard whose models are shown in Figure 6. A 20 m-long shunting locomotive (object O₁) was disconnected from wagon group end B in order to attach it to end A of that group because this is needed for the planned operations. This means that the locomotive should reapproach the wagon group by transiting the end of track #5.
The track route computation algorithm (identifying the shortest route in the digraph G) is parameterized as follows: S_V = {}, F_V = {}, and L = 20The weights are given for selected vertices and edges in the graphs, and current vacancies are quantified for selected vertices in the digraph G:(i)ω () = ω () = 259, κ () = 0, κ () = 39, ,  ∈ V(G), ε (e₅) = 259, e₅ ∈ E(G₀)(ii)ω () = ω () = 175, κ () = 155, κ () = 0, ,  ∈ V(G), ε (e₁₀) = 175, e₁₀ ∈ E(G₀)(iii)∀ [, ] ∈ E_rev (G): ε ([, ]) = 20The topology of the train route found is as follows: e₅(469) ← e₁₈(428) ← e₃(408) ← e₁₇(374) ← e₄(94) ← e₁₉(60) ← e₇(40) ← e₂₀(0) ← e₅(0)The trajectory run by locomotive O₁ from the starting position () to the opposite end () of the same track (track #5) is 469 m long. If the complete length of the locomotive enters track #5, then it has run a trajectory of 489 m long. And it requires another 19 m for attachment to train set O₂, whereby the total trajectory length is 508 m.
For demonstration reasons (beyond the scope of Example 3), the RDM (for L = 20) for the destination vertices in the digraph G, containing results of the calculations for differently parameterized Algorithm 1, is included in Table 8. This matrix matches the situation where, apart from the relocation object (which is always present on a different start track), the railway yard is entirely empty. From this matrix, one can read that the trajectory of relocation between track #10 (its end ) and track #4 (its end ) is 664 m long. The shortest track route found passes through track #5. The route for the relocation (between the same tracks) is different (and differently long) from that in Example 2 because track #5 was occupied in that example.

4.3. Modifications of the Basic Algorithm

Conditions for the starting and destination positions different from those associated with Algorithm 1 may be used in the parameterization of the dynamic search of routes within a railway yard. The algorithm uses a uniquely defined track end from which the sought-for-train/shunting route should start, and this also applies to the end of the finish track. From the point of view of the final mathematical model (digraph G), it is exactly determined by one start vertex and exactly one finish vertex for the t route sought (thus, the algorithm searches for a single-source single-destination shortest path). In other words, the relation | S_V | = | F_V | = 1 holds for the set of start vertices S_V and the set of finish vertices F_V.

However, if the whole track x must be specified as the starting element (hence, leaving it through either of its ends is permissible), then the appropriate parameter of the Shortest_Path function is defined as S_V = {, }. The members of the set S_V correspond to the opposite ends of the track x in the digraph G. Analogously, the set F_V can be constructed as F_V = {, } if the entire track is regarded as the destination element and entering it via either end is permissible. So, three different modifications of Algorithm 1, for different variants of construction of the sets S_V and F_V, are feasible. A summary overview of the Shortest_Path function parameterization options is presented in Table 9.

Algorithms 2–4 differ from the basic Algorithm 1 only due to changes in two subroutines, Start_Finish_Test and Start_Finish_Init, while the remaining parts are identical. The differences in the subroutines include different procedures of testing the admissibility of combinations of the input parameter values and different ways of performing initialisation actions associated with the start and finish vertices.

The first alternative to the basic algorithm is Algorithm 2, which seeks the shortest admissible route between two two-member sets of vertices (S_V and F_V) in the digraph G (two-sources two-destinations shortest path). One run of this algorithm provides the required route (through the function Get_Path), and the start vertex (from the set S_V) and finish vertex (from the set F_V) of that route are uniquely identified. The vertices define the direction in which the start track is left and the direction from which the finish track is entered. The Start_Finish_Init function potentially eliminates (among other things) from the set of finish vertices that vertex whose vacancy is inadequate for accommodating the relocation object whose length is L.

The next modification of the basic algorithm is Algorithm 3, computing the routes from two start vertices to one finish vertex in the digraph G (two-sources single-destination shortest path). When the process is over, the shorter of the two potentially computed routes is identified. The vertex , which is the pair vertex to the vertex  ∈ F_V, is included into the set of forbidden vertices through the Start_Finish_Init function.

The last modification of the basic algorithm is Algorithm 4, seeking the shorter of two routes proceeding from one start vertex to two different finish vertices in the digraph G (single-source two-destinations shortest path). That vertex whose vacancy is inadequate with respect to parameter L is potentially eliminated from the set of finish vertices by the Start_Finish_Init function. In addition, that function augments the set of forbidden vertices with the vertex —the pair vertex to the vertex  ∈ S_V.

4.4. Verification and Validation

The life cycle of simulation studies/projects consists of a number of partial phases, as described in detail in [32, 33]. Discussed in the following is a part of the life cycle (consisting of several sequentially linked phases), with focus on the construction, verification, and validation of models that are typically used in simulation studies.(a)Phase of designing and forming a conceptual model(b)Conceptual model validation phase(c)Phase of designing and building up a computerized model(d)Computerized model verification phase(e)Operational computerized model validation phase

The models can be briefly characterized as follows:(i)The conceptual model reflects (with an appropriate degree of abstraction) the object of investigation(ii)The computerized model represents an implementation of the conceptual model on a computer

In view of the scope of this article, attention (with respect to verification and validation) will not be paid to the whole target rail-traffic simulator (as implemented within the MesoRail tool): instead, only a part of it will be targeted, viz. that part that mirrors the rail infrastructure of the object of investigation and functions determined for computing track routes along which the rail vehicles in question can move on the rail infrastructure.

The conceptual model, which reflects the rail infrastructure of the object of investigation (representing the railway system in question) and the functions calculating track routes, uses the following:(i)A mathematical model weighted digraph, as described in the Final Model section. The digraph is a result of transformation of the primary mathematical model—a weighted undirected graph. The primary model reflects rather intuitively the topological and metric situation of the rail infrastructure associated with the object of investigation.(ii)The concept of Dijkstra’s algorithm for searching for the shortest paths in graphs. The algorithm had to be modified appreciably for use in problems of determining track routes on the final infrastructure model.

Validation of the conceptual model included, in particular, assessment of suitability of both mathematical models for description of the relevant part of the object of investigation and of the algorithms reflecting the selected operations on the object of investigation. This phase used the IV&V (independent verification and validation) approach [33], applied after completing the development of the conceptual model. This implied in practice that the validation was made by an independent third-party professional (from the Czech Railway Infrastructure Administration, State Organization), who was a renowned expert in the railway traffic domain and in the application of computer simulations for the needs of railway traffic optimizations (and was the second author of this paper). The face validation (expert validation) [33] method was used, requiring that the professional performing the validation has deep knowledge of the relevant application domain (railway traffic in this case). The conclusions from the conceptual model validation process were as follows: (i) the designed mathematical models of the rail infrastructure adequately reflect the characteristics of the real railway infrastructure; and (ii) the algorithms for track route computations relating to rail vehicle shunting and train runs have been correctly logically designed so as to be able to provide outputs (i.e., specific track routes) usable in actual railway systems.

When developing the computerized model, data structures (mentioned in the conclusion of the Basic Algorithm section) were selected so as to be applicable to the implementation of the weighted digraph (reflecting the rail infrastructure) and to enable effective computations of the implemented track route searching algorithms.

The computerized model verification phase included testing of the model’s logical correctness. This means that the track routes found for the specific objects of relocation were tested especially with respect to the following conditions: (i) the length of the relocation object is respected; (ii) those infrastructure elements that are currently occupied by rail vehicles or blocked by the interlocking system are not used; and (iii) reversals are performed on admissible track segments. The testing was made on different data instances (describing 3 different rail yards) applying different relocation object lengths and differently occupied track layouts. Verification was made by the person who had developed the computerized model (and is the first author of this paper). The performance of the algorithms was found to be logically correct (after eliminating a few minor errors).

The IV&V approach and the face validation method were also applied (by the same expert as during the conceptual model validation phase) during the operational validation of the computerized model. The expert assessment of results of the track route computations (using the same track layout variant as in the computerized model verification phase) included, in particular, assessment of the operational and technical usability of the track routes identified (for different relocation object lengths) for the track layouts as currently occupied. Following analysis of all the cases of track routes examined (as obtained by using the original algorithms for the computations of the shortest paths on the weighted digraph), the expert concluded that the algorithms performed correctly from both operational and technical aspects. Based on that, this partial computerized model was embedded in the target simulator within the MesoRail software tool.

4.5. Technical Notes for Practical Use of Algorithms within Rail-Traffic Simulators

A few technical comments should be added regarding practical use of the algorithms within software tools serving to simulate railway traffic (at the mesoscopic level of detail):(a)A combined approach can be applied in the simulators when searching for the optimal train routes and shunting routes. This may include selecting from a precalculated static set of essential train routes (constructed before starting the simulation experiments) and application of dynamic computation during the simulation when seeking for the optimum shunting routes. In this manner, the simulation will not be burdened by dynamic search for selected (very frequently repeating) train routes.(b)It is typical of railway traffic that dedicated track routes are not set on the infrastructure between extremely distant start and finish tracks. Instead, the approach of stepwise construction of several shorter routes is preferred. Taking this into account, the algorithms discussed can be augmented with a limitation regarding the maximum admissible length of the track route being sought. This limitation can be used to put restrictions to the spread of the computation within the appropriate graph. This approach can eliminate undesirable instances of very complex and long shunting routes (found, e.g., in a densely occupied part of the track infrastructure). This means in practice that the algorithm may include identification of the lowest value (d^min) among all distance marks for the vertices currently included in the set T_V. The d^min value can be indicated simply when withdrawing a vertex from the set T_V through the function Vert_Select. If this value exceeds an expertly defined limiting value d^max, the computation is terminated with the result that no route was found. For the relocation object, this means that, given the current traffic situation, it will have to stay where it is for some time until the traffic situation changes (e.g., when the relevant tracks become available for the operation), and the search for the track route can be repeated.(c)Given the degree of abstraction applied, the algorithms presented work with a simplification against reality, mainly concerning reversals within the motion of a relocation object. A reversal is defined as a situation where the relocation object stops at a certain position and then continues its motion in the direction opposite to the initial direction. As mentioned above, the infrastructure model presented and the appropriate algorithms always consider a reversal as an operation occurring on one track. In reality, however, more than one track (and switch) can be engaged in the reversal of a relocation object. The simplification is appropriate for simulators working at the mesoscopic level of detail (intended, e.g., for examining the capacity of the infrastructure) because shunting operations, in particular, are not supposed to be examined in great detail. However, when examining railway traffic at the microscopic level, such simplification might provide an unsatisfactory solution, unusable for application.(d)For practical use of the algorithms in simulation experiments, one must have an idea of how much real time the computations take—such information is important for the assessment of their usability in the simulations because they should not be very time consuming. By way of illustration of the time demands, computation experiments were performed for Algorithm 1 (with the highest potential for use in traffic simulations) in a model of a basic railway yard (shown in Figure 3) and in a more extensive model of a larger real railway marshalling yard in Teplička nad Váhom, Slovakia. The latter model (represented by a digraph) contained 1178 vertices (reflecting 589 track segments) and 1905 edges (the total length of tracks in the infrastructure was 75,958 m). Different values of parameter L (reflecting the relocation object lengths) were applied, viz. L = 0, 20, 50, 100, 200, 300, 400, and 500. The shortest routes were computed for all admissible vertex couples, which satisfied the condition that their weight (or vacancy) was not lower than the applied value of parameter L (both models reflected empty railway yards). This, however, also means that—particularly for the more extensive model—such complex routes were computed as would never be actually computed within the simulators. Such routes were included in the experiments for testing purposes only. And in addition, connecting vertices were also considered as the start vertices and finish vertices (except for destination vertices) in order to increase the number of the routes computed.

The results of the calculations providing mean durations () of searches for the shortest route are listed in Table 10. Generally, the mean time of computation of one shortest route within a more extensive demonstration model does not exceed 6 milliseconds, which is a very good figure with respect to the needs of railway traffic simulators. The computations were made on a common PC equipped with an Intel i7-8550U [email protected] GHz processor and 16.0 GB RAM.

The results also reflect computations that did not find the shortest route because none exists. The search for the shortest route between the vertices and for L = 100 in the model shown in Figure 3 is an example: although both vertices have a sufficient vacancy, the vertex is inaccessible because it mirrors that end of track #10 that constitutes the boundary of the model.

5. Conclusions

In conclusion, it has been demonstrated that the presented algorithms for automated dynamic calculations of the shortest track route topologies can be used with advantage within mesoscopic rail-traffic simulators to solve current traffic problems. The routes can then be used for shunting postulated relocation objects within the railway infrastructure in the actual occupancy situation. The data to be input when searching for the route include the start and finish positions and length of the object to be relocated.

So, the algorithms presented offer a good potential for extending and improving the scope of mesoscopic railway traffic simulators as regards automated identification of track routes especially for rail vehicle shunting.

The data specification of the rail infrastructure configuration, which currently uses the XML format, can be transformed in the future into a data description that will be fully compliant with the railML standard.

From the managerial aspect, it is noteworthy that it is convenient for the simulation projects in the railway traffic domain to acquire and use such simulation tools as support rapid constructions of the simulation models and fast parameterizations of the simulation experiments. Hence, if the simulation tool selected is equipped with functionalities that automatically compute track routes for specific relocation objects during the run of the simulation program, then such a tool has a comparative advantage over other tools lacking such functionalities. This is so because in this case, the user is freed from the requirement to tediously predefine many track routes, and hence, the time of the development of the target simulation models reflecting the operation of the railway system examined is appreciably shortened.

Data Availability

There is no supplementary information attached to the research article.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

The research presented in this article was supported by the ERDF/ESF Project: Cooperation in Applied Research between the University of Pardubice and companies, in the Field of Positioning, Detection and Simulation Technology for Transport Systems (PosiTrans) (no. CZ.02.1.01/0.0/0.0/17_049/0008394).