An Adaptive Large Neighborhood Search Heuristic for the Pickup and Delivery Problem with Scheduled Lines Veaceslav Ghilas*, Emrah Demir and Tom Van Woensel School of Industrial Engineering, Operations, Planning, Accounting and Control (OPAC), Eindhoven University of Technology, Eindhoven, 5600 MB, The Netherlands
Abstract Integrating freight flows with public scheduled transportation creates attractive business opportunities because the same transportation needs can be met with less traveling time and fewer emissions. The Pickup and Delivery Problem with Scheduled Lines (PDP-SL) concerns scheduling a set of vehicles to serve the requests such that a part of the journey can be carried out on a scheduled public transportation line using bus, train, tram, metro, etc. Due to the complexity of the problem, which is NP-hard, we propose an Adaptive Large Neighborhood Search (ALNS) heuristic algorithm to solve the PDP-SL. Complex aspects such as the fixed lines’ schedules and synchronization constraints are efficiently considered in the proposed algorithm. Results of extensive computational experiments show that ALNS is highly effective in finding good-quality solutions on the generated PDP-SL instances with up to 100 freight requests that reasonably represent real life situations. Keywords: pickup and delivery problem, heuristic algorithm, scheduled lines, freight transportation
1. Introduction A successful integration of passenger and freight transportation creates a seamless movement for people and freight. This integration achieves socially desirable transport options economically viable in urban areas as it reduces the impact of congestion and air pollution (Lindholm and Behrends [1]). Actual integration is already being observed in long-haul freight transportation: passenger aircraft and ferries. For example, Norwegian Hurtigruten carry freight and people efficiently and seamlessly in the region of Northern Europe (Levin et al. [2], Hurtigruten [3]). In short-haul transportation, however, people and freight rarely share the same transportation mode, although they largely use the same infrastructure. To our knowledge, Trentini et al. [4] is one of the few works that have investigated integrated transport solution to short-haul transportation. In Email address: V.Ghilas@tue.nl, E.Demir@tue.nl, T.v.Woensel@tue.nl (Veaceslav Ghilas*, Emrah Demir and Tom Van Woensel) * Corresponding author, Tel. +31 40 247 4984 Preprint submitted to Computers & Operations Research
28th August, 2014
particular, the authors investigated a two-echelon VRP with transshipments in the context of passenger and freight integrated system. They propose to use public transportation to ship the goods from a central distribution center to predefined stations (transshipment points) and from there, a number of tricycles are used to deliver products to their final destinations. The authors propose an ALNS heuristic to solve the problem. In this paper, we particularly investigate the opportunities and challenges to make use of available public transportation services that operate according to predetermined routes and schedules as a part of the freight journey. Hence, a parcel may be collected by a pickup and delivery (PD) vehicle and transferred to scheduled lines. In such case, the request can be recollected by another PD vehicle and delivered to its final destination. To consider such situation, we specifically consider an extension of the Pickup and Delivery Problem with Time Windows (PDP-TW) in which transfers of any request to scheduled lines is permitted. A part of the request’s journey can thus be carried out on a public scheduled transportation. Both direct and indirect flows are considered. The first one represents the case where a request uses only door-to-door transportation (by using a PD vehicle). The latter represents the situation where a request is transported by a scheduled line as a part of the total journey. We denote this specific transportation problem as Pickup and Delivery Problem with Scheduled Lines (PDP-SL). We consider two scenarios: (i) the integrated transportation system and (ii) the pickup and delivery environment, where transfers to scheduled lines are not allowed. These two scenarios are intended to provide a plausible and sufficient reason to implement such system by comparing them in terms of the total operating costs and the total travel time of the PD vehicles. The PDP-SL is NP-hard since it is an extension of the classical PDP-TW. It is shown that only a limited number of requests can be solved to optimality within a reasonable time limit. For this reason, we have developed a metaheuristics to obtain good-quality solutions within short computational times. More specifically, we propose an Adaptive Large Neighborhood Search heuristic algorithm, based on the destroy and re-create principle, to solve the PDP-SL. A successful synchronization of PD vehicles with scheduled public transportation is directly related to coordination (or timing), which is the key factor that makes each leg’s movement precise, well-timed, and well organized. This important feature is carefully studied in the algorithm so that the movement of parcels is relatively seamless and straightforward. Moreover, destroy and insertion operators, discussed in the literature, are adapted to the PDP-SL and extensive computational experiments on small to large instances are performed to quantify the benefits of the proposed system. The contributions of the paper are three-fold: (i) we introduce the idea of integrating scheduled lines with PD vehicles for the small-sized parcel transportation, (ii) we adapt the classical ALNS heuristic algorithm to solve PDP-SL, and (iii) we efficiently handle complex constraints (synchronization, schedules) within the proposed ALNS framework. The remainder of this paper is organized as follows. In Section 2, we present the mathematical formulation of the PDP-SL. Section 3 describes the proposed ALNS heuristic algorithm for the PDP-SL. Section 4 presents the results of extensive numerical experiments. Conclusions are stated in Section 5.
2
2. Pickup and delivery problem with scheduled lines As aforementioned, the PDP-SL is an extension of the standard PDP, but additionally considers the flexibility of using available scheduled lines, such as bus, train, metro, etc. Due to the fact that public transportation systems have a certain coverage (i.e., rural or urban), some delivery trips of the PD vehicles may overlap with the scheduled line (SL) services. Ultimately, using public transportation may lead to cost and environmental benefits for the whole transportation system. For instance, due to less driving time of their PD vehicles, logistics service providers may experience substantial operating cost savings. As a consequence, less travel time of the vehicles also leads to fewer carbon dioxide equivalent (CO2 e) emissions, at the global level, for the whole society. On the other hand, using scheduled lines for carrying freight gives extra cost benefits for the public transport service provider as the utilization of SL vehicles increases. An example of the application for PDP-SL can be illustrated as in Figure 1, where it shows the current metro system in Amsterdam, the Netherlands.
T150
d2
o3
T151 T154
T153
T253
o2
T250
T254
d3 o1
d1
T251
Legends
ox
Origin of package x
dx
Destination of package x Depot
Figure 1 An illustration of the metro system in Amsterdam (2014)
The system depicted in Figure 1 contains four scheduled lines, and five transfer points (end-of-lines stations). Note that T 151 , T 153 , T 154 , as well as T 250 and T 254 can be merged into two transfer points as these denote the same locations. Each metro line has one single route with two destinations in either direction. To use this metro system as a part of the transportation plan, package(s) can be delivered to one of its end-of-line stations and transported to other side of the line considering the available capacity and time schedules of the metro line. Note that each station-hub is considered as a consolidation point for requests (e.g., DHL-Packstation [5]). In other words, a storage space
3
for packages that need to be shipped to/from a scheduled line is available. Therefore, packages can be securely stored until their departure time at the transfer stations. 2.1. Formal description of the PDP-SL In this section, we give a formal description of the PDP-SL. A solution to the problem is a routing plan for the PD vehicles, such that all requests are served. Additionally, time schedules of PD vehicles and requests are produced. We now briefly describe the important features of the PDPSL. • Request. A request r has an origin, or , and a destination, dr . Each request is associated with two desired time windows, one for the origin ([lor , uor ]), and one for the delivery point ([ldr , udr ]). The set of all requests is given as P, such that request r, has destination node (or + n), where n shows the total number of requests. Furthermore, demand quantity hr is assumed to be known for each request. • Vehicle. A set of vehicles is given by V. In addition, each vehicle v has the information of carrying capacity ev and its origin gv . • Time. Travel and service times are known in advance and remain unchanged during the planning horizon. The travel time between nodes i and j is denoted by ci j and service time at node i is represented as si . • Fixed line. A set of all scheduled lines is given as E, which is defined by the arc between start and end of the line (i, j). In addition, each scheduled line has a set of departure times K i j from i (i.e., the start of scheduled line), such that the departure is given as pwij , ∀ w ∈ K i j , (i, j) ∈ E. Note that each SL may have different frequencies than other lines, thus the size of the K i j may differ. Furthermore, it is assumed that SL vehicles are designed to carry a limited amount of packages, thus implying a finite carrying capacity ki j , ∀ (i, j) ∈ E. We define a digraph G = (N, A), where N represents a set of nodes and A represents a set of arcs. Each physical station-hub is replicated n times (n - the number of requests) as in Hall et al. [6] and each replicated scheduled line is assigned a request. In particular, only the assigned request can use its corresponding replicated scheduled line. In addition, the following notations are used in the model formulation: d is the number of depots, τ - the number of replicated station-hubs. Moreover, a parameter fir is equal to 1 if node i is the destination node of request r, to 0 if the node is intermediate node and finally to -1 if i is the origin of r. Furthermore, parameters θ and η are the weights in the objective function of PD routes, and the cost of shipping one package on a scheduled line, respectively. The definition of each set is provided in Table 1. Table 1 Sets
Notation
Definition
P D Q T N Ot R1
Set of pickup nodes, P ≡ [d + 1, ..., d + n] Set of drop-off nodes, D ≡ [d + n + 1, ..., d + 2n] Set of depots, Q ≡ [1, ..., d] Set of replicated transfer nodes (station-hubs), T ≡ [d + 2n + 1, · · · , d + 2n + nτ] Set of nodes in graph G; P ∪ D ∪ Q ∪ T ≡ N Set of replicated transfer nodes associated with physical transfer node t Set of nodes that represent requests (P ∪ D)
4
Table 1 Continued Sets
Notation
Definition
R2 R3 A1 A2 A3 A4 A5 A
Set of nodes that represent requests and depots (P ∪ D ∪ Q) Set of nodes that represent requests and station-hubs (P ∪ D ∪ T ) Set of arcs (i, j) in G, ∀ i, j in R1 Set of arcs (i, j) in G, ∀ i in R1 and ∀ j in T Set of arcs (i, j) in G, ∀ i in T and ∀ j in R1 Set of arcs (i, j) in G, ∀ i in T and ∀ j in Oi ≡ A1 ∪ A2 ∪ A3 ∪ A4 Set of arcs in G defined by arc (i, j), ∀ i, j ∈ N, (note that A \ A5 ≡ F ∪i∈Q, j∈R3 (i, j)∪i∈R3 , j∈Q (i, j)) Set of PD vehicles Set of replicated scheduled lines that are defined as (i, j), with associated Zi j Set of departure times from replicated station-hub i on scheduled line (i, j) ∈ F Set of replicated scheduled lines associated with a request r Set of replicated scheduled lines connected to a station-hub t Set of replicated scheduled lines associated with a physical scheduled line (i, j) ∈ E
V F Zi j Fr Ft F ij
The decision variables used to handle the routing of the PD vehicles are denoted as xivj , which are binary variables equal to 1 if arc (i, j) is used by a PD vehicle v, 0 otherwise, ∀ (i, j) ∈ A, v ∈ V. The scheduling of the PD vehicles is shown with αv , continuous variables which indicate the time at which vehicle v returns to its depot, ∀ v ∈ V and continuous variables βi which indicate the departure time of a PD vehicle from node i, ∀ i ∈ N. The flow of the requests is given as yrij , which are binary variables equal to 1 if arc (i, j) is used by request r, 0 otherwise, ∀ i, j ∈ R3 , r ∈ P. The schedules of the requests are represented by the continuous variables γir that show the time that request r departs from node i, ∀ i ∈ R3 , r ∈ P. Fixed line decisions are shown by qrw i j , that are binary variables equal to 1 if replicated scheduled line (i, j) is used by request r and departs from i at time pwij , 0 otherwise, ∀ r ∈ P, (i, j) ∈ F r , w ∈ Zi j . 2.2. Mathematical formulation of the PDP-SL The PDP-SL can be formulated as the following mixed-integer formulation:
min
θ
X
X
+η
X
(i, j)∈A
v∈V
X r∈P
(i, j)∈F r
ci j xivj X w∈Zi j
(1) qrw ij
(2)
subject to
X
X i∈N
X i∈N
xivj
=
1
∀ j ∈ R1
(3)
xgv v ,i
≤
1
∀v ∈ V
(4)
xitv
≤
1
∀t ∈ T
(5)
v∈V
X i∈R X
3
v∈V
5
X X
X
xvji
=
0
∀i ∈ N, v ∈ V
(6)
yrij − yr j∈R3 ji X X xv i∈N v∈V it X hr yrij
=
fir X
∀r ∈ P, i ∈ R3
(7)
∀t ∈ T
(8)
≤
X
∀(i, j) ∈ A5
(9)
γrj
≥
∀r ∈ P, i, j ∈ R3
j∈N
xivj −
j∈N
X
j∈R3
r∈P
li
v∈V
yrij
ev xivj
βj
≥
αv
≥
βi + ci j + s j − M1i j (1 − xivj )
∀i ∈ R3 , j ∈ Q, v ∈ V
(12)
βi + ci,i+n + si+n
≤
βi+n
∀i ∈ P
(13)
xv ) v∈V i j
∀i ∈ N, j ∈ R
(10)
3
(11)
βi − si
≤
ui
∀i ∈ R
lgv ≤ αv − sgv X qrw ij ij
≤
u gv
∀v ∈ V
=
yrij
∀r ∈ P, (i, j) ∈ F r
≤
M2i (2
≤
γir X r∈P
(i, j)∈F t
r∈P
γir + ci j + s j − M1i j (1 − yrij ) X βi + ci j + s j − M1i j (1 −
w∈Z γir −
X
≤
X
(a,b)∈F i j
pwij pwij
≥
−
hr qrw ab
≤
ki j
−
γir − βi
≤
−
M2i (2
M2i (1 −
qrw ij −
−
yrij )
qrw ij
−
X j∈R1
1
(14) (15) (16)
∀r ∈ P, (i, j) ∈ F , w ∈ Z
(17)
∀r ∈ P, (i, j) ∈ F , w ∈ Z
(18)
∀(i, j) ∈ E, w ∈ K i j
(19)
∀r ∈ P, i ∈ T
(20)
∀r ∈ P, i ∈ T
(21)
∀r ∈ P, i ∈ R1
(22)
∀r ∈ P, i ∈ R1
(23)
∀r ∈ P
(24)
∀r ∈ P
(25)
r
ij
r
yrij )
yrij )
X
ij
γir − βi
≥
γir − βi
≤
γir − βi
≥
γdr r − βdr
≤
γdr r − βdr
≥
− M2i (1 − yr ) j∈R1 i j X M2i (1 − yr ) j∈R3 i j X − M2i (1 − yr ) j∈R3 i j X M2dr (1 − yr ) i∈R3 i,dr X − M2dr (1 − yr ) 3 i,dr
γtr − βt
≤
M2t (1 − yrt j )
∀r ∈ P, t ∈ T , j ∈ Ot
(26)
− βt
≥
−
M2t (1
∀r ∈ P, t ∈ T , j ∈ O
(27)
xivj
∈
{0, 1}
∀(i, j) ∈ A, v ∈ V
(28)
yrij
∈
{0, 1}
∀i, j ∈ R3 , r ∈ P
(29)
∈
+
∀v ∈ V
(30)
∀i ∈ R , r ∈ P
(31)
γtr
αv γir βi qrw ij
∈ ∈ ∈
i∈R
−
t
yrt j )
R
+
3
R
R
+
∀i ∈ N
(32)
∀r ∈ P, (i, j) ∈ F , w ∈ Z r
{0, 1}
ij
(33)
The objective function is the total operating costs, including traveling cost of the PD vehicles (1) and the total cost of using the scheduled lined services (2). Constraints (3) assure that all nodes related to the requests (pickup and drop-off nodes) are visited exactly once. Constraints (4) make sure that each vehicle leaves its depot at most once, and (5) assure that each replicated transfer node is visited at most once. Flow conservation for PD vehicles is considered in constraints (6). Constraints (7) assure flow conservation for the paths of each request. Constraints (8) ensure 6
that if a request uses a scheduled line, a PD vehicle should pick it up/drop it off at a station-hub related to that specific scheduled line. Constraints (9) force the capacity of each PD vehicle is not exceeded. Scheduling for each request and each PD vehicle is considered in constraints (10) – (12). Constraints (13) assure that the pickup node is visited before the drop-off node of each request and (14), (15) force the time windows to be respected. Constraints (16) – (18) assure that if a request uses a scheduled line, it departs at a scheduled departure time. Constraints (19) ensure that the package carrying capacity of the scheduled lines is not exceeded. Constraints (20) – (27) assure the synchronization between requests and PD vehicles. The domains of the decision variables are defined in (28) – (33). Note that M1i j can be substituted by (ui + si + s j + ci j ) and (ui + si ) can be used instead of M2i . 3. An Adaptive Large Neighborhood Heuristic Algorithm for the PDP-SL The proposed metaheuristic is an extension of the Large Neighborhood Search (LNS) heuristic, which is first proposed by Shaw [7]. The LNS is based on the idea of gradually improving an initial solution by using both destroy and repair neighborhood operators. In other words, LNS consists of a series of removal and insertion moves. If a new solution is better than the current best solution, it replaces it and uses it as an input in the next iteration. Moreover, the LNS heuristic can be embedded within any local search heuristic such as simulated annealing or tabu search. 3.1. Adaptive large neighborhood search The ALNS heuristic framework was introduced by Pisinger and Røpke [8], Røpke and Pisinger [9], Pisinger and Røpke [10] to solve several variants of the vehicle routing problem. Instead of using one large neighborhood as in LNS, the algorithm applies several removal and insertion operators to a given solution. The neighborhood of a given set of feasible routes is investigated by removing some requests and reinserting them back to the solution. The removal and insertion operators are dynamically selected according to their past and current performance. To this end, each operator is assigned a score, which is increased whenever it improves the current solution. The new solution is accepted if it satisfies some criteria defined by the defined local search framework (e.g., simulated annealing, tabu search) applied at the outer level. In the following sections, the main features of the proposed ALNS algorithm are provided in detail. 3.1.1. Initialization stage A greedy insertion heuristic is used to obtain a feasible initial solution to the PDP-SL. It is noteworthy that the quality of the initial solution is insignificant since a poor solution can be easily improved due to the dynamic nature of the algorithm. The feasibility is assured by considering the capacity of the PD and SL vehicles, synchronization of the transport operations along with time-window constraints of the requests. 3.1.2. Adaptive score adjustment procedure The selection of the removal and insertion operators is controlled by a roulette-wheel mechanism. Initially, all removal or insertion operators are equally weighted (e.g., for 10 considered removal 7
and 10 insertion operators, the probabilities are set to 0.1). During the course of the algorithm, t these scores are updated as Pt+1 d = Pd (1 − r p ) + r p πi /ωi , where r p is the roulette wheel parameter, πi is the score of operator i and ωi is the number of times it was used during the last Nw iterations. The score of each operator measures how well the operator has performed at each iteration. If a new best solution is found, the score of a removal and insertion operators is increased by σ1 . If the solution is better than the current solution, the score is increased by σ2 . If the solution is worse than the current solution but accepted, the score is increased by σ3 . 3.1.3. Removal stage Ten removal operators are used in our ALNS heuristic algorithm. All operators are adapted from or inspired by Shaw [7], Røpke and Pisinger [9] and Demir et al. [11]. The removal stage mainly consists of removing r requests from the current solution and adding them to so-called removal list L. A pseudo-code of the removal procedure is presented in Algorithm 1. The algorithm is initialized with a feasible solution X as input and returns a partially destroyed solution. The parameter φ defines the number of iterations of the search. In Algorithm 1, a chosen operator is used to remove a subset R of requests from the solution. These requests are inserted in a removal list L. Algorithm iterates in a similar manner for φ iterations. Algorithm 1: The overall structure of the removal operators input : A feasible solution X, and maximal number of iterations φ output: A partially destroyed solution X p 1 2 3 4
Initialize removal list (L ← ∅) for φ iterations do Apply remove operator to remove a request r (includes two nodes: pickup and delivery) L←L∪r
The removal operators used in our implementation are introduced below. • Random Removal (RR): This operator randomly removes r requests from the solution, and runs for φ = s iterations, s ∈ [s, s], where s and s are the lower and the upper limits of the removed requests. The idea of randomly selecting nodes helps diversifying the search space. The worst-case time complexity of the RR operator is found to be O(|P|). • Route Removal (ROR): This operator removes a full route from the solution. It randomly selects a route from the set of routes in the solution. The remove operator then repeatedly selects a node j from this route until all nodes are removed. The corresponding node of j, i.e. its pickup or drop-off node, is removed irrespective of which routes it is positioned in. The ROR operator can be implemented in O(P) worst-case time. • Worst-Time Removal (WTR): For each request r, this operator calculates the deviation of service start time from time lor and ldr , and then removes the request with the largest deviation (i.e. r∗ = argmaxr∈P {|[βor − sor − lor ] + [βdr − sdr − ldr ]|}, where β x is the departure time from node x). The idea is to prevent long waits or delayed service start times. The algorithm starts with an empty removal list, and runs for φ = s iterations. The worst-case time complexity of the WTR operator is O(|P|2 ).
8
• Worst-Distance Removal (WDR): This operator iteratively removes high-cost customers, where the cost is defined as the sum of distances from the preceding and following nodes on the tour of both, the pickup and the delivery nodes of a request, i.e. it removes node r∗ = argmaxr∈P {|ci,or + cor ,k + c j,dr + cdr ,m |}. The worst-case time complexity of the WDR operator is O(|P|2 ). • Shaw Removal (SR): The objective of the SR operator is to remove a set of customers that are related in a predefined way and therefore are easy to change. The algorithm starts by randomly selecting a request r and adds it to the removal list. Let lr,r1 = −1 if any two nodes related to r and r1 (i.e. origin or destination nodes) are in the same route, and 1 otherwise. The operator selects the request r∗ = argminr∈P {Π1 [cor ,or1 + cdr ,dr1 ] + Π2 [|βor − βor1 | + |βdr − βdr1 ]| + Π3 lr,r1 + Π4 |hr − hr1 |}, where Π1 –Π4 are weights that are normalized to find the best candidate from the considered solution. The operator is applied φ = s2 times by selecting a request not yet in the removal list which is most similar to the one last added to the list. The worst-case time complexity of the SR operator is O(|P|2 ). • Proximity-Based Removal (PR): The operator removes a set of requests that are related in terms of distance. This operator is a special case of the Shaw removal operator with Π1 = 1, and Π2 = Π3 = Π4 = 0. The worst-case time complexity of the PR operator is O(|P|2 ). • Demand-Based Removal (DR): This operator is a special case of the Shaw removal with Π4 = 1, and Π1 = Π2 = Π3 = 0. The worst-case time complexity of the DR operator is O(|P|2 ). • Time-Based Removal (TR): The operator is a special case of the Shaw removal with Π2 = 1, and Π1 = Π3 = Π4 = 0. The worst-case time complexity of the TR operator is O(|P|2 ). • Historical knowledge node Removal (HR): This operator keeps a record of the position cost of every request r, defined as the sum of the distances between its preceding and following nodes of its origin and destination nodes, and calculated as cr = ci−1,or + cor ,i+1 + c j−1,dr + cdr , j+1 at every iteration of the algorithm. Note that i − 1 and j − 1 are the preceding nodes of the origin and, respectively, destination nodes of r in their corresponding routes and i + 1 and j + 1 are their successors. At any point in the algorithm, the best position cost c∗r of request r is updated to be the minimum of all c x values calculated until that point. The HR operator then picks the request r∗ with maximum deviation from its best position cost, i.e. r∗ = argmaxr∈P {cr − c∗r }. Request r∗ is then added to the removal list. The worst-case time complexity of the HR operator is O(|P|). • Worst Removal (WR): This operator removes r requests with the highest cost. The cost in this case is computed as follows: given a solution, the cost of a request r is the difference in the objective function between the current solution (with r) and the same solution without serving r. Note that the difference between WR and WDR is that WR uses the total cost (including transfer cost) of the requests as objective, whereas WDR focuses only on the distance. 3.1.4. Insertion stage Five insertion operators are used in the proposed ALNS heuristic algorithm. The aim of these operators is to repair a partially destroyed solution by reinserting the requests from the removal list (L) back into the existing routes. The general schematic overview of an insertion procedure is shown in Algorithm 2. 9
∗ Algorithm 2: The generic structure of an insertion i∗ (Xnew , L, Xcurrent ) procedure ∗ input : A partially destroyed current solution Xnew , a list of removed requests L, current solution Xcurrent output: A feasible solution obtained after the insertion procedure 1 2 3 4 5 6 7 8 9 10 11 12
13 14 15 16 17
for (each request r in L) do Xnew ← NULL ∗ c(Xnew ) ← +∞ for (each positions within the routes Q and M) do Insert or and dr in positions q and m, respectively if (Q , M) then ∗ (Xt , to∗r , td∗r ) ← repairTransfers(Xnew , r, T r ) else ∗ Xt ← Xnew if (scheduleCheck(Xt ) AND feasibleCapacity(Xt )) then if (acceptance criteria of i∗ is satisfied) then Xnew ← Xt if (Xnew , NULL) then ∗ ← Xnew Xnew else return Xcurrent ∗ return Xnew
The feasibility with regards to the capacity, scheduling and time windows is always maintained. Note that checking the feasibility is not trivial, as the pickup and drop-off nodes of the same request can be located in different PD routes, and hence must use at least one scheduled line. Thus, such partial solutions need to be repaired with respect to transfer nodes. Therefore, repairTransfers(X, r, T r ) procedure is run to insert the corresponding replicated transfer nodes in a greedy fashion. Note that similarly to the proposed MIP, each original transfer point is replicated n (number of requests) times, hence each request gets assigned a list of replicated transfer nodes. The overview of the repair mechanism is shown in Algorithm 3. Algorithm 3: The generic structure of the repairTransfers(X, r, T r ) procedure input : A partial solution X, a request r and T r replicated transfer nodes related to r output: A feasible solution Xt and the origin and the destination transfer nodes (to∗r , td∗r ) of r in the current solution Xt 1 2 3 4 5 6 7
Q ← the route related to or M ← the route related to dr to∗r ← transfer node ∈ T r with the cheapest insertion in route Q, sequenced after or T r = T r \ to∗r td∗r ← transfer node ∈ T r with the cheapest insertion in route M, sequenced earlier than dr Xt ← updated X given minimal cost insertions of to∗r and td∗r return (Xt , to∗r , td∗r )
A transferable request r, during the repairTransfers(X, r, T r ) procedure in Algorithm 3, is assigned two related replicated transfer nodes: to∗r , origin transfer node, and td∗r , destination transfer node. In addition to that, a scheduled line flow path is generated for request r by using Dijkstra’s shortest 10
path algorithm (Dijkstra [12]), i.e. with the minimal total traveling time. In particular, on the related scheduled line sub-graph, we generate a shortest path from to∗r to td∗r . This path is used to update the corresponding timing variables, such that the schedules of the scheduled lines are considered. In other words, the departure time from td∗r is calculated in order to correctly verify the synchronization and scheduling constraints. Note that after each insertion, every transferable request gets an updated flow path, i.e. from or to dr , including the transfer line (e.g., or , ..., to∗r , ..., td∗r , ..., dr ). We now briefly define the five insertion operators used in the ALNS algorithm. We note that the requests are randomly chosen from the removal list L. Moreover, additional five variants of these operators are also used, where the requests are sorted in terms of their time flexibility (i.e. the least flexible first), where the flexibility of request r is computed as |udr − lor |. • Greedy Insertion (GI): This operator repeatedly inserts a request (both pickup and delivery nodes) in the best possible positions of the routes. ∆rIi J j is the objective function value when the pickup node of r is inserted in route I (position i) and its corresponding drop-off node is inserted in route J (position j). Thus, ∆rIi J j * = argmin{∆rIi J j }. The worst-case time complexity • •
•
•
of this operator is O(|P|2 ). Second-Best Insertion (SI): This new operator chooses the second best insertion. The worst-case time complexity of the SI operator is O(|P|2 ). Greedy Insertion with Noise function (GIN): This operator is an extension of the greedy algorithm but uses a degree of freedom in selecting the best place for a node. This degree of freedom is achieved by modifying the cost for request r: New Cost = Actual Cost + dÂŻ Âľ , where dÂŻ is the maximum distance between nodes, Âľ is a noise parameter used for diversification and is set equal to 0.1, and is a random number between [−1, 1]. New Cost is calculated for each request in L. The worst-case time complexity of the GIN operator is O(|P|2 ). Second-Best Insertion with Noise function (SIN): This operator is an extension of the SI and uses the same noise function as the GIN operator. The worst-case time complexity of the SIN operator is O(|P|2 ). Best out of Îť Feasible Insertions (ÎťFI): This new operator is similar to GI but chooses the best insertion out of the first Îť feasible insertions. The parameter Îť is a randomly generated integer number between 1 and Ďˆ. The worst-case time complexity of the ÎťFI operator is O(|P|2 ).
3.1.5. Feasibility of the routes and schedules The feasibility of the capacity and synchronization constraints for a given solution X must be satisfied. The capacity of the PD vehicles can be checked in a standard way with some preprocessing. In particular, the destination transfer node of a transferable request r (i.e., td∗r ) becomes an origin node on a different route, hence it will have a positive demand (i.e., hr ), whereas the origin transfer node of r (i.e., to∗r ) becomes a destination node and it is assigned a negative demand (i.e., -hr ). Scheduling constraints also bring complexity to the PDP-SL since the requests may be picked up by a PD vehicle and delivered by another one, thus multiple PD routes become dependent on each other. This implies that PD vehicles must be clearly synchronized. This constraint can be handled 11
in a recursive way. For a better understanding, we refer to the example shown in Figure 2. 0
7
8
9
10
11
Depot
Td_a
d_a
o_b
To_b
Depot
0
3
4
5
6
11
12
13
Depot
Td_c
d_c
o_a
To_a
Td_b
d_b
Depot
0
1
2
3
Depot
o_c
To_c
Depot
Figure 2 Interdependency of the routes
Three requests, namely a, b, and c, are to be delivered from o a, o b and o c to nodes d a, d b, and d c, respectively. All the requests are transferable, thus each request is shipped on a scheduled line. All these transfer nodes are the replications of the original scheduled line nodes, and each such replication is assigned to only one request. In the present example, T o a represents the origin transfer node of a, and T d a is its destination transfer node. In other words, the transfer node from which a request starts its trip on the scheduled lines is the origin transfer node, e.g., T o a . Similarly, the transfer node at which a request is recollected by a PD vehicle is called a destination transfer node of a, e.g., T d a . For the sake of simplicity, each arc has a travel time of one time unit and each node does not require any service time. The numbers on top of the nodes indicate the departure time from that specific node. In this example, three PD vehicles are needed for the transportation of these three requests. We now describe the scheduleCheck(X) procedure used in the insertion stage in Algorithm 4. Algorithm 4: The generic structure of the scheduleCheck(X) procedure input: A solution X 1 2 3 4 5 6 7 8 9 10
11
for (each route I in X) do for (each node i in I) do if (i = td∗r , ∀r ∈ P) then r ← getRelatedRequest(i) J ← getRoute(to∗r ) βi ← getSynchronizedTime(J, r) else βi ← max{β pi + c pi ,i + si ; li + si }, where pi is the predecessor of i in route I if (βi > ui + si ) then return FALSE return TRUE
For each route I and for each node i within the route (except td∗r ), the departure time from i is updated in a standard way as shown in Line 8. In the case when node i is a destination transfer node (Line 3), the actual departure time is updated by calling getSynchronizedTime(J, r) procedure (Line 6). Its pseudo-code is shown in Algorithm 5. By referring to Figure 2, the feasibility of the schedule is checked as the following: the process starts in the first route. The algorithm reaches the transfer node T d a that is a destination transfer 12
Algorithm 5: The generic structure of the getSynchronizedTime(J, r) procedure input : A route J and a request r output: departure time from td∗r 1 2 3 4 5 6 7
for (each node i in J) do βi ← max{β pi + c pi ,i + si ; li + si }, where pi is the predecessor of i in route J if (i is td∗r , ∀r1 ∈ P AND !r1 .updated) then 1 r1 ← getRelatedRequest(i) r1 .count ← r1 .count + 1 if (r1 .count > 1) then return +∞ J ← getRoute(to∗r ) 1 βi = getSynchronizedTime(J, r1 )
8 9 10
else if (i = or ) then βtdr = updatePathSchedule(βi , r) r.updated ← TRUE return βtdr
11 12 13 14 15 16 17
if βi > ui + si then return +∞ return βi
node of request a. Hence, getSynchronizedTime(J, a) method needs to be called in order to obtain the correct departure time from the current node. Therefore, the algorithm switches to the route that contains T o a (second route) and starts from the beginning of that specific route. At that point, T d c is reached, which is a destination transfer node of request c. Consequently, getSynchronizedTime(J, c) needs to be called again and the algorithms switches to the route that contains T o c (third route). In the current route, the method reaches node o c, which is the origin node of request c. At that point, request c gets an updated schedule of its path, which is [o c – T o c – T d c – d c], given βo c . Note that arc [T o c – T d c ] is a scheduled line path, hence the request must have a scheduled departure time from T o c . In this algorithm, the first scheduled departure time later than βTo c (i.e. dβTo c e) is used. Updated value of βTd c (i.e. 3) is returned and the algorithm switches back to the second route. Consequently, the value for d c is easily computed (i.e. 4) as shown in Line 8, Algorithm 4. Succeeding node, o a, is the origin node of request a, therefore the schedule of its path (i.e. [o a – T o a – T d a – d a]) is updated is the same way as for request c. The correct value for βTd a (i.e. 7) is returned and the algorithm switches back to the first route and continues from T d a to d a in a similar manner. Note that unnecessary computations can be made in solutions that contain cycles (see Figure 3). A cycle implies that the precedence constraints are violated for at least two transferable requests, since such requests need to be picked up and dropped off twice, including at/from transfer nodes. In addition, the cycles may be composed of multiple routes and requests and these should be detected as early as possible to avoid useless calculations. In our implementation, r.updated and r.count are used to reach this goal. Note that before checking the feasibility of a given solution X, r.count must be set to 0 and r.updated to FALSE respectively, ∀ r ∈ P.
13
Depot
Td_a
d_a
o_b
To_b
Depot
Depot
Td_b
d_b
o_a
To_a
Depot
Figure 3 An example of a two-request cycle
The procedure updatePathSchedule(βi , r) (see Algorithm 5, Line 12) computes the departure time from td∗r , given the departure time from or . Moreover, as mentioned earlier, the departure time (i.e., Îłtr ) of r from any related transfer node, i.e. t (except td∗r ), on the assigned scheduled line is dβt e. In addition, as the current flow path may include a destination transfer node of any other request r1 , getSynchronizedTime(J, r1 ) is applied in a similar manner as explained above. 3.1.6. Acceptance and stopping criteria In the ALNS, we have implemented simulated annealing as a master search framework for the PDP-SL. The overall framework of the ALNS algorithm with simulated annealing is provided in Algorithm 6. Algorithm 6: The general framework of the ALNS with simulated annealing input : a set of removal operators D, a set of insertion operators I, initialization constant Pinit , cooling rate Îş output: Xbest 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Generate an initial solution by using the Greedy insertion algorithm Initialize probability Ptd for each destroy operator d â&#x2C6;&#x2C6; D and probability Pti for each insertion operator i â&#x2C6;&#x2C6; I Let T be the temperature and j be the counter initialized as j â&#x2020;? 1 Let Xcurrent â&#x2020;? Xbest â&#x2020;? Xinit repeat Select a removal operator dâ&#x2C6;&#x2014; â&#x2C6;&#x2C6; D with probability Ptd â&#x2C6;&#x2014; Let Xnew be the solution obtained by applying operator dâ&#x2C6;&#x2014; to Xcurrent Select an insertion operator iâ&#x2C6;&#x2014; â&#x2C6;&#x2C6; I with probability Pti â&#x2C6;&#x2014; Let Xnew be the new solution obtained by applying operator iâ&#x2C6;&#x2014; to Xnew if c(Xnew ) < c(Xcurrent ) then Xcurrent â&#x2020;? Xnew else Let ν â&#x2020;? eâ&#x2C6;&#x2019;(c(Xnew )â&#x2C6;&#x2019;c(Xcurrent ))/T Generate a random number â&#x2C6;&#x2C6; [0, 1] if < ν then Xcurrent â&#x2020;? Xnew if c(Xcurrent ) < c(Xbest ) then Xbest â&#x2020;? Xnew T â&#x2020;? ÎşT Update probabilities using the adaptive weight adjustment procedure jâ&#x2020;? j+1 until the maximum number of iterations is reached
In the algorithm, Xbest indicates the best solution found during the search, Xcurrent is the current solution obtained at the beginning of an iteration, and Xnew is a temporary solution found at the end of iteration that can be discarded or become the current solution. The cost of solution X is denoted 14
by c(X). A solution Xnew is always accepted if c(Xnew ) < c(Xcurrent ), and accepted with probability e−(c(Xnew )−c(Xcurrent ))/T if c(Xnew ) > c(Xcurrent ), where T is the temperature. The initial temperature is set at Pinit , where Pinit is an initialization constant. The current temperature is gradually decreased during the course of the algorithm as κT , where 0 < κ < 1 is a fixed parameter. The algorithm returns the best found solution after a fixed number of iterations (i.e. 10000 iterations). 4. Computational results This section presents the results of extensive computational experiments performed to assess the performance of our ALNS heuristic algorithm. We first describe the generation of the instances and of the parameters. We then present the computational results obtained by the proposed heuristic algorithm. 4.1. Data and experimental setting Six sets of approximately 10 instances each were generated. The size of the instances ranges from five to 100 requests. The data sets include one scheduled line and two depots. The departure frequency of the SLs running between the end-of-line stations is set to be one departure every half an hour. The planning horizon is set to 10 hours. Distances are considered to be Euclidean on a 100x100 time units area. The request nodes are clustered (C) in the proximity of the two transfer points. One minute is considered to be one time unit. Moreover, two additional sets of instances were generated. Each set contains 10 data-sets with 60 requests each, two transfer nodes and two depots. These new sets are generated with respect to the geographical locations of the nodes. Considered instances involve randomly (R) generated, as well as random-clustered (RC) distributed requests. Time windows and service times are randomly generated in all instances. All data-sets are available for download from the web page of SmartLogisticLab [13]. The proposed algorithm is implemented in NetBeans IDE 7.1.1 using Java. All experiments were conducted on an Intel Core i5 with 2.6 GHz speed and 4 GB RAM. A preliminary analysis was conducted to fine-tune the parameters. Experimental testing showed that used parameter values worked well on our test instances. Our algorithm contains 16 user-controlled parameters which are listed in Table 3. The parameters used in the ALNS algorithm are categorized into two categories as described below. • Group A defines the selection procedure with the roulette wheel mechanism. We note that our setting of the parameters σ1 , σ2 and σ3 is contrary to the expected setting σ1 ≥ σ2 ≥ σ3 , normally used to reward an operator for good performance. In our implementation and similar to Pisinger and Røpke [8, 10], we have chosen an unconventional setting of these parameters whereby the discovery of a worse solution is rewarded more than the discovery of a better solution. This is to help diversify the search in the algorithm. • Group B of parameters is used to calibrate the simulated annealing acceptance mechanism and the removal and insertion operators.
15
Table 3 Parameters used in the ALNS heuristic Category A
B
Description
Typical values
Total number of iterations (Ni )
10000
Number of iterations for roulette wheel (Nw )
200
Roulette wheel parameter (r p )
0.1
New global solution (σ1 )
1
Better solution (σ2 )
0
Worse solution (σ3 )
5
Startup temperature parameter (Pinit )
200
Cooling rate (κ)
0.9995
Lower limit of removable requests (s)
2.5% of |P|
Upper limit of removable requests (s)
15% of |P|
First Shaw parameter (Π1 )
0.5
Second Shaw parameter (Π2 )
0.2
Third Shaw parameter (Π3 )
0.1
Fourth Shaw parameter (Π4 )
0.2
Noise parameter (µ)
0.1
Number of feasible insertions ψ
30
To show the number of times each removal operator was called within the ALNS, we give relevant information in Table 4. This table shows, for each removal operator, the frequency of use in the algorithm as a percentage of the total number of iterations. The total time spent to run each operator is also shown in parentheses. We note that the results are obtained using only one instance from each dataset. Table 4 Number of iterations as a percentage of the total number iterations and the CPU times required by the removal operators Instance sets
RR
ROR
WTR
WDR
SR
PR
DR
TR
HR
WR
5 – 12 requests 20 requests 40 requests 60 requests 80 requests 100 requests
3.0 (0.0) 3.1 (0.0) 2.5 (0.0) 3.7 (0.0) 2.0 (0.0) 3.0 (0.0)
8.6 (0.0) 0.1 (0.0) 2.5 (0.0) 3.1 (0.0) 1.8 (0.0) 1.8 (0.0)
12.5 (0.0) 25.7 (0.0) 15.5 (0.0) 13.8 (0.0) 22.3 (0.1) 17.0 (0.1)
14.4 (0.0) 11.3 (0.0) 17.0 (0.0) 15.3 (0.1) 14.3 (0.1) 5.3 (0.0)
7.7 (0.0) 10.3 (0.0) 9.5 (0.0) 8.0 (0.0) 8.8 (0.0) 13.7 (0.1)
5.8 (0.0) 5.1 (0.0) 8.0 (0.0) 7.0 (0.0) 11.8 (0.0) 9.3 (0.1)
5.8 (0.0) 6.2 (0.0) 4.5 (0.0) 6.4 (0.0) 5.0 (0.0) 3.3 (0.0)
5.8 (0.0) 6.2 (0.0) 7.0 (0.0) 8.0 (0.0) 9.8 (0.0) 11.6 (0.1)
17.3 (0.0) 15.4 (0.0) 18.5 (0.0) 15.0 (0.1) 9.3 (0.0) 14.4 (0.1)
19.2 (0.0) 16.5 (0.0) 15.0 (0.0) 19.9 (0.1) 15.3 (0.1) 19.8 (0.1)
The results indicate that the frequency of using different removal operators does not significantly vary in operators SR, PR, DR and TR. As the instances get larger in size, the frequencies of WTR, HR and WR increase compared to other operators. Since we use different strategies in scoring operators, the RR and ROR do not dominate other operators. This strategy allows more chances to other operators in case of clustered customers. 4.2. Results of the ALNS heuristic on the PDPs In this section, we provide in Table 5 computational results on the PDP-TW benchmark instances (i.e. Li and Lim [14]), which come in three sets: R, C and RC classified with respect to the ge16
ographical locations of the customers. The reason for choosing these instances is that Røpke and Cordeau [15] and Baldacci et al. [16] provide their results by using the minimization of operating costs as our algorithm does. Table 5 compares the published results to the ones obtained by our ALNS heuristic algorithm. The comparison is made in terms of best solution values obtained through 10 runs of the algorithm. This table presents, for each instance, the value of the best known or optimal solution compiled from several sources under column “Best known value”. Note that the values in bold emphasize that proposed algorithm found best known solution. The symbol “*” indicates that the values are not necessary optimal. Moreover, we note that all figures presented in Table 5 use a single decimal place. For the ALNS algorithm, we then present the best solution value obtained in column “ALNS”, with the GAP (%) from the best known value (i.e. let υ(ALNS ) be the solution value produced by our algorithm, then, the GAP (%) = 100 (υ(ALNS )−υ(Best)) /υ(ALNS ), where υ(Best) is the best known solution value for each instance) and the corresponding average CPU time required to run the algorithm. Table 5 Results of the ALNS heuristic on benchmark PDP-TW instances Li and Lim [14] instances
Best known value
ALNS algorithm
GAP %
CPU seconds
LC1 2 1 LC1 2 2 LC1 2 3 LC1 2 4 LC1 2 5 LC1 2 6 LC1 2 7 LC1 2 8 LC1 2 9 LC1 2 10 LR1 2 1 LR1 2 2 LR1 2 3 LR1 2 4 LR1 2 5 LR1 2 6 LR1 2 7 LR1 2 8 LR1 2 9 LR1 2 10 LRC1 2 1 LRC1 2 2 LRC1 2 3 LRC1 2 4 LRC1 2 5 LRC1 2 6 LRC1 2 7 LRC1 2 8 LRC1 2 9 LRC1 2 10
2704.6 2764.6 2772.2 2661.4∗ 2702 2701 2701 2689.8 2724.2 2741.6 4819.1 4093.1 3486.8 2830.7∗ 4221.6 3763 3112.9∗ 2645.4∗ 3953.5 3386.3 3606.1 3292.4 3079.5∗ 2525.8∗ 3715.8 3360.9 3317.7 3086.5 3053.8 2837.5∗
2704.6 2764.6 2772.2 2661.4 2702 2701 2701 2689.8 2724.2 2743.9 4819.1 4093.1 3486.8 2839.1 4221.6 3763 3112.9 2658.8 3953.5 3406.6 3606.1 3292.4 3108.5 2552.1 3766.2 3382.4 3357.6 3129.5 3095.9 2857.2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.08 0.00 0.00 0.00 0.30 0.00 0.00 0.00 0.50 0.00 0.60 0.00 0.00 0.93 1.03 1.34 0.64 1.19 1.37 1.36 0.69
42 50 113 125 43 44 48 49 61 76 52 92 156 215 44 71 119 169 54 59 43 69 110 200 52 46 54 65 64 72
0.33
82
Average
As shown in Table 5, the ALNS heuristic performs very well on the PDP-TW instances considered in our tests. For the majority of the instances, the heuristic is able to obtain the best known solutions published in the literature. For the rest of the instances, the percentage deviations are found to be not greater than 1.37%. The average CPU time required for the algorithm on the instances is 82 seconds.
17
4.3. Results of the generated instances This section presents the results obtained by the proposed heuristic on the generated six sets of PDP-SL instances. For the first set of instances, each instance was solved 10 times with the proposed heuristic and once with the PDP-SL MIP model by using CPLEX 12.3 (IBM ILOG [17]) with its default settings and the valid inequalities proposed by Ghilas et al. [18]. A common timelimit of three hours was imposed to CPLEX on the solution time for all instances. The following five sets were solved 10 times using the proposed ALNS in the context of PDP-SL and PDP. The detailed results of these experiments are presented in Table 6 and Tables 7 – 11. Table 6 Computational results for the instances with up to 10 requests Instance pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl pdpfsl
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8
Value 110.99 132.02 143.92 170.26 186.25 200.63 208.02 210.74 213.94 214.96 217.33 225.48 228.34 228.52 121.32 142.29 178.90 188.76 189.08 191.70 370.46 -
CPLEX Lower bound GAP % 110.99 132.02 143.92 170.26 186.25 180.80 193.80 209.82 208.02 210.74 213.94 214.96 217.33 225.48 228.34 228.52 121.32 142.29 178.90 188.76 189.08 191.70 197.73 200.23
0.00 0.00 0.00 0.00 0.00 3.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 46.63 -
CPU (seconds)
Value
118.24 11.44 545.78 4022.02 1985.13 10800.00 10800.00 10800.00 0.24 3.32 7.93 27.85 96.20 220.12 61.31 1041.68 2.05 353.66 6672.19 561.22 1256.88 2073.12 10800.00 10800.00
110.99 132.02 143.92 170.26 186.25 187.63 199.63 223.45 208.02 210.74 213.94 214.96 217.33 225.48 228.34 228.52 121.34 142.30 180.26 188.76 189.08 191.70 218.36 241.78
ALNS GAP (%) CPU (seconds) 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.02 0.01 0.75 0.00 0.00 0.00 -
0.82 0.95 1.56 1.68 1.82 1.92 2.23 2.31 0.76 0.83 0.91 0.99 1.23 1.35 1.44 1.89 1.96 2.14 2.12 2.74 2.34 3.12 3.32 3.42
Table 6 indicates that, in most of the cases, the ALNS heuristic generated the same solution values as those of CPLEX but in a substantially smaller amount of time. For the instances solved to optimality, the average CPU time required by CPLEX is approximately 752 seconds where the same statistic for the ALNS to produce the reported solutions is 1.8 seconds. In some cases where CPLEX could not find any solution or could obtain a sub-optimal one, the proposed ALNS was able to find solutions that have a tighter GAP relative to the best lower bound found within the imposed time limit. Tables 7 – 11 provide the results obtained for larger instances. The column Driving time indicates the total driven time of the best solution. The # of shipments on scheduled lines column indicates the number of shipments on the scheduled lines. In addition, the column Cost shows the total cost of the system. The CPU indicates the average computational time for solving the instances and the # of vehicles provides the average number of PD vehicles used over the executed runs. The proposed algorithm is relatively fast. For example, instances of up to 100 requests are solved in less than 20 minutes on average. As it can be noticed from the Tables 6 – 11, ALNS algorithm 18
Table 7 Results for 20-request instances Instance
Driving time
PDP-SL # of shipments on Cost scheduled lines (e)
PDP CPU (seconds)
# of vehicles
Driving time
Cost (e)
CPU (seconds)
# of vehicles
pdpfsl 20.1 pdpfsl 20.2 pdpfsl 20.3 pdpfsl 20.4 pdpfsl 20.5 pdpfsl 20.6 pdpfsl 20.7 pdpfsl 20.8 pdpfsl 20.9 pdpfsl 20.10
561.98 593.68 598.72 601.30 564.84 534.74 581.56 624.38 581.56 567.06
1 5 8 11 4 7 6 3 6 11
281.99 301.84 350.95 311.65 307.36 274.37 286.42 315.19 296.78 294.53
15.49 21.03 20.95 30.52 25.24 22.04 19.43 15.03 24.57 27.76
2 2 2 3 3 2 2 2 2 3
696.61 754.84 980.96 1023.6 842.66 870.70 742.77 773.09 890.47 882.06
348.31 377.42 490.48 511.80 421.33 435.35 371.39 386.55 445.24 441.03
3.79 3.67 3.27 6.05 4.46 3.12 5.98 6.74 10.40 3.25
3 2 3 4 2 2 2 2 2 3
Average
580.98
6
302.11
22.21
2.3
845.78
422.89
5.07
2.5
CPU (seconds)
# of vehicles
Driving time
Cost (e)
CPU (seconds)
# of vehicles
Table 8 Results for 40-request instances Instance
Driving time
PDP-SL # of shipments on Cost scheduled lines (e)
PDP
pdpfsl 40.1 pdpfsl 40.2 pdpfsl 40.3 pdpfsl 40.4 pdpfsl 40.5 pdpfsl 40.6 pdpfsl 40.7 pdpfsl 40.8 pdpfsl 40.9 pdpfsl 40.10
1310.64 1282.27 1231.01 1247.21 1210.73 1256.91 1267.37 1058.87 1029.53 1381.05
14 24 16 22 22 16 18 18 17 17
669.32 665.13 631.51 645.61 627.36 644.46 651.68 547.43 531.77 707.52
50.49 65.57 48.60 81.34 62.68 51.07 53.28 51.22 77.26 31.59
5 6 5 6 7 6 7 6 5 6
1653.85 1655.72 1497.90 1674.42 1786.04 1672.54 1717.16 1521.88 1496.62 1671.02
826.93 827.86 748.95 837.21 893.02 836.27 858.58 760.94 748.31 835.51
3.72 4.37 3.58 4.41 3.74 3.31 3.44 3.11 4.65 3.07
5 6 5 6 6 5 6 5 5 6
Average
1227.56
18
632.18
57.31
6
1634.72
817.36
3.74
5.4
CPU (seconds)
# of vehicles
Driving time
Cost (e)
CPU (seconds)
# of vehicles
Table 9 Results for 60-request instances Instance
Driving time
PDP-SL # of shipments on Cost scheduled lines (e)
PDP
pdpfsl 60.1 pdpfsl 60.2 pdpfsl 60.3 pdpfsl 60.4 pdpfsl 60.5 pdpfsl 60.6 pdpfsl 60.7 pdpfsl 60.8 pdpfsl 60.9 pdpfsl 60.10
1946.67 2257.75 1887.37 1844.75 1496.31 1663.94 2043.78 1718.19 1873.50 1733.10
31 27 8 33 27 27 18 24 29 31
1004.33 1155.88 951.69 955.38 775.16 858.97 1039.89 883.09 965.75 897.55
204.28 133.06 638.88 222.40 188.42 167.42 140.34 201.08 159.62 167.86
9 10 6 9 7 8 8 8 10 9
2388.62 2502.08 1929.26 2501.16 2154.22 2043.86 2324.50 2285.94 2487.66 2392.88
1194.31 1251.04 964.63 1250.58 1077.11 1021.93 1162.25 1142.97 1243.83 1196.44
8.22 9.16 19.60 18.61 8.70 8.11 7.04 9.43 6.88 11.00
7 8 6 8 7 6 7 8 9 8
Average
1846.54
26
948.77
222.34
8.3
2301.02
1150.51
10.68
7.5
for PDP-SL is substantially slower than the same algorithm in case of PDP. The main reason is the extra complexity that is induced by having the flexibility of using available scheduled lines, thus making multiple PD-vehicle routes depend on each other. In particular synchronization constraints require extra computation time (e.g., 20 â&#x20AC;&#x201C; 30% of the CPU time). The overview of the results over the five sets of instance is shown in Table 12. In particular, we show the potential savings in terms of operating costs and total traveling time. Note that the 19
Table 10 Results for 80-request instances Instance
Driving time
PDP-SL # of shipments on Cost scheduled lines (e)
PDP CPU (seconds)
# of vehicles
Driving time
Cost (e)
CPU (seconds)
# of vehicles
pdpfsl 80.1 pdpfsl 80.2 pdpfsl 80.3 pdpfsl 80.4 pdpfsl 80.5 pdpfsl 80.6 pdpfsl 80.7 pdpfsl 80.8 pdpfsl 80.9 pdpfsl 80.10
2412.32 2215.80 2281.28 2534.26 2807.53 3042.66 2528.47 2490.88 2697.81 2504.55
18 26 40 32 34 19 32 31 42 37
1224.16 1133.90 1180.64 1299.13 1437.76 1540.33 1296.23 1276.44 1390.90 1289.28
325.49 484.89 546.52 397.94 371.48 299.87 431.23 504.04 392.33 506.72
9 10 11 11 12 9 11 12 13 12
2755.20 2828.40 2974.74 2985.30 3315.34 3146.40 2963.00 3056.02 3038.20 2994.62
1377.60 1414.20 1487.37 1492.65 1657.67 1573.20 1481.50 1528.01 1519.10 1497.31
13.78 17.39 18.82 13.83 14.04 14.46 15.92 18.23 16.81 16.70
9 9 10 10 10 8 9 10 10 11
Average
2551.56
31
1306.88
426.05
11
3005.72
1502.86
16.00
9.6
CPU (seconds)
# of vehicles
Driving time
Cost (e)
CPU (seconds)
# of vehicles
Table 11 Results for 100-request instances Instance
Driving time
PDP-SL # of shipments on Cost scheduled lines (e)
PDP
pdpfsl 100.1 pdpfsl 100.2 pdpfsl 100.3 pdpfsl 100.4 pdpfsl 100.5 pdpfsl 100.6 pdpfsl 100.7 pdpfsl 100.8 pdpfsl 100.9 pdpfsl 100.10
3004.60 2732.84 2708.03 2879.54 3150.51 2927.99 3102.14 3041.00 3041.13 2907.99
44 37 39 32 44 42 35 45 42 41
1546.30 1403.42 1393.01 1471.77 1512.12 1505.99 1586.07 1565.50 1562.56 1494.99
1275.44 1012.85 1093.32 809.54 1239.71 1002.96 1405.46 1033.89 1211.19 1186.66
13 12 12 12 15 15 13 15 15 14
3516.46 3362.98 3100.20 3369.06 3520.00 3738.12 3758.54 3731.06 3498.50 3454.84
1758.23 1681.49 1550.10 1684.53 1760.00 1869.06 1879.27 1865.53 1749.25 1727.42
38.19 35.53 39.42 28.35 36.23 36.40 49.16 40.63 37.47 31.37
11 11 11 11 12 12 12 12 11 11
Average
2949.58
40
1504.17
1127.10
13.7
3504.98
1752.49
37.28
11.4
latter is directly related to the CO2 e savings. Moreover, the emissions generated by the public transportation vehicles are not considered in the computations for the following two reasons: (i) we consider small-sized freight (i.e., packages), hence extra carried weight leads to negligible additional CO2 e emissions (Demir et al. [19]), (ii) public transportation vehicles operate according to fixed schedules, irrespective of whether freight is carried or not. Thus, the CO2 e savings are of the same magnitude as the total travel time. Table 12 The overview of the obtained results Instance set
Cost savings (%)
Driving time/CO2 e savings (%)
20-request 40-request 60-request 80-request 100-request
28.56 22.66 17.53 13.04 14.17
31.31 24.91 19.75 15.11 15.85
Average
19.19
21.38
Note that the efficiency of the proposed system is highly dependent on both, the spatial pattern of the requests and the configuration of the scheduled lines. Unless the design of the scheduled lined services (routes and schedules) is integrated with vehicle routing, it is likely that the gains from an 20
integrated system operation would be inconsequential. Hence, designing such a system involves tactical decisions related to the pattern of the scheduled lines (positioning of the transfer points relative to the demand nodes clusters), the storage areas at the transfer points, and the re-design of the SL vehicles (e.g., freight compartment), that are not taken into consideration in this paper as the focus was on operational costs of the proposed system. Overall, the results indicate the potential operating costs and driving time savings due to available scheduled lines. In particular, savings of up to 19% on average can be achieved with regards to operating costs. In addition, up to 21% savings in terms of total travel time can be achieved and hence, fewer CO2 e emissions. However, the number of PD vehicles used slightly increase in PDPSL compared to the solutions for PDP. Moreover, we note that savings decrease along with the increase in number of requests. This can be explained by the increasing density of the requests over the considered area (100x100 time units). Hence, driving time from one demand node to another becomes shorter. 4.4. Analysis of the geographical distribution of the customers In this section, we investigate the impact of the customersâ&#x20AC;&#x2122; geographical distribution in the considered network with regards to the total savings (both operating costs and CO2 e emissions). Tables 13 and 14 provide the results obtained from solving the instances in the context of PDP-SL and PDP, in the case of R and RC sets. In each case, proposed ALNS was run five times and the best solution values found are shown. Table 13 Random (R) customers Instance
pdpfsl 60.R 1 pdpfsl 60.R 2 pdpfsl 60.R 3 pdpfsl 60.R 4 pdpfsl 60.R 5 pdpfsl 60.R 6 pdpfsl 60.R 7 pdpfsl 60.R 8 pdpfsl 60.R 9 pdpfsl 60.R 10
PDP-SL Costs Driving (e) time 1030.00 872.75 979.16 1133.30 1050.76 1102.35 994.40 1106.21 986.84 1042.80
2042.00 1729.50 1926.32 2236.60 2071.52 2174.70 1970.80 2192.42 1941.68 2065.60
Costs (e)
PDP Driving time
1099.61 1034.53 1076.86 1161.11 1194.02 1259.03 1075.03 1189.07 1164.62 1168.71
Average
2199.22 2069.06 2153.71 2322.21 2388.03 2518.06 2150.06 2378.13 2329.23 2337.41
Savings (%) Costs Driving time 6.33 15.64 9.07 2.39 12.00 12.44 7.50 6.97 15.26 10.77
7.15 16.41 10.56 3.69 13.25 13.64 8.34 7.81 16.64 11.63
9.84
10.91
According to the obtained results, one can easily observe that, in all cases, significant benefit with respect to operating cost and CO2 e emissions can be achieved. By comparing average savings between R, RC and C (for C the results are shown in Table 9) instances, the best performance of the system proved to be in clustered (C) instances, with 17.53% regarding operating costs and 19.75% driving time/CO2 e emissions. Hence, based on the obtained results, we can conclude that the more demand points are clustered around transfer nodes, the better performance of the system is.
21
Table 14 Random-clustered (RC) customers Instance
pdpfsl 60.RC 1 pdpfsl 60.RC 2 pdpfsl 60.RC 3 pdpfsl 60.RC 4 pdpfsl 60.RC 5 pdpfsl 60.RC 6 pdpfsl 60.RC 7 pdpfsl 60.RC 8 pdpfsl 60.RC 9 pdpfsl 60.RC 10
PDP-SL Costs Driving (e) time 767.22 881.06 1007.29 879.29 967.19 963.13 988.52 912.58 858.97 959.60
1500.44 1728.12 1964.58 1726.58 1872.38 1888.26 1933.04 1777.16 1691.94 1881.20
Costs (e)
PDP Driving time
942.02 1044.09 1068.79 1029.53 1154.54 1006.65 1180.40 1129.65 992.25 1072.75
1884.04 2088.18 2137.58 2059.05 2309.08 2013.30 2360.79 2259.29 1984.50 2145.50
Average
Savings (%) Costs Driving time 18.56 15.61 5.75 14.59 16.23 4.32 16.26 19.22 13.43 10.55
20.36 17.24 8.09 16.15 18.91 6.21 18.12 21.34 14.74 12.32
13.45
15.35
4.5. Amsterdam metro system In this section we investigate the performance of the PDP-SL environment on a realistic scheduled lined system. In particular, we solve one instance of 100 randomly generated requests on a 60 x 60 time units area, three depots and 20 PD vehicles. The scheduled lines graph, inspired from the current metro system in Amsterdam (see Figure 1), is shown in Figure 4. The distances are considered Euclidean and the time windows are randomly generated.
Figure 4 An illustrative representation of Amsterdamâ&#x20AC;&#x2122;s metro system
Table 15 Results on a realistic real-life scheduled line system Instance Amsterdam 100 requests
Driving time 1767.22
PDP-SL # of shipments on Cost scheduled lines (e) 36
919.61
PDP CPU (seconds)
# of vehicles
Driving time
Cost (e)
CPU (seconds)
# of vehicles
1258.52
10
1945.69
972.85
34.62
7
The results shown in Table 15 are obtained after five runs of the algorithm and indicate the best solutions found for both PDP-SL and PDP. In particular, the PDP-SL integrated transportation 22
system, due to the available scheduled lines, led to 5% savings in terms of operating costs and 9% in fewer total driving time/CO2 e emissions. Even though PDP-SL system can lead to operating costs and CO2 e emissions benefits, the number of vehicles used is increased, compared to PDP. 5. Conclusions We have described a heuristic algorithm to solve the PDP-SL. To fully evaluate the effectiveness of the heuristic algorithm, we have generated different sets of instances and compiled a library of PDP-SL instances. Compared to the existing solutions on a set of PDP-TW instances, the proposed algorithm performed well in terms of both, solution quality (with a maximum GAP of 1.37%) and CPU time (82 seconds on average). Furthermore, we have also shown that small PDPSL instances can be solved optimally by the proposed algorithm. The solutions obtained from solving larger instances, up to 100 requests, were compared to their corresponding PDP solutions and it is concluded that the flexibility of using scheduled lined services leads to significant cost and CO2 e emissions savings, being, on average, up to 19%, and 21% respectively. However, note that the performance of the PDP-SL system is highly dependent on the relative positioning of the scheduled lines to the request nodes. Overall the results show that the proposed algorithm is highly effective in finding good-quality solutions for relatively large instances in a reasonable amount of time (up to 20 minutes). Acknowledgements The authors gratefully acknowledge funds provided by Dinalog, the Dutch Institute for Advanced Logistics, under the grant titled “Cargo Hitching”, # 2011 4 086R. Bibliography [1] Lindholm M, Behrends S. Challenges in urban freight transport planning – a review in the Baltic Sea Region. Journal of Transport Geography 2012;22:129–36. [2] Levin Y, Nediak M, Topaloglu H. Cargo capacity management with allotments and spot market demand. Operations Research 2012;60(2):351–65. [3] Hurtigruten . Hurtigruten official webpage (accessed on 11.11.2013). 2013. Available at: www.hurtigruten-web.com/index_en.html. [4] Trentini A, Masson R, Lehuede F, Malheme N, Peton O, Tlahig H. A shared ”passenger & goods” city logistics system. 4th International Conference on Information Systems, Logistics and Supply Chain, Quebec, Canada 2012;. [5] DHL-Packstation . DHL official webpage (accessed on 29.11.2013). 2013. Available at: www.dhl.de/en/paket/pakete-empfangen/packstation.html. [6] Hall CH, Andersson H, Lundgren JT, Varbrand P. The integrated dial-a-ride problem. Public Transportation 2009;1:39–54. 23
[7] Shaw P. Using constraint programming and local search methods to solve vehicle routing problems. In: Proceedings of the 4th International Conference on Principles and Practice of Constraint Programming. Springer, New York; 1998, p. 417–31. [8] Pisinger D, Røpke S. A general heuristic for vehicle routing problems. Tech. Rep.; DIKU - Department of Computer Science, University of Copenhagen; 2005. Available at: http://www.diku.dk/hjemmesider/ansatte/sropke/Papers/GeneralVRP_ TechRep.pdf (accessed on November 11, 2013). [9] Røpke S, Pisinger D. An adaptive large neighborhood search heuristic for the pickup and delivery problem with time windows. Transportation Science 2006;40(4):455–72. [10] Pisinger D, Røpke S. A general heuristic for vehicle routing problems. Computers & Operations Research 2007;34(8):2403–35. [11] Demir E, Bektas¸ T, Laporte G. An adaptive large neighborhood search heuristic for the pollution-routing problem. European Journal of Operational Research 2012;223(2):346–59. [12] Dijkstra EW. A note on two problems in connexion with graphs. Numerische Mathematik 1959;1:269 –71. [13] SmartLogisticLab . Official webpage (accessed on 21.03.2014). 2013. Available at: www. smartlogisticslab.nl. [14] Li H, Lim A. A metaheuristic for the pickup and delivery problem with time windows. International Journal on Artificial Intelligence Tools 2003;12(2):173–86. [15] Røpke S, Cordeau JF. Branch and cut and price for the pickup and delivery problem with time windows. Transportation Science 2009;43(3):267–86. [16] Baldacci R, Bartolini E, Mingozzi A. An exact algorithm for the pickup and delivery problem with time windows. Operations Research 2011;59(2):414–26. [17] IBM ILOG . Copyright international business machines corporation 1987. 2013. [18] Ghilas V, Demir E, Van Woensel T. Integrating passenger and freight transportation: model formulation and insights. Tech. Rep.; Industrial Engineering & Innovation Sciences, Operations, Planning, Accounting, and Control, Eindhoven University of Technology; 2013. Internal Report, BETA publicatie working papers, No. 441, 23 pp. [19] Demir E, Bektas¸ T, Laporte G. A review of recent research on green road freight transportation. European Journal of Operational Research 2014;237(3):775 –93.
24