Dynamic Search of Train Shortest Routes Within Microscopic Traffic Simulators

Computer simulations are frequently used for rail traffic optimization. This approach, referred to as simulation-based optimization, typically employs simulation tools – simulators that are designed to examine railway systems at various levels of detail. Microscopic rail traffic simulators find use when examining rail traffic and the rail infrastructure in great detail. Such simulators typically serve to follow the positions and motions of rail vehicles (trains, locomotives, train cars) and their relocation as well as segments of the rail infrastructure (tracks, switches, track crossings). One of the typical problems to be solved by microscopic simulators within a simulation experiment is to determine the realistic (optimal) train and shunting routes (within the currently occupied infrastructure) along which the rail vehicles are moved. This paper describes novel dynamic route searching algorithms applicable to the relocation of rail vehicles within track infrastructure of railway systems. The following main topics are presented in turn: overview of solutions to the problem of finding track routes in the literature, a suitable rail infrastructure model (associated with algorithms that seek admissible routes for the transfer of the relocation objects of given lengths), graph search algorithms computing the shortest track routes (represented by the admissible shortest walks on graphs), illustrative examples of algorithms’ deployment, computational complexity of presented algorithms, comparison with other algorithms and summary of the benefits of newly developed algorithms. The use of the algorithms within the simulation tools (working at the microscopic level of detail) extends the modelling possibilities when searching for realistic track routes (especially for complicated shunting operations), which contributes to better modelling of complex railway traffic (than in the relevant existing rail traffic simulators) and thus to better application of the results of traffic simulations in practice.


I. INTRODUCTION
Traffic simulation models built at a microscopic level of detail (microscopic traffic simulators), serving to examine and optimize rail traffic systems, may be capable of mirroring real (or designed) systems as authentically as possible.
In practice, microscopic traffic simulation models examining various scenarios of simulation experiments are typically used, e.g., to address the following tasks: Detailed examination of the traffic properties of certain track infrastructure parts (within feasibility studies).
The associate editor coordinating the review of this manuscript and approving it for publication was Zhigang Liu . This type of simulation investigation is mainly applied when assessing the impact of a planned rail infrastructure reconstruction or upgrade on railway traffic. Thus, it is appropriate to compare the characteristics of the relevant traffic, for example, for the existing variant of the infrastructure configuration and for the variant after the reconstruction.
Determination of the traffic characteristics when launching new transport technological processes. The introduction of new innovative technological procedures of train handling (e.g., simultaneous shunting technique within railway yards), which can be tested by computer simulation before their deployment, represents a very good potential for increasing the efficiency of railway operation. VOLUME 10, 2022 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ Optimization of the decision-making strategies when addressing selected traffic problems (such as the assignment of alternative platform tracks to delayed trains) applying a specific optimization criterion (e.g., associated with the minimization of the sum of delays of all trains during the period examined). Simulation tools are very useful for testing various decision supports for different types of operational problems occurring randomly during the railway traffic under investigation. Innovative supports that show good results are appropriate candidates for application in practice.
Testing the robustness of train schedules/timetables and work schedules for rostering resources concerning the occurrence of random traffic disruptions (such as train delays). Simulation testing of the resilience of timetables (especially for selected critical areas on the rail network) contributes to the elimination of risks associated with the deployment of inappropriate variants of traffic plans.
When setting up the microscopic simulators, the simulation computations must mirror the processes as faithfully as possible. Among the examples of important tasks is the setting of admissible train and shunting routes for the relocation of rail vehicles within a specifically occupied track infrastructure. For well-designed automated computations to be included in a simulator, it is necessary to design and implement: (i) an appropriate track infrastructure model and (ii) efficient algorithms working over that model and computing the route topologies for the specified relocations. And it is the original infrastructure model and the original algorithms that constitute the subject of this paper.
This article follows up the paper [1] addressing the mesoscopic level of investigation, which proved to be useful when designing and implementing both a track infrastructure model and route searching algorithms for rail vehicle relocations. Mesoscopic simulators examine the rail traffic primarily for determining the infrastructure's traffic capacity rather than for faithful monitoring of all rail vehicle motions.

II. RELATED LITERATURE
Traffic simulations are widely used for rail traffic optimizations (simulation-based optimizations) with respect to specific criteria [2], [3]. For example, one of the global traffic indicators that should be minimized is the sum of the weighted delays of all trains [4] within the railway network segment of interest. A simulation experiment requires many partial optimization problems to be solved during the run (such as the assignment of alternative platform tracks to delayed trains; determining the priorities for entering the line tracks if the timetable is not followed; searching for the shortest admissible routes for rail vehicle relocations within the rail infrastructure; appropriate location of the service resources within the infrastructure; etc.), where different model types can be applied to the different partial problems. The use of partial optimizations facilitates the optimization of the traffic within the specific part of the railway network during the period of interest.
When solving the problem of searching for train routes on a track infrastructure, the route optimization can be based on a minimization of the route length. This problem constitutes a part of a wider problem called the train routing problem, which includes, among other things, the following tasks: route assignment to the trains within extensive railway network areas [5]; coordinated assignment of track routes to multiple trains in the railway stations [6], [7], [8], [9]; identification of the single train shortest route [1], [10], [11], [12]; etc. The layout of the track infrastructure on which the traffic takes place must be taken into account when addressing problems of this type. From this point of view, the specific type of investigation requires an appropriate infrastructure model and efficient algorithms. Among the track infrastructure models that are frequently used is the graph (and its implementations) as a mathematical concept dealt with graph theory [13]. The graph implementations are associated with the field of data structures and algorithms [14]. The models can use both directed graphs and undirected graphs. Many original modifications of the standard graphs are currently used, such as the double vertex graph [15], [16] and the doubly-weighted (edge-weighted and vertex-weighted) digraph [1], where the polar graph concept is loosely applied [10], [17]. Among typical problems addressed by the graph algorithms over the appropriate models is the identification of the admissible (potentially shortest) track routes along which the rail vehicles are relocated. Here, it may be advantageous to use the concept of the initial Dijkstra's algorithm [11], [14], [18], [19], which searches for the single-source shortest paths on edge-weighted directed graphs. Many modifications of this algorithm are also used when examining railway systems [20], [21], [22].
The extension of the research the results of which were published in [1] and [10] was driven by the need to broaden the modelling capabilities of the MesoRail simulation tool (briefly characterized in the supplementary material to the article [4]). This tool was initially used for mesoscopic rail traffic simulations only. As efforts were made to expand the tool to apply to rail traffic simulations at the microscopic level of detail, it became necessary to implement innovated functions for automated dynamic computations of the track routes along which the relocation objects (trains, locomotives) will be transferred (within the microscopic rail infrastructure model). To this end, the relevant initial algorithms, which have not been published so far, were re-designed and implemented. Such one-phase algorithms search the shortest admissible walks in the undirected edge-weighted graph representing the track infrastructure model. The walks represent the shortest routes within the track infrastructure. The implementations of the algorithm were successfully tested, integrated, and then tested within the MesoRail tool. The microscopic infrastructure model and the algorithms working over it constitute an original solution which (based on available literature) has not been used elsewhere. Conceptually closest to the above algorithms are approaches published in [11] and [12], where two-phase algorithms are used. The first, preprocessing phase serves to identify those track switches behind which reversals of trains (whose length is L) are feasible. The next step consists in the creation of a transformed model/graph enabling the shortest route to be computed by using original Dijkstra's algorithm during the second, routing phase. The computation result from this phase can be transformed into the shortest route in the track yard. However, the use of two-phase algorithms within very frequently called operations (searching the shortest route during the simulation experiment) is rather inconvenient from the time aspect because the preprocessing phase must be applied to each switch (regardless of its utilization). In contrast to the approaches applied in [11] and [12], the algorithms described herein compute the feasibility of train motion reversals only for those track switches that were actually reached within the computation spreading.

