Dynamic Automated Search of Shunting Routes within Mesoscopic Rail-Traffic Simulators

,


Introduction
e 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.
is 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). e 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. e 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. e 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. e solution has been developed for use in rail-traffic simulators working at the mesoscopic level of detail.

Literature Review
e operation of railway systems is examined and optimized by employing a number of different methods and techniques that are supported by various software tools. e main goal of such optimizations is to find such solutions which can be used to help ensure quality traffic. e 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. is 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][4][5][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. is 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. e concept of the original Dijkstra's algorithm [10][11][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][14][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]. e 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). is standard defines a recommended format of the files for the exchange of data for railway applications.
e RailTopoModel [29,30] is also available: this is a logical object model designed for standardization of the representation of railway infrastructurerelated 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. e algorithms were then tested with success within MesoRail for use in dynamic track route calculations. e 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).

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. e construction of such a model consists of 2 stages.

Primary
Model. Stage 1 includes the creation of a primary model using an undirected edge-weighted graph as specified in Table 1. e edges in the graph represent the individual tracks (or their parts) as well as the track segments of the switches. e edges reflecting the tracks are referred to as destination edges, while the remaining edges are referred to as connecting edges.
is terminology mirrors the fact that tracks can be viewed as targets for rail vehicle relocation whereas switches and track crossings cannot. e 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 0 are illustrated in Figure 1. Admissible transits in Figure 1 are specified in Table 2.
Each edge in graph G 0 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.
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 0 ). 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 (−). is 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 − e 5 � v 12 � + e 20 can be used in Figure 2. e 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). e 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. is principle was loosely applied to the marking of the opposite ends of the undirected edges in graph G 0 . 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).

Final
Model. Stage 2 includes transformation of the primary model G 0 into the final model (Figure 3), which is represented by a specific weighted digraph G. e specification of this graph is presented in Table 3. If the transformation is used, an ordered pair of appropriate vertices i v x ∈ V(G), i � 1, 2, is formed for each edge e x ∈ E(G 0 ) (that is, the bijective transformation function τ: ). e two vertices representing a track in the digraph G mirror the fact that the track can be entered/left in two opposite directions.
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. is 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 Digraph G is both vertex-weighted and edge-weighted, and the vacancies are preserved for the vertices. e following rules are applied to the weights and vacancies: (i) e 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 0 . (ii) e weights of transit edges (expressed through function ε) in digraph G are identical with the weights of the vertices they proceed from. e 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) e 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). is 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 Examples of particular weight and vacancy values belonging to selected elements in digraph G are shown in the following (Example 1).

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. e 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. Table 1: Specification of the weighted undirected graph G 0 -the primary model of the track infrastructure.

