Zeni GuilhermeAlmeida M PDF

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
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
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
Ficha catalográfica
Universidade Estadual de Campinas
Biblioteca da Faculdade de Tecnologia
Felipe de Souza Bueno - CRB 8/8577
Zeni, Guilherme Almeida, 1992-

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
Powered by TCPDF (www.tcpdf.org)

FOLHA DE APROVAÇÃO
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.
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.
(Edsger W. Dijkstra)
Agradecimentos
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.
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
benchmark pode 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.
Abstract
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

optimization, logistics.
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
4.8 Imagem ao topo: melhor comprimento de rota, obtido por um algoritmo AG
com troca de arestas 2-Opt. O custo total foi de 22.594,76, com 2 veículos e
injustiça entre as rotas de aproximadamente 2,7h. Imagem ao fundo: melhor
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
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

A.2 Todas as instâncias do RWPostVRPB. . . . . . . . . . . . . . . . . . . . . . . . 72
Lista de Algoritmos
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
11 Algoritmo Genético. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
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
VRPTW Vehicle Routing Problem with Time Windows
Lista de Símbolos
∈ 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
𝐸 Conjunto de arestas
𝑣 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
𝜎 Desvio padrão
Sumário
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
B Rota das Melhores Soluções Obtidas 75

17
Capítulo 1
Introdução
Benchmarks sã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
Capítulo 1. Introdução 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′ 22′′ 𝑆47°10′ 22′′ 𝑊 . 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
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.
Capítulo 2. Levantamento bibliográfico 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
pla33810 foi 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
Figura 2.1: Solução ótima da instância d15112. Fonte: adaptado de Waterloo (2005).
Figura 2.2: Instância pla33810. Fonte: elaborado pelo autor.

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.
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).
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
do VRP (https://www.sintef.no/projectweb/top/).
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
S(C, k) = (c1 , . . . , cn , π, . . . , π).
Capítulo 3. Metodologia 26
Esta sequencia é montada da seguinte maneira. Primeiro, todos os clientes são inseridos em S.
Após isso,é,são
𝑘= 3). A sequência
inseriodos k − 1 vezes o(𝐶,
vértices é dadaSepor
3)depósito. o conjunto
(𝐶, 3) de =
clientes
(𝑐 , …C ,e𝑐o número
, 𝜋, 𝜋). Uma possível solução seria
1 13
a permutação
de veículos k estiverem claros
no
′ contexto, poderemos usar S para represnetar S(C, k).
= (𝑐 , 𝑐 , 𝑐 , 𝑐 , 𝑐 , 𝜋, 𝑐 , 𝑐 , 𝑐 , 𝑐 , 𝜋, 𝑐 , 𝑐 , 𝑐
3 5 4 1 2 6 10 11 12 7 8 9 , 𝑐13 ).
Cada permutação de S representa uma solução do VRP. Para exemplificar, considere o grafo
abaixo:
c10 c12 c13
c10 c12 c13
c9 c9
c6 c11 c6 c11
c8 c8
π c7 π c7
c3 c3
c5 c2 c5 c2
c4 c4
c1 c1
Figura 4: Exemplo de Intância Figura

do VRP5: Solução S ′ = (c3 , c5 , c4 , c1 , c2 , π, c6 , c10 , c11 , c12 , π, c7 , c8 , c9 , c13 ).
Figura 3.1: Exemplo deToda vértices

rota inicia edo VRP
termina (esquerda)
no depósito. e S ′uma
A solução solução
representa  dos clientes
uma partição = em 3
′
Considere os vértices da descritos na Figura 4. Considere o número de veículos igual a 3, ou
(𝑐3 , 𝑐5 , 𝑐4 , 𝑐1 , 𝑐2 , 𝜋, 𝑐6 , 𝑐10 , 𝑐11 , 𝑐12 , 𝜋, 𝑐7 , 𝑐8 , 𝑐9 , 𝑐13 ) (direita). Fonte: elaborado pelo autor.
rotas: R1 = (c3 , c5 , c4 , c1 , c2 ), R2 = (c6 , c10 , c11 , c12 ) e R3 = (c7 , c8 , c9 , c13 ). Mais formalmente,
seja k = 3. A sequência S(C, 3) neste caso seria:
Todas as rotas começam

