MISTA 2009
Case studies of successful train crew scheduling optimization
Raymond S K Kwan
Abstract UK has a large and complex passenger rail network divided into a number of franchises. Crew scheduling, one of the last stages of operations planning before services go live, is mission critical to the train operating companies, which would feel the pain of manual scheduling. As far as the author is aware, attempts by these companies to adopt an automatic optimizing train crew scheduling system were unsuccessful except with TrainTRACS. After the first adoption of TrainTRACS by ScotRail in 2003, the author has founded the University of Leeds spin-out company Tracsis to commercialise TrainTRACS fully and to expand to other operations planning functions. Since then, TrainTRACS has gained wide acceptance by the UK rail industry. This paper discusses the major factors behind the achievements of TrainTRACS drawing from practical experience of development and interaction with the industry over many years. A couple of selected case studies will be presented in the discussion.
1. Introduction
In UK resource scheduling in advance of a new set of train timetables, usually for the next six months, is called ‘long term planning’ (LTP). In contrast, ‘short term planning’ (STP) deals with temporary network disruptions such as those caused by engineering work and timetable changes for public events such as football matches. This paper concerns mainly LTP train crew scheduling.
LTP train crew scheduling produces crew shifts on a daily basis. Across the week, individual crew members would need rest days and may have to attend training events. Furthermore provisions for sickness, annual leaves and spare coverage all add to the total work force. Therefore the actual number of crew members employed is a multiple of the maximum number of shifts on any day of the week. For example, for train drivers this multiplier is about 2.0. Total train crew cost also has to account for several categories of crews such as guards, conductors, and catering staff. Rail transport incurs substantial operating costs in network infrastructure, rolling stocks, energy and train crews. In UK, train crews account for about 20 – 25% of the total operating cost. A small percentage reduction of LTP daily shifts would translate into multi-million Pounds annual savings.
Train operators would also be motivated to seek the most efficient crew schedules so as to afford ploughing back some slacks into the schedules for robustness against crews being caught up by delays. Moreover, competitive tendering of the operating franchises in the privatised UK rail industry has forced the train companies to be ever more conscious of optimizing their operations – even before a franchise has been won.
Under this backdrop of motivation to optimize, train companies are under immense pressure to automate train crew scheduling. It is one of the last stages of resource planning after timetables planning and rolling stock scheduling. As it cannot start until the preceding processes have been completed and the timetables and rolling stock schedules have been frozen, planners are usually pressurized by very tight deadlines for the production of crew schedules before the operation goes live. Automation would speed up schedule production freeing up valuable time for the planners to think strategically and to explore a fuller range of what-ifs.
For the above reasons, train operating companies (TOC) would very much want to use automatic optimizing train crew scheduling systems. Indeed, there has been major piloting use of such software systems in
the last two decades by UK train operating companies. As far as the author is aware, all except TrainTRACS have been abandoned after a short time. ScotRail was the first TOC to use TrainTRACS in house in 2003 and they have continually been an active user to date. Currently, the following TOCs are also licensed to use TrainTRACS in-house: Northern Rail, Arriva Trains Wales, Southern Railway, National Express East Coast, Virgin West Coast, Arriva CrossCountry, London & South Eastern Railway, London Midland, and London Overground.
Apart from in-house use, franchise bidding teams and consultants have also been using TrainTRACS in the last few years in UK, Australia, and Northern Europe. Increasingly, franchise bidders are looking for hard evidence that if they won, they will be able to operate as planned. TrainTRACS as a production tool is therefore used instead of simple estimation methods.
Section 2 first introduces the train crew scheduling problem and TrainTRACS. One of the key research issues in designing automatic optimization systems is the goal of closing the gap between theory and practice (Burke et al 2001). TrainTRACS evidently has been bringing automatic train crew scheduling across to the practitioners and gaining wide acceptance in the UK. This paper examines some of the factors behind its achievements in section 3, some specific cases drawn from experience with the TOCs will be presented for illustration. Finally, conclusions and remarks are given in section 4.
2. LTP train crew scheduling
Bus and train crew scheduling are a well-known class of NP-hard problems, a general discussion is given by (Kwan 2004). Although the airline crew scheduling problem may be formulated similarly at the high level (Barnhart et al. 1998; Hoffman and Padberg 1993), it is usually considered distinct from those for bus and train because of the many airline specific operational practices. Bus crew scheduling problems (Wren 1981; Wren and Rousseau 1995), which have attracted early research focus, are generally not as difficult as those for train in terms of problem size and complexity. It was only from the 1990’s that there has been gradually more research on train crew scheduling (Capara et al. 1997; Kroon and Fischetti 2001; Abbink et al 2005; Kwan and Kwan 2007, Huisman 2007).
Train crew scheduling is basically partitioning of the schedule of each train into segments, which are permuted and recombined with breaks and other crew activities inserted to form crew shifts. Fig.1 shows an example of part of a train schedule being covered by 2 crew shifts. It is obvious that numerous candidate shifts are possible.
Train 1
Train 2
Train 3
Shift 1 sign on
Shift 1 sign off
Shift 2 sign on
Shift 2 sign off
1230 Leeds
Time Location (A relief opportunity)
Fig.1 Train work and crew shifts
In Fig.2, the optimization problem can be formulated mathematically as an integer linear programme (ILP) based on set covering (Smith and Wren 1988).
Minimise
∑
∑
= =+
n j j n j j jx
W
x
c
W
1 2 1 1 Subject tom
i
x
a
j n j ij1
1
,
2
,...,
1=
≥
∑
=n
j
or
x
j=
0
1
=
1
,
2
,...,
wheren is the number of candidate shifts m is the number of work pieces
j
x
is a shift variable,
=
otherwise
selected
is
shift
if
0
1
j
x
j jc
is the cost of shift j
=
otherwise
shift
by
covered
is
piece
work
if
0
1
i
j
a
ijW1and W2 are weight constants
Fig.2 Set covering ILP for train crew scheduling
In this section, the problem is further illustrated through a discussion of the input and output of a solution process in practice.
Train units are basic units of rolling stock that would not be broken down into any smaller sub-units during the operational day, even though a train unit may consist of multiple (e.g. 2, 4, 8, etc.) carriages. However, it is common for train units to be coupled together for parts or all of their journeys. Train units are usually scheduled before crew schedules are compiled to cover them. The schedule of a train unit is known as a ‘unit diagram’, an example of which is shown in Fig.3.
In Fig.3, the main body of a train unit diagram describes timetabled journeys that the unit serves, e.g. from Ebne at 14.55 to Vic at 16.31, via E Croy, is identified by the train ID (also known as a ‘headcode’) 1F37. The header of the unit diagram indicates that it is operated on a Sunday (“Su”). The other important information in a unit diagram concerns coupling (indicated by “ATTACH” or “ATTTT”) and decoupling (indicated by “DETACH” or “DETTT”), e.g. another unit numbered 117 is coupled with it at Ebne and departs at 09.55, which is later decoupled after arriving at Ebne again at 13.19. In scheduling train drivers, when multiple units are coupled, it is obvious that the crew scheduling system should only use one driver for the whole coupled train formation. For other crew types, e.g. Train Manager, when units are coupled, each unit might require its own crew because it might not be possible for the crew to get through the coupled units.
Whilst wheel turning work forms the bulk of a crew schedule, some non-wheel-turning work not shown in a unit diagram may also have to be done by a train crew. Such work has a significant impact on scheduling because often it could not be pre-determined, but is inserted as required dictated by the scheduling rules. For example, when a train unit is stationary at a platform, its engine may be left running if the driver remains onboard. However, the schedule may allow the driver to be relieved by a new driver. In that case, the relieved driver has to immobilize the engine before leaving, and the new driver may arrive some time after the other driver has left, and then he has to mobilize the engine again. Both immobilization and mobilization tasks have to
be given extra time allowances to the driver on top of the train arrival and departure times. Other types of idle time allowance may also have to be inserted dynamically to build robustness into the crew schedule. For example, if a train crew has to travel as a passenger, he would have to be scheduled to wait for the departing train rather than to be absolutely just-in-time.
Given a set of train unit diagrams, a solution crew schedule consists of a set of legal shifts that together provides the particular type of crew resource required for its complete operation. The construction of a shift must conform to the union agreements, which describe generally the working conditions of the crew. Within a
DIAGRAM: BB238 Su Fleet 377/1-12
Start Date: 01/12/2012 End Date : 31/05/2013 Bton LWS 06+37 5F40 116(1)\117(2)\238(3) Brighton 06+52 DETACH Brighton 07+02 5F40 Lewes 07+14 07.18 2F40 Brighton 07.34 07.43 2D11 Ore 09.00 09+02 5D11 Ore Up Sd 09+04 09+10 5F27 Ore 09+12 09.14 1F27 Ebne 09.48 ATTTT Ebne 09.55 1F27 238(1)\117(2) E Croy 11.09 11.10 1F27 238(1)\117(2) Vic 11.31 11.47 1F18 117(1)\238(2) Hay Hth 12.40 12.41 1F18 117(1)\238(2) Ebne 13.19 DETTT Ebne 13.26 1F18 Ore 14.00 14+02 5F18 Ore Up Sd 14+04 14+10 5F37 Ore 14+12 14.14 1F37 Ebne 14.48 ATTTT Ebne 14.55 1F37 238(1)\117(2) E Croy 16.09 16.10 1F37 238(1)\117(2) Vic 16.31 16.47 1F28 117(1)\238(2) Hay Hth 17.40 17.41 1F28 117(1)\238(2) Ebne 18.19 18.26 1F28 238(1)\117(2) Ore 19.00 19+02 5F28 238(1)\117(2) Ore Up Sd 19+04 19+10 5F51 117(1)\238(2) Ore 19+12 19.14 1F51 117(1)\238(2) Ebne 19.48 19.55 1F51 238(1)\117(2) E Croy 21.09 21.10 1F51 238(1)\117(2) Vic 21.31 21.47 1F48 117(1)\238(2) Hay Hth 22.40 22.41 1F48 117(1)\238(2) Ebne 23.19 23.26 1F48 238(1)\117(2) Hastings 23.59 00+08 5F48 117(1)\238(2) Ebne 00+30 CET WASH Ebne 01+10 5F48 238(1)\117(2) Ebne 02+18 STABLD
Fig.3 An example train unit diagram
Although there are different types of train crew together in a team on the day of operation, team work constraints do not have to be considered in LTP and each type has differing labour rule parameter values. For example, both drivers and catering staff are subject to a maximum time between signing on and signing off (called ‘spreadover’), but whereas the maximum spreadover for a driver may be 9:30, that for a catering staff may be 12:30. Hence, each type of train crew is scheduled separately. Where more than one members are required onboard for a type of crew, they would be scheduled as a single unit (i.e. each notional shift is applicable to however many crew members of the same type are required).
A train crew shift is more commonly called either a ‘turn’ or a ‘crew diagram’ in the railway industry. An example of a train crew diagram is shown in Fig.4.
shift, a crew is usually given a mealbreak (known as a ‘Physical Needs Break’ (PNB) in UK railway terms). Often, a shift can contain up to three mealbreaks which must start and end within specific hours, relative to the signing on time, as laid down in the union agreements. A main mealbreak is the one which divides the shift into two parts in similar proportion. A stretch is the period from the start of a shift to the start of the main mealbreak, or from the end of the main mealbreak to the end of the shift. A shift often contains two or more spells of work. A spell is a period of time a crew works continuously on a train. The time required for the crew to travel as passenger is usually excluded from a spell. In Fig.4, the main mealbreak is the period from 15:58 to 16:37 at Edinburgh where the driver is given enough walking time allowance between the platform and the canteen plus at least 15 minutes eating time. The shift has three mealbreaks, two stretches and four spells.
Not all the places where a train stops in train unit diagrams are feasible places for crew relief. A place where the train crew can be relieved is known as a ‘relief point’. In Fig.4, Edinburgh is a relief point but Dunblane and North Berwick are not. The times when a train unit passes these points are called ‘relief times’; a relief time at a particular relief point constitutes a ‘relief opportunity’. Many relief opportunities are not used and may not be shown in the crew diagrams. For example, train CK207 in Fig.4 passes through Stirling at 19:37 and 20:26, and relief opportunities exist then. The shift shown does not use these opportunities, but they might be used in other possible solutions. When a relief opportunity is chosen for crew relief, the crew onboard will leave the train (then takes a mealbreak, finishes the shift or join another train), and another crew (which may have just started its shift or have finished a break) would take over the operation of the train. Usually, when a train arrives at a point, there is a time gap before it departs. This creates a complication as there are two relief times at one location. The arrival and departure times may or may not be close together. In this case, the relief opportunity contains two different relief times. A crew can effectively relieve another crew at any time which falls within the time gap, and this leads to a window of relief opportunities (Laplagne 2008).
2.1 TrainTRACS
TrainTRACS is based on the Generate and Select (GaS) approach (Kwan 2004). In the Generate phase, GaS constructs a pool of very many legal candidate shifts controlled by soft constraint parameters and heuristics (e.g. only allow up to three breaks in a shift). In the Select phase, a solution schedule is formed by selecting a combination of candidate shifts that covers all the work best satisfying the objectives and any additional constraints at the schedule level. The set covering model naturally fits well for the selection process with GaS. Set covering is one of the most studied NP-hard problems (Garey and Johnson 1979, Chvátal 1979). Given a ground set U of m elements (pieces of work from the train unit diagrams), and a weight (labour cost) for each set (a shift), the goal is to cover U with the smallest possible number of sets. In the case of train crew scheduling, there is the additional objective of minimising the total weight. TrainTRACS uses the ILP (see Fig.2) technique for the set covering selection process (Smith and Wren 1998; Willers et al. 1995). One advantage of the GaS approach is that optimization is mainly performed at the Select phase, which can employ a largely domain independent solver taking advantage of advances in generic solution techniques, e.g. column generation (Fores et al 1998) and hybridised search (Kwan and Kwan 2007) are used in TrainTRACS.
TrainTRACS was originated from University of Leeds, where research in transport scheduling dates back to the early 1960s. General presentations of the system are given in (Wren et al. 2003; Fores et al. 2002). The company Tracsis was founded in 2004 to fully commercialise TrainTRACS. In 2004 and 2005, several major TOCs have commissioned pilot trials using TrainTRACS for part of their current operations. After the pilot trials, the TOCs involved have all adopted TrainTRACS for regular use in-house. More similar pilot trials and subsequent adoptions by other TOCs followed. Some transport company groups have also used TrainTRACS to support their franchise bids.
No. Train No.
Task BU2388
Driver HA403 MOB
On - 11:50 Edinburgh 12:10 2L06
Off - 21:30 Bathgate 12:38 12:48 2F36
Hours - 09:40 Edinburgh 13:14
Days - SUN IMMOB
mealbreak (min. 25 mins) HA409 MOB Edinburgh 14:15 5L28 Inverkeithing 14:39 14:41 5L28 Inkeithing N Jn 14:43 15:28 5L28 Inverkeithing 15:30 15:32 2L19 Edinburgh 15:58 IMMOB
mealbreak (min. 15 mins) GW161 MOB
Edinburgh 16:37 2B31 North Berwick 17:10 17:20 2G31 Edinburgh 17:53
IMMOB
mealbreak (min. 20 mins) CK207 MOB
Edinburgh 18:48 2R42 Dunblane 19:48 20:06 5R42 Dunblane Sig Box 20:07 20:14 5R31 Dunblane 20:15 20:18 2R56 Edinburgh 21:18
IMMOB
Fig.4 An example train crew (driver) diagram
3. Successful train crew scheduling optimization
TrainTRACS has persisted and evolved over a large number of years, not being exhaustive the main factors are:
• Mathematical engine consistently yields efficient solutions
• Solutions produced are readily operable
• Algorithmic approach suits long term development in which application domain knowledge could be accumulated incrementally
3.1 Optimizing capability
To most train planners, next to validity what they look for is efficiency in the schedules. Pilot trials of TrainTRACS have demonstrated to the TOCs very significant efficiency savings. Because of commercial sensitivity, TOCs usually would not be making public the saving figures. They would also, sometimes quite rightly, argue that there are other factors than using TrainTRACS in achieving the savings. In some cases, the TOC may decide not to implement reduction of their crews employed immediately (therefore ‘no saving’!), but to use the excess crews to increase the number of spare cover turns. In any case, the UK train industry is very self-referencing and the reputation of the tools and systems they use does get widely spread. In the following, a very recent case study is presented in which the schedule efficiency achieved by TrainTRACS was quite remarkable.
Case Study: Virgin West Coast
Virgin West Coast operates an inter-city network from London along the West Coast up to Scotland serving the major cities of Birmingham, Liverpool, Manchester and Glasgow. The West Coast Route Modernisation project (Modern Railway 2009), which has spanned over many years, was being completed by the end of 2008. The network capacity has been increased and trains are now able to pass through some previously bottlenecks at high speeds. As a result, journey times are shortened and Virgin was committed to a new set of timetables with vastly increased services (“Virgin High Frequency” (VHF) services). The number of weekday services was increased from 252 to 335, Saturday services was increased from 230 to 300, and Sunday services goes from 155 to 230 trains (Modern Railways 2008). Most notably, with a train every 20 minutes between London, Birmingham and Manchester in both directions it has become the most frequent long-distance inter-city service in Europe.
Around late 2007, Virgin began crew planning for the VHF timetable. With a 32% increase in services, even though they could manage (because of shortened journey times and improved maintenance facilities) with the existing fleet of trains, Virgin expected an increase in crew size. However, there was an obvious need to try minimizing the increase. From another franchise Virgin Cross Country, Virgin had prior experience of trialling and adoption of TrainTRACS. (When Cross Country’s franchise expired, Arriva won the new franchise and they continued using TrainTRACS.) Hence, a pilot trial was carried out between January and March 2008 using TrainTRACS for planning the crew schedules for the VHS services. The results of the pilot trial was very carefully scrutinised and management was impressed and confident that TrainTRACS was the tool they needed. Virgin quickly adopted TrainTRACS and used it in-house for planning the VHF crew schedules in full scale.
The Virgin onboard train crews include drivers, train managers and catering staff. Part of the train crew planning involves negotiations on changing some of the labour rules. Several key changes were accepted by the train crews. At the end only half a dozen more train managers were needed (Modern Railways 2009) and there was no increase in the other categories - out of a total of over 1600 onboard train crews, for the whole VHF crew schedule. The VHF timetable, covered by crew schedules produced by TrainTRACS, went live in December 2008.
The Virgin West Coast problem is highly constrained. As an example of schedule efficiency achieved by TrainTRACS, one of the Virgin driver labour rules is so-called “no double tripping”, meaning that a driver cannot be scheduled to drive the same route section in the same direction for more than once within a shift. Before the VHF timetable, many driver shifts would only cover one major city destination from London between breaks, and the breaks at London were typically very long (up to about 3 hours). The new driver schedules still adhere to the “no double tripping” rule, but some “triangular working” between London and two major city destinations would be covered, resulting in the removal of long breaks.
3.2 Solution operability
For a crew schedule to be operable means that basically
• Crew members are qualified for the work they are scheduled to do
• Crew members can get to where they need to be on time
Achieving total operability in its solutions is the ethos in the development of TrainTRACS. For some other scheduling problems, maybe for example an 80% valid solution would be acceptable and the user would either not to operate or manually making good the remaining 20%. Train services cannot be left uncovered and manual adjustments would be difficult due to the combinatorial nature of the schedule.
The TrainTRACS strategy has two main folds, it does not allow infeasible shifts at any stage of its algorithm, and it provides comprehensive features modelling the operations at the required level of details. Examples of two key features are:
• Crew travel as passengers. When a train crew is scheduled to cover a train at a distant location, we have to ensure precisely that there is a means of transport that will get the train crew there on time. For the scheduling of urban bus drivers, a constant time allowance would usually be adequate for a bus driver to travel from anywhere to anywhere within the bus network. Because of the wide area of network coverage, train crews often have to catch the train themselves and travel according to the timings in the train timetables; using just a constant travel time allowance often would not yield valid solutions. TrainTRACS computes the shortest paths using the timetabled transport and walking.
• Route and traction knowledge. Each train work piece has a set of route and traction skill requirements for the crew covering it. The TrainTRACS model includes lookup tables of which set of train crews, usually in groups within specific depots, knows which routes and traction types. When TrainTRACS forms crew shifts, only work pieces with compatible route and traction knowledge are allowed in the same shift.
TrainTRACS also has numerous other features for modelling labour rules and time allowances for individual shifts, and for modelling side constraints on parts of or the whole of the schedule. In the following, a case study of some experience with Southern Railway is presented to highlight a special scenario requiring accurate modelling of their operations.
Case Study: Southern Railway
Southern covers many large densely populated areas in south England from London to the coasts, e.g. Southampton, Portsmouth, Brighton and Eastbourne. Its services are of mainly intensive urban commuting type. After a brief pilot trial, Southern adopted TrainTRACS for in-house use in 2006. Their network was amongst the largest and most difficult to be tackled in a feasibility trial for TrainTRACS. The feasibility trial was carried out on the Saturday services over the whole network. Because of the intensive commuter services, there are many relatively short interval stops giving rise to very many relief opportunities and small work pieces. Southern has many crew depots scattered around the network, and the crews are subdivided into groups called ‘links’ within each depot. Drivers from each link may have knowledge of different combinations of routes posing a complex compatibility structure for the scheduling process. There are targets on the minimum and maximum number of turns for each depot link. Southern has a practice called ‘full crew working’, which means that onboard crew members will be scheduled as a team for the whole day. Full crew working has the advantage that working as a team generally increases schedule robustness and is usually welcomed by the crew. In this pilot, the full crew consists of a driver and a conductor. Usually, conductor problems are smaller than the driver problems because conductors do not have extra train work such as preparation, disposal, etc. Also, the labour rules for conductors and drivers are different. For example, the maximum turn length is usually higher for conductors than for drivers.
At Southern, train drivers have to engage in some non-driving tasks notably the coupling and de-coupling of train units. Exactly how the drivers are scheduled to share the driving and non-driving work at the coupling/de-coupling instances impinges on the operability of the schedule. A specific and frequently occurring scenario is presented below for illustration.
Basic scenario
Surplus
driver
Train 101
Train 78
Train
101/78
New
driver
X
Y
TimeSurplus
driver
Train 101
Train 78
Train
101/78
New
driver
X
Y
Surplus
driver
Train 101
Train 78
Train
101/78
New
driver
X
Y
Time TimeFig.5a Coupling of two trains
Fig.5a illustrates the attachment of train unit 78 to the rear of train unit 101 after they have arrived at a certain station X. The coupled train 101/78 only needs one driver making the other driver not needed at X. Normally, the driver at the rear would get off train, perform the attachment and let the driver on the front train to continue the train journey. Otherwise, the driver on the front train has to walk to the rear, does the attachment, and walk back to the front before setting off again, which may require more time than the train timetable allows. Therefore TrainTRACS applies the rule that “Driver on the front unit stays on” and pre-processes to remove the coupled work from all but the front train unit, which is illustrated in Fig.5b. Later on, the coupled units are detached at Y and go separate directions. This time one more driver is needed, who would be waiting at Y to do the detachment and then drives the rear unit. The pre-processed train unit diagram 78 becomes two segments separated by a large time gap, which would force its driver to be relieved at the start of the gap and another driver to get on after the end of the gap.
Train 101
Train 78
TimeTrain 101
Train 78
Train 101
Train 78
Time TimeComplex scenario with train reversing
Fig.6a illustrates a frequently occurring scenario: suppose now the coupled train stops at terminal Z, the driver walks to the other end of the train and continues the train journey in the reverse direction.
Train 101
Train 78
101/78Z
78/101 Train Reversed TimeTrain 101
Train 78
101/78Z
78/101 Train Reversed Time TimeFig.6a. Coupled train reversed direction
Train 101 becomes at the rear instead of at the front and vice versa for train 78. Applying the pre-processing rule used in the basic scenario, Fig.6b shows the results of removing train work in which the train unit is not at the front.
Train 101
Train 78
TimeTrain 101
Train 78
Train 101
Train 78
Time TimeFig.6b. Rear coupled train work removed Fig.6b is unsatisfactory because:
• The train work is more fragmented (into 4 segments) than the scenario shown in Fig.5b (3 segments). In general, dividing the train work into more segments would result in more short pieces of continuous driving work making the schedule less efficient.
• Each pre-processed train unit has a large time gap between its two segments, forcing a crew relief at Z, but Z might not be a suitable location for changing crews.
The planners at Southern observed that the resulting schedule is exhibiting a style of shift composition quite different from how they would operate in practice. The problem was intensively studied to identify all the variants of the scenario and the exact rules to be applied resulting in a different pre-processing method rearranging (‘reshaping’) the train work between the unit diagrams involved as illustrated in Fig.6c. Since the driver has repositioned to the other end of the train before the coupled train reverses direction, the driver on train 101 is at the front of the train all the time. The coupled work is therefore completely removed from train 78. Moreover, at the end of the coupled work, the driver is actually on the original train 78 because of the train reversal. Therefore the final leg of un-coupled work on train 78 is also appended to train 101 - the original final leg of which will now be at the rear and therefore detached and given a different train unit number ‘101a’. The reshaped unit diagrams are only for use by crew scheduling and no longer preserves the true identity of the rolling stock. By this method, the number of train work segments for crew scheduling is minimized.
Train 101
Train 78
Train 101a
TimeTrain 101
Train 78
Train 101a
Train 101
Train 78
Train 101a
Time TimeFig.6c. Rearranged train work
The scenarios are simplified in Figures 5-6 for illustration purposes. In real life, multiple train units may be involved in numerous different combinations of coupling during a day’s operation. Examples of many instances of reversal of coupled train units can be found in Fig.3, e.g. 16.31 at Vic and 18.19 at Ebne. Fig.7a shows diagrammatically an extract of a part of a train network in Southern. The operations are evidently complex with respect to how train units are coupled. For example, focusing on train unit 104, in the earlier part of the day it is coupled to the rear of unit 103; the coupled train is further attached to the rear of unit 133; the three-unit formation reverses direction of travel so that 104 becomes at the front; unit 104 is detached on its own before being attached to the rear of the coupled formation 129/137; reverses direction, detached and later attached to unit 133 again. TrainTRACS extends the ‘reshaping’ process discussed above transforming the train work from Fig.7a into Fig.7b with continuous segments of reshaped train work shown in textured lines. In the process, various additional tasks and their time allowances are also computed, which are needed for compiling the crew schedule. Examples are: PB (prepared from berth), PC (partial prepare), TC, B (berth), AB (attach and berth multiple units), AP (attach portion), APR (attach portion rear), DWFP (detach and work front portion) etc… Each type of task attracts a slightly different time allowance for the driver - sometimes dependent on the length of the train, sometimes dependent on whether the train is at a siding or at a platform.
133 103/ 104 10 4 14 8 14 8 10 3 133 15 0 104 129 137 170
Vertical bars indicate where coupled trains are reversed en route Train unit identifier Time 133 103/ 104 10 4 14 8 14 8 10 3 133 15 0 104 129 137 170
Vertical bars indicate where coupled trains are reversed en route Train unit
identifier TimeTime
Fig.7a. Complex train coupling at Southern Railway
Time Time Time
Continuous segments of reshaped train work are shown in textured lines Fig.7b. Reshaped train work
Without the automatic reshaping function in TrainTRACS the planners previously tackled the problem manually mainly by juggling with the working schedule. Apart from being a tedious process, the manual schedule adjustments may also result in loss of efficiency. The pre-processing methods are beneficial to commuter train operators mostly because their train networks are complex and their services are intensive, for which extensive
train coupling is common. The problems are less relevant to inter-city train operations, for which train coupling is largely not practised in UK.
3.3 Incremental accumulation of domain knowledge
Real world scheduling is usually an evolving problem. For example, before privatisation in the early 1990s, the UK rail services were operated by one single national company British Rail. Since then, the UK rail service network has undergone several rounds of being partitioned, reformed and franchised to many TOCs; the train crew labour rules and practices have also been diverging between the privatised TOCs and they are still changing. Therefore it is essential for a train crew scheduling system to be able to keep up with the changing scheduling scenarios on a long term basis.
Another reason for the need to be able to incrementally enrich the scheduling system’s domain knowledge model base is that it is impossible to acquire all such domain knowledge quickly in one go. Every TOC has its own peculiar problem scenarios to some extent and it is usually a very lengthy process spanning over many years in interacting with each TOC and discovering their precise problem scenarios.
It is therefore important in the long term that the scheduling system is built on an approach that is easily amenable to the incorporation of new domain knowledge from time to time. Otherwise the scheduling system would have to be overhauled frequently and that would be impractical in the long term.
Following a suitable approach, the need for further enhancements of the scheduling system would lessen over time as more and more problem scenarios would have been encountered, tackled and assimilated. Often, even if a new problem scenario has arisen, there would be some way, albeit probably a cumbersome one, of using the existing system to handle it. This is usually the first course of action to explore so that the train company users would not be held back, while a proper implementation would be incorporated into the system’s research and development plan.
TrainTRACS follows the GaS approach discussed in section 2.1, which is advantageous because the scheduling rules, domain specific knowledge, can be dealt with almost entirely within the Generate phase. Furthermore, the Generate phase does not consider how the candidate shifts would fit amongst themselves, individual candidate shifts are generated independent of each other; application of the scheduling rules are therefore straightforward and the rule set can be expanded relatively easily – enabling TrainTRACS to engage in the process of generalisation and incorporation of new problem scenarios in a continuous incremental manner.
The current TrainTRACS has incrementally accumulated domain knowledge from a large number of transport operators over many years. That many TOCs have adopted TrainTRACS (see Section 1) lends support for the merit of its incremental approach. The wide range of problem scenarios that TrainTRACS has been used for is reflected in the variety of train operation types of the TOC users - Inter-city: NXEC, Virgin West Coast; Provincial: Northern, Cross Country, London Midland, Arriva Wales; Intensive Commuter Services: Northern, Southern, South Eastern; Urban city: London Overground.
4. Conclusions and remarks
Being a very hard optimization problem to solve, an automatic train crew scheduling system like TrainTRACS takes many years of incremental research and development to mature incorporating domain knowledge from the industry along the way. The GaS approach has shown to be particularly suitable.
Every TOC user of TrainTRACS has commissioned a pilot trial before they adopted the system. The trials were conducted using real data from the TOC involved. The TOCs would have verified, often by comparison with their existing schedules, that valid operable and efficient results have been produced before they accepted the system. Once adopted TrainTRACS is used in-house regularly for production use. Apart from LTP some TOCs are also using the system for STP, for which some new features and automatic links to other systems for other aspects of train operations planning have been developed in the TrainTRACS system.
The use of TrainTRACS has not replaced any train planners. On the contrary, train planners may have become more important because with much time freed up by using an automatic system, they can devote more effort on exploring many planning options and strategic issues like schedule robustness. Schedulers welcome the
use of TrainTRACS. Much stress is relieved from a job that is very much squashed in time between when the train unit diagrams are ready and the going live of the new set of timetables.
There may be fear that labour unions would strongly oppose computer produced schedules because efficiency savings may lead to job cuts. From the experience with TrainTRACS, this fear did not seem to have materialised. Many UK TOCs barely have sufficient train crews. Drivers in particular are expensive to be trained on specific routes before they are legally allowed to drive. At least initially, TOCs tend to turn possible efficiency savings in their crew schedules into making their operations more punctual and robust. In one case, the labour union seemed even more enthusiastic than the TOC management for TrainTRACS. The labour union wanted certain working patterns that management has agreed in principle, but the schedulers were unable to work out satisfactory schedules that can implement the requested working patterns. Trial application of TrainTRACS resulted in schedules that solved the problems.
Refer ences
Abbink, E., Fischetti, M., Kroon, L., Timmer, G., & Vromans, M. (2005). Reinventing crew scheduling at Netherlands Railways. Interfaces, 35, 393-401.
Barnhart, C., E. L. Johnson, G. L. Nemhauser, M. W. P. Savelsbergh, and P. Vance. (1998). “Branch-and-price: column generation for solving huge integer programs,” Opns. Res. 46, 316-329.
Burke, E., Pinedo, M., Steef van de Velde. (2001) Editorial, J of Scheduling, 4, 1-2.
Caprara, A., M. Fischetti, P. Toth, D. Vigo, P. Luigi Guida. (1997). “Algorithms for railway crew management,” Mathematical Programming 79, 125-141.
Chvátal, V. (1979). “A greedy heuristic for the set-covering problem,” Mathematics of Operations Research4, 233-235.
Desrochers, M. and F. Soumis. (1989). “A column generation approach to the urban transit crew scheduling problem,” Transportation Science 23, 1-13.
Fores, S., L. Proll, and A. Wren. (1998). “A column generation approach to bus driver scheduling,” In: M. G. H. Bell (ed.) Transportation Networks: Recent Methodological Advances. Pergamon, 195-208.
Fores, S., L. Proll, and A. Wren. (2002). “TRACS II: A hybrid IP/heuristic driver scheduling system for public transport,” JORS 53, 1093-1100.
Garey, M. R. and D. S. Johnson. (1979). “Computers and Intractability: A Guide to the Theory of NP-Completeness,” Freeman, San Francisco.
Huisman, D. (2007). “A column generation approach to solve the crew re-scheduling problem.” EJOR, 180, 163-173.
Hoffman, K. L., M. Padberg. (1993). “Solving Airline Crew Scheduling Problems by Branch-and-Cut,” Management Science 39, No. 6, 657-682.
Kroon, L.G., & Fischetti, M. (2001). “Crew Scheduling for Netherlands Railways "Destination: Customer".” In Voß, S., & Daduna, J.R. (eds), Computer-Aided Scheduling of Public Transport. Springer, Berlin, 181-201.
Kwan, R. S. K. (2004). “Bus and train driver scheduling.” In J. Y.-T. Leung (ed.), Handbook of Scheduling: Algorithms, Models, and Performance Analysis. CRC Press, Chapter 51, 1- 20.
Kwan, R. S. K. and A. Kwan. (2007). “Effective search space control for large and/or complex driver scheduling problems,” AOR 155(1), 417-435.
Laplagne, I. (2008). “Train driver scheduling with windows of relief opportunities,” PhD Thesis, School of Computing, University of Leeds.
Modern Railways. (2008) “West Coast dominates timetable changes.” Modern Railways, December 2008, 46-47.
Modern Railways. (2009) “West Coast Route Modernisation.” Modern Railways, May 2009, 33-54.
Smith, B. M. and A. Wren. (1988). “A bus crew scheduling system using a set covering formulation,” Transportation Research 22A, 97-108.
Willers, W. P., L. G. Proll, and A. Wren. (1995). “A dual strategy for solving the linear programming relaxation of a driver scheduling system,” AOR 58, 519-531.
Wren, A. (1981). “General review of the use of computers in scheduling buses and their crews.” In A. Wren (ed.), Computer scheduling of public transport. North-Holland, 3-16.
Wren, A. and J.-M.Rousseau. (1995). “Bus driver scheduling – an overview.” In J. R. Daduna, I. Branco, and J. M. P. Paixao (eds.) , Computer-aided transit scheduling. Springer-Verlag, 173-187.
Wren, A., S. Fores, A. S. K. Kwan, R. S. K. Kwan, M. E. Parker, and L. Proll. (2003). “A flexible system for scheduling drivers,” J. of Scheduling 6, 437-455.
