RAILWAY TRAFFIC MANAGEMENTMeet & Pass Problem∗

Pedro A. Afonso, Carlos F. BispoInstituto de Sistemas e Robotica, Instituto Superior Tecnico, Av. Rovisco Pais, 1049-001 Lisboa, Portugal

pafonso@sapo.pt, cfb@isr.ist.utl.pt

Keywords: Re-scheduling, Single Track, Railway, Meet and Pass, Train, Conflict, Decision Support System.

Abstract: With the growing interest in the railway sector, mainly because of energetic reasons, there is also a needto increase the efficiency of the railway lines. One way to optimize this sector is to improve quality in thetrain control process itself. Nowadays, train dispatching is still mostly done by human operators that useelementary tools and thereby solving conflicts sub-optimally. Motivated by these factors, this report presentsa model capable of detecting and solving conflicts, for single track railways. More specifically, this modelproposes two resolutions methods: a heuristic resolution and a search for the optimal solution. To evaluate thequality of the developed model, several tests were made, obtaining encouraging results. These results showedthat it is possible to solve conflicts optimally or near optimally, in a feasible amount of time. This programcomes with a graphic interface so that the interaction with the dispatcher can be more user friendly. The majornovelties of this work regard the improvement on the conflict detection process, the introduction of capacityconflicts, and the creation of several parameters to adjust the search for the optimal solution.

1 INTRODUCTION

The railway industry plays a vital role in many coun-tries. All railway companies try to achieve more reg-ular and reliable train services, in order to satisfy theircustomers. One way to optimize these services isto improve quality in the train control process itself.Therefore, railway operators plan train services in de-tail (i.e. timetables), defining the train order and tim-ing, at junctions and platforms. A robust timetableshould be able to deal with minor delays occurringin real-time. However, unexpected events such astechnical failures, track incidents, etc., may cause pri-mary delays, which affect the running times, dwellingand departing events. Due to the interaction betweentrains, these delays may be propagated as secondarydelays to other trains, and so, disturbing the entire net-work. This is why train dispatching is very important.Not only do dispatching orders keep the railway safefrom collisions, but also have the objective of mini-mizing secondary delays throughout the network. As∗This work was supported by the FCT (ISR/IST pluri-

anual funding) through the PIDDAC Program funds.

the first objective may be simpler to ensure, the sec-ond one is a lot more complex and challenging. Evenso, train dispatching is still mostly done by humanoperators that use elementary Decision Support Sys-tems (DSS). These systems help them to quickly andeffectively re-schedule train movements, according tosimple dispatching rules. Such rules solve conflictsby means of a simple and local decision criterion,not taking a global look at the system and hence, notsearching for an optimal solution. In the last decadehowever, with the strong competition facing rail car-riers, the privatization of many national railroads, andthe enormous advances in technology, like comput-ers and telecommunications, many researchers devel-oped new optimization models. Despite the recentadvances, providing satisfactory solutions for such acomplex problem is still drawing the attention of re-searchers.

The main goal of this work is to develop, imple-ment, and evaluate a model capable of solving themeet and pass problem and then provide feasible so-lutions to the human controller. The objectives of thiswork are: Detect conflicts between trains in a single

railway line; Create a first solution for the conflicts,in a short period of time; Search for the optimal so-lution; and Propose several near optimal solutions tothe dispatcher.

The paper is organized as follows. Section 2presents a review on the train re-scheduling problemas well as the main technologies and systems alreadydeveloped to address the problem. Firstly, some basicnotions and terminology about this problem are pro-vided. Section 3 introduces the model developed inthis paper, by presenting its architecture and a func-tional description of each of its modules. Then themathematical formulation of the model is providedalong with two formal results that reduce the com-plexity associated with finding conflicts. Section 4presents a description of all the modules that consti-tute the developed application, particularly the algo-rithms implemented, in order to allow the reader toget an understanding of the entire process. Section 5presents a summary of the results for the tests carriedout to evaluate the proposed solution. Finally, Sec-tion 6 is dedicated to the conclusions.

2 BASIC CONCEPTS

In this section we will start by introducing someterminology, after which we review some issues re-garding timetables, safety technologies, dispatchingrules, typical objective functions, and a short litera-ture review to place our work in context.

2.1 Definition of terms used

Along the paper we will be using some technicalterms which will now be presented:

Single railway track - One where traffic in bothdirections shares the same track.

Track Segment - A track segment is a part ofa railway line that is bounded by two distinct endpoints, in this case the meetpoints.

Block - Section of the railway line delimited bysignals.

Siding - A section of track which can be used forthe crossing or passing of trains under single track op-erations. The terms “crossing loop” or “passing loop”are also used in some countries to describe such tracksections. A train station on a single line track willusually contain, at least, one siding.

Meetpoint - Location where two trains may crosssimultaneously. In this context, meetpoints includenot just stations, but also sidings.

Train Conflict - Basically there are two cases:when two trains approach each other on a single line

track travelling in opposite directions (Meet); andwhen a faster train catches a slower train travellingin the same direction (Pass).

Minimum Headway - The minimum time lengthseparating two trains on a single line track. This isusually determined by signals in the case when thetrains are travelling in the same direction. When trav-elling in opposite directions, the minimum headwayis determined by the time required for one train toclear the track segment sufficiently before the oppos-ing train can enter it.

2.2 Timetables

