Scheduling Vehicles and Their Drivers – Forty Years’ Experience

SCHOOL OF COMPUTING

RESEARCH REPORT SERIES

Report 2004.03

Scheduling Vehicles and their Drivers – Forty Years’ Experience

Anthony Wren

April 2004

Abstract The author has been researching and applying the use of computers in scheduling buses, trains and their drivers since 1960. Starting with the world’s first implementation of a locomotive scheduling program, for British Railways in 1963, his team’s developments in heuristics and mathematical programming applications are traced. Significant savings have been achieved in all areas, and modern methods allow schedulers rapidly to explore ranges of options. Particular attention is paid to problems of implementation, and to cases where choices of system have been based on incomplete information. Finally, some outstanding problems will be discussed.

1 Introduction

In the 1950s the British Transport Commission was responsible for all (nationalised) commercial and public road and rail transport in the United Kingdom. In 1959 the Commission sponsored the Electronic Computing Laboratory of the University of Leeds to investigate possible uses of computers in the scheduling of all its transport modes. The report of August 1960 [8] recommended: 1. the setting up of a research panel to keep under review progress in the solution of general scheduling problems and to advise from time to time on how best to further this progress and its application to the work of the Commission; 2. the initiation of an immediate investigation into the construction of a general program for bus crew scheduling, based on the work of the London Transport Executive and the City of Oxford Bus Company; 3. the extension of present studies to investigate the use of very large computers for railway timetabling and scheduling, with a view to constructing programs suitable for such work in the near future. The third of the above recommendations was accepted, and the work was commissioned from the University later in 1960. By that time the authors of the report had moved to other positions, and the present author was charged with carrying out the work. The first resultant schedules became operational in May 1963, believed to be the world’s first computer-produced working schedules. After several other rail projects, the author turned his attention to delivery vehicle routeing [27] and bus and driver scheduling. During the 1970’s several working bus schedules were produced, yielding substantial operating savings. From 1981 bus scheduling systems were supplied to many organisations for their daily use, and 1984 saw the supply (to London Transport) of the first of many bus driver systems. Train driver scheduling systems were developed from about 1994, and first used by twelve British operating bodies in the prelude to privatisation to conduct “what-if” investigations for proposed new timetables and labour agreements. The emerging system was demonstrated to London Underground on a number of occasions, showing savings on several operating lines. Current bus and driver scheduling systems are in regular use by all 25 operating units of the UK’s largest bus operator, while the rail driver system is used in house by one mainline train company, and in occasional scheduling projects by others. This paper describes the author’s experiences in developing, testing and implementing scheduling solutions over the past forty-three years. The actual methods used by the systems are not presented in full, references being given to the relevant papers. Other systems have been presented in other conferences in the present series [2, 3, 4, 12, 13, 19, 20, 25], and outlined by Wren and Rousseau. [30].

2 Rail locomotive scheduling (1961-1964)

The simplest view of a locomotive scheduling problem is that a set of locomotives of a single class is to be allocated to a set of trains in such a way as to minimise the number used, and within that to minimise the amount of light running (locomotives making positioning moves without trains). The problem can be modelled in mathematical terms as a standard Assignment Problem with a row and column for each train, and solved by the Hungarian algorithm. However, the number of trains in our first practical examples ranged up to 150, requiring cost matrices of 22.5K, well beyond our 1960 Pegasus computer’s capacity of 7K words for data and code together.

1 A heuristic was therefore devised which had the merit of producing the optimal solution in all problems small enough to be checked against the Hungarian algorithm. In the forty-three years since the research started, it has been applied to many thousand real and often large rail and bus scheduling problems of the above form without being bettered. (However, one may construct unrealistic examples, which we have not encountered in practice, where the heuristic terminates in a local optimum.) A strong lower bound to the required number of locomotives can easily be calculated as the maximum number of simultaneously operating trains, where two trains are effectively simultaneous if the locomotive used for the earlier finishing one cannot reach the starting point of any other train until after the departure of the second. This bound mechanism was presented by the author to Stern and Ceder [18] who proved its validity. The reader may be interested in the simple (but effective) method that was devised for locomotive scheduling by making use of this mechanism. A (possibly infeasible) solution was developed using the above bound for the number of locomotives; trains were taken in order of departure time and assigned to free locomotives rather arbitrarily; if no locomotive was free, then some locomotive was allocated infeasibly, and a penalty was assigned equal to the time needed to move the locomotive to the relevant point, minus the time available (which might be negative). The result was a linked list of activities (trains) for each locomotive, where each link had either a cost equal to the time necessary to move between points or a penalty as above. The heuristic examined all pairs of links, exchanging their end points if this produced a reduction in total penalty, or a reduction in total cost for no increase in penalty. A neutral exchange was made if no change in total cost or penalty resulted; this might create a new pattern which could allow the heuristic to escape from a local optimum at the next pass. The process stopped when two complete passes produced no improvement. Many experiments were carried out with different starting solutions, including some in which very large infeasibilities were present. All experiments, however bad the initial solution, converged for any given data set to the same total penalty and total cost, apparently the global optimum. In particular, where a feasible solution was known to exist with the given number of locomotives, such a solution was always found. Where a penalty remained after convergence, the original approach was to increase the number of locomotives by one and to try again. It was soon realised, however, that it was worth presenting the penalised links to the client, who could often retime a train in order to remove the penalty. In the first practical exercise implemented for British Railways (BR) in 1963, the number of locomotives was reduced from 15 to 12 (after two accepted retimings) and the light running was reduced by 28% [21]. The above had involved a set of freight trains running day and night, ferrying traffic around London, principally between the docks and marshalling yards. The solution had to be adjusted to allow the locomotives to be returned from time to time to the depot for maintenance. This adjustment, which was carried out manually by the author, followed another heuristic designed by him, which could not easily be coded within the computer’s capacity. This preserved the savings, although three additional locomotives were required to allow for maintenance, both in the “before” and “after” situations. It may be noted that the exchanging procedure is equivalent to pairwise swapping of the elements of a solution matrix for the assignment problem if the penalties are given precedence in the cost matrix. A major difficulty in having the process accepted by our peers in 1963 was the lack of a proof of optimality. The term “heuristic” was unknown to them and the author was forced to use the term “trial and error” in presenting the process. The system was used by BR’s OR department for several years on many parts of the network with considerable success.

