Conception de méthodes pour le transport à la demande pour...

Génie Mathématique et Modélisation 3éme Année

RAPPORT DE STAGE 2012 - 2013

Conception de méthodes pour le transport à la

demande pour les terminaux mobiles de type

smartphones sous Android

Soutenu le 10 septembre 2013

Présenté par

Benjamin Vincent

Responsable du stage Polytech : Gaelle LOOSLI

Responsables du stage au LIMOS : Philippe LACOMME, Nicolay TCHERNEV et Libo REN

Remerciements

Je tiens à remercier dans un premier temps, la direction du LABEX IMOBS3 et plus particulièrement,

Monsieur le Professeur Alain Quilliot responsable du challenge 2 « Services & Systèmes de Mobilité

Intelligente » qui a rendu ce stage possible.

Je tiens également à remercier tous les membres du LIMOS de leur accueil chaleureux.

L’encadrement de mon stage a été réalisé au quotidien par Philippe LACOMME, Nicolay TCHERNEV et Libo

REN. De par leur suivi régulier ils m’ont permis de découvrir le monde de la recherche et ils ont partagé

avec moi leur expérience. Merci aussi à eux pour m'avoir fait découvrir la notion de publication scientifique

et d'avoir écrit avec moi des articles pour des conférences.

Un grand merci pour l’accueil qu’ils m’ont réservé et merci de m’avoir permis de trouver un financement de

thèse, thèse qui débute à la suite de ce stage au sein du LIMOS en collaboration avec Ip Leanware.

Enfin ces remerciements ne seraient pas complets sans y associer les thésards que j’ai eu le plaisir de

fréquenter pendant 6 mois. Sans chercher à les citer tous citons Raksmey PHAN et Diyé DIA.

Résumé

Ce stage a été réalisé au sein du LIMOS, qui est une unité de recherche CNRS et a porté sur l'étude de différents problèmes de tournées de véhicules dont en particulier le VRP et le HVRP. Dans un premier temps, mon travail a consisté à implémenter une métaheuristique de résolution approchée du VRP. Dans un deuxième temps nous nous sommes intéressé au problème de cheminement dans un environnement urbain afin de pouvoir appliquer le travail sur les tournées de véhicules avec des instances issues d’un réseau urbain. Nous nous sommes particulièrement intéressé au cas de cheminement de piétons avec comme objectif de concevoir des algorithmes de cheminement dédiés aux contraintes spécifiques liées au contexte mobile. Le travail réalisé a donné lieu à la conception d'un web service et d'une application mobile pour piéton. Enfin le troisième chapitre est dédié à la conception d'une métaheuristique pour HVRP qui est testée sur des instances de la littérature mais aussi sur des instances générées à partir de réseaux routiers. Le travail réalisé durant ce stage a donné lieu à trois soumissions dans des conférences.

mots clefs : tournées de véhicules, métaheuristique, cheminement, milieu urbain, mobilité.

Abstract

This internship has been achieved in the LIMOS, a CNRS research unit and has been focused on the study of different vehicles routing problems especially on the VRP and on the HVRP. At first, my job was to implement a metaheuristic which is an approximated method of VRP. In a second step we studied the routing problem in an urban in the case of pedestrian with the objective to design algorithms dedicated to the specific constraints in mobile context. The work carried out has resulted in the design of a web service and a route guidance application for pedestrian. Finally, the third chapter of this report is dedicated to design of metaheuristics for HVRP. The metaheuristic we introduced is benchmarked on instances of the literature but also on instances generated from real life networks. The work achieved during this internship resulted in three submissions in conferences.

Keywords : vehicle routing problems, metaheuristic, routing, urban area, mobility.

i

Table des matières Table des matières .................................................................................................................................. i

Liste des figures ..................................................................................................................................... v

Liste des tableaux ................................................................................................................................ vii

Liste des algorithmes........................................................................................................................... viii

Introduction ........................................................................................................................................... 1

Chapitre 1 : Le problème de base en tournées de véhicules : le VRP......................................................... 3

1. Problème du type VRP .......................................................................................................................... 3

1.1 Présentation du VRP ............................................................................................................................ 3

1.2 Etude sur les méthodes de résolution existantes ............................................................................... 5

2. Conception d’une métaheuristique basée sur un codage indirect ...................................................... 6

2.1 Codage indirect des solutions .............................................................................................................. 6

2.2 Critères d’évaluation d’une métaheuristique ..................................................................................... 8

3. Principe d'un GRASP/ELS basé sur un codage indirect ......................................................................... 9

3.1 Définition d’une métaheuristique GRASP ........................................................................................ 9

3.2 Définition d’une métaheuristique ELS ........................................................................................... 11

3.3 La méthode hybride GRASP/ELS .................................................................................................... 11

4. GRASP/ELS proposé ............................................................................................................................ 12

4.1 Schéma général de la méthode implémentée ............................................................................... 13

4.2 Etape d’initialisation : la méthode des plus proches voisins ......................................................... 13

4.3 L’algorithme Split ........................................................................................................................... 14

4.4 La mutation .................................................................................................................................... 18

4.5 La recherche locale ........................................................................................................................ 19

5. Expérimentations numériques ........................................................................................................... 21

5.1 Paramètres ..................................................................................................................................... 21

5.2 Performances des ordinateurs utilisés ........................................................................................... 22

5.3 Résultats numériques .................................................................................................................... 22

6. Conclusion .......................................................................................................................................... 23

7. Références .......................................................................................................................................... 23

Chapitre 2 : Le problème de cheminement de piétons en milieu urbain ............................................... 25

8. Introduction ........................................................................................................................................ 25

Table des matières

ii

1.1 Le problème du plus court chemin .................................................................................................... 26

1.2 Principaux algorithmes de résolution d’un problème de PCC ........................................................... 27

9. Application du problème de PCC dans un environnement mobile .................................................... 35

2.1 Les contraintes à prendre en compte ............................................................................................ 35

2.2 Etude sur la structure d'un système orienté mobile...................................................................... 36

2.3 Etude sur la limitation de la taille du graphe ................................................................................. 37

2.4 Proposition d’une structure d'un système orienté mobile ............................................................ 39

2.5 Proposition d'un système "dynamique" de calcul du PCC ............................................................. 40

10. Réalisation du système de guidage orienté mobilité ......................................................................... 41

3.1 Etude sur les services de cartographie .............................................................................................. 41

3.2 Analyse des besoins du système liés au service de cartographie ..................................................... 42

3.3 Réalisation du Web service ............................................................................................................... 43

3.4 Réalisation d'un client Android.......................................................................................................... 46

11. Analyse des résultats .......................................................................................................................... 48

4.1 Présentation des données ......................................................................................................... 49

4.2 Analyse des résultats : cas idéal ................................................................................................ 50

4.3 Analyse des résultats : cas avec aléas ........................................................................................ 53

12. Conclusion .......................................................................................................................................... 56

13. Références .......................................................................................................................................... 56

Chapitre 3 : Etude du HVRP dans un contexte mobile ............................................................................ 59

1. Problème du type HVRP ..................................................................................................................... 59

1.1 Présentation du HVRP .................................................................................................................... 59

1.2 Etude sur les méthodes de résolution existantes ............................................................................. 61

2. Métaheuristique proposée basée sur un Path-Relinking ................................................................... 62

2.1 Schéma général de la méthode implémentée .................................................................................. 63

2.2 La méthode Split ............................................................................................................................ 65

2.3 Heuristique de génération de solutions ............................................................................................ 71

2.4 Proposition d'une méthode de type Path-Relinking ......................................................................... 73

2.5 La recherche locale ............................................................................................................................ 76

3. Paramètres et résultats ...................................................................................................................... 79

3.1 Paramètres sur les instances classiques ............................................................................................ 79

3.2 Performances des ordinateurs utilisés .............................................................................................. 80

3.3 Résultats numériques sur les instances classiques ........................................................................... 80

Table des matières

iii

3.4 Présentation de l’instance générée sur un réseau routier concret .................................................. 82

3.5 Résultats sur l’instance de Clermont-Ferrand .................................................................................. 83

4. Conclusion .......................................................................................................................................... 86

5. Références .......................................................................................................................................... 86

Conclusion ........................................................................................................................................... 89

Annexes ............................................................................................................................................... 91

v

Liste des figures Figure 1 : Solution d’un problème de VRP .......................................................................................... 5 Figure 2 : Classification des fonctions de mapping d'après (Cheng et al., 1996) ................................ 7

Figure 3 : Liste des publications avec un codage indirect selon Duhamel et al., [Duh12] ................. 8 Figure 4 : Schéma d’une heuristique efficace selon (Duhamel et al., 2011 ) ....................................... 9 Figure 5 : Initialisation de la méthode GRASP .................................................................................. 10 Figure 6 : Recherche locale de la méthode GRASP .......................................................................... 10 Figure 7 : Mutation d’un algorithme ELS .......................................................................................... 11

Figure 8: Recherche locale d’un algorithme ELS .............................................................................. 11 Figure 9 : Schéma d’une métaheuristique de type GRASP/ELS ....................................................... 12 Figure 10 : Mise en correspondance de l’espace des solutions et de celui des tours géants. ............. 12 Figure 11 : Schéma du GRASP/ELS proposé .................................................................................... 13

Figure 12 : Méthode des plus proches voisins ................................................................................... 14 Figure 13 : Exemple d’un problème avec clients déjà ordonnancés .................................................. 15 Figure 14 : Exemple de tournées incluant le premier client .............................................................. 16

Figure 15 : Exemple de tournée n’incluant pas le premier client (A) ................................................ 16 Figure 16 : Schéma de l’ensemble des tournées possibles................................................................. 16

Figure 17 : Calcul du plus court chemin ............................................................................................ 17 Figure 18 : Etape de mutation de l’algorithme GRASP/ELS ............................................................ 18 Figure 19 : Mouvement de type 2-opt intra-tournée .......................................................................... 19

Figure 20 : Mouvement de type 2-opt inter-tournées ........................................................................ 20 Figure 21 : Schéma de la méthode de type GRASP/ELS .................................................................. 22

Figure 22 : Graphe d’un problème de plus court chemin .................................................................. 26 Figure 23 : Initialisation de Dijkstra .................................................................................................. 28 Figure 24 : Première itération de Dijkstra .......................................................................................... 28

Figure 25 : Deuxième itération du Dijkstra ....................................................................................... 29

Figure 26 : Troisième itération du Dijkstra ........................................................................................ 29 Figure 27 : Dernière itération de Dijkstra .......................................................................................... 30 Figure 28 : Initialisation de Bellman .................................................................................................. 31

Figure 29 : Première itération de Bellman ......................................................................................... 31 Figure 30 : Deuxième itération de Bellman ....................................................................................... 32 Figure 31 : Initialisation de Floyd-Warshall ...................................................................................... 32

Figure 32 : Première itération de Floyd-Warshall .............................................................................. 33 Figure 33 : Deuxième itération de Floyd-Warshall ............................................................................ 33

Figure 34 : Troisième itération de Floyd-Warshall ............................................................................ 33 Figure 35 : Fin de Floyd-Warshall ..................................................................................................... 33 Figure 36 : Initialisation de A étoile ................................................................................................... 34

Figure 37 : Liste d’attente de la première itération de A étoile .......................................................... 35 Figure 38 : Liste d’attente de la deuxième itération de A étoile ........................................................ 35

Figure 39 : Liste d’attente de la dernière itération de A étoile ........................................................... 35 Figure 40 : Architecture où l’application client fait office de terminal.............................................. 36

Figure 41 : Limitation du graphe ....................................................................................................... 38 Figure 42 : Contraction du graphe ..................................................................................................... 39 Figure 43 : Architecture permettant de limiter les problèmes de connexion réseau .......................... 40 Figure 44 : Calculs itératifs ................................................................................................................ 41 Figure 45 : Illustration d’une carte constituée de tuiles ..................................................................... 43

Liste des figures

vi

Figure 46 : Diagramme de séquence des fonctions du web service ................................................... 44 Figure 47 : Environnement de développement du Web service ......................................................... 45

Figure 48 : Utilisation du Web service avec un explorateur internet ................................................. 46 Figure 49 : Environnement de développement de l’application cliente ............................................. 47 Figure 50 : Interface de l’application ................................................................................................. 48 Figure 51 : Réseau routier de Clermont-Ferrand et ces banlieues ..................................................... 49 Figure 52 : Graphe représentant le réseau routier de Clermont-Ferrand et ses banlieues ................. 49

Figure 53 : Itinéraire associé à l’instance 2 effectué par un calcul itératif ........................................ 52 Figure 54 : Itinéraire associé à l’instance 10 effectué par un calcul itératif ...................................... 52 Figure 55 : Itinéraire associé à l’instance 20 effectué par un calcul itératif ...................................... 53 Figure 56 : Arbre de probabilité sur trois intersections pour 1% ....................................................... 55 Figure 57 : Arbre de probabilité sur trois intersections pour 10% ..................................................... 55

Figure 58 : Allongement moyen d’un itinéraire par une erreur ......................................................... 56 Figure 59 : Solution d’un problème de HVRP ................................................................................... 60

Figure 60 : Fonction de mapping du HVRP ...................................................................................... 63 Figure 61 : Schéma général de la méthode ........................................................................................ 63 Figure 62 : Ajout de solutions (diversification) ................................................................................. 64 Figure 63 : Etape d’intensification ..................................................................................................... 65

Figure 64 : Première itération du Split pour HVRP ........................................................................... 66 Figure 65 : Deuxième itération du Split pour HVRP ......................................................................... 66

Figure 66 : Troisième itération du Split pour HVRP ......................................................................... 67 Figure 67 : Fin du Split pour HVRP et solution associée .................................................................. 67 Figure 68 : Solution optimale de l’exemple d’HVRP ........................................................................ 68

Figure 69 : Données de l’exemple illustrant l’algorithme de génération de solutions pour HVRP .. 71 Figure 70 : Déroulement de l’algorithme split sur le tour géant initial .............................................. 72

Figure 71 : Première itération de l’algorithme de génération de solution pour HVRP ..................... 72 Figure 72 : Deuxième itération de l’algorithme de génération de solution pour HVRP ................... 72 Figure 73 : Solution de l’heuristique de génération de solutions ....................................................... 72

Figure 74 : Première étape de l’algorithme de Zhang [Zha05] .......................................................... 75 Figure 75 : Deuxième étape de l’algorithme de Zhang [Zha05] ........................................................ 75

Figure 76 : Dernière étape de l’algorithme de Zhang [Zha05] .......................................................... 75

Figure 77 : Principe du Path-Relinking .............................................................................................. 76 Figure 78 : Tours géants générés par l’algorithme du Path-Relinking ............................................... 76 Figure 79 : Mouvement d'insertion .................................................................................................... 78 Figure 80 : Mouvement 4_opt intra-tournée ...................................................................................... 78 Figure 81 : Mouvement 4_opt inter-tournée ...................................................................................... 78

Figure 82 : Paramètres de l’algorithme pour le HVRP ...................................................................... 79 Figure 83 : Réseau routier de l’instance de HVRP sur Clermont-Ferrand ........................................ 82 Figure 84 : Répartition des clients de l’instance de HVRP sur Clermont-Ferrand ............................ 83 Figure 85 : Première tournée de la solution associée à l’instance de Clermont-Ferrand ................... 85 Figure 86 : Deuxième tournée de la solution associée à l’instance de Clermont-Ferrand ................. 85

Figure 87 : Cinquième tournée de la solution associée à l’instance de Clermont-Ferrand ................ 86

vii

Liste des tableaux Tableau 1 : Tableau de comparaison de puissance ............................................................................. 22 Tableau 2 : Résultats du VRP sur les instances de Christofides ........................................................ 23

Tableau 3 : Comparaison des différents systèmes de cartographies .................................................. 42 Tableau 4 : Instances et résultats de référence ................................................................................... 51 Tableau 5 : Bilan des résultats ............................................................................................................ 54 Tableau 6: Méthodes publiées utilisant les instances de Golden et al. référencées par [Pri09] ......... 62 Tableau 7 : Demandes des clients du tour géant de l’exemple du Split ............................................. 65

Tableau 8 : Liste des véhicules disponibles de l’exemple du Split .................................................... 65 Tableau 9 : Demandes des clients de l’exemple de génération de solutions ...................................... 71 Tableau 10 : Liste des véhicules disponibles de l’exemple de génération de solutions ..................... 71 Tableau 11 : Donnée de l’exemple de calcul de distance de Zhang ................................................... 74

Tableau 12 : Performance des processeurs......................................................................................... 80 Tableau 13 : Résultats du HVRP sur les instances de Golden ........................................................... 81 Tableau 14 : Liste des tournées d’une solution sur l’instance de Clermont-Ferrand ......................... 84

viii

Liste des algorithmes Algorithme 1 : 4-plus proches voisins .......................................................................................... 14

Algorithme 2 : Séparation d’un tour géant (Prins 2004)1 ............................................................ 18

Algorithme 3 : 2-opt intra tournée (Recherche locale)................................................................. 19

Algorithme 4 : Recherche locale de type 2-opt inter tournées ..................................................... 21

Algorithme 5 : Split pour HVRP .................................................................................................. 70

Algorithme 6 : Distance de Zhang ............................................................................................... 74

Algorithme 7 : Recherche locale pour HVRP .............................................................................. 77

1

Introduction La recherche opérationnelle est un domaine mêlant l'informatique et les mathématiques. L'objectif de

ce domaine est de développer des méthodes permettant de choisir parmi un nombre important de possibilités, la meilleure solution à un problème donné.

Les problèmes de recherche opérationnelle que nous allons traiter tout au long de ce rapport sont des problèmes de tournées de véhicules. Ils consistent à organiser de façon optimale les tournées d'une flotte de véhicules afin de livrer une liste de clients. La combinatoire des solutions associées à ces problèmes est tellement importante qu’il est difficile de déterminer de façon exacte la solution optimale dans des temps acceptables. De nombreuses méthodes de résolution de ces problèmes sont donc approchées afin d’être exécutées en un minimum de temps. C’est à ces méthodes que nous nous intéressons dans ce rapport.

D’autre part, les nouvelles technologies mobiles (via la téléphonie mobile par exemple) envahissent notre quotidien. On peut penser en particulier aux smartphones et à leurs applications dialoguant avec des services en ligne comme la météo.

L’objectif de ce stage est de réfléchir sur l’adaptation des méthodes du domaine de la recherche opérationnelle dans un environnement mobile. Dans ce contexte, nous nous sommes plus particulièrement intéressés aux problèmes de tournées de véhicules en zone urbaine avec pour objectif de développer des méthodes dynamiques et réactives aux contraintes du développement mobile.

Le rapport de stage est structuré en trois chapitres.

Le premier chapitre concerne la présentation des problèmes de tournées de véhicules et des méthodes approchées de type métaheuristique. Ce chapitre contient une présentation des différentes méthodes de résolution du VRP en détaillant plus particulièrement comment concevoir une métaheuristique GRASP/ELS. Une telle métaheuristique a été implémentée et comparée aux résultats établis en 2004 par C. Prins dont la méthode proposée est considérée comme une référence dans le domaine.

Le deuxième chapitre porte sur le problème de cheminement en milieu urbain. Ce problème illustre parfaitement les contraintes liées au développement mobile et sa résolution est de plus nécessaire pour aborder les problèmes de tournées de véhicules sur des données routières. Nous nous sommes particulièrement intéressés dans ce chapitre au cas du cheminement de piétons afin d’illustrer nos résultats sur une architecture constituée d’une application Android et d’un service web. Ce chapitre contient une présentation du problème de plus court chemin dans des graphes ainsi que de ses différentes méthodes de résolution. Il contient également la présentation de l’algorithme que l’on a développé afin de pallier aux contraintes urbaines et mobiles. On présente également les principes de l’application mobile et du service web développés. On termine ce chapitre par une analyse des résultats de notre algorithme sur des instances concrètes basées sur le réseau routier de Clermont-Ferrand.

Le troisième chapitre aborde le problème de tournées de véhicules dans le cas d’une flotte hétérogène. Ce chapitre consiste à élaborer une méthode de résolution de ce problème en appliquant les contraintes liées à l’environnement mises en évidence au chapitre précédent. Ce chapitre reprend le travail effectué sur la conception de méthodes approchées du chapitre 1 et les résultats sur le problème de cheminement du chapitre 2. Il contient la présentation du problème de tournées de véhicules avec une flotte hétérogène ainsi que de ses différentes méthodes de résolution. Il présente également le principe de la méthode de résolution développée dont les résultats sont comparés avec les résultats des différents articles référents du

Introduction

2

sujet. Ce chapitre conclut sur l’application de la méthode à un exemple issu du réseau routier de Clermont-Ferrand.

Ce stage m'a permis de découvrir le monde de la recherche opérationnelle avec une orientation très appliquée puisque les objectifs ont tous consisté à fournir des méthodes efficaces sur des cas les plus réalistes possibles. C’est pourquoi, ce rapport met en évidence : d’une part l’aspect ingénierie, à travers le développement d’une application mobile et d’un service web, et d’autre part l’aspect recherche à travers la conception de méthodes de résolution pour différents problèmes de recherche opérationnelle.

Chapitre 1 : Le problème de base en tournées de véhicules : le VRP

3

CHAPITRE 1

Le problème de base en tournées de véhicules : le VRP

L’objectif de ce chapitre est d’appréhender les problèmes de tournées de véhicules et certaines méthodes de leur résolution. Pour ce faire, on s’appuie sur le VRP (vehicle routing problem) qui est une extension du problème du voyageur de commerce (travelling salesman problem) et que l’on résout par une méthode approchée de type métaheuristique.

Ce chapitre est structuré en 5 parties. Dans la première partie, on présente le VRP et les différentes méthodes existantes dans la littérature pour le résoudre. Dans un deuxième temps, on s’intéresse à la conception d’une méthode approchée de type métaheuristique. Pour ensuite, dans la troisième partie, aborder le principe général d’une métaheuristique GRASP/ELS. On présente par la suite la métaheuristique développée durant la première partie du stage. Enfin, on présente les résultats obtenus qui sont comparés à ceux de Prins *Prin04+.

1. Problème du type VRP

1.1 Présentation du VRP

Les problèmes de tournées de véhicules se divisent en deux grandes catégories : les problèmes de tournées sur arcs et les problèmes de tournées sur nœuds. Traditionnellement, on considère que le VRP est le problème de base sur les problèmes de tournées sur nœuds. Les problèmes de type VRP (Vehicle Routing Problem) *Chr79+ font partie des problèmes NP-difficiles, c’est-à-dire qu'a priori (sauf si P=NP) il est impossible de trouver la solution de coût minimal en temps polynomial *Pap77+. Le VRP consiste en un certain nombre de clients distants les uns des autres et qui ont chacun une demande s’exprimant par une quantité entière. On dispose, pour satisfaire les demandes, d’une flotte de véhicules homogènes qui ont une certaine capacité de chargement limitant le nombre de clients qu’ils peuvent servir en un seul passage et d’un dépôt. Chaque tournée commence et se termine au dépôt. L’objectif consiste à déterminer un ensemble de tournées permettant de desservir tous les clients et minimisant la distance parcourue par les véhicules.

Définition : Le VRP est définit comme suit : on considère un graphe orienté complet (𝐺 = (𝑉, 𝐸)) où 𝑉 =

*0, . . , 𝑛+ est l’ensemble des sommets et 𝐸 = *(𝑖, 𝑗) | ∀𝑖, 𝑗 𝜖 𝑉, 𝑖 ≠ 𝑗+ est l’ensemble des arcs. Les sommets regroupent le dépôt (sommet 0) et les clients (sommets 1 à 𝑛). Chaque arc (𝑖, 𝑗) représente le plus court chemin pour aller de 𝑖 à 𝑗. On lui associe un coût non-négatif qui représente la distance


4

(ou la durée) de parcours pour se rendre de 𝑖 à 𝑗. Un ensemble de K véhicules (numérotés de 1 à 𝐾) homogènes sont initialement positionnés sur le dépôt. Chaque véhicule k a une capacité 𝑄. Chaque client i possède une demande de livraison 𝐷𝑖. On considère que ∑ 𝐷𝑖 ≤ 𝐾 ∗ 𝑄𝑖=𝑉\*0+ , pour garantir

que la capacité totale est suffisante. Cette condition n’est cependant pas suffisante pour assurer la réalisabilité. On cherche au plus 𝐾 tournées de véhicules sur le graphe qui satisfont les propriétés suivantes :

- (c1) une tournée commence et se termine au dépôt ; - (c2) un sommet est visité une et une seule fois ; - (c3) la charge d’un véhicule ne peut pas dépasser sa capacité ; - (c4) toutes les demandes doivent être satisfaites ; - (c5) la somme des coûts de transport est minimale.

Modélisation mathématique :

Fisher et Jaikumar *Fis81+ ont formulé le problème sous la forme d’un programme linéaire :

