' & $ % Résumé du chapitre
Pour résoudre les instances de grande taille, il s’agit de faire coopérer le moteur de résolution d’ILOG TPO avec un algorithme permettant de déterminer, pour chaque ordre de transport, dans quelle suite de hubs il serait judicieux de le transborder. Ce genre de décisions est difficile à prendre pour ILOG TPO car le nombre de tels chemins de hubs est exponentielle pour chaque ordre de transport. De plus, il s’agit de déci-sions plutôt globales, alors que le moteur d’ILOG TPO est basé sur des techniques de recherche locale.
Pour fournir de telles indications à ILOG TPO, nous proposons un nou-veau modèle mathématique à base de chemins, cette fois très simplifié par rapport au problème initial. Cette formulation n’est basée que sur la structure du réseau et néglige certains aspects comme les considérations temporelles (fenêtres de temps, etc.). Elle représente les véhicules comme un flot, et un certain nombre de variables booléennes de chemin sont asso-ciées à chaque ordre de transport. Ce sont ces variables qui sont utilisées pour déterminer les chemins de hubs prometteurs pour chaque ordre de transport.
Nous proposons trois façons de communiquer ces indications à ILOG TPO. Il s’agit de contraindre de façon plus ou moins importante le modèle d’ILOG TPO et le forcer, lors de la résolution, à utiliser les chemins de hubs indiqués par le modèle mathématique. Ceci est intégré dans une heu-ristique à deux phases. D’abord le modèle d’ILOG TPO contraint par ces indications est résolu avec les méthodes de résolution d’ILOG TPO. Les indications sur les chemins des ordres de transport sont ensuite relâchées, et le modèle d’ILOG TPO est résolu une nouvelle fois, avec comme pre-mière solution la solution finale de la phase précédente. Cette phase sert à corriger les imperfections sur les chemins des ordres qui découlent du caractère approché de la formulation mathématique à base de chemins.
4.1 ILOG TPO solving methods 101 ILOG TPO hardly manages to decide whether each shipment should be transshipped at a hub or if it should be delivered directly. Section 4.1 de-scribes some of the ILOG TPO standard solving strategies. They are based on local search, and some of their decisions may be questionable globally, as local search improves a solution step by step without considering the whole problem. The smallest instances can be solved by the models defined in the previous chapter, as they are a close representation of the routing problem and they can reach optimality in reasonable time. However, their large size doesn’t allow the solving of the largest instances of ILOG TPO benchmarks, that can have up to 1500 shipments. The idea is then, for these instances, to help the ILOG TPO solving by guiding some decisions, such as the ones con-cerning the shipment paths, with a global MIP model that keeps the network structure, but that is simpler and smaller than the previous formulations. Section 4.2 describes a model based on a network representation of the ve-hicles and where the decision variables involving shipments are the possible paths through which each shipment can be routed. At last, in section 4.3, the cooperation between the ILOG TPO solving engine and the MIP model is exposed. The MIP model is solved as a preprocessing and the MIP optimal solution provides guidelines for shipment paths. These guidelines are then given to ILOG TPO before the solving.
4.1 ILOG TPO solving methods
ILOG TPO tackles very complex problems as described in section1.3. Some of the customer instances it has to solve are large (hundreds of shipments), and can’t be solved to optimality, or at least, there can’t be a systematic proof that a final solution is optimal. The best solving strategies for this kind of problems is local search with no doubt, as it may include several problem features, and yet finds a good solution in reasonable time. Anyway, the customers using ILOG TPO would not expect an optimal solution, but at least a better solution than their own handmade plan and that they can’t improve easily by themselves.
This justifies the use of local search (LS) in the ILOG TPO solving engine. The core of the strategies used by ILOG TPO is described by De Backer et al. [De Backer et al., 2000]. In fact, it mixes Local Search and con-straint programming (CP). CP is a well-known solving technique where every variable has a domain that is reduced during the search thanks to con-straints triggering. Propagation is called as soon as the domain of a variable
xis reduced, and every other variable linked withxby a constraint can have its domain modified as well by applying this constraint on the new domain ofx.
The optimization model used by ILOG TPO is based on visits rather than sites. Almost all the basic decisions and local search moves imply one
102 Chap. 4: Cooperation algorithm with ILOG TPO or more visits. In particular, the integer variable Ri indicates the visit that is performed just after visit i on the same vehicle. This enables the use of several constraints, mostly conditional, to model load accumulation or time precedences. To model side constraints such as incompatibilities, a vehicle tagτi, standing for the vehicle that serves visiti, is also needed.
Any solution has two representations:
• the active one that is used for the local search of the next solution,
• the passive one, on which the checking procedure that validates the feasibility of the solution, with respect to all the constraints, is carried out.
As checking all the constaints might be time-consuming, some methods are proposed to avoid the complete checking, such as a reduction of the domain of cumulative variables (time or load), or restricting the checking to modified routes only.
The local search mainly uses five of the neighbourhoods described in sub-section 2.1.5: 2-Opt, Or-Opt, Relocate, Exchange and Cross. In addition, some complex neighbourhoods are implemented to take into account the advanced features of the problem such as transshipment or shipment alter-natives. In particular, a neighbourhood switches the transshipment status of a shipment (direct or indirect), whereas another one unperforms shipments
and performs an alternate shipment s′ instead.
All these LS operators can be used in a pure LS method, or in a more sophisticated one based on a metaheuristic in order to be able to escape from local minima. In particular, a basic tabu search (TS) is available. This TS defines two tabu lists (one for arcs added and another for arcs removed) that are inspected at each move, and if the move contains more than a given threshold (that depends on the kind of move) of added and removed arcs already in the tabu list, it is rejected. It is also possible to apply another metaheuristic: guided local search(GLS). GLS is a local search procedure that adds a penalty factor in the objective function as soon as it reaches a local optimum. This penalty factor depends on search experience and is kept until the end of the optimization. The main advantage of GLS compared with TS is that it is easy to implement and a few tests suffice to determine if this metaheuristic is appropriate for a problem. On the other hand, TS has many parameters to be customized and a slight modification in one of them may result in a deep change in the performances of the algorithm. In other words, the parameter customization of a TS algorithm is almost an optimization problem in itself!
Practically, the instances we face are usually solved using first-improve-ment moves, for which the first improving neighbour of the current solution is kept for the next local search step. The main advantage of this choice is to avoid searching over all the neighbourhood at each move, even if each
4.2 The path-based model 103
Figure 4.1: Example of ILOG TPO local search trace
improvement is then expected to be lower than a best-improvement move (for which the best neighbour is kept).
Figure 4.1 depicts a typical search process by ILOG TPO on a rea-sonnable size instance. The current solution value is displayed depending on computing time. As we can see, the search is a sequence of descents and when alocal minimumis reached, ILOG TPO has a diversification strat-egy by a modification of the costs based on the previous search experience. This diversification leads to a new solution with a high cost, and a new local search descent begins from this point.
This algorithm is used in our tests (see next chapter), especially on small and middle-size instances, since for large instances, the first local search descent isn’t usually finished at the end of the time limit of 3 hours.
4.2 The path-based model
Before describing the path-based formulation, let us define precisely some important notions.
Recall that in an ILOG TPO point of view, a shipment path is a (possibly empty) sequence of hubs in which a given shipment is transshipped. Here, a shipment path is made of the hubs the shipment goes through in its path, without any knowledge whether it is transshipped or not. A shipment path also contains information on the pickup and delivery sites, in the case the shipment has alternate shipments (i.e. in simple terms, several possible pickup and delivery sites). In addition, let a complete shipment path be an extension of shipment paths on all sites: a shipment path is a path
104 Chap. 4: Cooperation algorithm with ILOG TPO between hubs whereas a complete shipment path may include any kind of sites. A complete shipment path is then the sequence of sites, from the pickup site to the delivery site, through which the shipment goes before being delivered. For example, if a shipment goes through sites 1,5,2,4,7,8,3 in this order, where 1 is its pickup site, 3 is its delivery site and 2 and 8 are hubs, then its complete shipment path is(1,5,2,4,7,8,3) and its shipment path is(1,2,8,3), regardless of the vehicle(s) in which it travels. Note that both paths can be seen as sequences of sites, as well as sequences of arcs, providing the graph of sites is complete.
4.2.1 Motivation
ILOG TPO optimization engine is based on Local Search (LS) and has hardly a global view of the problem. Hence, the decisions are locally improving but might be questionable from a global point of view. Using LS, the current so-lution might not have a sequence of neighbour soso-lutions to get to a very good solution, or if it has one, the sequence may contain very bad solutions that would never be chosen by the optimization engine, whichever the heuristic or metaheuristic is. Furthermore, the sequence might be very long, which would be a serious drawback in terms of computing time. Therefore, we need to take good decisions from a global point of view at the very start of the solving process, so that these decisions impact both the quality of the final solution found and the computing time to find it. For example, we may pro-vide the solver with a bad first solution in terms of cost, but with a structure such that few moves are required to get to a good solution. The aim of this is to obtain a better final solution, or at least a similar final solution in less time.
Transshipment is one of the features that cause questionable decisions. As a cross-dock action involves several vehicles, it is not easy to introduce a simple neighbourhood that is likely to improve the solution by taking advantage of transshipment. For instance, for a shipment s, let a move be the modification between “s direct” (meaning not transshipped) and “s
through hubh”. If, at that time, there is no other shipment transshipped at hubh, this move will result in a raise of the costs, as there is no benefit from transshipment if less than two shipments are involved. Therefore, any such move will be rejected in a pure LS strategy, whereas it could be an improving move to modify the status of two direct shipments instead of only one.
The basic ILOG TPO first solution is built with a greedy procedure that uses local search, and may take wrong transshipment decisions, which can be the source of the suboptimality of the final solution. A solution to the issue presented above is to find some way to provide every shipment with paths between hubs that are expected to be of a good quality. Of course, such a procedure has to be efficient in a short time, as it is only a small part of the solving. The shipment paths given by this tool could then be frozen
4.2 The path-based model 105 and the optimization would only be focused on other decisions, and removing some of the defined neighbourhoods (those corresponding to shipment paths) obviously accelerates the local search.
A simple way to get the right paths between hubs is to model the problem with variables indexed on shipment paths. This formulation, unlike the arc-based formulation proposed in chapter 3, has to be concise but it has to model the problem as closely as possible, keeping in mind that the only decision that has to come out of the solving of this model is the choice of the shipment path for each shipment.
We chose to neglect the time aspects, for several reasons. First, it seems that to take a decision on the shipment paths, only the network structure is necessary, and time requirements such as time windows wouldn’t modify the benefit of using a given shipment path, except in some particular cases. Then, time is convenient to ignore as the vehicles no longer need to be individualized as in the models presented previously. By this way, we can model the vehicles as a flow that only specifies the capacity on each arc travelled by shipments. Recall that table3.1lists some of the real-life features of the problem and makes clear whether each of the three formulations can model them.
Path-based models are often provided for vehicle routing problems, espe-cially when the vehicle fleet is heterogeneous (see subsection 2.1.5 for more details). But most of the time, vehicle paths (or tours) are introduced. In our case, the vehicles are modelled as a flow, and the paths aspect is on the shipments.
4.2.2 Variables
The variables can be separated into two groups.
The vehicle flow variables are the variables that indicate how many vehicles of each fleet travel in the network. nijf depicts the number of vehicles of fleet f that travel from siteito site j, whereas n+if (resp. n−if) is the number of vehicles of fleet f for which the route starts (resp. ends) at sitei.
Let Q(s) be the set of all complete shipment paths for shipments. The complete shipment path variables are denoted by θsp, where shipment
stravels through complete path p∈Q(s) if and only if θsp = 1. Recall that
S is the set of shipments, whereas S′ also contains the alternate shipments, for instance to model the possiblity for a shipment to be delivered via a ZSH. For example, a shipment s∈S, that can be delivered to a nearby ZSH instead of being shipped directly to its destination, is associated with two shipments in S′: itself and a shipment s′ for which the delivery visit takes place at the ZSH. In this section however, we consider only the shipments
s ∈ S, and the shipment alternatives are modelled as additional paths for a shipment s (these paths may have distinct origins and destinations, of
106 Chap. 4: Cooperation algorithm with ILOG TPO
Figure 4.2: Alternative modelled as additional shipment paths
hub for shipment s (one hub and one inbound ZSH)
ZSH
i(p(s))
i(d(s)) All possible shipment paths
course). Figure 4.2 depicts a basic example with 4 sites where a shipment
shas a shipment alternative, and both of the alternate shipments have two shipment paths (direct or through the hub). This results in 4 possible ship-ment paths for shipship-ment s. Recall that i(p(s)) and i(d(s)) are its pickup and delivery sites, respectively. However, for the time being, the shipment paths that are considered in Q(s) are complete shipment paths containing any kind of sites. For any shipment, there may be a lot of such complete shipment paths.
In the following, the size of a fleetf is the number of vehicles available in f and is referred to by size(f). Any data notation that has been used previously for vehicles (such as cap(k)) can be kept for fleets (i.e. cap(f)) because in each fleet, all the vehicles are identical.
4.2 The path-based model 107
4.2.3 Constraints
The variables described above are subject to the following constraints:
∀i∈I,∀f ∈F, X j∈I nijf −X j∈I njif =n+if −n−if (4.2.1) ∀i∈I,∀f ∈F, n±if = 0 if i6= extrem±(f) (4.2.2) ∀f ∈F, X i∈I n+if ≤size(f) (4.2.3) ∀s,∈S, X p∈Q(s) θsp= 1 (4.2.4) ∀(ij)∈A, X s∈S qty(s) X p∈Q(s) p∋(ij) θsp ≤X f∈F cap(f)nijf(4.2.5) ∀i, j∈I,∀f ∈F, nijf, n+if, n−if ∈N (4.2.6) ∀s∈S,∀p∈Q(s), θsp∈ {0,1} (4.2.7) Constraint (4.2.1) is the flow conservation constraint on each site i and for each vehicle fleetf. This constraint generalizes the Kirchhoff constraint (2.2.2) of the classical network flow formulation described in subsection2.2.1. Constraint (4.2.2) only holds if the sites extrem±(f) are given in the data, and ensures that no vehicle will start or end its route at a wrong site. Con-straint (4.2.3) ensures that in each fleet, the number of vehicle used doesn’t exceed the number of vehicles available. Constraint (4.2.4) enforces each shipment to be transported through exactly one shipment path, and it is similar to constraint (2.1.8) that belongs to the path-based formulation of the VRP described in subsection 2.1.5. Here however, we consider ship-ment paths, and not vehicle paths. Finally, constraint (4.2.5) is the capacity constraint, as well as constraint (2.1.9) from the same VRP path-based for-mulation.
4.2.4 Objective
The objective is, as described in the previous models (subsection 3.1.5) to minimize costs that can be composed into 4 terms: the fixed cost, the zone-skipping cost (ZSC), the direct transportation cost (DTC) and the additional distance cost (ADC).
min obj = Cfixed+ CDTC+ CADC+ CZSC
The modelling of costs, especially the DTC and the ADC, is complex in this formulation, because they should depend on the first and last sites of the vehicle routes, although no real vehicle route is visible here. Of course,
108 Chap. 4: Cooperation algorithm with ILOG TPO we could determine each of the vehicle routes a posteriori, but here the point is to have access to them during the search, which is impossible unless many other variables and constraints are introduced, but this is inconceivable as it would break the flow structure for the vehicles. Moreover, there is obviously no way of getting the maximal quantity over a route (denoted by Qk in subsection 3.1.5), needed for the DTC. Therefore, the idea is to approximate the costs as well as possible, but above all so that a solution that dominates another in terms of the “real” costs will also be better when comparing the model costs. We give here a rough approximation of these costs, as a lot of problem features have already been approximated or even removed (time for example). Moreover, a more sophisticated approximation would not necessarily have a significant impact on the final solution.
• The fixed cost is simply:
Cfixed =X f∈F Cvehicle(f)X i∈I n+if !
• Recall that a zone-skipping cost is a cost that has to be paid for using a special site called ZSH instead of a regular pickup or delivery site. It depends on the total quantity of products that go through a given ZSH. If we decide to linearize it as for the previous models, the zone-skipping cost is also rather easy to write in this model, as shipment alternatives are merged with the notion of shipment paths here: