Résultats et analyse

Série 1

Le point le plus intéressant ressortant de cette expérience, est que le proces- sus DARPetDARPT permet implicitement une minimisation des temps de transit (TRide) des usagers sans que la performance TGlobal soit altérée. Cela découle des res-

trictions progressives imposées par le processus sur les bornes ∆i, i = 1..|D|. Nous

pouvons remarquer sur le diagramme 5.8 que les temps de connexion sont pratique- ment divisés par deux si l’on compare la première itération à la dernière (ces valeurs ont été relevées exclusivement sur des tournées valides où toutes les demandes de l’instance ont été insérées). La somme des durées des tournées (TGlobal) demeure

dans le même temps relativement stable.

Série 2

Nous reportons les résultats en tableau 5.1. Ils correspondent à 18 groupes de 10 instances où, pour chacune, les meilleurs taux (meilleure réplication) ont été relevés. On remarque que l’algorithme DARPetDARPT, autorisant les transferts, insère bien plus de demandes qu’INSERTION.

|D| K EF TInsert TInsertT Gap 32 4 5 38,8 52,7 35,8 32 4 15 54,6 62,8 15,0 32 4 30 61,8 68,3 10,5 32 5 5 49,7 70,7 42,1 32 5 15 70,3 86,0 22,4 32 5 30 77,0 89,1 15,7 64 4 5 21,2 28,5 34,7 64 4 15 29,4 34,3 16,9 64 4 30 35,3 37,1 5.0 64 5 5 27,6 38,7 40,1 64 5 15 39,1 46,1 18,1 64 5 30 45,2 48,2 6,7 96 4 5 15,7 20,9 33,0 96 4 15 22,4 24,2 7,7 96 4 30 25,9 27,0 4,2 96 5 5 20,5 28,2 37,9 96 5 15 28,6 32,6 13,9 96 5 30 33,3 35,4 6,3

Table 5.1 – Taux d’insertions sur 18 groupes d’instances

Commentaires. Nous pouvons remarquer que Gap connaît une baisse lorsque |D| augmente. En effet, nous avons, pour les trois valeurs croissantes de |D|, respecti- vement un gap moyen de 23,58%, 20,25% et 17,54%. Ceci semble dû au fait que lorsque le nombre de demandes croît (notamment les demandes non-transversales), la flotte perd en taux d’insertion mais, que ce soit pour l’une ou l’autre des résolu- tions, remplit plus facilement ses véhicules. Dans les deux résolutions, les demandes transversales sont, au fil d’une réplication, insérées en fin de processus puisque la minimisation des durées des tournées implique de prendre en premier lieu les de- mandes autour du dépôt (créant ainsi un phénomène automatique de clustering). Lorsque le processus commence à intégrer les demandes transversales, les véhicules sont déjà bien remplis. C’est pourquoi plus il y a de demandes locales moins les véhicules auront la capacité de gérer les demandes transversales.

La variation sur K semble montrer que l’augmentation du nombre de véhicules profite aux transferts (gap moyen de 18,09% pour 4 véhicules et de 22,58% pour 5 véhicules). De manière inverse, ceci s’explique comme la diminution de Gap lorsque les demandes augmentent, ici l’espace d’accueil croissant, les possibilités de rem- plissage sont plus importantes. Cette différence peut également provenir d’un autre élément : le nombre de combinaisons entre les véhicules créant un point de transfert

est plus important.

La figure 5.9 est un cliché de ces résultats avec un ensemble de tournées avec transferts provenant d’une instance de petite taille.

Perspectives et conclusion sur le DARPT

Nous avons mis au point une heuristique à base d’insertions successives pour résoudre les problèmes de Dial-a-Ride avec la possibilité de réaliser un transfert. Notre algorithme est suffisamment générique pour utiliser le même principe pour un nombre plus élévé de transbordements possibles dans la satisfaction d’une demande donnée (mais la longueur des algorithmes en aurait été grandement affectée). Au moment de tester une insertion, la propagation de contraintes du chapitre 3 intègre deux nouvelles règles d’inférences permettant de couvrir l’ensemble des tournées. Ainsi, les contraintes concernant les durées maximales d’acheminement mais aussi celles venues des fenêtres de temps sont toujours respectées si l’algorithme valide une insertion. La difficulté suivante a été de déterminer le moment où les transferts pouvaient contribuer à la résolution du problème DARP. Nous avons mis au point un second algorithme contractant les durées maximum d’acheminement au fil des réplications pendant lesquelles les résolutions du DARP et du DARPT s’enchaînaient (s’il y a rejet des demandes par le premier). Les prochaines évolutions de l’algorithme pourront améliorer la création de ces nœuds par un traitement final, c’est-à-dire une fois que l’on connaîtra les chemins pris par les flottes (comme par exemple, une recherche locale dont l’opérateur appliquera des permutations avec les nœuds relais). A nouveau, mais cette fois-ci dans le cadre du DARPT, il sera nécessaire de considérer l’arrivée des demandes qui doivent être traitées par des véhicules déjà en train de satisfaire des demandes calculées d’autres optimisations précédentes et de les intégrer dynamiquement. Là encore, notre algorithme permet que cela se fasse le plus facilement possible.

