Modelagem de um benchmark para o problema de roteamento de veículos baseado em um caso real de entrega de correspondências na cidade de Artur Nogueira

(1)

UNIVERSIDADE ESTADUAL DE CAMPINAS

Faculdade de Tecnologia

Guilherme Almeida Zeni

Modelagem de um benchmark para o problema de

roteamento de veículos baseado em um caso real de

entrega de correspondências na cidade de Artur Nogueira

Limeira

2020

(2)

Modelagem de um benchmark para o problema de roteamento de

veículos baseado em um caso real de entrega de correspondências na

cidade de Artur Nogueira

Dissertação apresentada à Faculdade de Tecnologia da Universidade Estadual de Campinas como parte dos requisitos para a obtenção do título de Mestre em Tecnologia, na área de Sistemas de Informação e Comunicação.

Orientador: Prof. Dr. Luis Augusto Angelotti Meira

Este exemplar corresponde à versão final da Dissertação defendida por Guilherme Almeida Zeni e orientada pelo Prof. Dr. Luis Augusto Angelotti Meira.

Limeira

2020

(3)

Ficha catalográfica

Universidade Estadual de Campinas Biblioteca da Faculdade de Tecnologia

Felipe de Souza Bueno - CRB 8/8577

Zeni, Guilherme Almeida,

Z43m ZenModelagem de um benchmark para o problema de roteamento de veículos

baseado em um caso real de entrega de correspondências na cidade de Artur Nogueira / Guilherme Almeida Zeni. – Limeira, SP : [s.n.], 2020.

ZenOrientador: Luis Augusto Angelotti Meira.

ZenDissertação (mestrado) – Universidade Estadual de Campinas, Faculdade

de Tecnologia.

Zen1. Problema de roteamento de veículos. 2. Otimização multiobjetivo. 3. Logística. I. Meira, Luis Augusto Angelotti, 1979-. II. Universidade Estadual de Campinas. Faculdade de Tecnologia. III. Título.

Informações para Biblioteca Digital

Título em outro idioma: Modeling a benchmark for the vehicle routing problem based on a real post office deliveries case in the city of Artur Nogueira

Palavras-chave em inglês: Vehicles routing problem Multiobjective optimization Logistics

Área de concentração: Sistemas de Informação e Comunicação Titulação: Mestre em Tecnologia

Banca examinadora:

Luis Augusto Angelotti Meira [Orientador] Anibal Tavares de Azevedo

Guilherme Palermo Coelho Data de defesa: 27-02-2020

Programa de Pós-Graduação: Tecnologia

Identificação e informações acadêmicas do(a) aluno(a)

- ORCID do autor: http://orcid.org/0000-0003-4594-733X - Currículo Lattes do autor: http://lattes.cnpq.br/6861627191463091

(4)

Abaixo se apresentam os membros da comissão julgadora da sessão pública de defesa de dis-sertação para o Título de Mestre em Tecnologia na área de concentração de Sistemas de Infor-mação e Comunicação, a que submeteu o aluno Guilherme Almeida Zeni, em 27 de fevereiro de 2020 na Faculdade de Tecnologia – FT/UNICAMP, em Limeira/SP.

Prof. Dr. Luis Augusto Angelotti Meira Presidente da Comissão Julgadora

Prof. Dr. Anibal Tavares de Azevedo FCA/UNICAMP

Prof. Dr. Guilherme Palermo Coelho FT/UNICAMP

Ata da defesa, assinada pelos membros da Comissão Examinadora, consta no SIGA/Sistema de Fluxo de Dissertação/Tese e na Secretaria de Pós Graduação da FT.

(5)

Simplicidade é uma grande virtude mas requer trabalho duro para alcançá-la e educação para apreciá-la. E o que é pior: a complexidade vende mais.

(6)

Primeiramente, a Deus, agradeço por ter me permitido chegar até aqui.

Aos meus pais, Elio Antonio Zeni e Maria Lúcia de Assis Almeida, que mesmo sem completarem a formação do ensino básico, me ensinaram que estudar era a chave para o sucesso.

Aos meus filhos, Guilhermme Costa Zeni e Gael Costa Zeni, agradeço por toda a motivação e inspiração que me fizeram não desistir. Esse é o meu legado para vocês.

Ao meu amigo, Rafael Sanches Rocha, que conheci no início das aulas do mestrado. Sempre me dando apoio e me direcionando através de seu exemplo de resiliência, contribuiu muito para o meu desenvolvimento pessoal durante nossa vida na pós-graduação.

À minha companheira e amada, Ana Paula Frezzarin, por estar ao meu lado em momentos difíceis, por ter sido plenamente compreensiva em relação ao tempo que dediquei a essa pesquisa, e por me ajudar a revisar esse documento e encontrar erros que puderam ser corrigidos.

Também sou grato a algumas instituições, que foram essenciais para que eu pudesse alcançar meus objetivos: à Collaborate, Innovate and Transform (CI&T) e seus colaboradores, especialmente aos meus amigos de time Anderson Broto Coelho e Maicol Douglas Solera, por terem flexibilizado o meu tempo de trabalho durante o desenvolvimento dessa dissertação; à Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP), por me conceder o computador no qual pude desenvolver a minha pesquisa (sob número de patrimônio 37/002153); à Universidade Estadual de Campinas (UNICAMP), melhor instituição de pesquisa do país atualmente, que cumpriu com todas as expectativas que eu tinha de comprometimento e excelência, e que abriu as portas para o meu desenvolvimento como cidadão, como profissional e como pesquisador; à Faculdade de Tecnologia (FT), por me acolher durante meus quatro anos de graduação e durante esses três últimos anos de mestrado. Os agradecimentos se estendem a todos os docentes e funcionários das três instituições, por contribuírem direta ou indiretamente com a minha formação acadêmica. Também enfatizo a participação do Prof. Dr. Anibal Tavares de Azevedo, da Faculdade de Ciências Aplicadas (FCA), por ter me ensinado preciosos conceitos de otimização com meta-heurísticas, o que tornou parte desse trabalho possível.

Aos Profs. Drs. Marco Antônio Garcia de Carvalho e Guilherme Palermo Coelho por, além de terem sido ótimos professores durante minha graduação e mestrado, terem participado da minha banca de qualificação. Através de indagações valorosas, ambos tiveram uma grande contribuição para o enriquecimento dessa pesquisa.

Finalmente, ao Prof. Dr. Luis Augusto Angelloti Meira, sem o qual toda a minha trajetória através da busca pelo conhecimento nesses anos de dedicação não seriam nada além de um sonho. Meus sinceros agradecimentos a sua personalidade incrível, que faz com que pequenos alunos como eu possam crescer.

(7)

Resumo

O número de técnicas de otimização no domínio combinatório é grande e diversificado. Contudo, existem poucos benchmarks baseados em casos reais para testes de algoritmos. Nessa pesquisa, criamos um benchmark extensível de um caso real de entrega de carteiros para o Problema do Roteamento de Veículos (do inglês Vehicle Routing Problem, VRP) em um grafo planar no espaço euclidiano 2D, utilizando uma nova variante multi-objetivo que desenvolvemos, o VRP de Entregas de Correios (do inglês Post Office Deliveries VRP, PostVRP). Tal problema é um estudo de caso de Sistema de Entrega Inteligente (do inglês Smart Delivery Systems, SDS) multi-objetivo em um mapa de estradas com até 30.000 entregas diárias. Cada instância modela um dia de entrega de correspondência, permitindo comparação e validação de algoritmos de otimização para problemas de roteamento. O benchmarkpode ser estendido para modelar outros cenários.

Palavras-chave: benchmark, roteamento de veículos, otimização em larga escala, otimização multi-objetivo, logística.

(8)

The number of optimization techniques in the combinatorial domain is large and diversified. Nevertheless, real-world based benchmarks for testing algorithms are few. This work creates an extensible real-world mail delivery benchmark to the Vehicle Routing Problem (VRP) in a planar graph embedded in the 2D Euclidean space, using a new variant that we developed, the Post Office Deliveries VRP (PostVRP). Such problem is a multi-objective Smart Delivery System (SDS) case study on a roadmap with up to 30,000 deliveries per day. Each instance models one generic day of mail delivery, allowing both comparison and validation of optimization algorithms for routing problems. The benchmark may be extended to model other scenarios.

Keywords: benchmark, vehicles routing, large scale optimization, multi-objective

(9)

Lista de Figuras

2.1 Solução ótima da instância d15112. Fonte: adaptado de Waterloo (2005). . . 21

2.2 Instância pla33810. Fonte: elaborado pelo autor. . . 21

2.3 Solução ótima da instância pla85900. Fonte: adaptado de Waterloo (2007). . . . 22

2.4 A instância RC207 de Solomon composta de 100 clientes e um depósito com uma solução contendo três rotas (BENT; VAN HENTENRYCK, 2004). A imagem não mostra a capacidade e as restrições de janela temporal. . . 23

3.1 Exemplo de vértices do VRP (esquerda) e uma solução ′ _{= (𝑐} 3, 𝑐5, 𝑐4, 𝑐1, 𝑐2, 𝜋 , 𝑐6, 𝑐10, 𝑐11, 𝑐12, 𝜋 , 𝑐7, 𝑐8, 𝑐9, 𝑐13) (direita). Fonte: elaborado pelo autor. . . 26

3.2 Uma seção do mapa da cidade (esquerda). Arestas e vértices criados sobre o mapa da cidade (direita). Fonte: elaborado pelo autor. . . 28

3.3 O custo entre duas entregas 𝑑𝑎 e 𝑑𝑏, localizados em arestas distintas 𝑒𝑎 e 𝑒𝑏, respectivamente. Fonte: elaborado pelo autor. . . 30

3.4 Exemplo de um arquivo model. Fonte: elaborado pelo autor. . . 31

3.5 Mapa baseado no modelo da Figura 3.4. Fonte: elaborado pelo autor. . . 32

3.6 Modelando segmentos sem entrega. Fonte: elaborado pelo autor. . . 32

3.7 Instâncias resultantes de 10, 100, 1.000, e 10.000 entregas. Fonte: elaborado pelo autor. . . 33

3.8 Solução para uma instância com 10 entregas. Fonte: elaborado pelo autor. . . . 34

3.9 Seção do mapa original. Fonte: Google Maps. . . 34

3.10 Arquivo model.txt de Manhattan. Fonte: elaborado pelo autor. . . 35