Min ∶ z = ∑ ∑ 𝐶𝑖𝑗𝑥𝑖𝑗𝑘

𝐾

𝑘=1(𝑖,𝑗)∈𝐸

(1)

Sous les contraintes :

∑ diyik ≤ Q

i∈V

∀ k = 1, … , K (2)

∑ yik = 1

K

k=1

∀ i ∈ V\*0+ (3)

∑ y0k ≤ K

N

k=1

(4)

∑ xijk = yj

k

i∈V

∀ j ∈ (1, . . , n) , k ∈ 1, … , K (5)

∑ xijk = yi

k

j∈V

∀ i ∈ (1, . . , n) , k ∈ 1, … , K (6)

∑ xijk ≤ |S| − 1

i,j∈ S

∀ S ⊂ V; 2 ≤ |S| ≤ n − 2,

k = 1, … , K(7)

xijk ∈ *0,1+ ∀ i, j ∈ V ; i ≠ j , k = 1, … , K (8)

yik ∈ *0,1+ ∀ i ∈ V , k = 1, … , K (9)

où

𝑉 : l’ensemble des sommets constitué des clients et du dépôt. 𝐸 : l’ensemble des arcs. 𝐶𝑖𝑗 : le coût de l’arc (𝑖, 𝑗).

𝐷𝑖 : la demande du client 𝑖. 𝐾 : le nombre de véhicules. 𝑄 : la capacité des véhicules.

𝑥𝑖𝑗𝑘 : indique si l’arc (𝑖, 𝑗) fait partie de la tournée 𝑘.

𝑦𝑖𝑘 : égale à 1 si le véhicule k effectue le service chez le client i. L’indice i=0 correspond au


5

dépôt. Dans ce modèle, la fonction objectif est de minimiser la somme des coûts de transport. Les

contraintes (2) vérifient que la capacité de chargement de chaque véhicule est bien respectée. Les contraintes (3) permettent de vérifier que chaque client est desservi. Les contraintes (4) permettent de vérifier que l’on construit au plus 𝐾 tournées. Les contraintes (5) et (6) assurent la cohérence entre la visite d’un client par un véhicule 𝑘 et l’appartenance de ce client à la tournée 𝑘. Les contraintes (7) ont pour but d’éviter la formation de sous-tours au sein des tournées.

Modélisation sous forme de graphe :

On peut modéliser une solution du problème de type VRP par un graphe (voir Figure 1) dans lequel le dépôt et les clients sont représentés chacun par un nœud. Chaque arc entre deux sommets symbolise l’ordre de passage du véhicule et la distance qui parcourue.

Figure 1 : Solution d’un problème de VRP

1.2 Etude sur les méthodes de résolution existantes

Les méthodes de résolution des problèmes de VRP peuvent être exactes ou approchées, c’est-à-dire qu’elles peuvent ou non garantir l’optimalité de la solution obtenue *Tot02, Ren12+.

Méthodes exactes : Les méthodes de résolution exactes ne sont, en pratique, utilisées que pour les instances de

petite taille (environ 50 clients) *Tot02+ car le temps de calcul pour ce genre de méthode est exponentiel en fonction du nombre de clients considérés et de ce fait, les instances de taille moyenne (de 100 à 200 clients) ont des temps de résolution peu raisonnables.

Ces méthodes sont divisées en trois catégories :

- les méthodes de branchement (procédure par évaluation et séparation progressive) qui ont pour principe de diviser progressivement l’espace des solutions du problème créant ainsi un arbre de sous problèmes dont les feuilles sont résolubles rapidement par des méthodes de programmation linéaire. (Ex : branch-and-bound *Lap87+) ;

- les méthodes de programmation dynamique qui sont basés sur une logique de résolution ascendante et qui ont pour principe d’élaborer une série de sous-problèmes. Ces méthodes ont été utilisées la première fois pour un problème de type VRP par Eilon et al. *Eil71+ en 1971 ;

- les méthodes basées sur la programmation linéaire en nombres entiers qui comprend par


6

exemple les méthodes de Génération de colonnes proposées par Dantzig et Wolfe *Dan60+.Le mécanisme de la génération de colonnes consiste alors à générer, au sein d'un algorithme à plusieurs étapes, les variables qui sont susceptibles d'améliorer la solution courante. L'efficacité de la méthode est très dépendante du mécanisme utilisé pour générer des colonnes.

Méthodes approchées :

Les méthodes de résolution approchées ne garantissent pas d’avoir une solution optimale, cependant ce sont des outils permettant d’obtenir rapidement une solution de très bonne qualité, elles sont donc particulièrement biens adaptées pour les instances de grandes tailles (plus de 200 clients). La résolution de ce type d'instance par une méthode exacte est généralement impossible.

On peut distinguer deux catégories de méthodes approchées :

- les heuristiques qui sont des algorithmes dédiés à un unique problème. En particulier, celles dédiées au VRP sont souvent issues de celles du TSP. Parmi les heuristiques souvent utilisées pour le VRP, on peut distinguer les heuristiques de construction qui consistent à élaborer la solution étape par étape sans remettre en question l’étape précédente (ex : méthode d’insertion *Chr79+) . Les heuristiques d’amélioration consistent à partir d’une solution existante et à explorer les voisinages pour l’améliorer. Les heuristiques à deux phases consistent à séparer la recherche de l’ordre dans lequel on dessert les clients et l’attribution des clients aux différentes tournées (ex : The Fisher and Jaikumar algorithm *Fis81+) ;

- les métaheuristiques qui sont des méthodes plus générales et qui peuvent s’appliquer à une grande variété de problèmes. Ce sont des schémas généraux qui peuvent incorporer une ou plusieurs heuristiques. Les métaheuristiques sont constituées généralement de deux étapes principales, une étape d’initialisation qui permet d’obtenir une solution initiale valide et une étape d’amélioration de cette solution.

Les métaheuristiques peuvent se distinguer en trois catégories (Classification par Gendreau et al. *Gen02+) :

- les méthodes de recherche voisinage qui consistent à améliorer la solution par des déplacements itératifs en choisissant une nouvelle solution parmi le voisinage considéré. (ex : Le recuit simulé *Osm93+) ;

- les méthodes de recherche à base de population qui consistent à générer plusieurs solutions et à les améliorer en parallèle. (ex : l’algorithme génétique (GA) *Prin04+) ;

- les méthodes de mécanisme d’apprentissage qui basent l’évaluation d’une solution sur les informations recueillies au fur à mesure de l’algorithme. (ex : l’algorithme de colonie de fourmis *Col91+).

Les métaheuristiques développées sont souvent des hybridations entre ces différentes catégories comme l’illustre la métaheuristique détaillée dans la section 3 de ce chapitre.

2. Conception d’une métaheuristique basée sur un codage indirect

2.1 Codage indirect des solutions

Lorsqu’on cherche une solution la plus proche à la solution optimale d’un problème


7

d’optimisation, il n’est pas toujours facile de travailler directement dans l’espace des solutions (qui correspond à l’ensemble des graphes orientés modélisant une solution dans le cas des problèmes de tournées de véhicules). C’est pourquoi, depuis les années 80, dans un premiers temps pour les problèmes d’ordonnancement, de nombreux articles ont mis en évidence l’importance d’une représentation indirecte de la solution. Plus particulièrement, on trouve dans les travaux de Cheng et al. *Che96+, une définition générale (Figure 2), applicable en particulier à notre problème de tournées de véhicules. La Figure 2 montre comment doit être mise en place un codage indirect d’une solution pour être utilisable. Un tel schéma consiste en deux espaces : espace de codage (indirect) et espace des solutions (i.e. codage direct). Chaque élément de l’espace de codage choisi doit, après avoir été appliqué par une fonction de « mapping » simple, correspondre à un élément dans celui des solutions qui respectent les contraintes. D’après *Che96+, il existe trois types de fonctions de « mapping » :

- Les fonctions de type « 1-to-1 » où un et un seul élément de l’espace de codage est associé à un et un seul élément de l’espace des solutions

- Les fonctions de type « n-to-1 » où plusieurs éléments de l’espace de codage peuvent être reliés à un seul élément de l’espace des solutions.

- Les fonctions de type « 1-to-n » où un élément de l’espace de codage peut être relié à plusieurs éléments de l’espace des solutions.

Espace de codage Espace des solutions

1-to-n mapping

n-to-1 mapping

1-to-1 mapping

Figure 2 : Classification des fonctions de mapping d'après (Cheng et al., 1996)

Il est naturellement plus confortable de trouver une fonction de type « 1-to-1 » pour établir une correspondance entre l’espace de codage et l’espace des solutions, cependant dans la pratique, il est très difficile de trouver une fonction de « mapping » du type « 1-to-1 ». Par exemple, la fonction de « mapping » associée au vecteur de Bierwirth *Bie95+ qui est une représentation indirecte classique d’une solution d’un problème d’ordonnancement est du type « n-to-1 ».

Dans le cas des problèmes de tournée de véhicule, la première méthode se basant sur un codage indirect fut une méthode de type « route-first, cluster-second » proposée par Beasley dans un article de 1983 *Bea83+ dans laquelle apparaît la méthode Split, détaillée dans la section 3.2 de ce chapitre, qui permet de passer de l’espace de codage à l’espace des solutions.

L'application de codage indirect pour les problèmes de type VRP se base le plus souvent sur la proposition initiale de Beasley. Depuis les années 2001 ce type de codage a connu un fort engouement et a été inséré dans des techniques globales d'optimisation *Lac 01+. Duhamel et al.


8

*Duh12+ ont réalisé un état de l'art dans lequel 41 articles ont été référencés (Figure 4).

Figure 3 : Liste des publications avec un codage indirect selon Duhamel et al., *Duh12+

2.2 Critères d’évaluation d’une métaheuristique

En considérant un bon nombre de publications, Duhamel et al. *Duh11+ ont mis en évidence les points clés pour élaborer une métaheuristique efficace :

- Une représentation indirecte de la solution plus compacte comme une séquence de nœuds ou de taches à effectuer par exemple ;

- La fonction de « mapping » qui permet d’associer une solution de l’espace de codage indirecte choisie à l’espace des solutions ;

- Une recherché locale effectuant des améliorations à une solution par exploration de son voisinage ;

- Un processus de diversification afin d’éviter de rester cloitrer à certains minimums locaux ;

- Une heuristique de construction d’une bonne solution initiale.


9

Figure 4 : Schéma d’une heuristique efficace selon (Duhamel et al., 2011 )

Comme le montre la Figure 4, le point clef d’une telle métaheuristique est d’alterner entre deux espaces. L’espace de codage qui est utilisé pour le processus de diversification et l’espace des solutions qui est utilisé pour améliorer la solution par une recherche locale.

Dans la majorité des méthodes de résolution des problèmes de tournées de véhicules on peut utiliser comme représentation indirecte un tour géant qui donne un ordre dans lequel doivent être desservis tous les clients. Un tour géant est une solution du problème de voyageur de commerce (TSP) sur une instance constituée du même graphe. On peut alors identifier une telle représentation à une solution de notre problème en découpant ce tour géant de la façon la plus efficace possible en tenant compte des contraintes telles que la capacité de chargement des véhicules.

3. Principe d'un GRASP/ELS basé sur un codage indirect

La métaheuristique de type GRASP/ELS a été proposée la première fois par Prins en 2009, *Prin09+. C’est une hybridation entre une heuristique probabiliste de type GRASP (greedy randomized adaptive search procedure), mise en place par Feo et Resende en 1989, et un algorithme de recherche locale de type ELS (evolutionary local search), initié par Wolf et Merz en 2007. Le schéma d’optimisation exposé dans cette partie n’est pas seulement dédié au problème de tournée de véhicules mais pourra aussi s’appliquer à des problèmes d’ordonnancement par exemple *Cha13+.

3.1 Définition d’une métaheuristique GRASP

La méthode GRASP est une métaheuristique qui permet d’explorer des zones très variées de


10

l’espace des solutions par une gestion correcte de la diversification et de l’intensification durant le processus d'optimisation. Elle se compose de deux étapes distinctes itérées jusqu’à ce qu’un nombre d'itérations choisi soit atteint :

- l’initialisation : consiste à générer une solution du problème. La construction de cette solution se fait généralement par des techniques de construction gloutonne permettant d'obtenir des solutions de qualité médiocre mais dans des temps raisonnable. Elles sont basées dans la majorité des cas, sur une technique de plus proche voisin randomisé.

la première étape consiste à créer une liste ordonnée des sommets à ajouter à la solution en utilisant par exemple un critère d'éloignement par rapport au dernier somme inséré. Dans l’exemple ci-dessous l’étape sélectionne les éléments A, B, et C.

la deuxième étape consiste à choisir aléatoirement un élément de la liste afin de le rajouter au vecteur solution illustré dans l’exemple Figure 5. Dans la majorité des cas, on utilise une probabilité 𝑃 de sélectionner un élément en position 𝑖 dans la liste et on passe à l'élément suivant si la probabilité n'est pas réalisée.

Figure 5 : Initialisation de la méthode GRASP

- La recherche locale consiste, une fois la solution obtenue par l’initialisation, à améliorer cette solution en recherchant la meilleure des solutions parmi celles de son voisinage.

Figure 6 : Recherche locale de la méthode GRASP


11

3.2 Définition d’une métaheuristique ELS

ELS est un algorithme de recherche locale évolutionnaire qui permet d'explorer les minimums locaux adjacents à la solution courante (explorer plusieurs bassins d’attraction). Elle consiste en deux étapes réitérées jusqu’à ce qu’un nombre d’itérations maximal soit atteint :

- Une étape de mutation qui consiste à transformer très légèrement la solution courante afin de donner plusieurs solutions fils : dans l’exemple ci-dessous la solution de départ donne trois solutions fils en sélectionnant, à trois reprises, aléatoirement deux éléments et en les inversant.

Figure 7 : Mutation d’un algorithme ELS

- Une étape de recherche locale qui consiste à améliorer chaque solution fils par un processus de recherche locale. La meilleure solution obtenue est ensuite retenue pour être la solution de départ à l’étape suivante.

Figure 8: Recherche locale d’un algorithme ELS

3.3 La méthode hybride GRASP/ELS

Une méthode hybride regroupant des métaheuristiques de types GRASP et ELS profite des points forts de chacune des d’entre elles ; en effet, une métaheuristique de type GRASP permet de diversifier l’espace de recherche des solutions en repartant à chaque itération d’une nouvelle solution générée par l’étape d’initialisation. Quant à ELS, il permet d’intensifier la recherche locale de façon efficace en explorant un maximum de solutions grâce à sa méthode de mutation. On peut voir sur le schéma Figure 9 comment s’adjacent les heuristiques pour être efficaces.


12

Figure 9 : Schéma d’une métaheuristique de type GRASP/ELS

4. GRASP/ELS proposé

Dans cette partie est présentée l’application du GRASP/ELS au problème de type VRP. Le GRASP/ELS proposé dans cette partie se base sur un principe de codage indirect, et suit le schéma présenté dans la section 3.3.Choix de l’espace de codage

La métaheuristique proposée se base sur une représentation indirecte de la solution. La représentation indirecte choisie pour notre solution est un vecteur de clients nommé « tour géant » : le tour géant est en fait une solution du TSP.

La fonction de « mapping » associée est de type « n-to-1» et a été définie en 2001 par *Lac 01+. Elle est couramment nommée SPLIT dans la littérature, son principe est détaillé dans la section 4.3. La fonction qui permet de passer de l’espace des solutions à l’espace de codage est une fonction de concaténation des différentes tournées d’une solution.

Figure 10 : Mise en correspondance de l’espace des solutions et de celui des tours géants.


13

4.1 Schéma général de la méthode implémentée

La Figure 11 présente le principe d’exécution du GRASP/ELS :

Figure 11 : Schéma du GRASP/ELS proposé

Le GRASP/ELS que nous proposons comprend deux étapes, à savoir :

- L’étape d’initialisation se fait par une méthode de génération de solution consistant à générer un élément (un tour géant) de l’espace de codage indirect par une méthode de type plus proches voisins puis à lui appliquer un algorithme de Split afin d’obtenir un élément (une solution de VRP) de l’espace des solutions ;

- La recherche locale est une hybridation de plusieurs opérateurs basés sur des mouvements de type 2-opt qui s’effectue dans l’espace des solutions. Un mouvement 2-opt correspond à la suppression de deux arcs et à l’ajout de deux nouveaux dans les tournées d’une solution ;

- La méthode de mutation s’effectue par interversion entre deux éléments d’un tour géant, donc s’effectue dans l’espace de codage après la concaténation d’un élément de l’espace des solutions.

4.2 Etape d’initialisation : la méthode des plus proches voisins

La première étape consiste à générer un tour géant. Pour se faire, on choisit un algorithme de plus proches voisins (Nearest Neighbors). L’idée de cet algorithme est de remplir le vecteur qui représente le tour géant élément par élément. Le premier élément du tour géant est un des plus proches voisins du dépôt, puis chaque nouvel élément est un des plus proches voisins du précédent. Une version alternative de cette méthode consiste à sélectionner non pas les plus proches voisins en termes de distance mais les voisins présentant le ratio le plus intéressant entre la charge du véhicule et la distance.

Cette méthode présentée par la Figure 12 ci-dessous est un algorithme (Algorithme 1) itératif randomisé dans le sens où il est connu dans le domaine qu’il est possible de randomiser le choix du voisin dans une liste de sommets voisins qu’on limite à un certain nombre de sommets (souvent 4 ou


14

5).

Figure 12 : Méthode des plus proches voisins

Algorithme 1 : 4-plus proches voisins

Sortie : un tour géant

Début

Etablir la liste des clients ordonnée du plus proche du dépôt au plus

éloigné.

Etablir, pour chaque sommet, la liste ordonnée des clients du plus proche

au plus éloigné du sommet.

Choisir de façon aléatoire comme premier élément du tour géant un des 4

clients les plus proches du dépôt.

Considérer le client choisi comme traité

Tant que tous les clients ne sont pas traités faire

Choisir de façon aléatoire un des 4 clients non-traités les plus

proches du dernier client traité comme élément suivant du tour géant

Considérer le client choisi comme traité

Fin tant que

Fin

4.3 L’algorithme Split

Une fois le tour géant construit, on cherche à identifier les différentes tournées afin d’obtenir un élément de l’espace des solutions. Pour se faire, on effectue un algorithme de Split, c’est-à-dire un algorithme de séparation de tour géant qui consiste à trouver la meilleure façon de découper un tour géant (celle qui donne le coût minimum) tout en respectant la capacité du véhicule.

Le principe de cet algorithme est expliqué à travers un exemple illustré Figure 13 issu de l’article de Prins *Pri04+ :


15

Figure 13 : Exemple d’un problème avec clients déjà ordonnancés

Voici les données du problème montré sur l’exemple :

- Un dépôt symbolisé par le rectangle bleu ;

- 5 clients à livrer représentés par les nœuds A, B, C, D, E ;

- Chaque client a une demande représentée par l’encadré bleu sous son nœud ;

- Les flèches symbolisent l’ordre dans lequel doit être effectué la livraison (données du tour géant) ;

- Les distances entres chaque nœud sont écrites sur les arcs les reliant ;

- La capacité de chaque camion est de 10.

L’algorithme du Split est composé de deux étapes:

- une étape de construction du graphe

- une étape du calcul du plus court chemin

L’étape de construction du graphe :

Le graphe à construire est constitué de :

- Un nœud point de départ sous forme rectangulaire ;

- n nœuds alignés horizontalement où n est le nombre total de clients ;

- Un ensemble d’arc où chaque arc représente une tournée avec son coût associé.

L’ensemble des arcs est alors construit de la façon suivante :

Chaque arc du point de départ vers un nœud 𝑖 représente une tournée regroupant les clients du

tour géant du premier au 𝑖è𝑚𝑒 (les tournées qui ne respectent pas la capacité du camion ne sont pas prisent en compte) :


16

Figure 14 : Exemple de tournées incluant le premier client

Chaque arc (𝑖, 𝑗) représente une tournée du client 𝑖+1 au client 𝑗 du tour géant.

Figure 15 : Exemple de tournée n’incluant pas le premier client (A)

Cette étape donne le schéma suivant :

Figure 16 : Schéma de l’ensemble des tournées possibles


17

L’étape du calcul du plus court chemin :

Une fois le graphe établie il suffit de calculer le plus court chemin pour aller du dépôt jusqu’au dernier nœud pour obtenir l’ensemble de tournées de coût optimal. Pour se faire, on traite les sommets dans l’ordre de leur visite et on obtient ainsi une solution en un seul passage :

Figure 17 : Calcul du plus court chemin

Algorithme de séparation d’un tour géant *Prin04+ :

Données :

- 𝑞 : vecteur de taille n où pour tout i de 1 à n, 𝑞𝑖est la demande correspondant au client i.

- 𝑑 : vecteur de taille n où pour tout i de 1 à n, 𝑑𝑖 est le coût fixe de livraison du client i.

- 𝑐 : matrice de taille (n+1,n+1) où pour tout i,j de 0 à n, 𝑐𝑖𝑗correspond au coût de l’arc (i,j)

où l’indice 0 correspond au dépôt et l’indice k de 1 à n correspond au client k.

- 𝑊 : capacité de chargement d’un véhicule

- 𝐿 : coût maximum d’une tournée

Variables :

- n : nombre de clients

- 𝑉 : vecteur de taille n+1 construit durant l’algorithme tel que 𝑉0 = 0 et pour tout i de 1 à

n, 𝑉𝑖est le coût minimum pour livrer le client en 𝑖è𝑚𝑒 position du tour géant en finissant une tournée par lui.

- charge : variable permettant de vérifier qu’une tournée respecte la capacité d’un véhicule.

- coût : variable permettant d’évaluer le coût de la tournée courante.

- 𝑃 : vecteur de taille n construit durant l’algorithme tel que et pour tout i de 1 à n, l’élément d’indice 𝑃𝑖 + 1 du tour géant correspond au début de la tournée à laquelle appartient le client d’indice i du tour géant.


18

Algorithme 2 : séparation d’un tour géant (Prins 2004) :

Sortie : P

Début

𝑉0 = 0

Pour i de 1 à n faire 𝑉𝑖 = +∞ Fin pour

Pour i de 1 à n faire

charge = 0, coût = 0, j = i

Fin pour

Faire

charge = charge + 𝑞𝑇𝑗

Si i = j alors

coût = 𝑐0𝑇𝑗 + 𝑑𝑇𝑗

+ 𝑐𝑇𝑗0

sinon

coût = coût - 𝑐𝑇𝑗−10 + 𝑐𝑇𝑗−1𝑇𝑗 + 𝑑𝑇𝑗

+ 𝑐𝑇𝑗0

Fin si

si ( charge≤ 𝑊 ) et ( coût ≤ 𝐿 ) alors

si 𝑉𝑖−1 + coût < 𝑉𝑗 alors

𝑉𝑗 =𝑉𝑖−1 + coût

𝑃𝑗 = i-1 Fin si

j = j + 1

Fin si

jusqu’à ( j > n ) ou ( charge > 𝑊 ) ou ( coût > 𝐿 ) Fin pour

Fin

4.4 La mutation

L’originalité de l’approche proposée réside dans la définition d’un opérateur de mutation sur un tour géant. Cette étape consiste alors à générer plusieurs tours géants par permutation de deux éléments choisis aléatoirement dans le tour (mouvement swap randomisé).

Figure 18 : Etape de mutation de l’algorithme GRASP/ELS


19

4.5 La recherche locale

Un autre point clé de ce type d’algorithme est la recherche locale qui doit être très efficace et peu couteuse en temps. Pour le VRP, les mouvements les plus efficaces ont fait l’objet de plusieurs publications et sont relativement bien connues. Ils comprennent en particulier des échanges d’arcs, des mouvements 2-opt intra-tournée et 2-opt inter-tournées.

Opérateur 2-opt intra-tournée :

L’opérateur consiste en un mouvement 2-opt intra-tournée et répété jusqu’à ce que la tournée ne soit plus améliorable par ce mouvement. Le mouvement supprime deux arcs et les remplace par deux nouveaux comme illustré sur la figure ci-dessous. Il faut noter que le fait de procéder à ce changement entraine un changement de sens d’une partie de la tournée. L’opérateur est effectué pour chaque tournée d’une solution.

Figure 19 : Mouvement de type 2-opt intra-tournée

Sur la Figure 19, l’arc de A à B et L’arc de E à F ont été remplacés par un arc de A à E et un de B à F entrainant l’inversion du sens de 3 arcs de la tournée.

Pour être sûr que la tournée n’est plus améliorable par un tel mouvement, on effectue une double boucle pour parcourir tous les échanges d’arcs possibles et on réitère l’opération jusqu’à ce qu’aucune amélioration de la tournée ne soit trouvable (voir Algorithme 3).

Algorithme 3 : 2-opt intra tournée (Recherche locale)

Sortie : solution améliorée

Début

Tant que ( fini = = faux )

fini = vrai

Pour chaque combinaison de deux arcs de la tournée faire