3 Heuristics for bus driver scheduling (1967-1978)

That the bus driver scheduling problem could be formulated as a set covering or set partitioning problem was known from the early 1960’s. However, no practical solution could be obtained from such a formulation until much later. Throughout the period 1967-1978 the author and his associates devoted much attention to seeking a good heuristic method [9, 23], culminating in the TRACS system [11]. Bus driver scheduling is the problem of designing legal shifts so that all scheduled buses have a driver assigned at all times of day. Shifts have constraints on their duration, on the position of meal breaks and on other features which may be negotiated locally. Drivers can only be changed at relief opportunities when buses

2 pass suitable points. Most shifts consist of two stretches of work separated by a meal break. While each stretch would ideally consist of work on a single bus, it is often necessary in order to fit all the bus work together that a stretch should contain more than one spell, on different buses separated by small paid breaks. When first presented with this problem the author hoped that a similar approach to that used in locomotive scheduling could be devised, i.e., that one might construct an infeasible schedule and then refine this until eventually a good feasible schedule was obtained. Unfortunately in removing the infeasibilities the schedule was forced to become progressively more fragmented, introducing wasteful gaps between spells of work, and thus requiring too many shifts. Attempts to devise heuristics to escape from the resultant local optimum were unsuccessful. These consisted of routines which exchanged work between shifts in several ways. While the refining routines were often (indeed usually) successful in improving existing manual schedules, it became evident that they were not capable of moving from a poor schedule, such as was initially constructed, to a good one. The conclusion that it was unlikely that heuristics could move from a poor solution to a good one was borne out by observation of manual schedulers; when a trainee constructed a schedule it would be checked by a senior colleague; unless the first attempt was reasonably good, the senior scheduler would find it easier to start again than to adopt the poor schedule as a basis for adjustment. Much time was therefore spent in improving the starting routine, and several approaches were designed. Examination of the problem structure enabled the team to identify certain critical features which would lead to inefficiency unless properly addressed, and by about 1974, with sponsorship by the National Bus Company, we had designed a process which would produce reasonably good initial schedules for three sample bus operators. The system (known as TRACS) incorporated techniques gleaned from human schedulers, while the starting schedules were refined by the heuristics designed several years earlier, resulting in solutions which were at least as good as manually produced ones. The author proposed to the National Bus Company to develop the process into a full system for in-house use. However, the company preferred to attempt to do this development themselves, but abandoned the work after a few years. Over the next few years feasibility studies were carried out for some dozen bus operators. The constraints on schedule construction (shift length, etc.) vary greatly between companies, as do the “shapes” of underlying bus schedules. Initial experience indicated that while the heuristics behind the starting solution had to be adapted to deal with new situations, these adaptations could be designed and accommodated within a developing general method after about three person-months of research. We were therefore hopeful that we should ultimately develop a general starting heuristic which would be applicable to new situations with minor, if any, modifications. During this time, several organisations had implemented schedules produced by the system, and one had used the programs to experiment in conjunction with the drivers’ union with many different sets of possible constraints to help design a new mutually acceptable set of rules. This last company entered negotiations to buy the system; these broke down when its in-house computer group objected to operating a system which could not guarantee an optimal solution, despite its consistently achieving better schedules than those produced manually. The last three organisations for whom tests were undertaken upset the earlier confidence in the system, and no acceptable schedule was obtained within the budgeted three months. In Glasgow the working day was longer than met elsewhere, and a desired percentage of “early” shifts was not achieved. In Dublin the times of the peaks were much later than elsewhere, preventing the heuristic which dealt with the morning peak from working satisfactorily. In London the bus schedule had always been carefully designed to accommodate a good driver schedule, and there was generally only one acceptable solution, which the heuristics could not find. We therefore initiated in 1978 a search for a different solution method (see Section 5). It may be remarked that the resulting new system is now used consistently in London and Glasgow, while the Dublin company is using a system believed to be based on a similar model.

4 Bus scheduling (1970-1991; 1995 onwards)

In 1970 the locomotive scheduling system was adapted for bus operation, first for a single bus type and single depot. A trial was carried out for Yorkshire Traction in Barnsley where 23 buses were saved out of 107, partly by improved linking of journeys, and partly by retiming or otherwise adjusting journeys where the system

