Problèmes de tournées avec fenêtres de temps et regroupement

Les cartes auto-organisatrices ont été appliquées au VRP, mais à notre connaissance jamais aux problèmes de tournées avec fenêtres de temps, tels que le classique VRPTW. Ici, nous présentons une version de l’approche mémétique-SOM permettant de produire des solutions pour une version du VRPTW avec introduction d’une distance à pieds des clients vers les points de ramassage ou de service. Des solutions approchées pour le VRPTW classique peuvent en être dérivées. Le problème est appelé VRPTW-Cluster. Dans les configurations de l’algorithme, de même que pour tous les problèmes avec regroupement que nous considérons, l’opérateur MAPPING effectue juste une affectation des requêtes aux centres de groupes, sans déplacement de ceux-ci, afin de les laisser libres sur le plan. La taille des clusters est réduite à une unité (une unique requête par centre) afin de se rapprocher du VRPTW classique.

L’algorithme est en deux phases. Une boucle mémétique-SOM avec de larges intensités de mouvements permet la construction des solutions, une deuxième boucle avec de faibles intensités l’amélioration.

Nous résumons les résultats présentés dans [Créput et al. 07a]. Nous avons appliqué l’approche sur le benchmark de Solomon [Solomon 87] qui comporte 56 instances de taille 100. Un exemple de solution est présenté à la Figure III-9(a-c) sur le cas de test rc201, montrant les étapes finales pour générer une solution classique du VRPTW à partir d’une solution obtenue possédant une distorsion non nulle. Le pattern obtenu est présenté en (a). Un résultat intermédiaire est produit en enlevant les clusters vides en (b). Une solution du VRPTW est ensuite dérivée en projetant les centres de groupes sur leur (unique) requête assignée en (c). Ainsi que nous pouvons le constater sur les figures (a-c), l’assignation des clients aux points de regroupement par l’algorithme coïncide avec une assignation au plus proche, ce qui tient compte du choix naturel d’un client de se diriger vers l’arrêt de bus le plus proche.

(a) (b)

(c)

Figure III-9. Problème de tournées avec fenêtres de temps et distances à pieds (instance de Solomon rc201). (a) Solution obtenue. (b) La même solution sans cluster vide. (c) Une solution de VRPTW classique

obtenue par projection des centres de groupe sur leurs (uniques) requêtes associées.

Pour résumer les performances, nous reproduisons dans le Tableau III-1 les résultats obtenus pour les six classes de problèmes du benchmark de Solomon. Les simulations ont été réalisées sur un AMD Athlon (2000 MHz), en attribuant environ 5 minutes de temps d’exécution par problème. Le nombre de véhicules est défini selon les meilleures solutions connues de la littérature. La première colonne du tableau donne le nom de la classe d’instances et le nombre moyen de véhicules. La deuxième colonne reporte la longueur des routes des meilleures solutions connues. Ensuite sont donnés nos résultats avec le nombre de requêtes satisfaites, la longueur des routes, et la distorsion moyenne (distortion / N) respectivement dans les colonnes « sat », « length » et « dist. moy. ». Ces valeurs sont données pour les solutions brutes obtenues, et ensuite sur trois autres colonnes pour les solutions dérivées correspondant à un VRPTW standard. L’écart avec la meilleure solution connue est donné entre parenthèse, en pourcentage de celle-ci.

Tableau III-1. Résultats pour les six classes de tests de Solomon comportant 56 instances.

L’approche produit ses meilleurs résultats sur les instances des classes C1 et C2 dont la distribution de requêtes comporte des îlots ou clusters, et sur les instances mixtes, plus ou moins uniformes avec des clusters, de la classe RC1. La qualité des solutions décroît légèrement pour les instances uniformes de la classe R1. Les résultats sont nettement moins bons sur les instances comportant un horizon large, avec un petit nombre de véhicules, des classes R2 et RC2. Si l’on considère les solutions brutes avec une distorsion non nulle, les longueurs de routes sont pour 4 des 6 classes inférieures à celles des meilleures solutions du VRPTW classique (écart négatif), tandis que la distorsion reste bornée dans un intervalle réduit de longueur 2 unités. De manière concrète, pour une étendue géographique de service d’environ 100 km u 100 km, un client devra marcher au plus 2 km pour joindre le point de service assigné (le plus proche).

L’algorithme n’est pas aussi performant que les heuristiques complexes et puissantes de la recherche opérationnelle. Une revue de ces approches est présentée dans [Bräysy et al. 04].

Par exemple, une recherche tabou à mémoire adaptative [Taillard et al. 97] produit un écart à l’optimum moyen sur les 56 problèmes de 4 % en 8 minutes environ, après normalisation du temps de calcul suivant notre AMD Athlon 2GHz. Le temps de calcul donné pour une station Sun Ultra-Sparc 1 (169 MHz) est normalisé en utilisant les facteurs de Dongarra [Dongarra 06]. Ici, ce temps est divisé par un facteur 12. Ou encore, une approche à base de colonies de fourmis [Gambardella et al. 99] produit un écart de 2,42 % en 3 minutes de temps normalisé.

Ici, le temps de calcul donné pour une station Sun Sparc 10 (50 MHz) est divisé par un facteur 31. Notre algorithme n’est pas aussi performant excepté peut-être pour les classes de problèmes de type C. Cependant, nous pensons que l’approche propose une manière nouvelle de traiter le VRPTW, par l’usage de patterns déformables s’adaptant à la répartition spatiale de la demande et l’introduction possible d’une distance à pied du domicile au point de service.

D’autre part, avec une nette amélioration en temps de calcul, la situation semble s’inverser en

notre faveur sur le VRP dynamique en comparaison de cette même approche de fourmis.

Nous présentons ces résultats au prochain chapitre.