III. TRACK INFRASTRUCTURE MODEL
The track infrastructure model, which represents a part of the traffic simulator's state space, is represented by a specific edge-weighted undirected graph G. The definition of the graph is presented in Table 1. The edge weights (determined through the function ω) match the physical lengths of the tracks/track segments modelled by the edges. The graph edges represent both tracks (and are referred to as destination edges) and track segments (and are then referred to as connecting edges), which can be parts of track crossings or switches. The terms mirror the assumption that while the tracks serve as the relocation object destinations, switches are the connecting elements between different tracks.
So, when specifying a rail vehicle relocation requirement, both the relocation start, and finish are assumed to be represented by specific tracks (modelled by the appropriate destination edge). Furthermore, the track end over which the vehicle should leave the starting track and the track end over which the vehicle should enter the destination track can also be specified. The track ends are represented by elements of the set I(G).
Function κ is introduced for graph G: this function assigns to the two opposite ends of each edge their edge ingress vacancies. The edge ingress vacancy value mirrors the length of the free part of the relevant track from the specific end. If the two edge ingress vacancies of an edge are equal to the weight of that edge, then the track (track segment) is considered free and passable. If this is not so, the track is either occupied by a rail vehicle (vehicles) or else it is fully locked by the railway interlocking system (in which case the ingress vacancies are zero). Specific weights of selected edges and values of the ingress vacancies of selected edges are illustrated in Example 1 below.
Track crossings must be discriminated from the various types of switches when setting up track yard models. To this end, a model as a subgraph of graph G is used for each track switch type and track crossing. The mental concept of the construction of such subgraphs is illustrated in Fig. 1.
First, the schematic symbols for track crossings and tract switches are shown (as used in track yard layouts). Next, the VOLUME 10, 2022 initial graph models that intuitively mirror the connections of the elementary track segments by using graph vertices are introduced. Finally, the final graph models whose topology is adequately modified to implement their admissible passages within the calculations of the track searching algorithms are presented. ''Forbidden turns'' between edge pairs modelling the partial track segments of a switch are graphically represented by grey triangles. This expresses the fact that direct relocations between selected segments belonging to the same switch are impossible.
The structure of the demonstration track yard model is presented in the illustrative example shown graphically in Fig. 2. First, the track yard layout is shown in Fig. 2(a). Next, the initial graph model is set up (Fig. 2(b)) as an intuitive transformation of the track yard layout to an undirected graph where each track is modelled by one edge and the switches are represented by subgraphs interconnected with the edges/tracks. The total length of the tracks and track segments is 3 418 m. Figs. 2(c) and 2(d) show the final track yard model as an edge-weighted undirected graph including the final track switch models (track switches: TS1-TS6) and weights of all edges in the graph.

IV. GRAPH SEARCH ALGORITHMS
At this stage of the introduction of the new algorithms for searching train and shunting routes in track yard models it should be emphasized that the algorithms are designed for computations over the model (edge-weighted undirected graph) specified in the previous section. From this point of view, the algorithms can be classed as graph search algorithms. The optimization performed by the algorithms is based the searching for the shortest admissible walk in the graph whose topology mirrors the route in the track yard.
The inspirative starting point when designing the algorithms was Dijkstra's algorithm [18], which is applicable when searching for the shortest routes between two vertices of an edge-weighted graph. Only such applications in which the edge weights are positive were relevant. However, this algorithm had to be fundamentally extended and redesigned to meet the requirements for the route computations in the track yard models. The algorithm was required to take into account the relocation object lengths and to enable inclusion of reversals in the track routes. Once the reversals are considered, the computation results of the new algorithms are interpreted as the shortest walks rather than the shortest paths, in contrast to Dijkstra's algorithm.
Auxiliary sets, row vectors and subprograms (described in Tables 2-4) are used in the specification of the route search algorithms (in the form of pseudocodes).
In the subprograms, discrimination is made between the input parameters (labelled with the prefix ' ↓ '), output parameters (with the prefix ' ↑ ') and input-output parameters (with the two-sign prefix ' ↓↑ ').