Train dispatchers have two main tools to supervise thenetwork, which are the timetable and the train dia-gram. The timetable is a schedule of trains on a givenrailway infrastructure. It contains the arrival and de-parture times of the trains, not only from stations butalso from intermediate stations and sidings. The traindiagram, or graphical timetable, is a representation ofthe timetable in a more intuitive way. It is basically atime distance graph where all the routes for travelingtrains are represented. The advantage of this diagramis the fact that conflict detection is relatively simplyto perform. The horizontal axis represents time ofday and the vertical axis the sequence of stations indistance scale. Lines indicate the movement of trains,with the slope indicating direction and speed, hori-zontal meaning stand-still. Usually, the outbound di-rection is defined upwards.

2.3 Safety technologies

There are two different systems to ensure the safetyof the railway networks: the fixed block technologyand the moving block technology. A block sectionis a track segment between two signals. The signalscontrol the train traffic and impose safe distance head-ways. There are signals along the lines and also be-fore every station, passing loops, junctions, etc. Themost common type of signalling is the three-aspectsignalling. A signal aspect may be red, yellow orgreen. If the subsequent block is occupied by an-other train, the signal is red. A yellow signal aspectmeans that the subsequent block section is empty, butthe following block is occupied by another train. Fi-nally, a green signal aspect indicates that the next twoblocks are empty. Trains have to stop when facing ared signal and wait for that signal to change to greenor yellow. When facing a yellow sign the train mayproceed its’ course but has to decelerate so that it canstop in case the next signal is red. Each block mayhost at most one train at a time. As for the mov-

ing block technology, it does not need signals sincethe exact position and speed of each train is known.Safety is ensured by the regulation of their respec-tive speeds. The safety standards define a maximumspeed for each train, depending on the distance fromthe preceding train, necessary to grant space to stopcompletely in case of emergency. With this technol-ogy, a track segment can host more than one train at atime.

2.4 Dispatching rules

Dispatching rules solve conflicts by means of a localdecision criterion. Two of the most common rules arethe first-in-first-out (FIFO) rule and the first-out-first-in (FOFI) rule. The FIFO rule solves conflict situa-tions by assigning the block section in discussion tothe first train that required it. This means that thisrule actually does not require any special dispatchingorder and lets the traffic proceed with its actual or-der. This rule is also known as first-come-first-served(FCFS). The FOFI rule assigns the block to the firsttrain that is able to leave it. For this evaluation, thetime that each train will take to enter the block andleave it available again has got to be calculated first.The precedence is then given to the train that is ableto leave the block first. The FOFI is also referred toas first-leave-first-served (FLFS).

2.5 Objective functions

To evaluate the quality of the obtained solutions, dis-patching models need to have an objective function.There are several objective functions each one withits advantages and disadvantages. The choice of whatfunction to use depends on the dispatcher or corpo-rate criteria. The following four optimization crite-ria, i.e., objective functions have been selected as themost common: Minimization of the total tardiness –D = ∑

ni=1 Ti; Minimization of the total weighted tar-

diness – WD = ∑ni=1 wiTi; Minimization of the maxi-

mum tardiness – Tmax =max{T1,T2, . . . ,Tn} – this cri-terion minimizes the maximum delay but many trainsmay suffer small delays, and is more suited when pas-senger trains prevail for scheduling; and Minimiza-tion of the maximum weighted tardiness – WTmax =max{w1T1,w1T2, . . . ,wnTn} –, this function is moresuited for mixed traffic situations where the weightswi are usually the same for trains with the same prior-ity.

2.6 Review

The majority of the models found in the literature fol-low the structure of a typical Decision Support Sys-tem, (DSS). These systems have three main functions:predicting train movements, detect possible conflicts,and propose solutions for the conflicts found. Severalapproaches have been proposed since the early seven-ties of the last century. However with the advances intechnology the most relevant progress has been madein the last two decades. An extensive survey of rel-evant railway traffic scheduling and rescheduling ap-proaches can be found in (Cordeau et al., 1988).

The work of (Sahin, 1999) uses a heuristic algo-rithm to reschedule trains. It compares the planned ar-rival times of trains with the current expected arrivaltimes for conflict detection. Then, it uses a discreteevent simulator to evaluate the alternative choices tosolve the first conflict found. The system proceedssolving a conflict at a time using this approach. In(Adenso-Dıaz et al., 1999) a mixed integer program-ming model is proposed and a branch-and-bound so-lution is used. To reduce the size of the search tree, afixed lenght horizon, in terms of number of services,is assumed.

Another simulation based approach is proposedin (Medanic and Dorfman, 2002), where each trainreaching a meetpoint will be compared with nearbytrains. If the train can reach the next meetpoint safely,the simulation proceeds. Otherwise, the procedurechoses a vicinity train to be stopped and proceeds.

In (D’Ariano et al., 2007a; D’Ariano et al., 2007b)the train rescheduling problem is formulated as a job-shop scheduling problem with blocking and no-waitconstraints, and uses the alternative graph of (Mas-cis et al., 2002; Mascis and Pacciarelli, 2002) as themodel structure. The conflicts are solved with dis-patching rules.

3 MODEL DESCRIPTION

Our model can be classified as a variable-speeddecision support system in real time. It is not sup-posed to replace the dispatcher but to help him/her intaking the best possible solutions. In other words, thismodel is a useful tool that allows train dispatchers toforesee the consequences of their decisions and alsoprovides them with other feasible and probably bettersolutions.

The system architecture is presented in Figure 1.It shows how the DSS will be incorporated in the dis-patching process and also illustrates the type of infor-mation that will be interchanged with the dispatcher.

Figure 1: Train dispatching system architecture.

Inside the DSS block are represented its two mainfunctions: the conflict detection and the conflict reso-lution blocks.

