Bus Scheduling with Trip Coordination and Complex Constraints

University of Leeds

SCHOOL OF COMPUTER STUDIES RESEARCH REPORT SERIES Report 93.23

Bus Scheduling with Trip Coordination and Complex Constraints

by Raymond S.K. Kwan and Mohammad A. Rahin Division of Operational Research & Information Systems

June 1993

Presented at the VIth International Workshop on Computer Aided Scheduling of Public Transport, Lisbon, Portugal, 6-9 July 1993.

1

ABSTRACT At the stage of compiling bus schedules, schedulers usually can still manoeuvre the trip timings to a certain extent. Sometimes, even options in the route structures might still be open. Most schedulers, especially in the highly competitive U.K. bus industry, would strive to explore many possibilities in order to derive the best schedules in terms of efficiency, competitiveness, quality of service to the public, and operational objectives. This paper reports on recent researches in producing complementary modules to the well-established bus scheduling system BUSPLAN to meet the schedulers/planners' growing needs. These include interactive and semi-automatic tools for co-ordinating trip timings, and heuristics for handling multi-vehicletype constraints. Earlier work on the co-ordination of trip timings had already been reported in the Fourth Workshop in Hamburg. Recent research has extended this to cover full-day operations rather than just over periods of steady state operations. This encompasses smooth transitions between steady state periods and less regular services at the beginning and end of day. Dead running between terminals also becomes an important consideration. Since deregulation in 1986, there is a resurgence in multi-vehicle-type constraints in the U.K. bus industry. These constraints are sometimes complicated by the use of more than one depot. VAMPIRES, which was developed in the 1970s and whose algorithm now forms the basis of BUSPLAN, included heuristics for these problems. This paper describes recent improvement updates to these heuristics. Research in improving the VAMPIRES algorithm through objectoriented modelling is also outlined.

1.

INTRODUCTION

Research in bus scheduling at Leeds has evolved since the late 1960s into the present BUSPLAN component of the BUSMAN suite [WREN and CHAMBERLAIN 88], catering for the changing needs of the bus industry, as well as taking advantage of new computing technologies. Recent research includes: integrating bus scheduling with some planning functions; a new approach to vehicle type constraints; and an object-oriented model. Even aided by the computer, schedulers still have to perform much trial-and-error. This is because scheduling packages only allow one fixed set of timings and route structure at a time. Many separate runs of the scheduling program have to be performed if options and flexibility available are to be explored. What would be desirable are advisory and evaluative tools that support the planning dimension by quickly predicting consequences on scheduling without actually performing a complete schedule compilation, which is time consuming. To support planning and scheduling under a diversity of service quality objectives and operational objectives, a coherent framework for integrating the many tools into an effective system is therefore being developed. One important planning/scheduling activity supported by the integrated framework is the coordination of trip timings on overlapped route sections. Earlier work [KWAN 88] concentrated on periods of steady state operation. Recent research has extended this to cover

2

the whole day, which includes irregular services during the peaks and at the beginning and end of day. The VAMPIRES algorithm [SMITH and WREN 81] forms the backbone of BUSPLAN. This algorithm is a heuristic that performs a huge number of trials of swapping between pairs of bus links. A bus link connects two successive trips served by a bus. In a bus link swap, the four trips involved are re-linked in the alternative way. The decision of making a swap depends on whether there will be a reduction in the total costs associated with the pair of bus links after the swap. Since deregulation in 1986, there is a resurgence in multi-vehicle-type constraints in the U.K. bus industry. The original VAMPIRES algorithm initially ignores vehicle type constraints. Costs reflecting vehicle type preferences are then assigned to the bus-work in the schedule. Such costs are minimised in another phase of bus link swapping iterations. This sometimes results in bus-work interspersed with trips of widely different, or even in conflict, vehicle type preferences. This problem was once tackled as a sub-problem solved mathematically during the swapping iterations; however, the amount of computation required increased tremendously. A new approach applies the basic heuristic, in parallel, to groups of trips that have similar vehicle type preferences. Migration of trips between groups would be tried when the target number of buses for individual groups cannot be met feasibly. The new approach tends to result in more uniform bus-work in terms of vehicle type preferences, and offers more flexibility in the final vehicle type allocation. The current VAMPIRES algorithm focuses on improvement of costs mainly associated with bus links. To handle complex constraints such as multi-vehicle-types and multi-garages, sophisticated heuristics involving costs associated with entire chains of bus-work would be needed. A fresh look at modelling the VAMPIRES algorithm following the object-oriented approach is being pursued. The major objective is to achieve a more easily extensible system, as more complex heuristic strategies are being incorporated.

