Eidelman, Adrián Pablo Valdez Lerena, Alejandro

Presentación del tema: "Eidelman, Adrián Pablo Valdez Lerena, Alejandro"— Transcripción de la presentación:

1 Eidelman, Adrián Pablo Valdez Lerena, Alejandro
Sistema de optimización para el ruteo dinámico de vehículos con ventanas de tiempo Buenos días, mi nombre es Alejandro y junto a Adrián vamos a presentar nuestra tesis de licenciatura sobre Ruteo Dinámico de Vehículos con ventanas de tiempo. Comencemos viendo de que se trata el problema que queremos resolver... Eidelman, Adrián Pablo Valdez Lerena, Alejandro Directora: Dra. Irene Loiseau

2 Introducción Descripción general del problema Motivación
Encontrar la mejor forma de organizar una flota de vehículos de reparto para poder entregar un conjunto de pedidos que van ingresando de manera dinámica Motivación Reducir los costos asociados a la cantidad de vehículos utilizados y sus recorridos Brindar una mejor atención a los clientes Un caso típico del ruteo dinámico de vehículos con ventanas de tiempo es el de un delivery que entregue productos a domicilio, en el que cada entrega debe realizarse en una determinada banda horaria, elegida por el cliente. Para realizar la entrega el delivery cuenta con una flota de vehículos. En nuestro caso los pedidos se van realizando a medida que transcurre el tiempo, es decir: inicialmente no hay pedidos para entregar y a medida que los clientes van realizando pedidos, estos se ingresan al sistema. Nuestro objetivo para resolver el problema es encontrar la mejor manera de armar los recorridos de los vehículos logrando emplear la menor cantidad de vehículos posibles, recorriendo la menor distancia y minimizando los tiempos de espera de un vehículo entre una entrega y la siguiente.

3 Caso real: Sushi Furusato
Situación actual Una persona dedicada a armar los recorridos que deben realizar los vehículos para cumplir con las entregas Desventajas El nivel de optimización depende de la persona que se está encargando de organizar los pedidos No se realiza un análisis sistemático de los posibles recorridos sino que se recurre a la intuición Para realizar el trabajo nos inspiramos en un caso real en el que se plantea este problema. Se trata de laa empresa Sushi Furusato que se dedica al delivery de Sushi a domicilio. Esta empresa cuenta con una flota de motos y al momento de hacer su pedido los clientes indican en que horario quieren recibirlo. En la actualidad, hay una persona que se dedica a revisar los pedidos pendientes y organizarlos en recorridos que luego son asignados a las motos. Esto tiene una serie de desventajas, como por ejemplo que la calidad de los recorridos armados dependen fuertemente de la habilidad de la persona que realiza la tarea Y del conocimiento que tiene de las distintas calles y barrios. Y que los recorridos producidos difícilmente logren aprovechar al máximo la capacidad de la flota de motos.

4 Elementos del problema
Área de distribución Una cuadricula representa una abstracción del mapa de calles Pedidos Cada pedido está asociado a un cliente, tiene un tamaño fijo y una banda horaria donde debe realizarse la entrega El conjunto de pedidos no se conoce inicialmente sino que pueden ingresar en cualquier momento Veamos más en detalle los distintos elementos que componen el problema tratado. En lugar de utilizar un mapa de calles, vamos a utilizar una cuadricula como las que se usan en las guías de transportes para definir el area donde se realiza la distribución de los pedidos. De esta manera queremos independizarnos del recorrido detallado que realiza la moto y solo nos fijamos entre que casillas se mueve. Por otro lado, tenemos los pedidos que además de tener una banda horaria tienen un tamaño que podría corresponderse a su volumen o peso, y cuyo destino está ubicado en una casilla del mapa. Como dije antes, estos pedidos no se conocen inicialmente sino que van ingresando a medida que transcurre el horario de atención del delivery.

5 Elementos del problema
Rutas Es una secuencia de pedidos de entrega, parte y termina en el depósito central. Para medir el recorrido se utiliza una métrica euclidiana. Flota Conjunto homogéneo de vehículos donde todos tienen la misma capacidad de transporte Un vehículo tiene asignado solo una ruta Depósito Lugar desde donde parten todos los vehículos para iniciar un recorrido de entrega y adonde vuelven luego de terminarlo Una ruta es la secuencia de pedidos que debe entregar un vehículo. Las rutas se inician en el depósito central, realizan su recorrido y vuelven al depósito a la espera de una nueva asignación. Para medir la distancia entre dos casillas se utiliza la longitud de una línea recta entre estas. Sobre la flota vamos a suponer que es un conjunto de vehículos de características similares, en este caso motos y a cada vehículo se le puede asignar a lo sumo una ruta por vez. También tenemos un depósito, que como dije antes, es el lugar de donde parten y a donde regresan los vehículos una vez realizado el recorrido.