3 indicated infeasibilities [22]. Yorkshire Traction subsequently sponsored developments of the system (known as VAMPIRES) to allow more than one depot and more than one type of bus. The multi-depot problem was handled by extending the exchanging concept of Section 2. The problem was solved first without reference to depot. Vehicles were then allocated to the depot requiring the least total empty running to their first departure point and from their last arrival point, and the heuristic was continued. When investigating a potential exchange, the best depots for the revised workings were determined on the same basis, and the exchange was accepted if the total costs of journeys to and from the depots and of the links being considered were not worsened. The system was later extended to treat the return of buses to their home depot in the course of the day by assigning appropriate negative costs to links having large idle times. It may be noted that the assignment problem approach which was rejected ten years earlier on the grounds of machine capacity could not have been extended in these ways, as the Hungarian algorithm can only treat the immediate costs of a link, and not the knock-on effect of a change on the rest of the bus working. It will be recalled that the original heuristic did not guarantee optimality, but obtained solutions which were in fact optimal in those cases where verification was possible. Little can be said about the optimality of the extensions, as the problems were much larger, and contained added complexities. Bus companies were, however, satisfied with the results. The treatment of more than one vehicle type is too complex to detail here. The first tests were carried out on a problem involving nine basic types, any journey having a range of preferred types. A multi-stage process was devised, repeatedly using a classical Transportation Problem to determine shadow costs which guided the heuristics. Although the results of this process were satisfactory where there were genuinely many types of vehicle, the increase in computer time was very great, and situations arose in which lack of optimality could be demonstrated. Shortly after this development, there was a movement in the UK towards bus fleets consisting of a single vehicle type, and the multi-vehicle option has not been used for about thirty years. Practical exercises for several other companies followed [10, 17]. The first regular user was Greater Manchester Transport who installed the program in 1975. Although VAMPIRES was used throughout the 1970’s, with considerable savings (over 10 vehicles in total), its ability to explore all possible combinations of journey across a region was superfluous when routes were scheduled in relatively small groups, and operations were regular, so that the normal activity for a bus on reaching its destination was to turn and go back to its origin. A simpler system, TASC, was therefore developed in which dead (empty) journeys were only considered if an arriving bus could not match a departure from the same point within a specified time. TASC [17] included a backtracking process to try to ensure that where dead journeys were necessary, the most efficient set was used, and was installed for several bus operators in the early 1980’s. It was easier to use than VAMPIRES, the data being specified as series of regular journeys on several routes, rather than as individual journeys, and it was initially faster. However, users started to complain that sometimes the solution was not optimal, and the backtracking process was gradually made more complex to satisfy their complaints, adding to the computer time. A simplified version of VAMPIRES was therefore combined with TASC; a preliminary solution was found by TASC, and divided into blocks of continuous work with no long gaps or dead journeys; these blocks were then rescheduled by VAMPIRES as if they were individual journeys. In 1983 the decision was made to convert the system for microcomputers, and after various trials it was determined that the TASC algorithm had become so complex that VAMPIRES was now faster. Therefore the first microcomputer version was based on a simple version of VAMPIRES. This has since been made more complex; for example, a crude but fast method for dealing with more than one vehicle type was added at the request of a client; this incorporates a three-way swapping procedure. This version was installed in some forty bus companies, and is still in commercial use. Although VAMPIRES and TASC were developed by the author’s group in the University of Leeds, they were latterly marketed by Wootton Jeffreys as part of the BUSMAN suite [1]. Wootton Jeffreys sold their interest to Hoskyns (later Cap Gemini) in 1992. Following a period of dispute the University also sold their interest in BUSMAN to Cap Gemini in 1993. Subsequently BUSMAN has had a series of owners, but as far as is known there has been no significant development in the scheduling algorithms since 1992. Having lost control of the VAMPIRES and TASC programs, the author’s colleagues set to design an object oriented approach to bus scheduling, and a new program, BOOST, was developed. BOOST [7] incorporates a modification of the previously published VAMPIRES algorithm, using flexible definitions of bus routes and service frequencies as input. On screen a lower bound to the number of vehicles is displayed, and this may be accepted or altered by the user. If no feasible solution may be found with the chosen number, the infeasibilities

4 may be displayed, so that the user may choose to retime highlighted journeys; alternatively, the user may choose to increase the number of vehicles. There are various output facilities, including a graphical form which enables the user to follow vehicles throughout the day, and to investigate fully the effect of any potential retiming. BOOST can produce input files for driver scheduling, showing, for each bus, the times at which relief points are visited. BOOST is used in-house by First, the UK’s largest bus operator, and by several other bus companies.

5 ILP based methods for bus driver scheduling (1978 onwards)

Advances in computer power led us in 1978 to examine again the possibility of basing a driver scheduling system on integer linear programming (ILP). A new system which was first installed for London Transport Buses in 1984 was first described in [16]. The basis was the generation of many thousand potential shifts followed by a specialised ILP process to select a subset which formed a good schedule; refining heuristics similar to those used earlier modified the solution, and were able to restore shifts rejected by earlier processes. Heuristics restricted the size of the generated set and drove the branch and bound part of the ILP. These are too complex to describe here, and readers are referred to [15, 16] for further details. It is sufficient to say that the generation process was restricted by two sets of heuristics based on knowledge of the problem structure. It had been observed that a good integer solution could be found using only the relief opportunities in the continuous relaxation and usually with the number of shifts indicated by the relaxation; the ILP took advantage of this in a specialised branch and bound algorithm. The original system (IMPACS) is fully described in a thesis [14]. The many thousand potential shifts were generated according to a comprehensive parameter set; shifts conforming to these parameters were passed to specialist routines written for the individual client which tested them against any extra local conditions. The remaining potential shifts (still many thousands) became input to the ILP phase. IMPACS was first developed under a number of research grants, and tested on a comprehensive collection of data sets which had been gathered from diverse bus systems. This led to practical demonstrations being given to three bus companies in November 1982; two were subsidiaries of the National Bus Company, operating a mixture of urban and rural services, while the other was London Transport. During this single month, data was gathered and coded from each company, three sets of special routines were written, and three acceptable schedules were produced, all indicating savings in driver costs. Following this demonstration, a contract was signed with London Transport, whereby a year’s further development would be undertaken, after which the program would be handed to London Transport for their own use. This work started in the autumn of 1983. Towards the end of 1984 a complete redesign of the London schedules became necessary, due to changed working practices. By that time one scheduler out of the very large London team had been trained in IMPACS, and he used it to produce a significant proportion of the new schedules; these were generally the most difficult schedules which had presented problems for his colleagues working manually. By the end of 1984 IMPACS had been fully accepted, and at the beginning of 1985 it became the standard means of producing driver schedules in London. It continued to be used throughout London, unaltered apart from a minor upgrading when transferred to a new computer, until some years after the privatisation of the London bus services which started in 1994. It is believed still to be in use in some of the London companies. In 1985, IMPACS was also supplied to Greater Manchester Transport, and later that year it was incorporated in the BUSMAN system [1]. In this form it was installed for about thirty transport organisations, including bus, tram and light rail systems. As has already been mentioned, the University of Leeds lost control of BUSMAN to Cap Gemini in 1993. The original IMPACS as supplied to London and Manchester still legally belongs to the University, although we have lost control of its use. In Section 6 experiences in developing a new ILP based rail driver scheduling system are described. This system, originally called TRACS II (now simply TRACS), was tested on a large number of bus data sets, to ensure that as well as on rail, it would work on all bus driver scheduling problems known to us. TRACS has been described in a number of papers charting its development, most recently [5,26].