Symbols Specifications
G 0 e weighted undirected graph e edge weight function related to the graph G 0 (i) ε: E(G 0 ) ⟶ R + (the set of positive real numbers) Figure 1: e models of switches and crossings applied within undirected graphs.  (Figure 1 Double slip switch ( Figure 1 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. e specifications are listed in Tables 5 and 6. e 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.

Basic Algorithm.
e 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. e 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. e 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 ). e 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. e 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 i v x and finish vertex j v y (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. e 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). e marks of predecessors are set at none for all vertices in the digraph G. e 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). e 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. e vertices from this set must not lie on the shortest route being sought. When the concept of forbidden vertices is applied, the relocation Journal of Advanced Transportation 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).
ese 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. e remarked vertices are also inserted into the set T V . e 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).
is 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.
e Vert_Select function always selects that vertex k v z from the set T V that has the lowest value of the distance mark k d z . e Succ_Mark function changes the marking of the accessible successors of the selected vertex k v z 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 v z ). Moreover, the Boolean expression (κ ( k v z ) � ω ( k v z )) must hold true for the transit successors to be accessible from the vertex k v z . is expresses the condition that the track to which the vertex k v z refers must be fully available for transiting. is means that the vacancy of the vertex k v z 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. e 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. e 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). e secondary array is sorted by the starting edge vertices. is 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. e contains destination vertices of the digraph G (iv) e set V conn (G) contains connecting vertices of the digraph G Note: symbol "\" denotes an integer division  Table 4: Construction of edges belonging to the digraph G transformed from a related graph G 0 .
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) e configuration of the railway infrastructure can be specified for the needs of the MesoRail simulator [20], for example, within the TrackEd editor [24]. is 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) e 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 0 . is means that the shortest route in the digraph G corresponds to the shortest walk in the graph G 0 . e 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. is, 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. e 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. e 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 1 ) 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 2 , where reloc 2 refers to the metric length of relocation from the postulated end of the finish track to the end position on that track.
is tagged by a mark k d z , which expresses the length of the currently detected shortest path from a vertex i v x ∈ S V to the vertex k v z (iii) If the above path to the vertex k v z ∈ V(G) does not exist, then k d z � d ∞ (d ∞ ∈ R + 0 , and it is equal to the value that is greater than the length of the longest admissible path in the graph G) Note: symbol "\" denotes an integer division P e row vector of predecessors is tagged by a mark k p z , which corresponds to a predecessor of the vertex k v z on the currently detected shortest path from a vertex i v x ∈ S V to the vertex k v z (iii) If the above path to the vertex k v z ∈ V(G) does not exist, then k p z � none (the symbol none expresses the nonexistence of a relevant predecessor with regard to the vertex k v z ) Seq e linearly ordered set of the shortest path topology Journal of Advanced Transportation

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. e 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 0 . ere is one train 120 m long (relocation object O 1 ) on track #5 (reflected by edge e 5 in graph G 0 ) of the yard. e train stands at the track end, referred to as − e 5 . e requirement is to find a route for transferring the object O 1 onto track #4 (represented by edge e 4 in graph G 0 ). e object O 1 should leave track #5 via the track end referred to as − e 5 and enter track #4 via its end referred to as − e 4 . is 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: e weights are given for selected vertices and edges of the relevant graphs, and current vacancies are quantified for selected vertices in the digraph G: � 120 e 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 0 ) is as follows:   Start_Finish_Init(↓S V , ↓F V ) // initialisation activities related to the start/finish vertices (8) Start_Mark(↓S V , ↓L) // remarking of transit successors of the start/finish vertices (9) repeat (10) if T V ≠ ∅ then (11) Vert_Select(↑ k v z ) // selection of a new current vertex (12) if U V ≠ F V then (13) Succ_Mark(↓ k v z , ↓L) // remarking successors of the current vertex k v z (14) end (15) end (16) until (T V � ∅ or U V � F V ) // algorithm termination testing (17) Get_Path(↑↓Topol) // getting a topology of the shortest path (18) end if (x � y and i ≠ j) then (30) okay ← false // inadmissible combination of the start and finish vertices (31) exit (32) end (33) if (ω ( i v x ) < L or κ ( j v y ) < L) then (34) okay ← false // inadmissible weights/vacancies of the start/finish vertices (35) exit (36) end (37) end (38) end (39) end (40) function General_Init() (41) for z � 1 to n\2 do // symbol "\" denotes an integer division (42) for k � 1 to 2 do (43) k d z ← d ∞ // initialisation of the row vector of distance marks (44) k p z ← none // initialisation of the row vector of marks-predecessors (45) end     trajectory to the points representing the input ends of the edges/tracks reached. e total length of the train's trajectory during the relocation is 470 m. e 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). e RDM contains the results of differently parameterized computations made by using Algorithm 1. e 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. e RDM is  Journal of Advanced Transportation 13 obtained by simple transformation of the complete distance matrix (CDM). is 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). e 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 0 and G, which represent infrastructure models analogous to those in Figure 4 e topology of the train route found is as follows:  A group of wagons, 200 m total length (object O 2 ), stands on track #5 of the yard whose models are shown in Figure 6. A 20 m-long shunting locomotive (object O 1 ) 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. is means that the locomotive should reapproach the wagon group by transiting the end + e 5 of track #5. e track route computation algorithm (identifying the shortest route in the digraph G) is parameterized as follows: e weights are given for selected vertices and edges in the graphs, and current vacancies are quantified for selected vertices in the digraph G: e topology of the train route found is as follows:   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. is 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 + e 10 ) and track #4 (its end + e 4 ) is 664 m long. e shortest track route found passes through track #5. e 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.

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. e 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 singledestination 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 � { 1 v x , 2 v x }. e 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 � { 1 v y , 2 v y } 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 Short-est_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. e 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.
e first alternative to the basic algorithm is Algorithm 2, which seeks the shortest admissible route between two twomember sets of vertices (S V and F V ) in the digraph G (twosources 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. e vertices define the direction in which the start track is left and the direction from which the finish track is entered.
e 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. e 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. e vertex b v y , which is the pair vertex to the vertex j v y ∈ F V , is included into the set of forbidden vertices through the Start_Fi-nish_Init function.
e 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). at 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 a v x -the pair vertex to the vertex i v x ∈ S V .

Verification and Validation.
e 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. 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. e 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: 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. is phase used the IV&V (independent verification and validation) approach [33], applied after completing the development of the   Table 9: Variants of algorithms for calculating the shortest paths.
is 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). e face validation (expert validation) [33] method was used, requiring (1) okay ← false (4) exit (5) end (6) for each i v x ∈ S V do (7) for each j v y ∈ F V do (8) if (ω ( i v x ) < L or κ ( j v y ) < L) then (9) okay ← false (10) exit (11) end (12) end if (ω ( i v x ) < L or (κ ( 1 v y ) < L and κ ( 2 v y ) < L)) then (8) okay ← false (9) exit (10) end that the professional performing the validation has deep knowledge of the relevant application domain (railway traffic in this case). e 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. e computerized model verification phase included testing of the model's logical correctness. is 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. e 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 if (ω ( i v x ) < L or (κ ( 1 v y ) < L and κ ( 2 v y ) < L)) then (8) okay ← false (9) exit (10) end computerized model (and is the first author of this paper). e performance of the algorithms was found to be logically correct (after eliminating a few minor errors). e 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. e 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.

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. is 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. is limitation can be used to put restrictions to the spread of the computation within the appropriate graph. is approach can eliminate undesirable instances of very complex and long shunting routes (found, e.g., in a densely occupied part of the track infrastructure). is 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 . e 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. e 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. e 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. e 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). is, 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. e results of the calculations providing mean durations ( mean t) 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. e computations were made on a common PC equipped with an Intel i7-8550U CPU@1.80 GHz processor and 16.0 GB RAM. e results also reflect computations that did not find the shortest route because none exists. e search for the shortest route between the vertices 2 v 5 and 1 v 10 for L � 100 in the model shown in Figure 3 is an example: although both vertices have a sufficient vacancy, the vertex 1 v 10 is inaccessible because it mirrors that end of track #10 that constitutes the boundary of the model.

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. e routes can then be used for shunting postulated relocation objects within the railway infrastructure in the actual occupancy situation. e 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. e 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. is 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
ere is no supplementary information attached to the research article.

Conflicts of Interest
e authors declare that they have no conflicts of interest.