2.1. MILP Formulation
Let be the set of all customers and be the set of all customers and the depot. For each customer , and denote, respectively, its delivery and the pickup amounts. The fleet of vehicles is denoted by . Note that for the sake of modeling simplicity, the number of vehicles available of each type is already given in this formulation. This assumption, however, limits the decision on the fleet composition, and commonly, a sufficiently high number of vehicles has to be assumed for each vehicle type such that optimality can be guaranteed. For each vehicle , , , and denote, respectively, its capacity, fixed cost, and variable cost. In addition, for each pair of nodes , represents the distance between the nodes.
We aim to determine the fleet composition and vehicle routes that minimize the total routing cost. Let
be the binary decision variable indicating whether vehicle
k traverses arc
or not. The continuous variable
denotes the total load picked up by vehicle
k while traversing arc
. Conversely, the continuous variable
denotes the total load to be delivered by vehicle
k while traversing arc
. The optimization problem can be formulated as follows.
The objective function (
1) minimizes the total fixed costs of vehicles and variable transportation costs. Constraints (
2) guarantee that each customer is visited exactly once. Constraints (
3) impose the condition that each customer is served by the same vehicle. Constraints (
4) ensure that each vehicle can serve one route at most. Constraints (
5) guarantee that there is no demand picked up in the beginning of routes. Conversely, constraints (
6) impose the condition that there is no demand for delivery in the end of routes. Constraints (
7) and (
8) are flow equations for pickup and delivery loads, respectively. Constraints (
9) and (
10), respectively guarantee that the sum of the inflow to the origin is equal to the total pickup demand and that the sum of the outflow from the origin is equal to the total delivery demand. Constraints (
11) ensure that the capacity of the vehicles is respected throughout the routes. Finally, constraints (
12) specify the domain of variables. The MILP model (
1)–(
12) contains
binary variables and
constraints.
2.2. Nearest-Neighbor-Based Randomized Algorithm
The original nearest neighbor algorithm is perhaps the simplest heuristic for the traveling salesman problem (TSP) [
14], which is a classical optimization problem closely related to the VRP. The key to this algorithm is to always visit the nearest unvisited city (customer). It is well known that the nearest neighbor algorithm, a popular choice for tour construction heuristics, works at an acceptable level for the Euclidean TSP, but it can produce very poor results for the general TSP [
15,
16].
We now introduce our nearest-neighbor-based randomized algorithm to tackle the HVRPSPD, as shown in Algorithm 1. In our approach, at each iteration of the main loop of the algorithm (line 2), a feasible solution to the HVRPSPD (i.e., a set of feasible routes, each of them associated with a vehicle type, to cover all customers) is constructed from scratch. We keep track of the best solution obtained during iterations, but it is not used to define a neighborhood structure or to guide the search for better solutions and, in this respect, it can be seen as a blind search. The construction of a feasible solution, however, is probabilistically guided by two alternative greedy criteria to select the next customer to be visited on the current route: the nearest neighbor or the first one from a given list of unvisited customers. In the sequel, we explain the construction of a feasible solution in more detail.
Algorithm 1: Nearest-Neighbor-Based Randomized Algorithm |
parameters: Computation time limit , probability of using the nearest neighbour strategy. input: Set of and , set of vehicle . output: Set of vehicle routes (). |
At each iteration, to obtain a feasible solution, we first generate a random permutation of all customers. We maintain a list of customers that were not served by a vehicle yet, named as , which is initially set with the random permutation. The routes of a feasible solution are generated sequentially. For each route, we randomly choose a vehicle among all types. The route always starts from the depot to the first customer from whose delivery and pickup demands respect the capacity of the vehicle used to serve the route. Thereafter, the next customer under consideration to be appended to the route, named as , is chosen either by the ordering of or by the nearest neighbor strategy, according to a probability . Every time has been effectively added to the current route, it is removed from . And every time has been proven to be infeasible to be part of the route (because of a vehicle capacity violation), we set its property , and then it is no more considered to be part of this route. The algorithm follows this process until there are no more customers that can be appended to the current route. In this case, the current route is closed, the feasibility of customers in is reestablished (), and a new route is opened. Routes are created until all customers have been visited ( is empty), when we obtain a feasible solution to the HVRPSPD.
The algorithm continues to generate feasible solutions until a time limit is reached. The best set of routes found during this whole process is deemed to be the final solution. To illustrate the core of our algorithm, consider the running example presented in
Figure 1 with 4 customers and the depot.
Assume that the random permutation is
and that the capacity of the vehicle chosen to serve the route is
. Since
is initially empty, the depot (i.e., node 0) is added to the route, and
is set to be the first customer from
(i.e., customer 3). In this point, the route to be tested is
. We denote by
the cargo of the vehicle while traversing the arc
. Note that the vehicle must leave the depot loaded with all deliveries of the customers on the route and, conversely, return to the depot with all pickup demands of these customers. In
Table 1, we check the feasibility of the route:
Since the capacity constraint is satisfied throughout the route, customer 3 is effectively added to it and removed from
. At this point, we choose the next
customer either by the ordering of
or by the nearest neighbor strategy, according to a probability
. Consider that the nearest neighbor strategy has been used to select the next customer this time, and thus customer 1 was chosen as
. Therefore, the route to be tested is
, as presented in
Table 2. We check its feasibility:
;
;
.
The capacity constraint remains satisfied all the way through the route, and therefore, customer 1 is added to it and removed from
. Again consider that
has been chosen by the nearest neighbor strategy, and thus customer 4 was selected as
. Now the route to be tested is
, as shown in
Table 3. We check its feasibility:
;
;
;
.
However, in this attempt, the capacity constraint is violated. Customer 4 is not removed from
but is set to be infeasible (crossed out in the list). Assume now that
has been chosen by the ordering of
. In this case, the first customer not set as infeasible (customer 2) was selected as
. Now the route to be tested is
, as presented in
Table 4. We check its feasibility:
;
;
;
.
The capacity constraint is satisfied throughout the route, and therefore, customer 2 is added to it and removed from
. At this point,
is not empty, and for that reason, we do not have a feasible solution yet. In addition,
only contains customers that are set as infeasible, and thus the current route cannot be expanded. This route is then closed and incorporated to the current set of routes under construction. The feasibility of unvisited customers is reestablished (
), and a new route is opened. For the new route, assume that the capacity of the vehicle randomly chosen is
. The depot is added to the route, and
is set to be the first customer from
(i.e., customer 4). The route to be tested is
, as shown in
Table 5. We check its feasibility:
The capacity constraint is fulfilled, and therefore, customer 4 is added to the route and removed from . Since is empty, the route is closed and incorporated to the current set of routes. Finally, a feasible solution to the HVRPSPD is obtained.
Note that the computation time of the functions , , and is . Computing a feasible solution is and and, therefore, is quite efficient. The worst case scenario, however, is quite artificial, and the solution computation is indeed very fast.