Si le mouvement 2_opt améliore le coût de la tournée alors

fini = faux

effectuer le mouvement 2_opt entre les deux arcs

Fin si

Fin pour

Fin tant que

Fin


20

L’opérateur 2-opt inter-tournées :

L’opérateur consiste en un mouvement 2-opt inter-tournées appliqué à deux tournées et répété jusqu’à ce que le coût total de ces tournées ne soit plus améliorable par ce mouvement. Le mouvement supprime un arc de chaque tournée et les remplace par deux nouveaux comme illustré sur la Figure 20 ci-dessous : ceci revient à échanger la fin des deux tournées. L’opérateur est appliqué à deux tournées reçues en paramètre de la fonction.

Figure 20 : Mouvement de type 2-opt inter-tournées

Sur la Figure 20, l’arc de A à B et L’arc de E à F ont été remplacés par un arc de A à F et un de E à B. Pour être sûr que le coût total des deux tournée n’est plus améliorable par un tel mouvement, on effectue une double boucle pour parcourir tous les échanges d’arcs possibles et on réitère l’opération jusqu’à qu’aucune amélioration de la tournée ne soit trouvée.

Recherche locale appliquée à chaque couple de tournées du tour géant :

Description des données :

- 𝑛𝑖 : nombre de clients dans la i-ème tournée traitée.

- 𝑑 : vecteur de taille nombre de clients de l’instance tel que pour tout i de 1 à n, 𝑑𝑖 est la demande du client i

- 𝑑𝑒𝑚𝑎𝑛𝑑𝑒𝑖 : demande totale des clients de la tournée i.

- 𝐿𝑖 : vecteur de la taille de la tournée i tel que pour tout k de 1 à 𝑛𝑖, 𝐿𝑖𝑘 indique l’indices

du tour géant correspondant au 𝑘è𝑚𝑒 client de la tournée i.

- 𝑊 : capacité des véhicules

Le déroulement de la recherche locale est donnée par algorithme 4.


21

Algorithme 4 : recherche locale de type 2-opt inter tournées

Sortie : solution améliorée

Début

fini = faux

Tant que fini = = faux

fini = vrai

Pour chaque client i de la tournée 1 faire

trop = faux

Pour chaque client j de la tournée 2 faire

Si fini = = vrai et trop = = faux alors

D = 0

Pour k de i+1 à n1 faire

D = D + d_(L_1k )

Fin pour

Pour k de j+1 à n2 faire

D = D – d_(L_2k )

Fin pour

Si demande_2 + D > W alors

trop = vrai

Sinon Si le coût de la solution est amélioré par le

mouvement 2_opt entre l’arc (i,i+1) de la tournée 1 et

(j,j+1) de la tournée 2 et si demande_1 – D ≤ W alors

fini = faux

Effectuer le mouvement 2-opt entre les deux arcs

Fin des boucles

Fin

5. Expérimentations numériques

Dans cette partie sont exposés les résultats obtenus, en termes de performance, de la métaheuristique de type GRASP/ELS dont nous venons de faire la description. L’algorithme a été implémenté c++ sous visual studio 2008 et a été testé sur les instances classiques du VRP puis les résultats sont comparés à ceux obtenus par C. Prins en 2004 *Prin04+.

5.1 Paramètres

Pour présenter l’algorithme de type GRASP/ELS regroupant les différentes étapes présentées dans la partie 3 de ce chapitre et établir les paramètres de façon claire on s’appuie sur le schéma Figure 21. Les différentes étapes :

- L’étape d’initialisation se fait par une méthode de génération de solution de type plus proches voisins (Nearest Neighbors).

- La recherche locale est constituée d’un opérateur 2-opt inter tournées et d’un opérateur 2-opt intra tournée.

- La méthode de mutation s’effectue par interversion entre deux éléments d’un tour géant.

Les différents paramètres qui ont été choisis, de façon à donner les résultats les plus proches de la meilleure solution connue en un temps raisonnable, en effectuant des test sur les premières instances de Christofides et al.:

- Le nombre d’itérations de la boucle GRASP α=30.

- Le nombre d’itérations de la boucle ELS β=30.

- Le nombre d’itérations de la recherche locale après l’initialisation δ1=15.

- Le nombre d’itérations de la recherche locale après la mutation δ2=10.


22

Figure 21 : Schéma de la méthode de type GRASP/ELS

5.2 Performances des ordinateurs utilisés

Pour pouvoir se comparer aux résultats de Prins *Prin04+, on a besoin d’établir la puissance de calcul relative de l’ordinateur utilisé dans ce stage et de celui utilisé par Prins. Pour se faire, on utilise le benchmark du site http://www.roylongbottom.org.uk. Les résultats du benchmark sur l’ordinateur de ce stage et sur un ordinateur équivalent à celui utilisé par Prins sont illustrés dans le Tableau 1 : Tableau de comparaison de puissance :

Tableau 1 : Tableau de comparaison de puissance

(Prins 2004) Ordinateur personnel

Ordinateur Pentium III de 1 GHz Pentium T4200 de 2 GHz OS Windows 98 Windows 7 Language Delphi 6.0 C++ Mflops 316.67 1073.36 Facteur vitesse 1 3.4

5.3 Résultats numériques

Les tests ont été effectués sur les instances numéro 1, 2, 3, 4, 5, 11, et 12 des instances de Christofides et al. *Chr79+, comme indiqué par la première colonne. Ces instances correspondent aux instances traitant de problème de tournée de véhicules sans contrainte de taille maximum des tournées. La deuxième colonne indique le nombre de clients par instance. La troisième colonne indique le coût de la meilleure solution connue sur l’instance. La quatrième colonne donne le coût moyen de la solution obtenu par l’algorithme génétique avec 30 000 « cross-over » de C. Prins. Le temps d’exécution de cet algorithme figure colonne 6 et La différence de coût de cette solution par rapport à la meilleure connue est illustrée colonne 5 par le GAP. A partir de la septième colonne, figurent les résultats de l’algorithme de ce chapitre. Tout d’abord, en colonne 7, on a le coût moyen (sur 10 exécutions) de la solution obtenue par l’algorithme. La huitième colonne indique le GAP de la solution obtenue par rapport à la meilleure connue. Le temps moyen d’exécution de l’algorithme figure colonne 9 et est multiplié par un coefficient de 3.4 colonne 11

http://www.roylongbottom.org.uk/


23

pour être comparé à celui de C. Prins. La colonne 10 correspond au temps moyen pour atteindre la meilleure solution connue (0 si la meilleure solution connue n’est pas atteinte) et il est multiplié par un coefficient de 3.4 colonne 12.

Tableau 2 : Résultats du VRP sur les instances de Christofides

Prins Algorithme proposé

Instance n BKS 30,000

crossovers GAP

% Time

GRASP Av. GAP

% Time

Av.

Time Av.

best

Time Av. St.

Time Av.

best St.

1 50 524,61 524,61 0,00 0,5 524,61 0,00 5,75 2,53 19,55 8,60 2 75 835,26 835,26 0,00 46,36 844,26 1,08 15,1 0 51,34 0 3 100 826,14 826,14 0,00 27,63 833,1 0,84 28,86 0 98,12 0 4 150 1028,42 1031,63 0,31 330,11 1050,93 2,19 73,09 0 248,51 0 5 199 1291,45 1300,23 0,68 1146,52 1343,23 4,01 135,15 0 459,51 0

11 120 1042,11 1042,11 0,00 17,85 1048,12 0,58 41,51 0 141.13 0 12 100 819,56 819,56 0,00 2,7 819,56 0,00 30,02 2,88 102,68 9,79

Moyenne 0,23 224,52 1,24 160.12

Sur les instances 1 et 12 l’algorithme proposé parvient à trouver la meilleure solution connue à chacune de ses 10 exécutions, cependant le temps moyen pour son exécution sur ces 2 instances est très mauvais par rapport à celui de C. Prins (10 et 20 fois supérieur). Sur les autres instances, en comparant le GAP des solutions obtenues avec celui de C. Prins, on voit clairement que l’algorithme proposé donne des solutions qui sont moins bonnes. Au niveau des temps on remarque que l’algorithme proposé est plus rapide sur les instances où C. Prins ne trouve pas la meilleure solution connue et qu’il est plus lent dans les autres cas.

6. Conclusion

Dans ce chapitre nous avons pu découvrir les problèmes de tournées de véhicules et nous sommes monté en compétences sur la conception de méthode de résolution approchée et plus particulièrement sur les métaheuristiques par le biais de l’élaboration d’une métaheuristique de type GRASP/ELS pour la résolution du problème de tournée de véhicules. Nous avons par ailleurs pu comparer les performances de l’algorithme proposé par rapport aux résultats de Prins *Prin04+ qui est une référence dans le domaine des tournées de véhicules. On obtient des résultats satisfaisants et qui permettent d’attaquer des problèmes plus complexes de tournées.

7. Références

*Bea83+ J.E. Beasley. Route-first cluster-second methods for vehicle routing. Omega, vol. 11, pp. 403–408, 1983.

*Bie95+ C., Bierwirth, A generalized permutation approach to job-shop scheduling with genetic

algorithms. OR Spektrum, vol. 17, pp 87-92, 1995.

*Cha13+ M. Chassaing, J. Fontanel, P. Lacomme, L. Ren, N. Tchernev, and P. Villechenon, A GRASP-

ELS approach for the job-shop with a web service paradigm packaging, Expert Systems with

Applications, Available online 19 August 2013.

*Che96+ R. Cheng, M. Gen and Y. Tsujimura. A tutorial survey of job-shop scheduling problems using genetic algorithms – I representation, Computers and industrial engineering, vol. 30, pp. 983-997. 1996.


24

*Chr79+ N. Christofides, A. Mingozzi, P. Toth. The vehicle routing problem. In Combinatorial Optimization, John Wiley, vol. 11, pp. 315–338, 1979.

*Col91+ A. Colorni, M. Dorigo, and V. Maniezzo. Distributed optimization by ant colonies. In F. Varela and P. Bourgine, editors, Proceedings of the European Conference on Artificial Life, Elsevier, Amsterdam, pp. 134–142, 1991.

*Duh11+ C. Duhamel, P. Lacomme, C. Prodhon. Efficient frameworks for greedy split and new depth first search split procedures for routing problems. Computers & Operations Research, vol. 38, pp. 723-739, 2011.

*Eil71+ S. Eilon, C.D.T. Watson-Gandy, and N. Christofides. Distribution Management: Mathematical Modelling and Practical Analysis. Griffin, London, 1971.

*Fis81+ M.L. Fisher, R. Jaikumar. A generalized assignment heuristic for vehicle routing. Networks, vol. 11, pp. 109–124, 1981.

*Gen02+ M. Gendreau, G. Laporte, J.Y. Potvin. Metaheuristics for the capacitated VRP. In: P. Toth, D. Vigo, Editors. The Vehicle Routing Problem. SIAM Monographs on Discrete Mathematics and Applications. SIAM, Philadelphia, pp. 129–154, 2002.

*Lac01+ P. Lacomme, C. Prins and W. Ramdane-Cherif, "Competitive genetic algorithms for the Capacitated Arc Routing Problem and its extensions". EURO-GP 2001 (4th European Conference on Genetic Programming), Côme, Italie, 18-20 avril 2001.

*Lap87+ G. Laporte, Y. Nobert. Exact algorithms for the vehicle routing problem. Ann. Discrete Math, vol. 31, pp. 147–184, 1987.

*Pap77+ C. H. Papadimitriou. The Euclidean travelling salesman problem is NP-complete. Theoretical Computer Science, vol. 4(3), pp 237–244, 1977.

*Prin04+ C. Prins. A simple and effective evolutionary algorithm for the vehicle routing problem, Computers & Operations Research, vol. 31, pp. 1985–2002, 2004.

*Prin09+ C. Prins. A GRASP×Evolutionary Local Search Hybrid for the Vehicle Routing Problem, in: F.B. Pereira and J. Tavares (Ed.), Bio-inspired Algorithms for the Vehicle Routing Problem, Studies in Computational Intelligence, publisher Springer, Berlin, vol. 161, pp.35–53, 2009.

*Ren12+ L. REN, État de l’art : problèmes et méthodes autour des tournées de véhicules, Conception et évaluation d’outils décisionnels pour des systèmes réactifs d’aide à la mobilité. PhD thesis, Université Blaise Pascal, Clermont-Ferrand, 2012.

*Tot02+ P. Toth, D. Vigo. Models, relaxations and exact approaches for the capacitated vehicle routing problem. Discrete Applied Mathematics, vol. 123 (1-3), pp. 487–512, 2002.

Chapitre 2 : Le problème de cheminement de piétons en milieu urbain

25

CHAPITRE 2

Le problème de cheminement de piétons en milieu urbain

L’objectif de ce chapitre est d'étudier en quoi un contexte mobile peut amener à redéfinir certains algorithmes afin de proposer un système orienté mobile qui soit efficace. Pour ce faire, on se place dans le cas du cheminement de piétons en milieu urbain pour lequel la conception d'une application mobile basée sur une architecture client-serveur va être réalisée. La conception de cette application comprend la conception d'un algorithme de plus court chemin adapté c'est-à-dire permettant d’effectuer des calculs au fur et à mesure du déplacement du piétons offrant la possibilité de réagir aux aléas du parcours.

Dans un premier temps, on introduit les algorithmes de plus court chemin et plus généralement les problèmes de cheminement dans les graphes avant de présenter l’algorithme développé. Dans un deuxième temps, nous montrons comment cet algorithme s'intègre au sein d'un système complet visant à calculer puis à guider un usager de sa position actuelle vers une destination. Le chapitre se termine par une étude statistique du système en évaluant sa performance en fonction des aléas liés aux déplacements.

1. Introduction

Au cours des dernières années il y a eu un regain d'intérêt pour le problème du plus court chemin pour une utilisation dans diverses applications de l'ingénierie des transports. Ceci peut être attribué aux récents développements dans les systèmes de transport intelligents (STI), en particulier dans le domaine du système de guidage (GPS). Dans chacun de ces cas, il est absolument nécessaire de trouver les chemins les plus courts à partir d'un point d'origine vers une destination d’une manière rapide et précise.

Un certain nombre de stratégie de recherche ont été développées pour augmenter l'efficacité des algorithmes de plus court chemin. La plupart de ces stratégies proviennent du domaine de l'intelligence artificielle (AI). On peut citer entre autres *Nil71+ et *Pea84+ où le problème du plus court chemin est utilisé comme un mécanisme permettant de valider l'efficacité des heuristiques.

Le domaine actuel du système de guidage en Amérique du Nord et en Europe a généré un regain d'intérêt en utilisant des algorithmes heuristiques pour trouver les plus courts chemins dans un réseau routier pour les opérations de routage de véhicules en temps réel. En 1989, *Guz89+ a examiné comment les méthodes de recherche heuristique pourraient être utilisés dans le système de navigation de véhicule. Un grand nombre de chercheurs ont alors suivi cette piste et ont essayé d'introduire une stratégie mondiale visant à améliorer l'efficacité du processus de recherche du plus court chemin. Ces efforts ont donné lieu à une abondante littérature, y compris un large éventail de


26

stratégies et de mécanismes recherche *Gub10+, *Will05+.

1.1 Le problème du plus court chemin

Le problème de cheminement dans un réseau routier, c’est-à-dire la recherche d’un itinéraire, se ramène à un problème du plus court chemin (PCC) dans un graphe représentant le réseau routier (Figure 22). Les sommets du graphe représentent des points précis du réseau (comme un carrefour ou un bâtiment) et les arcs représentent les routes reliant ces différents points avec pour chacun d’entre eux un coût symbolisant la longueur de la route (en temps et ou en distance selon les besoins).

Figure 22 : Graphe d’un problème de plus court chemin


Soit 𝐺 = (𝑉, 𝐸) où 𝑉 est l’ensemble des sommets et 𝐸 est l’ensemble des arcs avec un coût 𝐶𝑖𝑗 ≥ 0 associé à chaque arc (𝑖, 𝑗) ∈ 𝐸, on peut alors formuler le problème de la façon suivante :

Min ∶ z = ∑ 𝐶𝑖𝑗𝑦𝑖𝑗𝑘

(𝑖,𝑗)∈𝐸

(1)


∑ yj,i

(j,i)∈E