2.

INTERACTIVE FRAMEWORK FOR PLANNING/SCHEDULING

The main objectives in planning and scheduling are to provide the best quality service using the minimum number of buses. The key variables are trip departure times, which dictate whether a bus will be at the right time and place from the service quality point of view; and whether the trips can be linked efficiently from the scheduling point of view. Retiming a departure would change the inter-relationship of that service with others all along its route, and might cause large-scale revision of bus links in chain reactions. The consequence of retiming several departures at the same time is obviously complex. To devise a scheduling algorithm that can automatically find "the best" combination of departure times would be very difficult, if not impossible. First of all, there might not be a single "best" solution. The main objectives are potentially in conflict, and there might not be any well-defined criteria for apportioning weightings. The service quality objectives depend much on local requirements that would be impossible to generalise. Secondly, the ranges of flexibility and options are often ill-defined. Sometimes, they may be inter-dependent. Some options might be viable only if some others are in effect. A comprehensive specification of flexibilities, options, and local objectives at the outset is unlikely to be achievable. Finally,

3

allowing trip departure times to be variable would make it computationally impractical to solve except for trivially small problems. The other major consideration during the planning and scheduling process is variability in the route network design. For example, alternative ways of joining branches to a trunk section in forming a bus route might at first seem equally feasible. This would be even harder to generalise and automate. Active participation of the scheduler in a system for planning and scheduling is therefore essential. Instead of one single automatic process accomplishing everything, specialised and fast tools should be provided for the scheduler to utilise where and when appropriate in his course of investigation. Fig.1 is a schematic overview of an interactive framework.

Fig. 1 Actions flow diagram of an interactive framework In this model the planning objectives are expressed by some well-defined targets, eg. a joint headway of 10 minutes between Services #1 and #2 on High Street. The computer helps by suggesting some targets using default rules, but the scheduler is able to revise the targets over and over again. The set of targets implies a search space in which solutions are sought by the computer. The process will be specialised dependent on the planning task being tackled, and it will have to be fast in an interactive environment. The target-oriented search process takes an advisory role. It typically derives a range of, rather than just one, solutions in each run. With revised targets and further searches, probable solutions are accumulated. The aim is to focus on refined ranges of possibilities, stopping short at where planning/scheduling experience and local knowledge is needed to go further. Auxillary tools are available for analysing the probable solutions. Such tools are simple but

4

specific, often each tool only supports analysis under a single criterion. The analysis is mainly evaluative, eg. to rank some probable solutions by amount of slack time at a certain terminal. Provided there is a good indexing system to correlate sets of targets, network structures, solutions and analysis information; the scheduler would be able to assess and compare many options quickly, and in full control of steering the course of investigation according to intermediate findings. This interactive framework has been successfully applied to the co-ordination of services on overlapped route sections. Research is also being undertaken to apply it to the co-ordination of services where routes cross, and where generally passengers might change to another bus or another mode of public transport.

3.

SERVICE CO-ORDINATION ON OVERLAPPED ROUTE SECTIONS

Urban bus networks are often characterised by major route sections each covered by many different services. An intuitive objective is to ensure that buses arrive at the overlapped route sections at even intervals (joint headways), and that the minimum number of buses is used. This might be achieved either by juggling the trip timings or by varying the route network. The objective might not always be achievable perfectly, in which case the scheduler would have to establish appropriate weights and priorities for the factors in conflict. A system called HINT [KWAN 88] employing the interactive framework described in section 2 above has been developed for assisting in this process. In the following, recent research to extend HINT is discussed. HINT was first designed to assist in the co-ordination of regular services, for which smooth joint headways could be sustained for significant lengths of time. The co-ordinated services form a cyclic pattern. Cyclic dead running, if present, usually causes inefficiency and is therefore disallowed in HINT. However, this rationale might not hold when adjacent terminals are involved. Cycles of only very short dead runnings might be compensated by much larger savings in vehicle slack time. HINT uses a heuristic that retimes the trips and at the same time deduces the number of buses required from the cyclic schedule linkages. The heuristic attempts to improve from a crude starting solution by first systematically tighten the schedule linkages regardless of whether there is enough time between arrivals and departures. Further adjustments of the trip timings are tried in order to remove any infeasibiltiy. In the extension to HINT, dead running is considered for pairs of terminals that are within a short journey apart, eg. up to three minutes. The situation of having to schedule for groups of more than two adjacent terminals is rare and therefore will not be catered for unless it is encountered in practice in future. The adapted heuristic still works under similar principles as before. The tightening of linkages is still performed separately at individual terminals. However, swapping of linkages with those at an adjacent terminal will be considered when trip retiming alone fails to remove the infeasibility arisen at the terminal concerned. During a swapping trial, timings of the linkages may also be juggled to facilitate a successful swap.