umae solução
terminam noparticionada
pode ser depósito.emAdiversas
solução rotas ′ representa uma partição
de clientes em trêsS(C,
rotas: , 𝑐4 , 𝑐1 , 𝑐2 ), 2 = (𝑐6 , 𝑐10 , 𝑐11 , 𝑐12 ) e 3 = (𝑐7 , 𝑐8 , 𝑐9 , 𝑐13 ). O
1,1. .=. , c(𝑐133, ,π,𝑐5π).
3) = (c
P articao(S) = (R1 ,′ . . . , Rk )
vértice 𝜋 é utilizado para criar uma partição da sequência em 𝑘 ≤ 𝑘 rotas. Considere
Cada permutação de S(C, 3) representa uma solução para o VRP. Por exemplo, a permutação
̃
𝑃𝑎𝑟𝑡𝑖ç𝑎𝑜() = (1 , … , 𝑘 ′ ). Por definição, rotas vazias não fazem parte da 𝑃𝑎𝑟𝑡𝑖ç𝑎𝑜().
̃
onde a partição da solução é feita no depósito π.
Portanto, ′𝑃𝑎𝑟𝑡𝑖ç𝑎𝑜(1,
̃ 2, 𝜋, 𝜋, 3, 4) é {(1, 2), (3, 4)} e não {(1, 2), (), (3, 4)}, isto é, 𝑘 ′ ≤ 𝑘.
S = (c3 , c5 , c4 , c1 , c2 , π, c6 , c10 , c11 , c12 , π, c7 , c8 , c9 , c13 )
No exemplo da Figura 5 temos que
O comprimento de uma rota  = (𝑟1 , … , 𝑟𝑚 ) é dado por:
representa a solução descrita na Figura 5 𝑚−1
P articao(S ′ ) = ({c3 , c5 , c4 , c1 , c2 } , {c6 , c10 , c11 , c12 } , {c7 , c8 , c9 , c13 }) .
𝑊 () = 𝑤(𝜋, 𝑟1 ) + 𝑤(𝑟𝑚 , 𝜋) + ∑ 𝑤(𝑟𝑖 , 𝑟𝑖+1 ). (3.1)
9
𝑖=1
O comprimento de uma rota R = (r1 , . . . , rm ) é dado por:

O comprimento de uma solução  é a distância de todo o trajeto e é calculado por:
m−1
!
𝑊 () = W
∑ (R) = w(π, r1) + w(rm , π) +
𝑊 (). w(ri , ri+1 ) (3.2)
i=1
∈𝑃𝑎𝑟𝑡𝑖ç𝑎𝑜()
̃
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 |𝑃𝑎𝑟𝑡𝑖ç𝑎𝑜()|
̃ 10 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.
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:
√
2
∑ (𝑊 () − 𝑊 ())
∈𝑃𝑎𝑟𝑡𝑖ç𝑎𝑜()
̃
𝑓3 () = . (3.5)
̃
|𝑃𝑎𝑟𝑡𝑖ç𝑎𝑜()| −1
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 𝑐 ∈ ℝ2 para todo 𝑐 ∈ 𝑃. O grafo do mapa
completo contém um conjunto  = (𝑃1 , … , 𝑃𝑛′′ ) de cadeias poligonais, um para cada rua.
Então criamos o grafo 𝐺(𝑉 , 𝐸) a partir de . Cada vértice 𝑣 ∈ 𝑉 está associado com uma
coordenada cartesiana (𝑥𝑣 , 𝑦𝑣 ) ∈ ℝ2 e 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 𝑇 = ∑ 𝐷(𝑆𝑡(𝑒 ′ ))𝑤 ′ (𝑒 ′ ).
𝑇 𝑒′ ∈ 𝐸
𝑃𝑟𝑜𝑏(𝑒) é 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
𝑑𝑏 = (𝑒𝑏 , 𝛼𝑏 , 𝑠𝑏 ) é 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.
ua ub
da
G(V, E) db
va vb
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;
• 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
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
4 ex ex_10000_5 10000 5 2941.15 Instância [...] 104 93...53
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).
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).
#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 82th street [STREET][208,306]-[629,1067]-[634,1075]
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
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
para a alameda 𝐽 𝑎𝑠𝑚𝑖𝑛𝑒 por unidade de comprimento.
Figura 3.11: Mapa original de Artur Nogueira.

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.
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 𝑉
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 
Algoritmo 3: Construção de uma solução inicial gulosa.
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 
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
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
e atualizada em ;
• 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:
(3.8)
∗]
𝑃𝑟𝑜𝑏(Δ𝐸) = exp[(−Δ𝐸)/𝑇
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 if Energia Δ𝐸 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 
Algoritmo 6: Simulated Annealing.
3.7 Busca Tabu

Ao longo dos anos, a TS se tornou uma das meta-heurísticas de maior destaque na solução de
problemas de otimização combinatória (BLUM; ROLI, 2003), sendo também utilizada nas mais
diversas pesquisas de aplicação em outras áreas (GLOVER; LAGUNA; MARTI, 2018).
A TS aborda um conceito de memória, não abstraído da memória física dos seres vivos,
que possibilita a exploração ampla do espaço de busca. A memória da TS é baseada em uma
estrutura, denominada lista tabu, que mantém um histórico de soluções proibidas (tabu) que
não podem ser revisitadas enquanto estiverem armazenadas na lista. A estrutura da lista tabu
deve ser capaz de mapear o movimento entre cada dois pares de clientes que possam resultar
em soluções vizinhas. Portanto, como a troca entre o cliente 𝑐𝑥 e o cliente 𝑐𝑦 é igual a troca
entre o cliente 𝑐𝑦 e o cliente 𝑐𝑥 , a lista poderá conter até 𝑛(𝑛 − 1)/2 pares de troca. A Figura 3.14
mostra a estrutura completa de uma lista tabu clássica, considerando que o número de clientes
seja 𝑛 = 5:
Figura 3.14: Lista tabu, contendo 10 pares. Fonte: elaborado pelo autor.
Outra característica importante é a duração dos pares contidos na lista tabu. Supondo
que a duração seja igual a 4, um movimento de troca armazenado não será usado durante 4
iterações. Dependendo da capacidade temporal e de armazenamento da lista, a memória pode
ser classificada como: de curto-prazo; de médio-prazo; e de longo-prazo.
A memória de curto-prazo é definida apenas pelo uso da lista tabu como forma de
armazenamento das soluções recém-visitadas. A medida em que o número de clientes cresce,
mapear todos os possíveis movimentos que resultam em soluções vizinhas se torna inviável
e, portanto, algumas alternativas devem ser consideradas para diminuir a complexidade
computacional, como limitar o número de pares contidos na lista. As memórias de
médio-prazo e de longo-prazo são utilizadas, respectivamente, para intensificação através da
recência e diversificação através da frequência de soluções na lista tabu, mas o sucesso delas
depende da estrutura do problema a ser otimizado (TALBI, 2009).
Além da lista, a TS também precisa enumerar um conjunto dos movimentos que resultem
nos melhores candidatos à troca. A TS faz então uma sucessão de verificações para
determinar o melhor candidato que não esteja na lista tabu. Cada vez que um candidato
proibido é encontrado, o próximo a ser considerado será sempre o melhor depois dele, e
assim sucessivamente, evitando cálculos probabilísticos na decisão de qual pior solução
aceitar, diferentemente do que o SA faz. Isso significa que a exploração do espaço de busca é
feita de forma inteligente, diminuindo as chances do algoritmo ir para regiões do espaço
cujas soluções sejam muito piores e aumentando as chances de encontrar as regiões que
poderão resultar em um ótimo global.
O Algoritmo 7 descreve o funcionamento da TS com memória de curto-prazo. Como
utilizamos instâncias muito grandes nesse trabalho, limitamos o armazenamento da lista em
𝑝 soluções. Quando a capacidade 𝑝 é atingida, a lista começa a ser esvaziada pelo item mais
antigo (FIFO).
Input: Um número máximo de iterações 𝑛. Um tamanho máximo 𝑝 para a lista tabu. Um número máximo de soluções na
vizinhança 𝑚𝑎𝑥𝑉 𝑖𝑧𝑖𝑛ℎ𝑜𝑠
2 ′ ← 
3 𝑙𝑖𝑠𝑡𝑎𝑇𝑎𝑏𝑢 ← 
4 for 𝑖 ← 0 até 𝑛 do
5 𝑣𝑖𝑧𝑖𝑛ℎ𝑎𝑛𝑐𝑎 ← Selecione vizinhos de  ′
6  ′ ← Selecione primeira solução da 𝑣𝑖𝑧𝑖𝑛ℎ𝑎𝑛𝑐𝑎
7 for Cada solução vizinha  ′′ ∈ 𝑣𝑖𝑧𝑖𝑛ℎ𝑎𝑛𝑐𝑎 do
8 if  ′′ não está na 𝑙𝑖𝑠𝑡𝑎𝑇𝑎𝑏𝑢 ⊗ Custo de  ′′ menor do que custo de  ′ then
9  ′ ←  ′′
10 end
11 if Custo de  ′ menor do que custo de  then
12  ← ′
13 end
14 𝑙𝑖𝑠𝑡𝑎𝑇𝑎𝑏𝑢 ← 𝑙𝑖𝑠𝑡𝑎𝑇𝑎𝑏𝑢 ∪  ′
15 if Tamanho da 𝑙𝑖𝑠𝑡𝑎𝑇𝑎𝑏𝑢 maior que 𝑝 then
16 Remova a primeira solução da 𝑙𝑖𝑠𝑡𝑎𝑇𝑎𝑏𝑢
17 end
18 end
19 end
20 return 
Algoritmo 7: Busca Tabu com memória de curta-duração.
3.8 Greedy Randomized Adaptive Search Procedure

A meta-heurística GRASP é uma alternativa de exploração inteligente do espaço de soluções
em relação à busca local. Ao invés de ficar preso em uma determinada região do espaço a
partir de uma construção inicial aleatória ou gulosa, esse algoritmo sistematicamente constrói
soluções caracterizadas por um determinado equilíbrio entre as naturezas aleatória e gulosa,
aplicando a busca local a cada construção.
O GRASP não possui nenhum tipo de mecanismo de memória, dado que cada iteração é
independente, apenas confia em sua capacidade de fornecer soluções em diferentes regiões e
e depois as aprimora (TALBI, 2009).
Nas principais versões implementadas do GRASP, somente dois parâmetros de controle são
utilizados (RESENDE; MATEUS; SILVA, 2012): um valor máximo de iteração, que representa
o número de construções do algoritmo e, simultaneamente, o número de execuções da busca
local; e um valor 𝛼 ∗∗ ∈ [1, 𝑛], que balanceia o aspecto aleatório e/ou guloso.
O Algoritmo 8 descreve o método básico do GRASP, onde as duas fases principais,
construção e aprimoramento, são executadas 𝑖 vezes.
Input: 𝑖, o número máximo de iterações do sistema.

2 for 𝑖 ← 0 até 𝑖 do
3  ′ ← Construa uma solução gulosa-aleatória
4  ′ ← Execute busca local em  ′
5 if Custo de  ′ menor do que custo de  then
6  ← ′
7 end
8 end
9 return 
Algoritmo 8: GRASP.
É comum o uso de um método de reparo das soluções após a construção gulosa-aleatória

ser realizada, caso esta apresente infactibilidade. Contudo, optamos por aplicar a verificação
dentro da própria fase de construção, no momento da adição do vértices. Assim garantimos que
o algoritmo evitará execuções desnecessárias de reparo, ao sempre construir soluções válidas.
O Algoritmo 9 descreve a fase de construção gulosa-aleatória, que consiste na adição sucessiva
de vértices em uma solução vazia, retirados aleatoriamente de uma Lista Restrita de Candidatos
(LRC).
Output: Uma solução inicial  de aspecto guloso e/ou aleatório.

1 ←∅
3 𝐿𝑅𝐶 ← Gere uma lista de candidatos restrita a partir de 
4 𝑉 ← Selecione um vértice 𝑣 ∈ 𝐿𝑅𝐶 aleatoriamente
5 if  ∪ 𝑉 não é factível then
6  ← ∪𝜋
7 end
8  ← ∪𝑉
9 end
10 return 
Algoritmo 9: GRASP, fase de construção gulosa-aleatória.
A LRC é a alma do GRASP. Ela se adapta aos novos melhores candidatos da solução em
construção a cada inserção de vértices, desconsiderando os vértices já utilizados. Ou seja, se o
problema for de minimização, como o nosso caso do PostVRP, a lista irá conter os vértices com
menor valor de distância em relação ao último vértice presente na solução. O Algoritmo 10
descreve a criação de uma LRC.
Input: Uma solução em construção , isto é, cuja rota ainda possua lista de vértices incompleta. Um inteiro 𝛼 ∗∗ .
Output: Uma lista de candidatos restrita.
1 𝐿𝑅𝐶 ← ∅
2 𝑉 ← Selecione todos os vértices do grafo 𝐺
3 𝑉 ′ ← Selecione os vértices não disponíveis na solução em construção (𝑉 − )
4 Ordene 𝑉 ′ , do melhor para o pior
5 𝐿𝑅𝐶 ← Selecione os 𝛼 ∗∗ primeiros vértices de 𝑉 ′
6 return 𝐿𝑅𝐶
Algoritmo 10: GRASP, geração da LRC.
Quanto mais 𝛼 ∗∗ tender a 1, mais gulosa será a construção. Caso 𝛼 ∗∗ = 1, somente o

melhor candidato estará presente na LRC e, consequentemente, será adicionado à solução.
Isso significa, para este caso, que todas as construções realizadas serão iguais e puramente
gulosas, para todas as 𝑖 iterações. Logo, o algoritmo irá se comportar como se fosse uma série
de heurísticas gulosas, competindo entre si.
Quanto mais 𝛼 ∗∗ tender a 𝑛, mais aleatória será a construção. Caso 𝛼 ∗∗ = 𝑛, a LRC possuirá
todos os vértices que ainda não foram incluídos e o algoritmo irá se comportar como uma série
de buscas locais com diferentes soluções iniciais aleatórias, competindo entre si.
Para melhor eficiência do GRASP, é necessário ser capaz de refinar o 𝛼 ∗∗ de modo que o
algoritmo consiga explorar o espaço de busca o máximo possível, mas o mínimo suficiente
para produzir soluções iniciais de boa qualidade.
3.9 Algoritmo Genético

Há décadas, uma série de incontáveis artigos têm sido publicados por centenas de
pesquisadores sobre as mais diversas formas de implementação de sistemas evolutivos.
Dentre eles, os Algoritmos Genéticos (AGs) constituíram um marco na computação evolutiva.
Os AGs são estritamente baseados nos trabalhos pioneiros de Darwin e de Mendel, sobre
evolução e genética, respectivamente (SIMON, 2013). A partir de seus estudos, hoje sabemos
que, na natureza, características específicas dos indivíduos de uma espécie podem trazer
vantagens em um determinado ambiente, ao mesmo tempo que essas mesmas características
também podem resultar na extinção dessa mesma espécie em um outro habitat. Às espécies
adaptadas, para garantir a sobrevivência, seus indivíduos devem ser capazes de transmitir
seu código genético aos descendentes. Esses dois fatores, adaptação e decendência, são a base
da seleção natural que, por sua vez, constitui o processo fundamental da evolução.
A evolução também depende de outro fator: mudanças significativas no código genético
dos indivíduos, ou mutação. Por exemplo, a mutação que resultou nos pêlos dos ursos
polares, condeceu a capacidade dos indivíduos de se camuflarem em ambientes árticos,
resultando em uma maior eficiência na caça e garantindo a sobrevivência dessa espécie
nesses ambientes (RINKER et al., 2019). A mutação é a chave que abre as portas para o
surgimento de indivíduos desenvolvidos que, se adaptados, darão origem a uma nova
população evoluída.
Em analogia, os AGs simulam a evolução natural de uma população de soluções na
expectativa de encontrar o indivíduo mais evoluído após muitas gerações (Algoritmo 11).
Uma população inicial é construída a partir de soluções aleatórias. Dessa população, dois
ancestrais genitores são escolhidos para gerar dois descendentes, cujo código genético será
misturado. Nesse contexto, os cromossomos dos ancestrias e dos descendentes representam
os clientes do PostVRP. A cada nova população completa que nasce, todos os indivíduos
tendem a sofrer uma mutação. Depois do máximo de gerações terem sido atingido, é
escolhido o indivíduo mais apto, que constitui a solução do problema.
Input: 𝑚𝑎𝑥𝐺𝑒𝑟𝑎𝑐𝑎𝑜, número máximo de gerações. 𝑚𝑎𝑥𝑃𝑜𝑝, um tamanho máximo de indivíduos na população. 𝑎𝑢𝑚𝑒𝑛𝑡𝑜, um
valor incremental de indivíduos na população a cada nova geração
1 𝑝𝑜𝑝 ← Construa soluções aleatórias
2 for 𝑖 ← 0 até 𝑚𝑎𝑥𝐺𝑒𝑟𝑎𝑐𝑎𝑜 do
3 𝑛𝑜𝑣𝑎𝑃𝑜𝑝 ← ∅
4 while 𝑛𝑜𝑣𝑎𝑃𝑜𝑝 menor do que 𝑚𝑎𝑥𝑃𝑜𝑝 do
5 𝑎𝑛𝑐, 𝑎𝑛𝑐 ′ ← Selecione dois ancestrais de 𝑝𝑜𝑝
6 𝑑𝑒𝑠𝑐, 𝑑𝑒𝑠𝑐 ′ ← Gere um descendente para cada ancestral
7 𝑛𝑜𝑣𝑎𝑃𝑜𝑝 ← 𝑛𝑜𝑣𝑎𝑃𝑜𝑝 ∪ 𝑑𝑒𝑠𝑐 ∪ 𝑑𝑒𝑠𝑐 ′
8 end
9 𝑝𝑜𝑝 ← Gere mutações em 𝑛𝑜𝑣𝑎𝑃𝑜𝑝
10 𝑚𝑎𝑥𝑃𝑜𝑝 ← Aumente a capacide máxima da população (𝑎𝑢𝑚𝑒𝑛𝑡𝑜 > 0)
11 end
12  ← Selecione o indivíduo mais apto de 𝑝𝑜𝑝
13 return 
Algoritmo 11: Algoritmo Genético.
49
Capítulo 4
Resultados
Neste capítulo, apresentaremos os benchmarks desenvolvidos nessa pesquisa, Manhattan

pilot e RWPostVRPB, e faremos uma análise do comportamento dos algoritmos de
otimização ao serem aplicados às instâncias do segundo benchmark. A Seção 4.1 mostra o
benchmark piloto que fizemos em apenas um trecho de Manhattan. A Seção 4.2 traz o
benchmark oficial desenvolvido nesse trabalho, baseado em um caso real de entregas em
Artur Nogueira. As instâncias geradas foram classificadas e organizadas. A Seção 4.3 contém
o arranjo dos testes computacionais aplicados em algumas instâncias do RWPostVRPB e a
média dos resultados de todos os algoritmos. Na Seção 4.4, a convergência e a diferença dos
comprimentos de rota encontrados pelos algoritmos são verificados. É nessa seção que
entendemos o efeito que os algoritmos têm sobre problemas do mundo real. Finalmente, na
Seção 4.5, comparamos os melhores resultados para o comprimento de rota com os melhores
encontrados para o fator de justiça.
4.1 Manhattan pilot benchmark

Utilizando a ferramenta de geração de benchmarks, criamos programaticamente 30 instâncias
contendo entre 3 e 5.000 pontos de entrega. Como resultado, o benchmark piloto de
Manhattan demonstrou que a ferramenta que desenvolvemos funciona como o esperado e
serviu como ponto de partida para modelarmos um cenário real. Outros pesquisadores
também podem utilizar esse benchmark como um modelo base para o entendimento da
ferramenta, uma vez que possui um número pequeno de ruas mapeadas e poucos atributos
configurados. O Apêndice A.2 lista detalhadamente todas as instâncias.
Capítulo 4. Resultados 50
Por ser apenas um piloto de testes, todas as instâncias apresentadas nesse benchmark
receberam igualmente um número máximo de comprimento de rota e de veículos e, portanto,
foram classificadas em um único grupo. A Figura 4.1 mostra a imagem de uma das instâncias
baseadas nesse modelo.
Figura 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.
4.2 Real-world PostVRP benchmark

O RWPostVRPB contém 78 instâncias divididas em quatro grupos, Toy, Normal, OnStrike, e
Christmas (Tabela 4.1). O conjunto Toy contém 30 instâncias com um número pequeno de
entregas, e pode ser usado para validar os algoritmos antes deles serem aplicados às instâncias
maiores e realísticas, variando entre 5 e 15 veículos. O número máximo de veículos é 30, 45 e
60 para Normal, OnStrike, e Christmas, respectivamente.
O conjunto Normal contém 15 instâncias de 10.000 até 14.000 entregas. A cidade de Artur
Nogueira tem cerca de 50.000 habitantes e uma média de 12.000 correspondências a serem
entregues diariamente. O trabalho diário normal de um carteiro é de oito horas por dia. O
carteiro gasta duas horas preparando as entregas dentro da agência de distribuição e seis horas
para completar as entregas a pé. A agência de distribuição tem cerca de 15 carteiros para
realizar tais entregas. O número de veículos é variável no PostVRP, com um valor máximo
Tabela 4.1: Descrição das instâncias RWPostVRPB. O Apêndice A.2 lista detalhadamente todas
as instâncias do RWPostVRPB.
Conjunto # Instâncias # Entregas Comprimento (hrs) # Veículos (max)

Toy 30 3 até 5.000 6 5 até 15
Normal 15 10.000 até 14.000 6 30
OnStrike 15 15.000 até 19.000 8 45
Christmas 18 20.000 até 30.000 8 60
definido. Se uma solução factível com 11 carteiros for encontrada, a agência de distribuição
poderá atribuir tarefas internas para quatro carteiros (15 − 11).
Os conjuntos OnStrike e Christmas podem ser usados para modelar contingências. O
conjunto OnStrike é similar ao Normal, mas o número de entregas é maior (de 15.000 até
19.000) e o comprimento de rota máximo é de oito horas. O conjunto Christmas modela uma
temporada especial com altas taxas de entrega. A agência de distribuição frequentemente
contrata mão-de-obra extra para a época de Natal. Uma solução factível com 17 carteiros
representa duas novas contratações (15 + 2). Para todos os conjuntos, um comprimento de
rota médio mínimo é desejado assim como uma variância mínima entre os comprimentos das
rotas. A Figura 4.2 mostra a distribuição de 10.000 pontos de entrega em Artur Nogueira.
A velocidade dos veículos foi estimada em 0, 69𝑠/𝑝 𝚤𝑥𝑒𝑙,
́ isto é, 𝑃𝐼 𝑋 𝐸𝐿_𝑉𝐴𝐿𝑈 𝐸 = 0, 69. O custo fixo
por entrega foi definido como 5 × 0, 69𝑠 = 3, 45𝑠, isto é, 𝐴𝐷𝐷𝐼 𝑇 𝐼 𝑂𝑁 𝐴𝐿_𝐶𝑂𝑆𝑇 _𝑃𝐸𝑅_𝐷𝐸𝐿𝐼 𝑉 𝐸𝑅𝑌 = 5.
Em 10 de Julho de 2017, todas as instâncias se tornaram disponíveis no website como uma
matriz 𝑤, onde 𝑤(𝑢, 𝑣) é o custo para realizar um entrega em 𝑣 partindo de 𝑢 para todo
𝑢, 𝑣 ∈ 𝑆. Para a maior instância, a matriz resultante foi igual a 30.000 × 30.000 e consumiu
10, 4 𝐺𝐵 de memória para armazená-la. Em 17 de Janeiro de 2018, nós disponibilizamos a
instância representada como um grafo 𝐺(𝑉 , 𝐸, 𝑤). Representamos cada entrega como um
triplo (𝑒, 𝛼, 𝑙𝑎𝑑𝑜_𝑑𝑎_𝑟𝑢𝑎), e computamos a distância entre duas entregas pelas Equações (3.6)
e (3.7). A primeira representação teve um nível de desordem mais alta do que a segunda.
O conjunto completo das instâncias pode ser baixado do website do projeto (MEIRA, L. A. A.
et al., 2019). O website também inclui uma amostra piloto de modelagem de uma seção de
Manhattan.
Figura 4.2: Uma instância gerada com 10.000 pontos de entrega.

4.3 Testes Experimentais de Otimização

Nesse trabalho, otimizamos apenas algumas instâncias de calibragem dos algoritmos. Os
testes experimentais foram executados sistematicamente nas seguintes instâncias da classe
RealWorldPostToy: 3_0; 5_0; 10_0; 20_0; 50_0; 100_0; 200_0; 500_0; e 1000_0. Para cada uma
dessas instâncias, dividimos os testes em amostras de 10 por algoritmo, para cada mecanismo
de troca, totalizando 1.260 amostras (7 algoritmos × 2 tipos de troca × 10 execuções × 9
instâncias). A Tabela 4.2 lista a relação dos testes realizados em cada algoritmo.
Tabela 4.2: Testes executados.
Alg. Troca # Execuções # Instâncias

LS Aresta 10 9
LS Vértice 10 9
ILS Aresta 10 9
ILS Vértice 10 9
HG Aresta 10 9
HG Vértice 10 9
SA Aresta 10 9
SA Vértice 10 9
TS Aresta 10 9
TS Vértice 10 9
GRASP Aresta 10 9
GRASP Vértice 10 9
AG Aresta 10 9
AG Vértice 10 9
Optamos por calibrar todos os algoritmos com valores constantes, que não se alteraram
independentemente do tamanho da instância testada:
• LS, 100.000 iterações;
• ILS, 10.000 buscas locais de 1.000 iterações, cada;
• HG, 200.000 iterações;
• SA, temperatura decrescendo de 25 para 10, 5.000 iterações a cada decréscimo, e taxa de
resfriamento de 2,5%;
• TS, lista tabu com no máximo 20 soluções, e 15.000 iterações;

• GRASP, 100 construções gulosas aleatorizadas, 20.000 iterações internas, e LRC de

tamanho fixo igual a 5;
• AG, 100.000 gerações, população máxima de 20 soluções, sem aumento de população a

cada geração, máximo de 3 cromossomos trocados entre os ancestrais, e taxa de elitismo
de 5%.
Observamos que para até 100 pontos de entrega, o número de iterações foi suficientemente
grande em todos os algoritmos para encontrar resultados muito próximos. A partir de 200
pontos, o GRASP obteve comprimentos de rota maiores, contudo obteve as melhores médias
entre as instâncias de 10 e de 50 pontos. O SA atingiu as melhores médias para 100 e 200
pontos de entrega. O AG alcançou a melhor média com 500 pontos. O ILS somente obteve a
melhor média de resultados para a maior instância testada. O TS e a HG, embora não tenham
atingido a melhor média em nenhum dos casos, mantiveram média similar e relativamente boa
em relação a todos os outros algoritmos. A Figura 4.3 apresenta um gráfico contendo a média
dos resultados por algoritmo para as instâncias de tamanho 5, 3, 10, 20, 50, 100, 200, 500, e
1.000, de baixo para cima, respectivamente.
105
𝑓1 () em horas
104
LS ILS HG SA TS GRASP AG
Algoritmo
RealWorldPostToy_3_0 RealWorldPostToy_20_0 RealWorldPostToy_200_0

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

4.4 Convergência dos Algoritmos

Para as três instâncias menores, com algumas excessões, os algoritmos convergiram a um
mesmo valor em todas as funções-objetivo: 100% dos algoritmos alcançaram o comprimento
de rota 6023.94 na primeira instância; em 77% dos casos, as execuções atingiram 3742.11 na
segunda instância; e, aproximadamente, 68% conseguiram encontrar 8103.11 na terceira
instância. A Tabela 4.3 evidencia a similaridade dos resultados em todas as execuções nas
primeiras instâncias.
Tabela 4.3: Convergência dos algoritmos nas três instâncias menores.
𝑓1 () 𝑓1 () 𝑓1 ()

Instância 𝑛 menor média maior
𝑓2 () 𝑓3 ()
RealWorldPostToy_3_0 3 6023.94 6023.94 6023.94 1 0

Pensando em termos práticos, a diferença entre a pior e a melhor solução foi de fato
desprezível, mesmo para a instância RealWorldPostToy_10_0. Neste caso, o pior resultado
representou apenas três minutos a mais do que o melhor. Contudo, é preciso levar em
consideração que essas instâncias não representam 1% das correspondências diárias
entregues pelos carteiros. A Figura 4.4 demonstra o impacto que a otimização ineficiente
teria na vida real.
80
𝑓1 () em horas
60
40
20
3 5 10 20 50 100 200 500 1.000

𝑛
Figura 4.4: Diferença do comprimento de rota entre a melhor e a pior solução encontrada em
todas as instâncias.
Na medida em que as instâncias aumentaram, a diferença no comprimento das rotas entre

as melhores e as piores soluções cresceu significativamente, chegando ao impraticável a partir
de 500 pontos de entrega, com uma diferença de aproximadamente 27 horas. Um algoritmo mal
calibrado poderia resultar em um atraso de mais de 80 horas para uma instância de tamanho
1.000, ou seja, uma agência de distribuição levaria aproximadamente duas semanas a mais de
trabalho para garantir aproximadamente 10% das entregas que deveria realizar em um único
dia.
Caso os testes tivessem sido realizados nas instâncias do conjunto Normal, que representam
um tamanho mais compatível com a carga real de entregas, a diferença entre os piores e os
melhores resultados seria numa escala ainda maior. A Figura 4.5 mostra essa tendência de
crescimento. As três primeiras instâncias apresentaram convergência, contudo é possível notar
uma determinada distância crescendo entre o melhor e o pior resultado a partir da quarta
instância (RealWorldPostToy_20_0).
105
𝑓1 ()
104
3 5 10 20 50 100 200 500 1.000

𝑛
Maior comprimento de rota
Menor comprimento de rota
Figura 4.5: Comprimento de rota menor e maior, encontrados em cada instância.
A resposta para tal comportamento é simples e já conhecida em problemas de otimização

combinatória: quanto maior o espaço de busca, maior as possibilidades de solução, e menor
a quantidade de regiões exploradas. Com tantas regiões inexploradas, é muito provável que
alguns algoritmos acabem entrando apenas em locais muito ruins de se produzir boas soluções
durante suas execuções. Em algum momento, o contrário também deve ocorrer. A Figura 4.6
apresenta dois gráficos que evidenciam esse comportamento: no primeiro, compara a diferença
entre a quantidade de algoritmos que encontraram soluções cujo comprimento de rota seja
menor do que a média e a quantidade de algoritmos que encontraram o menor comprimento

de rota; e no segundo, compara a diferença entre a quantidade de algoritmos que encontraram
soluções cujo comprimento de rota seja maior do que a média e a quantidade de algoritmos
que encontraram o maior comprimento de rota. Note que, para ambos os casos, o número de
algoritmos que encontraram as melhores e as piores soluções é muito baixo.
100
80
Quantidade (%)
60
40
20
5 10 20 50 100 200 500 1.000

𝑛
Menor comprimento de rota
Comprimento de rota menor do que a média
100
80
Quantidade (%)
60
40
20
5 10 20 50 100 200 500 1.000

𝑛
Maior comprimento de rota
Comprimento de rota maior do que a média
Figura 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.
Embora o número de soluções melhores tenha sido maior do que o de soluções piores,
considerando a média, o desejável seria atingar mais estabilidade nas soluções ao reduzir a
distância das linhas das médias em relação à quantidade de soluções melhores e piores, de
forma com que as linhas azul e preta estivessem mais próximas ao topo do gráfico superior
e as linhas vermelha e preta estivessem mais próximas ao fundo do gráfico inferior. Para
conseguir essa estabilidade, isto é, encontrar melhores soluções em uma quantidade maior, é
necessário que os valores de entrada dos algoritmos sejam devidamente ajustados para cada
tamanho de instância, e que a quantidade de iterações internas sejam minimamente grandes a
ponto do algoritmo ser capaz de explorar profundamente diferentes regiões.
4.5 Comprimento de rota versus injustiça

Até 50 pontos de entrega, conseguimos obter resultados factíveis com apenas 1 carteiro,
resultando em um fator de injustiça igual a 0. Isso significa que o problema pode ser reduzido
a um TSP para essas instâncias. E caso o problema seja trabalhado dessa forma, é possível
encontrar a solução ótima ao minimizar apenas o comprimento 𝑊 (). A Figura 4.7 mostra as
melhores soluções encontradas para as cinco menores instâncias. Note a forma característica
de um TSP em todas as imagens.
Figura 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.
A partir de 100 pontos de entrega, nenhum dos algoritmos executados foi capaz de
encontrar uma solução com apenas um carteiro. Para esses casos, o fator de injustiça
representou 42,74%, 14,18%, 7,39%, e 3,10%, do comprimento de rota total para as instâncias
100, 200, 500, e 1.000, respectivamente. Na instância de tamanho 𝑛 = 100, cuja melhor
solução foi alcançada com apenas dois veículos, por exemplo, o tamanho das rotas foi muito
desproporcional. Numa situação prática, isso poderia acarretar em problemas na relação do
supervisor com os carteiros, logo a solução seria provavelmente descartada. A Tabela 4.4
mostra os melhores resultados, considerando o menor comprimento de rota, para cada
instância testada.
Tabela 4.4: As melhores soluções encontradas. O Apêndice B contém o tour das melhores
soluções para todas as instâncias.
Instância 𝑛 Alg. Troca 𝑓1 () 𝑓2 () 𝑓3 ()

RealWorldPostToy_20_0 20 AG Vértice 11229.15 1 0
RealWorldPostToy_50_0 50 GRASP Aresta 17759.02 1 0
RealWorldPostToy_100_0 100 AG Aresta 22594.76 2 9657.99
RealWorldPostToy_200_0 200 SA Aresta 32741.07 2 4642.78
RealWorldPostToy_500_0 500 AG Aresta 50555.87 3 3736.73
RealWorldPostToy_1000_0 1000 ILS Aresta 69511.11 4 2154.61
Já as instâncias com o menor fator de injustiça encontradas, otimizadas pelo comprimento

de rota, possuíram uma relação fator de injustiça por comprimento de rota muito menor: 0,07%,
0,56%, 0,85%, e 0,31%, para as instâncias 100, 200, 500, e 1.000, respectivamente. A Tabela 4.5
mostra os menores valores de injustiça encontrados ao otimizar o comprimento de rota.
Tabela 4.5: Soluções com o menor fator de injustiça.
Instância 𝑛 Alg. Troca 𝑓1 () 𝑓2 () 𝑓3 ()

RealWorldPostToy_100_0 100 TS Aresta 23303.06 2 16.42
RealWorldPostToy_200_0 200 TS Vértice 34039.47 2 189.02
RealWorldPostToy_500_0 500 ILS Vértice 52537.24 3 445.57
RealWorldPostToy_1000_0 1000 HG Aresta 80978.77 4 249.68
Esses resultados evidenciam que otimizar apenas o comprimento de rota não é uma boa
estratégia para o RWPostVRPB. As injustiças dos melhores comprimentos de rota foram,
aproximadamente, entre 8 e 600 vezes piores do que as melhores injustiças, otimizadas pelo
comprimento de rota. Em contrapartida, quando a injustiça foi melhor, o comprimento de
rota não piorou tanto (menos de 1,5% no pior caso). A Figura 4.8 mostra um exemplo dessa
diferença para a instância RealWorldPostToy_100_0.
Figura 4.8: Imagem ao topo: melhor comprimento de rota, obtido por um algoritmo AG com
troca de arestas 2-Opt. O custo total foi de 22.594,76, com 2 veículos e injustiça entre as rotas de
aproximadamente 2,7h. Imagem ao fundo: melhor 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.
Dentre as duas soluções acima, a segunda teria mais changes de ser escolhida numa
situação real de entrega, pois, apesar da rota apresentar mais de 10 minutos a mais do que na
primeira solução, os carteiros levariam praticamente o mesmo tempo para percorrer suas
respectivas rotas. Com a diferença menos evidente visualmente do que o resultado da
otimização para a instância de 100 pontos de entrega, as Figuras 4.9, 4.10 e 4.11 também
apresentam os melhores comprimentos de rota em comparação com as melhores injustiças,
obtidos nas instâncias de tamanho 200, 500, e 1.000, respectivamente.
Figura 4.9: Imagem ao topo: melhor comprimento de rota, obtido por um algoritmo 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 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).
Figura 4.10: Imagem ao topo: melhor comprimento de rota, obtido por um algoritmo AG com
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).
Figura 4.11: Imagem ao topo: melhor comprimento de rota, obtido por um algoritmo ILS com
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).
64
Capítulo 5
Conclusões
Nós trabalhamos na definição do PostVRP, uma variante multi-objetivo do VRP com restrição
no comprimento da rota. Os três objetivos a serem minimizados são: (i) o comprimento de
rota, (ii) o número de veículos e (iii) o desvio padrão (injustiça) do comprimento das rotas.
Como experimento, aplicamos alguns algoritmos para otimizar apenas o comprimento de
rota e demonstramos que essa não é a melhor forma de se resolver o problema, pois os melhores
comprimentos de rota apresentaram um fator de injustiça relativamente grande, enquanto
algumas soluções com os melhores fatores de injustiça apresentaram um comprimento de rota
menor. Isto implica que uma solução aparentemente boa pode ser ineficaz ao ser aplicada em
um problema real, logo os pesquisadores precisam definir uma boa estratégia para resolver o
problema. Tais conclusões foram possíveis através do benchmark que desenvolvemos.
Informalmente, nós listamos algumas características desejáveis de um bom benchmark:
simples; generalizável; de complexidade incremental; com funções-objetivo bem definidas;
sem informações privadas que reduzam o espaço de busca; e deve conter um modelo e uma
ferramenta de suporte.
Um “benchmark simples” possui uma quantidade razoável de informação, sem excessos.
Portanto, nós optamos por modelar um mapa no plano 2D ao invés de criar um modelo em 3D.
Nós poderíamos ter assumido novas restrições ou objetivos como, por exemplo, a velocidade
dos carteiros diminuindo com a fadiga humana. Detalhes demais podem ser negativos, então
é melhor se ater às restrições e objetivos principais do problema.
O conceito de “generalização” se refere à aplicação da metodologia a outras situações. A
metodologia que propusemos é adequada para o PostVRP, mas também pode ser adaptada a
outras variantes do VRP. O mapa foi criado como um conjunto de cadeias poligonais, logo é
Capítulo 5. Conclusões 65
relativamente simples modelar outras cidades. Também é possível, com um esforço adicional,
trabalhar com arestas direcionadas.
A “complexidade incremental” também é uma vantagem, para que seja possível analisar os
limites de um algoritmo. Um método exato pode otimizar instâncias relativamente pequenas
comparado com métodos heurísticos. Um algoritmo heurístico 𝑂(𝑛3 ) deve otimizar instâncias
menores que um outro de complexidade 𝑂(𝑛2 ). Um benchmark de complexidade incremental
permite a análise do limite de diferentes algoritmos.
Para as “funções-objetivo bem definidas”, nós utilizamos arredondamento para trabalhar
somente com valores inteiros. Mesmo a variância pode ser convertida em valores inteiros.
Minimizar 𝜎 é equivalente a minimizar 𝜎 2 𝑛(𝑛 − 1), com a segunda opção tendo um conjunto
imagem inteiro. Além disso, fornecemos um algoritmo em java que “parseia” o arquivo de
entrada e calcula o valor das funções-objetivo.
Para comparar dois algoritmos, é necessário que eles recebam a mesma informação sobre
o benchmark. Se um algoritmo tem informações exclusas do benchmark, que permitam um
início já “aquecido”, então os resultados não são comparáveis. Nesse trabalho, oferecemos
três representações das instâncias: a primeira consiste em uma matriz 𝑤𝑛×𝑛 ; a segunda, muito
mais compacta, contém o grafo do mapa; e a terceira consiste nos arquivos de entrada da
ferramenta de entregas. Um algoritmo que utiliza o grafo tem uma vantagem competitiva
sobre um algoritmo que trabalha somente com a matriz 𝑤. Dessa forma, podemos dizer que
os problemas são diferentes de acordo com a informação disponível.
Nesta pesquisa, nós propusemos um benchmark onde um modelo e uma ferramenta estão
ambos disponíveis. A ferramenta fornece um algoritmo de otimização de amostra com o
cálculo da função-objetivo e mecanismos de visualização para as instâncias. Essa forma de
representação das instâncias pode ser generalizada a outros problemas. As variáveis no
arquivo 𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒𝑠.𝑡𝑥𝑡 contêm parâmetros das instâncias, como o número de entregas,
comprimento máximo da rota, e uma semente geradora. Ao utilizar a ferramenta, nós
criamos um benchmark que modela um problema referente a um estudo de caso real das
entregas de correspondências a pé em uma cidade brasileira. As instâncias foram
classificadas em quatro grupos: (i) Toy, com até 5.000 entregas, (ii) Normal, com até 14.000
entregas, (iii) OnStrike, com até 19.000 entregas, e (iv) Christmas, com até 30.000 entregas. O
benchmark pode ser utilizado tanto para comparação como para validação de algoritmos de
otimização para roteamento de veículos.
66
Referências bibliográficas
AMAYA, A.; LANGEVIN, A.; TRÉPANIER, M. The capacitated arc routing problem with refill
points. Operations Research Letters, v. 35, n. 1, p. 45–53, 2007. ISSN 0167-6377. DOI: https:
//doi.org/10.1016/j.orl.2005.12.009.
AMINI, S.; JAVANSHIR, H.; TAVAKKOLI-MOGHADDAM, R. A PSO approach for solving