3.1 Problem Definition

Being railway scheduling such a rich and complexproblem, it is necessary to define all the model’s lim-itations, assumptions and inputs. This model consid-ers a single railway line that serves trains travellingin both directions. The railway is formed by tracksegments, which make the connection between all themeetpoints, as shown in Figure 2. In this context,meetpoints include not just stations, but also sidingsor any location where two trains may cross simulta-neously. So, for this model, trains are only able tomeet or pass at meetpoints. As it is represented inFigure 2, train directions will be defined as inboundfor trains going from right to left and outbound oth-erwise. Meetpoints and track segments are numberedin the outbound direction.

Figure 2: Model Railway Line Topology.

The safety technology considered is the fixedblock signalling system. Therefore, trains can followeach other on a track segment with minimum safetyheadway. Considering this, the model also assumesthat trains depart from stations as soon as possible, or

in other words, as soon as the following block clears.This policy concerning trains following each otherwill be very important in the resolution of the passconflicts that will be explained further ahead in Sec-tion 3.4.

Only three different types of trains are consideredin the rest of this paper but the model is valid indepen-dently of the number of train types. The consideredtrain types are: Fast Passenger Train; Slow PassengerTrain; and Freight Train.

This order of presentation is also the usual order ofpriorities between them. Fast Passenger Trains havepriority 1, which is the highest, and Slow PassengerTrains and Freight Trains have priorities 2 and 3, re-spectively. The first and last meet points, of the con-sidered railway network, do not have to be terminalstations. They can be the interface from single linesegments to double track segments or even a denserrail network, as it happens in most cases. Anyway, thesafety time intervals between arrivals and departuresin these stations will not be checked. In order to makethis model more realistic, all meet points have limitedcapacity. This is a very important aspect that makes abig difference in the quality of the final solution. Veryfew models take capacity into consideration. For sim-plicity, the rest of the paper does not explicitly con-sider acceleration and deceleration time losses. In ad-dition to these model definitions, the following modelassumptions are as follows. It is assumed that the lo-cation and speed of all the trains in the network isknown at all times. Minimum dwell times of the trainsat stations and their running times for each track seg-ment are needed in order to verify the constraints de-scribed in the following section. Train priorities haveto be given for each train. Maximum finite capacitiesfor all meet points are assumed.

In conclusion, a conflict is said to occur when twotrains meet or pass at a segment track, when they ar-rive and depart from stations without the minimumsafety intervals, and when a train arrives at a stationthat is full.

3.2 Mathematical formulation

The meet and pass problem, is essentially an op-timization problem, subject to several constraints.Therefore it can be described mathematically. Ac-cording to the definitions made in the previous sec-tion, the set of constraints is now presented in a for-mal manner. The selected optimization criterion wasthe minimization of the total weighted tardiness. Be-low we present the notation being used, after whichwe detail the mathematical formulation.i – Train index

u – Meetpoint indexk – Segment indexIo – Set of outbound trainsIi – Set of inbound trainsI – Set of trains, |I|= n, I = Ii∪ Io, Ii∩ Io = {�}Su – Number of trains at station u, S⊂ ICu – Maximum capacity of station uU – Set of meetpoints, |U |= mK – Set of segments, |K|= m−1rk

i – Running time for train i at segment kτk

i – Minimum allowed running time for train i atsegment ksu

i –Dwell timeωu

i – Minimum dwell timedu

i – Departure time of train i at station uau

i – Arrival time of train i at station uαm

i – Scheduled arrival time of train i at terminalstation msk

i – Start time of train i at segment kf ki – Finish time of train i at segment k

wi – Weighted priority of train ihk – Minimum headway between arrival and depar-ture times of two consecutive trains at segment kgu – Minimum headway between arrival and depar-ture times of two consecutive trains at station u

Objective function:

minZ =n

∑i=1

wi max{0,(ami −α

mi )} (1)

subject toFree running time constraints:

rki ≥ τ

ki ,∀i ∈ I,k = 1,2, . . . ,m−1 (2)

Consecutive departure and arrival constraints:

f ki ≥ sk

i + τki ,∀i ∈ I,k = 1,2, . . . ,m−1 (3)

Minimum dwell time constraints:

sui ≥ ω

ui ,∀i ∈ I,u = 1,2, . . . ,m (4)

Headway constraints on arrival times at stations:

aui ≥ au

i′ +gu⊕aui′ ≥ au

i +gu,

∀i, i′ ∈ I, i 6= i′,u ∈U (5)

Meet condition:

du+1i ≥ au+1

i′ +gu⊕dui′ ≥ au

i +gu,

∀u ∈U, i ∈ Ii, i′ ∈ Io (6)

Pass Condition:

(du

i ≤ dui′ +hk ∧au+1

i ≤ au+1i′ +hk

)⊕ (7)(

dui′ ≤ du

i +hk ∧au+1i′ ≤ au+1

i +hk),

∀u ∈U,{i, i′} ∈ Io

Meetpoint capacity limits:

Su ≤Cu,∀u ∈U (8)

In conclusion, if a schedule does not respect all ofthe above constraints, it means that a conflict will oc-cur and this schedule is considered unfeasible. How-ever, verifying the meet and pass constraints betweenall of the trains is unnecessary. In order to explain thisstatement, it is helpful to rewrite constraints (5) and(6) in relation to the segment instead of the stations.

Meet condition:

f ki < sk

i′ ⊕ f ki′ < sk

i ,∀k ∈ K,{i, i′} ∈ I (9)

Pass Condition:

(sk

i < ski′ ∧ f k

i < f ki′)⊕(sk

i > ski′ ∧ f k

i > f ki′),

∀k ∈ K,{i, i′} ∈ I (10)

The safety variables gu and hk are not consideredto simplify the analysis with no loss of generality.

Before the introduction of these main results, itis necessary to make the following assumptions: Thetrains are considered to be ordered by their entrancetimes (sk

i ) at a given segment k. This can be repre-sented by the following equation.

ski < sk

i+1 < ski+2 (11)

Condition (11) must always be verified for the fol-lowing results to hold. There is also one conditionwhich is always valid since trains cannot move instan-taneously, which is stated as follows.

ski < f k

i (12)

Theorem 1 If train i does not collide with train i+1,and train i+ 1 does not collide with train i+ 2, thentrain i cannot collide with train i+2.

Proof: See Appendix.Following the reasoning of the proof, one must

conclude that the non-conflict condition has the tran-sitivity property. Hence, it can be generalized for alltrains in the segment. If there are no conflicts betweenconsecutive train pairs then, one must conclude thatthere are no conflicts in the segment at all.

Theorem 2 If there is a conflict between train i andtrain p, with p ≥ i+ 2, then there is also a conflictbetween trains i and p− 1, or between trains p− 1and p.

Proof: See Appendix.Theorem 2 states that any conflict between two

trains, which are apart in terms of their entering order,implies a conflict between two consecutive trains, ora conflict between closer trains.

Corollary 1 In order to conclude about the existence,or non-existence of conflicts, in a given track seg-ment, it is only necessary to check for conflicts be-tween consecutive trains, in terms of their enteringorder.

Proof: See Appendix.The importance of these results is the complex-

ity reduction in the conflict detection problem, whichwas a combinatorial problem and now becomes a lin-ear one. More specifically, for a schedule with ntrains, instead of making all the (Cn

2) comparisons, itonly needs (n−1) comparisons. Furthermore, this al-gorithm is used recursively in the search for the opti-mal solution, which makes the reduction impact evenbigger.

3.3 Solving Conflicts

Now that all the constraints for the problem are prop-erly defined, the next step is to explain how to solvethe detected conflicts. Conflicts are grouped into fourdifferent types, as follows: Meet conflict; Pass con-flict; Safety intervals at the station; and Capacity con-flict.

For each type of conflict, the range of possible so-lutions is presented next.

3.3.1 Meet Conflict

This first type of conflict involves two trains and so,there are only two valid solutions to consider. Thesesolutions are either to stop the inbound train or theoutbound train. In Figure 3 is an example of a meetconflict (top plot), between trains i and j, followed byits two solutions on the bottom plots.

In Figure 3 we also represent the introduced de-lay and the safety time interval gu. The time intervalintroduced can be gu or hk, the chosen interval is theone which has the bigger value. This is also valid forthe pass conflict. In meet conflicts, delays are alwaysintroduced in the dwell times of trains at the stationsbut the same does not happen in the type of conflictexplained next.

Figure 3: Resolution of a Meet conflict.

3.3.2 Pass conflict

The pass conflict is not as simple as the first one be-cause, in this case, running times also have to be takeninto account. As it was referred earlier, it is assumedthat trains leave their stations as soon as possible, inorder to achieve the minimum possible delay. There-fore, if a faster train succeeds a slower one, its runningtime will have to be decelerated in order to avoid redsignals. The following Figure 4 illustrates the Passconflict (top) between fast train j and slow train i andtheir alternative solutions (bottom).

Figure 4: Resolution of a Pass conflict.

In Figure 4 the bottom left plot is a good exampleof an affected running time. Train j had to be sloweddown so as to arrive at station 2 without having to stopin the middle of the segment track, and wait for traini to clear the following block.

3.3.3 Safety intervals at stations

As for the arrivals and departures at stations there arethree different situations of conflict: two arrivals, twodepartures, one arrival and one departure. Becausethey are very similar situations, only the case with onearrival and one departure will be shown in Figure 5.

Figure 5: Resolution of a Safety conflict.

3.3.4 Capacity conflict

The Capacity conflict is by far the most complex ofthem all. The train chosen to wait for the full stationto be available again, is not necessarily the last onein the schedule to arrive. In fact, all of the trains atthe station, when the conflict is detected, are candi-dates to be re-scheduled. Hence, one can say that aconflict in a station with capacity N, will have N + 1possible solutions. The policy in this situation is tohold one of the trains at the previous station until thefirst train at the full station departs. To help under-stand this resolution better, the following example inFigure ?? shows a capacity conflict in station 2 withcapacity for two trains.

Figure 6: Resolution of a Capacity conflict.

3.4 Towards a feasible solution

Now that the resolutions for each conflict type are de-fined, it is necessary to select them properly in orderto generate the best possible solutions. The objectiveof this work is to provide the dispatcher with feasiblesolutions, in a short amount of time, but also try to ob-tain the optimal solution if possible. Therefore, two

approaches were developed in order to satisfy theserequirements: the heuristic approach and the searchbased approach. An explanation of each one of theapproaches will be presented next.

3.4.1 Heuristic approach