5

There are two main issues in extending HINT to also cover irregular services during the peaks and at the beginning and end of day: the smoothing of intervals of the irregular services either on an individual basis or on a joint basis; and the prediction of the number of buses required for the whole day. In a whole day operation, irregular services may be in the form of either extra trips superimposed on a long period of regular services; or trips filling up the transitional gaps around periods of regular services. In both cases, it is not difficult to smooth out the service intervals. The important thing is to enable the scheduler to express the situation effectively. For example, some irregular trips might be strictly defined and not allowed to be retimed; some might be in terms of the effective number of buses between two specified times; some might be constrained by lower/upper bounds on the level of service frequency. Graphic visualisation of the distribution of both the regular and the irregular trips in specific perspectives of the bus network would be very useful. Predicting the number of buses required is a more difficult issue because the process has to be fast under the interactive framework. A fast process is achievable for entirely regular services because only one of the repeating cycles of events has to be considered. For the whole day situation, two approaches are being pursued. The first approach uses the estimation process of BUSPLAN, which computes a target number of buses before any actual scheduling. That estimation process is fast and results in a very good lower bound. However, even though it is a very good estimate, more buses might actually be required. In the second approach, the cyclic partial schedules for the stable periods are integrated together with the other irregular trips to form a complete schedule. This involves reformation of schedule linkages at the fringes of the cyclic partial schedules. While this might give an accurate prediction of number of buses required, the process is slower and it might be impractical if the stable periods are not long enough or the proportion of irregular trips is large. The current strategy is to always provide the scheduler with the estimate yielded by the first approach. Prediction using the second approach would also be provided if a solution could be found within a pre-set response time limit. It must be stressed that the main objective of HINT is to assist the scheduler to narrow down the large number of planning options quickly, and therefore absolute accuracy in predicting schedule efficiency is not essential.

4.

SCHEDULING WITH MULTI-VEHICLE-TYPES

In the privatised U.K. bus industry, fleets of mixed vehicle types are common. Bus routes are tailored to capture as many passengers as possible at just the right levels of service frequencies. Some routes meander around housing estates and are therefore unsuitable to use large vehicles. Some routes are shuttle services that small capacity vehicles would be adequate. Against the vehicle types available is a scale of preference for each bus service. On an extreme end, a vehicle type is banned from being assigned. A bus service can use any of the vehicle types available unless it is specifically banned. However, preferences may be expressed on a numerical scale of from 1 (least suitable) to 9 (most suitable). For example, Table 1 shows that Service #1 can only use a double deck vehicle, and Service #2 can use either a small or a large minibus but has a preference for a small one.

6

Vehicle Type

Vehicle Type Preference Service #1

Service #2

Service #3

Double deck

9

BANNED

5

Coach

BANNED

BANNED

2

Small minibus

BANNED

9

BANNED

Large minibus

BANNED

2

9

Table 1. Example vehicle type preferences Since many bus services have the same vehicle type preferences, they are coded for repeated use. For example, in Table 1, the vehicle type preference columns may be coded as A, B and C respectively so that the code A may be specified for another Service #x if it has the same vehicle type preference as Service #1. Let us call the vehicle type preference codes Pcodes. Pcodes also serve the purpose of grouping bus trips during scheduling. Let us call such groups Vgroups, which are identified by their corresponding Pcodes. The use of Vgroups departs from the original VAMPIRES algorithm. The significant difference is that bus-work will now be assigned Pcodes instead of straight vehicle types throughout the scheduling process. One advantage is that actual assignment of vehicle types is left to the very end, so that there would be flexibility for matching the vehicles required to the available numbers for each vehicle type in the fleet. Following the spirit of the VAMPIRES algorithm, target numbers of buses are computed for individual Vgroups. An overall target without vehicle type consideration is also computed for reference. It is likely that the total of the Vgroup targets will exceed the overall target without vehicle types. For example, in Table 2 the scheduler may override the computed target for Vgroup C down to 11 buses to lower the total. Vgroup

A

B

C

Total

Estimated target number of buses

7

8

13

28

Estimated overall target without vehicle type consideration

26