VRPTW with real case study. Int. J. Res. Rev. Appl. Sci, v. 4, n. 3, p. 118–126, 2010.
APPLEGATE, D. L.; BIXBY, R. E.; CHVATAL, V.; COOK, W. J. The traveling salesman
problem: a computational study. [S.l.]: Princeton university press, 2006.
ARROYO, J. E. C. et al. Heurísticas e metaheurísticas para otimização combinatória

multiobjetivo. [sn], 2002.
AUGERAT, P. et al. Computational results with a branch and cut code for the
capacitated vehicle routing problem. [S.l.]: IMAG, 1995.
BENT, R.; VAN HENTENRYCK, P. A two-stage hybrid local search for the vehicle routing
problem with time windows. Transportation Science, INFORMS, v. 38, n. 4, p. 515–530, 2004.
BLUM, C.; ROLI, A. Metaheuristics in combinatorial optimization: Overview and conceptual

comparison. ACM computing surveys (CSUR), Acm, v. 35, n. 3, p. 268–308, 2003.
BUF, J. H. du; KARDAN, M.; SPANN, M. Texture feature performance for image segmentation.
Pattern Recognition, Elsevier, v. 23, n. 3, p. 291–309, 1990.
BURKARD, R. E.; KARISCH, S. E.; RENDL, F. QAPLIB–a quadratic assignment problem library.
Journal of Global optimization, Springer, v. 10, n. 4, p. 391–403, 1997.
CHABRIER, A. Vehicle routing problem with elementary shortest path based column
generation. Computers & Operations Research, Elsevier, v. 33, n. 10, p. 2972–2990, 2006.
CHE, S. et al. Rodinia: A benchmark suite for heterogeneous computing. In: IEEE.
WORKLOAD Characterization, 2009. IISWC 2009. IEEE International Symposium on.
[S.l.: s.n.], 2009. p. 44–54.
CHRISTOFIDES, N. The vehicle routing problem. Combinatorial optimization.