5 This version of TRACS was first used for a bus company in Reading (UK). The city had decided to relocate its bus depot, and therefore all schedules had to be recreated. Rather late in the day it was decided that the task should be done by a computer, and we were commissioned in November 1997 to apply BOOST and TRACS to this, with a deadline set by the projected opening of the new depot in January 1998. By Christmas, the scheduling task was completed by University and Reading staff working hand in hand. Significant savings were indicated on the first trial runs which replicated the scheduling of the old depot and proved the viability of the system. The old vehicle schedule was then adjusted manually to include the new depot, and suitable driver schedules were constructed. In fact, the opening of the new depot was postponed until April 1998, and advantage of this was taken to include the ful scheduling of the vehicles, to install the system fully in Reading [28], and to carry out a number of experiments to determine new labour rules. It had been estimated by the bus company that additional costs of £145,000 would be incurred annually because of the less favourable location of the new depot, but the new schedules produced by BOOST and TRACS cost only £10,000 per annum more than the schedules at the old depot. TRACS and BOOST have subsequently been installed for regular use in all twenty-five operating units of the largest British bus operator, and in four other companies.

6 Train driver scheduling (1990-1991, 1994-date)

A short exercise was undertaken over the winter of 1990-91 in which driver schedules were modelled for British Rail (BR), who wished to experiment with alternative definitions of legal or acceptable shifts and to progress to a new agreement with drivers’ unions. Train driver scheduling in the UK is considerably more complex than bus driver scheduling, but the accuracy required of the model was such that simplifying assumptions were acceptable First, modifications were made to the shift generation rules of IMPACS, which was then allowed to proceed to the optimum solution of the relaxed continuous LP. IMPACS at this time incorporated some rules to reject unlikely relief opportunities at an early stage of the process, in order to reduce the size of problem presented to the ILP. These were too specific to bus scheduling to be used here, and could not be adjusted within the very short time available for the exercise. This meant that the branch and bound process would have had to be applied to larger problems than usual. However, experience in bus driver scheduling had shown that the number of shifts in the optimal integer solution was almost always equal to that in the continuous solution, rounded up if necessary. In order to satisfy BR, some smaller problems were run through to an integer solution which proved to local managers that the model could lead to an acceptable solution. A number of heuristics were devised to assist BR to proceed from the relaxed LP to an estimate not only of the numbers of shifts, but their general forms. As good estimates were obtained, so BR expected ever better fits from the model, which after appropriate adjustments always predicted correctly the number of shifts in cases where the solution was known. The model was deemed to be successful, and was used in-house by BR in the context of a major restructuring exercise [29]. In 1994, a research grant was obtained to allow us to develop a new system to schedule train drivers. Although the problems are notionally the same, train driver scheduling, at least in the UK, is much more complicated than bus driver scheduling. Bus driver scheduling is normally concerned with drivers from a single depot who are restricted to buses from that depot. Train drivers work on trains from many different depots, although drivers from any individual depot are restricted to certain lengths of track with which they are acquainted. Any individual length of track is normally known to several depots, so that it is not possible to sub- divide the problem into specific depots. Similarly, drivers from any depot are only qualified to drive certain types of train. In most urban situations, bus drivers can be given a fixed time allowance to move from a point where they leave one bus to a point where they start to drive another bus. This allowance may provide simply for walking time, or may include an estimate for travelling as a passenger on a frequent bus service. In contrast, train drivers often have to travel as passengers on relatively infrequent services, perhaps even changing train en-route. A train driver scheduling system therefore must take into account the specific times of any trains which may be used for passenger travel. The possibilities for passenger travel generally include all the trains in the network being scheduled, as well as some trains on other networks, and buses or taxis. Rail stations normally have at

6 least two platforms, often many more, and different allowances have to be given for walking between different pairs of platforms. Allowances must also be given for walking between different areas of a train yard. Usually there are many more points at which drivers may be changed on a rail network than on a bus network. It has also been noted that while bus drivers normally work on no more than two or three different buses in the course of a shift, train drivers may work on up to about six different train sets. The above considerations make train driver scheduling very complicated compared to us driver scheduling. Problems are larger in several ways, and it is no longer possible to assume that an integer solution may be found with the same number of shifts as are indicated by the relaxed LP, due to the additional constraints relating to the types of work that may be undertaken by specific depots. By the time this research on rail driver scheduling started, we had lost control of the IMPACS programs. It was therefore decided to build a new system taking advantage of the broad methods of IMPACS, but using new specifically developed LP codes, and a range of new methods to guide the ILP search. It was no longer possible to exclude some relief opportunities in advance, and the number of potential shifts generated for presentation to the LP process became very large. (In some cases well in excess of a million shifts have been generated.) A column generation process was developed so that the LP started with a relatively small number of shifts, while others were progressively introduced from the generated set. As the optimisation progressed, selected non-basic shifts were discarded from consideration. This process was carried out in such a way that optimality of the relaxed solution was guaranteed. A number of control techniques were developed to guide the search of the branch and bound tree, while the user was given some control of the target number of shifts sought in the integer solution. The fully flexible system is described in [5,26]. The evolving TRACS II system (now simply TRACS) was first used in 1995-96 to assist British Rail in developing new strategies in preparation for privatisation. About half of the twenty-five new operating units employed it to determine new driver schedules in the face of ranges of possible new train schedules and new labour agreements. In each case, the first task was to produce driver schedules for the existing conditions, so that the TRACS results could be compared with existing schedules, in order to satisfy management that the new tool could produce effective schedules. In this way, management was prepared to accept the validity of the revised schedules, and of the comparisons between different scenarios. Some of these exercises are described in [6]. The largest problem tackled during this phase involved fifteen driver depots and over 400 daily shifts; TRACS indicated savings of between 5% and 10% in shift numbers. During the years since 1996, TRACS has been used for several different train operators, with increasing sophistication in the algorithms and in the user-friendly data structures and interfaces. In the most recent example, a train company has used the system in-house over the winter of 2003-4 to evolve new schedules to assist the bidding process for a new franchise.

7 Experiences (1960-2000+)

Some information has been given above on experiences with a number of bus and train operators. Here we look particularly at practical aspects of dealing with transport operators, and in working on such problems within a university environment. When this research was started, computers were very new, and were understood by very few people within the transport industry. A general view was: “Computers can do everything perfectly, but not as well as us”. It was very difficult to get information from transport schedulers, partly because of fears of their own position becoming redundant, partly because the computer was believed to be able to calculate the information for itself, partly because staff were reluctant to flood the computer with too much information at once, and partly – contradictorily – because the volume of information perceived to be necessary was enormous. Some examples follow.