6 Elementos del problema
Factibilidad de una ruta Una ruta es factible cuando se puede realizar el recorrido completo cumpliendo todas las ventanas de tiempo y sin exceder la capacidad del vehículo Solución Es un conjunto de rutas factibles que utilizan todos los pedidos que forman parte del sistema en un determinado momento Vamos a decir que una ruta es factible cuando la secuencia de pedidos es tal que se puede realizar su entrega respetando todas las ventanas de tiempo, y que además los pedidos a entregar no sobrepasan la capacidad del vehículo. Luego, una solución al problema es un conjunto de rutas factibles en los que se utilizan todos los pedidos que están pendientes de entrega en ese momento.

7 Objetivo del problema Minimizar la cantidad de viajes necesarios para realizar las entregas Minimizar el tiempo de espera entre entregas consecutivas de una ruta Minimizar la distancia recorrida Maximizar la capacidad utilizada en cada vehículo Nuestro objetivo es lograr encontrar soluciones que cumplan los que dice el slide. Minimizar la cantidad de viajes para realizar las entregas, esto permite tener un flota que no sea excesivamente grande y con vehículos sin utilizar. Minimizar el tiempo de espera entre entregas consecutivas, permite realizar mas entregas en la misma cantidad de tiempo. Minimizar la distancia recorrida, va a permitir realizar un ahorro en el uso de combustible. Maximizar la capacidad utilizada en cada vehículo, va a permitir poder enviar mas pedidos en un recorrido.

8 Problema a tratar Cantidad de vehículos ilimitada
Limite en el tiempo de viaje para un producto Pedidos de tamaño variable Los vehículos tienen velocidad constante Los pedidos que ingresan son factibles En base al problema que acabamos de explicar, nosotros realizamos algunas simplificaciones para que el problema sea computacionalmente mÁs sencillo de resolver. Vamos a suponer que la cantidad de vehículos es ilimitada. Esta simplificación la hacemos en base a que en caso de que se necesite mas motos, se puede contratar los servicios de una agencia que provea motos con conductor. De hecho este es el caso de furusato que cuenta con una flota de motos pero en caso de necesitar mas puede solicitarlas a una agencia especializada que le provee de mas motos en cuestión de minutos. Vamos a agregar un limite en el tiempo que un producto puede estar en transito, esto se debe a que algunos productos tienen cadena de frío y no puede pasar demasiado tiempo desde el comienzo del viaje hasta su consumo. Los pedidos son de tamaño variable, pero son lo suficientemente chicos para entrar en una moto vacía. Vamos a suponer que los vehículos tienen velocidad constante, lo cual nuevamente no es cierto, pero dado que los vehículos tienen características similares, seguramente se puede encontrar un estimador que indique la velocidad promedio dentro de la ciudad. Por ultimo, los pedidos que ingresan son factibles, esto significa que desde el momento en el que entran en el sistema alcanza el tiempo para realizar el viaje hasta el cliente y cumplir con la ventana horaria.

9 Nuestro enfoque VRPTW dinámico es un problema NP-Hard
No se conoce algoritmo que encuentre una solución óptima en tiempo polinomial Estos problemas suelen abordarse mediante el uso de técnicas heurísticas Proporcionan soluciones razonablemente buenas en periodos cortos de tiempo, sin garantizar que la solución sea óptima EL problema de distribución de vehículos planteado pertenece a la clase NP-Hard, por lo que hasta el momento no se conoce un algoritmo que encuentre una solución optima en tiempo polinomial. Este tipo de problemas suelen abordarse mediante el uso de técnicas heurísticas, que proporcionan soluciones razonablemente buenas, en periodos cortos de tiempo. Estos algoritmos no garantizan que la solución alcanzada sea la óptima.

10 Nuestro enfoque Utilizamos una heurística de búsqueda local
Parte de una solución inicial y realiza modificaciones intentando encontrar otras en las que se minimice el valor de una función objetivo Utilizamos Búsqueda Tabú (Glover, 1986) como metaheurística para evitar caer en mínimos locales Para tratar el problema utilizamos una heurística de búsqueda local, que parte de una solución inicial y la va cambiando de forma de mejorar la calidad de la solución. Estos algoritmos suelen encontrar soluciones localmente óptimas pero sin garantía de que sea la solución globalmente óptima. Para paliar el problema de las soluciones localmente óptimas utilizamos una metaheurística conocida con el nombre de Búsqueda Tabú que permite realizar movimientos de no mejora para alejarse de los óptimos locales.

11 Algoritmo propuesto Solución inicial
Inicialmente el conjunto de pedidos es vacío Heurística de inserción de pedidos Características deseables Debe ser rápida La solución resultante debe ser factible Debe minimizar el costo de la solución El algoritmo que proponemos parte de una solución inicial vacía, lo cual representa que el delivery acaba de abrir y está esperando que ingresen pedidos. Cuando ingresa un nuevo pedido al sistema hay que incorporarlo a la solución del problema, para realizar esta tarea encontramos como deseables los siguientes atributos: -Debe ser rápida, ya que podrían entrar muchos pedidos en forma consecutiva y con ventanas de tiempo con pronto vencimiento -La solución resultante debe ser factible, es decir: luego de insertar el pedido en la solución queremos que los recorridos que maneja el sistema puedan ser cumplidos. -Debe minimizar el costo de la solución, sería deseable que al insertar un pedido nuevo en una solución, la solución resultante fuera la mejor que se podría obtener al insertar ese pedido.

12 Inserción de pedidos Alternativas analizadas Factor decisivo
Realizar una búsqueda exhaustiva y en caso de no poder agregar el pedido a ninguna ruta utilizar una ruta nueva. Utilizar un algoritmo goloso Asignar una ruta nueva al pedido Factor decisivo Aprovechar al máximo el tiempo de cómputo disponible para optimizar la solución en general Para esta tarea analizamos distintas alternativas. -En primer lugar realizar una búsqueda exhaustiva en la solución, esto sería analizar en todas las rutas y en todas las posiciones factibles, cual es el mejor lugar para ubicar el pedido nuevo. -Utilizar un algoritmo goloso que se conforme con ubicar el pedido en el primer lugar que se pueda. -Por último, poner al pedido en una ruta nueva. En la práctica encontramos que era mas provechoso utilizar el tiempo de computo en mejorar la solución globalmente, que utilizar ese tiempo en ubicar un pedido en el mejor lugar posible. Esto está relacionado a la característica dinámica del problema, porque supongamos que ubicamos un pedido en el mejor lugar posible, lo mas probable es que la entrada de un pedido nuevo haga que el lugar donde insertamos el pedido anterior deje de ser ‘el mejor lugar’ y por lo tanto hayamos desperdiciado tiempo.

13 Inserción de pedidos Asignar el pedido a una ruta nueva
Inserción en O(1) Permite que el algoritmo Tabú explore las distintas formas de incorporar el pedido a la solución Mantiene la factibilidad de la solución La alternativa que mejor resultado nos dio fue la última: poner el pedido en una ruta nueva. -Este método utiliza una cantidad de tiempo constante, -Permite que el algoritmo Tabú explore las distintas maneras de agregar el pedido a las rutas existentes y, -Hace que la solución siga siendo factible luego de la inserción, porque el pedido está en un vehículo nuevo y podría partir tan pronto como fuera necesario para cumplir la ventana de tiempo del mismo.

14 Heurísticas de mejora Estrategias a seguir para encontrar una solución nueva de menor costo a partir de la inicial Intercambios Or-Opt (Or, 1976) Ampliamente utilizado en la bibliografía Se aplica a un par de rutas (origen, destino) Consiste en mover una secuencia de 1, 2 o 3 pedidos consecutivos desde la ruta de origen hacia algún punto de la ruta de destino Ahora vamos a ver las distintas estrategias que utilizamos para partiendo de una solución inicial intentar encontrar otra de mejor calidad. Los intercambios Or-Opt son una estrategia propuesta por Or en el año 76 y consiste en mover una secuencia de 1, 2 o 3 pedidos consecutivos desde una ruta DE origen hacia algún punto de una ruta de destino. Veamos un ejemplo para que quede mas clara la idea.

15 Intercambios Or-Opt Ejemplo: El pedido 5 de la ruta 2 pasa al final de la ruta 1 Acá podemos observar que originalmente tenemos dos rutas, la ruta 1 con dos pedidos y la ruta 2 con cuatro pedidos, lo que vamos a hacer es mover el Pedido 5 desde la ruta 2 al final de la ruta 1. En este caso la ruta 2 sería la ruta de origen y la ruta 1 la de destino. En nuestro caso solo vamos a realizar este tipo de movimientos cuando el movimiento de los pedidos mantenga la factibilidad de ambas rutas. Veamos otro ejemplo.

16 Intercambios Or-Opt Ejemplo: Los pedidos 3 y 4 pasan al inicio de la ruta En este caso, la ruta de origen y la de destino son la misma, esto permite explorar distintas maneras de ordenar los pedidos dentro de una ruta. Se puede ver que se retiran los pedidos 3 y 4 del medio de la ruta y se los pasa al principio de la misma.

17 Heurísticas de mejora Radio de acción
Es la máxima amplitud angular que se le permite tener a una ruta, tomando como origen de coordenadas el centro de distribución Idea no encontrada en la bibliografía Valor determinado en base a la experiencia Permite restringir el conjunto de posibles movimientos a analizar Para una ruta dada definimos lo que llamamos Radio de Acción que es la amplitud angular que tiene una ruta, tomando como origen de coordenadas el centro de distribución. Vamos a utilizar el radio de acción para limitar cuan “ancha” puede ser una ruta. Esta idea no la encontramos en la bibliografía, al menos usada en este tipo de problemas. El valor del radio de acción debe obtenerse en forma empírica mediante el análisis de varias instancias de prueba. Además de restringir cuan “ancha” puede ser una ruta, vamos a usar el radio de acción para limitar el conjunto de rutas entre las que vamos a hacer movimientos Or-Opt. Para realizar un movimiento Or-Opt entre dos rutas, vamos a pedir que los radios de acción de esas dos rutas tengan intersección no vacía. Esto tiene sentido porque si los ángulos de las dos rutas no se cruzan es porque seguramente las rutas están orientadas hacia zonas distintas, por ejemplo no vamos a querer analizar movimientos entre una ruta que va hacia el norte y una que va hacia el sur.