3.11 Mapa original de Artur Nogueira. . . 37

3.12 Ilustração de uma troca por arestas. Fonte: elaborado pelo autor. . . 40

3.13 Ilustração de uma troca por vértices. Fonte: elaborado pelo autor. . . 40

3.14 Lista tabu, contendo 10 pares. Fonte: elaborado pelo autor. . . 44

4.1 Uma instância com 1.000 pontos de entrega. O vértice de maior tamanho, destacado na cor verde, representa o depósito. . . 50

4.2 Uma instância gerada com 10.000 pontos de entrega. . . 52

4.3 Média dos comprimentos de rota encontrados pelos algoritmos. . . 54

4.4 Diferença do comprimento de rota entre a melhor e a pior solução encontrada em todas as instâncias. . . 55

4.5 Comprimento de rota menor e maior, encontrados em cada instância. . . 56

4.6 Comparando a quantidade de rotas menores e maiores do que a média com a quantidade de rotas melhores e piores, respectivamente, para cada instância. . 57

4.7 Solução das instâncias 𝑅𝑒𝑎𝑙𝑊𝑜𝑟𝑙𝑑𝑃𝑜𝑠𝑡𝑇𝑜𝑦 3_0, 5_0, 10_0, 20_0, e 50_0, com 1 veículo e injustiça inexistente. . . 58

(10)

injustiça, obtida por um algoritmo TS com troca de arestas 2-Opt. O custo total foi de 23.303,06, com 2 veículos e injustiça praticamente inexistente, muito próxima a 0h. . . 60 4.9 Imagem ao topo: melhor comprimento de rota, obtido por um algoritmo

Recozimento Simulado (SA) com troca de arestas 2-Opt. O custo total foi de 32.741,07, com 2 veículos e injustiça entre eles de aproximadamente 1,3h. Imagem ao fundo: melhor injustiça, obtida por um algoritmo Busca Tabu (TS) com troca de vértices 2-Troca. O custo total foi de 34.039,47, com 2 veículos e

variância entre eles de aproximadamente 0,05h. (Instância

RealWorldPostToy_200_0). . . 61 4.10 Imagem ao topo: melhor comprimento de rota, obtido por um algoritmo AG

com troca de arestas 2-Opt. O custo total foi de 50.921,27, com 3 veículos e injustiça entre eles de aproximadamente 1,5h. Imagem ao fundo: melhor injustiça, obtida por um algoritmo ILS com troca de vértices 2-Troca. O custo total foi de 52.537,24, com 3 veículos e variância entre eles de aproximadamente 0,1h. (Instância RealWorldPostToy_500_0). . . 62 4.11 Imagem ao topo: melhor comprimento de rota, obtido por um algoritmo Busca

Local Iterada (ILS) com troca de arestas 2-Opt. O custo total foi de 69.511,11, com 4 veículos e injustiça entre eles de aproximadamente 0,6h. Imagem ao fundo: melhor injustiça, obtida por um algoritmo HG com troca de arestas 2-Opt. O custo total foi de 80.978,77, com 4 veículos e variância entre eles de aproximadamente 0,07h. (Instância RealWorldPostToy_1000_0). . . 63 B.1 Melhor solução encontrada para o RealWorldPostToy_3_0, considerando o

comprimento de rota. . . 75 B.2 Melhor solução encontrada para o RealWorldPostToy_5_0, considerando o

(11)

Lista de Tabelas

2.1 Instâncias do TSPLib. . . 20

3.1 Arquivo de instância. . . 32

3.2 Atributo, nível e valores das penalidades. . . 36

3.3 Analogia entre o recozimento na natureza e o algoritmo SA (SIMON, 2013). A tabela original do autor não contempla Energia, Recristalização, e Estado de Equilíbrio. . . 42

4.1 Descrição das instâncias RWPostVRPB. O Apêndice A.2 lista detalhadamente todas as instâncias do RWPostVRPB. . . 51

4.2 Testes executados. . . 53

4.3 Convergência dos algoritmos nas três instâncias menores. . . 55

4.4 As melhores soluções encontradas. O Apêndice B contém o tour das melhores soluções para todas as instâncias. . . 59

4.5 Soluções com o menor fator de injustiça. . . 59

A.1 Todas as instâncias do Manhattan. . . 71

(12)

1 Algoritmo para criar as entregas. . . 29

2 Construção de uma solução inicial aleatória. . . 39

3 Construção de uma solução inicial gulosa. . . 39

4 Troca por arestas. . . 41

5 Troca por vértices. . . 41

6 Simulated Annealing. . . 43

7 Busca Tabu com memória de curta-duração. . . 45

8 GRASP. . . 46

9 GRASP, fase de construção gulosa-aleatória. . . 46

10 GRASP, geração da LRC. . . 47

(13)

Lista de Abreviações e Siglas

AG Algoritmo Genético

BCO Bee Colony Optimization

CARP-RP Capacitated Arc Routing Problem with Refill Points

CVRP Capacitated Vehicle Routing Problem

FIFO First-In, First-Out

GRASP Greedy Randomized Adaptative Search Procedure

HCP Hamiltonian Cycle Problem

HG Heurística Gulosa

ILS Iterated Local Search

LRC Lista Restrita de Candidatos

LS Local Search

MDVRP Multi-Depot Vehicle Routing Problem

PCI Placa de Circuito Impresso

PostVRP Post Office Deliveries Vehicle Routing Problem

RWPostVRPB Real World Post Office Deliveries Vehicle Routing Problem Benchmark

SA Simulated Annealing

SDS Smart Delivery System

SINTEF Stiftelsen for INdustriell og TEknisk Forskning

SOP Sequential Ordered Problem

TDP Truck Dispatching Problem

TS Tabu Search

TSP Traveling Salesman Problem

VLSI Very Large-Scale Integration

VRP Vehicle Routing Problem

(14)

∈ Pertence a

ℝ2 Conjunto dos números reais em duas dimensões

𝑆 Conjunto de elementos

𝜋 Depósito

𝐶 Conjunto de clientes

𝑛 Número de clientes

𝑘 Número de veículos

ℕ Conjunto dos números naturais

𝑤 Custo entre par de elementos

 Uma solução para o VRP

 Rota percorrida por um veículo 𝑘

∑ Somatório

𝑊 Custo (ou comprimento) total de uma rota ou de uma solução

𝑓1 Primeira função-objetivo

𝑓2 Segunda função-objetivo

𝑓3 Terceira função-objetivo

𝑚𝑎𝑥 Comprimento de rota máximo

𝑆𝑡 Rua

𝑃 Cadeia poligonal

𝑐 Coordenada planar

 Conjunto de cadeias poligonais

𝐺 Grafo

𝑉 Conjunto de vértices

(15)

𝑣 Vértice

𝑒 Aresta

𝑤𝑡ℎ Largura da rua

ℝ+ Conjunto dos números reais positivos

𝐷 Densidade de probabilidade não normalizada

𝑃 𝑟𝑜𝑏 Probabilidade

𝑇 Somatório do produto densidade da rua × custo total das arestas da rua

𝑑 Uma entrega

𝑙𝑜𝑐 Local de uma dada entrega

𝐷𝑒𝑙 Conjunto de entregas

𝛼 Valor gerado aleatoriamente, entre 0 e 1

𝛽 Constante real e positiva de um custo fixo adicional por entrega

∅ Conjunto vazio

∪ União

𝑤𝑛×𝑛 Matriz que representa uma instância

𝑇∗ Temperatura

𝑇_𝑚𝑖𝑛∗ Temperatura mínima

Δ𝐸 Variação de energia do sistema

𝑒𝑥𝑝(𝑥) Função exponencial natural

𝛼∗ Taxa de resfriamento

𝑝 Capacidade máxima de soluções da lista tabu

𝛼∗∗ Número de candidatos em uma LRC

𝑂 Limite assintótico superior

(16)

1 Introdução 17

1.1 Contribuição . . . 18

2 Levantamento bibliográfico 19 3 Metodologia 25 3.1 Definindo a variante PostVRP . . . 25

3.2 Descrição do modelo . . . 27

3.2.1 Gerando os pontos de entrega . . . 28

3.2.2 Estabelecendo o custo entre um par de entregas . . . 29

3.3 A ferramenta para o benchmark . . . 30

3.3.1 Gerando um benchmark piloto . . . 33

3.3.2 Gerando um benchmark real . . . 34

3.4 Processo de Otimização . . . 38

3.4.1 Construção de uma Solução Inicial . . . 38

3.4.2 Mecanismos de Troca . . . 40

3.5 Busca Local, Busca Local Iterada, e Heurística Gulosa . . . 41

3.6 Simulated Annealing . . . 41

3.7 Busca Tabu . . . 44

3.8 Greedy Randomized Adaptive Search Procedure . . . 45

3.9 Algoritmo Genético . . . 47

4 Resultados 49 4.1 Manhattan pilot benchmark . . . 49

4.2 Real-world PostVRP benchmark . . . 50

4.3 Testes Experimentais de Otimização . . . 53

4.4 Convergência dos Algoritmos . . . 55

4.5 Comprimento de rota versus injustiça . . . 58

5 Conclusões 64

Referências bibliográficas 66

A Instâncias Geradas 71

(17)

17

Capítulo 1

Introdução

Benchmarkssão encontrados em diversos campos da ciência, como geologia (CORREIA et al., 2015), economia (JORION, 1997), e climatologia (TOL, 2002), entre outras áreas. Eles possuem um papel central em ciência da computação, por exemplo, em processamento de imagens (BUF; KARDAN; SPANN, 1990; KRIZHEVSKY; SUTSKEVER; HINTON, 2012; HUANG et al., 2007), performance de hardware (CHE et al., 2009), e otimização (REINELT, 1991; KOLISCH; SPRECHER, 1997; BURKARD; KARISCH; RENDL, 1997).

No contexto de otimização, Johnson (2002) divide a análise de algoritmos em três abordagens: de pior caso; de caso médio; e a análise experimental. A respeito de trabalhos experimentais, ele identifica quatro casos: (i) solucionar problemas reais; (ii) fornecer a evidência de que um algoritmo é superior a outros; (iii) melhor entendimento de um problema; e (iv) estudar o caso médio. Ele propõe o uso de benchmarks bem estabelecidos para fornecer evidência da superioridade de um algoritmo (item ii). Tais artigos são conhecidos como artigos de corrida de cavalos.