Taking into account that this program will work inreal-time, there is the need to generate solutions asfast as possible to help the dispatcher. Therefore, theobjective of this algorithm is to find a feasible solutionfor the conflict in a short amount of time, and also toreproduce the dispatchers’ behaviour in the resolutionprocess. It can be useful to imitate train dispatchersso as to compare the quality of their solutions withthe optimal ones. The proposed decision criterion isbased mainly on train priorities and in the FOFI rule.For every conflict that involves only two trains, whichmeans all conflict types except for the capacity con-flict, the decision criterion works as follows. If onetrain has higher priority than the other, that’s the trainthat will always go first. If both trains have the samepriority, then the FOFI rule is applied. This rule willcheck which one of the trains is able to solve the con-flict in a faster way. In other words, this rule veri-fies which decision generates de smallest delay on thestopped train.

As for the capacity conflicts, there are N+1 trainsto consider and the procedure is as follows. Betweenall the trains involved in the conflict, choose the trainwith lowest priority in order to be delayed. In casethere is more than one train with low priority, choosethe last one to arrive at the station.

3.4.2 Search based approach

This approach was developed to provide the dispatch-ers with optimal or near optimal solutions, better thanthe ones they usually take. To do so, a search treeis considered. The nodes of the search tree are theconflicts and the branches are the respective solu-tions. This means that the path from the first node toany leaf node represents a feasible solution of the re-scheduling problem. Because the time available is akey element, the search mode adopted was the depthfirst search (DFS). The DFS allows reaching a firstfeasible solution without having to search the entiretree as it would happen in a breath first search.

This problem is NP-complete. Therefore, there isa need to adopt some strategies to ensure a solution isproduced. The DFS has a branch-and-bound mecha-nism and each search is limited in computational timeand time horizon for the schedule. That is, there is anupper bound on computational time, after which thesystem is supposed to return the best solution found

so far. To ensure a larger set of options searched, theobjective is to produce a conflict free schedule fromthe present time, t, up to some upper bound in time,say t+T . Therefore, the best solution returned is con-flict free for T units of time. This enables the systemto be re-started to search for more solutions in a com-putational time of order T .

4 IMPLEMENTATION

In our implementation, there are two distinct parts:the Conflict Detection Loop and the Conflict Resolu-tion part. These parts are indicated below in Figure 7within the dashed rectangles.

Figure 7: Structure of the software package.

The Conflict Detection Loop is responsible forthe surveillance of the railway network. It is alsoin charge of updating all the necessary data, so thatthe conflict detector can work with valid information.This loop is supposed to keep running until a con-flict is detected. The Conflict Resolution is evidentlythe part responsible for solving the detected conflicts.This part is divided into two main blocks which arethe heuristic solution and the search based solution.These two algorithms that were already introduced inSection 3 will be explained in detail further on. TheConflict Resolution part is also in charge of reportingthe achieved solutions to the dispatcher.

4.1 Conflict Detection

The detection of conflicts is executed by the inspec-tion of the network timetable. Two scans at thetimetable are performed, the first one tests out formeet and pass conflicts, as for the second scan, itchecks for the safety intervals at stations and for ca-pacity conflicts. Here in Table 1 is an example of atimetable with all the arrival and departure times ofall the trains from every meetpoint in the railway. Thedouble line between Train 3 and Train 4 is separatingthe outbound trains (Train 1 to Train 3) from the in-bound trains (Train 4 to Train 6). As explained ear-lier, the meetpoints and segment tracks are numberedin the outbound direction. The times presented in thetable are in minutes.

Table 1: Example of a Timetable

The first scan sorts the train order for each tracksegment and then for each pair of trains it verifiesthe meet and pass constraints. In other words, the al-gorithm compares the safety constraints between twoconsecutive trains entering a given track segment.

Considering the example of Table 1, the order oftrains entering track segment 2 corresponds to the sortof the highlighted values within the red circles. In thiscase it would be as indicated in Table 2.

Table 2: Entrance order in track segment #2.

Track Segment #2Entering times Order

Train 1 54 2Train 2 50 1Train 3 62 3Train 4 136 6Train 5 66 4Train 6 105 5

The scan would begin by checking between Train

2 vs. Train 1, then Train 1 vs. Train 3 and so on, untilthe last pair is analized, Train 6 vs. Train 4. This typeof approach allows saving precious time checking formeet and pass constraints between all the trains in thetimetable, and so reducing the complexity of the al-gorithm. When a conflict is found, the scan does notstop because it might not be the earliest one to occur.It is intended in this program to solve conflicts by theorder they occur. Although this may be not very ac-curate, the time of conflict is assumed as the instantwhen the first involved train leaves the meetpoint be-fore the conflict. It is logical to think this way con-sidering that this is the deadline to take a dispatchingmeasure. After that instant, the options considered forconflict resolution are not feasible any more.

Table 3: Sorting Meetpoint #1.

Meetpoint #1Arrival Order Departure Order

Train 1 1 1Train 2 3 2Train 3 2 3Train 4 6 4Train 5 4 6Train 6 5 5

The second scan is very similar to the first one ex-cept that in this case, it is not about entering times insegment tracks, but entering and leaving times frommeetpoints. The algorithm sorts out the arrival anddeparture times for one station and compares all theconsecutive times checking if the safety time inter-vals are respected. Simultaneously, a train count forthat same station is performed in order to detect ca-pacity conflicts. The blue shaded columns in Ta-blereftimetable will be the example for this scan.

4.2 Heuristic Solution

This algorithm is intended to be fast and effective asexplained in Section 3. Therefore, the detected con-flict is evaluated concerning only train priorities andthe FOFI rule which is a sub-optimal and myopicrule. A flowchart explaining the solution procedureis presented below in Figure 8. If all of the involvedtrains have the same priority, the program performsthe FOFI rule to see which option can cause de small-est delay.