18 Radio de acción Ejemplo 1:
Acá tenemos un gráfico que ilustra la idea del radio de acción. Vemos una ruta que parte del depósito, pasa por el pedido 1 y luego al pedido 2. En líneas punteadas está marcado el máximo radio de acción que podría tener esta ruta. Por lo tanto, cualquier pedido que se quiera insertar en la misma deberá estar dentro de este radio. Notar también que el radio de acción está centrado alrededor de la ruta.

19 Radio de acción Ejemplo 2:
Acá tenemos otro ejemplo, una ruta de 3 pedidos en la que casi se está usando todo el radio de acción, no vamos a permitir agregar pedidos a esta ruta que estén fuera del mismo.

20 Radio de acción Un valor demasiado grande tenderá a producir rutas con recorridos extensos en distancia Un valor demasiado chico tenderá a producir rutas con pedidos mas cercanos entre si, pero aumentará la cantidad de rutas de la solución Permite que la metaheurística no explore movimientos de pedidos entre rutas que no tengan radios de acción que se intersecan Esto permite no desperdiciar tiempo de computo en soluciones que seguramente no serán de buena calidad Si el radio de acción es demasiado amplio, en una misma ruta van a entrar pedidos que estén muy distantes entre si. Esto va a aumentar la distancia recorrida por cada vehículo lo cual no es deseable pues queremos minimizar la distancia recorrida por la flota. Si se eligiera un valor demasiado chico de radio de acción, se producirían rutas angostas con pedidos muy cercanos entre si pero se aumentaría la cantidad de rutas utilizadas. Esto equivaldría a utilizar mas vehículos para las entregas, situación que tampoco es deseable pues queremos minimizar el tamaño de la flota. Por eso el valor del radio de acción debe determinarse experimentalmente según el tipo de distribución espacial que tengan los pedidos. Como dije antes, la utilización del radio de acción para elegir entre que rutas se realizan intercambios de pedidos ayuda a restringir las combinaciones a analizar. Esto permite no utilizar tiempo de computo en movimientos que seguramente no van a dar buen resultado.

21 Heurísticas de mejora Selección de rutas a optimizar
No es factible analizar todas las formas posibles de acomodar los pedidos Se debe elegir subconjuntos de rutas para analizar sus intercambios Aun utilizando el radio de acción para restringir entre que rutas vamos a realizar movimientos de pedidos, el numero de rutas a analizar podría ser muy grande y esto no permitiría revisar todas las formas posibles de armar recorridos. Para tratar esta situación vamos a tomar dos subconjuntos de rutas del sistema, uno va a ser el de las rutas de origen y otro el de las de destino Y vamos a hacer intercambios Or-Opt solo entre estos dos subconjuntos.

22 Criterio de selección de rutas
Pasos Seleccionar aleatoriamente un conjunto de rutas X de tamaño t que serán tratadas como rutas de origen. Priorizando las rutas con un solo pedido Seleccionar aleatoriamente un conjunto de rutas Y de tamaño t que serán tratadas como rutas de destino (X e Y pueden tener elementos en común) La forma que mejor resultado nos dio fue elegir un tamaño t para cada subconjunto y asegurarnos que la suma de la cantidad de pedidos de las rutas en cada subconjunto no lo sobrepasen. En el caso de las rutas de origen se da prioridad a las rutas que tienen un solo pedido, que suelen ser pedidos que ingresaron recientemente al sistema. Recordar que para agregar un nuevo pedido al sistema lo ubicamos en una nueva ruta que solo contiene al pedido. Luego se realizan intercambios de pedidos desde cada ruta origen a cada ruta de destino en todas las posiciones donde sea factible insertar los pedidos que se están moviendo. Ver que los dos subconjuntos pueden tener rutas en común lo cual eventualmente permite analizar las distintas formas de ordenar el recorrido para una ruta dada.

23 Implementación de la Búsqueda Tabú
Lista Tabú Guardamos los movimientos inversos a los realizados Criterio de parada Quanto de tiempo disponible Movimiento Or-Opt manteniendo la factibilidad de la solución Vecindario Movimientos factibles entre las rutas de origen y destino cuyos radios de acción se intersecten Tamaño O(t2) Veamos ahora como implementamos los distintos conceptos del algoritmo de Búsqueda Tabú. La lista tabú es una secuencia de movimientos, donde por cada movimiento aplicado se guarda el inverso de ese movimiento. Antes de aplicar cada movimiento se verifica que el mismo no esté en la lista lo cual tiende a evitar repetir soluciones ya visitadas. Como criterio de parada para el algoritmo su utiliza un intervalo o “quanto” de tiempo. Esto permite parar el algoritmo para permitir que ingresen nuevos pedidos al sistema. El movimiento que permite pasar de una solución a otra nueva es la aplicación de un intercambio Or-Opt entre un par de rutas. Este intercambio debe mantener la factibilidad de la solución. El vecindario de la búsqueda local queda definido por todos los movimientos factibles entre los conjuntos de rutas de origen y destino cuyos radios de acción se intersecten. Esta vecindad tiene tamaño polinomial.