Johnson (2002) aponta que reprodutibilidade e comparabilidade são aspectos essenciais de qualquer artigo experimental. Ele também defende o uso de instâncias que permitam conclusões gerais. O autor menciona a dificuldade em justificar experimentos em problemas sem nenhuma aplicação direta. Tais problemas não possuem instâncias reais e o pesquisador é forçado a gerar dados no vácuo.

Nosso trabalho lida com uma nova variante do VRP baseada em um caso real de entrega de correspondências na cidade de Artur Nogueira, interior do Estado de São Paulo, Brasil. A agência de correios recebe milhares de correspondências que devem ser entregues diariamente. Cada correspondência é atribuída a um conjunto de 15 a 25 carteiros pedestres, responsáveis

(18)

por fazer a distribuição aos clientes. Cada carteiro é modelado como um veículo e cada ponto de entrega é um cliente. Denominamos o problema aqui como PostVRP, uma variante multi-objetivo do VRP com restrição de distância.

Especialistas indicam que o PostVRP possui três funções-objetivo principais a serem minimizadas (enquanto mantém a factibilidade das soluções): (i) comprimento da rota; (ii) número de carteiros; e (iii) injustiça, medido como a variância da carga de trabalho (isto é, o comprimento da rota) entre os carteiros.

O PostVRP considera veículos não-capacitados e comprimento de rota restrita. Cada carteiro pode carregar uma carga máxima de 8 a 10 kg. Um caminhão de suporte reabastece os carteiros tornando suas capacidades ilimitadas. Cada carteiro deve seguir uma jornada diária de trabalho de 6 a 8 horas, o que implica em uma capacidade máxima para o comprimento da rota.

Um comprimento de rota limitado é uma restrição que pode ser verificada em diferentes cenários de casos reais: um helicóptero tem um comprimento de rota limitado pela capacidade de seu tanque de combustível; o limite de um drone para sobrevoar as residências depende da duração de sua carga elétrica; os trabalhadores, em geral, possuem uma janela de tempo para operar um veículo, o que portanto limita o comprimento da rota.

1.1 Contribuição

Este trabalho apresenta um estudo de caso cujo modelo é baseado em uma cidade brasileira localizada em 22°34′₂₂′′_𝑆47°10′₂₂′′_{𝑊 . O benchmark proposto contém até 30.000 clientes. Nós}

disponibilizamos uma ferramenta de benchmark para que seja possível criar novas instâncias arbitrariamente grandes. A metodologia pode ser aplicada a outras cidades assim como a outras variantes do VRP (MEIRA, L. A. et al., 2020).

(19)

19

Capítulo 2

Levantamento bibliográfico

Uma das primeiras referências ao VRP aparece no trabalho de Dantzig e Ramser (1959), sob o nome de Problema de Despacho de Caminhões (do inglês Truck Dispatching Problem, TDP), uma generalização do Problema do Caixeiro Viajante (do inglês Traveling Salesman Problem, TSP). O termo VRP foi visto pela primeira vez no artigo de Christofides (1976). Christofides define o VRP como um nome genérico, dado a uma classe de problemas que envolvem a visita de “clientes” utilizando veículos.

Aspectos do mundo real podem impor variantes ao problema. Por exemplo, o

VRP-Capacitado (do inglês Capacitated-VRP, CVRP) considera um limite para a capacidade do veículo (FUKASAWA et al., 2006), o VRP com Janela Temporal (do inglês VRP with Time Windows, VRPTW) estabelece um limite de tempo na entrega das demandas (KALLEHAUGE et al., 2005), e o VRP com Múltiplos Depósitos (do inglês Multi-Depot VRP, MDVRP) estende o número de depósitos (RENAUD; LAPORTE; BOCTOR, 1996).

Jozefowiez, Semet e Talbi (2008) expandiram a pesquisa existente relacionada à otimização multi-objetivo aos problemas de roteamento. Amaya, Langevin e Trépanier (2007) introduziram o Problema de Roteamento em Arcos Capacitados com Pontos de Reabastecimento (do inglês Capacitated Arc Routing Problem with Refill Points, CARP-RP), onde os veículos devem ser reabastecidos através do uso de um segundo veículo. Gussmagg-Pfliegl et al. (2011) criaram heurísticas para um problema real de entrega de correspondência. Quatro veículos distintos foram considerados: o carro; o ciclomotor (um tipo de bicicleta motorizada); a bicicleta; e o pedestre. Outras variantes VRP podem ser facilmente encontradas na literatura.

(20)

Reinelt (1991) criou um benchmark para o TSP conhecido como TSPLib. Em seu trabalho, ele consolidou instâncias não resolvidas de 20 artigos distintos. Seu repositório, chamado TSPLIB95 (REINELT, 1995), possui instâncias de ambos os problemas do caixeiro viajante simétrico e assimétrico (TSP/aTSP) assim como três problemas relacionados: (i) o CVRP; (ii) o Problema da Ordenação Sequencial (do inglês Sequential Ordered Problem, SOP); e (iii) o Problema do Ciclo Hamiltoniano (do inglês Hamiltonian Cycle Problem, HCP). A Tabela 2.1 mostra a quantidade e tamanho das instâncias para cada problema.

Tabela 2.1: Instâncias do TSPLib.

Problema # Instâncias # Vértices

TSP 113 14 até 85.900

aTSP 19 17 até 443

CVRP 16 7 até 262

SOP 41 7 até 378

HCP 9 1.000 até 5.000

A solução ótima de todas as instâncias do TSPLib foram finalmente obtidas em 2006, após 15 anos de um progresso notável no desenvolvimento de algoritmos. O ótimo da instância

d15112 foi encontrado em 2001 (APPLEGATE et al., 2006). Essa instância contém 15.112

cidades da Alemanha (Figura 2.1) e foram precisos 22,6 anos de processamento computacional, divididos entre 110 processadores de 500 MHz (COOK, 2016). A instância pla33810foi resolvida em março de 2004 (APPLEGATE et al., 2006). Ela representa uma Placa de Circuito Impresso (PCI) com 33.810 nós (Figura 2.2), e foi resolvida em 15,7 anos de processamento (ESPINOZA, 2006). A última instância do TSPLib, chamada pla85900, foi resolvida entre os anos de 2005 e 2006 (APPLEGATE et al., 2006). Essa instância contém 85.900 nós representando uma aplicação de Integração em Escala Muito Grande (do inglês Very Large-Scale Integration, VLSI) (Figura 2.3).

Solomon (1987) criou um benchmark para o VRPTW, composto de 56 instâncias particionadas em seis conjuntos: R1, C1, RC1, R2, C2, e RC2. Os conjuntos R1 e R2 representam dados gerados aleatoriamente através de uma distribuição uniforme; os conjuntos C1 e C2 representam dados gerados através de clusterizações; e os conjuntos RC1 e RC2 representam a geração de dados semi-clusterizados, isto é, uma mistura de estruturas aleatórias e agrupadas. O número de clientes é igual a 100 em todas as instâncias. O veículo

(21)

Capítulo 2. Levantamento bibliográfico 21

Figura 2.1: Solução ótima da instância d15112. Fonte: adaptado de Waterloo (2005).

(22)

Figura 2.3: Solução ótima da instância pla85900. Fonte: adaptado de Waterloo (2007). tem uma capacidade fixa e os clientes têm uma demanda representada por inteiros. O número de veículos não é fixo: deriva do fato de que a capacidade é limitada. Sob esse ponto de vista, o problema pode ser considerado multi-objetivo, pois visa minimizar a rota e o número de veículos.

A primeira solução ótima do benchmark de Solomon (1987) foi publicada por Kohl et al. (1999). Chabrier (2006) resolveu 17 instâncias em aberto no benchmark. Amini, Javanshir e Tavakkoli-Moghaddam (2010) alcançaram soluções muito próximas do ótimo, considerando somente os primeiros 25 clientes. Em julho de 2015, 28 anos após o lançamento do benchmark, Jawarneh e Abdullah (2015) publicaram uma meta-heurística conhecida como Otimização de Colônia de Abelhas (do inglês Bee Colony Optimization, BCO). Tal algoritmo alcançou 11 novos melhores resultados nas instâncias estendidas do VRPTW de Solomon. É surpreendente que instâncias tão pequenas apresentem uma estrutura interna tão complexa para ser otimizada. A Figura 2.4 mostra uma instância de Solomon composta de 100 clientes e uma dada solução considerando três veículos.

Apesar de suas complexidades, os benchmarks TSPLib e de Solomon possuem um número de clientes entre 100 e 262 para o VRP, o que é um valor pequeno atualmente. Gehring e Homberger (1999) estenderam as instâncias de Solomon, criando então um benchmark para o VRPTW com o número de clientes variando entre 100 e 1.000.

(23)

Capítulo 2. Levantamento bibliográfico 23

Figura 2.4: A instância RC207 de Solomon composta de 100 clientes e um depósito com uma solução contendo três rotas (BENT; VAN HENTENRYCK, 2004). A imagem não mostra a capacidade e as restrições de janela temporal.

Nguyen et al. (2007) propuseram um Algoritmo Genético (AG) para otimizar o desafio World TSP. O desafio é caracterizado por uma instância TSP com 1.904.711 locais espalhados por todas as partes do mundo. Cada local é especificado por sua latitude e longitude.

Para o CVRP, o ABEFMP é um conjunto de instâncias amplamente utilizado, no qual Augerat et al. (1995) propuseram as classes A, B, P, e Christofides e Eilon (1969), Fisher (1994) e Christofides (1979) propuseram as classes E, F, M, respectivamente. Em seus benchmarks, o número de clientes varia de 13 até 200, e o número de veículos varia de 2 até 17.

Fukasawa et al. (2006) e Contardo e Martinelli (2014), entre outros, obtiveram o ótimo em diferentes instâncias do ABEFMP. Pecin et al. (2014) encontraram a solução ótima para a última instância não resolvida, chamada M-n151-k12, 35 anos após sua apresentação por Christofides (1979). Apesar disso, a maioria dessas instâncias são bem simples de se resolver nos dias de hoje.

Bruce L Golden et al. (1998) propuseram novas instâncias para o CVRP. O conjunto totaliza 20 instâncias, com o número de clientes variando de 240 até 483. Esse benchmark permanece interessante, pois a maioria de suas instâncias ainda não possuem um ótimo