Table 2. Example of computed target numbers of buses required After target numbers of buses are fixed by the scheduler, the basic VAMPIRES algorithm is applied to each Vgroup separately. If a feasible solution is found for each Vgroup, we have an overall feasible solution. The assignment of actual vehicle types to bus-work could be performed interactively, or automatically using some simple rules given the distribution of vehicle types in the fleet available. The system may also, under the scheduler's discretion, attempt reducing the cost of the schedule by allowing bus trips to migrate between Vgroups. This will be discussed later. If no feasible solution could be found for some Vgroup(s) with the target numbers of buses, the scheduler has a few options. The system could be asked to consider migration of trips between Vgroups. Or the scheduler might make some adjustments to the trips that caused the 7

infeasibility. The ability to pinpoint critical trips causing infeasibility has been a very useful feature of the VAMPIRES algorithm. These two options would normally be tried first. The last resort would be to raise the target(s). Before any movement of bus trips between Vgroups, each bus-work would have inherited the Pcode from its chain of bus trips. As a result of swapping bus trips between two chains of buswork of different Pcodes, the reformed bus-work would have more restricted vehicle type preferences. A reformed bus-work will retain the Pcode, and the corresponding Vgroup identity, of the majority of bus trips in it. However, it will be flagged and be assigned an additional effective Pcode representing the more restricted vehicle type preference. A new effective vehicle type preference is the resultant of two different preferences, signified by two different Pcodes, computed by maintaining all the banned status and taking averages weighted by number of bus trips for the rest. For example, using Table 1 suppose a bus-work consists of 10 trips of Service #3 and 4 trips of Service #2; large minibus will have a weighted averaged preference value of (10x9 + 4x2) / (10+4) = 7, and all other types will be banned. A bus link swap will be prevented if it would result in banning all vehicle types for some bus-work. Let us consider the case of attempting to remove time infeasibility by swapping bus links between Vgroups illustrated by Fig.2.

Fig. 2 Swapping bus links between Vgroups In Fig.2 the solid cross indicates that the link between trip a and trip b is time infeasible because t 2 ≤ t1 + D(p1 , p2 ) where t denotes time, p denotes location point, and D is a function returning the time required for a bus to get from the first point to the second. The dotted arrows indicate a possible swap, and hence migration of trips between the two Vgroups, of bus links. Time infeasibility is removed if t 4 ≥ t1 + D( p1 , p4 ) and t 2 ≥ t 3 + D( p2 , p3 ). The relative locations of arrivals and departures are obviously significant. In general, for a trip a in the situation depicted in Fig.2, all trips like d that are time feasible for linking to trip a will be identified as candidates for making a swap. In a swapping trial, if the two chains of bus-work are such that trip c cannot be time feasibly linked to trip b; a sub-

8

process will be invoked to try reforming the bus-work within Vgroup Q to create a bigger time gap before trip d. The bigger time gap increases the chance of trip c being suitable, but a lot depends on the travel time between the arrival and departure points of c and d respectively. In the original VAMPIRES algorithm, a bus link swap effectively switches the tail-ends of two bus-work. But here, we would try all possibilities of making one more swap down the tails of the two bus-work. This may result in switching chunks in the middle of the two chains of buswork instead, and the reformed bus-work may retain more dominant vehicle type preferences. From the above discussion, some options might arise that would remove the time infeasibility of a bus link. The choice is on the option that causes the least severance in restricting vehicle choice, which is measured by the difference in total preference values of the Pcodes in effect before and after the swap(s). Banned vehicle types are given preference values of zero. The larger the difference, the more restrictive vehicle choice would become. Movement of bus trips between Vgroups might be tried because it might reduce dead running and hence the cost of the schedule. In this situation, marginal improvements are sought against trade-offs of worsened vehicle type compatibility. Bus link swapping trials as discussed above are performed similarly except that there is no time infeasibility before the swap, and there is an extra criterion for accepting a swap. The extra criterion is that the saving in dead running must exceed a specified minimum, which could be made proportional to the severance in restricting vehicle choice.

5.

OBJECT-ORIENTED MODELLING

At the heart of the BUSPLAN system is the VAMPIRES algorithm, which was first developed in the early 1970s. The algorithm is described in [SMITH and WREN 81]. The basis of the algorithm is to first form an initial solution using a set target number of buses. Infeasible bus links, with buses going backward in time, are allowed in the initial solution. Pairs of bus links are then tried and swapped iteratively to remove infeasibility and to achieve other forms of improvement where possible. The strategies embedded in the swapping iterations are already complex. New adaptations to the algorithm would make it even more complex. It is therefore important to maintain a well structured and abstracted model. The object-oriented approach is natural and offers advantages of better reusability and extendibility [MYER 89] of concepts modelled. In the following, we shall briefly outline some initial research in improving the VAMPIRES algorithm through object-oriented modelling. In object-oriented modelling, it is typical to start with some fundamental classes of objects in the system. Specialised object classes are derived from the more general ones in a hierarchical fashion. We start with the generalisation that public transport scheduling is a planning process for the deployment of some agents to fulfil a deterministic set of primary activities. The agents will also be involved in auxillary activities that are either essential to facilitate the primary activities or are needed to achieve an efficient schedule. A schedule may be regarded as consisting of a number of activity chains, each of which starts with one or more auxillary activities followed by an alternation of one primary activity and then one or more auxillary activities. The units of one or more auxillary activities are each an activity link.