24 Implementación de la Búsqueda Tabú
Característica adicional Manejo de múltiples soluciones En cada quanto de tiempo, analizar el vecindario de la solución principal y luego utilizar el tiempo sobrante en el resto Intensificación Al priorizar la solución principal al inicio de cada quanto se intensifica la búsqueda en la zona más prometedora Diversificación Mediante las múltiples soluciones se analiza simultáneamente distintas formas de realizar las entregas Nuestra implementación maneja un conjunto de soluciones de entre las cuales se destaca la que llamamos ‘solución principal’ que es la mejor que se conoce hasta ese momento. Por cada quanto de tiempo el algoritmo comienza por optimizar la solución principal y una vez que no puede mejorarla MÁS, destina el resto de ese intervalo de tiempo a optimizar las demás soluciones que maneja. Originalmente repartíamos equitativamente el quanto de tiempo para analizar las distintas soluciones, pero descubrimos que esto generaba que todas las soluciones fueran mediocres. En cambio obtuvimos mejores resultados priorizando el proceso de optimización de la mejor solución conocida hasta el momento. El concepto de Intensificación del algoritmo Tabú se logra dedicando la mayor parte del tiempo a optimizar la solución principal, suponiendo que en la vecindad de esa solución debe haber otras de mejor calidad. La diversificación de la búsqueda se logra mediante el análisis de varias soluciones en forma simultanea, esto permite explorar distintos sectores del espacio de soluciones. Si alguna de esas soluciones resulta ser mejor que la solución principal, esta pasa a convertirse en la nueva solución principal.

25 Implementación de la Búsqueda Tabú
Función objetivo Minimizar la cantidad de rutas utilizadas Cada ruta tiene un “costo” de unidades Minimizar la distancia total de todas las rutas Cada unidad de distancia en el recorrido tiene un “costo” de 1 unidad Minimizar el tiempo de espera de las motos durante su recorrido Cada unidad de tiempo de espera tiene un “costo” de 1 unidad Por ultimo la función que se intenta minimizar es un polinomio donde intervienen distintos aspectos de la solución. Esta función tiene como objetivo principal minimizar la cantidad de vehículos utilizados y como objetivos secundarios minimizar la distancia total recorrida por la flota y el tiempo de espera de los vehículos entre entregas consecutivas de pedidos. Para poder comparar todos los aspectos al mismo tiempo y obtener un único valor para una determinada solución, nos fue necesario convertir los distintos valores a una unidad común. En el slide se muestra el factor de conversión para cada tipo de valor.

26 Implementación Módulos principales Dispatcher Optimizador
Implementa el modelado del tiempo y la generación de eventos Optimizador Implementa la metaheurística y el manejo de múltiples soluciones Visualización Permite comunicar el resultado de la simulación Para poder probar la heurística planteada en la teoría nos fue necesario desarrollar una herramienta informática. Esta herramienta la armamos de manera modular y sus módulos principales son: El dispatcher, módulo encargado de simular el paso del tiempo y la generación de los eventos El optimizador, que tiene a su cargo la implementación de la metaheurística y la administración de las múltiples soluciones La visualización, que permite comunicar los resultados de una manera humanamente legible

27 Dispatcher Necesidad de simular el avance del tiempo y el ingreso dinámico de pedidos Escala de tiempo para poder realizar pruebas en tiempos más cortos Utilización de un archivo de configuración que contiene los pedidos con sus características y su horario de ingreso al sistema Implementa la política de salida de rutas El módulo Dispatcher es necesario ya que a diferencia de muchos otros programas, el nuestro necesita simular el paso del tiempo y la ocurrencia de eventos. Desde un principio tuvimos en claro que era necesario poder escalar el tiempo real en un tiempo de simulación ya que de lo contrario cada prueba que quisiésemos realizar nos insumiría entre 4 y 6 horas que es el tiempo real durante el que entran y se reparten los pedidos. También vimos evidente la necesidad de contar con una forma sencilla de ingresar los distintos eventos al sistema. Para esto, la mejor opción nos resultó utilizar un archivo de configuración. Este archivo que es leído y procesado por el dispatcher, indica todos los eventos que deben ocurrir en una simulación y en que momento ocurren. La última, pero no por eso menos importante función del Dispatcher, es la de implementar la política de salida de las rutas.

28 Dispatcher Política de salida de rutas
Los pedidos deben partir o se vencen sus ventanas de tiempo Caso real: operador humano A falta de un operador humano que tome la decisión, el sistema debe decidir cuando una ruta debe partir Problema intratable computacionalmente Política implementada Las rutas parten lo más tarde posible pero asegurando que haya tiempo para cumplirlas Para poder usar más tiempo en la optimización A medida que avanza la simulación, los pedidos van entrando en el sistema y se van cargando en distintas rutas. Mientras esto ocurre, las mismas van siendo optimizadas y mejoradas por el algoritmo en busca de una mejor solución. Sin embargo, llega un momento en que las rutas deben partir del depósito ya que sino, se empezarán a vencer las ventanas de tiempo de sus pedidos. La política de salida de rutas, se encarga de decidir cuando es propicio que un vehículo salga a cumplir con su ruta de entrega de pedidos. En un caso real, sería un operador humano el que, basado en la información que le provee el sistema, decida que vehículo debe partir. Sin embargo, para poder realizar nuestras pruebas de forma automatizada, debíamos encontrar una política que pudiese ser implementada y que fuese razonable. El problema de decidir cuando una ruta debe partir es computacionalmente intratable, ya que uno nunca puede estar seguro que no va a entrar un nuevo pedido que va a hacer que la ruta sea mejor o que se pueda rearmar la ruta para hacerla más corta. En nuestro caso, decidimos dejar que el algoritmo use la mayor cantidad de tiempo posible para intentar optimizar las rutas, y por lo tanto, dejamos que estas queden en el sistema hasta un breve instante antes de que llegue su hora más tardía posible de partida.

29 Optimizador Mantiene la lista de múltiples soluciones y se encarga de distribuir el tiempo disponible Se prioriza la optimización de la solución principal y en caso de sobrar tiempo se analizan las demás Implementa la Búsqueda Tabú y la Búsqueda Local Permite incorporar nuevas heurísticas El módulo Optimizador, es el encargado de mantener la lista de múltiples soluciones y también de distribuir los tiempos de cómputos disponibles que fueron brindados por el Dispatcher. Cada vez que el Dispatcher entrega un nuevo lapso de procesamiento, el Optimizador selecciona a la mejor solución que se encontró hasta el momento y trata de mejorarla. En caso de realizar todos los movimientos de no mejora disponibles antes de que se agote el lapso de tiempo, el Optimizador selecciona la siguiente solución y trata de mejorarla y así hasta haber analizado todas o que se haya acabado el tiempo. El módulo Optimizador es el que posee el código que implementa la Búsqueda Tabú y fue hecho de manera tal que sea sencillo incorporar nuevas heurísticas en su funcionamiento.

30 Visualización Permite ver los pasos intermedios realizados por la Búsqueda Tabú y las rutas que deben ir saliendo Primera versión con log de texto Complejo de seguir a simple vista Segunda versión con generación de gráficos El último módulo que compone el sistema es el de Visualización. Este módulo permite observar los pasos intermedios que va realizando el sistema en búsqueda de la solución del problema. En una primera versión, la información era volcada en un formato de texto. Sin embargo, esto no permitía comprender a simple vista el funcionamiento y por lo tanto decidimos implementar una segunda versión que generase gráficos.

31 Visualización En este primer ejemplo de visualización vemos dos gráficos generados por el sistema. El de la izquierda es la imagen de la solución antes de retirar una ruta y el de la derecha luego de hacerlo. El punto rojo más grande representa al depósito, como se puede ver todas las rutas parten desde ahí. En el programa, las rutas terminan en el depósito pero no se grafica la vuelta al mismo para que quede claro el sentido de la ruta. Los demás puntos rojos representan los distintos pedidos y su ubicación espacial es la real. La intensidad del rojo de los pedidos indica la proximidad del vencimiento de la ventana de tiempo. Cuanto más oscuro es un punto, más cerca se está de la finalización de su ventana de tiempo. Como podemos ver, la ruta marcada con un círculo en la imagen de la izquierda es la que el sistema decidió que tenía que partir.

32 Visualización Ahora vemos dos gráficos que muestran dos instancias del problema. Lo primero que vemos es que se agregó un nuevo pedido en el extremo inferior medio. Este nuevo pedido, fue luego de varios pasos de optimización agregado a una ruta ya existente. Luego podemos apreciar varios cambios en el sector medio superior. Por un lado se agregaron dos nuevos pedidos y esto hizo que el algoritmo encontrara propicio separar una ruta preexistente y convertirla en dos.

33 Visualización Como último ejemplo de la visualización, volvemos a ver la partida de otra ruta. A medida que el sistema entra en la etapa final de la simulación, o sea cuando dejan de aceptarse nuevos pedidos y solo se aguarda la partida de las últimas motos, iríamos viendo como van desapareciendo las últimas rutas del gráfico hasta que queda solo el depósito.

34 Resultados Comparación con instancias VRP de Solomon
Realizadas al principio del desarrollo Intención: Ver el comportamiento del algoritmo teniendo en cuenta la distancia total de los recorridos Vamos ahora a analizar un poco los resultados obtenidos y tratar de obtener algunas conclusiones al respecto. En esta primera tabla podemos ver una pequeña comparación entre las mejores soluciones para el ruteo de vehículos simple (no dinámica) en instancias de Solomon y las obtenidas por la herramienta. En este caso, comparamos la diferencia en distancias totales entre ambos algoritmos, notando que las mismas varían entre un 6 y un 14%. Al hacer estas comparaciones, que fueron realizadas al principio de la programación, pretendíamos verificar que el algoritmo se comportaba razonablemente bien.