Having decided which train to delay, its scheduleis re-arranged accordingly and always respecting fu-ture dwelling times. Next, it is necessary to check formore conflicts in the schedule. If another conflict isdetected, the process is repeated again from the be-

Figure 8: Flowchart of the heuristic algorithm.

ginning. This cycle continues indeterminately untilthe schedule becomes free of conflicts, which meansa solution was found.

4.3 Search based solution

The search algorithm was developed with the objec-tive of reaching an optimal solution. To do so, itshould supposedly verify all the possible solutionsand then choose the best one among them. Due to theenormous size that the search tree may reach in densetraffic railways, it is unnecessary and also impossibleto store the entire tree in the computer memory andto search it in feasible time. The Depth First Searchwas then chosen because it does not require a lot ofmemory, and because it provides solutions faster evenif they are not optimal. Because time is a key factor inthis search, there is the need to adopt some techniquesto reduce the size of the search tree. One of them isthe introduction of an Upper Bound search limit. TheUpper Bound stops the depth search, whenever theconsidered solution is worse than the best one founduntil that moment. The quality of each solution is cal-culated by the cost function presented in Section 3.Another technique used to reduce the search tree is thetime horizon. The conflict detector only reports con-flicts earlier than the time horizon, ignoring all the fol-lowing future conflicts. This horizon enables the al-gorithm to prune a big part of the search tree and con-sequently saving precious time. Even with these fea-tures, there are still schedules that require too muchtime to be optimally solved. Hence, the dispatcherhas another possibility which is the Maximum searchtime. If this time is exceeded, the algorithm will stop

the search and report the best solution found until thatmoment. In Figure 9 we present the flowchart of thisalgorithm.

Figure 9: Flowchart of the search algorithm.

5 PERFORMANCE EVALUATION

The development of any application of this kind is notfinished without a serious and meaningful evaluationof its performance. Therefore, this chapter aims topresent and analyze the results of the tests carried outto check this model’s efficiency. More specifically,the main objective of these tests is to understand howthe program is influenced by its input parameters. Theparameters in study are: Initial schedule; Time hori-zon; Number of Solutions; Cost function; Maximumsearch time; and Upper Bound.

Next, each one of these features will then be an-alyzed individually. The package was implementedin Matlab R2007b on the Windows XP operating sys-tem, and all the experiments were conducted on a lap-top with an Intel Pentium M 1.20 GHz processor and1.23 GB of RAM. There are five schedules, each onewith different number of trains and meetpoints in or-der to evaluate the behavior of the algorithms in dif-ferent complexity environments.

5.1 Initial Schedule

In this first test, it is intended to demonstrate howthe increase in the complexity of the input scheduleaffects the search for a solution. As for the other

features, their input was as follows: the time hori-zon considered for all these experiments was one day(24h); the maximum search time was established atthirty minutes (1800 s); Also the number of requestedsolutions was one (1); finally, the cost function usedwas the total weighted tardiness whose weights arethe following: Priority 1 = 0.75; Priority 2 = 0.20;and Priority 3 = 0.05.

In Table 4 the simulation results are presented. Inthe first column is the identification number of theinput schedules which are ordered by their complex-ity. The number of initial conflicts indicates how dis-turbed the initial schedule is at the beginning of thesimulation. In the last two schedules, 4 and 5, theoptimal solution is not found before the maximumsearch time meaning the solutions presented are notoptimal but the best ones found in 1800 seconds. Thelimits columns present values of the number of timesthat each limit was used to stop the search.

Table 4: Results for different initial schedules (* Optimalsolution not found).

Through the analysis of Table 4, the first and mostimportant conclusion is that the more complex anddisturbed the schedule is, the longer it takes for theprogram to find the optimal solution. Quite surpris-ingly, the algorithm that finds the heuristic solution isbarely affected by this complexity increase. Anothergood result is the quality of the proposed heuristic so-lution that revealed a near optimal solution in mostcases. In Schedule 5, the quality of the heuristic so-lution could even overcome the thirty minute searchof the optimal algorithm. This aspect will be ana-lyzed later on this section. As for Schedule 2, thisis a case where the optimal solution, with half thecost of the heuristic solution, is found in just four sec-onds. This variety from schedule to schedule rein-forces the fact that independently of their complexity,schedules may change a lot from one another mak-ing greedy algorithms less reliable. As for the limitsused in the search for the optimal solution, the up-per bound limit revealed more effective than the timehorizon limit. Nonetheless, the time horizon was atits maximum value and for shorter time horizons it is

obviously more useful.

5.2 Time Horizon

With this second test, it is expected to show if thevariation in the time horizon can accelerate the searchfor the optimal solution. Once again, it is importantto clarify that the indicated solutions are optimal butonly within the time horizon limit. They are not theoptimal solutions for the whole schedule. For thissecond set of simulations, the maximum search time,number of solutions and cost function are the same ofthe previous tests.

Table 5: Variations in the time horizon (* Optimal solutionnot found).

By the inspection of Table 5, one can concludethat the decrease in the time horizon reduces drasti-cally the search time need to obtain an optimal so-lution. This result is of course expected since that ashort time horizon will ignore the majority of the fu-ture conflicts and so reducing the search space. ForSchedules 3 and 4, with a time horizon of ten hours,which is more than acceptable, the algorithm is ableto solve the conflicts optimally in less than thirty sec-onds. As for Schedule 5, the densest schedule, theheuristic algorithm completely outperforms the op-timal one for long time horizons. Once more, thisheuristic values lower than the optimal ones will beexplained later in this section.

5.3 Number of Solutions

This test aims to check if the increase in the number ofrequested solutions has a big influence on the programperformance.