7.1 British Railways (1960’s)

The first project with British Railways involved the scheduling of freight locomotives working around the northern edges of London. Various sections of the tracks were shared with a number of other freight and

7 passenger services, most notably the main line passenger services from a major London terminal (Euston). At an early meeting we were assured that in order to schedule light runs of locomotives it would be necessary to take account of all other train movements over the common tracks. This nearly sank the project before it started, as the data required to plot all the conflicting trains would have been far in excess of the computer’s capacity, even if it had been possible to agree a suitable method of gathering and presenting it. The railway staff seemed to delight in explaining the various complexities. After some thought, we asked the question: “If we wished to schedule some light running between specific points at a particular time, how would you determine whether this was feasible?” We were immediately told that it would always be possible to find a path for a light engine working within two or three minutes of the desired time, and the schedules for freight trains were never so precise that a difference of two or three minutes would matter. We therefore decided to adopt the line that anything we suggested within the constraints given would be acceptable. As OR people we felt that consideration should be given to adjusting the times of trains if it could be shown that this would save a locomotive. It was explained to us that this would be impossible (the actual words used were somewhat stronger); the trains all ran at times which had been unchanged for many years, and were immutable. It will be recalled that the method adopted led to an infeasible solution if no feasible solution were possible with a given number of locomotives. Our process started by seeking a solution with eleven locomotives, and increased this (one at a time) until a feasible solution was found with fourteen, a saving of one locomotive. In view of the supposed immutability of train times, it was with some trepidation that we pointed out that we could have obtained a solution with thirteen locomotives if they had been prepared to retime one train by thirty minutes. Immediately we were given a lecture about the cost of locomotives, and how it was obvious that they would retime a train by thirty minutes to save one locomotive. We then dared to suggest retiming another train by two hours to save another locomotive. This also was accepted, and the British Railways internal report states that three locomotives were withdrawn from service. However, when we tried to publish a claim that we had saved three locomotives, BR refused to accept this; we had saved one locomotive; their retiming had saved a further two! BR used our system in-house for several years. However, it appeared obvious to management that if a working scheduling system could be developed within a mere university, then a much better system could be developed by BR engineers. The process was therefore abandoned by BR when its Pegasus computer became obsolete, and an in-house system was commissioned and developed through many years, but never implemented. This was outlined by Wren [24] with the approval of its developers. BR still did not have a working automatic locomotive scheduling system in use when the organisation was split up in 1994.

7.2 Leeds City Transport (1960’s)

Our first experimental work on bus driver scheduling was with the municipal transport authority in Leeds. Senior management was very supportive, but the schedulers themselves were somewhat suspicious. After struggling for two years we succeeded in producing driver schedules which satisfied the rules we had been given. We were then told that these schedules did not conform to all rules; they had held back some rules initially in order not to make life too difficult for us! Unfortunately, the additional rules invalidated many of the heuristics we had used, and the system had to be redesigned. After another year or so we produced successful schedules for weekday working, and were asked to tackle a holiday Monday. This had no peak working, the number of buses being static from about 0700 to about 1900. By giving meal breaks to some early shifts much earlier than previously, our system was able to construct longer chains of meals, thus reducing the number of shifts by two. The earliest shifts now had only short periods of work before the break, with about four hours after, meaning that shifts had to be paid the minimum allowance of eight hours, despite working for only about six. This was compensated by later shifts having more work, and the total cost being reduced considerably. The schedules manager rejected our solution because, he said, these earliest shifts were inefficient. We appealed to a higher level, who insisted that the computer solution should be adopted on the grounds of overall economy. We subsequently learned that, unknown to higher management, our solution was in fact more expensive to implement because of an obscure labour agreement which insisted that all drivers who would normally be working on a Monday should be paid, and that those who did not have to work should be paid at a higher holiday rate! Another quaint custom revealed during our work in Leeds was that a driver working a “Spreadover” shift (a shift in excess of 9.5 hours, with a break of at least an hour) should be paid for the entire spread minus one hour, and that any idle time in excess of an hour should be paid at 1.5 times the normal rate. The time worked in such

8 a shift could not exceed 8.5 hours. Thus a driver working 0700-1115 and 1445-1900 would be paid for 11 hours (total spread minus one) plus 3.75 hours (2.5 idle x 1.5), totalling 14.75 hours. However, if two hours’ work were removed from the middle of the shift, the cost would be 11 + 6.75, totalling 17.75.

7.3 Yorkshire Traction (early 1970’s)

Yorkshire Traction was a subsidiary of the National Bus Company, and had recently absorbed a smaller private company. The smaller company’s vehicles were moved to garages of Yorkshire Traction, but the work of the two fleets had not been integrated. We carried out a number of bus scheduling exercises for this company during the first half of the 1970’s. The first covered work currently done by 41 double-deck buses in a single garage. A feasible solution was obtained with 39 vehicles, and we presented a 38-bus solution with some infeasibilities. The company accepted the implied retiming, and we then showed them a 37-bus solution. Again the retimings were accepted, and we were asked: “How low can you get?” After several computer runs with successive reductions in vehicles, a 31-bus solution was accepted. This was an exceptional order of saving, partly due to integration of the two vehicle fleets, but mainly due to the company’s close examination of every trip involved in infeasible connections. It transpired that over several years, the company had accepted a number of contracts before the start of the afternoon peak, believing that these could be operated at marginal cost. However, the true peak had gradually moved earlier, and many of these contracts now cost extra vehicles and drivers. Once this was realised, such uneconomical contracts were cancelled. A similar operation, with similar orders of savings, was then carried out on the larger single-deck fleet from the same garage. The company then asked us to undertake similar work at another garage. However, the National board had placed an embargo on research, and would not accept Yorkshire Traction’s argument that this was now a proven method of reducing costs. Once the embargo was lifted nationally, we agreed a plan of work with the company which included developing the system, first to deal with several garages simultaneously, and then to consider several different types of bus. By now the national headquarters was allowing research, but only up to £500, and we had to agree with the company to undertake several projects in succession, each under £500, in order to complete the work.