35 Resultados Comparación con instancias de VRPTW
Intención: Ver el comportamiento del algoritmo respecto de las ventanas de tiempo, las políticas de salida de rutas y la cantidad total de rutas empleadas Instancias encontradas solo priorizaban la longitud total de las rutas No nos fue posible encontrar instancias de VRPTW dinámico Luego quisimos hacer comparaciones con instancias del problema de ruteo pero con ventanas de tiempo. Nuestra intención era ver el comportamiento del algoritmo introduciendo las ventanas de tiempo y evaluar las políticas de salida de rutas y la cantidad de rutas empleadas. Sin embargo, no nos fue posible encontrar instancias de VRPTW en las que se analizara estos factores. En todas las instancias encontradas solo se priorizaba la longitud total de las rutas. Con la variante dinámica del problema tuvimos más inconvenientes aún ya que no nos fue posible encontrar instancias del mismo. Esto último nos obligó a generar nuestras propias instancias de prueba que veremos en las próximas diapositivas.

36 Resultados Instancias de prueba generadas en forma aleatoria
Evitar sesgo o error introducido manualmente Uso de distribución uniforme Generación de tres lotes con características propias Decidimos generar las instancias de prueba de manera aleatoria de forma de evitar cualquier sesgo o error que pudiésemos introducir al hacerlas manualmente. Para eso utilizamos una función de distribución uniforme (la provista por el lenguaje de programación) y generamos tres lotes con distintas cantidades de pedidos y mapas de distinto tamaño. El lote A consta de 200 instancias cada una de las cuales tiene 60 pedidos repartidos en una grilla de 50 por 50. El lote B consta de 179 instancias cada una de las cuales tiene 100 pedidos repartidos en una grilla de 100 por 100. El lote C consta de 54 instancias cada una de las cuales tiene 350 pedidos repartidos en una grilla de 100 por 100.

37 Resultados Características generales de los lotes utilizados
Tamaño de los pedidos Mínimo: 15 unidades Máximo: 29 unidades Capacidad de los vehículos 200 unidades Las características más importantes de las instancias generadas son: Que el tamaño de los pedidos oscila entre las 15 y 29 unidades y que la capacidad de los vehículos es de 200 unidades.

38 Resultados Definición de cota
Necesaria para poder tener un valor de referencia con el cual comparar Imposible calcular el valor exacto para las instancias Cota utilizada Cantidad de vehículos necesarios para acomodar todos los pedidos existentes Valor para las instancias: 200 / 22 ≈ 9 pedidos por vehículo Ventajas Simple de calcular Es la mínima cota definible Desventajas Poco realista No tiene en cuenta la distribución espacial ni temporal de los pedidos A partir de estos datos decidimos calcular una cota nos permitiese de alguna forma tener un valor de referencia con el cual comparar. Está claro que calcular el valor exacto para cada instancia no era factible puesto que el análisis exhaustivo de cada instancia podría llegar a demorar mucho tiempo. Por lo tanto, decidimos calcular una cota simple que por lo menos nos diera una cota mínima sobre el valor esperado. Esta cota se calcula asumiendo que todos los pedidos tienen el tamaño promedio de 22 unidades y que es posible poner en cada vehículo, tantos pedidos como queramos sin sobrepasar su capacidad. De esta manera estamos negando el efecto que la espacialidad y temporalidad de los pedidos tiene sobre el resultado. Para los valores elegidos, la cantidad de pedidos que entran en cada vehículo es de 9. Las ventajas que presenta esta cota es que es muy simple de calcular y que es la mínima cota definible (si tomamos como tamaño promedio el promedio del mínimo y máximo posibles). Por otro lado, sus desventajas son que parece ser poco realista ya que no tiene en cuenta la distribución espacial ni temporal de los pedidos.

39 Resultados Lote A 200 instancias de 60 pedidos
Cantidad de rutas mínima según la cota 7 Veamos ahora los resultados obtenidos con el lote A. Este lote constaba de 200 instancias de 60 pedidos cada una y a partir de la cota que habíamos definido, la cantidad de rutas mínima sería de 7.

40 Resultados Lote A Muy pocas instancias se acercan a la cota mínima definida Posibles causas Que la heurística implementada no sea buena para el problema Que la cantidad de pedidos no llegue a negar el efecto de la distribución espacial y temporal (que no es tenida en cuenta por la cota) Que la cota esté demasiado alejada de instancias reales Como pudimos ver recién en el gráfico, muy pocas instancias se acercan a la cota mínima definida. Y la gran mayoría utiliza un 60% más que el mínimo supuesto. Las posibles causas que analizamos para este resultado son: Que la heurística implementada no sea buena para el problema lo cual sería muy malo para nosotros  Que la cantidad de pedidos sea tal que no llegue a negar el efecto de la distribución espacial y temporal y por lo tanto esto haga que se aleje tanto de la cota O que la cota esté demasiado alejada de instancias reales en general

41 Resultados Lote B 179 instancias de 100 pedidos
Cantidad de rutas mínima según la cota 12 Veamos ahora los resultados obtenidos con el lote B. Este lote constaba de 179 instancias de 100 pedidos cada una y a partir de la cota que habíamos definido, la cantidad de rutas mínima sería de 12.