estabelecido (UCHOA; PECIN; PESSOA; POGGI; SUBRAMANIAN et al., 2017). Li,

Bruce Golden e Wasil (2005) criaram um conjunto de instâncias com o número de clientes entre 560 e 1.200. Atualmente, não há um ótimo definido para nenhuma dessas instâncias (UCHOA; PECIN; PESSOA; POGGI; SUBRAMANIAN et al., 2017).

(24)

Uchoa, Pecin, Pessoa, Poggi, Subramanian et al. (2017) criaram o CVRPLib, onde consolidaram as instâncias CVRP de Augerat et al. (1995), Christofides e Eilon (1969), Christofides (1979), Fisher (1994), Bruce L Golden et al. (1998) e Li, Bruce Golden e Wasil (2005). Além disso, Uchoa, Pecin, Pessoa, Poggi, Vidal et al. (2017) geraram novas instâncias com o número de clientes entre 100 e 1.000. Os trabalhos deles indicam a falta de benchmarks desafiadores bem estabelecidos para o VRP.

Uchoa, Pecin, Pessoa, Poggi, Vidal et al. (2017) também destacam o fato de benchmarks serem artificialmente criados. Solomon (1987) e Uchoa, Pecin, Pessoa, Poggi, Vidal et al. (2017) geraram suas próprias instâncias através de pontos aleatórios. No benchmark ABEFMP, algumas das instâncias geradas são aleatórias e outras instâncias representam problemas reais. Porém, em todas as instâncias, os clientes são pontos no espaço euclidiano. As instâncias de Bruce L Golden et al. (1998) e de Li, Bruce Golden e Wasil (2005) também são artificiais.

Cwiek, Nalepa e Dublanski (2016) criaram um gerador de benchmark heurístico para o VRPTW. Cada entrega é dada por (𝑥𝑖, 𝑦𝑖) ∈ ℝ2, e a distância entre duas entregas é a métrica

Manhattan 𝑐𝑖𝑗 = |𝑥𝑖 − 𝑥𝑗| + |𝑦𝑖 − 𝑦𝑗|. Kytöjoki et al. (2007) criaram instâncias artificiais com

até 20.000 clientes e instâncias reais com até 12.000 clientes. Ambos os grupos de instâncias foram modelados como CVRP e o grupo de instâncias reais foi baseado em um cenário de coleta de resíduos na Finlândia Oriental. Tais instâncias foram criadas para validar uma meta-heurística que eles desenvolveram para resolver problemas realísticos de roteamento em larga escala. Essa é provavelmente a maior instância VRP encontrada na literatura.

O website SINTEF (do norueguês Stiftelsen for INdustriell og TEknisk Forskning) contém os resultados das melhores soluções encontradas para benchmarks padrões de diversas variantes

(25)

25

Capítulo 3

Metodologia

Neste capítulo, descreveremos todas as etapas do desenvolvimento dessa pesquisa. O desenvolvimento pode ser dividido em duas partes: a criação do benchmark; e a otimização das instâncias. Na Seção 3.1, introduzimos uma nova variante para o VRP, o PostVRP. Na Seção 3.2, fazemos a modelagem das ruas e dos pontos de entrega. Na Seção 3.3, produzimos uma ferramenta capaz de gerar benchmarks para o PostVRP e aplicamos o método necessário para criar um benchmark piloto e um benchmark oficial através da nova ferramenta. As seções restantes (3.4 a 3.9) são dedicadas à implementação dos algoritmos através de heurísticas e de meta-heurísticas.

3.1 Definindo a variante PostVRP

Considere um conjunto de elementos 𝑆 onde o depósito é um elemento especial 𝜋 ∈ 𝑆. Este trabalho não lida com múltiplos depósitos no VRP. O conjunto de clientes é definido por 𝐶 = 𝑆 ⧵ {𝜋 }, e o número de clientes é denotado por 𝑛, onde 𝐶 = {𝑐1, … , 𝑐𝑛}. O número de

veículos na frota é representado por 𝑘 ∈ ℕ. O valor 𝑘 é tradicionalmente considerado uma constante, mas é possível definir variantes do VRP onde 𝑘 é variável. Seja 𝑤 ∶ 𝑆 × 𝑆 → ℕ o custo entre dois elementos quaisquer em 𝑆. Considere (𝐶, 𝑘) = (𝑐1, … , 𝑐𝑛, 𝜋 , … , 𝜋 ). Essa

sequência é criada da seguinte forma: (i) todos os elementos em 𝐶 são inseridos em ; (ii) o vértice do depósito é inserido 𝑘 − 1 vezes.

Cada permutação de (𝐶, 𝑘) representa uma solução para o VRP. Por exemplo, considere o grafo e os vértices descritos na Figura 3.1, e suponha que o número de veículos seja três (isto

(26)

é, 𝑘 = 3). A sequência (𝐶, 3) é dada por (𝐶, 3) = (𝑐1, … , 𝑐13, 𝜋 , 𝜋 ). Uma possível solução seria

a permutação ′

= (𝑐3, 𝑐5, 𝑐4, 𝑐1, 𝑐2, 𝜋 , 𝑐6, 𝑐10, 𝑐11, 𝑐12, 𝜋 , 𝑐7, 𝑐8, 𝑐9, 𝑐13). Após isso, são inseriodos k − 1 vezes o vértices depósito. Se o conjunto de clientes C e o número de veículos k estiverem claros no contexto, poderemos usar S para represnetar S(C, k).

Cada permutação de S representa uma solução do VRP. Para exemplificar, considere o grafo abaixo: c1 c2 c3 c4 c5 c6 c7 c8 c9 c10 c11 c12 c13 π

Figura 4: Exemplo de Intância do VRP

Considere os vértices da descritos na Figura4. Considere o número de veículos igual a 3, ou seja k = 3. A sequência S(C, 3) neste caso seria:

S(C, 3) = (c1, . . . , c13, π, π).

Cada permutação de S(C, 3) representa uma solução para o VRP. Por exemplo, a permutação

S′_{= (c}

3, c5, c4, c1, c2, π, c6, c10, c11, c12, π, c7, c8, c9, c13)

representa a solução descrita na Figura5 9 c1 c2 c3 c4 c5 c6 c7 c8 c9 c10 c11 c12 c13 π Figura 5: Solução S′_{= (c}₃_{, c}₅_{, c}₄_{, c}₁_{, c}₂_{, π, c}₆_{, c}₁₀_{, c}₁₁_{, c}₁₂_{, π, c}₇_{, c}₈_{, c}₉_{, c}₁₃_).

Toda rota inicia e termina no depósito. A solução S′_{representa uma partição dos clientes em 3} rotas: R1= (c3, c5, c4, c1, c2), R2= (c6, c10, c11, c12)e R3= (c7, c8, c9, c13). Mais formalmente, uma solução pode ser particionada em diversas rotas

P articao(S) = (R1, . . . ,Rk)

onde a partição da solução é feita no depósito π. No exemplo da Figura5temos que

P articao(S′_{) = ({c}

3, c5, c4, c1, c2} , {c6, c10, c11, c12} , {c7, c8, c9, c13}) .

O comprimento de uma rota R = (r1, . . . , rm)é dado por:

W (R) = w(π, r1) + w(rm, π) + m−1_!

i=1

w(ri, ri+1)

10

Figura 3.1: Exemplo de vértices do VRP (esquerda) e uma solução ′ ₌

(𝑐3, 𝑐5, 𝑐4, 𝑐1, 𝑐2, 𝜋 , 𝑐6, 𝑐10, 𝑐11, 𝑐12, 𝜋 , 𝑐7, 𝑐8, 𝑐9, 𝑐13) (direita). Fonte: elaborado pelo autor.

Todas as rotas começam e terminam no depósito. A solução ′ representa uma partição

de clientes em três rotas: 1 = (𝑐3, 𝑐5, 𝑐4, 𝑐1, 𝑐2), 2 = (𝑐6, 𝑐10, 𝑐11, 𝑐12) e 3 = (𝑐7, 𝑐8, 𝑐9, 𝑐13). O

vértice 𝜋 é utilizado para criar uma partição da sequência em 𝑘′ _{≤ 𝑘 rotas. Considere}

𝑃 𝑎𝑟 𝑡𝑖ç ̃𝑎𝑜() = (1, … , 𝑘′). Por definição, rotas vazias não fazem parte da 𝑃 𝑎𝑟 𝑡𝑖ç ̃𝑎𝑜().

Portanto, 𝑃𝑎𝑟𝑡𝑖ç ̃𝑎𝑜(1, 2, 𝜋, 𝜋, 3, 4) é {(1, 2), (3, 4)} e não {(1, 2), (), (3, 4)}, isto é, 𝑘′ _{≤ 𝑘.}

O comprimento de uma rota  = (𝑟1, … , 𝑟𝑚) é dado por:

𝑊 () = 𝑤(𝜋 , 𝑟1) + 𝑤(𝑟𝑚, 𝜋 ) + 𝑚−1

∑

𝑖=1

𝑤(𝑟𝑖, 𝑟𝑖+1). (3.1)

O comprimento de uma solução  é a distância de todo o trajeto e é calculado por:

𝑊 () = ∑

∈𝑃𝑎𝑟𝑡𝑖ç ̃𝑎𝑜()

𝑊 (). (3.2)

O número de veículos utilizados em uma dada solução é igual ao número de rotas não vazias, ou seja, |𝑃𝑎𝑟𝑡𝑖ç ̃𝑎𝑜()|. Se o número de veículos for 𝑘 e rotas não vazias são permitidas, então nós teremos a restrição |𝑃𝑎𝑟𝑡𝑖ç ̃𝑎𝑜()| = 𝑘. Se o número de veículos for no máximo 𝑘, ou se rotas vazias são permitidas, nós teremos |𝑃𝑎𝑟𝑡𝑖ç ̃𝑎𝑜()| ≤ 𝑘. Se o número de veículos não for parte da entrada, então o domínio poderá ser dado pela permutação da sequência (𝐶, 𝑛). Nesse caso, o número de veículos será definido durante a etapa de otimização.

(27)

Capítulo 3. Metodologia 27 Dada uma solução factível, é necessário calcular o seu custo. A função-objetivo mais comum a ser minimizada é o comprimento da solução:

𝑓1() = 𝑊 (). (3.3)