A. PRIMARY ALGORITHM SEARCHING FOR THE SHORTEST WALK
This primary algorithm (referred to as Algorithm 1) is focused on searching for the shortest walk in the track yard model: from a specific start edge (track) e x ∈E dest (G), ϕ(e x )=(v a ,v b ), v a ,v b ∈V(G) through its specified end vertex v a ; the set S of start edge-vertex elements is constructed as S={[e x ,v a ]} to a specific finish vertex (track) e y ∈E dest (G), ϕ(e y )=(v g ,v h ), v g ,v h ∈V(G) through its defined end vertex v g ; the set F of finish edge-vertex elements is constructed as F={[e y ,v g ]} The shortest walk found mirrors the shortest route in the track yard for the relocation of an object O whose length is L.
The basic Shortest_Path routine calculates the abovespecified shortest walk whose topology it returns in the output parameter Seq. For Algorithm 1, |S|=1 and |F|=1. The algorithm modifications to be introduced later can use variants for |S|∈{1,2} and |F|∈{1,2}.
The Shortest_Path routine computation is started with a test (within the Start_Finish_Test subprogram) to find if the route can be computed for the given relocated object's start and finish positions. The route cannot be sought if S = F or if the finish edge ingress vacancy is smaller than the relocation object length, κ([e y ,v g ])<L. If the route should be found between the two opposite ends of an edge/track (e x =e y ∧ [e x ,v a ] =[e y ,v g ]), the ingress vacancy of that edge with respect to the final relocation position is temporarily modified -updated -through the Vacancy_Update function. The updated value κ([e y ,v g ]) mirrors the track (edge e y ) occupancy after the relation object O has left.
The General_Init subprogram performs general initialization operations concerning the: vertex-edge marks (contained in the sets stored in the elements of the row vector M), distance marks of vertices (stored in the elements of the row vector D) and dynamic sets T V and U V and reversal paths beyond all switches.
Hence, the elements of vector M are sets. Set m k represents the k-th element of vector M which is associated with the vertex v k ∈V(G). Cardinality of each set m k , k∈ 1, . . . , |V(G)| , equals the degree of vertex v k : |m k |=deg(v k ). The elements of the sets m k are two-component marks [len j ,e j ]∈m k , len j ∈R + 0 , e j ∈Y(v k ), j=1, . . . , deg(v k ). The dynamic length-component len j fixes the current minimum length of the walk from the start position to the vertex v k attained from the ''direction'' determined by component e j . The static edge-component e j ∈Y(v k ) contains permanent information about the edge that is incident with vertex v k . The values d k of the elements of vector D (d k ∈R + 0 , k=1, . . . , |V(G)|) mirror (for each vertex v k of the graph) the minimum of the length-components: d k =min(len j ), [len j ,e j ]∈m k , e j ∈Y(v k ). Set T V saves (during the calculation of Algorithm 1) the temporarily marked vertices of graph G. The elements of set T V are represented by the ordered triplets [v i ,e u ,q], v i ∈V(G), e u ∈E(G), q∈R + 0 , v i ∈ϕ(e u ), which contain the specification of vertex v i (labelled with mark q) attained from the direction/edge e u . Set U V potentially contains the ultimately marked fin- All elements of vector D are initialized to the value dist ∞ ∈R + 0 , a constant which is higher than the highest admissible walk length in the graph G. For each set m k (k=1, . . . , |V(G)|) from vector M, the length-components of all of its elements are initially set to the value dist ∞ . Sets T V and U V are initially set empty, the reversal paths beyond all switches are set to the status notcalc (not yet calculated).
The initialization procedures (performed through the function Start_Finish_Init) are finalized by adjustment procedures concerning the start and finish positions of the relocation route being sought. The relocation start vertex v a ([e x ,v a ]∈S) is labelled with the mark q=κ([e x ,v a ]), the value of which expresses the following fact: If the relocation object O stands on track (edge) e x (at a certain distance from the end v a through which it will leave), then the distance q to the relevant end of track e x must be run first. So, the value q in the context of vertex v a plays a role in the following settings of the D and M set elements: d a ←q, Set_Mark(↓m a ,↓e x ,↓q). Now, the first element [v a ,e x ,q], mirroring the status at the beginning of the route search process, is inserted into set T V . If the finish track/edge e y is completely free and the relocation object should enter it through its end/vertex v g (ϕ(e y )=(v g ,v h ), F=[e y ,v g ]), then the ingress vacancy of that edge/track with respect to the opposite end/vertex v h , is temporarily reduced: κ([e y ,v h ])←(ω(e y )−ε), ε∈R + 0 , ε ω(e y ). The aim of this provision is to prevent transit of the edge/track e x from the ''direction'' of the edge v h (the transit cannot occur if κ([e y ,v h ])< ω(e y )).
The algorithm continues by starting the main computation cycle. It first selects (by means of the subprogram Vert_Select using the routine Min_Dist) the vertex v c in the set T V to be processed within the next iteration step. The value of the distance mark q of the selected vertex v c is the lowest among the vertices in the set T V . Next, the element [v c ,e u ,q]∈T V , which contains the vertex v c , is removed from the set T V . Subsequently, the vertices that are adjacent to the vertex v c are potentially re-marked (through the Adj_Mark routine), if the routes to them are more advantageous than the existing ones. The computation cycle is terminated if one finish vertex has been ultimately marked (U V =∅). The alternative termination condition (T V =∅) mirrors the fact that the computation cannot propagate along the infrastructure model anymore (because no vertex from which additional improvement of the existing routes could be sought is available).
If an adjacent vertex v t ∈ adj W trans (v c ,e u ) exists, then it can be reached from vertex v c via the track/edge e s (ϕ(e s )=(v c ,v t )) provided that the latter is currently passable (κ([e s ,v c ])=ω(e s )). Vertex v t can be re-marked by means of the Try_Change_Transit subprogram (using the Set_Mark function) to a new distance value newdist←(q+ω(e s )) if the relation newdist < currdist, [currdist,e s ]∈m t , holds true. The newdist value expresses the fact that a distance that is equal to the weight of edge e s (ω(e s )) must be run to reach the end (vertex v t ) of the track/edge e s . Once vertex v t has been re-marked, the appropriate element [v t ,e s ,newdist] is inserted into the set T V .
If an adjacent vertex v r ∈ adj W rev (v c ,e u ) exists, then it can be reached via edge e s (ϕ(e s )=(v c ,v r )) provided that the  latter is currently passable (κ([e s ,v c ])=ω(e s )). In addition, it holds for the edges e u and e s that (e u ,e s )∈Z. Those edges represent a ''forbidden turn'', i.e., they mirror two track segments of the same switch between which direct relocation of rail vehicles is technically impossible. The following two assumptions must be met for vertex v r to be re-markable in the Try_Change_Reverse subprogram: First, the relation newdist<currdist, [currdist,e s ]∈m r , must apply to enable vertex v r to be re-marked to a new distance value newdist←(q+ω(e s )+L) where L mirrors the Second, free infrastructure must be available ''behind'' the switch, which means that there must be available a partial track route whose length is no shorter than L, to which the object O will be temporarily relocated (in the track yard model, this route is represented by a vacant path in the graph). The route is searched by the Depth_First_Search routine using a depth-first search (DFS) algorithm. If the route is found, its topology is saved (by means of the Upload_Path function) for later partial use when setting up the topology of the finish shortest walk.
Once the vertex v r has been re-marked (by means of the Set_Mark function), the appropriate element [v r ,e s ,newdist] is inserted into the set T V . A few facts are noteworthy as regards the DFS-algorithm computing strategy. This algorithm uses the auxiliary stack data structure, applying the LIFO (Last In First Out) strategy for the order of the vertices processed during the computation progress. The ongoing results of the DFS-algorithm computations are saved in local auxiliary row vectors ( and ). Additional auxiliary subprograms are listed in Table 5. During the algorithm computations, vector stores the distance mark values of the vertices of graph G, mirroring the current lengths of the paths to the vertices from the starting vertex v c .
Each element k , k=1, . . . , |V(G)| of vector saves information on the predecessor of vertex v k ∈V(G) within the topology of the currently found path from the start vertex v c to vertex v k . The main computation cycle is based on a stepwise withdrawal of elements from the stack and potential re-marking of their adjacent transit vertices if they can be reached through paths that are shorter than the currently found ones. The DFS-algorithm computation is terminated once it has found the first path from vertex v c whose Path-Length meets the condition PathLength≥L. The topology of this path is made available through the Get_Path function, which makes reverse browsing of the path found (by using the marks-predecessors from vector ). The computation will also be terminated if it finds that no path having the required length exists within the given (currently occupied) track yard model.
The  predecessors for the walk elements. These functions evaluate (with respect to the current vertex v c ) the distance marks from those elements (of the set m k ) that are associated with the vertices v k ∈ adj W(v c ,e c ). Based on those evaluations, the vertex-predecessor or edge-predecessor is identified for each currently processed walk element (this procedure is illustrated in Example 1). A specific procedure is used if the reverse browsing finds that two consecutive walk elements should contain edges e c and e p for which (e c ,e p )∈Z. These edges mirror the track segments of a certain track switch (TS) and are in the ''forbidden turn'' interrelation. It holds that the partial walk topology must be inserted ''between'' those elements. Data for the computation of that partial walk (represented by the path topology behind the track switch TS) were precalculated before by the Depth_First_Search subprogram and are made available by means of the Down-load_Path routine (through the Partroute output parameter).
The partial walk in question is built up and inserted on an ongoing basis into the currently constructed main walk by means of the Insert_Reversal subprogram. This subprogram first performs an ''egress'' traversal and then an ''ingress'' traversal of the route whose topology was provided by the Partroute parameter.