7.4 Kingston upon Hull Transport (early 1970’s)

This city’s municipal bus undertaking had been impressed by our work with Yorkshire Traction, and asked us to schedule their buses. However, the city council, who had to approve this work, insisted that there was no need to go to a far-off university (Leeds is about 55 miles from Hull). Hull had a perfectly good university who should be asked to do the work. No amount of pleading by the bus manager about the quality of the Leeds expertise would succeed. Eventually I asked my friend, the head of the OR department in the University of Hull, to write to the council asking that my team should be allowed to do the work. Once he had done this, the work was authorised, and we saved seven buses out of 114.

7.5 Teesside Transport (early 1970’s)

Using our heuristic driver scheduling system we produced some schedules for the Teesside municipal authority. Here there was a rule that an agreed standard work time could be exceeded on a certain small percentage of shifts. It was difficult for our heuristics to deal well with this, and we therefore decided in a first approach to forbid such violations of the rule. Despite this, our schedules proved to be more economical than the existing ones. At this time relations between the drivers’ union and management were difficult throughout the UK, and drivers were very suspicious of computer-produced schedules. On the day that the general manager received our new schedule and was contemplating how he would get the union to accept it, the union chief negotiator stormed into his office and demanded that the standard work time should never be exceeded in future. The manager happily showed him our computer print-out, which he accepted!

7.6 Dublin Transport (mid 1970’s)

It was difficult to get this organisation to specify the rules governing an acceptable schedule. Initially they would not tell us how many drivers they used on the work covered in our pilot study, and we had to produce our

9 own schedule using rules given us by telephone in advance of our visit to Ireland. Once we were in their offices we were told that our schedule used more drivers than their own. We then went over the rules in detail with the schedules manager. One such rule was that the maximum amount of continuous work could not exceed 4 hours 30 minutes, and we pressed the manager on this. “Oh no, 4:30 is the absolute maximum; in fact we hardly ever go above 4:30”, he said. Once I had recovered from my shock, I pressed him to tell me what the true maximum was. He summoned his deputy, who thought for a long time. “Well”, he said, “You could safely use 4:45. Yes indeed, 4:45 is truly the greatest that would be accepted. You see, we would only once or twice exceed this.” I agreed that we would produce new schedules, but I insisted that I should be given a copy of their own schedules first, so that I could check that the rules to which we were working were never violated. I discovered that one of their shifts had some continuous working of 5:08, and we set this as the maximum, penalising in our optimisation any shifts with continuous work over 4:30. Dublin was one of our few failures with our heuristic system. Although bus services there started at around 5.30 a.m., as in the United Kingdom, the morning peak was between 9 and 10, whereas in the UK it was between 8 and 9. The heuristic we had designed was built around the notion that most shifts would have their breaks after the peak, whereas in Dublin most had to have a break before the peak had finished. We tried a number of approaches to deal with this, but failed to get a satisfactory solution within the three months allocated to the project.

7.7 West Yorkshire Passenger Transport (late 1970’s)

We had very good relations with the West Yorkshire Executive, which had in 1978 absorbed the municipal services of Leeds, Bradford, Halifax and Huddersfield. Our TASC bus scheduling system had been used to design timetables and schedules for proposed new route systems, and had been extended to provide an estimate of the number of drivers involved. The TRACS (heuristic) driver scheduling system had been used in projects with the drivers’ union designed to determine new sets of mutually beneficial rules. We entered negotiations to supply to the Executive a licence for TASC and TRACS. The directors of the Executive were supportive, but the systems would ultimately have to be run on the Executive’s mainframe computer, by the Executive’s own computer staff. It would have been easy to train the schedulers to use the systems, and they were keen to get to work. However, it became evident that the computer staff, whose experience lay in the running of standard data processing applications, was suspicious of a system which they did not understand. A series of obstacles was placed in our way:- How could we guarantee optimality? What would they do if management wanted an extension to the system? What would be the priorities between the demands of the financial officers needing a new payroll and the planners needing a new schedule? The Executive’s headquarters was about ten miles from the University of Leeds, and we offered a number of solutions: • We could run the systems in the university (unacceptable to the computer staff who would lose face); • We could provide a help desk (what if we weren’t there?); • We could train the computer staff in the systems (heaven help us!); • We could allocate one of our staff to work in the Executive’s offices (interference); • We could train their schedulers to operate the systems on their computers (unqualified people couldn’t use their computers). Negotiations dragged on until the sympathetic directors retired, and the leading scheduler moved in frustration to another organisation.

7.8 The 1980’s and 1990’s

The 1980’s were good years. We teamed up with Wootton Jeffreys Consultants Ltd, and together we developed the scheduling systems, and installed them in around thirty British bus systems, and some in Australia, South Africa and Hong Kong. Throughout this period, the university led the research, while Wootton Jeffreys provided add-on systems (input and output), and we worked together in the marketing and adaptation of the

10 systems to new circumstances. Wootton Jeffreys paid royalties to the university, which we used to pay staff salaries, funding new developments. Independent of Wootton Jeffreys, we developed the IMPACS driver scheduling system, supplying it to London Transport in 1984 and Greater Manchester Transport in 1985, in which year it was added to the Wootton Jeffreys portfolio, so that in the second half of the 1980’s and early 1990’s this mathematical programming based system became the standard British driver scheduling system. (Although the HASTUS system from Montreal was adopted by three British operators.) From 1970 we had financed a small research unit in the university entirely from our earnings, but relationships with the university authorities were not easy. At that time industrial contracts were seen as being contrary to the university’s research ethos. While our work was praised on occasion, our practice of making profits on individual projects, so as to fund new research, was seen as bad practice. Our arrangements with Wootton Jeffreys were based for ten years on annual exchanges of letters which ensured that the university retained ownership of the scheduling algorithms and that we had a guaranteed income as long as the systems continued to be marketed. However in 1991, the university’s marketing arm insisted that new contracts should be drawn up. These gave us joint ownership of the entire BUSMAN scheduling system, but lost us sole ownership of the core software. Within a year, Wootton Jeffreys had sold their interest to the Hoskyns group who unilaterally stopped paying our royalties in 1993. BUSMAN subsequently fell under the control of a succession of organisations, although I do not believe the scheduling algorithms have been developed since 1992. As has previously been stated, we started to develop new scheduling software from 1994, and these systems are in use by a number of bus and rail companies.