A ce moment de notre étude, il est difficile de ne pas envisager l’hypothèse d’un rapprochement entre les modules division du chargement et transbordement dans une nouvelle variante du DARP. La manière la plus simple consisterait à modi- fier INSERTIONDARPT dans sa première étape en remplaçant INSERTION par INSERTIONDARPSL : de cette manière, les transferts viendraient en auxiliaires de la division du chargement et non plus de la résolution classique. La figure 5.10 actualise le processus général ainsi mis à jour. Il serait également possible de trai- ter l’ensemble Rejet1 afin de distribuer les tournées ainsi que les demandes non insérables ainsi en fonction de leurs caractéristiques (cf. figure 5.11).

Enfin, le framework mis au point pourrait encore faire l’objet de nombreuses ex- périmentations. Nous pourrions par exemple reprendre le problème de clustering et nous en servir afin de situer les différents dépôts aux endroits stratégiques qui im- pliquent la meilleure performance et ceci selon les types de distribution de demandes. Autrement dit, nous pourrions distribuer les demandes selon un scénario donné puis modifier au fil des réplications la place des différents dépôts de chaque sous-flotte pour finalement en déterminer leur meilleur emplacement. Le même schéma pour- rait également se faire sur la distribution des populations de véhicules dans les sous-flottes et, aussi, sur la distinction des dépôts de départ et d’arrivée.

Figure 5.10 – Intégration de la division de charge au schéma général de résolution

Chapitre 6

Introduction à la robustesse dans le

DARP dynamique - DARPRob

Introduction

Dans le problème de Dial-a-Ride statique, l’ensemble des données est connu à l’avance alors qu’un service de transport à la demande nécessite l’intégration des requêtes des usagers au fur et à mesure et cela de manière réactive. Ce contexte induit le problème dit du DARP dynamique (dont l’état de l’art a été écrit dans le chapitre 2). Les algorithmes étudiés jusque là permettent un passage relativement aisé à cet autre problème. Mais, les traitements du DARP par insertions successives des demandes, tels qu’ils ont pu être réalisés jusqu’à présent, souffrent d’un défaut : quand une demande est insérée dans un ensemble de tournées courantes, il est peu tenu compte de l’impact de cette insertion sur la difficulté qu’il pourrait y avoir à traiter les demandes restantes. De fait, le seul moment où une telle prise en compte a lieu se situe dans le choix de la demande à insérer, avec priorité faite à celles pour lesquelles l’insertion tend à devenir difficile. Pour le reste, le choix des paramètres d’insertion (la tournée puis les positions de l’origine et de la destination au sein de celle-ci) ne dépendent que de celles qui sont déjà réalisées.

Au fil des insertions, la capacité d’accueil des tournées par rapport aux contraintes de temps tend à se rétrécir. Ceci se manifeste au travers de la propagation de contraintes appliquée aux différents points de passage déjà attribués aux véhicules par les 5 règles d’inférence décrites dans le chapitre 3. En contexte dynamique, ce point est d’autant plus critique que des rendez-vous avec les usagers doivent être fixés (cf. figure 6.1 page suivante).

Prenons par exemple deux nœuds consécutifs d’une même tournée qui ont été insérés lors d’un premier processus de résolution. Supposons que ces deux insertions ont été réalisées de façon à minimiser la distance totale parcourue. Si les contraintes relatives aux demandes de ces nœuds le permettent, le temps qui séparera ces deux points de passage sera exactement celui qui est nécessaire pour parcourir la distance qui les sépare. Plus tard, lors d’un second processus de résolution, l’insertion d’une tierce demande entre ces deux rendez-vous sera difficile à appliquer, voire impossible.

Figure 6.1 – Contraction des fenêtres de temps

Plus précisément, ne pourra être inséré aucun nœud qui impliquerait des temps de service, ou qui ne se situerait pas sur le segment rejoignant les deux premiers, là où les rendez-vous ont déjà été pris.

Nous reprenons dans ce chapitre les caractéristiques des précédents, nous inté- grons une nouvelle fois une flotte de véhicules à capacité finie et commune prenant en charge des demandes définies par une charge, une géographie, une borne sur la durée de transit et des fenêtres de temps. D’abord pour le DARP statique puis pour sa version dynamique, notre but est de montrer comment, au moment de réaliser une insertion, il est possible de prendre en compte les demandes à venir afin de leur laisser suffisamment de place, dans un souci de rendre le système plus robuste (pour le cas dynamique).

Nous introduisons d’abord une mesure d’Insérabilité - ang. Insertability - pour chaque demande non encore prise en charge. Cette mesure met en jeu l’amplitude des fenêtres de temps. Nous l’utilisons de 2 façons : en contexte statique afin de faciliter l’acceptation des demandes et, en contexte dynamique, afin de préserver les possibilités d’insertion des demandes futures.

Dans un premier temps, pour le problème DARP statique, nous voyons comment, au moment d’insérer une demande, anticiper les insertions grâce à cette mesure. L’Insérabilité nous permet notamment de déterminer si une demande doit être reje- tée, dès lors que son acceptation entraînerait une importante chute de l’Insérabilité des demandes non encore insérées. Une première série d’expérimentations permet de tester et d’étudier le comportement de ces techniques.

Dans un second temps, nous adaptons ces procédés au cas dynamique. Ici, nous anticipons sur les demandes futures qui seront probablement à insérer lors de pro- chaines exécutions du processus de résolution. Nous représentons ces demandes fu- tures grâce à la notion de demandes virtuelles. Nous tendons donc à pratiquer les insertions courantes de façon à préserver l’Insérabilité de ces demandes virtuelles ce qui revient à introduire un critère de Robustesse. Pour permettre une seconde série d’expérimentations adaptées au contexte dynamique, nous mettons en place un modèle de simulation.