− ∑ y𝑖,𝑗 = {1, 𝑠𝑖 𝑗 = 𝑠−1, si j = t

0, sinon(i,j)∈E

∀ j ∈ V (2)

yi,j ∈ *0,1+ ∀ (i, j) ∈ E (3)

où :

𝑉 : l’ensemble des sommets constitué des clients et du dépôt. 𝐸 : l’ensemble des arcs. 𝑠 : le sommet de départ. 𝑡 : le sommet d’arrivée.

𝑦𝑖,𝑗 : 1 si l’itinéraire passe par l’arc (𝑖, 𝑗) ∈ 𝐸 si non 0


27

Dans ce modèle, les contraintes 2 sont constituées de trois inégalités ; la première vérifie que l’on part du point de départ, la deuxième vérifie que l’on finit le trajet au point d’arrivée et la dernière vérifie que chaque sommet du graphe contient autant d’arcs entrants compris dans l’itinéraire que d’arcs sortants (conservation de flot).

1.2 Principaux algorithmes de résolution d’un problème de PCC

La recherche sur les algorithmes de plus court chemin s’est principalement développée à la fin des années 50 et durant les années 60 comme le rappelle l’article de Dreyfus en 1969 *Dre69+. De nos jours, la recherche sur les problèmes de plus court chemin s'est orientée vers les graphes de grandes tailles et sur la réduction de ces graphes. On peut consulter à ce sujet les travaux de Willhalm en 2005 *Wil05+, ou encore ceux de Gubichev en 2010 *Gub10+. Il est possible de distinguer les algorithmes de résolution du problème de plus court chemin en deux catégories :

les méthodes exactes qui garantissent l’optimalité de la solution obtenue ;

les méthodes approchées qui donnent une solution de bonne qualité mais pas forcément optimale en un temps généralement plus court.

Méthodes exactes :

Les méthodes exactes pour la résolution de problèmes de PCC sont très utilisées dans le secteur industriel et cela même pour des graphes de grandes tailles où elles sont généralement associées à des techniques de réduction et de contraction de graphes. Parmi les algorithmes de résolution exacte du problème de PCC les plus connus, on retrouve l’algorithme de Dijkstra *Dij59+ qui s’applique aux graphes à coût positif, l’algorithme de Bellman *Bel58+ qui autorise la présence d'arcs de coût négatif et l’algorithme de Floyd-Warshall *War62+ qui permet d’obtenir les distances entre chaque pair de points du graphe en une seule exécution.

- L’algorithme de Dijkstra *Dij59+

Cet algorithme possède une complexité de l’ordre de (m+n)×n où 𝑚 est le nombre d’arcs du graphe étudié et 𝑛 est son nombre de nœuds. Dans le cas d’un réseau routier 𝑚 et 𝑛 sont du même ordre de grandeur, l’algorithme a donc une complexité quadratique suivant le nombre de nœuds du graphe. C’est un algorithme itératif dans lequel l’information sur la distance parcourue depuis le point de départ est propagée de voisin en voisin jusqu’au point d’arrivée. Pour se faire, cet algorithme repose sur un principe de propagation de labels. Au fil de l’algorithme, à chaque nœud traité, le label qui lui est associé est le coût du plus court chemin pour l’atteindre depuis le nœud de départ. A ce nœud est alors aussi associé un nœud père qui est le précédant dans le plus court chemin jusqu’à lui.

L’exemple de la Figure 23 donne l'initialisation de l'algorithme pour un calcul du plus court chemin du nœud 𝑠 au nœud 𝑡. Il s'agit d'initialiser le label du nœud 𝑠 à 0 et tous les autres labels à +∞ puis dans un tableau de mémoriser les sommets du graphe non-traités par l’algorithme.


28

Figure 23 : Initialisation de Dijkstra

Vient ensuite l’étape itérative qui consiste à choisir le sommet du graphe non-traité qui possède le label le plus petit puis à propager son label vers les nœuds qui lui sont adjacents. Sur l’exemple on choisit donc le sommet 𝑠 qui a un label de valeur 0. On met ensuite à jour les labels des nœuds 4 et 5 qui sont adjacents au nœud de départ par le label du nœud 𝑠 auquel on ajoute le coût de l’arc parcouru (notons que l’on ne change un label qu’avec une valeur qui lui est inférieure). Enfin le sommet 𝑠 est supprimé du tableau des nœuds non-traités.

Figure 24 : Première itération de Dijkstra

On réitère cette étape jusqu’à ce que le nœud d’arrivée t porte le plus petit label parmi les nœuds non-traités. On choisit donc à l’étape suivante le nœud 4 et on met à jour les labels des nœuds 2,3


29

et 7.

Figure 25 : Deuxième itération du Dijkstra

On tombe sur un cas où on a deux choix pour le sommet à traiter, le 5 et le 7. Il est possible de choisir arbitrairement l’un des deux sans que cela change la solution finale. Dans ce cas le sommet 5 est choisi en premier. On met donc à jour le label du nœud 2.

Figure 26 : Troisième itération du Dijkstra

A partir du nœud 7, et on met à jour les labels des nœuds 1, 6, 8 et t.


30

Figure 27 : Dernière itération de Dijkstra

Arrivé à cette étape, on peut constater que 𝑡 fait partie des sommets qui ont le plus bas label parmi ceux non-traités, on peut donc s’arrêter à cette étape. Il nous suffit alors de remonter les nœuds pères depuis le nœud d’arrivé jusqu’au nœud de départ pour obtenir une solution optimale ; on trouve alors le chemin (s,4,7,t) de coût 35 comme solution optimale du problème de plus court chemin.

Une partie très importante du temps de calcul de cet algorithme repose dans la recherche du plus petit label à chaque itération. Cette étape peut être grandement accélérée par l’utilisation d’un tas pour stocker les labels des nœuds non-traités au lieu d’un tableau. En effet, lorsque l’on utilise un tableau, la recherche du plus petit élément se fait en O(n) alors que la recherche dans un tas se fait en O(1) à partir du moment où le tas est réarrangé en O(ln(n)) à chaque itération. On obtient alors un algorithme de complexité O((m + n) × ln(n)) au lieu de O((m + n) × n).

- L’algorithme de Bellman *Bel58+

Cet algorithme possède une complexité au pire de l’ordre de 𝑛2 × 𝑚 où 𝑚 est le nombre d’arcs du graphe et 𝑛 est le nombre de nœuds. Cet algorithme est un algorithme de programmation dynamique qui se distingue du précédent par le fait que l'ordre de parcours des sommets ne peut pas être obtenu en sélectionnant le sommet ayant le plus petit label à une itération donné du fait des arcs à coûts négatifs. Il faut donc déterminer a priori un ordre de parcours des sommets. Cet ordre a une influence très importante sur le nombre d'itérations de l'algorithme. Un ordre de parcours des sommets permettant de faire un seul passage sur l'ensemble des sommets du graphe défini un ordre topologique. Au pire des cas, l'algorithme peut effectuer autant d'itérations qu'il y a de sommets dans le graphe.

Comme pour l’algorithme de Dijkstra, la première étape est une étape d’initialisation dans laquelle on met le label du nœud 𝑠 à 0 et tous les autres labels à +∞. A chaque itération de l’algorithme, tous les arcs du graphe sont parcourus, selon l'ordre initialement choisi. En fonction de l'ordre choisi, le nombre total d'itérations de la méthode varie. Sur cet exemple, au pire, la méthode effectuera donc 5 itérations. L'ordre de parcours des sommets du graphe permettant de trouver le chemin optimal en 1 itération est appelé ordre topologique. Dans la majorité des cas, sauf à utiliser des graphes ayant une structure particulière, la détermination d'un ordre topologique n'est pas triviale.

A titre d'exemple, considérons l'ordre O : s 1 2 3 4 t


31

Figure 28 : Initialisation de Bellman

Lors du premier passage :

On commence par le sommet s qui entraine une mise à jour des nœuds 2 et 3.

On regarde les arcs issus du nœud 1 qui a toujours pour label +∞ donc rien n’est à mettre à jour.

On regarde les arcs issus du nœud 2, on met à jour les labels des nœuds 1 et 4.

On regarde les arcs issus du nœud 3, on met à jour le label du nœud 4.

On regarde les arcs issus du nœud 4, on met à jour le label du nœud d’arrivée.

Figure 29 : Première itération de Bellman

Lors du second passage :

On commence par regarder les arcs issus de s où rien n’est à changer.

On regarde les arcs issus du nœud 1, on met à jour le label du nœud d’arrivée.

On regarde les arcs issus du nœud 2, rien n’est à changer.




32

Figure 30 : Deuxième itération de Bellman

L’algorithme effectue un troisième passage durant lequel aucun des labels n’est modifié. L’algorithme est donc fini et on obtient le chemin (s, 2, 1, t) avec un coût de 40 comme solution optimale du problème de plus court chemin.

- L’algorithme de Floyd-Warshall :

Cet algorithme possède une complexité de l’ordre de 𝑛3 où 𝑛 est le nombre de nœuds du graphe étudié. Cet algorithme a un intérêt un peu différent des deux précédents du fait qu’il calcul l’itinéraire le plus court pour tous les couples de sommets du graphe et pas pour un seul couple. Le principe de cet algorithme est qu’à chaque itération, on va fixer un point de passage à l’ensemble des itinéraires et mettre à jour les itinéraires qui sont améliorés en passant par ce point. L’exemple Figure 31 servira à illustrer son principe. Les figures 31 à 35 présentent le déroulement de l’algorithme avec les tableaux des coûts associés. Sur l’exemple les arcs ne sont pas orientés afin de simplifier l’exemple. La première étape est une étape d’initialisation dans laquelle on initialise le tableau des coûts des différents chemins par le coût des arcs lorsque les nœuds de départ et d’arrivée sont adjacents et par +∞ sinon.

Figure 31 : Initialisation de Floyd-Warshall


33

La première étape consiste à fixer le nœud 1 et à regarder pour chaque couple de points si le chemin est amélioré en passant par ce nœud. A cette itération, le chemin 2 à 5 est le seul à être amélioré.

Figure 32 : Première itération de Floyd-Warshall

A la deuxième itération on s’intéresse au nœud 2, le chemin de 1 à 3 et le chemin de 3 à 5 sont améliorés.

Figure 33 : Deuxième itération de Floyd-Warshall

On s’intéresse ensuite au nœud 3, les chemins de 1 à 4 et de 2 à 4 sont améliorés.

Figure 34 : Troisième itération de Floyd-Warshall

On s’intéresse ensuite au nœud 4, le chemin de 3 à 5 est amélioré. Enfin en regardant le nœud 5, le chemin de 1 à 4 est amélioré. On obtient donc, à la fin de ces itérations, un tableau des coûts des plus courts chemins entre chaque couple de nœuds.

Figure 35 : Fin de Floyd-Warshall

Méthodes approchées :

Les méthodes approchées pour la résolution du problème du PCC sont très utilisées dans le domaine de l’intelligence artificiel et des jeux vidéo par exemple car elles permettent d’obtenir une solution de façon très rapide. L’algorithme de résolution approchées du problème du PCC le plus connu est l’algorithme A* de *Har68+.


34

- L’algorithme de A*:

Si on faisait une recherche en largeur comme le réalise l'algorithme de Dijkstra, on rechercherait tous les points dans un rayon circulaire fixe, augmentant graduellement ce cercle pour rechercher des intersections de plus en plus loin de notre point de départ. Ceci pourrait être une stratégie efficace si on ne savait pas où se trouve notre destination, comme la police recherchant un criminel en planque.

On peut considérer que l’algorithme de A étoile est basé sur le même principe que celui de Dijkstra. Il repose en effet sur une propagation de labels et sur une sauvegarde du nœud père à chaque itération similaire à l’algorithme de Dijkstra. Sa différence réside dans le fait que plutôt que d’élargir progressivement le rayon de propagation des labels à partir du nœud de départ dans toutes les directions, on explore en priorité les nœuds en direction du nœud d’arrivé. Cette notion de direction induit une notion de distance à définir. On choisit pour présenter l’algorithme la distance euclidienne. L’idée de l’algorithme est alors d’estimer pour chaque nœud le coût qui le sépare du nœud d’arrivé afin que d’éviter de traiter les nœuds désavantageux ; l’algorithme va à chaque itération construire un itinéraire en prenant le point de passage suivant, autant que faire se peut, en direction du point d’arrivée. Son principe est illustré sur l’exemple de la Figure 36, sur laquelle on s'intéresse au calcul du plus court chemin du nœud s au nœud t. La première étape est une étape d’initialisation dans laquelle on calcule pour chaque nœud une estimation de sa distance au point d’arrivée qui est la distance Euclidienne dans le cadre de cet exemple. On finit cette étape en initialisant la file d’attente avec le point de départ.

Figure 36 : Initialisation de A étoile

A chaque itération de l’algorithme, il faut considérer le premier élément de la file d’attente, parcourir chacun de ses nœuds adjacents qui n’ont pas encore été traités par l’algorithme. Ils sont ajoutés à la file d’attente de la façon suivante. On somme le coût de l’arc pour parvenir au nœud et son estimation pour atteindre le nœud d’arrivée et on ordonne ensuite la liste de la plus petite valeur à la plus grande. Cette étape est réitérée jusqu’à atteindre le nœud d’arrivée. Lors de la première itération, on s’intéresse donc aux nœuds 4 et 5 que l’on ajoute à la file d’attente respectivement avec les valeurs 45 et 65. On considère ensuite s comme traité.

http://fr.wikipedia.org/wiki/Algorithme_de_Dijkstra


35

Figure 37 : Liste d’attente de la première itération de A étoile

A la deuxième itération, le premier élément de la file est le nœud 4 et ses nœuds adjacents sont les nœuds 2, 3 et 7 que l’on rajoute donc à la liste.

Figure 38 : Liste d’attente de la deuxième itération de A étoile

A la troisième itération, le premier élément de la file est le nœud 7 et ses nœuds adjacents sont les nœuds 1, 5, 6, 8 et t. t, le nœud d’arrivée, fait partie de la liste des nœuds adjacents au nœud en tête de liste donc l’algorithme s’arrête. Suivant le même principe que pour l’algorithme de Dijkstra, on remonte le chemin depuis le nœud d’arrivée et obtient une solution approchée du plus court chemin (s,4,7,t) qui est, dans ce cas, une solution optimale.

Figure 39 : Liste d’attente de la dernière itération de A étoile

2. Application du problème de PCC dans un environnement mobile

Cette partie est consacrée à la conception de l’algorithme du plus court chemin pour piétons dans un environnement urbain modélisé sous la forme d'un graphe orienté. L'objectif est de fournir un système capable de calculer un plus court chemin mais aussi de guider l'utilisateur dans des conditions réelles d'utilisation.

2.1 Les contraintes à prendre en compte

La première difficulté à résoudre est la gestion des problèmes de modélisation du réseau routier. En effet, le graphe modélise un réseau routier "idéal", dans lequel ne sont pas pris en compte les travaux, les accidents ou les changements "récents" des règles de circulations (nouveau sens interdit, rue interdite à la circulation…). Ces éléments (aléas) peuvent induire de la part de l'usager du système, une incapacité à respecter des consignes c'est-à-dire l'incapacité à respecter le plus court chemin calculé. Ces aléas sont aussi dus à des difficultés à communiquer les consignes (tourner à droite, puis à gauche) : reflets du soleil sur l'écran du smartphone, bruits ambiant empêchant l'usager de comprendre l'indication par exemple.

La deuxième difficulté est liée à la taille des graphes modélisant le réseau routier. A titre d’exemple, une région de la France comme l’Auvergne comporte 95 000 nœuds et 233 000 arcs, on se situe donc dans des graphes de grandes tailles. Il s'agit donc d'intégrer cela dans la conception des algorithmes. Cette remarque prend tout son sens dans la mesure où le système est une architecture client-serveur. Dans ce type de système de nombreux utilisateurs de smartphone partage une même ressource (le serveur) sur lequel les calculs sont effectués.


36

Compte tenu des deux difficultés qui viennent d'être mise en évidence, nous avons proposé un algorithme de plus court chemin dynamique travaillant sur un graphe réduit.

2.2 Etude sur la structure d'un système orienté mobile

Il s'agit d'une architecture dans laquelle les clients (leurs mobiles) se connectent via une application dédiée à un serveur qui va effectuer les calculs. Les rôles respectifs du mobile et du serveur peuvent varier selon le type d’architecture considérée. On présente ci-dessous deux schémas d’architecture client-serveur classiques :

Architecture avec un client de type terminal

L’architecture client-serveur dialoguant avec un serveur de cartographie et avec un client de type terminal se décompose en trois parties (Figure 40) :

Une partie client qui prend en charge le déclenchement de la demande de calcul du plus court chemin (1). C’est-à-dire qu’elle est en charge de fournir au serveur les coordonnées de départ et d’arrivé de l’itinéraire souhaité. Une fois l’itinéraire récupéré (5), elle est chargée également de la visualisation du chemin, donc de la récupération des tuiles auprès de MapQuest ainsi que de l’affichage de l’interface.

Une partie serveur qui, après avoir récupéré les positions de départ et d’arrivée auprès de la partie cliente, s’occupe de récupérer les données routières auprès d’OSM (2) et (3) afin de construire le graphe nécessaire au calcul d’itinéraire. Une fois le graphe construit, le serveur effectue le calcul de plus court chemin (4) afin de renvoyer à l’application cliente l’itinéraire obtenu (5).

Le serveur de données routières d’OSM qui permet de fournir les données nécessaires à la réalisation du graphe (2) et (3).

Figure 40 : Architecture où l’application client fait office de terminal

Une architecture de ce type a pour intérêt, d’une part de limiter au maximum la quantité de données présentes sur l’application mobile qui ne contient alors que les données strictement nécessaires à l’interface et à l’affichage du résultat pour l’utilisateur, et d’autre part d’effectuer les calculs sur le serveur distant afin d’alléger la consommation CPU de l’application.

L’inconvénient de cette architecture est qu’elle nécessite une connexion réseau quasi-permanente entre l’application cliente et le serveur. En effet, plusieurs appels au serveur sont


37

effectués à chacun des recalculs d’itinéraire, c’est-à-dire à chaque fois que l’utilisateur s’éloigne de l’itinéraire calculé ou qu’il s’approche de la fin du morceau d’itinéraire calculé. Cette architecture est donc très sensible aux coupures réseaux qui sont très fréquentes en milieu urbain. C’est pourquoi la seconde architecture client-serveur qui est présentée limite le nombre d’accès au serveur.

Architecture avec un client de type semi-autonome

Il s'agit d'une architecture dans laquelle le client est en autonomie partielle vis-à-vis du serveur. Cette architecture se compose des trois éléments identiques à l’architecture précédente mais qui voient leur rôle au sein de l’architecture client-serveur modifié :

La partie client prend en charge le déclenchement du calcul mais aussi le calcul lui-même. Elle récupère donc du serveur le graphe nécessaire au calcul d’itinéraire (1) et (4) avant d’effectuer, si l'état du réseau est insuffisant, en local un calcul de plus court chemin (5). Elle reste, bien sûr, chargée de la récupération des tuiles auprès de MapQuest pour l’étape de visualisation du chemin ainsi que de l’affichage de l’interface.

La partie serveur qui récupère les données routières d’OSM (2) et (3) puis qui les transforme en un graphe qui est ensuite envoyé à la partie client pour le calcul d’itinéraire.

Le serveur de données routières d’OSM qui continue de jouer le rôle du fournisseur de données nécessaires à la réalisation du graphe (2) et (3).

Une architecture de ce type a pour intérêt de limiter le nombre de communications avec le serveur tout en évitant de télécharger des quantités de données routières trop importantes en local. L’inconvénient de cette architecture est la quantité de données qui doivent être récupérées et présentes sur le client ainsi que la consommation CPU de l’application client est assez importante dû au fait que certains calculs se font directement sur le client (en l'occurrence un téléphone portable). Dans cette configuration, une fois le graphe récupéré du serveur, l’application peut fonctionner en autonomie jusqu’à ce que le graphe en local devienne obsolète pour le calcul d’itinéraire. En effet, les cas de demande de recalcul due à l’utilisateur qui s’éloigne de l’itinéraire ne nécessitent généralement pas le téléchargement d'un nouveau graphe.

Pour résumer, cette architecture comme la précédente permet de ne pas télécharger les données routières sur le client afin de ne pas saturer la connexion et la mémoire du mobile, elle se différentie par le calcul effectué éventuellement en local qui permet de réduire le nombre de communications avec le serveur.

2.3 Etude sur la limitation de la taille du graphe

Depuis plusieurs années les principales publications sur les problèmes de PCC dans les graphes de grande taille travaillent sur des techniques de limitation de la taille du graphe *Wil05+, *Gub10+. Ces techniques sont partagées entre les techniques visant à limiter le nombre de nœuds considérés et les techniques limitant le nombre d’arrêtes empruntables.


38

Techniques limitant l'exploration du graphe

Dans l’optique de parcourir moins de nœuds lors de l’exécution de l’algorithme de Dijkstra, il est possible de limiter l'exploration du graphe à un sous-graphe situé autour du chemin représentant la distance euclidienne. On peut alors délimiter une zone ellipsoïdale de taille raisonnable (c’est-à-dire de façon à garder la connexité entre le point de départ et d’arrivée) autour de cette ligne droite afin de limité l'exploration du graphe à ce sous-graphe.

Figure 41 : Limitation du graphe

Il faut noter que dans un graphe modélisant une zone urbaine on perd l’optimalité du plus court chemin mais que probablement dans un grand nombre de cas, le chemin trouvé est probablement être proche du chemin optimal pour peu que la densité soit suffisante.

Contraction du graphe

Après avoir limité la taille du graphe à explorer, on peut aussi appliquer des principes de contraction du graphe. Comme de nombreux auteurs l'ont souligné il existe de nombreuses techniques permettant de contracter plusieurs sommets en un seul sommet et des techniques visant à limiter le nombre d'arcs. Ces techniques sont présentées par exemple par *Dor03+ et par *Dor05+. A titre d'exemple, nous soulignons ci-dessous, la possibilité, dans le cas d'un calcul d'itinéraire pour piétons (graphe non orienté) qu'il est possible d'envisager la suppression des arcs qui ne sont pas orienté dans la direction (s; t) en considérant que plus on s'éloigne de la ligne droite entre s et t, plus la probabilité de rester sur le plus court chemin diminue. Toutefois, les nombreux sens interdits en zone urbaine limite cette remarque aux piétons. Il est alors possible de contracter le graphe de différentes manières, en supprimant par exemple les arcs qui ont un sens opposé au sens défini par le point de départ et d’arrivée dans la mesure où l’on garde une connexité entre le point de départ et d’arrivée. La Figure 42 illustre la contraction possible sur le graphe.


39

Figure 42 : Contraction du graphe

2.4 Proposition d’une structure d'un système orienté mobile

Il s'agit de définir une architecture qui soit compromis des deux architectures présentées afin de limiter les problèmes liés à la connexion réseau tout en soulageant au minimisant la contribution de l’application client. Le principe de cette architecture réside sur le fait que lorsque des problèmes de connexion réseau surviennent dans un milieu urbain, ils ne durent rarement plus de quelques minutes. Cette architecture va donc tirer profit des créneaux durant lesquels la connexion avec le serveur est stable pour se préparer aux potentiels problèmes de connexion. L’intérêt est de pouvoir lancer un recalcul d’itinéraire en local pour pallier aux erreurs d’itinéraires de l’utilisateur lors des "trous de connexion" mais de continuer à effectuer le calcul sur le serveur lorsque la connexion réseau le permet. Cette architecture va être présentée en détaillant ses étapes de fonctionnement illustrées par la Figure 43.

Lors du fonctionnement normal de l’architecture, c’est-à-dire quand la connexion est établie, le client ne joue le rôle que de terminal à ceci près qu’il récupère, en plus de l’itinéraire, un graphe autour de la position courante. Il s’occupe donc de la gestion du déclenchement du calcul (1), de la visualisation du chemin une fois l’itinéraire récupéré auprès du serveur (5) et met à jour si nécessaire le graphe qu’il a en local avec celui fourni par le serveur (6). Le serveur, quand à lui, récupère les données routières auprès d’OSM afin de construire le graphe de calcul (2) et (3), effectue le calcul (4), fourni au client l’itinéraire (5) et fournit si nécessaire un graphe autour de la position courante du mobile au client (6). (C’est-à-dire dans le cas où le centre du graphe déjà présent du coté client est trop éloigné de sa position courante.) Lors d’un "trou de connexion", c’est-à-dire quand la connexion client-serveur n’est plus effective, l’application regarde si le graphe contenu en local contient sa position courante auquel cas l’application effectue en local un calcul du PCC vers la position du graphe la plus proche du point de destination (2bis).


40

Figure 43 : Architecture permettant de limiter les problèmes de connexion réseau

2.5 Proposition d'un système "dynamique" de calcul du PCC

Dans le graphe, on ne modélise par les aléas tels que les accidents, les routes momentanément inaccessibles car fermées pour travaux par exemple. D'autres éléments liés à l'utilisation de l'algorithme dans un cadre urbain viennent aussi générer d'autres formes d'aléa. En effet, l'algorithme à concevoir a pour vocation à être intégré dans un système global fonctionnant sur téléphone portable. Et dans ce cadre, l'usager peut non seulement être amené à ne pas respecter le trajet calculé car cela est impossible à cause des aléas survenant dans le réseau routier, mais aussi car le téléphone communiquant par un dessin sur l'écran et oralement ne lui permet pas de comprendre les instructions données. On peut garder l'esprit les difficultés qu'il y a à lire sur son téléphone un simple mail alors que l'écran est éclairé par le soleil ou bien la difficulté par tenir une conversation dans le bruit de la rue.

Compte tenu des aléas liés à une utilisation urbaine, l'aspect dynamique est apparu comme très important. C'est la raison pour laquelle, le calcul du chemin se fait de manière dynamique afin de faciliter les recalculs cependant l’optimalité de la solution n’est plus garantit. Le principe réside dans le fait que l’on n’a pas besoin pour se diriger sur une route de l’ensemble de l’itinéraire mais seulement des quelques prochaines instructions. L’algorithme consiste donc à ne calculer qu’une partie de l’itinéraire (un rectangle d'environ 1km et demi est suffisant) afin de rendre le calcul plus rapide. Le calcul consiste, comme pour la technique de la limitation du graphe, à tracer une droite entre le point de départ et d’arrivée afin d’obtenir la direction que l’on doit suivre et donc d’établir un premier point de passage. Le calcul est alors réitéré dans deux cas, le cas où l’utilisateur s’éloigne du chemin pré-calculé et le cas où l’on est à une distance raisonnable de la fin du premier morceau d’itinéraire. La Figure 44 ci-dessous illustre deux itérations du calcul itératif pour établir un itinéraire. On constate sur ce graphe que le chemin initial calcul comprend les nœuds s, a, b, r. Le nouveau calcul s'effectue à partir du nœud r qui figure en noir sur la figure.


41

Figure 44 : Calculs itératifs

3. Réalisation du système de guidage orienté mobilité

Le système de guidage qui est proposé dans ce chapitre s’applique aux piétons dans un environnement mobile. Ce système repose sur l’architecture proposée dans la section 2.5. Pour créer une application basée sur cette architecture, il est nécessaire, dans un premier temps, de générer un graphe représentant le réseau routier dans lequel l’utilisateur se déplace. Ceci nécessite l’accès à un service de cartographie le plus récent et le plus complet possible. Après avoir présenté le choix fait pour ce service de cartographie, on présente la réalisation du web service et l’application mobile qui sont respectivement le serveur et le client de l’architecture utilisée. L’installation et le détail de fonctionnement sont donnés en annexe 2.

3.1 Etude sur les services de cartographie

Un service de cartographie est un sous-ensemble de la famille des SIG (Système d'information géographique) qui sont des systèmes d'information permettant de créer, d'organiser et de présenter des données géographiques (ex : plans et cartes). Il est constitué principalement de quatre éléments indispensables au système de guidage :

Un serveur de données routières qui fournit les données nécessaires pour la modélisation du réseau routier sous forme de graphe ;

Un serveur de tuiles permettant d’obtenir la représentation visuelle du réseau sur le client sous forme de tuiles ;

Des API de développement qui offrent la possibilité au client d’interagir avec le service de cartographie afin par exemple d’afficher des repères visuels sur la carte ou la possibilité d’obtenir une localisation géographique à partir d’une adresse postale.

La plupart des services de cartographie ne proposent l’accès gratuit de façon limitée ou non qu’à certains de ces éléments. Le Tableau 3 dessous présente les services de cartographie les plus complets existants ainsi que le degré de disponibilité de leurs ressources :


42

Tableau 3 : Comparaison des différents systèmes de cartographies

Nom Serveur de données

Serveur de tuiles

API de développement

Google Maps Non-disponible Accès limité Accès limité ArcGIS Payant Payant Payant

Bing Maps Non-disponible Accès limité Accès limité Mapquest Non-disponible disponible disponible

Via Michelin Non-disponible Accès limité Accès limité OpenStreetMap disponible disponible Non-disponible

3.2 Analyse des besoins du système liés au service de cartographie

Dans cette section, on présente les choix faits sur les différents systèmes de cartographie selon les besoins :

Constitution du graphe modélisant le réseau routier

Pour récupérer les données routières et ainsi constituer le graphe, il a été choisi OpenStreetMap (OSM) car c’est un système de cartographie très complet et dont les données routières sont fournies de façon "open-source". OSM propose une API pour développeur qui permet d’importer des données du réseau routier au format XML par une simple requête de type GET envoyée au web-service REST du serveur de données d’OSM afin de définir la zone de la carte demandée. Ceci permet de récupérer une partie de la carte nécessaire à la constitution du graphe.

Acquisition de la position des points de départ et d’arrivée

La position de départ de l’itinéraire est déterminée directement par l’utilisation des outils de géolocalisation de l’appareil mobile. Une fois la position GPS de l’utilisateur connue, il suffit de projeter cette position sur l’arc du graphe le plus proche afin d’obtenir la position de départ. Cette étape de l’algorithme est détaillée dans section 4.3 de ce chapitre.

Pour déterminer la position d’arrivée, l’utilisateur doit saisir une adresse postale. Une fois cette adresse récupérée, il faut la géolocaliser. Ceci peut se faire par l’API de géolocalisation proposée par MapQuest. Une fois la position GPS connue, une projection sur l’arc du graphe le plus proche s’effectue de la même façon que pour la position de départ.

Visualisation de la carte

Afin que l’utilisateur puisse visualiser l’itinéraire calculé, il est nécessaire une cartographie sous format image pour pouvoir projeter le chemin obtenu dessus. Une tuile est une portion de la carte sous format image pour un zoom donné. L’affichage d’une carte sur un mobile est constitué par exemple d’environ quatre tuiles comme illustré sur la Figure 45. Ces quatre tuiles changent bien sûr en permanence en fonction du zoom et du défilement effectués sur la carte. De nombreux systèmes de cartographie laissent un accès libre ou peu restreint à leur serveur de tuiles dont OSM et MapQuest. Ces deux serveurs sont particulièrement intéressants car ils ont une parfaite correspondance entre les tuiles de leur serveur et les données routières d’OSM. Le choix d’utiliser MapQuest a été fait car il fournit de API d’utilisation de tuiles issues de différents services de cartographie. Ces API facilitent la gestion du zoom et du défilement de la carte par exemple.


43

(a) Carte sans tuile (b) Carte avec tuiles

Figure 45 : Illustration d’une carte constituée de tuiles

3.3 Réalisation du Web service

Le coté serveur du système basé sur l’architecture client-serveur, présentée précédemment par la Figure 43, est constitué d’un web-service défini par ses différentes fonctions.

Principe du web service

Un service web pourrait être défini comme un logiciel fonctionnant sur un serveur, fournissant un service et

l'exposant sous forme d’un ensemble de fonctions ou de méthodes. Pour chaque appel d’un client à une méthode

exposée, un service web doit accepter la demande, effectuer une exécution d'une ou plusieurs fonctions selon la

demande reçue et retourner un résultat.La description doit être formelle et explicite de manière à ce que le client

puisse facilement interagir avec le système. Le langage XML (eXtensible Mark-up Language), basé sur le

protocole internet, est utilisé pour établir cette description ce qui permet une grande interopérabilité entre

différents web services.

Analyse fonctionnelle

Pour que le système de guidage soit fonctionnel le coté serveur a besoin de communiquer avec le client et le serveur de données suivant le schéma Figure 46.


44

Utilisateur Web service Serveur de données

demarrer_Guidage

demande de données routières

données routières

testerEtatDemande

état du calcul

recupererResultatGuidage

itinéraire

recupererGraphe

demande de données routières

données routières

données du graphe

Calcul du plus court chemin

Figure 46 : Diagramme de séquence des fonctions du web service

Les méthodes associées au Web service développé ont deux fonctions principales : celle de fournir un itinéraire entre deux points donnés du réseau routier et celle de fournir les données d’un graphe autour d’une position donnée. Ces deux fonctions reposent sur le téléchargement de données routières et leur conversion en graphe. Chacun des appels à une de ces fonctions nécessite donc un certain temps de traitement et une certaine quantité de mémoire disponible. Ces méthodes sont implémentées de manière asynchrone ce qui permet le traitement simultané de plusieurs requêtes.

Le Web Service proposé fournit donc cinq méthodes :

demarrer_Guidage : Méthode qui envoie au serveur une requête de calcul à partir des coordonnées GPS du point de départ et d’arrivée fournies en argument accompagnées de la clef d’identification.

testerEtatDemande : Méthode qui permet de vérifier l’état de la demande de calcul fait au serveur à partir de la clef qu’on lui fournit en argument.

recupererResultatGuidage : Méthode qui permet de récupérer, toujours à partir de la clef, la liste des arcs de l’itinéraire à parcourir sous forme d’une chaîne de caractères une fois qu’il est disponible.

lireCodeRetour : Méthode qui prend en argument un nombre et renvoie la signification du code erreur qui lui est associé sous forme d’une chaîne de caractères. recupererGraphe : Méthode qui permet de récupérer toutes les informations sur les arcs et les

nœuds d’un graphe dans un rayon donné autour d’une position donnée.

Contrôle d’accès :

Afin de d'identifier les utilisateurs un système de gestion de clefs a été mis en place dans lequel chaque utilisateur possède une clef qui lui est propre et qui sera communiquée au serveur à chaque


45

fois qu’il fait appel au Web service. L’utilisation de ce système permet de limiter chaque utilisateur à une connexion au serveur d’une part, et de limiter le nombre de connexion journalière de chaque utilisateur d’autre part ceci afin de limiter les utilisations abusives.

L’utilisation du Web service est donc restreint par l’utilisation d’une clef qui est fournie de manière automatique lors de l’utilisation de l’application Android en fonction de l’identifiant unique du mobile, ou qui peut aussi être fournie par un courrier électronique en remplissant un formulaire (http://fc.isima.fr/~lacomme/identification/).

Implémentation

Le Web service est développé sous Java dans l’environnement de développement de NetBeans

est hébergé sur un serveur d'applications GlassFish (Figure 47). Ce serveur d’application est hébergé sur deux serveurs de l’ISIMA afin de palier à l’arrêt d’un des serveurs (http://orws.isima.fr:8080/ et http://orws2.isima.fr/).

Figure 47 : Environnement de développement du Web service

Utilisation du web service

Il peut être utilisé de trois façons. Soit directement à l’aide d’un explorateur internet, soit par l’utilisation d’un socket par le biais du langage de programmation choisi, soit en utilisant un environnement de développement qui gère la communication avec le Web service à partir de l’adresse du WSDL du web service.

a) Avec un explorateur internet :

Lors du déploiement d’un web service (SOAP) sur un serveur d’application, ce dernier va créer de façon automatique une page de test permettant d’utiliser les différentes fonctions avec un navigateur internet. Afin d’accéder à cette page, il suffit de rentrer l’adresse du web service suivi du paramètre « tester » comme illustrer sur l’exemple ci-dessous : http://orws2.isima.fr/Recuperation_donnee/Recuperation_donnee?tester

Une page test se présente alors sous la forme illustrée Figure 48 :

http://fc.isima.fr/~lacomme/identification/

http://orws.isima.fr:8080/

http://orws2.isima.fr/

http://orws2.isima.fr/Recuperation_donnee/Recuperation_donnee?tester


46

Figure 48 : Utilisation du Web service avec un explorateur internet

b) Avec un Socket :

Pour accéder au Web service, on peut aussi utiliser un socket afin de faire communiquer l’application avec le Web service. Il suffit de construire une enveloppe SOAP avec tous les paramètres nécessaires à la méthode demandée afin d’envoyer au Web service une requête POST constituée de cette enveloppe. C’est la méthode choisie pour faire communiquer l’application Android avec le Web service, elle est détaillée et expliquée dans l’annexe.

c) Dans un environnement de développement:

A partir de l’adresse du web service, un environnement de développement, tel que NetBeans par exemple, est capable de récupérer toutes les informations nécessaires à l’utilisation des méthodes proposées. C’est-à-dire qu’il génère de façon automatique le code qui s’occupera de toute la partie communication avec le Web service. Les méthodes du Web service pourront alors être utilisées dans le code du client comme des fonctions importées à partir d’une librairie.

3.4 Réalisation d'un client Android

L’application mobile est conçue pour fournir un itinéraire depuis la position courante vers une destination choisie en milieu urbain. Elle est constituée principalement de trois couches illustrée par la Figure 49 :

Une couche de communication permettant de dialoguer avec le web service

Une couche métier traitant les informations issues du web service

Une couche affichage constituant l’interface avec l’utilisateur


47

Figure 49 : Environnement de développement de l’application cliente

Analyse fonctionnelle

a) Multithread

La principale préoccupation lors de la conception d’une application Android est d'obtenir un fonctionnement correct mais aussi une fluidité d’utilisation satisfaisante. C’est pourquoi chaque action coûteuse en temps se fait en tâche de fond de l’application afin que l’utilisateur puisse continuer de naviguer sur la carte et dans le menu (application multithread).

b) Graphe en local