Christofides N., Mingozzi A., Toth P., Sandi C.(eds) J. [S.l.]: Wiley & Sons, 1979.
CHRISTOFIDES, N. The vehicle routing problem. Revue française d’automatique,

d’informatique et de recherche opérationnelle. Recherche Opérationnelle, v. 10, n. 1,
p. 55–70, 1976.
CHRISTOFIDES, N.; EILON, S. An algorithm for the vehicle-dispatching problem. Or, JSTOR,
p. 309–318, 1969.
CONTARDO, C.; MARTINELLI, R. A new exact algorithm for the multi-depot vehicle routing
problem under capacity and route length constraints. Discrete Optimization, Elsevier, v. 12,
p. 129–146, 2014.
COOK, W. Traveling Salesman Problem Site. [S.l.: s.n.], 2016. (last check 01/30/2016) http:
//www.math.uwaterloo.ca/tsp/d15sol/.
CORREIA, M.; HOHENDORFF, J.; GASPAR, A. T. F. S.; SCHIOZER, D. UNISIM-II-D:

Benchmark Case Proposal Based on a Carbonate Reservoir. In: SOCIETY OF PETROLEUM
ENGINEERS. SPE Latin American and Caribbean Petroleum Engineering Conference.
[S.l.: s.n.], 2015.
CROES, G. A. A method for solving traveling-salesman problems. Operations research,