Uma outra função-objetivo consiste em achar uma solução factível que otimize o número de veículos:

𝑓2() = |𝑃 𝑎𝑟 𝑡𝑖ç ̃𝑎𝑜()|. (3.4)

Finalmente, é necessário que a solução atenda a um critério de justiça, isto é, as rotas devem ser distribuídas de tal forma que a carga de trabalho (comprimento da rota) seja balanceada entre os veículos. Nós modelamos a injustiça através da minimização da variância dos comprimentos de rota:

𝑓3() = √ ∑ ∈𝑃𝑎𝑟𝑡𝑖ç ̃𝑎𝑜() (𝑊 () − 𝑊 ()) 2 |𝑃 𝑎𝑟 𝑡𝑖ç ̃𝑎𝑜()| − 1 . (3.5)

O VRP é um conjunto de problemas que consiste na visita de clientes através de veículos. Cada variante tem restrições de factibilidade adicionais, como a proibição de rotas vazias (|𝑃𝑎𝑟𝑡𝑖ç ̃𝑎𝑜()| = 𝑘). O PostVRP assume que o comprimento da rota é limitado. Seja 𝑚𝑎𝑥 o

comprimento de rota máximo permitido, isto é, 𝑊 () ≤ 𝑚𝑎𝑥.

Definição 1 (PostVRP) . Dado um conjunto de elementos 𝑆, uma função de custo 𝑤 ∶ 𝑆 × 𝑆 → ℕ, uma constante 𝑘 ∈ ℕ que representa o número máximo de veículos, um vértice especial 𝜋 ∈ 𝑆 e um comprimento de rota máximo𝑚𝑎𝑥 ∈ ℕ. Seja 𝐶 ← 𝑆 ⧵ {𝜋 }. Considere a sequência (𝐶, 𝑘),

e seja 𝑃𝑒 o conjunto de todas as permutações factíveis de (𝐶, 𝑘), respeitando 𝑚𝑎𝑥. O problema

PostVRP consiste em minimizar (𝑓1(), 𝑓2(), 𝑓3()) sujeitos à  ∈ 𝑃 𝑒.

3.2 Descrição do modelo

Nós iniciamos o processo de criação do benchmark através do mapeamento de cada rua em um grafo. Cada rua 𝑆𝑡 é modelada como uma cadeia poligonal 𝑃, que é definida como um conjunto de coordenadas planares, tal que 𝑃 = (𝑐1, … , 𝑐𝑛′), onde 𝑐 ∈ ℝ2para todo 𝑐 ∈ 𝑃. O grafo do mapa

(28)

Então criamos o grafo 𝐺(𝑉 , 𝐸) a partir de . Cada vértice 𝑣 ∈ 𝑉 está associado com uma coordenada cartesiana (𝑥𝑣, 𝑦𝑣) ∈ ℝ2e cada aresta 𝑒 = (𝑢, 𝑣) é um segmento de reta entre 𝑢 e

𝑣. O custo da aresta é 𝑤′(𝑒) =√(𝑥𝑢 − 𝑥𝑣)2+ (𝑦𝑢 − 𝑦𝑣)2. Os vértices associados com as esquinas

são construídos automaticamente por um algoritmo de intersecção de segmento de reta. A Figura 3.2 mostra as ruas simples modeladas como uma única cadeia poligonal, enquanto as ruas com ilhas são modeladas por duas cadeias poligonais. Segmentos de reta adicionais são colocados para permitir os atalhos pelos pedestres.

Figura 3.2: Uma seção do mapa da cidade (esquerda). Arestas e vértices criados sobre o mapa da cidade (direita). Fonte: elaborado pelo autor.

Dado uma aresta 𝑒, sua rua é denotada por 𝑆𝑡(𝑒). Cada rua 𝑆𝑡 tem uma largura arbitrariamente definida 𝑤𝑡ℎ(𝑆𝑡) ∈ ℝ+, que representa o custo de atravessar a rua. O valor

𝑤𝑡ℎ(𝑆𝑡) pode ser definido como zero, assim resultando em nenhum custo para atravessar a rua.

Uma densidade de probabilidade não normalizada 𝐷(𝑆𝑡) é atribuída a cada rua. A probabilidade de uma rua receber uma carga de trabalho de entrega por unidade de comprimento é diretamente proporcional ao valor da densidade 𝐷. Esse valor é utilizado para criar uma rua central com uma grande carga de trabalho comparada a uma rua distante. As probabilidades são descritas na próxima subseção.

3.2.1 Gerando os pontos de entrega

Considere um grafo do mapa das ruas 𝐺(𝑉 , 𝐸). A probabilidade de uma entrega ser associada a uma aresta 𝑒, indicada por 𝑃𝑟𝑜𝑏(𝑒), é:

𝑃 𝑟𝑜𝑏(𝑒) = 𝐷(𝑆𝑡(𝑒))𝑤

′_(𝑒)

𝑇 , onde 𝑇 = ∑_𝑒′_{∈ 𝐸}

(29)

Capítulo 3. Metodologia 29 𝑃 𝑟𝑜𝑏(𝑒) é diretamente proporcional ao comprimento da aresta 𝑤′(𝑒) e à sua densidade de probabilidade 𝐷(𝑆𝑡(𝑒)), e deve ser normalizada para obter ∑𝑒∈ 𝐸𝑃 𝑟𝑜𝑏(𝑒) = 1.

O local de uma dada entrega 𝑑, indicada por 𝑙𝑜𝑐(𝑑), é composto de três atributos: uma aresta 𝑒 = (𝑢, 𝑣); um valor 𝛼 ∈ [0, 1]; e um rótulo 𝑙𝑎𝑑𝑜_𝑑𝑎_𝑟 𝑢𝑎 = {⊕, ⊖}. A entrega é posicionada na combinação afim de 𝑢 e 𝑣 em respeito a 𝛼, isto é (𝑥𝑢, 𝑦𝑢)(𝛼) + (1 − 𝛼)(𝑥𝑣, 𝑦𝑣). A rua de uma

entrega 𝑑 = (𝑒, 𝛼, 𝑠), indicada por 𝑆𝑡(𝑑), é a rua da aresta 𝑆𝑡(𝑒).

Um inteiro 𝑛 representa o número de entregas, e uma entrega artificial 𝑑𝜋 é criada para o

depósito. O valor de 𝛼 é gerado aleatoriamente dentro do intervalo [0, 1]. O rótulo do lado da rua é uma escolha aleatória equiprovável no conjunto {⊕, ⊖}. O Algoritmo 1 é então utilizado para criar o conjunto de entregas. Dado que o número de entregas é uma parte da entrada, é possível criar instâncias arbitrariamente grandes.

Input:Um inteiro 𝑛 e um conjunto de arestas 𝐸 com probabilidades 𝑃𝑟𝑜𝑏(𝑒), ∀𝑒 ∈ 𝐸 Output:Um conjunto de entregas 𝐷𝑒𝑙.

1 _{𝐷𝑒𝑙 ← ∅}

2 Particione todas as probabilidades das arestas no intervalo [0, 1] 3 for i=1 até n do

4 Selecione um valor aleatório 𝑟 ∈ [0, 1]

5 _{if 𝑟 está no intervalo associado com 𝑃𝑟𝑜𝑏(𝑒) then} 6 Selecione um valor aleatório 𝛼 ∈ [0, 1]

7 Selecione um valor do lado da rua aleatório 𝑠 ∈ {⊕, ⊖}

8 𝐷𝑒𝑙 ← 𝐷𝑒𝑙 ∪ {(𝑒, 𝛼, 𝑠)}

9 end

10 end

11 _{return 𝐷𝑒𝑙}

Algoritmo 1:Algoritmo para criar as entregas.

3.2.2 Estabelecendo o custo entre um par de entregas

O grafo do mapa das ruas 𝐺(𝑉 , 𝐸) é utilizado para computar o custo entre as entregas. Dado duas entregas 𝑑𝑎 e 𝑑𝑏, o custo para atravessar a rua é definido por:

𝑡𝑟 𝑎𝑣𝑒𝑠𝑠𝑖𝑎(𝑑𝑎, 𝑑𝑏) = ⎧ ⎪ ⎪ ⎪ ⎪ ⎪ ⎨ ⎪ ⎪ ⎪ ⎪ ⎪ ⎩ 𝑤𝑡ℎ(𝑆𝑡(𝑑𝑎)), se os rótulos 𝑙𝑎𝑑𝑜_𝑑𝑎_𝑟𝑢𝑎 de (𝑑𝑎, 𝑑𝑏) forem {(⊕, ⊖), (⊖, ⊕)} e 𝑆𝑡(𝑑𝑎) = 𝑆𝑡(𝑑𝑏), 0, caso contrário.

Uma constante 𝛽 ∈ ℝ+, que representa um custo fixo adicional por entrega, deve ser

definida. Esse custo adicional é referente ao tempo médio que um carteiro leva para tirar a correpondência da bolsa e colocar na caixa de correios, ou aguardar o cliente assinar os papéis de retirada, ao realizar uma entrega. O custo entre duas entregas 𝑑𝑎 = (𝑒𝑎, 𝛼𝑎, 𝑠𝑎) e

(30)

𝑑𝑏 = (𝑒𝑏, 𝛼𝑏, 𝑠𝑏) é dado por 𝑤(𝑑𝑎, 𝑑𝑏). Se 𝑒𝑎 = 𝑒𝑏 então:

𝑤(𝑑𝑎, 𝑑𝑏) = |𝛼𝑎− 𝛼𝑏|𝑤′(𝑒𝑎) + 𝑡𝑟 𝑎𝑣𝑒𝑠𝑠𝑖𝑎(𝑑𝑎, 𝑑𝑏) + 𝛽. (3.6)

Seja 𝐺(𝑉 , 𝐸) o mapa da rua original, 𝑒𝑎 = {𝑢𝑎, 𝑣𝑎}, 𝑒𝑏 = {𝑢𝑏, 𝑣𝑏}, e seja 𝐺∗(𝑉∗, 𝐸∗) definido

como: 𝑉∗ _{= 𝑉 ∪ {𝑑}

𝑎, 𝑑𝑏}, 𝐸∗ = 𝐸 ∪ {(𝑢𝑎, 𝑑𝑎), (𝑣𝑎, 𝑑𝑎), (𝑢𝑏, 𝑑𝑏), (𝑣𝑏, 𝑑𝑏)} (Figura 3.3), portanto:

𝑤(𝑑𝑎, 𝑑𝑏) = 𝑚𝑒𝑛𝑜𝑟 _𝑐𝑎𝑚𝑖𝑛ℎ𝑜(𝑑𝑎, 𝑑𝑏, 𝐺∗) + 𝑡𝑟 𝑎𝑣𝑒𝑠𝑠𝑖𝑎(𝑑𝑎, 𝑑𝑏) + 𝛽. (3.7)

A instância é composta de uma matriz 𝑤𝑛×𝑛, um inteiro 𝑘, e um inteiro 𝑚𝑎𝑥. A primeira

entrega representa o depósito.

1 ua va da G(V, E) ub vb db

Figura 3.3: O custo entre duas entregas 𝑑𝑎 e 𝑑𝑏, localizados em arestas distintas 𝑒𝑎 e 𝑒𝑏,

respectivamente. Fonte: elaborado pelo autor.

3.3 A ferramenta para o benchmark

Esta seção descreve a ferramenta que cria o benchmark. A ferramenta possui três arquivos de configuração: background.png; model.txt; e instances.txt. O arquivo background contém uma imagem utilizada para melhorar a visualização e sua resolução é utilizada como base para o modelo. O arquivo model deve conter as seguintes informações:

• Local do depósito: a referência posicional das coordenadas para o depósito; • Custo adicional por entrega: custo para realizar a entrega;

• Precisão decimal: número de dígitos após a parte fracional;

• Valor do píxel: valor utilizado para converter um píxel em outras unidades. Esse valor pode representar a velocidade do veículo;

(31)

Capítulo 3. Metodologia 31 • Atributos: atributos utilizados para computar a densidade de probabilidade da rua e o

custo para atravessar a rua;

• Mapa das ruas: a descrição das ruas incluindo a cadeia poligonal.

Um pesquisador pode realizar experimentos onde o valor do píxel, o custo adicional por entrega e/ou a precisão decimal são variáveis. Considere uma imagem com o fundo em branco de 500 × 500 píxeis de dimensão e o modelo descrito na Figura 3.4. A ferramenta processará o arquivo model.txt e criará um mapa das ruas (Figura 3.5). O depósito é posicionado na aresta mais próxima da coordenada escolhida. A densidade de probabilidade 𝐷 da 4th Av é 0,4 porque é caracterizada[𝐴𝑉 𝐸, 𝑃 𝐸𝑅𝐼 𝑃 𝐻 𝐸𝑅𝐴𝐿, 𝑅𝐴𝐷𝐼 𝑂𝐴𝐶𝑇 𝐼 𝑉 𝐸]com os valores {20, 0.2, 0.1}.

#GENERAL

DEFINE DEPOT_X 250 DEFINE DEPOT_Y 250

DEFINE ADDITIONAL_COST_PER_DELIVERY 10 DEFINE DECIMAL_PRECISION 6

#ONE PIXEL IS PIXEL_VALUE UNITS (meters,sec,etc). DEFINE PIXEL_VALUE 10.0 #PENALTIES DEFINE PERIPHERAL .2 DEFINE RADIOACTIVE .1 #STR DEFINE STR 10 DEFINE STR_CROSSCOST 20 #AVE DEFINE AVE 20 DEFINE AVE_CROSSCOST 10 #ROADMAP 1th STR [STR][100,100]-[400,100] 2th STR [STR,PERIPHERAL][100,200]-[400,200] 3th STR [STR,RADIOACTIVE][100,300]-[400,300] 4th STR [STR,PERIPHERAL,RADIOACTIVE][100,400]-[400,400] 1th Av [AVE][100,100]-[100,400] 2th Av [AVE,PERIPHERAL][200,100]-[200,400] 3th Av [AVE,RADIOACTIVE][300,100]-[300,400] 4th Av [AVE,PERIPHERAL,RADIOACTIVE][400,100]-[350,250]-[400,400]

Figura 3.4: Exemplo de um arquivo model. Fonte: elaborado pelo autor.

Em muitos municípios no Brasil, há locais onde as agências de distribuição não realizam entregas, seja por motivos de segurança, seja por serem locais de difícil acesso, ou mesmo por serem bairros novos, onde estratégias de roteamento ainda estejam sob supervisão. Em adição, há muitos trechos de rodovias, por exemplo, onde não há pontos de entrega por não haverem domicílios. A estratégia para modelar esses casos através da ferramenta, é definir um tipo de rua com os atributos densidade de probabilidade e custo de travessia zerados. Ao adicionar as cadeias poligonais, a ferramenta irá ignorar a distribuição dos pontos de entrega nesses

(32)

St D(St) wth(St) pixel 1th STR 10 20 2th STR 2 20 3th STR 1 20 4th STR 0.2 20 1th Av 20 10 2th Av 4 10 3th Av 2 10 4th Av 0.4 10

Figura 3.5: Mapa baseado no modelo da Figura 3.4. Fonte: elaborado pelo autor.

trechos sem deixar de incluir as arestas e os vértices no grafo 𝐺. A Figura 3.6 demonstra como impedir que a ferramenta atribua entregas a três arestas que servem apenas para conectar ruas e a um trecho de uma rodovia.

#EMPTY DEFINE EMPTY 0.0 DEFINE EMPTY_CROSSCOST 0 #ROAD MAP LINK01[EMPTY][4371,1172]-[4357,1161] LINK02[EMPTY][4276,1426]-[4256,1421] LINK03[EMPTY][4503,1387]-[4313,1324] HIGHWAY SP 332[EMPTY][4376,1021]-[4072,1818]-[4030,1930]

Figura 3.6: Modelando segmentos sem entrega. Fonte: elaborado pelo autor.

O último arquivo é chamado instance.txt (Tabela 3.1). Cada linha corresponde a uma instância no benchmark. A linha deve conter o identificador da instância, o diretório e subdiretório, o número máximo de veículos e uma linha de comentário. Cada linha também deve conter uma semente geradora pseudo-aleatória e uma assinatura MD5.

Tabela 3.1: Arquivo de instância.

ID Dir Subdir n k 𝑚𝑎𝑥 Comment Seed MD5

0 ex ex_0_0 0 0 2941.15 Rota máxima [...] 100 4d...af

1 ex ex_10_5 10 5 2941.15 O tamanho [...] 101 e9...10

2 ex ex_100_5 100 5 2941.15 Considere [...] 102 eb...a2

3 ex ex_1000_5 1000 5 2941.15 Instância [...] 103 05...62

(33)

Capítulo 3. Metodologia 33 O valor de verificação MD5 é utilizado para assegurar a identidade da instância. A ferramenta recriará as instâncias em offline e verificará a assinatura MD5 do arquivo de instância. A ferramenta executará os arquivos da Figura 3.4 e da Tabela 3.1 e criará as instâncias mostradas na Figura 3.7.

Figura 3.7: Instâncias resultantes de 10, 100, 1.000, e 10.000 entregas. Fonte: elaborado pelo autor.

É possível editar o arquivo de instância para criar novas instâncias para um dado modelo. Uma vez que as novas instâncias são criadas, é necessário atualizar manualmente a assinatura MD5. Por exemplo, uma nova semente criará uma nova instância com uma outra sequência pseudo-aleatória.

O website do projeto (MEIRA, L. A. A. et al., 2019) provê o código-fonte que faz o parsing do arquivo de instância. O programa executa também uma otimização de troca simples de aresta e salva a rota em ambos arquivos de texto e de imagem (Figura 3.8). O propósito é fornecer ao pesquisador a solução e uma forma de visualizá-la.

3.3.1 Gerando um benchmark piloto

Nesta subseção, adaptamos a metodologia para criar um benchmark das ruas de Manhattan, na cidade de Nova York, Estados Unidos. Por se tratar apenas de um piloto, não fizemos nenhum estudo de caso real para definir as configurações utilizadas nesse benchmark, logo o número de entregas em Manhattan pode diferir consideravelmente. Nós iniciamos com uma imagem digital de uma seção de Manhattan (Figura 3.9).

(34)

Figura 3.8: Solução para uma instância com 10 entregas. Fonte: elaborado pelo autor.

Figura 3.9: Seção do mapa original. Fonte: Google Maps.

Nós adicionamos manualmente todas as ruas (34 nesse caso) como cadeias poligonais no arquivo de modelo. Como as ruas são geralmente retas nesse exemplo, a maior parte delas é composta por cadeias poligonais com duas coordenadas cartesianas. As coordenadas foram obtidas através de um software free e open source de edição de imagens. Classificamos as ruas em quatro tipos [𝐿𝐴𝑅𝐺𝐸_𝐴𝑉 𝐸𝑁 𝑈 𝐸, 𝐴𝑉 𝐸𝑁 𝑈 𝐸, 𝑆𝑇 𝑅𝐸𝐸𝑇 , 𝐷𝑅𝐼 𝑉 𝐸] com penalidades respectivas e custo para

atravessar as ruas. A Figura 3.10 mostra o resultado da modelagem.

3.3.2 Gerando um benchmark real

Utilizamos a ferramenta para modelar um caso real de entrega de correspondências na cidade de Artur Nogueira, Brasil, chamado RWPostVRPB (do inglês Real World PostVRP Benchmark).

(35)

Capítulo 3. Metodologia 35 #GENERAL DEFINE DEPOT_X 327 DEFINE DEPOT_Y 565 DEFINE ADDITIONAL_COST_PER_DELIVERY 3.2 DEFINE DECIMAL_PRECISION 3

#ONE PIXEL IS PIXEL_VALUE UNITS 1px=1.7m DEFINE PIXEL_VALUE 1.7 DEFINE LARGE_AVENUE 100 DEFINE LARGE_AVENUE_CROSSCOST 0 DEFINE AVENUE 75 DEFINE AVENUE_CROSSCOST 10 DEFINE STREET 40 DEFINE STREET_CROSSCOST 5 DEFINE DRIVE 10 DEFINE DRIVE_CROSSCOST 5 #ROADMAP

Park Avenue [LARGE_AVENUE][654,246]-[0,604] Park Avenue B [LARGE_AVENUE][654,259]-[0,620] 5th Avenue [AVENUE][654,54]-[0,416]