42 Resultados Lote B 30% de los resultados están en el valor de la cota Otro 30% se encuentra una ruta sobre el valor de la cota El resto de las instancias no se alejan mucho más de la cota El algoritmo se comporta de una manera sumamente positiva para estas instancias a diferencia de lo que sucedía con el lote A Estos nos hace descartar que la heurística no sea buena para el problema planteado También nos permite descartar que la cota sea muy mala de por sí Este nuevo gráfico con los resultados, nos muestra que aprox. el 30% de las simulaciones realizadas dieron un valor igual a la cota mínima especificada. Con otro 30% obtuvimos resultados que utilizaban solo 1 ruta más o sea menos de un 10% sobre el mínimo. El resto de las instancias no se aleja mucho más de la cota. Con este lote, podemos ver que el sistema se comporta de manera sumamente positiva a diferencia de lo que pasaba con el Lote A. Estos nos hace descartar que la heurística no sea buena para el problema planteado, ya que en ese caso no sería buena para ningún lote. Y también nos permite descartar que la cota siempre esté alejada de un resultado posible.

43 Resultados Lote C 54 instancias de 350 pedidos
Cantidad de rutas mínima según la cota 39 Por último tenemos el Lote C. Este lote está compuesto de 54 instancias de 350 pedidos cada una y en este caso la cantidad mínima de rutas posibles es de 39.

44 Resultados Lote C El 99% de las resoluciones de las instancias no supera en un 8% el valor de la cota Al igual que el lote B, este lote nos confirma que la cota no es mala en sí misma y que el algoritmo funciona razonablemente bien Para este último lote, el 99% de las resoluciones obtenidas por el sistema se encuentra alejado no más de un 8% del valor de la cota mínima calculada. Lo mismo que el lote B, este nos confirma el hecho de que la cota no es tan mala como nos podría haber hecho suponer el Lote A y que el algoritmo propuesto funciona razonablemente bien.

45 Resultados Análisis de la cantidad de rutas promedio utilizadas
Este último gráfico nos muestra un análisis comparativo entre la cantidad de rutas necesarias para resolver las instancias según nuestra cota y el promedio de rutas utilizadas por el sistema. Se puede ver claramente como a medida que aumenta la cantidad de pedidos, los resultados obtenidos por el sistema tienden a parecerse más a la cota mínima definida.

46 Resultados Este último gráfico muestra que
Bajo las condiciones de prueba, a partir de los 100 pedidos, el espacio desperdiciado en las rutas pasa a ser despreciable El algoritmo se comporta razonablemente bien para instancias que superan este límite de pedidos A partir del gráfico también podemos ver que bajo las condiciones de prueba utilizadas, a partir de los 100 pedidos, el espacio desperdiciado en las rutas pasa a ser prácticamente despreciable y por lo tanto que el algoritmo se comporta razonablemente bien para instancias que superan este límite de pedidos.

47 Conclusiones En base a las pruebas realizadas podemos afirmar que la heurística implementada se comporta razonablemente bien Es capaz de procesar varios cientos de pedidos de manera dinámica y con fuertes restricciones de tiempo de cómputo Tener en cuenta que las simulaciones corrían con una fracción del tiempo real disponible Sería de mucha utilidad en casos reales donde haya una gran cantidad de pedidos a repartir Confirmamos la eficacia de la Búsqueda Tabú para el problema de VRPTW dinámico bajo las condiciones antes mencionadas Para ir cerrando, a manera de conclusiones de todo el trabajo podemos decir que: En base a las pruebas realizadas la implementación de la heurística se comporta razonablemente bien para el problema planteado La misma es capaz de procesar varios cientos de pedidos de manera dinámica y con fuertes restricciones de tiempo de computo. Tengan en cuenta que las simulaciones se corrían con una fracción del tiempo real disponible Creemos que sería de mucha utilidad en casos reales en donde la cantidad de pedidos sea muy alta ya que ayudaría a descomprimir enormemente la tarea de armado de las rutas Y por último podemos decir que confirmamos la eficacia de la Búsqueda Tabú para el problema de VRPTW dinámico planteado por nosotros

48 Trabajos futuros Inclusión de un modelo matemático formal que ayude a comprender mejor el problema Implementación de nuevas técnicas heurísticas para la resolución del problema como submódulos del sistema Desarrollo de una interfaz gráfica que permita interactuar en tiempo real con el sistema Ahora si, concluimos mencionando posibles trabajos futuros que permitirían profundizar y avanzar con el trabajo presentado. Apuntando a la formalización de la heurística, sería interesante plantear un modelo matemático formal para poder comprender mejor algunos aspectos del problema. Desde el punto de vista práctico sería interesante implementar y comparar otras heurísticas para la resolución de este problema, aprovechando la estructura modular del desarrollo realizado. Y por último desde un punto de vista de uso real, sería indispensable el desarrollo de una interfaz gráfica que permita a un operador interactuar con el sistema en tiempo real y poder aprovechar así las ventajas que ofrece.

49 ¡¡ Muchas gracias !! ¿ Preguntas ? Muchas gracias a todos. Preguntas ?