INFORMS, v. 6, n. 6, p. 791–812, 1958.
CWIEK, M.; NALEPA, J.; DUBLANSKI, M. How to Generate Benchmarks for Rich Routing
Problems? In: SPRINGER. ASIAN Conference on Intelligent Information and Database
Systems. [S.l.: s.n.], 2016. p. 399–409.
DANTZIG, G. B.; RAMSER, J. H. The truck dispatching problem. Management science,

Informs, v. 6, n. 1, p. 80–91, 1959.
DEB, K.; PRATAP, A.; AGARWAL, S.; MEYARIVAN, T. A fast and elitist multiobjective
genetic algorithm: NSGA-II. IEEE transactions on evolutionary computation, IEEE, v. 6,
n. 2, p. 182–197, 2002.
DORIGO, M.; STÜTZLE, T. Ant colony optimization: overview and recent advances. In:
HANDBOOK of metaheuristics. [S.l.]: Springer, 2019. p. 311–351.
ESPINOZA, D. G. On linear programming, integer programming and cutting planes.

2006. Tese (Doutorado) – Georgia Institute of Technology.
FISHER, M. L. Optimal solution of vehicle routing problems using minimum k-trees.

Operations research, INFORMS, v. 42, n. 4, p. 626–642, 1994.
FLOOD, M. M. The traveling-salesman problem. Operations research, INFORMS, v. 4, n. 1,