7.9 London Underground (1990’s onwards)

From the 1980’s onwards we had a good relationship with the scheduling staff of London Underground, and had demonstrated to them successive versions of the IMPACS driver scheduling program. When we started in 1994 to develop the new TRACS driver scheduling system for train drivers, we chose London Underground as one of the test beds. Our first exercise, in 1995, was on the Piccadilly Line, and is described in [6]. The existing schedule had 2500 relief opportunities, and used 169 daily shifts from four driver depots. At that time this exceeded the capacity of our embryonic system, and we therefore subdivided the train sets into four groups of decreasing size, dependent on their starting and finishing depots. The largest group was tackled first; the most efficient 70% of shifts was retained for the final schedule, while the work contained in the other 30% was added to the second sub-problem. Similarly, 30% of shifts from the second solution were cascaded down to the third sub-problem, and so on. Finally, a simple exchange heuristic was used to make marginal improvements over the whole resultant schedule. Our solution saving two shifts was accepted by the schedules management. In this large organisation there were several management levels above the schedules manager. At about the same time as we were undertaking the above project, senior management commissioned a large international organisation to prepare a plan for the computerisation of schedules. That organisation interviewed the schedulers to try to determine the rules they used in their work. A specification was then drawn up, without reference to us, of a step by step process for constructing driver schedules, and this was used as the basis of an invitation to tender. It should be said at this stage that the schedulers knew that this process would be unworkable, but they were overruled. Initially we were ruled out of the bidding process, as we were judged to be too small an outfit. We then teamed up with one of the largest UK companies to prepare a bid, and we were allowed to make a presentation. We were then disqualified because our large partners were not among the initial qualified bidders. At this stage we held discussions with one of the shortlisted companies, a large software supplier. They had no knowledge of scheduling, and we offered to supply scheduling algorithms, for a few hundred thousand pounds, to be embedded in their overall system. They thought our price was extortionate, given that they required several million pounds for the overall project. The contract was awarded to the organisation who had drawn up the specification. I was subsequently told that one reason for our initial exclusion was that I had said that it would take us a year to incorporate all the requirements in the ITT, while the successful bidder undertook to complete the project within six months. Five years later, the successful bidder had not succeeded in producing acceptable schedules, despite the expenditure

11 of several million pounds. In the meantime we continued to demonstrate our evolving system, which by this time did not require decomposition as above. We succeeded in producing schedules for the most complicated of situations, and these were accepted by the schedulers as being more efficient than the existing schedules. Some of these demonstrations were undertaken at the request of senior management, and at one time we really believed that our systems would be accepted in place of the existing developer. However, the existing developer was always given one more chance to satisfy London Underground.

7.10 General remarks

The above experience with London Underground has been set out in some detail. It is not untypical. Decisions about scheduling software are made by senior management who have no experience of scheduling. They are often made without regard to quality of final result, and large sums are lost as a consequence. Most computer systems commissioned by finance directors are required to produce a specific result. A payroll system ensures that every employee receives the correct payment, taking into account salary level, hours worked, taxes and other deductions. If it does not do this, it is not acceptable. A decision to purchase can then be based on such things as price, ease of use, any additional features, and a judgement of the supplier’s capability to deliver and to support the installation. A scheduling system does not produce the correct schedule; there is no such thing. Even when it is possible to quantify subjective views so that one schedule may be judged to be better than another, it is not possible, except in very simple situations, to guarantee that an optimal schedule will be found by any driver scheduling system. It is frequently claimed that the use of a computer will guarantee optimality. This is not true. Driver scheduling can be proved to be NP-hard. This means that it is one of the most complex problems known to mathematicians, that the time taken to find an optimal solution rises exponentially with the size of problem, and that provably optimal solutions can only be obtained for very small problems. Scheduling systems therefore are designed to try to get as close to the theoretical optimum as possible. Many different methods are used to try to achieve this, and some succeed better than others. The operational costs of schedules produced by different suppliers’ systems can vary enormously, yet many purchasers have not taken these differences into account when choosing a system. It is unfortunately true that there have been many unsuccessful scheduling attempts, and that large amounts of money have been squandered on these. In another case known to the author, a large multi-national company with no experience of driver scheduling was commissioned to develop from scratch a train driver scheduling system. They used constraint programming, a technique well-suited to some other scheduling problems. The system was abandoned after a large investment, and I am happy to say that the train company concerned has now successfully used the TRACS system. There are great variations in the capabilities of currently or recently marketed scheduling systems. Some do little more than build up schedules one step at a time; the first few shifts to be formed are good, and can be shown to potential users; later pieces of the jig-saw fit badly, and the whole is very inefficient. Other systems have increasing degrees of sophistication; none guarantees an optimal solution. The best systems use combinations of mathematical programming and heuristics. Despite this great range of suitability, few purchasers properly compare competing systems. In the past fifteen years in the UK, only First has done so. How then should a choice be made? Comparing systems is expensive for both supplier and purchaser, and although very substantial savings can be made by using good systems, potential purchasers are unwilling to invest significant sums in tests, so that suppliers can seldom afford to take part. Any purchaser should demand evidence of well-satisfied customers. No potential supplier should be chosen who has not a proven record of success in the relevant field of driver scheduling. However, scheduling conditions vary between countries; for example, American bus driver scheduling rules are generally simpler than those in the UK, so a system that works well in America may not work in other countries.

12 8 Outstanding problems

There is not space here to present possible solutions to those areas of scheduling in which research is still taking place. Clearly, all existing systems are capable of improvement. We distinguish between improvements which provide better solutions methods for problems which are already solved, and research to tackle new or partly solved problems. Two specific problems which have been tackled by adaptations of our TRACS scheduling software are the cases where handovers between drivers may take place within time windows defined by a train’s standing time at a station, and where “minimal change” schedules have to be provided. The latter case is often presented by current users, but is often ill-defined. It is intended to resolve situations where a standard schedule is known to require changes on one or more specific days, for example due to engineering work closing a section of track. It is desirable that most of the schedule should be unaltered, but the degree of sub-optimality which may be accepted is seldom known. One possibility is to undertake two computer runs; in one, freedom is given to ignore the existing schedule, so that the solution should be near-optimal; in the other, specific costs may be assigned to any shift which deviates from the standard schedule; the scheduler may accept the second solution if its true cost is not significantly higher than the first.