This hypothesis comes from the fact that, thehigher the number of requested solutions is, the higherthe upper bound will be, and thus, less restrictive.Once again the input parameters remain the same ex-cept for the time horizon that will be reduced to tenhours. The tests reveal that the number of solutions

Table 6: Variations in the number of solutions.

is not relevant in the behavior of the program. Differ-ences like six seconds are not significant when talk-ing about train dispatching. Besides, there is proba-bly more interest in having a set of feasible solutionsavailable so that the dispatcher can have more choiceoptions.

5.4 Cost Function

The purpose of this test is to show how the heuris-tic solution may have different quality performanceswith different cost functions. To do so, four differentsets of weights were considered

Table 7: Sets of weights for the weighted tardiness function.

Priority 1 Priority 2 Priority 3Set 1 0.7 0.2 0.1Set 2 0.6 0.3 0.1Set 3 0.5 0.4 0.1Set 4 0.5 0.3 0.2

In order to be more realistic, there were two con-ditions that the above sets had to verify: 1) Priority1> Priority2 > Priority3; 2) Priority1 + Priority2 +Priority3 = 1;

The case where all the weights are the same isalso considered with the total tardiness cost function.The time horizon is set to 10 hours and the maximumsearch time was set to 300 seconds. Bellow in Ta-blerefresults4 are the results of this experiment. An-alyzing the results, it may be concluded, as expected,that the gap between the heuristic solution and theproposed optimal solution increases when the weightsare more evenly distributed.

The heuristic algorithms performs as if all theweight is in the train with higher priority and hencethese results. It is now up to the dispatcher to ana-lyze the different produced solutions and work withdifferent cost functions in order to decide which setof weights fits better to reality.

Table 8: Variations in the cost function.

5.5 Maximum Search Time

The interest in studying the maximum search time ismainly to observe how fast does the algorithm con-verge into an optimal solution. The input parametersare the same as in the first test. To better illustratehow this algorithm behaves in time, the graphic inFigure 10 was made. The solutions quality, or cost,is not presented in its absolute value but instead it isnormalized to make their comparison easier. Consid-ering Ropt the quality of the optimal solution and Rithe quality of the current solution, then the normal-ized quality R is defined as being Ri/Ropt. In Sched-ules 4 and 5, the optimal solution considered was theone obtained at 1800 s. In Table 9 are indicated theabsolute cost values obtained in this experiment.

Table 9: Variations in the maximum search time (*OptimalSolution found in 944s).

As it was concluded in the first test, the more com-plex the schedule is, the longer it takes for the pro-gram to obtain the optimal solution. This conclusionis once more evidenced in this graphic where the linesare logarithmic tendency lines. These tendency linesare slightly overestimated because in the normaliza-tion, the best solutions found at 1800 seconds, wereconsidered as being the optimal ones.

5.6 Upper Bound

With this set of tests, it is intended to study the effectof the initial upper bound value, in the performance of

Figure 10: Search algorithm performance.

the optimal algorithm. By default, the optimal algo-rithm does not take into consideration the cost valueof the heuristic solution. The initial value of the up-per bound is set to infinite. This decision was made sothat the program could also consider solutions worsethan the heuristic solution and let the dispatcher ana-lyze them in the end. The set back of this option isthat, by giving a high initial upper bound, the algo-rithm’s performance is affected and so, it might notbe as effective as it could. Again, the input parame-ters are the same as in the first test.

Table 10: Variations in the value of the initial upper bound.

To better illustrate the difference between the twosituations, the graphics below were created. Like inthe previous section, these values are normalized tothe optimal solution or in the case of Schedule 4 tothe best solution found in 1800s.

6 CONCLUSIONS

In Section 3, we established a procedure to reduce thecomplexity of the conflict detection. Also, the capac-ity conflicts are the most complex to solve, but withthe advantage of giving more realism to the model. Fi-nally, two resolution methods for re-scheduling were

proposed. One is the heuristic solution based on asimple dispatch mechanism, which is a greedy algo-rithm that provides a solution for the problem in ashort amount of time by means of a local decisioncriterion. The second method is a search based mech-anism, an algorithm that checks for all the possibil-ities, by using a search tree and a branch-and-boundtechnique. In order to make the optimal search lessexhaustive and more useful in real-time, the time-horizon and the maximum search time were adopted.With a proper management of these search parame-ters, the dispatcher may solve a conflict in a shortamount of time, pushing the conflicts further on, andgaining precious time for another search, looking forbetter results. The heuristic algorithm performed fastin all situations, independently of the complexity ofthe initial schedule. The quality of its solutions wasmainly near optimal but, as expected for a greedy al-gorithm, there were cases were the proposed solutionwas far from optimal. The search based algorithmdepends very much on the complexity of the initialschedule. Nonetheless, the time horizon parameter re-vealed very effective, with the tradeoff of shorteningthe validity of the solution. The number of requestedsolutions has almost no effect on the performance andprovides the dispatcher with a set of useful differentsolutions.

A PROOFS

In both proofs of the theorems, train i is always con-sidered an outbound train. The case when i is inbound, isanalogous with the outbound situation, and so it will not bediscussed, given the fact that the proof is not conditioned bythe direction.Proof of Theorem 1:

Case 1) i+ 1 is an outbound train. If train i does notcollide with train i+1, then:

f ki < f k

i+1 (13)

If train i+1 does not collide with train i+2, then therecan be two cases:

Case 1.1) i+ 2 is an outbound train. If train i+ 1 doesnot collide with train i+2, then:

f ki+1 < f k