Comme il l’a été présenté dans la section 2.4, l’application stocke un graphe en local dès qu’elle en a l’occasion comme sécurité en cas de dégradation du réseau afin de continuer le guidage. Pour éviter tout conflit dans la constitution de l’itinéraire ou pour l’accès au graphe en local, l’application n’autorise qu’un seul calcul ou téléchargement de graphe en parallèle. Pour effectuer le calcul, un test de connexion réseau est effectué. Si le réseau n’est pas disponible, l’application fait le calcul en local (dans la mesure où le centre du graphe en local est suffisamment proche de la position courante pour que le calcul ait un sens). Le déclenchement du calcul se fait de deux façons : 1) soit lorsque l’utilisateur en fait la demande par l’interface; 2) soit de façon automatique lorsque l’application décide que l’itinéraire nécessite d’être recalculé compte tenu de la position GPS du mobile.

c) Guidage

Dans le cas d’un déclenchement par l’utilisateur, l’application fournit des indications sonores et visuelles sur l'avancement du calcul. Ensuite, lors du parcours de l’itinéraire, l’application calcule l’angle entre l’arc sur lequel se trouve l’utilisateur et le prochain arc du chemin ainsi que la distance restante jusqu’à l’intersection des deux arcs afin d’indiquer à l’utilisateur quelle direction il doit emprunter (gauche, droite ou tout droit et dans combien de mètres).

d) Géocodage d’une adresse postale

Afin d’obtenir les coordonnées GPS de destination, on récupère l’adresse postale auprès de l’utilisateur par une interface de saisie. L’adresse postale est ensuite géolocalisée à l’aide d’une API d’un service de cartographie.

Conception de l’interface :

L’interface de l’application se compose d’une carte sur laquelle l’utilisateur peut se déplacer et zoomer, d’un bouton permettant de quitter l’application pour éviter qu’elle continue de s’exécuter en tache de fond et d’un menu déroulant permettant d’accéder aux différentes fonctions de l’application. L’architecture de l’interface est présentée Figure 50 dans laquelle plutôt que d’utiliser les composants natifs du langage de développement (java), on choisit, par soucis d’esthétique, d’incorporer une interface en html. Par conséquent l’interface, vue de l’environnement de développement, n’est constituée que d’un composant WebView :


48

a) Squelette de l’interface b) Interface en HTML

Figure 50 : Interface de l’application

Détaillons ci-dessous les différentes fonctionnalités de l’application qui sont disponibles à partir du

menu :

Ma position : Permet de centrer la carte sur la position GPS actuelle.

Destination : Permet de saisir l’adresse postale de la destination dans une nouvelle fenêtre.

Guider : Permet de lancer le calcul d’itinéraire une fois que la destination souhaitée a été rentrée puis d’afficher l’itinéraire obtenu sur la carte.

La langue : Permet de passer l’application en anglais ou en français. (la langue par défaut correspond à la langue du téléphone.)

A propos de : Fournit quelques informations sur la conception de l’application.

Implémentation

L’application cliente a été développée pour Android sous java dans l’environnement Eclipse. Elle communique avec le serveur de Web services par le protocole SOAP. L’interface de la page principale de l’application, quant à elle, a été programmée en javascript et html afin, d’une part, d’optimiser sa compatibilité avec les api de visualisation de carte de MapQuest, et d’autre part, de simplifier l’agencement et l’élaboration des éléments graphiques qui peuvent être complexe en programmation Android (Ce n’est pas le cas pour la page de saisie d’adresse et de la page à propos de).

4. Analyse des résultats

Comme on a pu le voir dans la seconde partie de ce chapitre, l’algorithme développé est destiné à être utilisé par des utilisateurs en prenant en compte les aléas connus du cheminement de piétons en milieu urbain, c’est-à-dire que l’itinéraire initial est souvent remis en cause par les déplacements de l’utilisateur.

Cette partie est donc consacrée à l'analyse du système en modélisant les non-respects des directives envoyées à l’utilisateur par une certaine probabilité d'erreur au niveau des nœuds du graphe.


49

4.1 Présentation des données

Pour évaluer le fonctionnement du système dans un cas concret, les données routières d’une zone géographique d’environ 5 kilomètres de côté ont été récupérées, comprenant la majeure partie de Clermont-Ferrand et de ses banlieues sud (Chamalières, Beaumont, et Aubière) (Figure 51).

Figure 51 : Réseau routier de Clermont-Ferrand et ces banlieues

On obtient alors un graphe de 1502 sommets et 4400 arcs (Figure 52).

Figure 52 : Graphe représentant le réseau routier de Clermont-Ferrand et ses banlieues


50

A partir de ce graphe, plusieurs couples (points de départ, point d’arrivée) ont été sélectionnés aléatoirement de telle façon que leur distance, calculée à partir d’une méthode de plus court chemin sur le graphe, soit supérieure à 800m. Le cas des chemins de longueur trop petite est en effet peu intéressant car l’algorithme itératif effectue le calcul de PCC jusqu’au point de destination en une seule itération (dans le cas où l’utilisateur ne se perd pas).

4.2 Analyse des résultats : cas idéal

Pour chaque instance, on a commencé par établir le plus court chemin par un algorithme de Dijkstra et puis nous avons calculé l’itinéraire dynamiquement en supposant que l'usager ne se perdait pas pendant le trajet.

Les résultats obtenus sont présenté sur le Tableau 4. La première colonne représente les numéros des différentes instances. Les colonnes 2 et 3 représentent les latitudes et longitudes respectivement du point de départ et d’arrivée du trajet à effectuer. La colonne 4 représente le coût optimal ℎ* du chemin en mètres obtenu par la résolution d’une méthode exacte (Dijkstra avec tas). La colonne 5 représente le coût en mètre de l’itinéraire obtenu par l’algorithme itératif développé lorsque l’utilisateur suit parfaitement l’itinéraire indiqué. La colonne 6 représente l’erreur relative en pourcentage du résultat de la colonne 5 par rapport à celui de la colonne 4. La colonne 7 représente le nombre d’itérations de l’algorithme nécessaires pour atteindre la destination.

On peut constater qu'en moyenne l’algorithme, de par son caractère dynamique, donne des chemins qui sont à 5.50% du chemin optimal.

Remarquons dans un premier temps que les itinéraires sélectionnés ont un coût optimal de l’ordre de 1 à 5 kilomètres et que la moyenne si situe autour de 2 kilomètres 500 soit un trajet d’environ une heure pour un piéton moyen en milieu urbain. L’algorithme itératif fournit un itinéraire en moyenne 5,62% plus long que celui obtenu par la méthode exacte ce qui représente sur ce trajet de 2km500 un allongement d’environ 140 mètre et donc 3min de marche sur un trajet d’une heure. Il peut donc être estimé, à priori, que dans une situation concrète il sera très peu contraignant pour un piéton d’effectuer le chemin donné par l’algorithme itératif plutôt que le chemin le plus optimal.

Il est cependant nécessaire de s’intéresser maintenant aux résultats de façon plus individuelle. On remarque alors que dans près de la moitié des instances (13 sur 27), la différence de longueur de chemin avec l’optimum est nulle ou inférieur à 1% et dans la moitié des instances restantes (7 sur 27) elle est supérieure à 10% atteignant jusqu’à 27%. Le pourcentage varie donc grandement selon les

N° instance Point d’origine Point d’arrivée N° instance Point d’origine Point d’arrivée

1 45,7581 3,1101 45,7780 3,0831 15 45,7645 3,1053 45,7812 3,0903

2 45,7792 3,1168 45,7580 3,0784 16 45,7728 3,0727 45,7662 3,0680

3 45,7848 3,1028 45,7746 3,0947 17 45,7805 3,1001 45,7763 3,0770

4 45,7890 3,0951 45,7704 3,1188 18 45,7592 3,0841 45,7777 3,0703

5 45,7780 3,1104 45,7884 3,0983 19 45,7620 3,1248 45,7612 3,0934

6 45,7751 3,0829 45,7710 3,0926 20 45,7691 3,1079 45,7879 3,0997

7 45,7701 3,0808 45,7801 3,1184 21 45,7773 3,0907 45,7877 3,0861

8 45,7821 3,0985 45,7636 3,1078 22 45,7764 3,0713 45,7664 3,0796

9 45,7705 3,0656 45,7651 3,0769 23 45,7725 3,0936 45,7668 3,1143

10 45,7819 3,1027 45,7647 3,0974 24 45,7613 3,0906 45,7867 3,0788

11 45,7590 3,1159 45,7856 3,0735 25 45,7682 3,0893 45,7654 3,0984

12 45,7789 3,0836 45,7823 3,1019 26 45,7654 3,0892 45,7654 3,0882

13 45,7890 3,1001 45,7707 3,0757 27 45,7659 3,1079 45,7804 3,0874

14 45,7683 3,1066 45,7816 3,1239


51

positions de départ et d’arrivée.

Pour mieux comprendre pourquoi certaines valeurs sont si élevées, on va examiner le cas des trois instances dont les résultats possèdent un l’écart à l’optimum important (les instances 2, 10 et 20). Comme le montre la Figure 53, le résultat de l’instance n°2 illustre parfaitement que dans certains cas particuliers serpenter autour de la ligne en direction de la destination peut avoir un effet négatif. En effet, le caractère itératif de l’algorithme tente à chaque itération de calculer un itinéraire le plus proche possible de la droite qui relie le point de départ (position actuelle) et le point final du trajet. Cela a pour effet d’empêcher l’algorithme d’établir un itinéraire passant par des points intermédiaires éloignés de cette droite et d’induire un « effet escalier ». Ici sur la Figure 53, vu que le nombre de liaisons entre la rue de la Pradelle et la rue de l’Oradou est très limité c’est un passage qu’il vaut mieux contourner comme l’illustre le détour par le nord fait par l’itinéraire optimal.

Tableau 4 : Instances et résultats de référence

N° instance Point d’origine Point d’arrivée ℎ* ℎ(0%) Gap % Itérations

1 45,7581 3,1101 45,7780 3,0831 3629,80 3812,60 5,04 14

2 45,7792 3,1168 45,7580 3,0784 4509,11 5613,92 24,50 22

3 45,7848 3,1028 45,7746 3,0947 1639,40 1639,40 0,00 4

4 45,7890 3,0951 45,7704 3,1188 4047,20 4496,63 11,10 11

5 45,7780 3,1104 45,7884 3,0983 1866,19 1882,40 0,87 6

6 45,7751 3,0829 45,7710 3,0926 1245,82 1289,56 3,51 5

7 45,7701 3,0808 45,7801 3,1184 3278,60 3388,53 3,35 20

8 45,7821 3,0985 45,7636 3,1078 2737,98 2737,98 0,00 7

9 45,7705 3,0656 45,7651 3,0769 1525,79 1699,48 11,38 6

10 45,7819 3,1027 45,7647 3,0974 2417,21 3079,71 27,41 8

11 45,7590 3,1159 45,7856 3,0735 5440,46 5659,44 4,03 20

12 45,7789 3,0836 45,7823 3,1019 1789,43 1943,73 8,62 8

13 45,7890 3,1001 45,7707 3,0757 3383,98 3741,73 10,57 14

14 45,7683 3,1066 45,7816 3,1239 2750,92 2770,76 0,72 8

15 45,7645 3,1053 45,7812 3,0903 2529,81 2529,81 0,00 7

16 45,7728 3,0727 45,7662 3,0680 1260,14 1260,14 0,00 3

17 45,7805 3,1001 45,7763 3,0770 2074,18 2137,08 3,03 12

18 45,7592 3,0841 45,7777 3,0703 2588,66 2588,66 0,00 8

19 45,7620 3,1248 45,7612 3,0934 3033,87 3094,42 2,00 12

20 45,7691 3,1079 45,7879 3,0997 3103,75 3703,95 19,34 7

21 45,7773 3,0907 45,7877 3,0861 1677,82 1682,47 0,28 4

22 45,7764 3,0713 45,7664 3,0796 1454,39 1454,39 0,00 5

23 45,7725 3,0936 45,7668 3,1143 2047,18 2373,95 15,96 9

24 45,7613 3,0906 45,7867 3,0788 3356,14 3356,14 0,00 10

25 45,7682 3,0893 45,7654 3,0984 1127,62 1127,62 0,00 5

26 45,7654 3,0892 45,7654 3,0882 884,33 884,33 0,00 1

27 45,7659 3,1079 45,7804 3,0874 2594,19 2594,19 0,00 13

moyenne 2518,30 2686,78 5,62 9,22


52

Figure 53 : Itinéraire associé à l’instance 2 effectué par un calcul itératif

Les résultats associés aux instances 10 et 20 dont les itinéraires sont illustrés respectivement Figure 54 et Figure 55, sont aussi assujetties au problème du faible nombre de liaisons entre la rue de la Pradelle et la rue de l’Oradou représenté par une bulle rouge sur les deux figures.


Ces deux cas se distinguent cependant de la précédente par le fait que le point d’arrivée et de départ sont de part et d’autres de la voie de chemin de fer. Les passages à niveau au-dessus de la voie de chemin de fer sont très espacés les uns des autres ; l’algorithme peut donc être amené à faire un détour important pour traverser la voie afin de rester dans l’axe de direction fixé par la destination plutôt que de la longer durant un certain temps comme l’optimum.


53


Ces trois cas permettent de montrer que l’algorithme est sensible aux zones de faible densité routière que cela soit dû à un passage à niveau ou à la faible communication de deux boulevards. Il faut noter que la traversée d’une ville par un fleuve ou une rivière engendre des situations similaires à celle d’un chemin de fer et qu’un allongement de 27% sur des trajets de cet ordre, soit le cas le plus pathologique rencontré, représente plus ou moins 15min de marche.

4.3 Analyse des résultats : cas avec aléas

Dans le but d'évaluer le comportement du système dans des conditions plus réalistes, on a simulé plusieurs scénarios concernant des utilisateurs ayant une probabilité de se perdre à chaque intersection de 1, 2, 5, et 10%. A chaque erreur, l’utilisateur parcourt un arc du réseau avant qu’un calcul soit relancé. On peut supposer raisonnablement que dans la majorité des cas, lorsqu’un utilisateur se perd à une intersection (donc un nœud), ce n’est pas en repartant par le même arc que celui qu’il a emprunté pour arriver sur l’intersection. De même, à une intersection de plusieurs voies, un utilisateur aura plus tendance à se perdre en prenant une voie proche de la direction de la destination plutôt qu’une voie qui lui est opposée. Ces deux remarques ont donc été prises en compte dans la simulation.

Lors de la modélisation des erreurs de cheminements dans le réseau routier, il a été considéré qu'un choix par le piéton d'une rue erronée dépendait de la rue par laquelle il arrivait au carrefour et que par exemple, la probabilité d'une erreur conduisant le piéton à faire demi-tour pouvait être considéré comme négligeable.

Les probabilités d'erreur au différents embranchements, ont été calculé en fonction de l’angle avec le vecteur pointant vers la destination, mesuré de 0 à 180 degrés, et sont affectées d’un poids de 1 à 11 suivant la formule suivante : 1 + ((180 − 𝑎𝑛𝑔𝑙𝑒)/180) ∗ 10) .

Pour chaque paramétrage, c’est-à-dire, pour chaque couple de points sélectionnés et pour chaque

probabilité de se perdre, 100 scénarios ont été effectués. Le Tableau 5 ci-dessous représente la

moyenne sur l’ensemble des couples sélectionnés et sur l’ensemble des scénarios joués des différentes

valeurs auxquelles on va s’intéresser.


54

Tableau 5 : Bilan des résultats

Coût GAP % Distance ajoutée Ecart type Itérations Erreurs

ℎ* 2518,30 - - - 1 -

ℎ(0%) 2686,78 5,62 - - 9,22 -

ℎ̅ (𝑥, 1%) 2704,57 6,32 17,79 58,87 9,39 0,24

ℎ̅ (𝑥, 2%) 2725,76 7,18 38,98 88,18 9,55 0,51

ℎ̅ (𝑥, 5%) 2783,59 9,49 96,81 139,47 10,12 1,26

ℎ̅ (𝑥, 10%) 2896,78 13,96 210,00 206,35 11,20 2,67

Les deux premières lignes sont les moyennes sur les 27 instances des données références relatives à l’itinéraire optimal ℎ* et à l’itinéraire obtenu de façon itérative sans erreur de l’utilisateur ℎ(0%). Les

quatre lignes suivantes sont des estimateurs ℎ̅ de la moyenne sur les 27 instances des données relatives aux cas où l’utilisateur s’égare à chaque intersection avec une probabilité de 1, 2, 5 et 10%. Ces estimateurs sont basés sur la moyenne empirique des données associées aux 100 scénarios effectués sur chacune instance et représentés par le vecteur d’évènements aléatoires x. La première colonne indique le coût moyen des itinéraires obtenus en mètres. La deuxième colonne indique le taux moyen d’erreurs en pourcentage par rapport à l’optimal. La troisième colonne indique la distance moyenne ajoutée en mètres par rapport au parcourt sans erreurs. La quatrième colonne indique l’écart type moyen en mètres des coûts d’itinéraires (pour chaque instance un écart type est calculé sur les 100 scénarios joués). La cinquième colonne indique le nombre moyen d’itérations de l’algorithme pour atteindre la destination. La sixième colonne indique le nombre moyen d’erreurs que le piéton a commises pour arriver à destination.

Dans un premier temps pour justifier ces choix de probabilité, entre 1 et 10% de chance de se perdre par intersection, il faut s’attarder sur la dernière colonne. On peut alors remarquer qu’avec la probabilité d’1%, le piéton fait en moyenne une erreur pour quatre trajets de 2km500 ce qui représente plus ou moins la probabilité qu’un utilisateur se voit bloquer l’accès à une rue dû à des travaux publics ou un accident par exemple. D’autre part avec une probabilité de 10%, le piéton fait pratiquement trois erreurs par trajet d’une heure, ce qui correspond à un piéton plutôt distrait. On a donc un éventail raisonnable de scénarios en choisissant les probabilités de s’égarer entre 1 et 10%. On rappelle que le but de cette analyse est d’établir certaines tendances du comportement de l’algorithme et donc cette partie sera l’objet de plusieurs approximations raisonnables.

Par un rapide calcul, on s’aperçoit que la distance ajoutée par rapport au parcours sans erreur et le nombre d’itérations nécessaires pour atteindre l’optimum sont proportionnelles au nombre d’erreurs faîte sur le parcours. Ceci est parfaitement logique étant donné qu’à chaque erreur d’itinéraire un recalcule est déclenché et le chemin est dans la quasi-totalité des cas allongé. Ce qui par contre plus intéressant est le coefficient de proportionnalité entre ces différentes grandeurs ; le nombre d’itérations ajoutées est d’environ trois pour quatre erreurs respectivement pour les quatre probabilités de 70,8%, 64,7%, 71,4%, 74,15%. Ce coefficient est dû à plusieurs causes. Premièrement le piéton a progressé une partie du chemin avant de se perdre, il est donc logique que le coefficient soit inversement proportionnel à la portion de l’itinéraire effectué avant de se perdre. En effet si le piéton parcourt à chaque fois une grande partie de l’itinéraire avant de se perdre et de déclencher un recalcule, le nombre d’itérations nécessaires ne sera que très peu augmenter alors que si l’utilisateur se perd dès la première intersection à chaque fois le nombre de recalcule sera approximativement le nombre d’erreurs survenues. Donc pour connaître la proportion entre le nombre d’itérations supplémentaires nécessaires et le nombre d’erreurs, il suffit de connaître la proportion moyenne du chemin parcourue avant chaque déclenchement d’erreur tout en prenant en compte le malus accordé par le parcours de l’arc sur lequel on s’égare ; on sait en effet qu’en moyenne on allonge le parcours effectué en n’empruntant pas l’arc désigné par l’algorithme du fait que la distance ajoutée est proportionnelle au nombre d’erreurs.

On peut estimer parcourir environ 27 intersections en moyenne sur des chemins de 2km500 étant


55

donné le taux d’erreurs pour la probabilité d’1% qui est bien inférieur à 1 (0,24) ; en effet la première intersection a 99% d’être atteinte sans erreur mais la 27ème n’aura que 76% de chance (0,9927), soit 24% de chance de s’être trompé au moins une fois que l’on approxime au fait qu’il y a 0.24 erreurs en moyenne par chemin. On précise bien que cette approximation n’est valable uniquement car on suppose la probabilité d’avoir plus d’une erreur par chemin négligeable. Il faut en moyenne un peu plus de 9 itérations pour parcourir ces 27 intersections, soit une moyenne d’environ trois intersections par itérations.