9 Acknowledgements

The work described here has been carried out by the author working with a team of colleagues. The composition of the team has of course varied throughout these forty years, and all members cannot be acknowledged here. I would particularly like to thank those who are carrying the work forward into the twenty- first century: Les Proll, Margaret Parker, Raymond Kwan, Ann Kwan and Sarah Fores. Others who have played very significant roles in the past are Barbara Smith, Trevor Hartley, Philip Manington, Anna Weaver and Barbara Manington. A successful collaboration with Wootton Jeffreys over more than ten years is also acknowledged, as is the help and enthusiasm of many schedulers and others in the bus and rail industries.

9 References

1 Chamberlain, M.P. and Wren, A., Developments and recent experience with BUSMAN and BUSMAN II. In Desrochers, M. and Rousseau, J.-M. (eds.), Computer-aided transit scheduling - 2, Springer, Berlin, pp.1- 15, 1992. 2 Daduna, J.R., Branco, I. and Pinto Paixao, J.M. (eds.), Computer-aided transit scheduling, Springer, Berlin, 1995. 3 Daduna, J.R. and Wren, A (eds.), Computer-aided transit scheduling, Springer, Berlin, 1988. 4 Desrochers, M. and Rousseau, J-M (eds.), Computer-aided transit scheduling, Spriniger, Berlin, 1992. 5 Fores, S., Proll, L. and Wren, A. TRACS II: A hybrid IP/heuristic driver scheduling system for public transport. Journal of the Operational Research Society, vol.53, pp.1093-1100, 2002. 6 Kwan, A.S.K., Kwan, R.S.K., Parker, M.E. and Wren, A., Producing train driver schedules under differing operating strategies. In Wilson, N.H.M. (ed.), Computer-Aided Transit Scheduling, pp.129-154, Springer- Verlag, 1999. 7 Kwan, R.S.K. and Rahin, M..A., Object oriented bus vehicle scheduling – the BOOST system. In Wilson, N.H.M. (ed.), Computer-aided transit scheduling, Springer, Berlin, pp.177-191, 1999. 8 Leeds University Computing Laboratory (1960) The solution of large scale scheduling problems by computers; an appreciation of basic principles and future possibilities. 9 Manington, B. and Wren, A., A general computer method for bus crew scheduling. In Preprints of the workshop on automated techniques for scheduling of vehicle operators for urban public transportation services, Chicago, 1975. 10 Manington, P.D. and Wren, A., Experiences with a bus scheduling algorithm which saves vehicles. In Preprints of the workshop on automated techniques for scheduling of vehicle operators for urban public transportation services, Chicago, 1975. 11 Parker, M.E. and Smith, B.M., Two approaches to computer crew scheduling, In Wren, A. (ed.), Computer scheduling of public transport, North-Holland, Amsterdam, pp.193-221, 1981. 12 Preprints of the workshop on automated techniques for scheduling of vehicle operators for urban public transportation services, Chicago, 1975

13 13 Rousseau, J-M (ed.), Computer scheduling of public transport 2, North-Holland, Amsterdam, 1985. 14 Smith, B.M., Bus crew scheduling using mathematical programming, University of Leeds PhD thesis, 1986. 15 Smith, B.M., IMPACS - a bus crew scheduling system using linear programming, Math Prog. 42, 181-187. 1988. 16 Smith, B.M. and Wren, A., A bus crew scheduling system using a set covering formulation. Transportation Research, vol.22A, pp. 97-108, 1988. 17 Smith, B.M. and Wren, A., VAMPIRES and TASC: two successfully applied bus scheduling programs. In Wren, A. (ed.) Computer scheduling of public transport, North-Holland, Amsterdam, pp.97-124, 1981. 18 Stern, H.I. and Ceder, A., An improved lower bound to the minimum fleet size problem, Transpn.Sci. 17, 471-477, 1983. 19 Voss, S, and Daduna, J.R. (eds.) Computer-aided scheduling of public transport, Springer, Berlin, 2001. 20 Wilson, N.H.M. (ed.), Computer-aided transit scheduling, Springer, Berlin, 1999. 21 Wolfenden, K. and Wren, A., Locomotive scheduling by computer. Proc. British Joint Computer Conference, pp. 31-37, IEE Conference Publication no. 19, London, 1966. 22 Wren, A., Bus scheduling: an interactive computer method. Transportation Planning and Technology, vol.1, pp. 115-122, 1972. 23 Wren, A., Computers in transport planning and operation, Ian Allan, London, pp.85-89, 1971. 24 Wren, A., ibid, pp.103-106, 1971. 25 Wren, A. (ed.), Computer scheduling of public transport, North-Holland, Amsterdam, 1981. 26 Wren, A., Fores, S., Kwan, A., Kwan, R. Parker, M and Proll, L. A flexible system for scheduling drivers. Journal of Scheduling vol.6, pp.437-455, 2003. 27 Wren, A. and Holliday, A., Computer scheduling of vehicles from one or more depots to a number of delivery points. OR Quarterly, vol.23, pp. 333-344, 1972. 28 Wren, A., and Kwan, R.S.K., Installing an Urban Transport Scheduling System. Journal of Scheduling, vol. 2, pp.3-17, 1999. 29 Wren, A., Kwan, R.S.K. and Parker, M.E., Scheduling of rail driver duties. In Murthy, T.K.S., Mellitt, B., Brebbia, C.A., Sciutto, G. and Sone, S. (eds.), Computers in railways – IV, vol. 2, pp.81-89, 1994. 30 Wren, A. and Rousseau, J.-M., Bus driver scheduling – an overview. In Daduna, J.R., Branco, I. and Paixao, J.M.P. (eds.) Computer-aided transit scheduling, Springer, Berlin, pp.173-187, 1995.