p. 61–75, 1956.
FUKASAWA, R. et al. Robust branch-and-cut-and-price for the capacitated vehicle routing

problem. Mathematical programming, Springer, v. 106, n. 3, p. 491–511, 2006.
GEHRING, H.; HOMBERGER, J. A parallel hybrid evolutionary metaheuristic for the vehicle
routing problem with time windows. In: SPRINGER BERLIN. PROCEEDINGS of EUROGEN99.
[S.l.: s.n.], 1999. v. 2, p. 57–64.
GLOVER, F.; LAGUNA, M.; MARTI, R. Principles and Strategies of Tabu Search. Handbook
of Approximation Algorithms and Metaheuristics: Methodologies and Traditional
Applications, v. 1, 2018.
GOLDEN, B. L.; WASIL, E. A.; KELLY, J. P.; CHAO, I.-M. The impact of metaheuristics on
solving the vehicle routing problem: algorithms, problem sets, and computational results. In:
FLEET management and logistics. [S.l.]: Springer, 1998. p. 33–56.
GUSSMAGG-PFLIEGL, E. et al. Heuristics for a Real-World Mail Delivery Problem. In:

Applications of Evolutionary Computation: EvoApplications 2011: EvoCOMNET,
EvoFIN, EvoHOT, EvoMUSART, EvoSTIM, and EvoTRANSLOG, Torino, Italy, April
27-29, 2011, Proceedings, Part II. Edição: Cecilia Di Chio. Berlin, Heidelberg: Springer
Berlin Heidelberg, 2011. p. 481–490. ISBN 978-3-642-20520-0. DOI:
https://doi.org/10.1007/978-3-642-20520-0_49.
HAKLAY, M.; WEBER, P. Openstreetmap: User-generated street maps. IEEE Pervasive

Computing, IEEE, v. 7, n. 4, p. 12–18, 2008.
HUANG, G. B.; RAMESH, M.; BERG, T.; LEARNED-MILLER, E. Labeled faces in the wild: A
database for studying face recognition in unconstrained environments. [S.l.], 2007.
JAWARNEH, S.; ABDULLAH, S. Sequential Insertion Heuristic with Adaptive Bee Colony
Optimisation Algorithm for Vehicle Routing Problem with Time Windows. PLOS ONE,
Public Library of Science, v. 10, n. 7, p. 1–23, jul. 2015. DOI:
https://doi.org/10.1371/journal.pone.0130224.
JOHNSON, D. S. A theoretician’s guide to the experimental analysis of algorithms. Data

structures, near neighbor searches, and methodology: fifth and sixth DIMACS
implementation challenges, v. 59, p. 215–250, 2002.
JOHNSON, D. S.; PAPADIMITRIOU, C. H.; YANNAKAKIS, M. How easy is local search?

Journal of computer and system sciences, Elsevier, v. 37, n. 1, p. 79–100, 1988.
JORION, P. Value at risk: the new benchmark for controlling market risk. [S.l.]: Irwin
Professional Pub., 1997.
JOZEFOWIEZ, N.; SEMET, F.; TALBI, E.-G. Multi-objective vehicle routing problems.
European Journal of Operational Research, v. 189, n. 2, p. 293–309, 2008. ISSN 0377-2217.
DOI: https://doi.org/10.1016/j.ejor.2007.05.055.
KALLEHAUGE, B.; LARSEN, J.; MADSEN, O. B.; SOLOMON, M. M. Vehicle routing problem
with time windows. [S.l.]: Springer, 2005.
KOHL, N. et al. 2-path cuts for the vehicle routing problem with time windows.
Transportation Science, INFORMS, v. 33, n. 1, p. 101–116, 1999.
KOLISCH, R.; SPRECHER, A. PSPLIB-a project scheduling problem library: OR

software-ORSEP operations research software exchange program. European journal of
operational research, Elsevier, v. 96, n. 1, p. 205–216, 1997.
KRIZHEVSKY, A.; SUTSKEVER, I.; HINTON, G. E. Imagenet classification with deep

convolutional neural networks. In: ADVANCES in neural information processing systems.
[S.l.: s.n.], 2012. p. 1097–1105.
KYTÖJOKI, J.; NUORTIO, T.; BRÄYSY, O.; GENDREAU, M. An efficient variable neighborhood
search heuristic for very large scale vehicle routing problems. Computers & Operations
Research, v. 34, n. 9, p. 2743–2757, 2007. ISSN 0305-0548. DOI: https://doi.org/10.

1016/j.cor.2005.10.010.
LI, F.; GOLDEN, B.; WASIL, E. Very large-scale vehicle routing: new test problems, algorithms,
and results. Computers & Operations Research, Elsevier, v. 32, n. 5, p. 1165–1179, 2005.
LOURENÇO, H. R.; MARTIN, O. C.; STÜTZLE, T. Iterated local search. In: HANDBOOK of
metaheuristics. [S.l.]: Springer, 2003. p. 320–353.
MEIRA, L. A. A.; ZENI, G. A.; MENZORI, M.; MARTINS, P. S. PostVRP Project Site (Last
checked Oct–2019). [S.l.: s.n.], jun. 2019. Disponível em: <http://www.ft.unicamp.br/
~meira/postvrp>.
MEIRA, L. A.; MARTINS, P. S.; MENZORI, M.; ZENI, G. A. How to assess your Smart Delivery
System?: Benchmarks for rich vehicle routing problems. In: SMART Delivery Systems. [S.l.]:
Elsevier, 2020. p. 227–247.
METROPOLIS, N. et al. Equation of state calculations by fast computing machines. The

journal of chemical physics, AIP, v. 21, n. 6, p. 1087–1092, 1953.
NGUYEN, H. D.; YOSHIHARA, I.; YAMAMORI, K.; YASUNAGA, M. Implementation of an

effective hybrid GA for large-scale traveling salesman problems. IEEE Transactions on
Systems, Man, and Cybernetics, Part B (Cybernetics), IEEE, v. 37, n. 1, p. 92–99, 2007.
PECIN, D.; PESSOA, A.; POGGI, M.; UCHOA, E. Improved branch-cut-and-price for capacitated
vehicle routing. In: INTEGER programming and combinatorial optimization. [S.l.]: Springer,
2014. p. 393–403.
POLMEAR, I.; STJOHN, D.; NIE, J.-F.; QIAN, M. Light alloys: metallurgy of the light
metals. [S.l.]: Butterworth-Heinemann, 2017.
REINELT, G. TSPLIB—A traveling salesman problem library. ORSA journal on computing,