Pour une probabilité d’1%, sur trois intersections, on peut considérer les chances qu’une erreur intervienne est équiprobable à chaque intersection comme le montre Figure 56 où une erreur à la troisième intersection n’a que 2% de chance de moins de se produire qu’à la première. On peut donc estimer que l’erreur surviendra en moyenne au milieu du parcours. Et donc le fait que le ratio entre le nombre d’itérations ajoutées et le nombre d’erreurs survenues soit d’environ trois pour quatre (70,8%) est en majeur partie dû à l’éloignement causé par les arcs empruntés en cas d’erreurs.

Figure 56 : Arbre de probabilité sur trois intersections pour 1%

Pour une probabilité de 10% par contre, sur trois intersections, la différence entre la troisième et la première sont non-négligeable comme l’illustre la Figure 57. En effet le piéton a 19% de chance de moins de se perdre à la troisième intersection plutôt qu’à la première ; si une erreur survient il y a alors 36,9% que ce soit au niveau de la première intersection, 33,2% que ce soit au niveau de la deuxième 29,9% que ce soit au niveau de la troisième.

On voit bien cependant que le ratio de 74,15% est là encore en majeur partie dû à l’éloignement causé par les arcs empruntés en cas d’erreurs cependant il est normal de voir un pourcentage plus élevé dans le cas de 10% plutôt que dans le cas de 1%. Il faut alors noter que la valeur pour 2% (64,70%) devrait se trouver légèrement au-dessus de celle de 1% (70,8%) ce qui rend bien compte de l’incertitude des données malgré le fait que chacun de ces ratios se base sur plus de 2 700 calculs d’itinéraire (27*100).

Figure 57 : Arbre de probabilité sur trois intersections pour 10%

Pour conclure cette analyse, on s’intéresse au rapport de proportionnalité existant entre la distance moyenne ajoutée par itinéraire et le nombre d’erreurs moyen qui est de 75 mètres par erreur ce qui correspond à la longueur moyenne d’un arc ; ce qui veut dire qu’en moyenne le chemin issu d’un sommet sur lequel le piéton se perd est de même longueur que le chemin issu du sommet précédent comme l’illustre la Figure 58 et donc que l’angle formé par la direction de la destination et l’arc vers le point erroné est en moyenne inférieur à 90°, vu que le triangle moyen formé par le point destination et les deux sommets est isocèle. Ceci est surement dû au fait que le piéton favorise la direction de la destination pour se perdre et a pour effet direct que le piéton n’allonge que très peu l’itinéraire à chaque erreur.


56

Figure 58 : Allongement moyen d’un itinéraire par une erreur

Pour résumer cette analyse aura permis de mettre en évidence : les différents cas pathologiques pour lesquels l’algorithme itératif fourni un résultat éloigné de l’optimum, et d’autre part, les subtilités des relations entre les erreurs d’itinéraire et les différentes grandeurs caractéristiques de l’algorithme.

5. Conclusion

Ce chapitre a permis de se familiariser avec les algorithmes de plus court chemin ; une étude des algorithmes existants les plus utilisés a été faite et a conduit à l’élaboration d’un algorithme de type Dijkstra avec tas qui a été utilisé dans le dernier chapitre. Dans un second temps cet algorithme a été modifié afin d’être utilisé dans une architecture client-serveur permettant le guidage d’un piéton en milieu urbain. Cette architecture a eu deux principaux objectifs : celui de mieux comprendre les enjeux induits par le fait de travailler dans un milieu urbain et sur des graphes de grande taille, et celui d’élaborer un web service fonctionnel et une application Android. Le travail sur les tournées de véhicules qui a été effectué dans le chapitre suivant, utilise comme prétraitement, l’algorithme de plus court chemin qui a été proposé, afin d’obtenir un tableau des plus courts chemins dans un graphe.

6. Références

*Bel58+ R. E., Bellman, On a Routing Problem, Quart. Appl. Math., Vol. 16(1), pp. 87-90, 1958.

*Chr79+ N. Christofides, A. Mingozzi, P. Toth. The vehicle routing problem. In Combinatorial Optimization, John Wiley, vol. 11, pp. 315–338, 1979.

*Dij59+ E. W., Dijkstra, Note on Two Problems in Connexion with Graphs, Numerische Mathematik, vol. 1, pp. 269–271, 1959.

*Dor03+ D. Wagner and T. Willhalm. Geometric Speed-Up Techniques for Finding Shortest Paths in Large Sparse Graphs. Konstanzer Schriften in Mathematik und Informatik.ISSN 1430–3558. Nr. 183, Januar 2003.

*Dor05+ D. Wagner, T. Willhalm and C. Zaroliagis. Geometric Containers for Efficient Shortest-Path Computation. ACM Journal of Experimental Algorithmics, Vol. 10(1.3), pp. 1-30. 2005

*Dre69+ S. Dreyfus. An appraisal of some shortest-path algorithms. Operations Research, vol. 17(3), pp. 395–412, 1969.

*Gub10+ A. Gubichev, S. Bedathur, S. Seufert and G. Weikum. Fast and Accurate Estimation of


57

Shortest Paths in Large Graphs. CIKM’10, October 26–30, 2010, Toronto, Ontario, Canada.

*Guz89+ J, Guzolek and E. Koch Real-time route planning in road network. Proceedings of VINS, September 11–13, 1989. Toronto, Ontario, Canada, p. 165–9.

*Har68+ P. E. Hart, A Formal Basis for the Heuristic Determination of Minimum Cost Paths, IEEE Transactions on Systems Science and Cybernetics SSC4, vol. 4(2), pp. 100–107, 1968.

*Nil71+ J., Nilsson, Problem-solving methods in artificial intelligence. New York: McGraw-Hill; 1971.

*Pea84+ J., Pearl, Heuristics: intelligent search strategies for computer problem solving. Addison-Wesley Publishing Company; 1984.

*Ren12+ L. REN, Conception et évaluation d’outils décisionnels pour des systèmes réactifs d’aide à la mobilité, PhD thesis, Université Blaise Pascal, Clermont-Ferrand, 2012.

*War62+ S., Warshall Theorem on Boolean Matrices, J. ACM, vol. 9, pp. 11–12, 1962.

*Wil05+ T. Willhalm. Engineering Shortest Paths and Layout Algorithms for Large Graphs. Dissertation der Universität Fridericiana zu Karlsruhe (TH). 2005.

59

CHAPITRE 3

Etude du HVRP dans un contexte mobile

L’objectif de ce chapitre est de proposer une méthode de résolution des problèmes de tournée de véhicules de type HVRP (Heterogeonous Vehicle Routing Problem) dans un contexte mobile. Le HVRP est une extension du problème de VRP. La méthode proposée est originale car elle se base sur une métaheuristique qui exploite une approche de type Path relinking pour diversifier la recherche. L’originalité de l’approche vient aussi du fait que l’algorithme de Path Relinking est défini sur l’espace des tours géants et non sur l’espace des solutions.

La première partie de ce chapitre est consacrée à la présentation du problème et des différentes méthodes de résolution existantes. Ensuite le schéma général de la métaheuristique développée ainsi que ces différents éléments sont détaillés. Enfin les résultats de la métaheuristique sur les instances classiques de la littérature et sur des réseaux urbains sont exposés dans la dernière partie de ce chapitre.

1. Problème du type HVRP

1.1 Présentation du HVRP

Définition Le problème de type HVRP, initialement décrit par *Gol84+, est une variante du problème de VRP

et il appartient donc à la famille des problèmes NP-difficiles. Cette variante du problème de tournées de véhicules a été introduite afin de prendre en compte une flotte de véhicules hétérogènes c’est-à-dire ayant des coûts d’utilisation différents.

Un problème de HVRP, comme un problème de VRP, se compose d’un ensemble de clients qui ont chacun une demande. Les véhicules dont on dispose pour effectuer les tournées sont, contrairement au VRP, en nombre limité d’une part et de capacités de chargement et de coûts différents d’autre part. Le problème consiste toujours à trouver un ensemble de tournées respectant la capacité du véhicule qui est attribué à la tournée permettant de desservir tous les clients à coût minimal.

Modélisation sous forme de graphe

On peut modéliser une solution du problème de type HVRP par une liste de tournées présentée sous la forme d’un graphe comme illustré par la Figure 59 dans lequel le dépôt et les clients sont représentés chacun par un nœud et où un arc entre deux clients symbolise l’ordre de passage du véhicule et la distance qui les sépare. A chaque tournée est associé un coût fonction du véhicule utilisé et de la distance parcourue.

Chapitre 3 : Etude du HVRP dans un contexte mobile

60

Figure 59 : Solution d’un problème de HVRP


Pour établir une formulation du problème de HVRP, on peut reprendre celle de Fisher et Jaikumar en 1981 *Fis81+ du problème de VRP et adapter certaines contraintes afin de prendre en compte la flotte hétérogène de véhicules de la façon suivante :

Min ∶ z = ∑ CkukMk=1 ∑n

i=0 ∑ cijkn

j=0 xijk (1)


∑ diyik ≤ Qkn

i=1 , ∀ k ∈ (1, . . , M) (2)

∑ yik = 1M

k=1 , ∀ i ∈ (1, . . , n) (3)

∑ uk ≤ MMk=1 (4)

∑ xijk = yj

kni=1 , ∀ j ∈ (1, . . , n) , ∀ k ∈ (1, . . , M) (5)

∑ xijk = yi

knj=1 , ∀ i ∈ (1, . . , n) , ∀ k ∈ (1, . . , M) (6)

∑ xijk ≤ |S| − 1i,j∈ S , ∀ S ⊂ V; 2 ≤ |S| ≤ n − 2 , ∀ k ∈ (1, . . , M) (7)

xijk ≤ uk , ∀ i ∈ (1, . . , n) , ∀ j ∈ (1, . . , n) , ∀ k ∈ (1, . . , M) (8)

xijk ∈ *0,1+ , ∀ i, j ∈ V ; i ≠ j , ∀ k ∈ (1, . . , M) (9)

yik ∈ *0,1+ , ∀ i ∈ V , ∀ k ∈ (1, . . , M) (10)


61

uk ∈ *0,1+ , ∀ k ∈ (1, . . , M) (11)

où 𝑉 est l’ensemble des arcs du graphe complet constitué des clients et du dépôt.

𝑥𝑖𝑗𝑘 : indique si j est immédiatement visité après i dans la tournée k.

𝑦𝑖𝑘 : est égale à 1 si le véhicule k effectue le service chez le client i si non 0. L’indice i=0

correspond au dépôt.

𝑢𝑘 : est égale à 1 si le véhicule k est utilisé.

𝑐𝑖𝑗𝑘 : est le coût de l’arc (i,j) pour le véhicule k.

𝐶𝑘 : est le coût fixe associé à l’utilisation du véhicule k. 𝑑𝑖 : est la demande du client i. 𝑛 : est le nombre de clients. 𝑀 : est le nombre de véhicules.

𝑄𝑘 : est la capacité du véhicule k.

Dans ce problème, la contrainte 2 vérifie que la capacité de chargement de chaque véhicule est bien respectée. La contrainte 3 permet de vérifier que chaque client est desservi. La contrainte 4 permet de vérifier que l’on construit au plus M tournées. Les contraintes 5 et 6 assurent la cohérence entre la visite d’un client par un véhicule k et l’appartenance de ce client à la tournée k. La contrainte 7 a pour but d’éviter la formation de sous-tours au sein des tournées. La contrainte 8 assure que chaque véhicule qui assure la livraison auprès d’au moins un client est considéré comme utilisé.

1.2 Etude sur les méthodes de résolution existantes

Comme le souligne C. Prins dans son article *Pri09+, Les problèmes de tournée de véhicules avec une flotte hétérogène sont, contrairement aux problèmes de VRP, très peu présents dans la littérature depuis leur première apparition en 1984 dans un article de Golden et al. *Gol84+. Ces problèmes sont scindés en quatre catégories :

Les problèmes de type VFMP-F (Vehicle Feet Mix Problem with Fixed costs) où l’on a à notre disposition un certain nombre de types de véhicule caractérisés par une capacité et un coût fixe d’utilisation mais où le coût par unité de distance parcourue est commun. De plus le nombre de véhicules de chacun des types n’est pas limité.

Les problèmes de type VFMP-V (Vehicle Feet Mix Problem with Variable costs) où l’on a à notre disposition un certain nombre de types de véhicule caractérisés par une capacité et un coût par unité de distance parcourue mais où le coût fixe par camion est identique à tous les camions. De plus le nombre de véhicules de chacun des types n’est pas limité.

Les problèmes de type VFMP-FV (Vehicle Feet Mix Problem with Fixed and Variable costs) où l’on a à notre disposition un certain nombre de types de véhicule caractérisés par une capacité, un coût fixe d’utilisation et le coût par unité de distance parcourue. De plus le nombre de véhicules de chacun des types n’est pas limité.

Les problèmes de type HVRP auxquels on s’intéresse dans ce chapitre. Ce problème se différencie du VFMP-FV par le fait que le nombre de véhicules de chacun des types est limité.

L’article de Golden et al. *Gol84+ propose 20 instances du problème de VFMP-F : 12 instances de petites tailles (de moins de 30 clients) et 8 instances de grande taille (plus de 50 clients). Les 8 plus grandes instances ont ensuite été modifiées par Taillard *Tai99+ afin de fournir des instances de VFMP-V et de HVRP. Ces instances sont utilisées par la plupart des travaux publiés dans ces domaines comme instances de références. Parmi les résultats publiés sur ces instances certains articles traitent


62

de plus d’un type de problème avec la même méthode. Les principaux articles sur le sujet et se basent sur les instances de Golden et sont référencés dans l’article *Pri09+. Le Tableau 6 ci-dessous précise quels sont les instances utilisées dans chacun des cas.

Tableau 6: Méthodes publiées utilisant les instances de Golden et al. référencées par *Pri09+

Taillard a été le premier à s’intéresser à la résolution du HVRP dans son article de 1999 *Tai99+. Il utilise pour se faire une heuristique de résolution approchée basée sur le principe de la génération de colonne qui repose sur l’idée de relaxer le programme linéaire associé au problème en ne prenant en compte qu’une partie des variables puis en réinjectant progressivement les variables susceptibles de faire varier la solution obtenue.

Tarantilis a, quant à lui, développé un algorithme TA (Threshold Accepting) *Tar04+ qui autorise donc la recherche local à détériorer temporairement la solution avec un certain seuil d’acceptation afin de diversifier la recherche.

Li et al. dans leur article *Li07+ ont utilisé un algorithme de type record-to-record dont la recherche locale consiste à explorer l’espace(sans rechercher forcément une amélioration), au voisinage des solutions qui sont raisonnablement peu éloignées (en coût) de la meilleure solution trouvée.

A ces trois articles référencés dans le Tableau 6, il faut bien sûr ajouter celui de C. Prins *Pri09+ qui propose deux méthodes de résolutions du HVRP basées sur un algorithme génétique et une recherche locale intensive. Il faut également citer plusieurs articles qui ont été écrit après celui de C. Prins en 2009.

Pessoa et al. *Pes09+ en 2009 ont élaboré la première méthode de résolution exacte du HVRP pour des instances allant jusqu’à 75 clients basée sur un algorithme de BCP (Branch-Cut-and-Price) qui consiste à diviser le problème principale en sous-problèmes et à résoudre chacun des sous-problèmes susceptible de contenir la solution optimale par une méthode de génération de colonnes.

Baldacci et Mingozzi *Bal09+ en 2009 ont élaboré une seconde méthode de résolution exacte permettant de résoudre certaines instances allant jusqu’à 100 clients basée sur un algorithme de SP (Set Partitioning) utilisant des bornes fixées par une relaxation linéaire et lagrangienne du problème. Ces deux méthodes de résolution exactes sont cependant extrêmement lentes sur des problèmes de moyenne taille et ne sont pas adaptées à la résolution d’instances de grande taille.

C. Duhamel et al. *Duh10+ en 2010 ont développé une métaheuristique de type GRASP-ELS basé sur une procédure de split évoluée.

Enfin A. Subramanian et al. *Sub12+ en 2012 ont formulé le problème sous forme d’un problème de Set Partitioning qu’ils ont résolu par une méthode de recherche locale itérative (ILS).

2. Métaheuristique proposée basée sur un Path-Relinking

La métaheuristique proposée pour résoudre des problèmes de type HVRP est un algorithme


63

évolutionnaire qui utilise donc un ensemble de solutions afin de donner la meilleure solution possible. L’algorithme est décrit dans cette partie à travers son schéma général et l’explication détaillée des principales parties qui le composent.

De même que l’algorithme GRASP/ELS présenté dans le deuxième chapitre, cette méthode se base sur les tours géants comme représentation indirecte de la solution. Comme pour le VRP, la construction de la fonction de mapping (le Split) permettant de passer de l’espace de codage à l’espace des solutions autorise plusieurs tours géants à obtenir la même solution. Cependant, contrairement au cas du VRP, la fonction de mapping du HVRP peut donner plusieurs solutions. La fonction de mapping associée au HVRP est alors de type n-to-n illustré Figure 60. L’élaboration de cette fonction est décrite en détail dans la deuxième section de cette partie.


n-to-n mapping

Figure 60 : Fonction de mapping du HVRP

2.1 Schéma général de la méthode implémentée

La méthode proposée est constituée de deux phases principales illustrée sur la Figure 61 naviguant entre l’espace de codage et l’espace des solutions :

Ajout de nouvelles

solutions Intensification

Suppression

randomisé d’éléments

Diversification

Début de

la méthode

Fin de la

méthode après

n ittération

Figure 61 : Schéma général de la méthode

Une partie dite de diversification de la population qui consiste à générer de nouvelles solutions de façon aléatoire afin d’élargir le champ de recherche au maximum. Elle s’exécute en deux sous-étapes. D’une part, une partie des solutions de la population est supprimée de façon randomisée en fonction de leur qualité respective. D’autre part on procède à une injection de solution dans la population illustrée sur la Figure 62 qui consiste à construire par la méthode des plus proches


64

voisins un tour géant et lui appliquer une heuristique d’obtention de solutions décrite dans la section 3 de cette partie puis enfin à intégrer les solutions obtenues dans la populations.


Recherche

locale

Ajout des

solutions à la

population

Solutions

améliorées

Population des

solutions

1 5 3 4 2 6

Tour géant

généré

Méthode des plus

proches voisins

Split

Plusieurs

solutions

Figure 62 : Ajout de solutions (diversification)

Une partie dite d’intensification de la recherche illustrée sur la Figure 63 qui consiste en une recherche approfondi autour des solutions de la population. Pour se faire plusieurs solutions de la population sont retranscrites dans l’espace de codage afin de croiser leur tour géant associé par une méthode de Path-Relinking générant ainsi de nouveaux axes de recherche proches des solutions croisées et donc couvrant au maximum les solutions proches de très bonnes solutions déjà mises en évidence lors des précédentes recherches locales. Pour chaque tour géant généré l’algorithme de Split est appliqué et une recherche locale est alors effectuée sur les solutions trouvées. La population est ensuite mise-à-jour avec les meilleures solutions parmi celles déjà contenues dans la population et les nouvelles solutions issues des recherches locales.


65


Split

Recherche

locale

Ajout des

solutions à la

population

Solutions

améliorées

Plusieurs

solutions

Population des

solutions

Concatenation

Sélection de

deux

solutionsSolutions à

croiser

1 5 2 4 3 6

2 6 3 4 1 5

1 6 3 4 2 5

Ensemble de

tours géants

obtenus

1 5 3 4 2 6

2 6 1 4 3 5

Tours géants à

croiser

Path-Relinking

Figure 63 : Etape d’intensification

2.2 La méthode Split

Le principe du Split est de construire itérativement la façon optimale de découper un tour géant en tournées réalisées par les différents véhicules à notre disposition. Le principe de base du Split appliqué au problème de type HVRP reste très similaire à celui détaillé dans le cas du VRP dans le chapitre deux. On ne s’intéressera donc dans cette partie qu’aux particularités qu’on lui a apportées afin de rester efficace dans le cadre du HVRP. Afin de clarifier les explications, on va illustrer les modifications nécessaires au fonctionnement d’un algorithme pour le HVRP par rapport à celui implémenté pour le VRP à travers un exemple simple.

Présentation de l’exemple et premières modifications de l’algorithme :

L’exemple proposé est composé de 4 clients à desservir dont les demandes sont présentées dans le Tableau 7, et de 3 véhicules pour effectuer les tournées qui ont chacun une capacité et un coût différent présentés dans le Tableau 8. On note que choisir seulement un coût variable et non un coût fixe pour chaque véhicule est suffisant pour rendre l’exemple traité pertinent. On va de plus poser pour obtenir un exemple la plus clair possible que toutes les distances entre deux clients ou entre un client et le dépôt sont de 1 unité de distance.

Tableau 7 : Demandes des clients du tour géant de

l’exemple du Split

Clients du TG 1 2 3 4

Demandes 3 3 4 2

Tableau 8 : Liste des véhicules disponibles de

l’exemple du Split

Véhicules 1 2 3

Capacités 9 5 3

Coût par unité de distance 1 2 3


66

Pour que l’algorithme split soit applicable, il faut bien sûr que chacune des tournées soit identifiée non seulement par les clients qui la composent mais aussi par le véhicule qui l’effectue ce qui induit pour chaque tournée un choix de véhicule en fonction de sa capacité, de son coût et de sa disponibilité. Tous les véhicules disponibles et de capacité suffisante devront donc être testés pour chaque tournée. On se tiendra, dans un premier temps, à ses simples modifications de l’algorithme pour résoudre notre exemple afin de mettre en évidence la principale modification qui sera nécessaire à l’optimalité de la méthode.

Déroulement de l’algorithme :

Afin de présenter cet exemple de manière concise, on ne va détailler que les trois premières itérations de l’algorithme sous la forme d’un graphe de façon similaire à l’exemple traité pour le VRP.

Chaque arc représente donc une tournée. Sur chaque arc figure un couple de valeur correspondant respectivement au véhicule de la tournée et au coût de la tournée. A chaque nœud 𝑖 est associé le coût pour desservir les 𝑖 premiers clients du tour géant.

La première étape illustrée par la Figure 64, consiste à desservir le client 1. Les trois véhicules étant disponibles et de capacité suffisante, on compare donc pour chacun d’entre eux le coût nécessaire pour faire l’aller-retour entre le premier client et le dépôt. Le coût est minimal (2) en effectuant la tournée avec le véhicule 1.

Figure 64 : Première itération du Split pour HVRP

La deuxième étape illustrée par la Figure 65 consiste à établir les tournées comprenant le client 1 et 2. Seul le véhicule 1 est assez volumineux pour desservir les deux clients (de capacité 9 > 3 +3). Un coût de 3 est alors attribué au nœud 2 correspondant aux déplacements effectués : (dépôt;client 1) + (client 1;client 2) + (client 2;dépôt).

Figure 65 : Deuxième itération du Split pour HVRP

La troisième étape consiste à établir les tournées contenant les clients 1 2 et 3 cependant aucun des véhicules n’est assez volumineux pour desservir les trois clients. L’algorithme passe donc aux tournées commençant par le client 2.

On commence donc cette fois par évaluer les tournées comprenant uniquement le client 2 sachant que le véhicule 1 est donc assigné à la tournée constituée uniquement du client 1. Comme l’illustre la Figure 66 Les véhicules 2 et 3 sont éligibles à effectuer la tournée. Le véhicule 2 est celui des deux qui possède le coût le plus faible cependant le coût de cette tournée (4) ajouté à celle de la première tournée constituée du client 1 (2) et supérieure au coût de la tournée qui dessert le client 1 et 2 avec le véhicule 1. Aucune des tournées ne prenant uniquement le client 2 n’est donc prise en


67

compte.

Figure 66 : Troisième itération du Split pour HVRP

On continue de faire fonctionner l’algorithme ; aucun véhicule disponible ne peut contenir le client 2 et 3, l’algorithme passe donc aux tournées commençant par le client 3. Le véhicule 2 est choisi pour effectuer la tournée constituée uniquement du client 3. Aucun véhicule disponible ne peut desservir les clients 3 et 4 dans la même tournée. L’algorithme passe aux tournées commençant par le client 4 où l’on choisit le seul véhicule disponible, le 3, pour effectuer la tournée constituée du client 4. A la fin de l’algorithme on obtient donc la solution présentée Figure 67 constituée de trois tournées et de coût égal à 13.

Figure 67 : Fin du Split pour HVRP et solution associée

Solution optimale et analyse :

En analysant la solution obtenue, on se rend compte qu’en prenant le véhicule 2 pour effectuer une tournée constituée uniquement du client 1, on peut alors faire rentrer les trois autres clients dans le véhicule 1 et ainsi trouver une meilleure solution comme l’illustre la Figure 68 n’utilisant que deux des trois véhicules.