9

In the context of bus scheduling, buses are the agents; bus trips are the primary activities; buswork are the activity chains; and bus links are the activity links. There are a variety of auxillary activities such as layover, dead-running, and parking. The auxillary activities are variables that govern the efficiency of the resulting schedule. Usefulness of the generalisation above is apparent considering the extension of it to bus crew scheduling: for example, drivers are agents; blocks of bus-work are primary activities; mealbreaks, signing on/off, and travelling between crew relief points are auxillary activities. It might be possible to develop a unified model for both bus and bus crew scheduling in future. However, here we shall just concentrate on bus scheduling. Sub-classes of bus links are derived according to the characteristics due to member auxillary activities. For example, cross terminals link has the following member auxillary activities: post-trip minimum layover, dead run from arrival terminal to the next departure terminal, idle waiting, and pre-trip minimum layover; temporary garage link has a large time gap between arrival and the next departure during which the vehicle is temporarily returned to garage. The detailed classification of bus links coupled with their attributes time feasibility (boolean value) make it relatively easy to design swapping strategies that focus on the appropriate bus links, thereby reducing unnecessary iterations. One of the strengths of object-oriented models is the association of methods, or procedures, with objects. Methods of an object class are inherited by all its derived classes, which are able to make variations pertinent to their particular specialisation. When a method is invoked, only the actions achieved are of interest; how the method is implemented is not of concern to the object requesting the method. For example, in computing the cost of a bus link a method may be invoked to return the dead running time; that part of the model would not be affected by how dead running times are actually implemented: eg. shortest-path based, time of the day dependent, etc. Costing bus links is one of the most important functions in VAMPIRES. The existing algorithm employs a simple costing formula for all bus links. With the object-oriented approach, it is practicable to devise more tiers of costing methods to exploit the well classified characteristics of bus links. For example, dead running to or from garages might be costed differently from cross-terminals dead running; and temporary garage dead running in the middle of the day might be costed differently from begin or end of day garage dead running. Costing bus links alone during swapping trials is unsatisfactory in dealing with more complex constraints. This is because after a swap, the tail ends of the two bus-work involved are switched; but the costing takes no account of compatibility between the front and tail ends of a bus-work. The existing algorithm attempts to overcome this for vehicle type constraints by some form of costing the overall suitability of the chain of bus-work for an assigned vehicle type. Current research in this new approach is aiming at generally introducing costs to associate with activity chains (chains of bus-work, see definitions above), and evolve through inheritance and specialisation costing mechanisms appropriate to specific constraints. In exploiting forefront computing technologies such as object-oriented approaches, it is appropriate to consider the practicality of supporting tools. We have chosen to use the C++ language [Stroustrup 91]. It supports all the object-oriented modelling concepts and there are

10

fast, standard and popular compilers available. Amongst the features of C++, it is especially worth mentioning "templates" and "container classes". These features enable useful data structures like linked lists, sets, queues, hash tables, dictionaries and so on to be automatically implemented for any object classes. Furthermore, "iterator" methods are available for processing the objects contained in such data structures. For example, it is possible to create a set object of infeasible bus links and apply a certain bus link swapping heuristic to all the set members in just a few C++ statements.

REFERENCES Kwan R.S.K. (1988). Co-ordination of joint headways. In Computer-aided transit scheduling (J.R. Daduna and A. Wren, eds.), 304-314. Springer-Verlag, Berlin. Myer, B. (1989). Reusability: The case for object-oriented design. In Software Reusability Vol II, Applications and Experience. (T.J. Biggerstaff and A.J. Perlis, eds.), ACM Press, Addison-Wesley. Smith, B.M. and A. Wren (1981). VAMPIRES and TASC: Two successfully applied bus scheduling programs. In Computer scheduling of public transport (A. Wren, ed.), 97-124, North-Holland Publishing. Stroustrup, B. (1991). The C++ programming language. 2nd Ed., Addison-Wesley. Wren, A. and M. Chamberlain (1988). The development of Micro-BUSMAN: Scheduling on micro-computers. In Computer-aided transit scheduling (J.R. Daduna and A. Wren, eds.), 160-174. Springer-Verlag, Berlin.

11