Madison Avenue [AVENUE][654,154]-[0,512] Lexington Ave [AVENUE][654,352]-[0,712] 3rd Avenue [AVENUE][654,447]-[0,809] 2rd Avenue [AVENUE][654,583]-[0,942] 1rd Avenue [AVENUE][654,729]-[0,1090] York Avenue [AVENUE][654,865]-[177,1130] East End Ave [AVENUE][654,1010]-[432,1130] E 71th street [STREET][645,60]-[654,78] E 72th street [STREET][605,85]-[654,179] E 73th street [STREET][567,108]-[654,274] E 74th street [STREET][528,129]-[654,368] E 75th street [STREET][489,152]-[654,462] E 76th street [STREET][449,173]-[654,553] E 77th street [STREET][410,195]-[654,646] E 78th street [STREET][370,217]-[654,738] E 79th street [STREET][328,239]-[654,835] E 80th street [STREET][282,267]-[654,927] E 81th street [STREET][247,285]-[654,1026] E 82th street [STREET][208,306]-[629,1067]-[634,1075] E 83th street [STREET][170,327]-[600,1110] E 84th street [STREET][129,350]-[560,1130] E 85th street [STREET][90,372]-[492,1099] E 86th street [STREET][49,394]-[454,1130] E 87th street [STREET][9,416]-[401,1130] E 88th street [STREET][0,505]-[350,1130] E 89th street [STREET][0,590]-[299,1130] E 90th street [STREET][0,684]-[249,1130] E 91th street [STREET][0,774]-[196,1130] E 92th street [STREET][0,864]-[148,1130] E 93th street [STREET][0,951]-[56,1058] FDR Drive [DRIVE][654,1054]-[634,1075]-[600,1110]-[573,1130]

Figura 3.10: Arquivo model.txt de Manhattan. Fonte: elaborado pelo autor.

Para tornar as instâncias realísticas tanto quanto possível, confiamos na perícia de um funcionário de uma agência real da cidade acima mencionada.

Nós construímos o modelo a partir de uma imagem digital ao invés de utilizar grafos existentes de ruas mapeadas pelas seguintes razões (Figura 3.11): (i) o trajeto realizado por uma pessoa a pé pode diferir dos disponíveis em grafos que priorizam trajetos por veículos

(36)

motorizados; (ii) o número de ruas em Artur Nogueira é suficientemente pequeno para permitir uma criação manual do grafo (≈ 400 ruas); e (iii) mapas públicos como o OpenStreetMap(HAKLAY; WEBER, 2008) estão incompletos, isto é, a cidade tem um grande número de ruas não cobertas.

A ferramenta automaticamente computou as esquinas, resultando em um grafo com |𝑉 | = 2111 e |𝐸| = 3225. Cada vértice está associado com um píxel e cada aresta está associada com uma linha reta entre dois píxeis. O custo de uma aresta (𝑢, 𝑣) é diretamente proporcional à distância Euclidiana entre os vértices 𝑢 e 𝑣 em ℝ2.

Cada rua foi classificada utilizando os atributos Região (R), Tipo (T) e Zona (Z). Cada atributo tem um número correspondente de níveis e cada par atributo-nível está associado com uma penalidade multiplicativa (Pen) em ℝ+. A Tabela 3.2 contém as atribuições do

atributo, do nível, e da penalidade.

Tabela 3.2: Atributo, nível e valores das penalidades.

Atributo Nível 1(𝑃 𝑒𝑛) Nível 2(𝑃 𝑒𝑛) Nível 3(𝑃 𝑒𝑛) Nível 4(𝑃 𝑒𝑛)

Região (R) 𝑐𝑒𝑛𝑡𝑟𝑎𝑙(1.0) 𝑝𝑒𝑟 𝑖𝑓 ́𝑒𝑟 𝑖𝑐𝑜(0,75) 𝑑𝑖𝑠𝑡𝑎𝑛𝑡𝑒(0,4) 𝑖𝑠𝑜𝑙𝑎𝑑𝑜(0,2)

Tipo (T) 𝑎𝑣𝑒𝑛𝑖𝑑𝑎(1.0) 𝑟 𝑢𝑎(0,75) 𝑎𝑙𝑎𝑚𝑒𝑑𝑎(0,4) 𝑟𝑜𝑑𝑜𝑣𝑖𝑎(0)

Zona (Z) 𝑐𝑜𝑚𝑒𝑟𝑐𝑖𝑎𝑙(1.0) 𝑚𝑖𝑠𝑡𝑜(0,75) 𝑟𝑒𝑠𝑖𝑑𝑒𝑛𝑐𝑖𝑎𝑙(0,4) —

No modelo proposto, as ruas localizadas na área central têm uma taxa de entrega maior por unidade de comprimento que as localizadas nas periferias. Tal comportamento é capturado pelo atributo Região através de quatro níveis: central, periférico, distante e isolado. O atributo Tipo também tem quatro níveis, nomeados avenida, rua, alameda e rodovia, enquanto o atributo Zona pode ser comercial, misto, ou residencial. Nós utilizamos o Google

Maps como uma ferramenta auxiliar para classificação das ruas. Cada uma das 422 ruas

recebeu um valor em 𝑅 × 𝑇 × 𝑍, de acordo com o conhecimento especializado.

A densidade de probabilidade (não normalizada) 𝐷 ∶ 𝑆𝑡𝑟𝑒𝑒𝑡𝑠 → ℝ+ é obtida das

penalidades multiplicativas. Por exemplo, a Avenida XV é (𝑐𝑒𝑛𝑡𝑟𝑎𝑙, 𝑎𝑣𝑒𝑛𝑖𝑑𝑎, 𝑚𝑖𝑠𝑡𝑜),

portanto 𝐷(𝑋 𝑉 ) = 1 × 1 × 0, 75 = 0, 75. Por outro lado, a Alameda Jasmine é (𝑖𝑠𝑜𝑙𝑎𝑑𝑜, 𝑎𝑙𝑎𝑚𝑒𝑑𝑎, 𝑟𝑒𝑠𝑖𝑑𝑒𝑛𝑐𝑖𝑎𝑙), portanto 𝐷(𝐽 𝑎𝑠𝑚𝑖𝑛𝑒) = 0, 2 × 0, 4 × 0, 4 = 0, 032. Nesse exemplo, uma entrega aleatória para a avenida 𝑋 𝑉 é 0,75

0,032 mais provável que uma entrega

(37)

Capítulo 3. Metodologia 37

(38)

3.4 Processo de Otimização

Não aplicamos métodos exatos de otimização nesta pesquisa. Fazemos o uso de algumas heurísticas clássicas e também implementamos algumas meta-heurísticas, estas por serem genéricas e por se adaptarem bem a diferentes problemas de tamanhos diferentes. Os algoritmos escolhidos foram: Busca Local (do inglês Local Search, LS); Busca Local Iterada (do inglês Iterated Local Search, ILS); Heurística Gulosa (HG); Recozimento Simulado (do inglês Simulated Annealing, SA); Busca Tabu (do inglês Tabu Search, TS); Busca Gulosa Aleatorizada e Adaptativa (do inglês Greedy Randomized Adaptative Search Procedure, GRASP); e Algoritmo Genético (AG). O objetivo principal desta etapa é demonstrar como os algoritmos podem ser utilizados na solução do problema.

Problemas de casos reais tendem a ser multi-objetivo e costumam apresentar algum tipo de conflito ao tentarem ser resolvidos simultaneamente (SIMON, 2013). Cabe ao decisor a tarefa de avaliar as melhores soluções dos objetivos conflitantes (ARROYO et al., 2002). Recorrer a uma abordagem com soma ponderada dos objetivos (DEB et al., 2002) ou mesmo trabalhar na fronteira de Pareto (TAN; CHEW; LEE, 2006), são algumas das formas existentes de se resolver problemas multi-objetivo. Entretanto, para este trabalho, decidimos iniciar da maneira mais simples possível: tratar o problema como mono-objetivo e otimizar as instâncias a partir do comprimento de rota apenas, mantendo a restrição de factibilidade pelo tamanho máximo do comprimento de rota de cada veículo, isto é, o tempo máximo de trabalho de cada carteiro. Todos os algoritmos que implementamos dependem de três métodos: (i) construção de uma solução inicial que será otimizada; (ii) permutação da solução atual para uma solução vizinha (mecanismo de troca); e (iii) a validação da solução (se atendeu as restrições). Note que clusterizações não são utilizadas.

3.4.1 Construção de uma Solução Inicial

Dado uma solução vazia, um algoritmo de construção trabalha iterativamente na adição dos candidatos à solução até que ela esteja completa (DORIGO; STÜTZLE, 2019). O algoritmo tende a construir melhores soluções iniciais caso ele avalie os candidatos disponíveis a entrar na solução do que adicionar aleatoriamente todos os candidatos. Neste trabalho, implementamos duas construções: aleatória; e gulosa.

(39)

Capítulo 3. Metodologia 39 Com excessão da HG, todos os algoritmos aqui fazem uso de uma construção aleatória. Isso implica que, na maior parte dos casos, as soluções iniciais serão muito ruins, deixando os algoritmos se encarregarem completamente da otimização. O Algoritmo 2 descreve a solução inicial desenvolvida através de uma construção aleatória. A factibilidade é analisada a cada vez que um vértice 𝑣 é escolhido para entrar na solução , fazendo o veículo retornar ao depósito caso a restrição não seja atendida.

Output:Uma solução inicial , factível.

1 _{ ← ∅}

2 _{𝑉 ← Selecione todos os vértices do grafo G} 3 while não está completa do

4 𝑉′_{← Selecione os vértices não disponíveis na solução em construção (𝑉 − 𝑆)} 5 _{𝑣 ← Selecione um vértice aleatório de 𝑉}′

6 if ∪ 𝑣 não é factível then

7 _{ ←  ∪ 𝜋}

8 end

9  ←  ∪ 𝑣

10 end

11 return

Algoritmo 2:Construção de uma solução inicial aleatória.

Em comparação com a construção aleatória, os passos que diferem o desenvolvimento da construção gulosa apresentada nesse trabalho dependem de um simples método de ordenação crescente. Ao iniciar a construção, o algoritmo procura o candidato que esteja mais próximo do depósito e o inclui na solução . A cada nova inserção, os vértices disponíveis são reordenados, utilizando como critério o menor comprimento de rota dos vértices contidos na solução em relação aos disponíveis. Isso garante soluções iniciais mais estáveis para todos os tamanhos de instância que iremos trabalhar mas, em contrapartida, faz com que a solução seja sempre a mesma para cada instância. O Algoritmo 3 representa uma solução inicial gulosa. A factibilidade é tratada da mesma forma que na construção aleatória.

