- Email: [email protected]
A visual interactive approach to vehicle routing
Computers & Operations Research 30 (2003) 321 – 337
www.elsevier.com/locate/dsw
A visual interactive approach to vehicle routing Barrie M. Bakera; ∗ , Carlos A.C. Carretob a
School of Mathematical and Information Sciences, Coventry University, Priory Street, Coventry CV1 5FB, UK b Departamento de Informatica, Instituto Politecnico da Guarda, Portugal Received 1 May 2001; received in revised form 1 October 2001
Abstract This paper describes a graphical-user-interface and a heuristic based on a greedy randomised adaptive search procedure which have been developed to work in combination to tackle the basic vehicle routing problem (VRP). Customers of known demand are supplied from a single depot by vehicles which are subject to a weight limit and, in some cases, to a limit on the distance travelled. Only one vehicle is allowed to supply each customer. The system works in a Windows environment with a familiar look and feel for the majority of computer users. The best known results for benchmark VRPs have been obtained using tabu search or simulated annealing. However, most publications describe implementations that do not allow the user any control over the routes that are produced. In practice, users may have local knowledge concerning constraints on the route structure, together with insight and judgement that would be di2cult to program in a heuristic for general application. The system described here allows the user to combine their special knowledge and insight with the power of the computer to perform modern heuristic techniques at high speed. Thus, the user retains control over the 4nal routes, thereby ensuring that they will be acceptable in practice. Even for intensively researched benchmark problems, where there are no constraints on route structure other than load and distance restrictions, interactive sessions of at most 15 min produced total distances averaging 61% above the best known values.
Scope and purpose The basic vehicle routing problem (VRP) consists of a large number of customers, each requiring a speci4ed weight of goods to be delivered. Vehicles despatched from a single depot must deliver the goods required, then return to the depot. Each vehicle can carry a limited weight and may also be restricted in the total distance it can travel. Only one vehicle is allowed to visit each customer. The problem is to 4nd a set of delivery routes satisfying these requirements and giving minimal total cost. In practice, this is often taken to
∗
Corresponding author. E-mail address: [email protected] (B.M. Baker).
0305-0548/02/$ - see front matter ? 2002 Elsevier Science Ltd. All rights reserved. PII: S 0 3 0 5 - 0 5 4 8 ( 0 1 ) 0 0 0 9 9 - 5
322
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
be equivalent to minimising the total distance travelled, or to minimising the number of vehicles used and then minimising total distance for this number of vehicles. Most published research for the VRP has focused on the development of heuristics which do not include any user control over the routes that are produced. In this paper, we describe how a graphical-user-interface and a heuristic have been developed which enable human intuition and local knowledge to be combined with the computer’s ability to perform the high speed calculations required for modern heuristics. This approach allows the user a high degree of control over the 4nal routes and, for this reason, is likely to be more acceptable to route planners in the real world. ? 2002 Elsevier Science Ltd. All rights reserved. Keywords: Routing; Heuristics; GRASP
1. Introduction The basic vehicle routing problem (VRP) consists of a large number of customers with known demand levels. Delivery routes must be determined for vehicles starting and 4nishing at a depot, so that all customer demands are satis4ed and each customer is visited by just one vehicle. Vehicle capacities are given and, sometimes, a maximum distance that each vehicle can travel. In the latter case, a drop allowance may be associated with each customer and added to the total distance travelled by the vehicle to which the customer is assigned. Thus, a vehicle which visits many customers will not be able to travel as far as a vehicle that visits relatively few customers. Possible objectives may be to 4nd a set of routes which minimises the total distance travelled, or which minimises the number of vehicles used and the total distance travelled with this number of vehicles. Various mathematical formulations of the VRP are given by, for example, Laporte [1]. Problems of realistic size are tackled using heuristics. There have been many contributions to the subject, including various extensions to the basic problem described above. Laporte [1] gives a survey, and an extensive bibliography has been compiled by Laporte and Osman [2]. The best known results to benchmark problems have been obtained using tabu search, such as reported by Osman [3], Taillard [4], Gendreau et al. [5] and Rochat and Taillard [6], or using simulated annealing as reported by Osman [3] and Hiquebran et al. [7]. However, most publications describe implementations that do not allow the user any control over the solutions generated. In practice, the user may wish to incorporate some special requirements or local knowledge concerning acceptable route structure. Human insight, or long experience with a particular problem structure, which would be di2cult to program for general application, could help guide heuristics towards promising regions of the solution space. Furthermore, a system that retains a high degree of user control may be more acceptable to planners in the real world. The aim of this study was to develop an eIective graphical-user-interface (GUI), along with suitable tools and techniques, and a heuristic to work within this environment, to enable the user’s special knowledge or insights to be combined with the computer’s capacity to perform high speed calculations. We have called the system which we developed CRUISE (computerised routing using interactive seed entry). The following sections describe the GUI, tools and heuristic of CRUISE, along with some techniques which we have found to be useful for obtaining good solutions. Even for intensively researched benchmark problems, where there are no constraints on route structure other than the overall capacity
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
323
and distance constraints, our computational results for interactive sessions of at most 15 min average 6 1% above the best known solutions.
2. The interactive process The interactive process is based on that which was originally put forward by Fisher and Jaikumar [8], and subsequently extended by Baker [9]. The customer locations are 4rst displayed. Then, for each vehicle, the user can select a single seed customer to indicate the region of operation of the vehicle, as proposed by Fisher and Jaikumar. Alternatively, several customers can be selected in the order that the user would expect them to be visited, to form an outline route, as described by Baker. Fig. 1 shows a typical selection of seeds and an outline route for the 100-city benchmark problem described later. The computer checks for any constraint violation throughout this process, in case the user attempts to construct an outline route which exceeds the maximum permitted load or distance. A heuristic is then applied by the computer to allocate the remaining customers to the routes started by the user, and the full routes are displayed. Then the tools provided allow the user to construct new outline routes from the routes produced by the heuristic, or to modify the routes generated by the heuristic, or to revert to the previous outline routes and modify those in any desired manner. Thus, the heuristic can be applied again, and the two alternating phases of user modi4cation and computer allocation can be repeated as many times as the user wishes. Further details of the tools and techniques developed are described in later sections. More formally, let i1 ; i2 ; : : : ; iK be the customers chosen to form the outline route for vehicle r, where K = 1 in the case of a single seed customer being chosen. Then, assuming a symmetric distance matrix, (dij ), the cost of allocating any remaining customer j to route r is approximated by crj = min {dik ;j + dik+1 ;j − dik ;ik+1 }; 06k 6K
(1)
where i0 and iK+1 both represent the depot. Thus, crj is the extra distance travelled if customer j is inserted into outline route r in the position that increases the length of the route by the smallest amount. The approach used by Baker [9] applied a heuristic to allocate the remaining customers to the outline routes so as to minimise the total of these approximate allocation costs, subject to load constraints. Then a TSP was solved for each vehicle to determine the true value for the total distance and, if any distance constraint violation occurred, the user would try to modify the outline routes, using an extra vehicle if necessary, so that distance constraints were satis4ed by a subsequent solution. It has been shown by Baker and Sheasby [10] that, for any given set of seeds, better results for the VRP are usually obtained if several near-optimal solutions are generated using the approximation in Eq. (1), allowing the best of these to be selected. To generate many near-optimal solutions, we use a greedy randomised adaptive search procedure (GRASP), which can also try to satisfy both load and distance constraints during the construction phase. Thus, a construction heuristic adds customers one-by-one to routes corresponding to small values of crj , incorporating an element of randomisation and, following each insertion, updating the crj -values for the route which has been modi4ed. In this way, the total distance travelled by each
324
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
Fig. 1. Seeds selection.
vehicle is known with reasonable accuracy throughout the construction heuristic, and this allows distance as well as load constraints to be taken into account. Periodic re-optimisation of each route during the construction phase is an option that the user can select for improved accuracy. A neighbourhood search is then carried out to try to improve each VRP solution before beginning the next GRASP iteration. An advantage of the GRASP approach is that it generates reasonably good results very quickly and allows the user the option to wait for improved results. Of course, it is not guaranteed that the construction procedure will generate a feasible solution at every GRASP iteration, especially if the problem instance has tight constraints. Furthermore, even if the problem instance has a feasible solution with the number of vehicles and the distance and capacity constraints being used, the selection of outline routes imposes additional constraints on the problem, which could mean that there is no longer a feasible solution, or that a feasible solution is very hard to 4nd using a construction heuristic. Throughout the GRASP iterations, the display shows the best solution obtained so far (feasible or infeasible), and the user can terminate the procedure whenever they wish to make a manual intervention in the solution process. In this context, the best infeasible solution is considered to be
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
325
one for which the unallocated customers have minimal total demand, since this oIers good scope for 4nding a feasible solution following a manual intervention. The GRASP procedure is stated formally as Algorithm 1 in the appendix. 3. The construction heuristic Further to the cost, crj , of inserting customer j into route r, de4ned in Section 2, de4ne Sj1 and Sj2 to be the smallest and second smallest insertion costs for customer j over all routes, and let Prj be the best insertion position of customer j in route r. Large values of Dj = Sj2 − Sj1 indicate customers that should be given some priority when deciding the order of allocating customers to routes, in order to achieve solutions with small total distance. The number of routes that each customer can go on without causing a constraint violation, Rj , is also taken into consideration, to reduce the occurrence of infeasible solutions. Further, R0 , R1 and R2 denote, respectively, the number of customers that can go on exactly 0, 1 or 2 routes without causing a constraint violation. Clearly, all the values de4ned so far need to be updated each time a customer is inserted into one of the routes. Thus, if R0 ¿ 0 at any stage of the construction heuristic, then the construction procedure has failed to produce a feasible solution at this GRASP iteration, but the procedure for this iteration will still continue if no feasible solution has been obtained at a previous iteration. If there are any customers that can be inserted into only one route (R1 ¿ 0), then the corresponding customers will be inserted into the routes which they can go on in descending order of Dj . If all customers have at least two routes into which they can be inserted (R1 = 0), the above de4ned quantities are used to generate a restricted candidate list (RCL) from which to select the next customer to be inserted. The maximum length, k, of the RCL can be selected by the user, as described later. Then, if there are customers that can be inserted into just two routes (R2 ¿ 0), the RCL will be formed from those customers. If R2 ¿ k, the RCL will consist of the k customers with largest Dj from those that have Rj = 2. If 0 ¡ R2 6 k, then the RCL will consist of all customers with Rj = 2. Finally, if all customers can be inserted into three or more routes (R2 = R1 = 0), then the RCL consists of the k customers with largest Dj if more than k customers remain unallocated, or all remaining customers if there are no more than k of them. Denoting the weight required by customer j by wj , each customer in the RCL is assigned a probability of wj = wj , where the summation is over the customers in the RCL, so that the probability of selection for any customer is proportional to demand. Priority is given to customers with larger demands in this way because it becomes more di2cult to 4nd routes that can accommodate these customers later in the allocation process. The construction heuristic and the procedure for obtaining the RCL are stated more formally in the appendix as Algorithms 2 and 3. Following the insertion of customer j ∗ in route r ∗ , say, both cr ∗ j and Pr ∗ j must be updated for each unallocated customer j where cr ∗ j ¡ ∞. Three cases must be considered. The simplest is where the remaining capacity for route r ∗ is less than the weight required by customer j, in which case cr ∗ j is set to in4nity. Otherwise, the cases where Pr ∗ j = Pr ∗ j∗ and Pr ∗ j = Pr ∗ j∗ must be considered separately. When Pr ∗ j = Pr ∗ j∗ , the insertion cost for customer j must be calculated with respect to the two new links created by the insertion of customer j ∗ and both cr ∗ j and Pr ∗ j must be updated if an improved value is found. Clearly, if the updated cr ∗ j exceeds the remaining distance that
326
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
the vehicle can travel (taking into account any drop allowance), cr ∗ j must be set to in4nity. If no improvement is found for cr ∗ j and its value is still less than the remaining distance that the vehicle can travel, then if Pr ∗ j ¿ Pr ∗ j∗ , Pr ∗ j must be increased by one to allow for the extra link created by the insertion of customer j ∗ . In the third case, where Pr ∗ j = Pr ∗ j∗ , the cost of inserting customer j must be re-calculated with respect to all possible insertion positions in route r ∗ , and the smallest value selected. Once again, if the updated cr ∗ j exceeds the remaining distance that the vehicle can travel, then cr ∗ j must be set to in4nity. This procedure for updating cr ∗ j and Pr ∗ j is stated more formally in the appendix as Algorithm 4. As customers are inserted into routes, the routes may become sub-optimal, and the user has the option to include application of the 3-optimal heuristic (Lin [11]) to improve individual vehicle routes when they reach any chosen percentage of their maximum distance. If a feasible solution is produced by the construction heuristic, then the 3-optimal procedure is applied to each vehicle route. Finally, a neighbourhood search is applied at the end of each GRASP iteration, which allows customers to be moved between routes, with the option to enable or disable moves involving customers selected by the user as seeds or in outline routes. Moves can be restricted to p-neighbourhoods, as used by Gendreau et al. [5], in which each customer j can be moved only to routes which contain at least one of the p nearest customers to customer j. In this context, the depot location is included along with the customer locations and, if the depot location is one of the p nearest locations to customer j, then j can be moved to any other route. First, each customer is considered in turn and tried in its best position in each route that is eligible. Then all pairs of routes are considered, and all customers that are eligible to be moved between these two routes are tried in pair-wise swaps between the two chosen routes. Computational testing included both best-improve and 4rst-improve strategies, as described by many other authors (such as Osman [3], for example). The user can choose between two metrics for determining the p-neighbourhoods. The circular metric uses the Euclidean distance, dij , between each pair of customers i and j. The generalised savings metric is given by sij = d0i + d0j − dij , as proposed by Yellow [12], with = 1:2. 4. Design of the graphical-user-interface Our aim was to design a GUI which would be eIective for the basic VRP and, at the same time, oIer potential for future developments, such as the incorporation of time windows or pick-ups as well as deliveries. For the basic VRP, the display should show both customer locations and the size of each customer’s order. Thus, each customer can be represented by a symbol whose area is proportional to the customer demand. With future developments in mind, the symbol used is a triangle, since this can be inverted to display a second piece of information. We can even place two triangles of diIerent sizes at one customer location, base-to-base say, with the customer location corresponding to the centre of each base, to show two diIerent pieces of information for each customer. The system was programmed to run within a Windows environment with dialog boxes, menus and toolbars similar to those which are familiar to the majority of computer users, as illustrated in Fig. 1. When pointing at any customer during the construction of seed or outline routes, the Inspect dialog box alongside shows the weight of any delivery or pick-up to be made. Details for
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
327
the route under construction are also shown: maximum distance and capacity, remaining distance and remaining capacity for both delivery and pick-ups. With the appropriate toolbar button selected, customers can be removed from or inserted into routes, whole routes can be removed, or fresh outline routes can be constructed. Groups of customers can be removed simultaneously from their various routes by a click and drag process to draw a rectangle over them. All these actions can be repeated or combined before clicking on the Solve button for a fresh application of the GRASP heuristic. At any stage, the user can gather information about routes by pointing at any customer to see full details for the customer and the corresponding route in the Inspect dialog box. All the operations previously described function equally whether the display shows a full solution or just seed and outline routes. The user can, therefore, try any manual alteration to the routes that they wish, with the computer checking feasibility. A particular feature is that, when a full solution is displayed, the user can remove a number of customers from their routes, then click on the Solve button again, and the residual routes will be used as the outline routes during the ensuing GRASP iterations. This is a very useful feature, as described in Section 5. The Options menu also allows the user to: • • • •
Vary the size of the RCL for GRASP. Select the circular or the generalised savings metric. Vary the value of p for the p-neighbourhoods, or use a full search. Enable the 3-optimal heuristic at any chosen percentage of maximum route distance, or delay the call to the 3-optimal heuristic to the end of each GRASP iteration. • Vary the sizes of triangle used in the display. • Connect lines between customers to either the apex or the base of each triangle. (The former introduces a minute amount of error into the representation, but may be useful in future developments where delivery and collection phases could be di2cult to distinguish otherwise.) The default settings for the above options are those that were found to be best during computational testing.
5. Interactive techniques Some useful techniques which emerged during computational testing are brieOy described in this section. Clearly, if the user has local knowledge or experience of the particular situation, this will be a primary inOuence in the choice of seed and outline routes, but some of the techniques described here could supplement this knowledge. Otherwise, having estimated the number of vehicles that are likely to be needed in order to meet the demand, it is advisable to start with a small number of customers selected for each route, say a maximum of four, to avoid over-constraining the solution. If the 4rst attempt does not lead to a promising result, it may be advisable to rotate the whole seed structure, placing the new seeds roughly mid-way between the 4rst set of seeds. When certain parts of the solution look reasonably well-structured, the corresponding seeds can be left unchanged whilst alternative selections of seeds are tried for regions where the solution structure looks poor or where customers are unassigned (i.e. the solution is infeasible).
328
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
When most of the solution structure looks reasonably good, it can be useful to remove two or three adjacent routes completely, where there is a substantial amount of overlap, then choose two seeds near the extremities of this region and, if appropriate, a third to bisect the region. Then click on the Solve button to re-allocate the customers within this region. Thus, most of the customer allocations are 4xed to well-de4ned routes and, with a signi4cantly reduced number of customers to be allocated by the construction heuristic, the GRASP iterations are completed very rapidly. If a good result is still not forthcoming, further attempts can be made, varying search parameters or the candidate list length. A very eIective technique for achieving more localised re4nement of routes is to draw a rectangle around one or more customers, to remove them from their routes, before clicking on the Solve button again. This often produces an improvement when the user judges that there is excessive overlap of routes within some region. When an infeasible solution is obtained, removal of a few customers in the region of an unallocated customer creates some slack in the constraints, allowing a previously unallocated customer to be inserted into a suitable route. This guarantees a change in the order in which customers are allocated, and increases the chance of 4nding a feasible solution with a fresh use of the Solve button. 6. Computational study of construction heuristic parameter settings The main items of interest are the eIects on the construction phase of varying the candidate list length and including re-optimisation of individual routes using a method such as 3-optimal. Studying the eIects of diIerent strategies and parameter settings on solution quality is complicated by the inOuence that the human user might have during the interactive process. As described in Section 5, the user can click on the Solve button under a variety of diIerent scenarios. To simplify the study, we concentrated on two extreme cases. The 4rst case was that of a typical 4rst-time application of the construction heuristic, in which we restricted the choice to one seed per vehicle for problems without distance constraints, and a maximum of two seeds per vehicle for problems with distance constraints. The second case was for a typical interactive session, in which a maximum of four areas were identi4ed where route structure could, perhaps, be improved, and a small number of customers were removed from their routes in each area, as described in Section 5. In each case, 100 feasible solutions were then generated using GRASP. For the study, visual comparisons were supported by two nonparametric tests, the Friedman test [13,15] to compare the results of several diIerent parameter settings for the heuristic, and the Wilcoxon test [14,15] to compare paired results for two sets of parameter settings. The graphics, tools and heuristic described in the previous sections were coded in C++ and applied to 14 vehicle routing problems from Christo4des et al. [16], which have been widely used as benchmarks by many researchers, and which can be downloaded from the OR-library (see Beasley [17]). The 4rst ten problems have customers that are randomly distributed with the depot in an approximately central location. In the last four problems, the customers are in clusters. Problems 1–5 and 11 and 12 have no distance constraints. The customers, demands, and load constraints of these seven problems are duplicated in problems 6 –10 and 13 and 14, which include distance constraints as well. The experiments were carried out separately for the problems with and without
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
329
distance constraints, since the inclusion of distance constraints could have a signi4cant eIect on the performance of the heuristic. For each problem, the percentage above the best published solution value was recorded for each of the 100 feasible solutions. The statistical tests were performed on both the average and the best of the 100 values obtained for each problem. 6.1. Problems without distance constraints For the seven problems without distance constraints, initial test-runs called the 3-optimal heuristic each time a customer was added to a route. Candidate list lengths from 1 to 6 were tried for both the 4rst-time and the interactive scenario. The Friedman test showed that varying the list length has a signi4cant eIect on both the average and the best values. As expected, the quality of average values deteriorates as the RCL length is increased for both the 4rst-time and interactive scenarios. However, the quality of the best solution values for both scenarios improves dramatically as a result of increasing the RCL length from 1 to 2, but longer lengths have relatively little eIect. For the 4rst-time scenario, the extra variability given by an RCL length of 3 may be advantageous but, with the smaller number of customers to be allocated in the interactive scenario, an RCL length of 2 gives su2cient variability. The eIect of re-optimising after each customer is added was studied for the 4rst-time scenario only, because of the small number of customers being added for the interactive scenario. One hundred feasible solutions were generated using as many GRASP iterations as were necessary, with an RCL length of 2. Three diIerent re-optimisation strategies were compared: re-optimisation after every insertion, re-optimisation only after all customers had been inserted, and with no re-optimisation. Using the Wilcoxon test, there was no signi4cant diIerence between the 4rst two strategies for either the average or the best result. As expected there was a signi4cant diIerence between the second and third strategies and, therefore, re-optimisation at the end of the construction heuristic is worthwhile, reducing the best distances obtained from 2.03% above the best known values to 1.81% above the best known values on average for the seven problems. In the 4rst strategy, only 8.66% of calls to the 3-optimal heuristic produced an improvement, and the average improvement obtained by these calls was only 1.8% of the route length. Thus, the extra distance due to adding a customer is not changed much by re-optimising, and so there is no signi4cant inOuence on the clustering heuristic due to re-optimising every time a customer is added to a route. 6.2. Problems with distance constraints For the seven problems with distance constraints, testing focused initially on the eIect of reoptimising during the construction phase since, at least for cases where a single seed customer is chosen, it seems possible that routes would be signi4cantly sub-optimal by the time they are close to the maximum distance. Therefore, re-optimising might allow an extra customer to be added to some of the routes. However, the tests described below do not support this theory. Initially, the RCL length was set to 2 and tests were carried out only for the 4rst-time application scenario, due to the small number of customers being added to routes during the interactive scenario. Results were compared with no re-optimisation, and with re-optimisation set to occur with each insertion after routes had reached 25%, 50%, 75%, 85%, 95% or 100% of the maximum distance, followed by (for the 4rst 4ve percentages) a 4nal re-optimisation when all customers were
330
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
allocated. The results showed that the 4nal re-optimisation had no eIect when re-optimisation was triggered at 75% or less. For the larger percentages, routes often never reached the distance at which re-optimisation would be triggered and, therefore, the 4nal re-optimisation had an eIect. It was found that re-optimisation has no signi4cant eIect on the average of the distances for 100 feasible solutions produced by GRASP, at any of the percentages used for the trigger. For the best distance from 100 feasible solutions, re-optimisation triggered at 85% was slightly better than the other levels for the trigger. With the trigger at 85%, the best distances averaged 2.08% above the best known values, over the seven problems, compared with 2.90% above the best known values with re-optimisation only at the end of each feasible GRASP iteration. The main points are as follows. Firstly, the extra distance due to adding a customer to a route is not changed much by re-optimising a route. Even with re-optimisation triggered at 95%, only 17% of re-optimisation calls produced an improvement and, at each of the percentages used as triggers, the average improvement was 6 0:7% of the route length. This is too small to have a signi4cant inOuence on the construction heuristic. Furthermore, in the 4rst-time scenario, the heuristic is more sensitive to the choice of seeds when there are distance constraints present, and it is quite common to 4nd that the chances of obtaining a feasible solution are improved by selecting two or more customers per route to give a petal shaped start for the heuristic. With this kind of outline route, the initial distance is a much larger percentage of the maximum distance, and routes are much less likely to become sub-optimal during the construction heuristic. Nevertheless, the study was conducted using a maximum of two customers chosen to form outline routes, and with at most 50% of routes being initialised with more than one customer. Where routes were initialised with two customers, they were chosen to be close together to keep the initial distance to a small percentage of the maximum distance. The only exceptions to this were the clustered problems 13 and 14, where it is necessary to choose customers in diIerent clusters for some routes to obtain feasible solutions. In conclusion, the best re-optimisation percentage was found to be 85%, although usually reoptimisation is only needed at the end for distance constrained problems. When the study turned to the RCL length for distance constrained problems, it was found that longer lists were more eIective than for problems without distance constraints. For the 4rst-time scenario, RCL lengths from 1 to 10 were tried, with re-optimisation at 85% of maximum distance, and with two to four customers chosen for each outline route. For the interactive scenario, the conditions were the same as those used without distance constraints. The Friedman test showed that changing the RCL length has a signi4cant eIect on the best solution obtained for both scenarios, with RCL lengths of 5 generally giving the best results in both cases. Table 1 summarises the parameter settings for the construction heuristic which gave the best results. Table 1 Best RCL lengths=re-optimisation strategies
First-time scenario Interactive scenario
Without distance constraints
With distance constraints
3=At end 2=At end
5=At 85% 5=At 85%
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
331
7. Computational study of local search phase parameters For this study, only the 4rst-time scenario was considered. The seeds used were the same as those used for the study reported in Section 6, with the parameter settings of Table 1. The distances were averaged over 100 feasible solutions produced using GRASP. Initially, the eIects of best-improve and 4rst-improve strategies were studied, trying all possible one-node and two-node interchanges at each iteration. Table 2 shows that both the average values and best solutions are improved by including the local search. The diIerence between the two move strategies is not signi4cant using the Wilcoxon test. As the 4rst-improve strategy is faster than the best-improve strategy, subsequent tests were carried out using only the 4rst-improve strategy. Four experiments were conducted with the p-neighbourhood reduction, consisting of the circular metric and the generalised savings metric combined with p = 5 and 10. Table 3 shows that all four combinations produce substantial reductions in the number of interchanges that are examined, with little deterioration in the quality of the results. The generalised savings metric produces a greater reduction in the number of interchanges considered, but the circular metric produces slightly better results. The diIerences are not statistically signi4cant. The larger size of p-neighbourhood gives a slight improvement in best solutions for three out of four cases, but not su2cient to justify the increased number of interchange candidates. Table 2 Comparison of move strategies for local search phase Move
Best-improve First-improve None a Per GRASP
Problems without distance constraints
Problems with distance constraints
Percentage above best known
Local search iterationsa
Percentage above best known
Local search iterationsa
Average
Best
One-node
Two-node
Average
Best
One-node
Two-node
1.0 0.9 1.8
4.9 3.6 —
8.6 5.4 —
3.8 3.8 4.5
1.4 1.2 1.8
3.3 1.8 —
1.9 0.7 —
2.7 2.8 4.0 iteration.
Table 3 Comparison of p-neighbourhood metrics for local search phase Metric
Problems without distance constraints
Problems with distance constraints
Percentage above best known Average Best
Interchange candidatesa
Percentage above best known Average Best
Interchange candidatesa
4254.5 7049.8 2056.0 4137.0 48671.6
3.8 4.0 4.3 4.1 3.8
1652.6 2718.4 787.6 1534.1 17065.0
Circular p = 5 2.8 Circular p = 10 2.9 Savings p = 5 3.2 Savings p = 10 3.1 Full search 2.8 a per GRASP iteration.
1.1 1.2 1.4 1.2 0.9
1.3 1.2 2.0 1.5 1.2
332
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
As a result of these tests, the 4rst-improve strategy, along with the circular metric and p = 5 were used as the default settings in CRUISE.
8. Computational results Using the default parameter settings and a Pentium II computer running at 300 MHz, each of the 14 benchmark problems described in Section 6 was the subject of an interactive session of at most 15 min duration using CRUISE. Table 4 shows the distances obtained during these sessions alongside well-known published results obtained using simulated annealing and tabu search [3– 6], and results obtained by Hjorring [18] using GRASP. The distances for all approaches in Table 4 were calculated as real values without truncation. The full routes corresponding to the CRUISE solutions are given by Carreto [19]. The distances obtained using CRUISE are, on average, 0.84% above the best tabu search results from Taillard [4], and Rochat and Taillard [6], but compare favourably with the results of the other authors. It should be noted that the solutions with smallest distance reported for problems 5 and 14 use one extra vehicle, which could be an expensive alternative in the real world. CRUISE allows the user to experiment with the number of vehicles and decide which solution is preferable, taking into account 4xed costs of vehicles. In the case of problem 14, where customers are in clusters, with only 10 vehicles the constraints are tight, and our best solution required several vehicles to visit more than one of the clusters. Using 11 vehicles the problem is much easier to solve, and we reduced the distance from 902.81 to 867.92, which is within 0.18% of the result from Taillard [4]. In a separate experiment, we recorded the time to produce 100 feasible solutions using GRASP, in the 4rst-time scenario as described in Section 6. A slightly faster computer was available for this experiment (Pentium II 500 MHz). The times obtained are shown in the last column of Table 4. These times include all associated procedures, such as loading and saving information held in 4les and updating the display each time an improved solution is found. In some cases, where constraints are tight, the number of GRASP iterations will be ¿ 100, as some iterations may not produce a feasible solution. Since the incidence of infeasible solutions depends on the choice of seeds or outline routes, diIerent times could result from diIerent choices. In practice, the user would often choose to stop the process earlier.
9. Conclusion A visual interactive system, CRUISE, has been developed which is easy to use, with a Windows interface of the kind that will be familiar to most computer users. The tools which have been programmed into CRUISE provide considerable Oexibility, allowing users to combine their insights, knowledge and judgement with the power of the computer to perform modern heuristics at high speed. Interactive sessions of at most 15 min gave results within 1%, on average, of the best results obtained using tabu search. This approach is likely to appeal to schedulers who wish to retain some control over the routes that are adopted, especially if there are local constraints on route structure that need to be taken into consideration.
528 838 829 1058 1376 555 909 866 1164 1418 1176 826 1545 890h
524=524 844=844 838=835 1044=1052 1334=1354 555=555 911=913 878=866 1184=1188 1441=1422 1043=1042 819=819 1545=1547 866=866h
524.61 835.32 826.14 1031.07 1311.35h 555.43 909.68 865.94 1162.89 1404.75 1042.11 819.56 1545.93 866.37h
524.61 845.50 829.34 1052.37 1342.74h 555.43 917.06 867.58 1181.13 1460.06 1045.30 820.92 1551.19 901.01 Average
524.61 839.36 830.16 1040.67 1336.55 555.43 909.68 865.94 1171.62 1407.14 1042.11 819.56 1546.55 902.81
0.84
0.00 0.49 0.49 1.19 3.49 0.00 0.00 0.00 0.78 0.81 0.00 0.00 0.35 4.21
16 45 58 101 334 21 102 52 537 956 158 80 84 120
Gendreau et al.d Hjorringe CRUISEf % gap GRASPg (TABUROUTE) (GRASP) (interactive) times
Simulated annealing by Osman [3]. b Tabu search + First-best-admissible=best-admissible by Osman [3]. c Tabu search by Taillard [4]=Tabu search by Rochat and Taillard [6]. d Tabu search by Gendreau et al. [5]. e GRASP by Hjorring [18]. f CRUISE—computerised routing using interactive seed entry and % above best tabu search result. g Seconds to produce 100 feasible solutions using GRASP (Pentium II 500 MHz). h Uses an extra vehicle.
a
5 10 8 12 16 6 11 9 14 18 7 10 11 10
524.61 835.26 826.14 1028.42 1298.79=1291.45h 555.43 909.68 865.94 1162.55 1397.94=1395.85 1042.11 819.56 1541.14 866.37h
0=∞ 0=∞ 0=∞ 0=∞ 0=∞ 10=200 10=160 10=230 10=200 10=200 0=∞ 0=∞ 50=720 90=1040
50 75 100 150 199 50 75 100 150 199 120 100 120 100
160 140 200 200 200 160 140 200 200 200 200 200 200 200
Taillard=Rochatc (TS)
Cities Capacity Drop allowance = Vehicles Osmana Osmanb distance limit (SA) (TS)
Table 4 Comparison of visual interactive approach with published results
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337 333
334
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
The system oIers scope for further development to vehicle routing problems that include backhauls or time windows for example, and research within these areas is already underway. Another area of interest which will be pursued is the incorporation of a learning strategy in the construction heuristic. Although the straightforward GRASP approach has proved eIective, we will investigate whether a learning strategy could be used to improve performance. For increased practicality, further development could integrate the program with a Geographic Information System. A road map could be displayed as a background image, with no signi4cant changes to the existing program code being needed. We believe that the user could identify outline routes eIectively and apply the interactive techniques in much the same way as we have done for the benchmark problems, which are restricted to Euclidean distances. Although the user should be able to see from the map display if customers that are separated by a short straight line distance are actually far apart on the road system, it could be that the user’s experience and local knowledge would become even more relevant to this kind of problem. Thus, there is considerable scope for further research and development arising from the work described in this paper. Appendix. Algorithm 1. Greedy randomised adaptive search procedure (GRASP) De4ne Cf (x ) to be the total distance for the solution x if x is feasible, and Ci (x ) to be the total weight unallocated for the solution x if x is infeasible.
begin user selects initial seeds; best feasible cost = ∞; best infeasible cost = ∞; repeat start with the initial seeds; construct greedy randomised solution x; find local minimum x starting from x; if (x is feasible) if (Cf (x ) ¡ best feasible cost) { x∗ = x ; best feasible cost = Cf (x ); display x∗ ; } else if ((Ci (x ) ¡ best infeasible cost) and (x∗ = R)) { x∗∗ = x ; best infeasible cost = Ci (x ); display x∗∗ ; } until (stopping criterion is true) end
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
Algorithm 2. The construction phase
begin initialise crj and Prj for each unallocated customer j and route r; initialise Dj and Rj for each unallocated customer j; initialise R0 , R1 and R2 ; while (customer allocations are still possible) { if (R0 ¿ 0) and (a feasible solution has been previously found) terminate construction phase; if (R1 ¿ 0) j ∗ = customer j with largest Dj and Rj = 1; else j ∗ = random selection from RCL; ∗ r =argmin (crj∗ ); insert customer j ∗ in position Pr ∗ j∗ ; mark customer j ∗ as being allocated; update remaining capacity and distance for route r ∗ ; apply 3-optimal to route r ∗ if necessary; update cr ∗ j , Pr ∗ j , Dj and Rj for each unallocated customer j; update R0 , R1 and R2 ; } apply 3-optimal to each route; end Algorithm 3. Construction of and selection from the Restricted Candidate List (RCL)
begin T = {unallocated customers with Rj = 2}, (R2 = |T |); if (R2 = 0) { if (more than k customers remain unallocated) construct RCL with k customers with largest Dj ; else construct RCL with all unallocated customers; assign probabilities proportional to demands; j ∗ = customer selected randomly from RCL; } else if (R2 = 1) j ∗ = element in T ; else { if (R2 ¿ k) construct RCL with k customers in T with largest Dj ; else construct RCL with all customers in T ; assign probabilities proportional to demands; j ∗ = customer selected randomly from RCL; } end
335
336
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
Algorithm 4. Updating cr ∗ j and Pr ∗ j De4ne aj to be the drop allowance for customer j.
begin for (each unallocated customer j); if (wj ¿ remaining delivery capacity of route r ∗ ) cr ∗ j = ∞; else if (Pr ∗ j = Pr ∗ j∗ ) { calculate cr ∗ j with respect to new links; update cr ∗ j if necessary; if (cr ∗ j + aj ¿ remaining delivery distance for route r ∗ ) cr ∗ j = ∞; else if (there is an improvement) update Pr ∗ j ; else if (Pr ∗ j ¿ Pr ∗ j∗ ) increase Pr ∗ j by 1; } else { recalculate cr ∗ j for all possible Pr ∗ j ; record new values for cr ∗ j and Pr ∗ j ; if (cr ∗ j + aj ¿ remaining delivery distance for route r ∗ ) cr ∗ j = ∞; } end References [1] Laporte G. The vehicle routing problem: an overview of exact and approximate algorithms. European Journal of Operational Research 1992;59:345–58. [2] Laporte G, Osman IH. Routing problems: a bibliography. Annals of Operations Research 1995;61:227–62. [3] Osman IH. Metastrategy simulated annealing and tabu search algorithms for the vehicle routing problem. Operations Research 1993;41:421–51. S Parallel iterative search methods for vehicle routing problems. Networks 1993;23:661–73. [4] Taillard E. [5] Gendreau M, Hertz A, Laporte G. A tabu search heuristic for the vehicle routing problem. Management Science 1994;40:1276–90. S Probabilistic diversi4cation and intensi4cation in local search for vehicle routing. Journal of [6] Rochat Y, Taillard E. Heuristics 1995;1:147–67. [7] Hiquebran DT, Alfa AS, Shapiro A, Gittoes DH. A revised simulated annealing and cluster-4rst route-second algorithm applied to the vehicle routing problem. Engineering Optimization 1994;22:77–107. [8] Fisher ML, Jaikumar R. A generalized assignment heuristic for vehicle routing. Networks 1981;11:109–24. [9] Baker BM. Further improvements to vehicle routing heuristics. Journal of the Operational Research Society 1992;43:1009–12. [10] Baker BM, Sheasby JE. Extensions to the generalized assignment heuristic for vehicle routing. European Journal of Operational Research 1999;119:147–57.
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
337
[11] Lin S. Computer solutions of the travelling salesman problem. Bell Systems Technical Journal 1965;44:2245–69. [12] Yellow PC. A computational modi4cation to the savings method for vehicle scheduling. Operational Research Quarterly 1970;21(2):281–3. [13] Friedman M. The use of ranks to avoid the assumption of normality implicit in the analysis of variance. Journal of the American Statistical Association 1937;32:675–701. [14] Wilcoxon F. Individual comparison by ranking methods. Biometrics 1945;1:80–3. [15] Zar J. Biostatistical analysis, 4th ed. Englewood CliIs, NJ: Prentice Hall, 1998. [16] Christo4des N, Mingozzi A, Toth P. The vehicle routing problem. In: Christo4des N, Mingozzi A, Toth P, Sandi C, editors. Combinatorial optimization. New York: Wiley, 1979. p. 315–338. [17] Beasley JE. OR-library: distributing test problems by electronic mail. Journal of the Operational Research Society 1990;41:1069–72. [18] Hjorring CA. The vehicle routing problem and local search metaheuristics. PhD thesis, University of Auckland, 1995. [19] Carreto CAC. Visual interactive methods for vehicle routing. PhD thesis, Coventry University, UK, 2000. Barrie M. Baker holds a BSc in Mathematics and an MSc and Ph.D. in Operational Research, all from London University. He is a member of the academic staI at Coventry University, and his main interests are in network and distribution modelling and spreadsheet modelling. Carlos Carreto holds a Bacharelato and Licenciatura in Computer Science from Instituto PolitSecnico da Guarda, Portugal, and gained a Ph.D. from Coventry University researching modern heuristic methods. He is a member of the academic staI at Instituto PolitSecnico da Guarda, where his main interests are in heuristics and graphics programming.
www.elsevier.com/locate/dsw
A visual interactive approach to vehicle routing Barrie M. Bakera; ∗ , Carlos A.C. Carretob a
School of Mathematical and Information Sciences, Coventry University, Priory Street, Coventry CV1 5FB, UK b Departamento de Informatica, Instituto Politecnico da Guarda, Portugal Received 1 May 2001; received in revised form 1 October 2001
Abstract This paper describes a graphical-user-interface and a heuristic based on a greedy randomised adaptive search procedure which have been developed to work in combination to tackle the basic vehicle routing problem (VRP). Customers of known demand are supplied from a single depot by vehicles which are subject to a weight limit and, in some cases, to a limit on the distance travelled. Only one vehicle is allowed to supply each customer. The system works in a Windows environment with a familiar look and feel for the majority of computer users. The best known results for benchmark VRPs have been obtained using tabu search or simulated annealing. However, most publications describe implementations that do not allow the user any control over the routes that are produced. In practice, users may have local knowledge concerning constraints on the route structure, together with insight and judgement that would be di2cult to program in a heuristic for general application. The system described here allows the user to combine their special knowledge and insight with the power of the computer to perform modern heuristic techniques at high speed. Thus, the user retains control over the 4nal routes, thereby ensuring that they will be acceptable in practice. Even for intensively researched benchmark problems, where there are no constraints on route structure other than load and distance restrictions, interactive sessions of at most 15 min produced total distances averaging 61% above the best known values.
Scope and purpose The basic vehicle routing problem (VRP) consists of a large number of customers, each requiring a speci4ed weight of goods to be delivered. Vehicles despatched from a single depot must deliver the goods required, then return to the depot. Each vehicle can carry a limited weight and may also be restricted in the total distance it can travel. Only one vehicle is allowed to visit each customer. The problem is to 4nd a set of delivery routes satisfying these requirements and giving minimal total cost. In practice, this is often taken to
∗
Corresponding author. E-mail address: [email protected] (B.M. Baker).
0305-0548/02/$ - see front matter ? 2002 Elsevier Science Ltd. All rights reserved. PII: S 0 3 0 5 - 0 5 4 8 ( 0 1 ) 0 0 0 9 9 - 5
322
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
be equivalent to minimising the total distance travelled, or to minimising the number of vehicles used and then minimising total distance for this number of vehicles. Most published research for the VRP has focused on the development of heuristics which do not include any user control over the routes that are produced. In this paper, we describe how a graphical-user-interface and a heuristic have been developed which enable human intuition and local knowledge to be combined with the computer’s ability to perform the high speed calculations required for modern heuristics. This approach allows the user a high degree of control over the 4nal routes and, for this reason, is likely to be more acceptable to route planners in the real world. ? 2002 Elsevier Science Ltd. All rights reserved. Keywords: Routing; Heuristics; GRASP
1. Introduction The basic vehicle routing problem (VRP) consists of a large number of customers with known demand levels. Delivery routes must be determined for vehicles starting and 4nishing at a depot, so that all customer demands are satis4ed and each customer is visited by just one vehicle. Vehicle capacities are given and, sometimes, a maximum distance that each vehicle can travel. In the latter case, a drop allowance may be associated with each customer and added to the total distance travelled by the vehicle to which the customer is assigned. Thus, a vehicle which visits many customers will not be able to travel as far as a vehicle that visits relatively few customers. Possible objectives may be to 4nd a set of routes which minimises the total distance travelled, or which minimises the number of vehicles used and the total distance travelled with this number of vehicles. Various mathematical formulations of the VRP are given by, for example, Laporte [1]. Problems of realistic size are tackled using heuristics. There have been many contributions to the subject, including various extensions to the basic problem described above. Laporte [1] gives a survey, and an extensive bibliography has been compiled by Laporte and Osman [2]. The best known results to benchmark problems have been obtained using tabu search, such as reported by Osman [3], Taillard [4], Gendreau et al. [5] and Rochat and Taillard [6], or using simulated annealing as reported by Osman [3] and Hiquebran et al. [7]. However, most publications describe implementations that do not allow the user any control over the solutions generated. In practice, the user may wish to incorporate some special requirements or local knowledge concerning acceptable route structure. Human insight, or long experience with a particular problem structure, which would be di2cult to program for general application, could help guide heuristics towards promising regions of the solution space. Furthermore, a system that retains a high degree of user control may be more acceptable to planners in the real world. The aim of this study was to develop an eIective graphical-user-interface (GUI), along with suitable tools and techniques, and a heuristic to work within this environment, to enable the user’s special knowledge or insights to be combined with the computer’s capacity to perform high speed calculations. We have called the system which we developed CRUISE (computerised routing using interactive seed entry). The following sections describe the GUI, tools and heuristic of CRUISE, along with some techniques which we have found to be useful for obtaining good solutions. Even for intensively researched benchmark problems, where there are no constraints on route structure other than the overall capacity
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
323
and distance constraints, our computational results for interactive sessions of at most 15 min average 6 1% above the best known solutions.
2. The interactive process The interactive process is based on that which was originally put forward by Fisher and Jaikumar [8], and subsequently extended by Baker [9]. The customer locations are 4rst displayed. Then, for each vehicle, the user can select a single seed customer to indicate the region of operation of the vehicle, as proposed by Fisher and Jaikumar. Alternatively, several customers can be selected in the order that the user would expect them to be visited, to form an outline route, as described by Baker. Fig. 1 shows a typical selection of seeds and an outline route for the 100-city benchmark problem described later. The computer checks for any constraint violation throughout this process, in case the user attempts to construct an outline route which exceeds the maximum permitted load or distance. A heuristic is then applied by the computer to allocate the remaining customers to the routes started by the user, and the full routes are displayed. Then the tools provided allow the user to construct new outline routes from the routes produced by the heuristic, or to modify the routes generated by the heuristic, or to revert to the previous outline routes and modify those in any desired manner. Thus, the heuristic can be applied again, and the two alternating phases of user modi4cation and computer allocation can be repeated as many times as the user wishes. Further details of the tools and techniques developed are described in later sections. More formally, let i1 ; i2 ; : : : ; iK be the customers chosen to form the outline route for vehicle r, where K = 1 in the case of a single seed customer being chosen. Then, assuming a symmetric distance matrix, (dij ), the cost of allocating any remaining customer j to route r is approximated by crj = min {dik ;j + dik+1 ;j − dik ;ik+1 }; 06k 6K
(1)
where i0 and iK+1 both represent the depot. Thus, crj is the extra distance travelled if customer j is inserted into outline route r in the position that increases the length of the route by the smallest amount. The approach used by Baker [9] applied a heuristic to allocate the remaining customers to the outline routes so as to minimise the total of these approximate allocation costs, subject to load constraints. Then a TSP was solved for each vehicle to determine the true value for the total distance and, if any distance constraint violation occurred, the user would try to modify the outline routes, using an extra vehicle if necessary, so that distance constraints were satis4ed by a subsequent solution. It has been shown by Baker and Sheasby [10] that, for any given set of seeds, better results for the VRP are usually obtained if several near-optimal solutions are generated using the approximation in Eq. (1), allowing the best of these to be selected. To generate many near-optimal solutions, we use a greedy randomised adaptive search procedure (GRASP), which can also try to satisfy both load and distance constraints during the construction phase. Thus, a construction heuristic adds customers one-by-one to routes corresponding to small values of crj , incorporating an element of randomisation and, following each insertion, updating the crj -values for the route which has been modi4ed. In this way, the total distance travelled by each
324
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
Fig. 1. Seeds selection.
vehicle is known with reasonable accuracy throughout the construction heuristic, and this allows distance as well as load constraints to be taken into account. Periodic re-optimisation of each route during the construction phase is an option that the user can select for improved accuracy. A neighbourhood search is then carried out to try to improve each VRP solution before beginning the next GRASP iteration. An advantage of the GRASP approach is that it generates reasonably good results very quickly and allows the user the option to wait for improved results. Of course, it is not guaranteed that the construction procedure will generate a feasible solution at every GRASP iteration, especially if the problem instance has tight constraints. Furthermore, even if the problem instance has a feasible solution with the number of vehicles and the distance and capacity constraints being used, the selection of outline routes imposes additional constraints on the problem, which could mean that there is no longer a feasible solution, or that a feasible solution is very hard to 4nd using a construction heuristic. Throughout the GRASP iterations, the display shows the best solution obtained so far (feasible or infeasible), and the user can terminate the procedure whenever they wish to make a manual intervention in the solution process. In this context, the best infeasible solution is considered to be
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
325
one for which the unallocated customers have minimal total demand, since this oIers good scope for 4nding a feasible solution following a manual intervention. The GRASP procedure is stated formally as Algorithm 1 in the appendix. 3. The construction heuristic Further to the cost, crj , of inserting customer j into route r, de4ned in Section 2, de4ne Sj1 and Sj2 to be the smallest and second smallest insertion costs for customer j over all routes, and let Prj be the best insertion position of customer j in route r. Large values of Dj = Sj2 − Sj1 indicate customers that should be given some priority when deciding the order of allocating customers to routes, in order to achieve solutions with small total distance. The number of routes that each customer can go on without causing a constraint violation, Rj , is also taken into consideration, to reduce the occurrence of infeasible solutions. Further, R0 , R1 and R2 denote, respectively, the number of customers that can go on exactly 0, 1 or 2 routes without causing a constraint violation. Clearly, all the values de4ned so far need to be updated each time a customer is inserted into one of the routes. Thus, if R0 ¿ 0 at any stage of the construction heuristic, then the construction procedure has failed to produce a feasible solution at this GRASP iteration, but the procedure for this iteration will still continue if no feasible solution has been obtained at a previous iteration. If there are any customers that can be inserted into only one route (R1 ¿ 0), then the corresponding customers will be inserted into the routes which they can go on in descending order of Dj . If all customers have at least two routes into which they can be inserted (R1 = 0), the above de4ned quantities are used to generate a restricted candidate list (RCL) from which to select the next customer to be inserted. The maximum length, k, of the RCL can be selected by the user, as described later. Then, if there are customers that can be inserted into just two routes (R2 ¿ 0), the RCL will be formed from those customers. If R2 ¿ k, the RCL will consist of the k customers with largest Dj from those that have Rj = 2. If 0 ¡ R2 6 k, then the RCL will consist of all customers with Rj = 2. Finally, if all customers can be inserted into three or more routes (R2 = R1 = 0), then the RCL consists of the k customers with largest Dj if more than k customers remain unallocated, or all remaining customers if there are no more than k of them. Denoting the weight required by customer j by wj , each customer in the RCL is assigned a probability of wj = wj , where the summation is over the customers in the RCL, so that the probability of selection for any customer is proportional to demand. Priority is given to customers with larger demands in this way because it becomes more di2cult to 4nd routes that can accommodate these customers later in the allocation process. The construction heuristic and the procedure for obtaining the RCL are stated more formally in the appendix as Algorithms 2 and 3. Following the insertion of customer j ∗ in route r ∗ , say, both cr ∗ j and Pr ∗ j must be updated for each unallocated customer j where cr ∗ j ¡ ∞. Three cases must be considered. The simplest is where the remaining capacity for route r ∗ is less than the weight required by customer j, in which case cr ∗ j is set to in4nity. Otherwise, the cases where Pr ∗ j = Pr ∗ j∗ and Pr ∗ j = Pr ∗ j∗ must be considered separately. When Pr ∗ j = Pr ∗ j∗ , the insertion cost for customer j must be calculated with respect to the two new links created by the insertion of customer j ∗ and both cr ∗ j and Pr ∗ j must be updated if an improved value is found. Clearly, if the updated cr ∗ j exceeds the remaining distance that
326
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
the vehicle can travel (taking into account any drop allowance), cr ∗ j must be set to in4nity. If no improvement is found for cr ∗ j and its value is still less than the remaining distance that the vehicle can travel, then if Pr ∗ j ¿ Pr ∗ j∗ , Pr ∗ j must be increased by one to allow for the extra link created by the insertion of customer j ∗ . In the third case, where Pr ∗ j = Pr ∗ j∗ , the cost of inserting customer j must be re-calculated with respect to all possible insertion positions in route r ∗ , and the smallest value selected. Once again, if the updated cr ∗ j exceeds the remaining distance that the vehicle can travel, then cr ∗ j must be set to in4nity. This procedure for updating cr ∗ j and Pr ∗ j is stated more formally in the appendix as Algorithm 4. As customers are inserted into routes, the routes may become sub-optimal, and the user has the option to include application of the 3-optimal heuristic (Lin [11]) to improve individual vehicle routes when they reach any chosen percentage of their maximum distance. If a feasible solution is produced by the construction heuristic, then the 3-optimal procedure is applied to each vehicle route. Finally, a neighbourhood search is applied at the end of each GRASP iteration, which allows customers to be moved between routes, with the option to enable or disable moves involving customers selected by the user as seeds or in outline routes. Moves can be restricted to p-neighbourhoods, as used by Gendreau et al. [5], in which each customer j can be moved only to routes which contain at least one of the p nearest customers to customer j. In this context, the depot location is included along with the customer locations and, if the depot location is one of the p nearest locations to customer j, then j can be moved to any other route. First, each customer is considered in turn and tried in its best position in each route that is eligible. Then all pairs of routes are considered, and all customers that are eligible to be moved between these two routes are tried in pair-wise swaps between the two chosen routes. Computational testing included both best-improve and 4rst-improve strategies, as described by many other authors (such as Osman [3], for example). The user can choose between two metrics for determining the p-neighbourhoods. The circular metric uses the Euclidean distance, dij , between each pair of customers i and j. The generalised savings metric is given by sij = d0i + d0j − dij , as proposed by Yellow [12], with = 1:2. 4. Design of the graphical-user-interface Our aim was to design a GUI which would be eIective for the basic VRP and, at the same time, oIer potential for future developments, such as the incorporation of time windows or pick-ups as well as deliveries. For the basic VRP, the display should show both customer locations and the size of each customer’s order. Thus, each customer can be represented by a symbol whose area is proportional to the customer demand. With future developments in mind, the symbol used is a triangle, since this can be inverted to display a second piece of information. We can even place two triangles of diIerent sizes at one customer location, base-to-base say, with the customer location corresponding to the centre of each base, to show two diIerent pieces of information for each customer. The system was programmed to run within a Windows environment with dialog boxes, menus and toolbars similar to those which are familiar to the majority of computer users, as illustrated in Fig. 1. When pointing at any customer during the construction of seed or outline routes, the Inspect dialog box alongside shows the weight of any delivery or pick-up to be made. Details for
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
327
the route under construction are also shown: maximum distance and capacity, remaining distance and remaining capacity for both delivery and pick-ups. With the appropriate toolbar button selected, customers can be removed from or inserted into routes, whole routes can be removed, or fresh outline routes can be constructed. Groups of customers can be removed simultaneously from their various routes by a click and drag process to draw a rectangle over them. All these actions can be repeated or combined before clicking on the Solve button for a fresh application of the GRASP heuristic. At any stage, the user can gather information about routes by pointing at any customer to see full details for the customer and the corresponding route in the Inspect dialog box. All the operations previously described function equally whether the display shows a full solution or just seed and outline routes. The user can, therefore, try any manual alteration to the routes that they wish, with the computer checking feasibility. A particular feature is that, when a full solution is displayed, the user can remove a number of customers from their routes, then click on the Solve button again, and the residual routes will be used as the outline routes during the ensuing GRASP iterations. This is a very useful feature, as described in Section 5. The Options menu also allows the user to: • • • •
Vary the size of the RCL for GRASP. Select the circular or the generalised savings metric. Vary the value of p for the p-neighbourhoods, or use a full search. Enable the 3-optimal heuristic at any chosen percentage of maximum route distance, or delay the call to the 3-optimal heuristic to the end of each GRASP iteration. • Vary the sizes of triangle used in the display. • Connect lines between customers to either the apex or the base of each triangle. (The former introduces a minute amount of error into the representation, but may be useful in future developments where delivery and collection phases could be di2cult to distinguish otherwise.) The default settings for the above options are those that were found to be best during computational testing.
5. Interactive techniques Some useful techniques which emerged during computational testing are brieOy described in this section. Clearly, if the user has local knowledge or experience of the particular situation, this will be a primary inOuence in the choice of seed and outline routes, but some of the techniques described here could supplement this knowledge. Otherwise, having estimated the number of vehicles that are likely to be needed in order to meet the demand, it is advisable to start with a small number of customers selected for each route, say a maximum of four, to avoid over-constraining the solution. If the 4rst attempt does not lead to a promising result, it may be advisable to rotate the whole seed structure, placing the new seeds roughly mid-way between the 4rst set of seeds. When certain parts of the solution look reasonably well-structured, the corresponding seeds can be left unchanged whilst alternative selections of seeds are tried for regions where the solution structure looks poor or where customers are unassigned (i.e. the solution is infeasible).
328
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
When most of the solution structure looks reasonably good, it can be useful to remove two or three adjacent routes completely, where there is a substantial amount of overlap, then choose two seeds near the extremities of this region and, if appropriate, a third to bisect the region. Then click on the Solve button to re-allocate the customers within this region. Thus, most of the customer allocations are 4xed to well-de4ned routes and, with a signi4cantly reduced number of customers to be allocated by the construction heuristic, the GRASP iterations are completed very rapidly. If a good result is still not forthcoming, further attempts can be made, varying search parameters or the candidate list length. A very eIective technique for achieving more localised re4nement of routes is to draw a rectangle around one or more customers, to remove them from their routes, before clicking on the Solve button again. This often produces an improvement when the user judges that there is excessive overlap of routes within some region. When an infeasible solution is obtained, removal of a few customers in the region of an unallocated customer creates some slack in the constraints, allowing a previously unallocated customer to be inserted into a suitable route. This guarantees a change in the order in which customers are allocated, and increases the chance of 4nding a feasible solution with a fresh use of the Solve button. 6. Computational study of construction heuristic parameter settings The main items of interest are the eIects on the construction phase of varying the candidate list length and including re-optimisation of individual routes using a method such as 3-optimal. Studying the eIects of diIerent strategies and parameter settings on solution quality is complicated by the inOuence that the human user might have during the interactive process. As described in Section 5, the user can click on the Solve button under a variety of diIerent scenarios. To simplify the study, we concentrated on two extreme cases. The 4rst case was that of a typical 4rst-time application of the construction heuristic, in which we restricted the choice to one seed per vehicle for problems without distance constraints, and a maximum of two seeds per vehicle for problems with distance constraints. The second case was for a typical interactive session, in which a maximum of four areas were identi4ed where route structure could, perhaps, be improved, and a small number of customers were removed from their routes in each area, as described in Section 5. In each case, 100 feasible solutions were then generated using GRASP. For the study, visual comparisons were supported by two nonparametric tests, the Friedman test [13,15] to compare the results of several diIerent parameter settings for the heuristic, and the Wilcoxon test [14,15] to compare paired results for two sets of parameter settings. The graphics, tools and heuristic described in the previous sections were coded in C++ and applied to 14 vehicle routing problems from Christo4des et al. [16], which have been widely used as benchmarks by many researchers, and which can be downloaded from the OR-library (see Beasley [17]). The 4rst ten problems have customers that are randomly distributed with the depot in an approximately central location. In the last four problems, the customers are in clusters. Problems 1–5 and 11 and 12 have no distance constraints. The customers, demands, and load constraints of these seven problems are duplicated in problems 6 –10 and 13 and 14, which include distance constraints as well. The experiments were carried out separately for the problems with and without
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
329
distance constraints, since the inclusion of distance constraints could have a signi4cant eIect on the performance of the heuristic. For each problem, the percentage above the best published solution value was recorded for each of the 100 feasible solutions. The statistical tests were performed on both the average and the best of the 100 values obtained for each problem. 6.1. Problems without distance constraints For the seven problems without distance constraints, initial test-runs called the 3-optimal heuristic each time a customer was added to a route. Candidate list lengths from 1 to 6 were tried for both the 4rst-time and the interactive scenario. The Friedman test showed that varying the list length has a signi4cant eIect on both the average and the best values. As expected, the quality of average values deteriorates as the RCL length is increased for both the 4rst-time and interactive scenarios. However, the quality of the best solution values for both scenarios improves dramatically as a result of increasing the RCL length from 1 to 2, but longer lengths have relatively little eIect. For the 4rst-time scenario, the extra variability given by an RCL length of 3 may be advantageous but, with the smaller number of customers to be allocated in the interactive scenario, an RCL length of 2 gives su2cient variability. The eIect of re-optimising after each customer is added was studied for the 4rst-time scenario only, because of the small number of customers being added for the interactive scenario. One hundred feasible solutions were generated using as many GRASP iterations as were necessary, with an RCL length of 2. Three diIerent re-optimisation strategies were compared: re-optimisation after every insertion, re-optimisation only after all customers had been inserted, and with no re-optimisation. Using the Wilcoxon test, there was no signi4cant diIerence between the 4rst two strategies for either the average or the best result. As expected there was a signi4cant diIerence between the second and third strategies and, therefore, re-optimisation at the end of the construction heuristic is worthwhile, reducing the best distances obtained from 2.03% above the best known values to 1.81% above the best known values on average for the seven problems. In the 4rst strategy, only 8.66% of calls to the 3-optimal heuristic produced an improvement, and the average improvement obtained by these calls was only 1.8% of the route length. Thus, the extra distance due to adding a customer is not changed much by re-optimising, and so there is no signi4cant inOuence on the clustering heuristic due to re-optimising every time a customer is added to a route. 6.2. Problems with distance constraints For the seven problems with distance constraints, testing focused initially on the eIect of reoptimising during the construction phase since, at least for cases where a single seed customer is chosen, it seems possible that routes would be signi4cantly sub-optimal by the time they are close to the maximum distance. Therefore, re-optimising might allow an extra customer to be added to some of the routes. However, the tests described below do not support this theory. Initially, the RCL length was set to 2 and tests were carried out only for the 4rst-time application scenario, due to the small number of customers being added to routes during the interactive scenario. Results were compared with no re-optimisation, and with re-optimisation set to occur with each insertion after routes had reached 25%, 50%, 75%, 85%, 95% or 100% of the maximum distance, followed by (for the 4rst 4ve percentages) a 4nal re-optimisation when all customers were
330
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
allocated. The results showed that the 4nal re-optimisation had no eIect when re-optimisation was triggered at 75% or less. For the larger percentages, routes often never reached the distance at which re-optimisation would be triggered and, therefore, the 4nal re-optimisation had an eIect. It was found that re-optimisation has no signi4cant eIect on the average of the distances for 100 feasible solutions produced by GRASP, at any of the percentages used for the trigger. For the best distance from 100 feasible solutions, re-optimisation triggered at 85% was slightly better than the other levels for the trigger. With the trigger at 85%, the best distances averaged 2.08% above the best known values, over the seven problems, compared with 2.90% above the best known values with re-optimisation only at the end of each feasible GRASP iteration. The main points are as follows. Firstly, the extra distance due to adding a customer to a route is not changed much by re-optimising a route. Even with re-optimisation triggered at 95%, only 17% of re-optimisation calls produced an improvement and, at each of the percentages used as triggers, the average improvement was 6 0:7% of the route length. This is too small to have a signi4cant inOuence on the construction heuristic. Furthermore, in the 4rst-time scenario, the heuristic is more sensitive to the choice of seeds when there are distance constraints present, and it is quite common to 4nd that the chances of obtaining a feasible solution are improved by selecting two or more customers per route to give a petal shaped start for the heuristic. With this kind of outline route, the initial distance is a much larger percentage of the maximum distance, and routes are much less likely to become sub-optimal during the construction heuristic. Nevertheless, the study was conducted using a maximum of two customers chosen to form outline routes, and with at most 50% of routes being initialised with more than one customer. Where routes were initialised with two customers, they were chosen to be close together to keep the initial distance to a small percentage of the maximum distance. The only exceptions to this were the clustered problems 13 and 14, where it is necessary to choose customers in diIerent clusters for some routes to obtain feasible solutions. In conclusion, the best re-optimisation percentage was found to be 85%, although usually reoptimisation is only needed at the end for distance constrained problems. When the study turned to the RCL length for distance constrained problems, it was found that longer lists were more eIective than for problems without distance constraints. For the 4rst-time scenario, RCL lengths from 1 to 10 were tried, with re-optimisation at 85% of maximum distance, and with two to four customers chosen for each outline route. For the interactive scenario, the conditions were the same as those used without distance constraints. The Friedman test showed that changing the RCL length has a signi4cant eIect on the best solution obtained for both scenarios, with RCL lengths of 5 generally giving the best results in both cases. Table 1 summarises the parameter settings for the construction heuristic which gave the best results. Table 1 Best RCL lengths=re-optimisation strategies
First-time scenario Interactive scenario
Without distance constraints
With distance constraints
3=At end 2=At end
5=At 85% 5=At 85%
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
331
7. Computational study of local search phase parameters For this study, only the 4rst-time scenario was considered. The seeds used were the same as those used for the study reported in Section 6, with the parameter settings of Table 1. The distances were averaged over 100 feasible solutions produced using GRASP. Initially, the eIects of best-improve and 4rst-improve strategies were studied, trying all possible one-node and two-node interchanges at each iteration. Table 2 shows that both the average values and best solutions are improved by including the local search. The diIerence between the two move strategies is not signi4cant using the Wilcoxon test. As the 4rst-improve strategy is faster than the best-improve strategy, subsequent tests were carried out using only the 4rst-improve strategy. Four experiments were conducted with the p-neighbourhood reduction, consisting of the circular metric and the generalised savings metric combined with p = 5 and 10. Table 3 shows that all four combinations produce substantial reductions in the number of interchanges that are examined, with little deterioration in the quality of the results. The generalised savings metric produces a greater reduction in the number of interchanges considered, but the circular metric produces slightly better results. The diIerences are not statistically signi4cant. The larger size of p-neighbourhood gives a slight improvement in best solutions for three out of four cases, but not su2cient to justify the increased number of interchange candidates. Table 2 Comparison of move strategies for local search phase Move
Best-improve First-improve None a Per GRASP
Problems without distance constraints
Problems with distance constraints
Percentage above best known
Local search iterationsa
Percentage above best known
Local search iterationsa
Average
Best
One-node
Two-node
Average
Best
One-node
Two-node
1.0 0.9 1.8
4.9 3.6 —
8.6 5.4 —
3.8 3.8 4.5
1.4 1.2 1.8
3.3 1.8 —
1.9 0.7 —
2.7 2.8 4.0 iteration.
Table 3 Comparison of p-neighbourhood metrics for local search phase Metric
Problems without distance constraints
Problems with distance constraints
Percentage above best known Average Best
Interchange candidatesa
Percentage above best known Average Best
Interchange candidatesa
4254.5 7049.8 2056.0 4137.0 48671.6
3.8 4.0 4.3 4.1 3.8
1652.6 2718.4 787.6 1534.1 17065.0
Circular p = 5 2.8 Circular p = 10 2.9 Savings p = 5 3.2 Savings p = 10 3.1 Full search 2.8 a per GRASP iteration.
1.1 1.2 1.4 1.2 0.9
1.3 1.2 2.0 1.5 1.2
332
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
As a result of these tests, the 4rst-improve strategy, along with the circular metric and p = 5 were used as the default settings in CRUISE.
8. Computational results Using the default parameter settings and a Pentium II computer running at 300 MHz, each of the 14 benchmark problems described in Section 6 was the subject of an interactive session of at most 15 min duration using CRUISE. Table 4 shows the distances obtained during these sessions alongside well-known published results obtained using simulated annealing and tabu search [3– 6], and results obtained by Hjorring [18] using GRASP. The distances for all approaches in Table 4 were calculated as real values without truncation. The full routes corresponding to the CRUISE solutions are given by Carreto [19]. The distances obtained using CRUISE are, on average, 0.84% above the best tabu search results from Taillard [4], and Rochat and Taillard [6], but compare favourably with the results of the other authors. It should be noted that the solutions with smallest distance reported for problems 5 and 14 use one extra vehicle, which could be an expensive alternative in the real world. CRUISE allows the user to experiment with the number of vehicles and decide which solution is preferable, taking into account 4xed costs of vehicles. In the case of problem 14, where customers are in clusters, with only 10 vehicles the constraints are tight, and our best solution required several vehicles to visit more than one of the clusters. Using 11 vehicles the problem is much easier to solve, and we reduced the distance from 902.81 to 867.92, which is within 0.18% of the result from Taillard [4]. In a separate experiment, we recorded the time to produce 100 feasible solutions using GRASP, in the 4rst-time scenario as described in Section 6. A slightly faster computer was available for this experiment (Pentium II 500 MHz). The times obtained are shown in the last column of Table 4. These times include all associated procedures, such as loading and saving information held in 4les and updating the display each time an improved solution is found. In some cases, where constraints are tight, the number of GRASP iterations will be ¿ 100, as some iterations may not produce a feasible solution. Since the incidence of infeasible solutions depends on the choice of seeds or outline routes, diIerent times could result from diIerent choices. In practice, the user would often choose to stop the process earlier.
9. Conclusion A visual interactive system, CRUISE, has been developed which is easy to use, with a Windows interface of the kind that will be familiar to most computer users. The tools which have been programmed into CRUISE provide considerable Oexibility, allowing users to combine their insights, knowledge and judgement with the power of the computer to perform modern heuristics at high speed. Interactive sessions of at most 15 min gave results within 1%, on average, of the best results obtained using tabu search. This approach is likely to appeal to schedulers who wish to retain some control over the routes that are adopted, especially if there are local constraints on route structure that need to be taken into consideration.
528 838 829 1058 1376 555 909 866 1164 1418 1176 826 1545 890h
524=524 844=844 838=835 1044=1052 1334=1354 555=555 911=913 878=866 1184=1188 1441=1422 1043=1042 819=819 1545=1547 866=866h
524.61 835.32 826.14 1031.07 1311.35h 555.43 909.68 865.94 1162.89 1404.75 1042.11 819.56 1545.93 866.37h
524.61 845.50 829.34 1052.37 1342.74h 555.43 917.06 867.58 1181.13 1460.06 1045.30 820.92 1551.19 901.01 Average
524.61 839.36 830.16 1040.67 1336.55 555.43 909.68 865.94 1171.62 1407.14 1042.11 819.56 1546.55 902.81
0.84
0.00 0.49 0.49 1.19 3.49 0.00 0.00 0.00 0.78 0.81 0.00 0.00 0.35 4.21
16 45 58 101 334 21 102 52 537 956 158 80 84 120
Gendreau et al.d Hjorringe CRUISEf % gap GRASPg (TABUROUTE) (GRASP) (interactive) times
Simulated annealing by Osman [3]. b Tabu search + First-best-admissible=best-admissible by Osman [3]. c Tabu search by Taillard [4]=Tabu search by Rochat and Taillard [6]. d Tabu search by Gendreau et al. [5]. e GRASP by Hjorring [18]. f CRUISE—computerised routing using interactive seed entry and % above best tabu search result. g Seconds to produce 100 feasible solutions using GRASP (Pentium II 500 MHz). h Uses an extra vehicle.
a
5 10 8 12 16 6 11 9 14 18 7 10 11 10
524.61 835.26 826.14 1028.42 1298.79=1291.45h 555.43 909.68 865.94 1162.55 1397.94=1395.85 1042.11 819.56 1541.14 866.37h
0=∞ 0=∞ 0=∞ 0=∞ 0=∞ 10=200 10=160 10=230 10=200 10=200 0=∞ 0=∞ 50=720 90=1040
50 75 100 150 199 50 75 100 150 199 120 100 120 100
160 140 200 200 200 160 140 200 200 200 200 200 200 200
Taillard=Rochatc (TS)
Cities Capacity Drop allowance = Vehicles Osmana Osmanb distance limit (SA) (TS)
Table 4 Comparison of visual interactive approach with published results
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337 333
334
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
The system oIers scope for further development to vehicle routing problems that include backhauls or time windows for example, and research within these areas is already underway. Another area of interest which will be pursued is the incorporation of a learning strategy in the construction heuristic. Although the straightforward GRASP approach has proved eIective, we will investigate whether a learning strategy could be used to improve performance. For increased practicality, further development could integrate the program with a Geographic Information System. A road map could be displayed as a background image, with no signi4cant changes to the existing program code being needed. We believe that the user could identify outline routes eIectively and apply the interactive techniques in much the same way as we have done for the benchmark problems, which are restricted to Euclidean distances. Although the user should be able to see from the map display if customers that are separated by a short straight line distance are actually far apart on the road system, it could be that the user’s experience and local knowledge would become even more relevant to this kind of problem. Thus, there is considerable scope for further research and development arising from the work described in this paper. Appendix. Algorithm 1. Greedy randomised adaptive search procedure (GRASP) De4ne Cf (x ) to be the total distance for the solution x if x is feasible, and Ci (x ) to be the total weight unallocated for the solution x if x is infeasible.
begin user selects initial seeds; best feasible cost = ∞; best infeasible cost = ∞; repeat start with the initial seeds; construct greedy randomised solution x; find local minimum x starting from x; if (x is feasible) if (Cf (x ) ¡ best feasible cost) { x∗ = x ; best feasible cost = Cf (x ); display x∗ ; } else if ((Ci (x ) ¡ best infeasible cost) and (x∗ = R)) { x∗∗ = x ; best infeasible cost = Ci (x ); display x∗∗ ; } until (stopping criterion is true) end
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
Algorithm 2. The construction phase
begin initialise crj and Prj for each unallocated customer j and route r; initialise Dj and Rj for each unallocated customer j; initialise R0 , R1 and R2 ; while (customer allocations are still possible) { if (R0 ¿ 0) and (a feasible solution has been previously found) terminate construction phase; if (R1 ¿ 0) j ∗ = customer j with largest Dj and Rj = 1; else j ∗ = random selection from RCL; ∗ r =argmin (crj∗ ); insert customer j ∗ in position Pr ∗ j∗ ; mark customer j ∗ as being allocated; update remaining capacity and distance for route r ∗ ; apply 3-optimal to route r ∗ if necessary; update cr ∗ j , Pr ∗ j , Dj and Rj for each unallocated customer j; update R0 , R1 and R2 ; } apply 3-optimal to each route; end Algorithm 3. Construction of and selection from the Restricted Candidate List (RCL)
begin T = {unallocated customers with Rj = 2}, (R2 = |T |); if (R2 = 0) { if (more than k customers remain unallocated) construct RCL with k customers with largest Dj ; else construct RCL with all unallocated customers; assign probabilities proportional to demands; j ∗ = customer selected randomly from RCL; } else if (R2 = 1) j ∗ = element in T ; else { if (R2 ¿ k) construct RCL with k customers in T with largest Dj ; else construct RCL with all customers in T ; assign probabilities proportional to demands; j ∗ = customer selected randomly from RCL; } end
335
336
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
Algorithm 4. Updating cr ∗ j and Pr ∗ j De4ne aj to be the drop allowance for customer j.
begin for (each unallocated customer j); if (wj ¿ remaining delivery capacity of route r ∗ ) cr ∗ j = ∞; else if (Pr ∗ j = Pr ∗ j∗ ) { calculate cr ∗ j with respect to new links; update cr ∗ j if necessary; if (cr ∗ j + aj ¿ remaining delivery distance for route r ∗ ) cr ∗ j = ∞; else if (there is an improvement) update Pr ∗ j ; else if (Pr ∗ j ¿ Pr ∗ j∗ ) increase Pr ∗ j by 1; } else { recalculate cr ∗ j for all possible Pr ∗ j ; record new values for cr ∗ j and Pr ∗ j ; if (cr ∗ j + aj ¿ remaining delivery distance for route r ∗ ) cr ∗ j = ∞; } end References [1] Laporte G. The vehicle routing problem: an overview of exact and approximate algorithms. European Journal of Operational Research 1992;59:345–58. [2] Laporte G, Osman IH. Routing problems: a bibliography. Annals of Operations Research 1995;61:227–62. [3] Osman IH. Metastrategy simulated annealing and tabu search algorithms for the vehicle routing problem. Operations Research 1993;41:421–51. S Parallel iterative search methods for vehicle routing problems. Networks 1993;23:661–73. [4] Taillard E. [5] Gendreau M, Hertz A, Laporte G. A tabu search heuristic for the vehicle routing problem. Management Science 1994;40:1276–90. S Probabilistic diversi4cation and intensi4cation in local search for vehicle routing. Journal of [6] Rochat Y, Taillard E. Heuristics 1995;1:147–67. [7] Hiquebran DT, Alfa AS, Shapiro A, Gittoes DH. A revised simulated annealing and cluster-4rst route-second algorithm applied to the vehicle routing problem. Engineering Optimization 1994;22:77–107. [8] Fisher ML, Jaikumar R. A generalized assignment heuristic for vehicle routing. Networks 1981;11:109–24. [9] Baker BM. Further improvements to vehicle routing heuristics. Journal of the Operational Research Society 1992;43:1009–12. [10] Baker BM, Sheasby JE. Extensions to the generalized assignment heuristic for vehicle routing. European Journal of Operational Research 1999;119:147–57.
B.M. Baker, C.A.C. Carreto / Computers & Operations Research 30 (2003) 321 – 337
337
[11] Lin S. Computer solutions of the travelling salesman problem. Bell Systems Technical Journal 1965;44:2245–69. [12] Yellow PC. A computational modi4cation to the savings method for vehicle scheduling. Operational Research Quarterly 1970;21(2):281–3. [13] Friedman M. The use of ranks to avoid the assumption of normality implicit in the analysis of variance. Journal of the American Statistical Association 1937;32:675–701. [14] Wilcoxon F. Individual comparison by ranking methods. Biometrics 1945;1:80–3. [15] Zar J. Biostatistical analysis, 4th ed. Englewood CliIs, NJ: Prentice Hall, 1998. [16] Christo4des N, Mingozzi A, Toth P. The vehicle routing problem. In: Christo4des N, Mingozzi A, Toth P, Sandi C, editors. Combinatorial optimization. New York: Wiley, 1979. p. 315–338. [17] Beasley JE. OR-library: distributing test problems by electronic mail. Journal of the Operational Research Society 1990;41:1069–72. [18] Hjorring CA. The vehicle routing problem and local search metaheuristics. PhD thesis, University of Auckland, 1995. [19] Carreto CAC. Visual interactive methods for vehicle routing. PhD thesis, Coventry University, UK, 2000. Barrie M. Baker holds a BSc in Mathematics and an MSc and Ph.D. in Operational Research, all from London University. He is a member of the academic staI at Coventry University, and his main interests are in network and distribution modelling and spreadsheet modelling. Carlos Carreto holds a Bacharelato and Licenciatura in Computer Science from Instituto PolitSecnico da Guarda, Portugal, and gained a Ph.D. from Coventry University researching modern heuristic methods. He is a member of the academic staI at Instituto PolitSecnico da Guarda, where his main interests are in heuristics and graphics programming.