i+2 (14)

And so, from (13) and (14) we get

f ki < f k

i+2 (15)

From conditions (11) and (15), it can be concluded that,in this case, train i does not collide with train i+2.

Case 1.2) i+2 is an inbound train. If train i+1 does notcollide with train i+2, then:

f ki+1 < sk

i+2 (16)

And so, from (13) and (16) we get

f ki < sk

i+2 (17)

From conditions (11) and (17), it can be concluded that,in this case, train i does not collide with train i+2.

Case 2) i+1 is an inbound train. So, if train i does notcollide with train i+1, then

f ki < sk

i+1 (18)

If train i+1 does not collide with train i+2, then therecan be two cases

Case 2.1) i+ 2 is an outbound train. If train i+ 1 doesnot collide with train i+2, then

f ki+1 < sk

i+2 (19)

And so, from conditions (18) and (19) we get

f ki < sk

i+1 < f ki+1 < sk

i+2⇐⇒ f ki < sk

i+2 (20)

With conditions (11) and (20), it can be concluded that,in this case, train i does not collide with train i+2.

Case 2.2) i+2 is an inbound train. If train i+1 does notcollide with train i+2, then

f ki+1 < f k

i+2 (21)

And so, from equations (18) and (21) we get

f ki < f k

i+2 (22)

From conditions (11) and (22), it can be concluded that,in this case, train i does not collide with train i+2.

utProof of Theorem 2:

Case 1) p is an outbound train. If there is a conflict, then

f ki > f k

p (23)

Case 1.1) p−1 is an outbound train. For train p−1 notto collide with train i, it must be the case that

f ki < f k

p−1 (24)

For train p−1 not to collide with train p, it must be thecase that

f kp−1 < f k

p (25)

Which means that{f ki < f k

p−1 < f kp

f ki > f k

p⇐⇒ Impossible (26)

Thus in this case, train p− 1 will either collide withtrain i or train p.

Case 1.2) p−1 is an inbound train. For train p−1 notto collide with train i, it must be the case that

skp−1 > f k

i ⇐⇒ f kp−1 > sk

p−1 > f ki

⇐⇒ f kp−1 > f k

i (27)

For train p−1 not to collide with train p, it must be thecase that

f kp−1 < sk

p ⇐⇒ f kp−1 < sk

p < f kp

⇐⇒ f kp−1 < f k

p (28)

Combining conditions (23), (27) and (28), we getf ki > f k

pf kp−1 > f k

if kp−1 < f k

p

⇐⇒ Impossible (29)

Thus in this case, train p− 1 will either collide withtrain i or train p.

Case 2) p is an inbound train. If there is a conflict, then

f ki > sk

p (30)

Case 2.1) p−1 is an outbound train. For train p−1 notto collide with train i, it must be the case that

f kp−1 > f k

i (31)

For train p−1 not to collide with train p, the followinghas to hold

f kp−1 < sk

p (32)

These two conditions together with condition (30) yieldf ki > sk

pf ki < f k

p−1f kp−1 < sk

p

⇐⇒ Impossible (33)

Thus in this case, train p− 1 will either collide withtrain i or train p.

Case 2.2) p−1 is an inbound train. For train p−1 notto collide with train i, it must be the case that

skp−1 > f k

i (34)

This with condition (30) yields

skp−1 > f k

i > skp⇐⇒ sk

p−1 > skp (35)

This equation is impossible because it violates the initialassumption referred in (10). Hence, in this case, train p−1will either collide with train i or train p.

The result follows.ut

Proof of Corollary 1:From Theorem 1 we say that if there are no conflicts be-

tween consecutive trains on a given track segment, then nec-essarily there are no conflicts between any of those trains.Therefore this condition assures the non-existence of con-flicts. From Theorem 2, we say that any conflict betweennon-consecutive trains, means that there is also a conflictbetween consecutive trains. Hence, this conclusion guaran-tees that all the existing conflicts will be detected.

ut

REFERENCES

B. Adenso-Dıaz and M. O. Gonzalez and P. Gonzalez-Torre,“On-line timetable rescheduling in regional train ser-vices,” Transp. Res. – Part B, Vol. 33, No. 6, pp. 387-398, 1999.

J. F. Cordeau and P. Toth and D. Vigo, “A survey of op-timization models for train routing and scheduling,”Transp. Sci., Vol 32, No. 4, pp. 380-404, 1988.

A. D’Ariano and M. Pranzo and I. A. Hansen, “Conflict res-olution and train speed coordination for solving real-time timetable perturbations,” IEEE Trans. IntelligentTransportation Systems, Vol. 8, No. 2, 2007.

A. D’Ariano and D. Pacciarelli and M. Pranzo, “A branchand count algorithm for scheduling trains in a railwaynetwork,” European Journal of Operational Research,Vol. 183, pp. 643-657, 2007.

A. Mascis and D. Pacciarelli and M. Pranzo, “Models andalgorithms for traffic management of rail networks,”RT-DIA-74-2002.

A. Mascis and D. Pacciarelli, “Job-shop scheduling withblocking and no-wait constraints,” European J. of Op-erational Research, Vol. 143, pp. 498-517, 2002.

J. Medanic and M. J. Dorfman, “Efficient scheduling of traf-fic on a railway line,” Journal of Optimization Theoryand Applications, Vol. 115, No. 3, pp. 587-602, 2002.

I. Sahin, “Railway traffic control and train scheduling baedon inter-rail conflict management,” Transp. Res. – PartB, Vol. 33, No. 7, pp. 511-534, 1999.