INFORMS, v. 3, n. 4, p. 376–384, 1991.
REINELT, G. Tsplib95. [S.l.], 1995.
RENAUD, J.; LAPORTE, G.; BOCTOR, F. F. A tabu search heuristic for the multi-depot vehicle
routing problem. Computers & Operations Research, Elsevier, v. 23, n. 3, p. 229–235, 1996.
RESENDE, M. G.; MATEUS, G. R.; SILVA, R. GRASP: Busca gulosa aleatorizada e adaptativa.
Parte: http://hdl.handle.net/10316.2/5655, Imprensa da Universidade de Coimbra, 2012.
RINKER, D. C.; SPECIAN, N. K.; ZHAO, S.; GIBBONS, J. G. Polar bear evolution is marked by
rapid changes in gene copy number in response to dietary shift. Proceedings of the National
Academy of Sciences, National Acad Sciences, p. 201901093, 2019.
SIMON, D. Evolutionary optimization algorithms. [S.l.]: John Wiley & Sons, 2013.
SOLOMON, M. M. Algorithms for the vehicle routing and scheduling problems with time
window constraints. Operations research, Informs, v. 35, n. 2, p. 254–265, 1987.
TALBI, E.-G. Metaheuristics: from design to implementation. [S.l.]: John Wiley & Sons,
2009. v. 74.
TAN, K. C.; CHEW, Y.; LEE, L. H. A hybrid multi-objective evolutionary algorithm for solving
truck and trailer vehicle routing problems. European Journal of Operational Research,
Elsevier, v. 172, n. 3, p. 855–885, 2006.
TOL, R. S. Estimates of the damage costs of climate change. Part 1: Benchmark estimates.
Environmental and Resource Economics, Springer, v. 21, n. 1, p. 47–73, 2002.
UCHOA, E.; PECIN, D.; PESSOA, A.; POGGI, M.; SUBRAMANIAN, A. et al. CVRP Library
Site (Last checked Sep–2017). [S.l.: s.n.], 2017. Disponível em: <http://www.galgos.
inf.puc-rio.br/vrp/>.
UCHOA, E.; PECIN, D.; PESSOA, A.; POGGI, M.; VIDAL, T. et al. New benchmark instances
for the Capacitated Vehicle Routing Problem. European Journal of Operational Research,
v. 257, n. 3, p. 845–858, 2017. ISSN 0377-2217. DOI: https://doi.org/10.1016/j.ejor.
2016.08.012.
WATERLOO, U. of. D15112: Optimal Solution (Last checked Mar–2020). [S.l.: s.n.], abr.
2005. Disponível em: <http://www.math.uwaterloo.ca/tsp/d15sol/computation
/d15112_sol.html>.
WATERLOO, U. of. pla85900 Home > Pictures > Large Line (Last checked Mar–2020).
[S.l.: s.n.], set. 2007. Disponível em: <http://www.math.uwaterloo.ca/tsp/pla8590
0/tours/pla8tour_large.htm>.
WATERS, C. A solution procedure for the vehicle-scheduling problem based on iterative

route improvement. Journal of the Operational Research Society, Springer, v. 38, n. 9,
p. 833–839, 1987.
71
Apêndice A
Instâncias Geradas
Tabela A.1: Todas as instâncias do Manhattan.
Instância # Entregas Comprimento (m) # Veículos (max)

ManhattanPilot_3_0 3 4999.955 5
Apêndice A. Instâncias Geradas 72

ManhattanPilot_1000_0 1000 4999.955 5
ManhattanPilot_1000_1 1000 4999.955 5
ManhattanPilot_1000_2 1000 4999.955 5
ManhattanPilot_5000_0 5000 4999.955 5
ManhattanPilot_5000_1 5000 4999.955 5
ManhattanPilot_5000_2 5000 4999.955 5
Tabela A.2: Todas as instâncias do RWPostVRPB.
Instância # Entregas Comprimento (hrs) # Veículos (max)

RealWorldPostToy_3_0 3 6 5
RealWorldPostNormal_10000_0 10000 6 30
RealWorldPostOnStrike_15000_0 15000 8 30
RealWorldPostChristmas_20000_0 2000 8 30
75
Apêndice B
Rota das Melhores Soluções Obtidas
NAME : genetic_algorithm_2019-12-08_17-57-09.tour
COMMENT : RealWorldPostToy_3_0 solution achieved by Genetic Algorithm algorithm
TYPE : TOUR
DIMENSION : 3
MIN_LENGTH : 6023.937832
MIN_VEHICLES : 1
MIN_FAIRNESS : 0,00
TOUR_SECTION
1 3 2
EOF
Figura B.1: Melhor solução encontrada para o RealWorldPostToy_3_0, considerando o

comprimento de rota.
TYPE : TOUR
DIMENSION : 5
MIN_LENGTH : 3742.1097670000004
MIN_VEHICLES : 1
MIN_FAIRNESS : 0,00
TOUR_SECTION
3 5 2 1 4
EOF

Apêndice B. Rota das Melhores Soluções Obtidas 76
TYPE : TOUR
DIMENSION : 10
MIN_LENGTH : 8103.1093759999985
MIN_VEHICLES : 1
MIN_FAIRNESS : 0,00
TOUR_SECTION
1 8 7 5 4 3 2 10 6 9
EOF

TYPE : TOUR
DIMENSION : 20
MIN_LENGTH : 11229.149347
MIN_VEHICLES : 1
MIN_FAIRNESS : 0,00
TOUR_SECTION
18 9 3 5 13 14 12 17 4 19 1 2 10 6 16 15 11 8 7 20
EOF

NAME : grasp_2019-12-05_08-30-48.tour
COMMENT : RealWorldPostToy_50_0 solution achieved by Grasp algorithm
TYPE : TOUR
DIMENSION : 50
MIN_LENGTH : 17759.015403999998
MIN_VEHICLES : 1
MIN_FAIRNESS : 0,00
TOUR_SECTION
8 10 17 32 46 33 25 14 19 2 47 27 24 1 20 13 15 11 31 23 16 5 4 42 37 3 21 30 36 29 48
34 9 35 49 26 38 40 28 22 44 39 43 45 7 12 41 50 18 6
EOF

TYPE : TOUR
DIMENSION : 100
MIN_LENGTH : 22594.755909999996
MIN_VEHICLES : 2
MIN_FAIRNESS : 9657,99
TOUR_SECTION
86 36 43 7 77 39 70 50 92 19 100 63 53 6 59 64 78 87 38 14 45 29 24 15 69 46 89 44 82
9 35 90 95 74 52 40 23 65 51 13 84 42 85 3 93 48 21 60 10 61 20 57 88 16 2 17 94 75 56
27 71 98 32 99 76 1 25 11 47 97 79 33 96 55 66 49 68 26 31 8 80 12 83 58 91 81 37 4 34
73 41
72 62 54 5 67 22 30 28 18
EOF

NAME : simulated_annealing_2019-12-01_20-52-18.tour
COMMENT : RealWorldPostToy_200_0 solution achieved by Simulated Annealing algorithm
TYPE : TOUR
DIMENSION : 200
MIN_LENGTH : 32741.073537999997
MIN_VEHICLES : 2
TOUR_SECTION
78 68 143 126 177 167 81 198 108 23 25 28 191 90 186 96 36 173 37 8 7 154 131 184 76 93
95 164 39 77 151 156 30 16 159 155 62 101 15 175 53 45 3 74 66 162 116 48 84 107 20 80
194 132 29 140 38 150 87 165 185 196 65 170 128 166 43 183 34 124 73 35
42 161 89 121 9 6 46 24 138 158 97 113 180 199 51 172 163 109 142 111 115 152 31 179 57
1 67 69 26 197 119 47 120 10 99 82 12 122 44 88 92 112 56 79 64 130 136 52 189 100 168
22 17 200 103 127 32 153 160 193 11 174 118 149 33 137 114 98 178 60 19 129 169 105 195
139 63 5 171 148 4 50 102 86 94 125 2 91 190 134 187 14 27 71 18 133 70 181 117 85 61
72 41 144 182 49 13 104 75 135 192 40 106 145 83 59 176 54 58 157 146 110 55 21 141 123
147 188
EOF