68

Figure 68 : Solution optimale de l’exemple d’HVRP

L’algorithme tel qu’il est n’est donc pas optimal. Il peut même ne trouver aucune solution alors que plusieurs existent comme on peut le remarquer en ajoutant un cinquième client de demande égale à 2 à notre exemple. Selon la figure 7, une solution existe du fait que le véhicule 3 n’est pas occupé et qu’il est de capacité suffisante. Cependant l’algorithme ne trouverait aucune solution. Ce problème vient du fait que les véhicules sont disponibles en quantité limitée. En effet, l’algorithme choisi à chaque itération le véhicule le moins couteux. Cependant, il n’est pas trivial qu’il soit plus judicieux d’utiliser les camions les moins couteux au début de l’algorithme comme l’illustre parfaitement l’exemple proposé.

La solution est donc, plutôt que de sauvegarder à chaque nœud uniquement la meilleure solution à priori, de sauvegarder toutes les solutions qui ont une chance de mener à la solution optimale pour le nœud final. Seules les solutions complètements dominées ne sont alors pas prises en compte ; par exemple, si deux solutions utilisent la même flotte de véhicules seule la moins coûteuse sera sauvegardée, de même si la plus coûteuse ne possède aucun véhicule libre non possédé par la moins coûteuse.

L’algorithme une fois effectué peut alors proposer plusieurs solutions sur le dernier label qui sont en partie ou toutes intéressantes à conserver pour l’étape de recherche locale étant donné que ces solutions n’utilisent pas la même composition de véhicules.

Optimisation en temps et en espace de l’algorithme :

Conserver autant de labels sur chaque nœud du graphe de l’algorithme peut rendre le split extrêmement coûteux en espace et en temps.

En effet, un coût total, un tableau indiquant le nombre de véhicules disponibles pour chacun des types, l’indice correspondant au premier client de la tournée et l’indice du label père. Cet espace nécessaire est à multiplier le nombre de labels de chacun des nœuds qui débute sur le premier nœud par le nombre de types de véhicule à disposition de capacité supérieur à la demande du premier client du TG puis augmente de façon exponentielle à chaque nœud sur lesquels une nouvelle tournée est initiée en fonction du nombre de types de véhicule alors disponibles. Un label arrête d’être propagé au nœud suivant et donc le nombre de labels diminue lorsque plus aucun des véhicules disponibles ne peut traiter la demande du client suivant.

D’autre part, comparer deux labels revient à comparer le nombre de véhicules disponibles pour chaque type de véhicule du problème et le coût total. Ce temps nécessaire à une comparaison est à prendre en compte à chaque fois qu’un nouveau label potentiel doit être comparé aux labels déjà présents pour un nœud traité.

Afin de réduire le coût en espace et en temps de l’algorithme du split, il est alors judicieux de réduire le nombre de comparaisons de labels et le nombre de labels par nœud au maximum sans pour autant perdre les solutions intéressantes. Pour se faire, un pré-calcul est effectué avant de démarrer le split afin d’associer à chaque nœud un coût minimal pour traiter les clients restants et de


69

ne comparer un label par rapport aux autres, durant l’algorithme, que s’il est suffisamment bon en lui ajoutant la valeur pré calculée (inférieur au coût de la meilleure solution connue auquel on ajoute un pourcentage d’incertitude). Cette borne inférieure du coût est calculée en supposant que l’on dispose en quantité non limité d’un véhicule dont la capacité est le maxima parmi celles présentes dans la flotte de véhicules et dont le coût fixe et le coût variable sont les minimas parmi ceux présents dans la flotte de véhicules. De plus la distance entre le dépôt et les clients n’est prise en compte pour ce coût minimal que lors du retour de la dernière tournée afin de s’assurer de bien être inférieur en tout cas à la valeur optimale à partir du nœud traité. L’algorithme ainsi optimisé est décrit dans l’algorithme 5 ci-dessous

Algorithme Split pour HVRP [Duh10] :

Données :

- n : nombre de clients

- t : nombre de types de véhicule

- 𝑞 : vecteur de taille n où pour tout i de 1 à n, 𝑞𝑖est la demande correspondante au client i.

- 𝑐 : matrice de taille (n+1,n+1) où pour tout i,j de 0 à n, 𝑐𝑖𝑗correspond à la

distance de i à j où l’indice 0 correspond au dépôt et l’indice k de 1 à n correspond au client k.

- 𝑊 : vecteur de taille n où pour tout i de 1 à t, 𝑊𝑖 est la capacité de chargement d’un véhicule de type i.

- 𝐿 : distance maximum d’une tournée.

- 𝐹 : vecteur de taille t où pour tout i de 1 à t, 𝐹𝑖 est le coût fixe d’un véhicule de type i.

- 𝑉 : vecteur de taille t où pour tout i de 1 à t, 𝑉𝑖 est le coût variable d’un véhicule de type i.

- Borne_inf : vecteur de taille n où pour tout i de 1 à n, 𝐵𝑜𝑟𝑛𝑒_ inf𝑖 𝑒𝑠𝑡 la valeur pré-calculée minimale pour finir de desservir les clients après le client i.

Variables :

- Label : vecteur de taille n où pour tout i de 1 à n, Labeli est la liste des labels associée au nœud i.

- charge : variable permettant de vérifier qu’une tournée respecte la capacité d’un véhicule.

- distance : variable permettant d’évaluer la distance de la tournée courante.

- coût : variable permettant d’évaluer le coût de la tournée courante en fonction d’un type de véhicule choisi.

- coût_variable : variable qui prend la valeur du coût variable minimum parmi ceux des différents véhicules durant la première étape de l’algorithme

- coût_fixe : variable qui prend la valeur du coût fixe minimum parmi ceux des différents véhicules durant la première étape de l’algorithme

- capacité : variable qui prend la valeur de la capacité maximum parmi celles des différents véhicules durant la première étape de l’algorithme

- nb_vehicule : variable temporaire utile dans la première partie de l’algorithme indiquant le nombre de véhicules nécessaire pour desservir les clients.

- temp, stop, trop, échec : variables temporaires.

- Label_temp : label temporaire.


70

Algorithme 5 : Split pour HVRP

Sortie : Label

Début

coût_variable = Min(𝑉𝑖) ; coût_fixe= Min(𝐹𝑖) ;capacité = Max(𝑊𝑖) ;

Pour i de 1 à n-1 faire

nb_vehicule= 1

Borne_inf[i] = 0

temp = 0

Pour j de i à n-1 faire

Borne_inf[i] = Borne_inf[i] + 𝑐𝑗,𝑗+1

temp= temp + 𝑞𝑖

Si temp > capacité alors

temp = 𝑞𝑖

nb_vehicule++

Fin si

Fin pour

Borne_inf[i] = Borne_inf[i] + 𝑐𝑛,0

Borne_inf[i] = Borne_inf[i] * coût_variable + coût_fixe * nb_vehicule Fin pour

Ajouter un label à 𝐿𝑎𝑏𝑒𝑙0 de coût 0

Pour i de 0 à n-1 faire

j = i + 1

stop=0

Tant que stop == 0 faire

Si i + 1 == j alors

distance = 𝑐0𝑗 + 𝑐𝑗0

charge = 𝑞𝑗

Sinon alors

distance = distance - 𝑐𝑗−1,0 + 𝑐𝑗−1,𝑗 + 𝑐𝑗,0

charge = charge + 𝑞𝑗

Fin si

échec = vrai

Pour chaque élément k de 𝐿𝑎𝑏𝑒𝑙𝑖 faire trop = faux

Pour l de t à 1 avec un pas de -1 faire

Si trop == vrai faire sortir de la boucle pour Fin si

Si 𝐿𝑎𝑏𝑒𝑙𝑖,𝑘 possède un véhicule l disponible faire

Si 𝑊𝑙> charge faire

échec = 0

coût = distance ∗ 𝑉𝑙 + 𝐹𝑙

coût total de Label_temp = coût total de 𝐿𝑎𝑏𝑒𝑙𝑖,𝑘 + coût

véhicules disponibles de Label_temp = véhicules

disponibles de 𝐿𝑎𝑏𝑒𝑙𝑖,𝑘

véhicules disponible de type l de Label_temp --

indice du label père de Label_temp = k

indice du nœud père de Label_temp = i

Si (coût total de Label_temp + Borne_inf _j) < (coût meilleure solution connue du problème * un coefficient

d’incertitude supérieur à 1) faire

insérer Label_temp dans la liste Label_j

Sinon faire trop = vrai Fin si

Fin si

Fin pour

Fin pour

j ++

Si j > n ou échec == 1 faire stop = 1 Fin si

Fin tant que

Fin pour

Fin


71

2.3 Heuristique de génération de solutions

Dans le cas de problèmes, pour lesquels la capacité totale des véhicules de la flotte est proche de la demande totale des clients, un tour géant obtenu à la suite de l’exécution d’une méthode de plus proches voisins ne permet pas toujours de trouver une solution en n’utilisant que l’algorithme du split. Or, contrairement aux instances traitées dans le cadre du VRP, les instances utilisées par les articles référents sur le HVRP (instances de *Gol84+) possèdent des capacités totales proches des demandes totales des clients.

L’heuristique proposée pour remédier à ce problème repose sur un principe simple : lorsque l’algorithme split ne parvient pas à trouver un découpage, cela vient du fait qu’arriver à un certain nœud l’algorithme ne possède plus de véhicule capable de contenir le client suivant. L’idée est alors de déplacer ce client à une position plus en amont du tour géant jusqu’à ce que le split aboutisse à une solution. Il s'agit d'une technique de "réparation" qui va modifier le tour géant.

Pour expliquer le fonctionnement de cette heuristique de façon simple, on a considère l’exemple de la Figure 69 constitué de 4 clients à desservir et de 2 véhicules de types différents pour effectuer les tournées. Aucun coût n’est pris en compte dans cet exemple car le but de l’algorithme et de trouver des solutions et non de chercher les meilleurs possibles.

Tableau 9 : Demandes des clients de l’exemple de

génération de solutions


Demandes 2 5 1 2

Tableau 10 : Liste des véhicules disponibles de

l’exemple de génération de solutions

Véhicules 1 2

Capacités 4 6

Figure 69 : Données de l’exemple illustrant l’algorithme de génération de solutions pour HVRP

On illustre sur la Figure 70 les deux possibilités de faire évoluer le Split ; c’est-à-dire, en débutant par le véhicule 1 ou par le véhicule 2. On remarque qu’aucune des deux possibilités ne permet de desservir la totalité des clients. En effet, on a deux possibilités pour desservir le client 1 en choisissant (le véhicule 1 ou 2). Ensuite aucun des deux véhicules ne peut prendre en charge la capacité des clients 1 et 2 dans la même tournée. En partant du label où le client 1 est desservi par le véhicule 1, le véhicule 2 reste disponible et peut effectuer la livraison du client 2. Le véhicule 2 peut prendre en charge le client 2 et 3 dans la même tournée ce qui le remplira complètement et donc ce nouveau label associé au nœud 3 ne se propagera pas. D’autre part, en partant du label où le client 1 est desservi par le véhicule 2, seul le véhicule 1 est disponible mais il ne dispose pas de la capacité suffisante pour contenir la demande du client 2 l’algorithme s’arrête donc complètement avec deux labels sur le nœud 1, un label sur le nœud 2 et un label sur le nœud 3.


72

Possibilité 1

Véhicule 1 :

1

1 2 3 4

2 5 1 2

Client

Demande

Volume 2/4

Véhicule 2 :

2

Volume 6/6

3

Possibilité 2

Véhicule 2 :

1

Volume 2/6

Véhicule 1 :

Volume 4/4

Figure 70 : Déroulement de l’algorithme split sur le tour géant initial

Etant donné qu’aucune solution n’est trouvée, l’heuristique se met en marche afin de modifier le TG jusqu’à ce qu’une solution soit mise en évidence.

L’indice du client associé au dernier label est donc 3 ; l’algorithme va donc commencer par essayer de déplacer le client 4 jusqu’à ce l’algorithme du split engendre une solution. La première

itération illustrée par la Figure 71 consiste à échanger la position des clients 3 et 4 et à réitérer l’algorithme du split sur le TG obtenu.


Demandes 2 5 2 1

Figure 71 : Première itération de l’algorithme de génération de solution pour HVRP

Le split de ce TG donne deux labels sur le nœud 1 et un label sur le nœud 2 mais ne donne aucune solution c’est-à-dire aucun label sur le dernier nœud. L’algorithme poursuit donc échangeant,

à partir du tour géant de départ, le client 4 avec le client 2 comme l’illustre la Figure 72.


Demandes 2 2 1 5

Figure 72 : Deuxième itération de l’algorithme de génération de solution pour HVRP

Le split de ce tour géant aboutit avec une unique solution qui consiste à effectuer une tournée avec le véhicule 1 comprenant les deux premiers clients (1 et 4) et une tournée avec le véhicule 2 comprenant les deux derniers clients (3 et 2). L’algorithme s’arrête donc à cette étape avec une seule solution pour résultante illustrée sur la Figure 73.

Véhicule 1 :

1

Volume 4/4

Véhicule 2 :

3

Volume 6/6

24

Figure 73 : Solution de l’heuristique de génération de solutions

Le but étant de garder une solution initiale raisonnablement bonne, c’est-à-dire proche de celle issue par la méthode des plus proches voisins, cet algorithme n’effectue qu’un seul échange de


73

position au maximum dans le tour géant initial. Dans le cas où l’algorithme ne débouche sur aucune solution un nouveau tour géant est généré par la méthode des plus proches voisins et on réitère l’algorithme jusqu’à trouver une solution.

2.4 Proposition d'une méthode de type Path-Relinking

L’idée du Path-Relinking est similaire à celui d’un algorithme génétique : elle se base sur le fait que lorsque deux solutions que l’on sait bonnes sont connues, il est peut être intéressants d’explorer les solutions qui sont "entre" les deux solutions. Cela signifie qu'il faut disposer d'une notion de distance afin de définir la notion de "entre" de manière formelle. Avec une notion de distance, on peut donner un sens à une phrase du type "une solution est à égale distance de la solution S1 et de la solution S2" ce qui veut aussi dire qu'il faut disposer d'un opérateur permettant de "parcourir" la distance entre les deux solutions.

Le fonctionnement d'un algorithme de type Path Relinking consiste à évaluer un nombre de transformations nécessaires pour passer de l’une des deux solutions à l’autre (une distance) et de générer une nouvelle solution lors de chacune de ces transformations. Chacune de ces transformations doit être suffisamment significative pour intégrer à la solution générée une nouvelle propriété issue de la solution cible. Cette idée du Path-Relinking a été pour la première fois proposée par F. Glover en 1996 *Glo96+ pour améliorer les heuristiques basées sur une recherche taboue. Il choisit comme transformations pour passer d’une solution à une autre par la méthode de Path-Relinking des mouvements de type « 1-moves » (mouvements de type 2-opt par exemple). *Li10+ a proposé en 2010 le premier algorithme basé sur la méthode de Path-Relinking pour résoudre des problèmes de type HVRP. Son algorithme comme celui de F. Glover effectue chacun des pas pour transformer une solution en une autre solution cible par des mouvements de type « 1-moves ».

Tel que l’algorithme de ce chapitre est construit, chacune des solutions de la population étudiée est un minimum local du problème de HVRP. L’idée originale de l’algorithme développé dans ce chapitre est alors, plutôt que de parcourir le chemin entre deux solutions de la population tel que le ferrait une méthode de Path-Relinking classique, de parcourir le chemin séparant les deux tours géants représentant respectivement ces deux solutions dans l’espace de codage indirect. Chaque tour géant de transition ainsi généré sera soumis à la méthode split pour donner zéro, une ou plusieurs solutions.

Pour travailler dans l’espace de codage, la première étape est d’établir une notion de distance entre deux tours géants afin d’évaluer le nombre de tours géants constituant le chemin qui les sépare.

Elaboration de la distance

Il existe deux principaux types de mesures utilisées pour estimer cette relation: les mesures de distance et de mesures de similarité. En problème d'ordonnancement de nombreuses mesures de distances ont été étudiées comme l'a souligné *Sev07+. Dernièrement, en 2005, *Zha05+ propose un algorithme efficace (Algorithme 6) pour calculer la distance donnant le nombre minimal de permutations nécessaires pour transformer une séquence B d'éléments dans la séquence B '. Cette distance suppose que la liste des éléments utilisés dans les deux séquences est identique. C’est cette distance qui est utilisé pour les tours géants dans le Path-Relinking, elle est notée MPD (Minimal Permutation Distance).


74

Algorithme de la distance de Zhang [Zha05]

Données :

- 𝐵 : vecteur d’éléments

- 𝐵’ : vecteur d’éléments

Variables :

- 𝑉 : vecteur de booléens

- 𝐿𝑂𝐶 : vecteur tel que 𝐿𝑂𝐶,𝑖- donne la position de 𝑖 dans 𝐵

Algorithme 6 : Distance de Zhang

Sortie : P

Début

V=[Faux, Faux, …, Faux]

m=0

Pour I de 0 à n faire

LOC[B[i]] = i

Fin pour

Pour I de 0 à n faire

Si V[i] == Faux faire

m++

i_tps = i

V[i_tps] = Vrai

First = B[i]

Tant que (B’[i_tps] != First) faire

i_tps = LOC[i_tps]

V[i_tps] = Vrai

Fin tant que

Fin si

Fin pour

Fin

On va illustrer le fonctionnement de cet algorithme à partir de l’exemple donné dans le Tableau 11 :

Tableau 11 : Donnée de l’exemple de calcul de distance de Zhang

B 3 4 1 2 5 6 7

B’ 4 3 5 2 6 1 7

L’algorithme consiste à cherche dans le vecteur B le premier élément non-traité. La Figure 74

illustre la première étape dans laquelle l’élément 3 de B en position 1 est traité. La valeur de B’ en position est 4 et on a 𝐿𝑂𝐶*4+ qui vaut 2 donc la première permutation enregistrée est l’échange des positions 1 et 2.


75

7652143

7162534

B

B’

7652143

FFFFFTT

LOC

V

Figure 74 : Première étape de l’algorithme de Zhang *Zha05+

Vu que l’on a échangé les positions 1 et 2 la boucle tant que s’arrête et la boucle pour se déroule. Comme l’illustre Figure 75, la deuxième itération prend en compte la valeur 1 en position 3 de B. La valeur 5 associée à la position 3 de B’ est en position 5 de B. La valeur 6 associée à la position 5 de B’ est en position 6 de B. Enfin la position 6 de B’ correspond à la valeur 1 ce qui termine la boucle tant que.

7652143

7162534

B

B’

7652143

FTTFTTT

LOC

V

Figure 75 : Deuxième étape de l’algorithme de Zhang *Zha05+

Les deux derniers éléments non traités ont des places correspondantes dans le vecteur B et le vecteur B’ donc l’algorithme se finit donc comme illustré sur la Figure 76 :

7652143

7162534

B

B’

FTTTTTTV

7652143

7162534

B

B’

TTTTTTTV

Figure 76 : Dernière étape de l’algorithme de Zhang *Zha05+

Sur cette même Figure 76, à la fin de l’algorithme, on peut apprécier le nombre de permutations pour passer de B à B’ qui est 3 ; les permutations associées sont (1;2), (3;5), (5;6).


76

Principe général du Path-Relinking proposé

Le Path-Relinking repose alors sur un schéma très simple illustré sur la Figure 77 où ; à chaque permutation listée par l’algorithme de Zhang on génère un tour géant afin d’intensifier la recherche en explorant un maximum de solutions dans le voisinage des solutions de la population durant la suite de l’algorithme général.

Algorithme de Zhang

Calcule de la distance

de ZhangGénération des tours

géants

Etablissement de la liste

des permutations

Deux tours

géants issus de

solutions de la

population

Figure 77 : Principe du Path-Relinking

En reprenant, l’exemple du Tableau 11, les tours géants générés par le Path-Relinking à partir de B et B’ sont donc au nombre de 2 ; il y a 3 permutations et la dernière aboutit sur le vecteur B’ comme le montre la Figure 78 :

7652143

7162534

7652134

7612534

B

B’

Tour géant 1

Tour géant 2

Figure 78 : Tours géants générés par l’algorithme du Path-Relinking

2.5 La recherche locale

Une recherche locale intensive est appliquée à chaque nouvelle solution générée par les différents Split au cours de l’algorithme. Et de ce fait, elle constitue la majeure partie du temps d’exécution de l’intégralité de l’algorithme. Elle s’organise autour de l’utilisation randomisée de quatre mouvements différents comme l’illustre l’algorithme 7 ci-dessous.


77

Algorithme 7 : Recherche locale pour HVRP

Entrée : Solution à améliorer

Sortie : Solution améliorée

Début

coût_initial = +∞

coût_trouvé = coût de la solution à amélioré

nb_itération = 1

Tant que (coût_initial - coût_trouvé > amélioration_minimale ou

nb_itération < nb_itération_max) faire

coût_initial = coût_trouvé

Pour chaque tournée de la solution faire

Recherche locale de type 2_opt intra-tournée

Fin pour

Affecter un ordre de façon randomisée aux tournées

Pour i de 1 au nombre de tournées faire

Pour j de 1 au nombre de tournées faire

Si i ≠ j faire

Recherche locale de type insertion entre les tournées i et j

suivant l’ordre randomisé

Fin si

Fin pour

Fin pour

Pour chaque tournée de la solution faire

Recherche locale de type 4_opt intra-tournée

Fin pour

Affecter un ordre de façon randomisée aux tournées

Pour i de 1 au nombre de tournées faire

Pour j de 1 au nombre de tournées faire

Si i ≠ j faire

Recherche locale de type 4_opt inter-tournée entre les

tournées i et j suivant l’ordre randomisé

Fin si

Fin pour

Fin pour

nb_itération++

Fin tant que

Fin

Cette recherche locale repose sur le principe que pour améliorer une tournée, il peut apparaître logique de se focaliser dans un premier temps sur les clients qui imposent un détour important du véhicule. Ainsi chacune des deux recherches locales associées à un mouvement intra-tournée (2_opt intra-tournée et 4_opt intra-tournée) opère avec une certaine probabilité du client le plus contraignant au client le moins contraignant. Sur ce même raisonnement, pour les mouvements faisant intervenir deux tournées (insertion et 4_opt inter-tournée), on affecte un ordre de traitement des tournées afin que les tournées traitées en priorité aient une forte probabilité d’être celles possédant le client imposant le plus grand détour.

Description des différents mouvements utilisés : La recherche locale repose donc sur quatre mouvements :

Le mouvement 2_opt intra-tournée qui est similaire à celui présenté pour le VRP.

Le mouvement insertion qui consiste prendre un client d’une tournée pour l’insérer dans une autre comme le montre la Figure 79.


78

Figure 79 : Mouvement d'insertion

Le mouvement 4_opt intra-tournée qui consiste à changer quatre arcs d’une tournée par quatre autres. Le nombre de possibilités d’un tel mouvement étant très important, on se restreint dans cet algorithme au cas où l’on échange les places de deux clients comme le montre la Figure 80.

Figure 80 : Mouvement 4_opt intra-tournée

Le mouvement 4_opt inter-tournée qui consiste à changer deux arcs d’une tournée et deux arcs d’une seconde par quatre autres. On se restreint là encore au cas où l’on échange les places de deux clients illustré sur la Figure 81.

Figure 81 : Mouvement 4_opt inter-tournée


79

3. Paramètres et résultats

3.1 Paramètres sur les instances classiques

Le schéma Figure 82 reprend le schéma général présenté dans la partie précédente afin d’expliquer plus clairement les différents paramètres qui entre en œuvre dans cet algorithme.

Figure 82 : Paramètres de l’algorithme pour le HVRP

Les principaux paramètres :

Le nombre maximal de solutions dans la population : 100.

Le nombre d’itérations de la boucle Principale α=80.

Le nombre d’itération de la boucle d’injection de nouvelles solutions dans la population β=20

Le nombre de meilleures solutions prises comme point de départ du Path-Relinking δ1=10.

Le nombre de solutions cibles associées à chaque point de départ du Path-Relinking δ2=10.


80

L’amélioration minimale de la boucle principale de la recherche locale : 0.5

Le nombre d’itérations maximal de la boucle principale de la recherche locale : 10

Pourcentage de TG pris en compte lors d’un Path-Relinking : 5%

3.2 Performances des ordinateurs utilisés

Pour pouvoir comparer les résultats obtenus à ceux de la littérature, on se base sur le Tableau 12 des puissances relatives des ordinateurs établit par *Duh10+ auquel on rajoute la valeur associée à la puissance de l’ordinateur utilisé dans le cadre de ce stage et celle de l’ordinateur utilisé par *Sub12+

Tableau 12 : Performance des processeurs

3.3 Résultats numériques sur les instances classiques