B. MODEL PROPERTIES AND IMPLEMENTATION COMMENTS
As regards the above primary algorithm, additional information concerning the implementation as well as the track infrastructure model properties can be presented.
With respect to the properties of the graph G:  This is a sparse graph [13] where the relation between the number of its edges (m) and the number of its vertices (n) can be expressed by a linear function. For the infrastructure model described (graph G), the computations of Algorithm 1 do no spread massively to the width (using the basic concept of Dijkstra's algorithm) because it is possible to continue in no more than 2 directions from each vertex attained. This can be illustrated on the demonstration track yard model shown in Fig. 2(d), for which we have n=22, m=24, as well as on the model of the real rail infrastructure (partially shown in Fig. 3), where n=677 and m=710. From the practical point of view, this means that the number of routes/walks (leading to the given relocation finish positions) that must be examined is considerably lower than in the case of dense (undirected) graphs. For such graphs, the relation between m and n can be expressed by a quadratic function [13].
For example, the maximum number of edges in a simple undirected graph is n ((n−1)/2). The undirected graph G can also be characterized by using the indicator d(G) called edge density [13]: d(G)=(2 m)/(n (n−1)), d(G)∈ 0, 1 . This parameter mirrors the graph sparsity/density rate expressed by the ratio of the actual-to-maximum possible number of edges in graph G. A graph is crudely classified as sparse if its d(G)<1/2, dense if its d(G)>1/2, and indifferent if its d(G)=1/2. The graph shown in Fig. 2(d) has d(G)=0.103 and the graph shown in Fig. 3 has d(G)=0.003.
Graph G was implemented by using an aggregate data structure composed of two hash tables, making their elements accessible based on keys. The one table stores the graph vertices, the other, the graph edges. Each element-vertex encapsulates an array of references at the appropriate incident edge (of which there can be up to 3). Each element-edge fixes 2 references to the relevant incident vertices. The references associated to the elements in the two tables can be used for efficient traversing between the graph vertices and edges. A Fibonacci heap [14] was used for the implementation of set T V , whereby very efficient implementation of the priority queue is attained. The priorities of its elements ([v i ,e u ,q], v i ∈V(G), q∈R + 0 , e u ∈E(G), v i ∈ϕ(e u ), are determined by the q-component value (the element priority is the higher the lower the value of its distance mark q).
The track infrastructure can be defined within a specific configuration file (in XML format), which uses templates inspired by the railML standard [35], [36]. The infrastructure models can be constructed (e.g., for the MesoRail simulator [4]), within the TrackEd simulator [37] for instance.
For the Shortest_Walk function (performing calculation within Algorithm 1), the finish relocation position ([e y ,v g ]∈F) within the track yard model (graph G) is represented by track/edge e y , reached through its particular end (vertex v g ). In reality, this means that once the relocation motion is over, object O will stand precisely at the respective end of the finish track. So, if object O is required to stand at a certain distance from the above track/edge end (vertex v g ), ≥L ∧ ≤κ([e y ,v g ]), the total distance travelled by object O must be increased by .

V. EXAMPLES OF PRIMARY ALGORITHM DEPLOYMENT
To illustrate the use of Algorithm 1, examples of its application when computing different routes within the track yard demonstration model are presented below.  The contents of the auxiliary vectors M and D when the Shortest_Walk routine is over is illustrated in Table 7 and the resulting walk Seq is presented in Table 8. For graphic reasons, each element of the walk Seq is saved on one table column and the partial components of the various elements are saved in different rows.
As mentioned above, the topology of the walk Seq is computed by the Get_Walk function, and the computation development (related to object O 1 ) proceeds from its finish position to its start position. The process can be illustrated The element [e 19 ,v 12 ] is inserted into the walk Seq. This vertex is the start vertex of the walk (and its incident edge e 5 is the start edge of the walk). So, the element [e 5 ,v 12 ] is the last to be inserted into the walk Seq, whereby the Seq construction procedure is terminated.
In summary, the topology of the complete track route in graph G, found by the computation, is: e 4 (314)←v 11 (194)←e 18 ←v 13 ←e 7 ←v 14 ←e 21 ←v 16 ← e 9 ←v 16 ←e 21 ←v 14 ←e 7 ←v 13 (40)←e 19 ←v 12 (0)←e 5 The numeral data in parentheses (following selected walk elements) describe the lengths travelled by object O 1 to the points that represent the ingress ends of the edges/tracks reached. The route travelled by object O 1 from the starting position to the ingress end (v 11 ) of the finish track/edge (e 4 ) is 194 m long. The last partial relocation to the finish track/edge requires object O 1 to travel a distance of L=120 m. So, the total relocation length is 314 m. Fig. 4 displays the ultimate distance mark values at the relevant vertices for the computed shortest walk in graph G.
For illustration, Table 9 contains the reduced distance matrix (RDM) (for L=120) containing the relocation lengths between all the relevant destination edge pairs in graph G. The RDM was calculated by Algorithm 1 (with differently defined sets S and F). The computations were made assuming that except for object O 1 (each time standing on a different start VOLUME 10, 2022 track), the infrastructure is completely empty. The RDM is obtained by simple reduction of the complete distance matrix (CDM). The reduction is based on the fact that the RDM does not include those CDM rows and columns all elements of which contain the dist ∞ value (indicating the non-existence of the walk specifying the object O 1 relocation).

B. EXAMPLE 2-SHUNTING LOCOMOTIVE RELOCATION
The example demonstrates the computation results for the relocation trajectory along which a shunting locomotive is moved to a specific end of a particular train set. Fig. 5 shows the model of the track yard, now occupied by 3 relocations objects: object/train O 2 100 m long stands on track/edge e 5 ; object O 1 -a regional multiple-unit train 50 m long − stands on track/edge e 10 ; and object/train O 3 50 m long stands on track/edge e 4 . The task is to relocate object O 1 to track/edge e 4 via track/edge end v 9 .
The following settings apply to the track route computation (by the Shortest_Walk routine):  10 The total length of the trajectory travelled by object O 1 is 1752 m.
This example can be used to demonstrate the irreplaceable role of the distance marks from vector M in this situation where the distance marks from vector D are not sufficient (in contrast to the traditional Dijkstra's algorithm). This case is associated with vertex v 19    the set of its adjacent transit vertices. Where the condition: currdist>706 (666 + ω(e 23 )) was met and hence, the current value (currdist) of the mark ([currdist,e 23 ]∈m 18 ) could be changed, this was performed.
From the above description it will be clear that the minimum (639) from the distance marks of vertex v 19 mirrors correctly the length of the shortest walk to this vertex via edge e 22   If the whole track yard including track e 5 were unoccupied (except for the start track e 10 ) and the remaining parameters remained unchanged, the track route would be as follows: e 4 (724)←v 9 (674)←e 16 ←v 8 ← e 3 ←v 6 ←e 14 ←v 6 ←e 3 ← v 8 (590)←e 17 ←v 10 (549) ←e 5 ←v 12 (290)←e 19 ← v 13 (250) ←e 7 ←v 14 (210)← e 20 ←v 15 (172)←e 8 ←v 20 (33)←e 24 ←v 21 (0)←e 10 In this case, it is possible to find a track route that is substantially shorter (724 m) than with the basic parametrization in Example 2 (where the route is 1752 m long).
In the parametrization in Example 2, no track route is found if the L value is changed to L=150. Track/edge e 4 cannot be accessed via its end/vertex v 9 because a relocation object 150 m long cannot perform the required reversal on track/edge e 2 due to the inadequate vacancy − ω(e 2 )=100.

C. EXAMPLE 3-LOCOMOTIVE SERVING ONE TRAIN
This example demonstrates a case where a shunting locomotive is relocated from one train end to the other end. A train car set without a locomotive, 200 m total length, stands in the track yard the model of which is shown in Fig. 6. The car set is regarded as object O 2 standing on track/edge e 5 . A shunting locomotive − object O 1 -20 m long has just been uncoupled from the train to be coupled up to it at the opposite end A. For this, the locomotive must enter track/edge e 5 through its end v 10 .
The The contents of the auxiliary vectors M and D once the Shortest_Walk subprogram is over is listed in Table 12 and the resulting walk Seq, in Table 13 (this walk includes 2 reversals: v 13 ←e 7 ←v 13 and v 8 ← e 3 ←v 8 ).

VI. EXTENSIONS OF THE PRIMARY ALGORITHM
Algorithm 1 is designed to search for the shortest route in the model of a currently occupied track yard. The route starts from one end of the start track (where object O is present) and leads to one defined end of the finish track (to which object O is to be relocated). This can be referred to as the single-source single-destination shortest walk (that is, |S|=|F|=1).
If no requirement exists as to the end through which object O should leave the start track and/or the end through which the object should access the finish track, then Algorithm 1 must be modified: set S and/or set F (|S|∈{1, 2}, |F|∈{1, 2}) must be specified differently. This is so because it can be irrelevant through which end the start track is left and/or through which end the finish track is accessed. The combinations of the differently specified sets S and F that are associated with the different modifications of Algorithm 1 are listed in Table 14.    routines test by various methods the admissibility of combinations of the input parameters and perform the initialization operations regarding the relocation start and finish elements.
Algorithm 2 searches for the shortest admissible walk between two two-member sets S and F (|S|=|F|=2), that is, a two-sources two-destinations shortest walk. From the practical point of view, this means that the algorithm starts its propagation in 2 directions from the side vertices of the same edge (mirroring the opposite ends of that track on which the relocation object O stands). Hence, initialization includes a procedure during which two elements representing the two possible starting positions (two sources) of the route are inserted into set T V (temporarily marked vertices). If the walk was found, the algorithm was terminated under the condition that one of the finish vertices was withdrawn from the set T V . The use of Algorithm 2 is illustrated in Example 4. VOLUME 10, 2022  Algorithm 3 applies the two-sources single-destination strategy. The potential result obtained with this algorithm is the shorter of the two walks starting from the specific start positions (the two side vertices of the start edge) and ending in one specified finish position.
The last modification of the primary algorithm is Algorithm 4 which makes the single-source two-destinations type search, that is, searches for the shorter of two walks starting from one start position and leading to two defined finish positions (the two opposite ends of the finish track).

A. EXAMPLE 4-TWO-SOURCES TWO-DESTINATIONS SEARCH
A locomotive (object O 1 whose length is L=20 m) stands on track/edge e 6 of the track yard shown in Fig. 7 The contents of the auxiliary vectors M and D once the Shortest_Walk routine is over is listed in Table 15 (Table 15).

VII. VERIFICATION AND VALIDATION
The track infrastructure models and shortest route searching algorithms described in the previous sections were implemented within the MesoRail simulator [4]. While initially designed for mesoscopic rail traffic simulations, this simulator was extended recently to be applicable to microscopic simulations as well. Several case studies mirroring different parts of the Czech railway network infrastructure were used for testing. Each case study included the track infrastructure of both selected railway lines (or their parts) and a selected relevant railway station. To illustrate the time demands of the track route searching algorithms, the next parts of this paper use the results of a case study dealing with the application of the algorithms to a model of the infrastructure of the Pardubice Main Train Station (Pardubice hl.n.) and the adjacent railway network (the total length of this track infrastructure was: 71 514 m).
Verification and validation (of the infrastructure models and track route searching algorithms) followed the same procedure as described in detail in ref. [1]. The procedure is based on the approaches published in refs. [38], [39].
First, attention was paid to the conceptual model, containing 2 components: (i) An undirected edge-weighted graph (mathematical model reflecting the topological situation and associated lengths of the track infrastructure elements).    (ii) Graph algorithms computing the shortest admissible walks reflecting the routes along which the relocation objects can be moved in the track yard. Such algorithms build on the basic concept of Dijkstra's algorithm, which had to be substantially modified and completed. Conceptual model validation focused on the appropriateness of both the mathematical model describing the track infrastructure and selected algorithms working over the mathematical model. The approach referred to as IV&V (Independent Verification & Validation) [39] was used: this is based on an expert assessment by a professional in the respective application domain. Specifically, a renowned independent railway traffic expert -employee of the railway transport company ČD -Informační systémy a.s. (Czech Railways -Information Systems) was hired for this assignment. This expert used the Face Validation (Expert Validation) method [39], requiring in-depth knowledge/expertise in the rail traffic system domain. The following conclusions arose from the conceptual model validation: (i) the mathematical model of the track infrastructure reflects the topological properties and lengths of the actual track elements adequately faithfully; and (ii) the algorithms for the computation of the rail vehicle relocation routes (and working over the given mathematical model) are conceptually well-designed to provide results matching the relevant solutions in practice (i.e., the realistic topologies of the routes in the specifically occupied track yard). Topological correctness of the routes found, especially with respect to the reversals of the specifically long relocation objects.
Accounting for the track occupancies (by rail vehicles) or their blocking by the interlocking system.
The verification procedure was performed by the authors of this paper, who found the computation results obtained with the relevant algorithms in the case studies to be logically correct. Some wrong results also occurred, of course, and were corrected by modifying the algorithm implementations accordingly.
The process of checking the suitability of the computerized model was concluded by its operational validation, made by the above Czech Railways company expert using the IV&V approach and the Face Validation method. In the various case studies, the traffic and technical admissibility of selected representative routes (delivered by the algorithms being tested) was examined for the specifically occupied track infrastructure and the specific relocations of the differently long rail vehicles. As a result, the solutions produced by the algorithms were classed as correct, both from the traffic aspect and from the technical aspect. Taking the validation results into account, the algorithms were integrated into the MesoRail simulation tool and are now routinely used.

VIII. COMPUTATIONAL COMPLEXITY AND PRACTICAL USE OF THE ALGORITHMS
This section analyses (formalizes) the computational complexity of the algorithms introduced above (regarding the implementations) and includes comments on the practical use of the algorithms for rail traffic simulations.

A. COMPUTATIONAL COMPLEXITY OF THE ALGORITHMS
The term computational complexity refers herein to the upper bound for the asymptotic computational complexity of an algorithm, which can be formalized by means of the big-O notation [14]. To express the total computational complexity of the algorithms described in the preceding sections (Algorithms 1-4), each algorithm must be first decomposed VOLUME 10, 2022 into parts that will be independently analyzed (from the computational complexity aspect).
As mentioned in the previous sections, Algorithms 1-4 use (i) a modified concept of Dijkstra's algorithm (applied to the calculation of the shortest path between two graph vertices) and (ii) the concept of the depth-first search (DFS) algorithm. The two concepts are used in independent parts of the programs and hence, can be analysed separately. The total computational complexity of the algorithms is then obtained by subsequent aggregation of the results of that analysis.
Each computation of the DFS-algorithm is used to determine the topology of the first free path found (in the undirected graph G specified in Tables 1-2), which serves to locate an object (with a length L) on the modelled rail yard infrastructure ''behind'' the track switch before reversing the direction of its movement. The complexity of one computation run of this algorithm can be expressed as O(m + n), n=|V(G)|, m=|E(G)| [14]. The maximum possible number of reversals computed on graph G (during the computation of each of the Algorithms 1-4) is |Z|≤ m/2 . This means that the DFS-algorithm can be computed no more than m/2times on a maximum of m edges of graph G (this is the upper bound of the number of edges passed through during a computation). Hence, the total computational complexity associated with the repeated use of the DFS-algorithm can be expressed as O((m/2)·(m + n))=O((1/2) m 2 +(1/2) m n). If the upper bound of the number of edges in graph G is considered to be m=(3/2) n, then the complexity can be written: O((15/8) n 2 ). A simple illustrative example of a graph G for which m=(3/2) n is shown in Fig. 8.
Computations of the modified Dijkstra's algorithm are also performed over the undirected graph G ( Table 1). The standard expression of the computational complexity of the original Dijkstra's algorithm, however, is associated with its application over an edge-weighted directed graph G, for which we have: G=( ,E,ϕ,ω), =| (G)|, If this algorithm uses a Fibonacci heap for the implementation of the set of temporarily marked vertices, then it exhibits the complexity: O( log + ) [14]. Each vertex k ∈ (G) has available just one mark k ∈R + which, during the computation, reflects the current length of the current shortest path from the starting vertex a ∈ (G) to vertex k . During the computation of the original Dijkstra's algorithm, each oriented edge is passed through/processed once at the most.
When the modified Dijkstra's algorithm concept is used within Algorithms 1-4, the changes against the original Dijkstra's algorithm must be analysed when examining the computational complexity. This practically means that the computations performed on the basic undirected graph G can be illustrated as computations performed over a virtual ''transformed'' directed graph G, for which the parameters =| (G)|, =|E(G)| must be primarily determined and compared to the parameters n=|V(G)|, m=|E(G)| of the initial graph G.
Each vertex v k ∈V(G) has available a maximum of three marks: [len j ,e j ]∈m k (len j ∈R + 0 , e j ∈Y(v k ), j=1, . . . , deg(v k ), deg(v k )∈1,2,3); the mark values mirror the current lengths of the shortest walks leading to vertex v k through its different incident edges during the computation. In the context of the storage and potential removal (through the Extract_Min function [14]) of each vertex from set T V (implemented by using the Fibonacci heap), the upper bound of the number of vertices in the virtual graph G can be determined as =3 n.
Each edge e u ∈E(G) can be passed through/processed four times as a maximum (this case is illustrated in Fig. 9 on edge e 3 as part of the infrastructure model fragment shown. So, with respect to the re-marking (by means of the  Decrease_Key function [14]) of each vertex in set T V (implemented by using the Fibonacci heap), the upper bound of the number of edges in the virtual graph G is =4 m. If the computation were to be performed in the virtual graph G, VOLUME 10, 2022  measures would have to be made to ensure meeting of the condition that an oriented edge can be passed through no more than once (as in the original Dijkstra's algorithm). So, the computational complexity of the modified Dijkstra's algorithm within the computations of Algorithms 1-4 can be expressed as O( log + )=O(3 n log 3 n+4 m). If the upper bound of the number of edges is m=(3/2) n, then the computational complexity can be alternatively expressed as O(3 n log 3 n + 6 n). Fig. 9 shows the sample computation of Algorithm 1 seeking for the shortest route for the relocation of a train which is 200 m long. Among the 4 different treatments of edge e 3 (during the different computation phases), one of the incident vertices of e 3 is re-marked in 3 cases (Figs. 9(c), 9(d) and 9(e)). In one case the condition for vertex (v 5 ) re-marking is not satisfied and so that vertex is only examined (Fig. 9(f)). Two of the 4 cases -Figs. 9(c) and 9(e) -mirror the situation where the potential passage through the relevant edge (e 3 ) is not immediately preceded by train movement reversal, whereas the other 2 cases -Figs. 9(d) and 9(f) -describe the potential start of the train movement through e 3 immediately following a reversal.
The total computational complexity of each of the Algorithms 1-4 can be expressed by combining the partial computational complexities of the modified Dijkstra's algorithm and the DFS-algorithm: O((15/8) n 2 + 3 n log 3 n + 6 n). (1)

B. COMPUTATION TIME DEMANDS
For using the algorithms within simulation experiments, it is useful to know how long each program will actually run in real time. This is important for practical reasons: simulations should not call too many time-consuming routines or else they are unusable. Examples of the mean times (and maximum times) taken by Algorithms 1-4 for two demonstration track infrastructures are included in Tables 17-20. The first infrastructure describes the demonstration track yard shown schematically in Fig. 2 (a), the second infrastructure refers to the track yard of Pardubice hl.n. and some parts of the adjacent rail network (a part of this infrastructure is schematically shown in Fig. 3). Pardubice hl.n. represents a medium-sized passenger railway station. There are 2 double-track lines and 1 single-track line adjacent to the station. These lines lead to neighboring railway stations, whose models are also part of the investigated simulation system. The infrastructure model also includes 97 single switches, 3 track crossings and 15 transit station tracks. The second infrastructure model (including Pardubice hl.n.) -an edge-weighted undirected graph -encompasses 677 vertices and 710 edges and its total track length is 71 514 m. Different relocation object lengths were used in the computation experiments: L=0, 20, 50, 100, 200, 300, 400 and 500.
The shortest walk was computed for all the admissible start and finish track pairs (the latter represented by destination edges in the model) regarding the track yard as empty. The condition was imposed that the start and finish track/edge weights are no lower than the L value. From the results it can be concluded that the mean computation time ( mean t) of a track route (represented by the shortest admissible walk in the infrastructure model) did not exceed 2 milliseconds in a rather extensive demonstration case study. Computations through which no shortest walk was found because none exists are also included. From the point of view of rail traffic simulations, the above mean computation time can be considered very favourable because it does not stress the system significantly more than other computation routines involved in simulations. The computations were made on a PC equipped with an Intel i7-8550U CPU@1.80 GHz processor, 16.0 GB RAM.

C. COMBINATION OF STATIC AND DYNAMIC COMPUTATIONS
Static and dynamic computations can be combined during the rail traffic simulations aimed at finding the optimum track routes for the train riding and shunting. Static computations are made by the algorithms before starting the simulation experiments and they may result in a quite extensive base of frequently used alternative routes for train relocations. The routes in the base are computed for the conditions of a free track infrastructure and preference can be given to no-reversal train relocation routes. Dynamic computations are made during the simulation experiment and are largely used to identify routes for rolling stock shunting and some train running routes. Such combinations can bring about reduction in the computation demands of the simulation program runs because the number of dynamic computations of the (frequently repeating) track routes is then lower.

IX. ADDITIONAL POTENTIAL ALGORITHM MODIFICATIONS
Additional modifications and/or extensions of the algorithms presented are feasible. Some are introduced below.

A. ROUTE LENGTH LIMITATION
Very long track routes between the given start position and the desired finish position are seldom set in real rail traffic. If a rail vehicle needs to be relocated at a long distance, the approach typically consists in consecutive setting of several shorter routes. This strategy can be inspirative for the specification of the requirements for rail vehicle relocation in infrastructure models that are parts of railway traffic simulators. This means in practice that the potential requirements for finding a long route in a simulation trial can be divided into multiple requirements for searching several shorter routes. The partial routes lead consecutively to partial finishes, the last being identical with the desired finish of the complete (long) relocation. For this, a next parameter might be introduced in the route searching algorithms to specify the maximum admissible route length (dist max ) that is still acceptable as the algorithm computation result: no longer routes would be sought and the computation procedure would be terminated. So, if no route is found, the relocation object must temporarily stay in its current position. The requirement for finding a route is repeated after any traffic change (e.g., after another object leaves a track).
For the computations, the condition under which the distance mark of a vertex v∈V(G) (i.e., currdist) can be changed to a new value (newdist∈R + 0 ) would have to be extended. This extension of the condition (which is included in rows 83 and 98 of Algorithms 1-4) is as follows: newdist<currdist ∧ newdist≤dist max . If this condition is not met, vertex v∈V(G) is not re-marked or inserted into set T V .

B. RESTRICTIONS ON REVERSALS
If the route is required to contain no reversals, the algorithms can be simply modified as follows. The code in rows 71-75 is removed (with no substitution) from the Adj_Mark function. This means that if the neighbours of the current vertex v c are examined, vertices from the set of its reverse adjacent vertices are omitted (and are not re-marked). So, the algorithms will identify only such routes (e.g., for the relocation of trains) as do not require the relocation object's direction of motion to be reversed during the relocation operation.
In another approach, routes involving reversal are not inadmissible, but priority is given to reversal-free routes. This can be achieved, for instance, by imposing an expert penalty on each reversal included in the route: for instance, the length parameter of each reversal can be increased by a penalization constant (penconst). As a result, routes with reversals will be selected only if reversal-free routes either do not exist or are too long. The way to do this consists in a minor modification in row 97 of the Try_Change_Reverse function, where the new distance-mark value (newdist) is calculated as newdist←(q+ω(e s )+L+penconst). It must be borne in mind, however, that in this approach, the vertex distance marks will not contain the true relocation distances anymore: instead, the distance will potentially be increased by the penalty for reversals. This fact must be accounted for when imposing any route length limitations.

C. SIMPLIFIED PROCEDURE TO GET THE ROUTE TOPOLOGY
The computation aimed at gaining the shortest route topology (by the Get_Walkfunction) can be simplified by expanding the state space by adding another dynamic component (edge P e j m k from vector M. Edge P e j is the edge-predecessor of edge e j on the walk being sought. Edges e j and P e j are incidental with the same vertex v i . So, the elements m k are defined as follows: m k = {[len j , e j , P e j ]|len j ∈R + 0 , e j ∈Y(v k ), e j , P e j ∈Y(v i ), v k , v i ∈V(G)}, |m k | = deg(v k ), k = 1, . . . , |V(G)| Hence, the implementation of the Get_Walk function can be modified (simplified) for reverse browsing of the walk found. In this modification, it is possible to consecutively reversely traverse directly over the predecessors of each vertex and edge visited while the Insert_Reversal function is used in the unchanged form.
For this extension, the transfer and setting of the P e j components during the computation must be treated. Another parameter must be added to the Set_Mark function for the input of edge P e j . The function calls must be modified in rows: 51 (input value: none u

D. HEAD-OF-TRAIN MONITORING
If the train in the finish relocation position is required to be oriented specifically in one of the two possible directions, steps must be made to follow either the head-of-train (heot) or the end-of-train (eot) during the computation. For example, Algorithm 3 can be modified into Algorithm 3M.
The Algorithm 3 modifications to give Algorithm 3M are as follows: The set of the start edge-vertex elements S and the set of the finish edge-vertex elements F obey the relation: S,F⊂I(G)×{head,end}, |S|=2, |F|=1 (a two-sources single destination search algorithm).
The elements [[e x ,v a ],head],[[e x ,v b ],end]∈S specify that the relocation object -train -stands on edge/track e x so that the head-of-train is oriented towards vertex v a and the en-of-train is oriented towards vertex v b . The element [[e y ,v g ],ind]∈F specifies that the relocation finish track/edge is e y and this must be entered through the end v g . In addition, it is determined that the train must enter the finish track by its precisely defined part (front part or back part, ind∈{head,end)}.     15 , which stores the current value (118) of the distance mark of vertex v 15 with respect to its attainment by the train head through edge e 20 . As a practical consequence of the structure modification of the elements from the sets m k , we can follow not only the potential attainment of any vertex through all incident edges but also the attainment by either of the train (relocation object) ends. The algorithm is successfully terminated if the specified finish position has been attained by the required train end. If the finish position is approached by the other train end, the train must not proceed further by transiting the finish edge. This must be taken into account in the algorithm.
In relation to the structure modification of the elements of the sets m k , the implementation of Algorithm 3M should modify (against that of Algorithm 3) those parts that are associated with the initializations of the above elements, with their reading and re-marking (by the Get_Mark and Set_Mark functions). Furthermore, provisions can be made for the Try_Change_Reverse routine to be able to change the train ride orientation -once the reversal is over, the other adjacent vertices will be attained by the train end opposite to that before the reversal. As regards the attainment of the vertices potentially by either train end, the use of the two-row vectors head D a end D is convenient. They are used in a way analogous to that for vector D in Algorithms 1-4.
For the finish position of the relocation object O (whose length is L) it can be potentially required that the heot is located in a given point R at a distance of meters from the approach end/vertex v g of the finish track/edge e y ([[e y ,v g ],head]∈F, ≥L ∧ ≤κ([e y ,v g ])) -point R can mirror, e.g., the railway signal. For the above example, the total object O relocation length is head d g + where head d g is the value of the relevant distance mark of vertex v g stored in vector head D.
The procedures to analyse Algorithm 3M may be similar to those used in the analysis of Algorithms 1-4 (and described in Section VIII.A). Since the train orientation is relevant, the number of variants by which each edge of graph G is passed is twice as high as in the orientation-free approach. In addition, each vertex v k ∈V(G) has available a maximum of six marks (|m k |=2 deg(v k ), deg(v k )∈1,2,3). In this context, the upper bounds of the number of edges and vertices in the virtual graph G are =6 n, =8 m. If the upper bound of the number of edges is m=(3/2) n, then the complexity of the modified Dijkstra's algorithm can be alternatively expressed as O(6 n log 6 n + 12 n). After adding the complexity of the DFS-algorithm, the total computational complexity of Since only the basic concept of Algorithm 3M is described here, the changes with respect to this algorithm will not be described in more detail.

E. ALTERNATIVE APPROACHES TO THE TRACK ROUTE EVALUATION
Evaluation of the identified track routes (admissible walks in the graph) by means of the total distances travelled by the relocation objects may not always be the most suitable approach. Alternative measures may include, e.g., inclusion of the object relocation times. This means that the graph edge ''length'' weights will be completed with their ''time'' weights. Such time measures (τ : E(G)→R + ) mirror the estimated times required for the particular relocation object to pass through the relevant track or track segment. The times taken by train reversals would also have to be estimated.

X. COMPARISON WITH OTHER ALGORITHMS
Comparison of the presented new algorithms with other algorithms that are focused on searching for the shortest routes within the track infrastructure is quite difficult, due to the fact that for other algorithms: their detailed formal description is often not availablethis typically applies to algorithms used within commercial software tools focused on rail traffic simulations, their total asymptotic computational complexity is not quantified, their focus is different to a greater or lesser extent (e.g., some algorithms do not take into account the length of the relocation object), it is not possible to practically verify the time complexity of their computations (due to the unavailability of their implementation).
The algorithms described in Sections IV and VI and their potential further extensions in Section IX, are referred to as DynSTR-algorithms(Dynamic Search of Train Routes). VOLUME 10, 2022 From the available literature, these algorithms can only be roughly compared with the SCRP-algorithm(Single-Cut Routing Problem) described in [11] and [12]. The aforementioned comparisons can be made in the categories listed in Table 23.
The SCRP-algorithm is a two-phase algorithm, in which the first phase (preprocessing phase) is used to calculate for all switches on the primary track model (edge-weighted undirected graph) whether it is possible to reverse the specified train (defined by its length L) ''behind'' them. Based on the result of this phase, the transformation of the primary graph into the final graph (edge-weighted directed graph) is performed. On the final graph, the shortest relocation route is computed (routing phase) as a classical shortest path using Dijkstra's algorithm.
In the preprocessing phase, a linear programming method (computing the reduced longest path problem) is applied, which is able to achieve the result in polynomial time for certain track infrastructure topologies. However, the specific computational complexity for the relevant class of problems is not given by the authors.
On the other hand, DynSTR-algorithms are single-phase algorithms that combine the principles of two computational methods (a modified Dijkstra's shortest path search algorithm) and a Depth-first search algorithm that computes path topologies for train reversals only ''behind'' those switches that were reached during the computation.
A classical comparative analysis of these algorithms cannot be performed, since the authors of this paper do not have enough information on both the implementation of the SCRPalgorithm (in particular its preprocessing phase) and the expression of its respective total asymptotic computational complexity.
However, for the needs of massively called shortest route computations during traffic simulations, the deployment of DynSTR-algorithms seems to be more appropriate, as these purposely focus only on the computation of one specific route (on the currently occupied track infrastructure) and the corresponding computations do not focus on any parts of the infrastructure model, that were not reached during the computation (unlike the SCRP-algorithm, which calculates the feasibility of reversals for a given train with respect to all switches within the track layout during the preprocessing phase -regardless of whether or not these are used in the next routing phase).

XI. CONCLUSION
In conclusion, the above algorithms for automated dynamic search (made during the simulation computation) of the shortest track routes can be included in microscopic railway traffic simulators. The routes found mirror the optimum ways to relocate an object within a specifically occupied rail infrastructure represented by a model-graph. The input parameters for the simulation include the relocation object's start and finish positions and its length.

A. SUMMARY OF KEY CHARACTERISTICS OF ALGORITHMS
The novelties of the presented algorithms can be summarized as follows: The shortest track route within rail infrastructure is searched within the relevant infrastructure model (represented by the edge-weighted undirected graph) as the shortest admissible walk.
The algorithms are based on the combination of the principles of the Dijkstra's algorithm and the Depth-first search algorithm.
The lengths of modelled relocations objects (the trains or train sets) are considered during computations of shortest admissible walks.
The use of the algorithms described in this paper extends the modelling possibilities when searching for realistic track routes (especially for complicated shunting operations), which contributes to better modelling of complex railway traffic (than in the relevant existing rail traffic simulators) and thus to better application of the results of traffic simulations in practice. In addition, the application of the algorithms supports significant simplification of the simulation experiment scenario parametrization compared to approaches that do not include such dynamic computations. The user is freed from the task to tediously pre-define many track routes and hence, the time needed to set up the computer simulation models of the rail systems is appreciably shorter.
The track route optimization method consisting in a minimization of the total route length responds to the practical requirement to cut the railway traffic cost as much as reasonably achievable. In the current environment where electromobility (also in the railway domain) is massively supported, the optimization criterion can be applied with advantage to the traffic patterns of the electric/battery shunting locomotives operating within non-electrified infrastructure zones. For this case, the minimization of the shunting route lengths is interrelated with a maximization of the times between the locomotive recharging periods.