TYPE : TOUR
DIMENSION : 500
MIN_LENGTH : 50555.867155000014
MIN_VEHICLES : 3
TOUR_SECTION
332 493 396 333 44 146 118 211 84 284 315 20 439 295 409 453 267 297 76 385 201 225 51
189 251 239 381 323 260 59 50 71 285 402 364 391 29 45 177 448 160 416 486 245 473 269
153 8 479 350 108 370 374 78 481 289 472 42 134 484 437 141 166 72 496 335 347 257 220
262 317 13 185 187 492 442 367 195 236 476 427 247 6 498 389 5 273 420 490 246 294 491
219 214 81 135 104 265 53 376 463 363 423 19 480 60 434 88 356 26 89 465 394 205 52 119
290 313 308 433 455 157 380 92 39 184 125 292 378 175 410 34 454 302 90 430 276 7 32
73 305 64 281 179 361 451 311 266 478 471 319 287 331 12 10 68 252 17 180 178 446 115
372 101 182 111 334 386 249 121 94 63 21 325 150 22 65 238 254 421 369 202 123 424 264
497 248 83 49 499 443 321 382 235 309 148 388 223 320 142 296 467 346 62 204 494 124 25
460 128 132 27 67 259 500 482 82 58 316 475 324 379 40 87 425 48 233 55 483 261 241 199
164 337 229 130 286 227 489 422 255 197 4 329 136 429 237 86 358 400 283 353 280 145 47
418 447 298 477 341 485 209 30 414 415 244 43 106 436 61 340 256 152 102 293 144 169
212 428 495 228 38 445 11 149 365 272 2 411 360 487 173 307 345 406 107 190 413 464 392
263 54 314 444 274 129 46 440 37 351 310 275 359 408
171 343 172 151 114 113 158 217 188 357 216 230 162 432 194 69 192 154 33 466 14 390
452 24 138 218 270 243 268 242 70 336 474 28 15 127 80 137 198 279 183 398 93 271 168
221 18 404 344 342 57 1 9 306 304 213 431 100 435 224 301 300 91 441 282 77 191 449 143
147 117 366 167 96 397 207 131 362 163 393 186 456 122 470 206 468 75 105 231 155 349
103 126 23 222 399 253 328 97 426 299 203 176 355 354 215 16 450 66 277 375 159 348 36
371 303 318 488 85 377 165 208 98 95 41 459 401 373 140 461 258 193 110 288 387 322 156
278 226 330 405 31 469 327 120 200 352 56 384 326 403 99 74 139 383 3 79 407 35 458 419
181 232 417 457 170 338 438 210 250 395 133 240 368 116 339 109 174 291 462 161 412 112
312 234 196
EOF

NAME : iterated_local_search_2019-12-02_14-06-30.tour
COMMENT : RealWorldPostToy_1000_0 solution achieved by Iterated Local Search algorithm
TYPE : TOUR
DIMENSION : 1000
MIN_LENGTH : 69511.10527199978
MIN_VEHICLES : 4
TOUR_SECTION
993 455 843 982 142 124 50 246 209 414 963 254 504 828 979 767 550 91 360 507 615 298
489 364 617 491 217 624 467 934 295 212 635 338 187 388 188 943 326 755 16 462 302 215
359 898 372 815 571 367 729 802 942 2 669 178 945 128 446 620 578 223 610 719 795 664
103 286 542 195 441 421 419 823 381 284 607 913 399 937 156 516 895 590 568 104 830
517 952 144 493 193 101 357 668 380 256 741 589 835 41 780 841 992 985 345 709 313 452
547 175 565 915 936 655 842 22 506 97 723 429 37 318 961 415 46 510 878 808 294 92 984
167 257 822 454 656 162 523 159 969 291 86 5 198 737 23 922 562 314 290 358 494 386
283 717 916 665 425 592 407 378 252 248 525 770 472 465 801 593 17 999 478 93 905 473
280 881 832 998 636 686 927 134 640 612 69 169 106 774 457 813 84 872 333 584 896 464
308 783 214 646 329 30 406 35 726 545 735 930 690 883 975 4 11 418 296 132 102 742 453
311 803 569 47 561 190 120 679 346 700 791 71 352 848 794 72 678 825 426 312 384 319
824 368 923 438 910 459 567 417 189 540 287 118 220 573 300 707 349 344 339 904 24 19
804 575
917 105 596 423 61 574 274 891 699 555 90 897 138 760 202 404 827 854 987 836 712 560
213 839 796 29 186 288 27 430 864 536 183 483 137 503 659 557 299 672 745 154 683 924
957 63 685 763 811 505 887 779 383 633 65 78 148 731 276 771 363 481 3 892 849 385 692
492 194 527 249 747 631 661 644 475 544 652 335 518 572 52 232 49 859 667 285 653 777
765 145 440 394 537 21 347 845 884 981 100 932 549 210 443 263 152 965 33 15 34 908
748 149 70 933 554 62 432 789 292 846 205 68 74 174 869 113 340 401 251 902 941 427
576 390 512 733 743 694 865 66 508 674 960 533 718 45 766 6 817 532 391 260 133 997
725 851 582 143 89 395 153 226 270 641 716 814 890 109 871 882 977 880 894 889 463 416
96 456 25 165 356 501 956 946 402 649 225 57 39 637 591 566 758 914 751 353 216 163
621 461 115 754 587 243 236 970 185 181 259 80 950 460 524 307 81 83 931 306 224 684
231 277 297 255 986 88 387 54 833 211 680 806 958 247 129 782 301 650 972 638 146 776
150 911 242 141 14 466 629 724 99 7 208 753 645 155 601 781 403 192 826
785 409 85 8 448 422 177 434 559 219 702 647 166 125 13 36 127 906 393 852 73 773 253
855 451 450 408 389 325 797 632 988 369 207 944 790 820 973 990 964 230 172 968 792
732 486 116 611 135 909 173 229 885 671 903 548 706 805 953 721 238 639 750 714 235
710 784 959 762 392 436 179 332 673 623 701 442 107 967 191 158 471 271 989 470 761
642 682 479 139 164 799 844 588 583 67 939 618 949 577 928 800 847 873 281 75 818 893
273 834 244 480 261 983 241 919 316 752 546 860 87 218 954 551 12 373 529 625 305 147
328 877 468 122 626 602 370 320 764 310 840 651 749 161 698 31 365 119 579 10 444 929
130 552 861 204 663 853 26 222 769 662 322 9 809 614 112 354 736 603 886 876 482 182
971 734 628 613 534 197 341 131 947 258 622 55 321 920 449 863 176 433 43 77 140 199
337 821 978 32 925 233 28 18 267 966 691 40 807 342 619 330 695 485 689 180 703 829
289 265 838 868 681 268 350 976 543 962 95 278 200 400 995 658 428 123 693 227 411 787
48 206 722 738 688 605 1000 810 245 1 918 926 666 744 608 899 51 901 327 974 675 514
606 600 556 362 705 772 522 94 994 697 437 269 317 264 397 275 570 279 581 474 708 82
756 447 496 398 171 951 866 875 38 955 867
996 458 323 563 266 396 677 862 114 351 687 221 728 746 439 348 412 850 324 151 309
870 374 499 382 586 715 858 59 670 262 79 413 768 535 704 282 379 375 775 405 431 720
778 76 980 56 530 599 498 476 136 616 484 366 538 594 580 477 528 991 948 497 539 237
111 696 355 228 907 713 727 553 819 371 500 812 520 786 377 184 20 541 740 488 203 420
361 757 42 793 110 117 837 564 521 303 53 856 126 98 519 874 526 739 157 627 759 201
900 597 196 857 168 490 376 831 304 888 921 509 445 336 60 798 604 595 598 469 879 634
334 170 121 343 424 495 788 660 676 272 44 630 293 730 315 58 515 657 585 711 643 654
239 160 938 940 108 935 609 558 240 331 511 234 531 912 64 816 250 513 435 410 487 648
502
EOF


Zeni GuilhermeAlmeida M PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Zeni GuilhermeAlmeida M PDF

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE ESTADUAL DE CAMPINAS

Guilherme Almeida Zeni

Modelagem de um benchmark para o problema de

Modelagem de um benchmark para o problema de roteamento de

Dissertação apresentada à Faculdade de Tecnologia

Orientador: Prof. Dr. Luis Augusto Angelotti Meira

Este exemplar corresponde à versão final da

Zeni, Guilherme Almeida, 1992-

ZenOrientador: Luis Augusto Angelotti Meira.

Zen1. Problema de roteamento de veículos. 2. Otimização multiobjetivo. 3.

Informações para Biblioteca Digital

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

Powered by TCPDF (www.tcpdf.org)

Abaixo se apresentam os membros da comissão julgadora da sessão pública de defesa de dis-

Prof. Dr. Luis Augusto Angelotti Meira

Prof. Dr. Anibal Tavares de Azevedo

Prof. Dr. Guilherme Palermo Coelho

Ata da defesa, assinada pelos membros da Comissão Examinadora, consta no SIGA/Sistema de

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

O número de técnicas de otimização no domínio combinatório é grande e diversificado.

Palavras-chave: benchmark, roteamento de veículos, otimização em larga escala, otimização

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

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

3.1 Exemplo de vértices do VRP (esquerda) e uma solução

B.1 Melhor solução encontrada para o RealWorldPostToy_3_0, considerando o

2.1 Instâncias do TSPLib. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Arquivo de instância. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

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

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

1 Algoritmo para criar as entregas. . . . . . . . . . . . . . . . . . . . . . . . . . . 29

B Rota das Melhores Soluções Obtidas 75

Tabela 2.1: Instâncias do TSPLib.

Problema # Instâncias # Vértices

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

Neste capítulo, descreveremos todas as etapas do desenvolvimento dessa pesquisa. O

3.1 Definindo a variante PostVRP

Figura 4: Exemplo de Intância Figura

Figura 3.1: Exemplo deToda vértices

Todas as rotas começam

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

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

Finalmente, é necessário que a solução atenda a um critério de justiça, isto é, as rotas

O VRP é um conjunto de problemas que consiste na visita de clientes através de veículos.

Definição 1 (PostVRP) . Dado um conjunto de elementos 𝑆, uma função de custo 𝑤 ∶ 𝑆 × 𝑆 →

3.2 Descrição do modelo

3.2.1 Gerando os pontos de entrega

𝑃𝑟𝑜𝑏(𝑒) é diretamente proporcional ao comprimento da aresta 𝑤 ′ (𝑒) e à sua densidade de

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

3.2.2 Estabelecendo o custo entre um par de entregas

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

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

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

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

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

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

3.3 A ferramenta para o benchmark

• 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;

• Atributos: atributos utilizados para computar a densidade de probabilidade da rua e o

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

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