Les résultats présentés Tableau 13 (deux parties) pour l’algorithme proposé sont ceux obtenus par la meilleure parmi 5 exécutions effectuées.

La première colonne indique l’instance traitée. Les instances utilisées sont les instances numéro 13 à 20 des instances de Golden *Gol84+. La colonne 2 indique le nombre de types de véhicules de l’instance. La colonne 3 indique le nombre de clients de l’instance. La colonne 4 indique le coût de la meilleure solution connue de l’instance. De la colonne 5 à la colonne 16, figurent les résultats associés aux différentes publications. A chaque publication est alors associée 3 colonnes respectivement le coût de la solution obtenue, la différence en pourcentage par rapport à la meilleure solution connue, et le temps d’exécution standardisé de la méthode utilisée.

Publications Fréquence Processeurs Mflops Coéfficients

Taillard (1999) 50MHz SunSparc10 27 0.007

Tarantilis et al.(2004) 400Mhz PentiumII 262 0.063

Li et al.(2007) 1GHz Athlon 1168 0.282

Prins (2009a) 1.8GHz Pentium4M 1564 0.378

Duhamel et al.(2010) 2.1GHz Opteron 4140 1.000

Subramaniana et al.(2012) 2.93 GHz IntelCore i7 5839 1.410

Mon ordinateur 2.0 GHz PentiumT4200 1073 0.259

81

Tableau 13 : Résultats du HVRP sur les instances de Golden

Taillard Tarantilis Li Prins

Instances types n BKS Cost Gap % scaled time Cost Gap % scaled time Cost Gap% scaled time Cost Gap % scaled time

13 6 50 1517,84 1518,05 0,01 3,311 1519,96 0,14 53,109 1517,84 0,00 100,956 1517,84 0,00 12,5496

14 3 50 607,53 615,64 1,33 4,025 611,39 0,64 24,381 607,53 0,00 39,762 607,53 0,00 14,2128

15 3 50 1015,29 1016,86 0,15 2,345 1015,29 0,00 23,184 1015,29 0,00 46,812 1015,29 0,00 2,4948

16 3 50 1144,94 1154,05 0,80 2,45 1145,52 0,05 21,483 1144,94 0,00 53,016 1144,94 0,00 2,7594

17 4 75 1061,96 1071,79 0,93 15,715 1071,01 0,85 22,869 1061,96 0,00 60,912 1065,85 0,37 30,807

18 6 75 1823,58 1870,16 2,55 20,132 1846,35 1,25 61,173 1823,58 0,00 103,212 1823,58 0,00 72,0468

19 3 100 1117,51 1117,51 0,00 40,831 1123,83 0,57 26,964 1120,34 0,25 113,928 1120,34 0,25 67,2084

20 3 100 1534,17 1559,77 1,67 23,814 1556,35 1,45 72,828 1534,17 0,00 126,054 1534,17 0,00 84,4074

Moyenne 1227,8525 1240,47875 0,93 14,077875 1236,2125 0,62 38,248875 1228,20625 0,03 80,5815 1228,6925 0,08 35,810775

Duhamel (Greedy Split) Duhamel (DFS) Subramaniana Path-Relinking

Instances types

n BKS Cost Gap

% scaled time

Cost Gap % scaled time

Cost Gap % scaled time

Cost Gap

% scaled time

13 6 50 1517,84 1517,84 0,00 15,36 1517,84 0,00 16,01 1517,84 0,00 1,88 1518,05 0,01 225,68

14 3 50 607,53 609,17 0,27 24,2 607,53 0,00 71,63 608,74 0,20 1,54 609,17 0,27 10,62

15 3 50 1015,29 1015,29 0,00 33,86 1015,29 0,00 9,16 1015,29 0,00 3,00 1015,29 0,00 35,82

16 3 50 1144,94 1144,94 0,00 22,51 1144,94 0,00 28,19 1145,23 0,03 1,99 1148,62 0,32 35,43

17 4 75 1061,96 1065,2 0,31 23,61 1065,2 0,31 43,12 1064,67 0,26 5,95 1067,06 0,48 88,50

18 6 75 1823,58 1823,58 0,00 129,45 1823,58 0,00 7,24 1831,48 0,43 5,72 1838,2 0,80 239,37

19 3 100 1117,51 1120,34 0,25 144,3 1120,34 0,25% 76,44 1121,11 0,32 12,86 1120,34 0,25 145,56

20 3 100 1534,17 1534,17 0,00 60,33 1548,89 0,96% 221,43 1536,89 0,18 12,53 1562,72 1,86 106,82

Moyenne 1227,8525 1228,81625 0,10 56,7025 1230,45125 0,19 59,1525 1230,15625 0,18 5,68 1234,93125 0,50 110,973536


82

De façon générale, on peut voir que l’algorithme de ce stage obtient un coût moyen meilleur que ceux associés aux publications de Taillard et de Tarantilis. Cependant Les publications les plus récentes obtiennent globalement de meilleurs coûts. En termes de rapidité l’algorithme développé est en moyenne plus lent que ceux des articles présentés. En analysant de façon plus détaillée, on remarque que l’on obtient la meilleure solution connue pour l’instance 15 et que l’on se situe à 0.01% de la meilleure solution connue de l’instance 13. Pour ce qui est du temps de calcule, on remarque que l’algorithme est particulièrement lent pour les instances 13 et 18 qui possèdent un nombre de types de véhicules important, alors qu’il est très correcte sur les autres instances relativement aux autres publications.

Les résultats sur les instances de Golden sont donc plutôt satisfaisants car proches de ceux trouvés dans les publications existantes. Le principal point négatif de l’algorithme proposé est son comportement par rapport à un grand nombre de types de véhicules où son temps d’exécution devient très élevé comparé aux différentes publications.

3.4 Présentation de l’instance générée sur un réseau routier concret

Apres avoir illustrée l’efficacité de l’algorithme proposé en se comparant aux principaux travaux du domaine grâce aux instances de Golden *Gol84+, il est intéressant d’étudier un cas se basant sur un réseau routier concret. Afin de construire une instance de HVRP valide, les données du réseau routier du centre de Clermont-Ferrand sont récupérées via OSM et sont transformées sous forme de graphe de façon analogue à ce qui a été fait dans le chapitre 2. Une fois le graphe routier complet établit, on construit les éléments qui formeront le graphe associé à l’instance que l’on veut générer (Figure 83).

Figure 83 : Réseau routier de l’instance de HVRP sur Clermont-Ferrand

On choisit 51 nœuds du réseau routier de façon randomisée qui représentent les clients à desservir et on leur associe aléatoirement une demande entre 1 et 100 unités. La répartition des clients est illustré Figure 24.


83

Figure 84 : Répartition des clients de l’instance de HVRP sur Clermont-Ferrand

On obtient par ce procédé une demande totale à desservir de 1769 unités, on choisit donc en conséquence une flotte de véhicules de capacité raisonnable. La flotte choisie est composée de quatre types de véhicules :

Type 1 : 1 véhicule de capacité 160, de coût fixe 10.0 et de coût par unité de distance 1.0

Type 2 : 2 véhicules de capacité 260, de coût fixe 25.0 et de coût par unité de distance 2.0

Type 3 : 2 véhicules de capacité 360, de coût fixe 50.0 et de coût par unité de distance 8.0

Type 4 : 1 véhicule de capacité 600, de coût fixe 100.0 et de coût par unité de distance 10.0

Pour que les coûts fixes des différents véhicules ainsi choisis aient un impact raisonnable sur la constitution des tournées par notre algorithme, on choisit d’utiliser comme unité de distance 10 mètres.

Les instances classiques de la littérature, comme les instances de Christofides pour le VRP ou celles de Golden pour le HVRP, utilisent des coordonnées cartésiennes pour localiser les clients et le dépôt et utilisent la distance euclidienne pour estimer la distance entre chaque nœud (le coût de chaque arrête du graphe). Dans cette instance, on utilise les coordonnées GPS du graphe routier pour localiser les nœuds représentants les clients et le dépôt. Pour établir le coût de chacune des arrêtes du graphe associé à l’instance on calcule sur le graphe du réseau routier la distance du plus court chemin entre chacun des 52 nœuds choisis. Ces calculs de plus court chemin sont faits de façon exacte par un algorithme de Dijkstra. Une fois le graphe construit, l’instance est complète et peut être utilisée par l’algorithme de résolution de HVRP proposé dans ce chapitre.

3.5 Résultats sur l’instance de Clermont-Ferrand

On va présenter dans cette section la meilleure solution obtenue par l’algorithme de HVRP sur l’instance du centre de Clermont-Ferrand. Les paramètres utilisés sur cette instance sont les mêmes que ceux utilisés sur les instances de Golden. La meilleure solution obtenue sur 5 exécutions est constituée de 6 tournées présentées dans le Tableau 14.


84

Tableau 14 : Liste des tournées d’une solution sur l’instance de Clermont-Ferrand

Tournée Type Volume occupé Volume libre Clients Longueur Coût

1 1 160 0 15 985,97 995,97 2 4 580 20 11 387,67 3976,66 3 3 356 4 10 377,71 3071,68 4 2 258 2 4 403,01 871,02 5 3 158 202 3 23,81 240,49 6 2 257 3 8 592,39 1289,79

La première colonne indique l’indice de la tournée. La deuxième colonne indique le type de la tournée. La troisième colonne indique le volume total de demande traitée par la tournée. La quatrième colonne indique le pourcentage d’espace restant au véhicule de la tournée. La cinquième colonne indique le nombre de clients de la tournée. La sixième colonne indique le coût total de la tournée.

On remarque sur ces résultats que les véhicules les moins coûteux (de type 1 et 2) effectuent des tournées de longueurs élevées malgré leur faible capacité ; ils s’occupent donc à priori de desservir les clients les plus éloignés. D’autre part il est logique que les véhicules ayant un gros coût par unité de distance (de type 3 et 4) ne soient utilisés que partiellement. Cependant il est intéressant de remarquer que le véhicule qui est très nettement le plus délaissé n’est pas le véhicule de type 4 mais celui de type 3. Ce phénomène peut s’expliquer par la différence de capacité des véhicules. Il faut en effet garder en tête que pour les points qui ne sont pas dans le voisinage du dépôt, il est à priori préférable que les points les plus proches les uns des autres soient traités par la même tournée afin de limité la distance totale parcourue.

Pour étayer ces remarques, on présente les trois tournées suivantes :

La tournée 1 qui utilise le véhicule le moins coûteux et qui est de longueur maximale

La tournée 2 qui utilise le véhicule le plus coûteux et qui est remplie à plus de 98%

La tournée 5 qui utilise un véhicule de type 3, qui est de longueur minimale est remplie à moins de la moitié de sa capacité.

La première tournée est constituée de 15 clients qui sont desservis par le véhicule de type 1 dans l’ordre illustré Figure 85 où le dépôt est représenté par un point vert. Sur la figure, deux clients successifs sont reliés par une droite afin de ne pas la surcharger avec le chemin complet reliant ces clients. On peut voir que les clients desservis sont très dispatchés du nord au sud de l’instance et vont de l’extrême ouest au centre de l’instance. On remarque en particulier que la tournée prend les points les plus au sud-ouest de la carte.


85

Figure 85 : Première tournée de la solution associée à l’instance de Clermont-Ferrand

La deuxième tournée est constituée de 11 clients qui sont desservis par le véhicule de type 4 dans l’ordre illustré Figure 86 où le dépôt est représenté par un point vert. On peut voir que les clients desservis sont scindés en trois groupes :

Un groupe de trois points proches du dépôt.

Un groupe très compact de 5 points à une distance modéré du dépôt.

Un deuxième groupe compact de 3 points à une distance également modéré du dépôt.

Figure 86 : Deuxième tournée de la solution associée à l’instance de Clermont-Ferrand

La cinquième tournée n’est constituée que de 3 clients qui sont desservis par un véhicule de type 3 dans l’ordre illustré Figure 87 où le dépôt est représenté par un point vert. On peut voir que les


86

clients desservis ont de grosses demandes et sont très proches du dépôt.

Figure 87 : Cinquième tournée de la solution associée à l’instance de Clermont-Ferrand

4. Conclusion

Dans ce chapitre nous avons pu, grâce au travail effectué précédemment sur le VRP, résoudre de façon approchée le problème du HVRP par une métaheuristique. Le point fort de notre méthode fut d’approcher le problème d’une façon originale par une méthode de Path-Relinking tout en gardant des résultats satisfaisants comparés aux principales publications sur le sujet.

Nous nous sommes, par ailleurs, servi du travail effectué dans le deuxième chapitre pour proposer une méthode de construction d’instance basée sur un réseau routier réel afin d’appliquer notre algorithme à un cas concret.

5. Références

*Bal09+ R., Baldacci and A., Mingozzi, A unified exact method for solving different classes of vehicle routing problems. Mathematical Programming, vol. 120 , pp. 347-380, 2009.

*Duh10+ C. Duhamel, P. Lacomme and C., Prodhon, Efficient frameworks for greedy split and new depth first search split procedures for routing problems, Computers & Operations Research, vol.38, pp. 723–739, 2010.

*Gol84+ B. L., Golden, A. A., Assad, L.,Levy and F., Gheysens, The feet size and mix vehicle routing problem, Computers & Operations Research, vol. 11, pp. 49-66, 1984.

*Glo96+ F. Glover. Tabu search and adaptive memory programing – Advances, applications and challenges. In R.S. Barr, R.V. Helgason, and J.L. Kennington, editors, Interfaces in Computer Science and Operations Research, pp 1–75. Kluwer, 1996.

*Li07+ F., Li, B., Golde and E., Wasil, A record-to-record travel algorithm for solving the heterogeneous fleet vehicle routing problems. Computers & Operations Research, vol. 34, pp. 2734–2742, 2007.


87

*Li10+ X. Li, P., Tian and Y., Aneja, An adaptive memory programming metaheuristic for the heterogeneous fixed fleet vehicle routing problem. Transportation Research Part E: Logistics and Transportation Review, vol. 46, pp. 1111-1127, 2010.

*Pes09+ A., Pessoa, E., Uchoa and M., Aragao, A robust branch-cut-and-price algorithm for the heterogeneous fleet vehicle routing problem. Networks, vol. 54 , pp. 167-177, 2009.

*Pri09+ C., Prins. Two memetic algorithms for heterogeneous fleet vehicle routing problems. Engineering Applications of Artificial Intelligence, vol. 22, pp. 916–928, 2009.

*Sev07+ M., Sevaux, K. Sörensen, J. Springael, and W. Dullaert. Applications of metaheuristics. European Journal of Operational Research, 179(3):601-604, 2007

*Sub12+ A., Subramaniana, P. Huachi Vaz Penna, E. Uchoa and L. Satoru Ochi. A Hybrid Algorithm for the Heterogenous Fleet Vehicle Routing Problem. European Journal of Operational Research January 18, 2012

*Tai99+ E., Taillard, A heuristic column generation method for the heterogeneous fleet VRP. RAIRO Operations Research, vol. 33 (1), pp. 1–14, 1999.

*Tar04+ C., Tarantilis, C., Kiranoudis and V., Vassiliadis, A threshold accepting metaheuristic for the heterogeneous fixed fleet vehicle routing problem, European Journal of Operational Research 152, pp. 148–158, 2004

*Zha05+ L., Wang, Y., Zhang and J. Feng, On the Euclidean Distance of Images, IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 27(8), pp. 1334-1339, Aug. 2005

89

Conclusion

Durant ce stage d'une durée de 6 mois, trois problèmes de recherche opérationnelle ont été traités sur les problèmes de routing. Le premier problème à résoudre a été le VRP, considéré comme le problème de base en tournées de véhicules, qui a permis de se familiariser avec les méthodes approchées. Le deuxième problème abordé a été le problème de cheminement en milieu urbain intégré dans un environnement mobile. Il a permis d’appréhender les différentes contraintes liées au milieu urbain et au milieu mobile. Le dernier problème abordé a été le HVRP qui est un problème de tournées de véhicules sur lequel peu de littérature a été publiée.

Le premier mois du stage a été consacré à la découverte du milieu scientifique, l’étude des différents problèmes théoriques abordés plus tard durant le stage. Cette première période s'est terminée par l’élaboration d’une métaheuristique pour résoudre le VRP. Les résultats de cette méthode ont été comparés aux résultats obtenus par C. Prins.

Une fois ces compétences acquises, une majeure partie du stage fut consacrée au problème de cheminement pour piéton en milieu urbain dans un environnement mobile. Cette partie consiste, dans un premier temps, à élaborer une méthode de résolution de plus court chemin dans des graphes de grandes tailles. Une fois ce travail effectué, un service web dialoguant avec une base de données routières. Une application GPS sous Android dédiée aux guidages de piétons en milieu urbain et utilisant ce web service a été élaborée. L’application et le web service sont fonctionnels et ont été présentés à Paris au siège de Via Michelin qui possèdent des services d’itinérance pour véhicule très performants.

La dernière partie de mon stage consistait à concevoir une méthode approchée originale pour le HVRP qui soit applicable aux instances de la littérature mais aussi à des instances construites à partir de réseaux routiers. Cette méthode de résolution propose des résultats satisfaisants et s’applique parfaitement aux instances de très grande taille créées à partir de plusieurs milliers de nœuds et d’arcs issus d’un réseau routier de Clermont-Ferrand.

Ce stage m’a permis de monter en compétences sur de nombreux domaines qui m’étaient peu familiers mais aussi de m’intégrer au domaine de la recherche opérationnelle me permettant ainsi de poursuivre mon cursus par une thèse.

A partir du mois de septembre 2013, je débute une thèse avec la société Ip Leanware financée par une bourse d'innovation de la région Auvergne.

91

ANNEXES

ANNEXE 1 : Installation et détails du fonctionnement de l'application mobile ........................................A1

ANNEXE 2 : Installation et détails du fonctionnement de l'application mobile ...................................... A11

Annexes

A-1

ANNEXE 1

Installation et détails du fonctionnement de l'application

mobile

Annexes

A-3

Installation de l’application Pour installer l’application sur un mobile Android, il suffit de suivre les trois étapes suivantes :

Télécharger l’application sur le mobile à l’adresse suivante : http//www.isima.fr/~lacomme/ORWebServices/GPS4pedestrian/source/Gps_android.apk

Configurer le mobile pour accepter les applications non issues du market Android. Pour cela il faut aller dans les paramètres du téléphone puis dans l'onglet Sécurité et autoriser l’installation d’application non Market.

Installer sur le mobile l’application à partir du fichier téléchargé.

Figure A-1 : Installation de l’application Android en trois étapes

Il faut noter que pour utiliser l’application, le GPS et les données mobiles du téléphone doivent être

activés.

Figure A-2 : Exemple d’utilisation de l’application

http://www.isima.fr/~lacomme/ORWebServices/GPS4pedestrian/source/Gps_android.apk

Annexes

A-5

Détails du fonctionnement de l'application mobile

Dans cette annexe, nous illustrons à les différents cas d’utilisation de notre application à travers le parcours d’un itinéraire en allant du parking de l’ISIMA jusqu’au centre d’Aubière (12 rue des ramacles).

Figure A-3 : Vue d’ensemble du trajet à effectuer

Nous commençons donc par vérifier que le mobile dispose d’une connexion réseau et que la localisation par GPS est activée. Une fois cette vérification effectuée, et l’application lancée, on accède à l’interface à partir de laquelle on a accès au menu de l’application :

Annexes

A-6

Figure A-4 : Interface de démarrage

A partir de ce menu, on choisit l’onglet "ma position" afin de vérifier que le mobile

localise correctement le téléphone. Cette étape n’est pas nécessaire, elle permet seulement

d’ajuster automatique le zoom de la carte mais il faut noter que le calcul d’itinéraire ne se

déclenchera pas tant que le mobile n’est pas géolocalisé.

Annexes

A-7

Figure A-5 : Lancement du calcul

sans position GPS

Figure A-6 : Zoom sur la position

courante

On choisit maintenant l’onglet Destination afin de rentrer l’adresse du point d’arrivée

(NB : Les abréviations av. pour avenue sont considérées comme des erreurs de saisie

d’adresse). Une fois l’adresse localisée, la carte est centrée sur la destination mais le zoom est

inchangé. Le calcul de l’itinéraire ne se déclenchera pas tant qu’aucune adresse n’a été saisie.

Figure A : Saisie de l’adresse de destination

Maintenant que l'application à tous les éléments nécessaires, il est possible de lancer la

demande d’itinéraire avec l’onglet guider. Le web service met en moyenne 5 secondes pour

traiter la demande. Une fois que l’itinéraire a été trouvé le chemin s’affiche sur la carte.

Notons qu’après le première itinéraire, l’application récupère auprès du web service un graphe

autour de la position courante afin de pouvoir lancer un recalcule en local en cas de coupure

réseau. Cette opération se fait de façon transparante pour l’utilisateur qui continue d’être

guidé durant le téléchargement.

Annexes

A-8

Figure A-8 : Calcul de l’itinéraire

Les indications à suivre commencent alors dès que la position de l’utilisation a bougé

ou que l’on appuie sur ma position. La position courante du mobile est projetée sur le chemin

et des indications sur la prochaine intersection apparaissent à l’écran au fur et a mesure que

l’on se déplace.

Figure A-9 : Parcours de l’itinéraire

A partir d’une certaine distance à parcourir et ceci même si l’utilisateur suit

parfaitement les consignes fournies par l’application, l’itinéraire se recalcule. Une fois que

l’on s’approche de la fin de la partie de l’itinéraire calculé, un recalcul est alors déclenché

Annexes

A-9

pour compléter l’itinéraire.

Figure A-10 : Calcul itératif

Lors du parcours du chemin, il peut arriver que l’utilisateur s’éloigne de l’itinéraire

précalculé. L’application déclenche alors un recalcul afin de prendre en compte le détour de

l’utilisateur.

Figure A-11 : Recalcule de l’itinéraire

Lors de ces différents recalculs, il peut arriver que la connexion avec le réseau soit

interrompue auquel cas l’application se sert du graphe stocké dans le téléphone (dans la

mesure où il comprend la position actuelle) pour effectuer le calcul d’itinéraire. Cette prise en

charge du calcul par l’application du téléphone est invisible pour l’utilisateur.

Dans l’exemple suivant, une perte de connexion a été simulé par la coupure des

données mobiles puis nous avons relancé le calcul d’itinéraire vers la destination par l’onglet

Annexes

A-10

guider, puis en déclenchant le recalcul de l’itinéraire de façon automatique si l'utilisateur

s’éloigne du chemin précédemment calculé.

Figure A-12 : Gestion de la perte de réseau

Annexes

A-11

ANNEXE 2

Liste de publications

Vincent B., P. Lacomme, R. Libo and N. Tchernev. Shortest Path in the context of Route

Guidance Systems. International France-China Workshop. NICST’2013, New and smart

Information Communication Science and Technology to support Sustainable Development,

18-20 September 2013, Clermont Ferrand, France. Accepté pour publication.

Vincent B., P. Lacomme, R. Libo and N. Tchernev. Shortest Path for Mobile Devices in Urban

Area., Congrès ROADEF de Société française de Recherche Opérationnelle et d'Aide à la

Décision. 26-28 février 2014. Soumission en cours.

Vincent B., P. Lacomme, R. Libo and N. Techernev. Shortest Path challenging problem in the

context of mobile devices in urban area takling weakened GPS data and wireless network

traffic interruption. ICORES 2014. 3rd

International Conferences on Operations Research and

Enterprise Systems. ESEO, Angers, Loire Valley, France, 6-8 march 2014.

Annexes

A-13

Vincent B., P. Lacomme, R. Libo and N. Tchernev. Shortest Path in the context of Route

Guidance Systems. International France-China Workshop. NICST’2013, New and smart

Information Communication Science and Technology to support Sustainable Development,

18-20 September 2013, Clermont Ferrand, France. Accepté pour publication.

Annexes

A-14

Annexes

A-15

Annexes

A-16

Annexes

A-17

Annexes

A-18

Annexes

A-19

Vincent B., P. Lacomme, R. Libo and N. Tchernev. Shortest Path for Mobile Devices in Urban

Area., Congrès ROADEF de Société française de Recherche Opérationnelle et d'Aide à la

Décision. 26-28 février 2014. Soumission en cours.

Annexes

A-20

Annexes

A-21

Vincent B., P. Lacomme, R. Libo and N. Techernev. Shortest Path challenging problem in the

context of mobile devices in urban area takling weakened GPS data and wireless network

traffic interruption. ICORES 2014. 3rd International Conferences on Operations Research and

Enterprise Systems. ESEO, Angers, Loire Valley, France, 6-8 march 2014.

Annexes

A-22

Annexes

A-23

Annexes

A-24

Annexes

A-25

Annexes

A-26

Annexes

A-27

Annexes

A-28

Annexes

A-29

Annexes

A-30

Conception de méthodes pour le transport à la demande pour...

Documents

Transcript of Conception de méthodes pour le transport à la demande pour...