Output:Uma solução inicial , factível.

1 _{𝑉 ← Selecione todos os vértices do grafo G}

2 Ordene 𝑉 em relação ao depósito 𝜋, do melhor para o pior 3 _{ ← Selecione o primeiro vértice de 𝑉}

4 while não está completa do

5 _𝑉′_{← Selecione os vértices não disponíveis na solução em construção (𝑉 − 𝑆)} 6 Ordene 𝑉′em relação ao último vértice disponível em , do melhor para o pior 7 𝑣 ← Selecione o primeiro vértice de 𝑉′

8 if ∪ 𝑣 não é factível then

9 _{ ←  ∪ 𝜋}

10 end

11 _{ ←  ∪ 𝑣}

12 end

13 return

(40)

3.4.2 Mecanismos de Troca

Os mecanismos de troca são utilizados para a melhoria das soluções, através da intensificação do espaço de busca. Dado uma solução , um pequeno movimento de troca entre as arestas ou entre os vértices deve ser aplicado para produzir uma solução ′ adjacente (ou vizinha), com

o objetivo de reduzir o custo total da solução.

Flood (1956) introduziu a idéia básica de troca por arestas, sendo aplicada em um algoritmo 2-Opt, que realiza a troca entre apenas duas arestas a cada movimento (CROES, 1958). A Figura 3.12 exemplifica as etapas necessárias na troca por arestas. Os clientes 𝑐𝑖, 𝑐𝑘, escolhidos

aleatoriamente, são utilizados para selecionar uma faixa da solução  e, então, esta faixa é invertida.

Figura 3.12: Ilustração de uma troca por arestas. Fonte: elaborado pelo autor.

Na troca por vértices, conhecida como 2-Troca (WATERS, 1987), dois clientes 𝑐𝑖, 𝑐𝑘 que

pertecem a uma dada solução  são escolhidos aleatoriamente e são trocados de posição, gerando uma solução vizinha. A Figura 3.13 mostra as etapas da troca por vértice.

Figura 3.13: Ilustração de uma troca por vértices. Fonte: elaborado pelo autor.

Após a troca ser realizada, para ambos os mecanismos, a factibilidade é imediatamente analisada e, caso a nova solução não atenda as restrições (infactível), a solução de entrada 

(41)

Capítulo 3. Metodologia 41 deve retornar intacta. Os Algoritmos 4 e 5 mostram os passos para gerar vizinhos com 2-Opt e 2-Troca, respectivamente.

Input:_{Uma solução inicial .}

Output:Uma solução vizinha factível ′_{com as arestas trocadas em relação à . Na impossibilidade da rota vizinha ser factível,}

retorna a solução inicial .

1 _′_{← ∅}

2 Selecione dois inteiros aleatórios 𝑖, 𝑘 ∈ {0, tamanho de }, tais que 𝑖 < 𝑘 3 ′← Selecione clientes ((𝑐0,𝑐𝑖) ∪ reverso (𝑐𝑖,𝑐𝑘) ∪ (𝑐𝑘+1, 𝑐.𝑡𝑎𝑚𝑎𝑛ℎ𝑜)) ∈  4 if′_{é factível then}

5 return′

6 end

7 return

Algoritmo 4:Troca por arestas.

Input:Uma solução inicial .

Output:Uma solução vizinha factível ′_{com os clientes trocados em relação à . Na impossibilidade da rota vizinha ser}

factível, retorne a solução inicial .

1 ′← 

2 Selecione dois inteiros aleatórios 𝑖, 𝑘 ∈ {0, tamanho de ′_{}, tais que 𝑖 ≠ 𝑘} 3 Selecione dois clientes aleatórios 𝑐_𝑖e 𝑐_𝑘_{∈ }

4 Troque 𝑐_𝑖com 𝑐_𝑘 5 if′é factível then

6 return′

7 end

8 return

Algoritmo 5:Troca por vértices.

3.5 Busca Local, Busca Local Iterada, e Heurística Gulosa

Os algoritmos LS (JOHNSON; PAPADIMITRIOU; YANNAKAKIS, 1988), ILS (LOURENÇO; MARTIN; STÜTZLE, 2003), e HG (DORIGO; STÜTZLE, 2019), são muito parecidos. A LS consiste em construir uma solução inicial  que será exaustivamente intensificada por comparações dentro de um laço de repetição. As comparações são feitas com uma solução candidata vizinha de . A solução  é atualizada com a solução candidata sempre que esta apresentar alguma melhora. A ILS é simplesmente uma série de buscas locais sendo repetidamente aplicada a cada candidato melhor do que . A grande diferença está na capacidade maior do ILS de estabelecer um equilíbrio entre diversificação e intensificação. A HG, implementada neste trabalho, é uma busca local aplicada a uma construção inicial puramente gulosa.

3.6 Simulated Annealing

Na natureza, alguns materiais possuem estruturas cristalinas que são alteradas à medida em que a temperatura desses respectivos materiais varia (SIMON, 2013). Aumentando a

(42)

temperatura, o nível de desordem dos átomos também aumenta dado o acúmulo de energia que o material recebe. Por outro lado, diminuindo a temperatura, os átomos começam a se organizar até entrarem em um estado de equilíbrio, com um alto nível de ordem e baixa energia. Partindo desse fenômeno físico, na indústria é comum a aplicação de um processo metalúrgico de aquecimento e resfriamento das substâncias químicas na obtenção de materiais cristalinos, conhecido como recozimento (POLMEAR et al., 2017). Analogamente, o algoritmo de otimização SA assemelha-se ao processo de recozimento e visa encontrar soluções estáveis conforme a temperatura no sistema diminui. A Tabela 3.3 mostra a relação entre o processo de recozimento na natureza e o SA:

Tabela 3.3: Analogia entre o recozimento na natureza e o algoritmo SA (SIMON, 2013). A tabela original do autor não contempla Energia, Recristalização, e Estado de Equilíbrio.

Recozimento na Natureza SA

Estrutura atômica Solução

Temperatura Tendência a explorar o espaço de busca

Energia Comprimento (ou custo) da solução

Resfriamento Diminuição da tendência de exploração

Mudanças nas estruturas atômicas Mudanças nas soluções candidatas

Recristalização Otimização

Estado de equilíbrio Solução ótima

O Algoritmo 6 descreve o funcionamento do SA. Inicialmente, uma solução inicial  não otimizada é construída. Para cada decréscimo da temperatura 𝑇∗, até que ela esteja abaixo de

uma temperatura mínima 𝑇∗

𝑚𝑖𝑛, uma etapa de otimização executará 𝑛 vezes. A etapa de

otimização consiste em reduzir o nível de energia da solução , isto é, minimizar o comprimento 𝑊 (). A cada iteração na etapa de otimização, geramos uma solução candidata ′ a partir de . Um algoritmo de troca (4 ou 5) será aplicado em ′ para criar uma

perturbação, resultando no aumento ou na diminuição do nível de energia. Em alguns casos, a energia poderá se manter inalterada.

A energia Δ𝐸 representa uma variação entre o comprimento de uma solução e o comprimento de uma respectiva solução candidata, ou seja, 𝑊 (′_{) − 𝑊 ():}

• Caso Δ𝐸 < 0, a energia do sistema diminuiu, ou seja, menor o comprimento 𝑊 (′_{) e}

melhor a solução ′ em relação a 𝑊 () e , respectivamente. A solução ′ será aceita

(43)

Capítulo 3. Metodologia 43 • Caso Δ𝐸 = 0, não houve alteração de energia, ou seja, ambas as soluções  e ′ são

iguais e apresentam o mesmo comprimento. A solução ′será aceita e atualizada em ;

• Caso Δ𝐸 > 0, a energia do sistema aumentou, ou seja, maior o comprimento 𝑊 (′_{) e}

pior a solução ′ em relação a 𝑊 () e , respectivamente. Essa solução poderá ser

selecionada sob uma determinada condição (Equação 3.8).

Diferentemente de outros algoritmos iterativos que descartam soluções candidatas piores do que as respectivas soluções de origem, o SA passa por uma aceitação probabilística que permite ao algoritmo aumentar o espaço de busca, de modo a não ficar preso em um ótimo local. Essa aceitação ocorre através da probabilidade de um estado de energia estar em equilíbrio a uma determinada temperatura, conhecido na mecânica estatística como fator de Boltzmann, e foi adaptado à computação pelo Algoritmo de Metrópolis (METROPOLIS et al., 1953), sendo depois incorporado ao SA:

𝑃 𝑟𝑜𝑏(Δ𝐸) = exp[(−Δ𝐸)/𝑇∗] (3.8)

Um número entre 0 e 1 é escolhido aleatoriamente e então é comparado com 𝑃𝑟𝑜𝑏(Δ𝐸). Caso esse número seja menor, a solução ′ é aceita e atualizada em . Todo esse processo

ocorre repetidamente enquanto a temperatura 𝑇∗, cujo decaimento é dado por 𝑇∗

− (𝑇∗× 𝛼∗), não atingir a temperatura mínima 𝑇∗

𝑚𝑖𝑛.

Input:Uma temperatura inicial máxima 𝑇∗_{. Uma temperatura mínima 𝑇 ∗}

𝑚𝑖𝑛. Um número máximo de iterações 𝑛 para cada

variação da temperatura. Uma taxa de resfriamento 𝛼∗_{do sistema.}

Output:Uma solução  otimizada.

1  ← Construa uma solução inicial aleatória 2 _{while 𝑇}∗> 𝑇∗

𝑚𝑖𝑛do

3 _{for 𝑖 ← 0 até 𝑛 do}

4 _′_{← Encontre uma solução candidata na vizinhança de }

5 _{Δ𝐸 ← Calcule a energia do sistema}

6 ifEnergia Δ𝐸 menor ou igual a 0 then

7  ← ′

8 end

9 else

10 Selecione um valor aleatório 𝛼 ∈ [0, 1]

11 _{if 𝛼 < 𝑃𝑟𝑜𝑏(Δ𝐸) then}

12  ← ′

13 end

14 end

15 end

16 Atualize a temperatura 𝑇∗através de 𝛼∗

17 end

18 return