eindhoven university of technology master heuristic
TRANSCRIPT
Eindhoven University of Technology
MASTER
Heuristic solutions to the vehicle routing problem with mixed backhauls in a high value sector
Lancée, M.
Award date:2015
Link to publication
DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.
General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain
1
Eindhoven, August 2015
Martijn Lancée
Bsc. Industrial Engineering – TU/e
Student identity number 0681737
in partial fulfillment of the requirements for the degree of Master of Science
in Operations Management and Logistics University supervisors: Dr. E. (Emrah) Demir, TU/e, OPAC Prof. Dr. T. (Tom) Van Woensel, TU/e, OPAC Company supervisors: W. (Wil) Louvet, Idealogistic Verhoeven
L. (Louis) Bardoel, Idealogistic Verhoeven
Heuristic solutions to the vehicle
routing problem with mixed
backhauls in a high value sector
2
Keywords: Vehicle routing problem, mixed backhauls, time windows, heterogeneous fleet, high-value
freight, transportation, heuristics, TAPA
3
Abstract This master thesis develops a heuristic based script that solves a complex vehicle routing problem with
up to 250-300 customers in a company that is specialized in transporting high value goods. The solution
to this problem can also be used to determine average load factors, fuel emission rates and other
performance indicators. It is to be used as a decision support tool for the management in their search
for such a tool for the Benelux and other planning departments. The focus lies in reaching feasible
solutions for planners to work with in limited time, but in order to aid the department in reserving
resources such as trailers also a regression is done. The routing solver is developed in three phases.
Phase one is where the working methods of the department are analyzed and a general concept for
the solver is made to ensure usability. Phase two is the actual development where the amount of
constraints are set and weighed against complexity – thus calculation time. In phase three the results
of the solver are compared to the planning made by the department in a case study and a look ahead
into implementation scenarios is made.
4
Executive Summary Road transportation is a big part of the integral supply chain and has mostly been the main way of
transporting goods throughout Europe. The direct costs of road transportation have been increasing
since 2000 and even more so in recent years. Since the economic crisis, logistics service providers have
to focus more on their planning and execution and areas of expertise in order to survive.
Goal The research project that is presented in this thesis, is the result of the cooperation with a Dutch based
leading logistics service provider in secure and fast transport, Idealogistic Verhoeven, henceforth called
IDLV. The research is focused to the operational day-to-day planning for the short hauls within the
Benelux area. The Benelux planning department handles 300-400 requests per day and has to respect
a high number of practical constraints that are the result of their specialized secure transportation,
such as numerous vehicle type constraints, time windows, container loading and the fact that IDLV
operates with mixed backhauls. At the same time, a new transport management system is being
prepared for implementation. Thus the goal of this research was to develop a model that quantifies
the planning process along with all its constraints, that can solve the planning problem and if
implemented can reduce the workload on employees and reduce cost drivers within the execution.
Present situation The transport management system at this point supports the diversion of one order into multiple
planning lines: separated into pickup orders, delivery orders and more such as transshipment, long
haul or storage. Planning lines consist of quantities, time windows (although in text format), high value
specifications, other vehicle requirements (also in text format), addresses and unique ID numbers.
These are the inputs for planners to manually create a planning using a detailed hard copy map of the
Benelux. There are some issues concerned with the manually made planning: it is a time consuming
task and the result is an inflexible planning that is hard to test for mistakes. The knowledge required
to make the planning is nested in human capital. Some of the constraints that planners take into
account are:
Time windows
Three dimensional container loading
Customer location related vehicle constraints
Order related vehicle constraints
Capacity calculation complexity from mixed backhauls
Direct order deliveries without transshipment
Maximum tour length
Maximum working hours
Driver scheduling
Reserving trailer space for possible on-line pickup orders
Model The original purpose was to develop a model that could solve the vehicle routing problem with mixed
backhauls, and which could decide between direct shipments and shipments over the depot. However,
the logistics and temporal structures within the transport management system make the problem too
complex. Together with this, a distinct need for a prediction model for resource reservation became
clear. Therefore a regression model was made for the prediction of numbers of trailers, together with
a tool that can solve the vehicle routing problem with mixed backhauls and the other constraints that
5
exist. Also, a green extension to the routing tool was made, to shift the objective away from distance
minimization, to CO2 and CO2e emissions minimization.
If both the regression model and the routing tool were to be implemented, the following decisions
were to be shifted towards or supported by the models:
DECISIONS SUPPORTING BENELUX AREA PLANNERS REGRESSION MODEL
ROUTING TOOL
DRIVER ALLOCATION ✓
DECISIONS OF ASSIGNING ORDERS TO CHARTER
✓
ESTIMATING RESOURCES NEEDED ✓
MAPPING OF LOCATIONS ✓ CONSOLIDATION ✓ FEASIBILITY CHECK ✓ DESIGNING ROUTES ✓ KPI CALCULATION ✓ CREATING LOAD PLAN FOR TRANSSHIPMENT
✓
In particular, a case study confirms that when the tool solves the vehicle routing problem with mixed
backhauls and true fleet heterogeneity, it can attain a direct fuel related cost saving of 20%, together
with reducing distances with 25%. Apart from the direct cost savings, there are also plenty ‘soft’
savings. The time it takes to develop a planning can be reduced with 80%, and the tool can also serve
as a feasibility checker, thus relieving the planners of some of their tasks. The load factors per ride, and
over the entire planning can now be calculated so that capacity utilization is guaranteed.
Implementation would also mean the automated generation of loading plans, to which end the way
could be paved for the transshipment center to look into options for automating some scheduling for
their own. Also, the regression model takes away the guessing that is currently done about resource
reservation and allows IDLV to make investment decisions in new resources vs outsourcing.
Consequently the implementation of both the regression model and a routing tool can help planners
achieve feasible, better solutions to their planning tasks, while also reducing the time and effort
needed to come to these decisions. Please do note that during this project it has never been the
intention of the author nor the company to replace the planners’ tasks with that of automated systems.
In contrast, due to the human capital focus that IDLV prides itself in, these tools are designed to
facilitate planners in their tasks. Therefore the solutions generated should be addressed as an initial
sketch with which the planners can design final solutions, or as KPI indicators which help planners
make decisions.
Recommendations We would recommend IDLV, first of all to implement a routing software package. It has been shown
that even though IDLV has complex operations and specific constraints, it is possible to tailor a
standard package to their needs to come to feasible solutions. Because of the calculation speed and
reliability issues, a tool that runs in VBA is not suited for such a professional company with high safety
standards. Therefore, when IDLV is finished implementing their new TMS, it would be very wise to look
into more professional packages. One option would be to hire a programmer and rewrite some code
to work in a more reliable and faster shell, together with professional modules for geocoding and road
6
distance calculation. Another option would be to use the constraints addressed in this thesis as well as
the pseudocode to handle them and use this to tailor fit a professional package to their TMS.
The reasons for implementing this tool are twofold. First off, generous cost and emission savings can
be attained. On the other hand, assisting planners in their work and valuing human capital has always
been a high standard at IDLV and implementing a routing software package will aide planners
noticeably. Also these types of automations can be the start of automating other operations, and they
visualize better the KPIs that IDLV has.
As a final recommendation we urge IDLV to use the regression model, but update the proposed
correction factor until the sample size for a new regression based on material instead of rides is about
that of one year. The regression tool can be a very simple but effective way to familiarize planners with
automated solutions that may come in the future.
7
Preface This report is the result of the final stage of my master education ´Operations Management and
Logistics´ at the Eindhoven University of Technology. I have been given the chance to perform this
project at Idealogistic Verhoeven, where complex routing problems are solved daily. Idealogistic has
given me a lot of freedom in the project, so that I could not only practice the academic part of the
project, but also grow in terms of communications, expectancy management and implementation
skills.
I could not have come to such results without the help and support of the company. The operational
director and general manager have guided me personally throughout the process. I would therefore
like to thank operational director Louis Bardoel for making time and thinking along with me. He and
his practical knowledge of the work environment has helped me to keep a focus on making the final
product usable, and helped me set a scope. I would also like to thank Will Louvet for entrusting me
with this project. Furthermore, Will has challenged me to improve other skills such as my
communicational skill and I really enjoyed discussing other matters such as career paths and even a bit
of philosophy. Finally I would like to thank all the other stakeholders in the company who made me
feel welcome, were very interested in the project and all helped me where they could.
From the university I would like to thank dr. Emrah Demir, my first supervisor. Emrah and I share the
interest in the practical applicability of vehicle routing research and it was always very interesting to
discuss matters I came across at the company. He took his time to answer my questions and I always
felt as if he was up-to-date about my progress. I would also like to thank prof. dr. Tom van Woensel
for taking the time to read and assess the quality of this thesis.
From my personal surroundings I would like to thank my mother and father for supporting me both
financially and emotionally during these years, my little brother and best friend and my fellow students
and dear friends with whom I have done a lot of studying, Erwin, Vital and Bram. Finally I also have to
thank my roommates for allowing me to vent some steam during these years, Thijs and Steven.
8
Contents Abstract ................................................................................................................................................... 3
Executive Summary ................................................................................................................................. 4
Goal ..................................................................................................................................................... 4
Present situation ................................................................................................................................. 4
Model .................................................................................................................................................. 4
Recommendations .............................................................................................................................. 5
Preface ..................................................................................................................................................... 7
List of Abbreviations .............................................................................................................................. 10
Chapter 1: Introduction ................................................................................................................... 11
1.1 Fleet description .................................................................................................................... 12
1.2 IDLV’s logistic network .......................................................................................................... 12
1.3 Overview ................................................................................................................................ 13
Chapter 2: Assignment .................................................................................................................... 14
2.1 Literature review ................................................................................................................... 14
2.1.1 Research area ................................................................................................................ 14
2.1.2 Container loading .......................................................................................................... 14
2.1.3 Vehicle routing problems .............................................................................................. 15
2.1.4 Green logistics ............................................................................................................... 16
2.1.5 Vehicle routing algorithms, heuristics and metaheuristics ........................................... 17
2.1.6 Combinatorial problems in freight transport ................................................................ 17
2.1.7 Literature gaps ............................................................................................................... 18
2.2 Research questions................................................................................................................ 18
2.3 Scope ..................................................................................................................................... 18
Chapter 3: Performance analysis .................................................................................................... 20
3.1 Order arrival process ............................................................................................................. 20
3.2 Ride planning ......................................................................................................................... 21
3.3 Transshipment ....................................................................................................................... 23
3.4 Volume analysis ..................................................................................................................... 23
3.4.1 Volumes and factors ...................................................................................................... 24
3.4.2 Pattern identification .................................................................................................... 25
3.4.3 Regression analysis ........................................................................................................ 28
3.4.4 Analysis of green indicators ........................................................................................... 30
Chapter 4: Mathematical modeling ................................................................................................ 33
4.1 General information on VRP models ..................................................................................... 33
4.2 Mixed integer linear programming problem ......................................................................... 34
9
Chapter 5: Development of decision support model ...................................................................... 36
5.1 Comparing alternatives ......................................................................................................... 36
5.1.1 Communities ................................................................................................................. 36
5.1.2 Applications ................................................................................................................... 36
5.1.3 Engines and web services .............................................................................................. 37
5.2 VRP-model ............................................................................................................................. 38
5.2.1 Revised VRP-model with Mixed Backhauls (MB)........................................................... 39
5.2.2 Revised VRPMB-model with true fleet heterogeneity .................................................. 42
5.2.2 Revised HFVRPMB-model with faster LNS heuristic ..................................................... 44
5.3 Revised HFVRPMB-model with green extension (G-HFVRPMB) ........................................... 45
5.5 Revised geocoding and distance matrix ................................................................................ 46
5.6 Discussion .............................................................................................................................. 46
Chapter 6: Computational studies .................................................................................................. 48
6.1 Computational study: Faster LNS heuristic analysis .............................................................. 49
6.1.1 Description of case ........................................................................................................ 49
6.1.2 Case study results .......................................................................................................... 50
6.2 Computational study: LNS operator analysis ........................................................................ 51
6.2.1 Description of case ........................................................................................................ 51
6.2.2 Case study results .......................................................................................................... 52
6.3 Green extension analysis ....................................................................................................... 54
6.3.1 Description of the case .................................................................................................. 54
6.3.2 Case study results .......................................................................................................... 55
Chapter 7: Real life case studies ...................................................................................................... 56
7.1 Description of the case .......................................................................................................... 56
7.2 Case study results .................................................................................................................. 57
7.2.1 Actual results from the planning department ............................................................... 57
7.2.2 Results from the solver .................................................................................................. 58
7.3 Case study conclusions .......................................................................................................... 59
Chapter 8: Conclusions .................................................................................................................... 60
8.1 Limitations ............................................................................................................................. 61
8.2 Implementation ..................................................................................................................... 61
8.3 Recommendations................................................................................................................. 62
8.4 Future research ..................................................................................................................... 62
9 Appendix ........................................................................................................................................ 64
9.1 tables and images .................................................................................................................. 64
9.1.1 Planning process according to the quality manual....................................................... 64
10
9.1.2 Order arrival and planning process, gathered from interviews ...................................... 0
9.1.3 Screenshot planning lines ................................................................................................ 0
9.1.4 Screenshot of the obtained per-day overview ................................................................ 0
9.1.5 Benelux fleet emission numbers for January 2015 ......................................................... 1
9.1.6 Case study customer locations for dataset A-50 through A-250 .................................... 2
9.1.7 Case study customer locations for dataset B-50 through B-300 ..................................... 7
9.1.8 Screenshot of the original solver’s console worksheet ................................................. 13
9.1.9 Screenshot of the revised solver’s console worksheet ................................................. 14
9.2 References ............................................................................................................................. 15
List of Abbreviations IDLV Idealogistic Verhoeven
TMS Transport Management System
VBA Visual Basic for Applications
VRP Vehicle Routing Problem
VRPMB Vehicle Routing Problem with Mixed Backhauls
HV/HR High Value/High Risk
ODL Open Door Logistics
VeRoLog EURO Working Group on Vehicle Routing and Logistics Optimization
CO2 Carbon dioxide
CO2e Carbon dioxide equivalent. CO2e allows other greenhouse gas emissions to be expressed in terms of CO2 based on their relative global warming potential
LNS Large Neighborhood Search
TAPA Transported Asset Protection Association
LSP Logistics Service Provider
3PL Third-party Logistics Service Provider
LTL Less than truckload
FTL Full truckload
11
Chapter 1: Introduction IDLV operates as a shipper and third party logistics provider in the axis from Ireland to Poland and
Slovakia. The main office and west-European international and Benelux distribution planning hub is
situated in Uden and also functions as a transport hub for the Benelux area. The eastern-European
international planning hub is situated in Poznan. IDLV owns 11 other hubs and a fleet of 62 trucks.
These other hubs are self-regulatory. Within the network created by connecting these 13 hubs, IDLV
operates long-hauls. From the hubs to customer addresses, the short-hauls - either pickups or
deliveries - are orchestrated. IDLV offers its customers groupage shipments, LTL and FTL shipments. All
hauls are executed using trucks, meaning that there is no inter-modality.
A subset of the orders transported by IDLV may be susceptible to theft and can be classified as HV/HR
(high value/high risk). For this special kind of order more constraints have to be considered. Within
this classification, another six classifications exist, each with their own constraints. These constraints
can apply to specifications on the following areas: Trailers, trucks, drivers, routes, stopping locations
and monitoring. The rich amount of constraints make IDLV an interesting case, where academic
research can meet practical situations.
Decision making for long-hauls and short-hauls in certain areas of Europe is split up to different
responsible departments. In both processes of planning rides, some support is currently available for
planners in a somewhat dated transport management system (TMS). The support is in form of an
overview of all the addresses that need to be visited on a certain day, which the dimensions and weight
of the order. Other information such as the time window for delivery is also available, although not
standardized but as a separate comment.
This TMS is to be updated between the second half of 2015 and the beginning of 2016. It is a long
awaited update for which its’ underneath structures are changed significantly. This operation will be
costly and time consuming, but more possibilities for automation and planner support will become
available. The supplier of the TMS offers routing software components from a partnering company,
but these come at a high price, intense integration and results cannot be measured beforehand.
IDLV has been growing for a long time and even during the crisis, positive profits have been attained,
superseding other transportation service providers.
IDLV has a strong open culture where human capital is highly valued and personal growth is stimulated.
Colleagues can enter the company as a truck driver and if wanted are challenged to grow into more
responsibilities. The company prides itself in these trajectories and sees the value of colleagues having
relevant knowledge of all aspects of the company in order to make the best decisions. That said, the
amount of orders to be handled by the Benelux short haul planning department on a daily basis is
growing, and therefore also complexity. Automating a yet to be determined part of the planning
process can arguably take workload of the planning department, allowing for sustained performance
in case of growth.
12
1.1 Fleet description
IDLV has a fleet of about 70 trucks. Of these 70 trucks, an average of 40 operate the Benelux zones
daily. These trucks are either driven by IDLV’s own fleet or drivers that are contracted out. For the
Benelux department, IDLV operates with trailers that may or may not have:
DIFFERENCES IN TRAILER FEATURES OPTIONS
TYPE OF TRAILER BODY Tautliner Boxtrailer
TYPE OF LOCKS SBS Electric
TYPE OF DOORS Docking doors Tailgate Table 1: Different options for IDLV's trailers
This means that there are about eight different types of trailers that can be used. For the owned fleet
that is used in the Benelux, the following brands, type numbers, building years and Euro emission
standards apply:
TYPE OF TRUCK EURO NORM AMOUNT OWNED YEAR OF BUILD
VOLVO FH12 4 5 2003
VOLVO FH12 3 1 2003
VOLVO FH12 4 2 2005
VOLVO FH 440 5 4 2006
DAF XF95 3 2 2005
DAF XF95 5 1 2006
VOLVO FH 440 5 1 2009
VOLVO FH 440 5 1 2009
VOLVO FH 480 5 2 2008
DAF XF 105.480 5 1 2008
DAF XF105.460 5 1 2006
DAF XF105 5 1 2007
VOLVO FH42 5 1 2008
VOLVO FM9 3 1 2005
VOLVO FH 420 6 1 2013 Table 2: IDLV's fleet that operates in the Benelux
1.2 IDLV’s logistic network
As IDLV was growing, a certain distinction between different regions needed to be made. It was
decided to create an underlying network for their TMS, which translates their service area into specific
zones. For example, the United Kingdom has certain zones and certain hubs. When choosing either
one of those, it becomes immediately clear if a collection, distribution or transshipment is to be made.
This has not only made it easier for IDLV to more clearly determine customer prices, but also makes
interdepartmental collaboration easier. When an order originating in Poland and destining in the
Benelux is accepted, the Eastern-European planning department decides on the collection process and
the transshipment options within Poland. Automatically, for the Benelux department, a distribution
order is generated for the expected time when the order has arrived at the Uden hub.
13
Figure 1: The axis in which IDLV operates. Note that Eindhoven and Poznan areas form the main planning hubs
Between these hubs and agents, linehauls are orchestrated. From these hubs, the pickup and deliveries
are made. If a shipment is to be made from the Poznan area to the Eindhoven area, the Poland planning
department enters the order into the system, arranges the pickup in the area and adds the shipment
to a linehaul from Poznan to Eindhoven. Automatically, for the scheduled day of arrival in Eindhoven,
the Benelux department will receive a planning line to distribute this shipment in the Eindhoven area.
1.3 Overview The rest of this thesis is structured as can be seen in figure (2)
1. Introduction 2. Assignment3. Performance
analysis
What is the field?
What needs to be developed?
What is the current state of the company?
4. Mathematical model
5. Developing the model
What is the framework?
What alternatives are
there?
6. Computational
studies
7. Real life case study
How do certain operators and settings act?
How does the tool’s outcome differ from the actual
planning?
8. Conclusions
What have we learned? What
should the company do?
9. Appendix
Figure 2: Schematic overview of how the chapters interrelate
14
Chapter 2: Assignment IDLV is at the moment of writing this thesis, preparing the implementation for a new TMS which allows
for more ways to support planners with their tasks. One option would be to purchase a routing
software package from one of the biggest developers of these kinds of software. The combination of
the multiple of constraints that exist in their practical Vehicle Routing Problem that is to be solved daily
has yet to be researched on academic level to the best of my knowledge. It is unknown to IDLV the
amount and type of savings that can be made with implementing a tailor made vehicle routing tool.
Therefore it is a very difficult decision to make whether or not to implement such a software package.
This means IDLV wants to know their exact planning process, what factors need to be taken into
account when designing a tool for such a process, what limitations it has and what kind of savings can
be obtained.
This assignment therefore focuses on designing such a tool to see exactly how similar tools work and
why it could be beneficial to use such a tool. Research questions to support the focus of this thesis are
set up in chapter 2.2, partly based on the constraints selected by IDLV. The literature study in chapter
2.1 aims to get more insight in relevant literature and supports chapter 2.2. In chapter 2.3 a more
detailed scope for the assignment is given and chapter 2.4 provides the reader with the research
method used to answer the research questions.
2.1 Literature review To get more insights into practices in transport, what types of vehicle routing problems exist and how
route design interacts with trailer loading, a literature review is conducted. It is tried to find cases in
literature that overlap with the practical case at hand and to see how practical problems are solved.
2.1.1 Research area
The field in which this review is executed is that of freight transport. In Europe a common transport
policy between borders is relatively young. 1986’s Single European Act relieved restrictions on air and
sea transportation, where only in 1992 the Maastricht Treaty (European Union, 2014) ruled for the
existence of Trans-European Networks (TENs) in order for trucks to return to their country of origin
without empty trailers. It can thus be said that the inter-European transportation sector has only been
given the chance to grow for a relatively short time. Within freight transport, the classic operations
research fields of container loading and vehicle routing and their overlap are reviewed from their
origins to the richest cases to see what has been researched and where literature gaps exist.
2.1.2 Container loading
Container loading, or often also called containerization, is the problem of packing multiple, three-
dimensional small items (freight) in three-dimensional cubic larger objects (container). Container
loading problems can therefore be interpreted as geometric assignment problems. In essence,
container loading can be reduced to a special case of the cutting and packing problem (C&P), which is
NP-hard. All problems can be said to be cutting and packing problems if they have the following
problem structure (Wäscher et al., 2007): there needs to be a set of large objects (input/supply) and a
set of small items (output/demand). Wäscher et al. (2007) and Bortfeldt and Wäscher (2013) make
more statements on certain categorization criteria to define generalized versions of the cutting and
packing problem. The exact five categorization criteria are dimensionality, kind of assignment,
assortment of large objects, assortment of small items and shape of the small items (Wäscher et al,
2007).
15
The paper of Bortfeldt and Wäscher (2012) aims to review all constraints found in container loading
literature. The constraints have been categorized in figure (3) below.
Figure 3: Categorization of container loading constraints according to Bortfeldt and Wässcher (2012)
In freight transport, the customer visitation order implies the trailer/container loading pattern. This is
called an allocation constraint.
Rectangular packing problems in general are shown to be NP-hard problems (Fowler et al., 1981).
Irregular packing problems or 3D packing problems can be seen as more complex. Therefore these, as
well as packing problems with added complexity constraints, can also be regarded as NP-hard. This
means that computational resources needed to solve such a problem for the optimal packing are too
costly. One resource used to determine computational needs is solving time, especially measured in
CPU usage. As CPU strength increases, one day these problems might no longer be considered NP-
hard, or NP-hard problems may be solvable in seconds. However, research suggests that in the
medium-long term, CPU strengths will not dissolve NP-hard problems (Drexl, 2011).
2.1.3 Vehicle routing problems
The vehicle routing problem is one of the most well-known success stories of operations research
management. Being first published under the title ‘Truck Dispatching Problem’ (Dantzig and Ramser,
1959) makes this problem over 55 years old. To put it simply, the VRP is defined as the designing of a
number of delivery routes from a depot to a number of geographically dispersed customers, while
minimizing delivery costs (Laporte, 2009). When solving the VRP, a different set of side constraints may
apply.
For so-called pickup and delivery problems, there are two types of customer: the transportation of
goods from the depot is done to line-haul customers and then from backhaul customers back to the
depot. These pickup and delivery problem classes are handled as VRPBs, Vehicle Routing Problems
with Backhauls. Within these vehicle routing problems, several more classifications are possible,
depending on the order in which line-hauls and backhauls are done and the consideration of customers
as either line- or backhaul customer or as both. These classifications can be seen below in table (1).
Container-related constraints
Weight limits
Weight distribution constraints
Item-related constraints
Loading priorities
Orientation constraints
• vertical orientation
• horizontal orientation
Stacking constraints
Cargo-related constraints
Complete-shipment
constraints
Allocation constraints
Positioning constraints
absolute positioning constraints
relative positioning constraints
Load related constraints
Stability constraints
Complexity constraints
16
SUBCLASS TYPE DEFINITION ABBREVIATION
CLUSTERED
BACKHAULS
The version of the problem where all line-hauls have
to be done before the backhauls can be collected
VRPCB
MIXED BACKHAULS Problem without clustering restriction: mixed visiting
sequences are explicitly allowed
VRPMB
DEVISIBLE DELIVERY
AND PICKUP
Customers are associated with
both a linehaul and a backhaul quantity. Two visits,
one for delivery and one for pickup are possible
VRPDDP
SIMULTANEOUS
DELIVERY AND PICKUP
Every customer is associated with a linehaul as well as
a backhaul quantity. It is imposed that every
customer can only be visited exactly once
VRPDSP
Table 3: Various subclasses of the VRPMB
Apart from the Pickup and Delivery problem, which is practically a generalized version of the Vehicle
Routing Problem, the other most important fundamental variants of the classical VRP are, according
to Drexl (2011):
VRPs with time windows (VRPTW) imply that the service the carrier gives to the customer
(either a pickup or a delivery) will have to start within a given time window. An order may have
to be picked up after a certain time, delivered in a specific period or after a certain period.
Capacitated arc routing problems (CARP) do not plan around visiting customers to perform a
service (again either a pickup or delivery), but rather the service is performed while traveling
along the links of a transportation network
VRPs under uncertainty:
o Stochastic VRPs assume that information on both occurrence (order intervals) and the
volume of customer demand, or even travel times between customers, is given by
probability distributions.
o Dynamic VRPs take into account the fact that planners need to make decisions (e.g. on
a preliminary planning) before all orders are known. These preliminary plans need to
be adjusted multiple times in such situations, changing the way such a problem needs
to be addressed.
Inventory routing problems (IRP) do not use customer demands in their formulation. Instead
customers have certain consumption rates. Apart from that, customers have given initial
amounts of goods and storage capacity. In a multi-period planning horizon, the challenge then
becomes for the depot to make sure customers never run out of goods, while planning routes
of minimal costs.
2.1.4 Green logistics
Another version of the VRP which is rapidly gaining popularity is the concept of green logistics. Green
logistics has emerged as a new point of focus in supply chain management. Traditional objectives in
distribution management and other operations management practices have been to minimize cost.
Now these objectives are slowly upgraded to ‘system-wide’ costs, where economic as well as
environmental issues are addressed (Canhong Lin et al., 2014). For an overview of which types of
negative externalities are associated with logistics, such as air pollution, noise pollution and
congestion, and how these can be modeled, the reader is referred to the work of Demir et al. (2015).
17
The research on Green-VRP (G-VRP) primarily focuses on the energy consumption in route planning.
Transportation, being one of the primal building blocks of economic growth, is also one of the biggest
user of fossil fuels (Salimifard et al., 2012). This means that G-VRP has to incorporate multiple aspects
that contribute to fuel consumption: travel speed, load weight and transportation distance (report by
the US department of Energy, 2008). The aspects that typically contribute to the fuel consumption can
be categorized in the following factors: vehicle related, environment related, traffic related, driver
related and operations related (Demir et al., 2014b). In their work, Demir et al. also show how to
calculate each factor. Other efforts to reduce pollution associated with vehicle routing can be found in
the work of Demir et al. (2013), where the road gradient and its effects to pollution is taken into
account with designing routes.
2.1.5 Vehicle routing algorithms, heuristics and metaheuristics
Vehicle routing, which generalizes the traveling salesman problem, is fairly difficult to solve. Exact
algorithms have been developed, but they cannot solve large instances. Heuristics are not simply
optimization algorithms, but by selecting an initial solution and looking by local search for
improvement, these methods use less computational power to come up with near-optimal solutions.
Metaheuristics, in their original definition, are ‘’solution methods that orchestrate an interaction
between local improvement procedures and higher level strategies to create a process capable of
escaping from local optima and performing a robust search of a solution space’’ (Gendreau and Potvin,
2013). Since heuristics tend to get stuck in local optima (in the more complex solution spaces), and
therefore do not work as intended, one can use another heuristic (hence the term meta) to help
prevent the original heuristic get stuck in local optima.
A lot of heuristics for the VRP have been proposed over the years (Laporte, 2009). Most of the earlier
produced heuristics are purely constructive. Later, these heuristics started to include an improvement
phase.
When one wants to postoptimize a vehicle routing solution, the option exists for either intraroute
postoptimization or interroute postoptimization (Laporte, 2009). Intraroute moves contain the
improvement of each specific route internally as a traveling salesman problem (as seen in 6.4.2.3).
Interroute postoptimization can act over several routes simultaneously. The latter is somewhat more
challenging, and a lot of algorithms have been proposed for this type of postoptimization, such as
Thompson and Prasaftis (1993).
Local search methods, which are a kind of metaheuristic, typically explore the possible solution space,
starting at an initial solution. With each iteration the current solution is swapped for one in the
neighborhood of that solution (hence the name local search). Typically, local search methods use
interroute moves (Laporte, 2009). The specific importance in local search methods are the mechanisms
that define the neighborhood and explore it.
2.1.6 Combinatorial problems in freight transport
In the two-dimensional loading capacitated vehicle routing problem (2L-CVRP), the loading of freight
into vehicles and the routing afterwards is combined, with the aim of responding to all customer
demand. This specific version this combinatorial problem is relevant in the case where three-
dimensional items need to be transported, but these items cannot be stacked on top of each other
(See also constraints in container loading, 2.1.2). This can be for example be an issue in case of fragility,
large dimensions or planning with unknown heights (Fuellerer et al., 2009). Such is the case with large
18
mechanical components for example. In the work of Fuellerer et al., an ant colonization algorithm is
used to solve the problem. Duhamel et al., (2010) propose a multi-start evolutionary local search
method.
2.1.7 Literature gaps
Vehicle heterogeneity is mostly addressed in literature as defining vehicles with specific speeds, costs
and capacities. However not often the fact is addressed that some types of goods can only be
transported on specific vehicles, or the fact that some customers can only be visited with specific
vehicles. The combination of these kinds of ‘true’ vehicle heterogeneity are to my knowledge not yet
researched. Furthermore the VRPMB is only rarely researched. Besides this, the overall knowledge that
is freely available in creating support tools is very limited. Researchers limit their papers to pseudo
code and mathematical modeling, probably due to privacy considerations. This results in a limited open
source availability for companies to test the profitability of such a tool.
2.2 Research questions The research questions are split up into five questions. In the first three questions a thorough
understanding of the way IDLV works is achieved. Constraints are indexed, practicalities are accounted
for and together with the company a feasible plan is made with regards to what should be developed.
In the second part which covers the final two questions, historical data is analyzed and we get a good
idea of what input is available for a vehicle routing tool. With the input and the scope in mind a tool
that covers all of the indexed constraints can be designed to help IDLV in their decision on
implementing such a tool.
1. How does the planning department currently make a routing plan?
a. How do the high value classifications affect constraints?
b. What different types of time-windows exist?
c. How are decisions between own drivers and charter services made?
d. Are there other kinds of order-related constraints?
2. What are the characteristics of the fleet (trucks and trailers) and the drivers, and how can
these be coupled with constraints?
a. How fixed is the fleet used by the Benelux planning department?
b. How many of each type of trailers is there?
c. Can trailer and truck characteristics be translated into vehicle-related constraints?
3. Can order patterns be defined for (returning) customers?
a. Can a regression model proactively estimate the final number of trucks needed, based
on a given amount of orders at a certain moment?
4. To which degree can this process be automated?
a. Can a heuristic also propose the best use for a charter service?
b. Can a heuristic outperform the planners’ routing decisions?
2.3 Scope In reality, IDLV Benelux plans almost all of their orders as problems of the vehicle routing problem with
mixed backhauls, time windows and order related vehicle constraints and customer related vehicle
constraints which result in true vehicle heterogeneity. A very small part (estimated to be smaller than
one per cent) of the orders is transported directly between two customers. In literature, the problem
now becomes a pickup and delivery problem. To the best of my knowledge, a model that combines
19
the VRPMB with possibilities to skip the depot and extend into a PDP is not yet researched. Because
only such a small number of orders is handled this way, this is excluded from the scope of this research.
The planning department uses the amount of loading meters as a unit to check for vehicle capacity
feasibility. Often also the type of pallet (euro pallets, block pallets and colli’s are very common) are
used. Because dimensions might translate into few loading meters, but in practice require more space
due to irregular shape, sometimes issues occur. This is exactly the overlap between container loading
and vehicle routing as described in the literature research. However due to the limited amount of
available data as input for a routing tool and the implied added complexity, only the amount of loading
meters is can be used. However to assure feasibility, a predetermined percentage of the trailer capacity
is used. Another part of the tasks done by the planning department is the coupling of trailer to truck,
and truck to driver. Truck-driver combinations can be under contract by IDLV or contracted out. For
example, certain drivers are more accustomed to driving in specific parts of the country. This research
will limit its scope to suggesting which amount of specific types of trailers is needed for all the orders,
thus excluding the coupling of drivers and trucks.
20
Chapter 3: Performance analysis For an official description of the planning process, an excerpt from the company’s quality manual can
be found in Appendix 9.1.1. The remainder of this section details personal findings and conclusions.
3.1 Order arrival process
At IDLV, orders typically arrive in two ways. Classically, orders arrive per email or phone at the order
entry department. Also, from the logistic network described in section 1.3, orders can be created as a
result of an international order. In a more recent effort created by IDLV to be more proactive in sales
and create a customer care system, a new department has been created: Sales. In the previous
situation, there was just an order acceptance function within IDLV. Decisions to engage customers in
a fixed contract or to identify more needs were not made by the order acceptance function, leaving a
gap. The sales department focuses on customer care and actively looks for orders by addressing
customers online and visiting them to identify their needs. For example, in freight transport it is
common for some shippers to post their orders at an online platform, where carriers may respond and
offer them a time interval and rates. The sales department actively participates in this. Other activities
include guiding and helping new customers and outsourcing shipments.
3.1.1 Order entry department
The order entry department receives emails detailing new orders. The customer orders that arrive at
the order entry department are originated from customers that already have a contract with IDLV. This
means that they have an agreed pricelist between IDLV and the customer. The prices corresponding
to each unit, for certain kilometers, per customer are fixed in the transport management system used
by IDLV. Most of the customers use their own ordering form, meaning that the order entry department
needs to read the document and extract the information needed from the customer. For the case of
the order entry department for the Benelux, a big part of incoming customer orders already specify
the dates and sometimes even times of order pickup and delivery. These are then entered in TMS,
where the wanted pickup and delivery times are added externally as comments. These orders are,
depending on the desired service level, generated into one or more planning lines as two separate
orders: one for the day of picking them up, one for the day at which they need to be delivered. They
therefore also appear in the order planning collection, used by planners, separately. Orders arrive
usually with little slack. The common way of order arrival (and communication with planners) is the
following. On day t=0 an order arrives. Customers state that the order ‘should’ be picked up at day t=1
if this is possible. Sometimes a comment is added if the order is already ready to be picked up at day
t=0. Depending on the time of order arrival at day t=0, it is scheduled to be picked up the next day:
after 15:00 PM, order entry checks with the planning department if said pickup would be possible. If
they think it is, the order is accepted. This order is then picked up on day t=1 and delivered on day t=2
(or sometimes picked up even at day t=0 if this is possible).
Note: Momentarily, there is an option for the order entry employee to enter orders as direct or
backhaul. The decision is made for an order to be direct if the locations are close to each other. There
is a list with recurring orders (origin-destination pairs) in which these direct shipments are pre-
specified. Order entry checks this list before deciding on a direct shipment.
3.1.2 Sales department
Customers that are not yet under contract with IDLV, or customers that already are but are
transporting irregularly shaped items (not indexed in their pricing contract) contact the Sales
21
department. The sales department actively uses spot pricing to make competitive offers for these
customers and also enters orders into the transport management system. In some cases, when
containers are known to do line-hauls which will result in empty returns, the sales department will try
to find patterns of discrepancies and try to even them out in the long run (this does not apply to day-
to-day activities) This does not directly apply to the practice of the Benelux department. With regard
to specific dates and times set by customers there is a notable difference between orders arriving after
a phone call with sales and over email at the order entry department of customers that are already
under contract. About 60% of orders accepted in the sales department have a rather soft constraint
with regards of the order pickup. These orders just simply need to be picked up before they are
delivered for logical reasons. The delivery dates vary from a before date, a fixed day or a fixed time
window. However, the transport management system requires for a pickup day to be set when
entering the order. The sales department usually schedules the pickup to be scheduled the next
planning day in such cases, as advised by the logistic network within the TMS
3.1.3 Logistic network and automated orders
As explained before, some orders are a result of long-haul orders accepted by other departments.
These orders have their ending destination or origin in the Benelux area. Some of the bigger,
contracted customers, can also directly feed orders into the system.
3.2 Ride planning
The ride planning team for Belgium, the Netherlands and Luxemburg (Benelux) operates in two teams.
They work in two shifts, which overlap. For the sake of clarity, one team which starts at 7 am will be
called the morning team, the team which starts at 13 pm will be called the evening team.
24-6-2015 25-6-2015
24-6-2015
Morning team begins (7:00)
24-6-2015
Evening team finalizes planning (23:00)
24-6-2015
Evening team starts (13:00)
24-6-2015 - 24-6-2015
Orders x for shipments arrive
25-6-2015
Morning team begins (7:00)
25-6-2015
Evening team begins (13:00)
24-6-2015
Morning team finishes (18:00)
25-6-2015
Morning team finishes (18:00)
25-6-2015
Evening team finalized planning (23:00)
25-6-2015 - 25-6-2015
Orders x are delivered/picked up
25-6-2015 - 25-6-2015
Orders x+1 for shipments arrive
Figure 4: schematic overview that shows how both the morning and evening team work on the execution of the same planning
3.2.1 Morning team
The morning team starts the workday t=0 more or less with trucks that have been dispatched that
same day. These trucks have their rides already planned, by the evening team (t= -1). Most of the
addresses visited for a truck driver during the day consist of deliveries. Their trailers are packed by the
transshipment department the day before in the evening (t= -1). Some pickup addresses are also
considered and planned. These pickups (backhauls in a vehicle routing problem) can be done in
between deliveries (in vehicle routing this principle is called mixed backhauls). The morning team
troubleshoots problems as drivers are on the way, and are in close contact with drivers that are on the
road. When drivers are done or still busy with their rides for day t=0, planners check the orders that
are ready for pickup at day t=0 as most drivers need to return to the depot anyway. These pickup
22
orders are arriving as the drivers are on the road. When assigning new orders to rides that are already
on the road, these orders are technically termed on-line orders. Concluding, the morning team
troubleshoots, accepts new orders and handles on-line orders. Note that not all orders arriving on-line
are added to the on-line rides.
3.2.2 Evening team
The evening team, on day t=0 uses the deliveries that have to be delivered by day t=1 to make their
planning. These have usually been picked up on day t=-1. They use accepted deliveries, which are being
picked up on or before day t=1. After these have been picked up the initial routing for the pickups and
deliveries for day t=1 is made. Because orders to be picked up are arriving during the day, pickup
addresses may be added to the preliminary route plans and routes may be altered. However at 17:00
pm the final amount of addresses is known and the final vehicle routing plan is made. Constraints that
are taken into account:
• HV/HR: high value or high risk products need special trailers to be transported in
• Tailgate / tail lift: some pallets may only be loaded/unloaded using a tailgate, e.g. if a
customer does not own a forklift or a trailer dock. This typically occurs when orders need
to be delivered in an urban area.
• Pickup/delivery: because there are mixed backhauls, loading patterns need to be taken
into account when planning rides
• The measurements of the items: not all accepted orders are euro pallets, making the
loading pattern not simply a sequence, but a two-dimensional loading problem*
*even though the two-dimensional loading problem is intuitively taken into account while planning
rides, a loading plan is not yet decided on when making a routing plan. These two problems are not
yet combined, but rather planners grossly estimate if a feasible loading pattern should be possible to
define, and use some slack in container space.
For a systematical overview of the Benelux planning process, please see Appendix 8.1.2.
3.2.3 Loading constraint implications
A decent subset of the distribution trailers used by IDLV are the so-called curtainsiders, having a width
and length, 248 cm x 1,360 cm. The safer, box-trailers have the same dimensions but can only be
opened from the back. The below image illustrates how exactly 33 euro pallets can fit into a
curtainsider.
Figure 5: A 248 cm x 1,360 cm curtainsider fits 33 euro pallets
Typically, incoming orders can have the following format, with regards to dimensions:
1. Orders are passed on in numbers of euro pallets, these have the following dimensions: 80 cm
x 120 cm. They can be lifted by a forklift from each side
2. Orders are passed on in numbers of block pallets, these have the following dimensions: 100
cm x 120 cm. They can be lifted by a forklift from each side
3. Orders are passed on in terms of loading meters, a loading meter serving as one meter taken
up in the length of a trailer, and the full width of the trailer
23
4. Orders are passed on using purely their dimensions (width x length x height)
To calculate a price for their customers, all of the 4 formats are calculated into loading meters. Using
these loading meters, gross estimations on trailer loading utilization can be done.
1. In the case of euro pallets, when putting three next to each other, and having their shortest
side be orthogonal to the curtain side of the trailer, these take up the full width of the trailer,
and 1.2 meters in length. Therefore three euro pallets take up 1.2 loading meters. When
putting two next to each other after rotating them both 90 degrees, they still take up the width
of a trailer, but only 0.8 meters of the length, resulting in 0.8 loading meters. Following this
logic, a euro pallet is always 0.4 loading meters.
2. Following the same logic, when placing two block pallets together so that they span the entire
width of a trailer, they take up one loading meter. Correspondingly, one block pallet takes up
0.5 loading meters.
3. When using more specific dimensions (in width and length) one can multiply width and length
and divide by 240 cm. For the case of a euro pallet: (120 x 80)/240 corresponds with 40 cm,
so 0.4 loading meters.
Using these loading meters as a means of determining utilization is supported by the system IDLV uses,
and it therefore provides an easy performance indicator. However sometimes, especially when load is
not purely consisting of pallets and when unloading constraints have to be taken into account, it is
impossible to achieve full loading meters.
Not all trailers used are curtainsiders. Some are fortified box-trailers, compliant to the TAPA norms and
requirements. This implies loading and unloading only from the tailgate. The packing now resembles a
two dimensional strip packing problem. However, some customers do not have forklifts at their origin
or destination. In such a case, a customer might ask that the truck is equipped with a tailgate to unload
the shipment. Implicitly, if a customer requires a tailgate, this makes the loading or unloading
operation for that specific address also a two dimensional strip packing problem. In this special case,
for other addresses to be done on a route for a specific trailer, the packing problem might differ again.
3.3 Transshipment
The ride planning and its sequential address visits per truck, directly translate into a loading plan for
the transshipment packing. The final loading address for a specific ride is placed first, so close to the
truck. Idealogistic Verhoeven strives to load each truck with a pallet truck (pompwagen). The driver is
expected to apply some own insight when loading mixed backhauls during his ride. Using the pallet
truck, a collected backhaul can be placed in such a way that other distributions are still possible.
3.4 Volume analysis For the Benelux department, as said before, orders arrive as planning lines. It is chosen to go back to
the start of 2012. This provides a large sample size, with over 1000 days to analyze. Also the file size
becomes over 100mb, and for MS Excel stability issues it is chosen not to get a bigger file. We gather
all planning lines from 2012 until the end of May 2015. Each day has about 400 planning lines daily.
Per planning line, data is available to which trailer the order has been assigned, order quantity, weight,
whether it is a pickup or delivery, at what time the order has been entered into the system.
24
3.4.1 Volumes and factors By writing some simple macros, we can move from planning lines to average numbers per day, per
ride, and get order inter arrival times. Now we get an idea of the volumes moved on average in the
Benelux area by IDLV. Screenshots from the original overview and the overview obtained from the
macro are given in appendices (9.1.3) and (9.1.4). Overall, from January 2012 to May 2015, an average
of 56 tours have been operated per day. On average, each day about 724782 kg is collected. Also, an
average volume of about 594221 kg is distributed daily. This means that each day, IDLV is responsible
of moving around 1.2 million kilograms of shipments throughout the Benelux area.
Of the average of 56 tours, about 10 are carrying HV/HR goods and can thus be classified as being done
with specialized trailers.
Over the past three and a half years, we can see some seasonality trends, but an overall steady growth
in order volumes. In the figures (6) and (7) below this is visualized. With these increasing order
volumes, complexity increases.
Figure 6: Average daily collection volume in kgs per month
0
100000
200000
300000
400000
500000
600000
700000
800000
900000
1000000
Jan
-12
Feb
-12
Mar
-12
Ap
r-1
2M
ay-1
2Ju
n-1
2Ju
l-1
2A
ug-
12
Sep
-12
Oct
-12
No
v-1
2D
ec-1
2Ja
n-1
3Fe
b-1
3M
ar-1
3A
pr-
13
May
-13
Jun
-13
Jul-
13
Au
g-1
3Se
p-1
3O
ct-1
3N
ov-
13
Dec
-13
Jan
-14
Feb
-14
Mar
-14
Ap
r-1
4M
ay-1
4Ju
n-1
4Ju
l-1
4A
ug-
14
Sep
-14
Oct
-14
No
v-1
4D
ec-1
4Ja
n-1
5Fe
b-1
5M
ar-1
5A
pr-
15
May
-15
25
Figure 7: Average daily distribution volume in kgs per month
Now we have a general idea about how many rides and orders are handled by IDLV. We can also check
the average load factors and distances drives for some days. The load factors and distances are not
typically logged by IDLV and are therefore manually calculated using a complex macro. This will be
explained later on in the report.
We analyze some days to give an image of more KPIs:
Date Amount of
rides
Amount of rides
departing at 7:00
Average load
factor
Total kms
driven
Stops
1-7-2015
56 43 0,52 11185,03 396
2-7-2015
66 45 0,44 10906,36 383
3-7-2015
67 49 0,45 11826,93 366
Table 4: KPIs for the first three days of July 2015
3.4.2 Pattern identification More than just knowing the daily overall data, it is interesting to see if there are overall patterns. These
patterns can be between days and within days.
First we see for each number of days, how many occurrences (days) exist with that number of days.
This way we can see how the average numbers of rides are distributed. The bins that are now plotted
seem to somewhat follow a normal distribution, this can be seen by the bell shape of the graph. It is
good to see that the average number of rides is not just a random number but that there is some
consistency.
0
100000
200000
300000
400000
500000
600000
700000
800000
jan
-12
mrt
-12
mei
-12
jul-
12
sep
-12
no
v-1
2
jan
-13
mrt
-13
mei
-13
jul-
13
sep
-13
no
v-1
3
jan
-14
mrt
-14
mei
-14
jul-
14
sep
-14
no
v-1
4
jan
-15
mrt
-15
mei
-15
26
Figure 8: Amount of rides per day and their relative occurence
We see that the most common number of rides is 61 and that this also finds itself somewhat in the
middle of the bell shaped graph. We would like to find the relation between rides and the amount of
orders. Intuitively, one would say that a higher amount of orders leads to more rides, but we have no
idea how this relationship should exactly behave. So for each bin where a number of rides exists, we
can now calculate the average total order volume. When we have these numbers and plot them we
can see a relationship that appears to be linear. This is typically a good indicator that the amount of
rides can be predicted by the amount of orders. This would mean that for IDLV, there may be options
to predict the amount of rides. As of now, there are no such tools available and planners have to
reserve resources based on gut feeling. As stated before, this often results in surplus reservations
which can be costly. However for a prediction this data is not yet suitable, as in this case the order
numbers are measured when the day has already ended, so the total order volume is known. What is
needed for a relevant tool is that the rides can be predicted early in the day.
0
0,01
0,02
0,03
0,04
0,05
0,06
0,07
0,08
0,09
2 5 15 24 26 29 33 36 38 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72
27
Figure 9: Average order volume on a day per number of rides per day
Therefore, for such a linear relation between orders and rides to be of practical use, the order arrival
process during the day itself also needs to behave in a somewhat stable way. For a practical tool,
planners might want to know early on in the day what the total amount of orders will be at the end of
the day, as well as the total amount of rides that they will need to plan for the next day. If this is known,
better resource scheduling can be done which should save some money.
So logically the next step is to look at the order arrival process. For each day, the orders that have to
be orchestrated that day are analyzed and sorted into bins, based on when they were entered in the
system. The data is collected starting from one day before the actual day, at 9:00 am. Up until this
point all orders are already accumulated. So for day t=1, we act as if the order arrival process starts at
t-1 at 9:00 am, with already a collection of orders at this point. As stated before the number of rides
with the most observations is 61. In fact there are 73 days where 61 rides are orchestrated. We plot
the average number of orders per timeslot, together with the highest and lowest order numbers. It
shows that the arrival process seems to follow a certain pattern for both collection and distribution
orders. It makes sense that for collection orders, orders arrive even the trucks are already on the road
(on-line). Planners can add collection orders to trucks that are on-line to ensure high load factors and
resource utilization. For distribution this of course is impossible, since distribution orders have to
originate from the depot and can therefore not easily be added on-line.
0
200000
400000
600000
800000
1000000
1200000
1400000
1600000
1 3 7 20 25 27 31 34 37 40 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71
28
Figure 10: Collection order volumes order arrival patterns
Figure 11: Distribution order volumes order arrival patterns
3.4.3 Regression analysis From these somewhat stable order arrival processes, we assume that there might be an option to
predict the number of rides directly from the order arrival process. Of course, the model needs to run
early in the day, so we run a regression with all timeslots for the day before the ride, from 9:00 am
until 15:00 pm. Also dummy variables for the day of the week and the month are included.
All data is prepared for SPSS and a backwards enter method for a linear regression is done. With the
month numbers as dummy variables a less high adjusted r-squared is achieved, so it is chosen to only
use dummy variables for the day of the week.
The adjusted r-squared of the final model comes at 0,712 which is very high. For the days, it seems
that only if the day is Monday, Wednesday or Friday this makes a significant change to the amount of
0
200000
400000
600000
800000
1000000
1200000
Lowest order volume Average order volume Highest order volume
0
100000
200000
300000
400000
500000
600000
700000
800000
900000
Lowest order volume Average order volume Highest order volume
29
rides needed. As one would expect, the model uses for both distribution and collection orders the
cumulative amount from the start of the day and from the end (15:00 pm). This should mean that
between these numbers a sort of extrapolation is possible. Below the model summary as well as its
components can be seen.
Model Summary
Model R R Square Adjusted R Square
Std. Error of the
Estimate
1 ,848a ,719 ,712 3,447
a. Predictors: (Constant), D_Tminus1_14_15, Monday, C_Tminus1_10_11, Wednesday,
Friday, C_Tminus1_14_15, D_Tminus1_9_10
Table 5: Overall model summary for the regression model, indicating a strong model
Coefficientsa
Model
Unstandardized Coefficients
Standardized
Coefficients
t Sig. B Std. Error Beta
1 (Constant) 26,204 1,329 19,717 ,000
Monday -2,759 ,610 -,170 -4,525 ,000
Wednesday -1,556 ,569 -,098 -2,736 ,007
Friday -3,612 ,590 -,225 -6,121 ,000
C_Tminus1_10_11 -8,822E-6 ,000 -,107 -2,299 ,012
C_Tminus1_14_15 3,013E-5 ,000 ,407 8,662 ,000
D_Tminus1_9_10 -1,302E-5 ,000 -,196 -2,447 ,015
D_Tminus1_14_15 4,999E-5 ,000 ,841 10,609 ,000
a. Dependent Variable: Amount_of_Rides
Table 6: Table showing the coefficients of the regression model and their power
For this to be implemented by IDLV should be fairly simple. The result of this regression is a formula
that asks the type of day, the cumulated order volumes for collections up until 11 am and 15 pm and
the cumulated order volumes for distributions up until 10 am and 15 pm.
M: Binary variable, 1 if today is Monday, 0 otherwise
W: Binary variable, 1 if today is Wednesday, 0 otherwise
F: Binary variable, 1 if today is Friday, 0 otherwise
𝐶11: cumulative amount of collection orders at 11:00 am
𝐶15: cumulative amount of collection orders at 15:00 am
𝐷10: cumulative amount of distribution orders at 10:00 am
𝐷15: cumulative amount of distribution orders at 15:00 am
𝐴𝑚𝑜𝑢𝑛𝑡 𝑜𝑓 𝑟𝑖𝑑𝑒𝑠 𝑛𝑒𝑒𝑑𝑒𝑑
= 26,204 − 2,759𝑀 − 1,556𝑊 − 3,612𝐹 − 8,822 ∗ 10−6𝐶11 + 3,013 ∗ 10−5𝐶15
− 1,302 ∗ 10−5𝐷10 + 4,999 ∗ 10−5𝐷15
30
However, what is more welcome for planners is a certain subset of rides per day. This subset, should
be the subset of rides that leave first the next morning. This is the case because trucks get reused
during the day for new rides. For planners, the amount of resources they need to reserve is equal to
the amount of rides leaving at the start of the next workday. Unfortunately for this, some data on
when the ride leaves is needed. This data has only been collected since July 2015. This means that only
about one month of data is available, strongly reducing the sample size used by SPSS if a new
regression were to be done. This would undermine the strong model which has been obtained above.
However for practical purposes, for the available data we can calculate the fraction of rides that leave
in the day with respect to the total amount of rides. This fraction can then be used to correct for the
predicted amount of rides by the regression model. It would also be possible to test the power of this
correction, but once again the sample for the calculation of the fraction is low.
Correlations
VAR00001 VAR00002
VAR00001 Pearson Correlation 1 ,530**
Sig. (2-tailed) ,009
N 23 23
VAR00002 Pearson Correlation ,530** 1
Sig. (2-tailed) ,009
N 23 23
**. Correlation is significant at the 0.01 level (2-tailed).
Table 7: Correlation table showing a strong positive relation between amount of rides and amount of trailers
If we calculate for each day in July the total amount of rides and the amount of rides that departed at
the start of the day (i.e. the amount of trucks needed) and use a Pearson’s R correlation test, it is found
to have a significant correlation. The power of the relationship is 0,53, which indicates a strong positive
relationship. This is a good indicator that if more data about departure times would have been
available, the regression model would also be able to predict the resources needed instead of the rides.
It is therefore recommended to IDLV to keep collecting this data and when the sample size is large
enough, create a new regression model in the same fashion as done here. For now, even though it is
statistically incorrect, practical use of the regression model might be done by correcting with the
average fraction of resources over rides. For each day we can device the resources used by the total
amount of rides and take the average over the month of July. This number comes to 0,744. The
temporary practical model would now look like this:
𝐴𝑚𝑜𝑢𝑛𝑡 𝑜𝑓 𝑟𝑖𝑑𝑒𝑠 𝑛𝑒𝑒𝑑𝑒𝑑
= (26,204 − 2,759𝑀 − 1,556𝑊 − 3,612𝐹 − 8,822 ∗ 10−6𝐶11 + 3,013 ∗ 10−5𝐶15
− 1,302 ∗ 10−5𝐷10 + 4,999 ∗ 10−5𝐷15) ∗ 𝟎, 𝟕𝟒𝟒
3.4.4 Analysis of green indicators As has already been discussed, the road logistics industry is one of the biggest contributors to the
emissions of greenhouse gases. Efforts to reduce these contributions are made by governments
(Maastricht treaty, 1992) and companies themselves (lean and green, 2014). In the remainder of this
section, an overview of the efforts currently made by IDLV to reduce their carbon footprint is given.
31
3.4.4.1 Kilometer per stop
With the use of board computers, IDLV can monitor fuel consumption per driven km of their own fleet.
Only a fraction of the rides that are orchestrated daily is done with owned trucks. IDLV has some trucks
and drivers on a flexible contract, to which board computers they not have access. Currently, these
numbers are weighed against the amount of addresses the truck has visited per km. The logic behind
this is that if a ride has had less distance in between stops, so relatively more stops, the ride has burned
more fuel per km. If this relation is found to be true, it can be used as a predictor for fuel consumption
when designing rides. Furthermore the company also actively monitors the fuel consumption rates and
reminds their drivers to keep it below certain benchmarks. So when the kilometers per stop are
calculated on average per month, these are used to interpret the average usage numbers per month
for certain drivers. The Pearson’s R test shows a correlation coefficient of 0,290, indicating a weak
positive relation between the usage and the distance between stops. This relationship follows intuition
as relatively more stops would mean less constant speeds, and higher fuel usage
DRIVER USAGE (LITER/KILOMETER) KM PER STOP
1 3,41 37,85
2 3,09 52,91
3 3,19 29,04
4 3,17 31,81
5 3,25 34,44
6 3,52 53,81
7 3,11 54,21
8 3,39 50,78
9 3,46 53,54
10 3,25 42,86
11 3,54 41,11
12 3,51 35,17
13 3,55 32,46
14 3,56 42,02
15 3,39 50,42
16 3,74 44,83
17 3,20 49,90
18 3,14 51,89
19 3,21 32,81
20 3,43 39,43
21 3,92 38,69
22 3,70 73,26 Table 8: Relationship shown between fuel consumption and kms per stop per driver, for the month of January 2015
3.4.4.2 CO2 emissions per truck
For the Benelux area, the owned fleet is categorized with year of build, the make name, type and
engine size in ccs. Each truck as a Euro norm classification which indicates the fuel consumption and
CO2 emission. Apart from this rather static data, each month the total CO2 emissions per vehicle are
calculated by multiplying fuel consumption with a factor 2,65. This is the factor commonly used to
measure CO2 emissions in kilograms, per liter diesel burnt. However when one wants to also include
other equally harmful gases, one can use the CO2e factor of 3,15. (Demir et al., 2013) For this factor,
the other gases have been scaled as their relative harmfulness with respect to CO2 and added to the
2,65 factor. Also the average emission per km, per vehicle, per month is then calculated. In section
32
(9.1.6), an example is given on how these emission numbers are kept. For January 2015, the overall
average emission for the Benelux department was 0,77 kilograms per kilometer driven.
33
Chapter 4: Mathematical modeling This chapter will answer the final sub-questions of the first two research questions, namely how
material restrictions and order details result in types of constraints and variables. The chapter explains
which variables and constraints are important for the tool that will be created. To make the model
applicable to other companies, some variables will be made generic. Following the logistic network
described in section 3.1.4, orders are translated into planning lines. A planning line contains a lot of
data, such as both pickup and delivery address, order quantity and weight, and vehicle requirements.
Other things such as time windows are momentarily not yet available in a unified format, but in string
form manually entered by employees. First of all, some general information about how VRPs are
modeled is given by describing some commonly used terms. Then the generic mathematical model is
given, representing a mixed integer linear programming problem.
4.1 General information on VRP models
Vertices
Vertices represent customer location. IDLV has information on whether a planning line is a pickup or a
delivery. When this is known, also the right address can be looked up, since per shipment more than
one addresses are available. The address is available in form of a combination of zipcode and country
code. A routing tool usually works with coordinates of vertices. To obtain coordinates in the form of
latitude and longitude, a web service needs to be used. The process of feeding an address to a server
and retrieving the coordinates is called geocoding. There are several servers who provide companies
or individuals with such a geocoding server, such as bing maps, google maps and open street maps
(.org). Besides the location of the vertex, other constraints or requirements can be coupled to a vertex
such as a time window in which the vertex must be visited, specific vehicle contraints (some locations
may only be visited with smaller vehicles).
Arcs
Arcs represent the distances between customers. A tour consisting of visiting certain vertices can be
measured in distance by adding up the arc between the customers. For a routing tool, a distance matrix
containing all possible arcs between customers is used as input. In this case, the arc describes either
the distance between the customers or the travel time. Distance can be measured in a straight line,
using the ‘crow flies’ principle, or by using available road data. The same goes for distance. In even
more complex situations, live traffic data can also be used. Apart from the arcs as input for a model,
they can also be used to describe the amount that is transported between customers.
Vehicles
Vehicles are the instances that travel over arcs and visit vertices. The vehicle is used to model
constraints such as capacity. The capacity can be set at a maximum, and then for each moment the
capacity utilization can be calculated to check the capacity restrictions. In more complex models,
capacity can be not just an integer, but consist of a bin packing problem. Also for each vehicle specific
parameters can be set such as speed, maximum working hours and starting time.
34
4.2 Mixed integer linear programming problem
Indices
𝑃: 𝑆𝑒𝑡 𝑜𝑓 𝑝𝑖𝑐𝑘𝑢𝑝 𝑛𝑜𝑑𝑒𝑠, 𝑃 = {1,… , 𝑛}
𝐷: 𝑆𝑒𝑡 𝑜𝑓 𝑑𝑒𝑙𝑖𝑣𝑒𝑟𝑦 𝑛𝑜𝑑𝑒𝑠, 𝐷 = {𝑛 + 1,… ,2𝑛}
𝑁: 𝑆𝑒𝑡 𝑜𝑓 𝑝𝑖𝑐𝑘𝑢𝑝 𝑎𝑛𝑑 𝑑𝑒𝑙𝑜𝑣𝑒𝑟𝑦 𝑛𝑜𝑑𝑒𝑠, 𝑁 = (𝑃 ∪ 𝐷)
𝐾: 𝑆𝑒𝑡 𝑜𝑓 𝑎𝑙𝑙 𝑣𝑒ℎ𝑖𝑐𝑙𝑒𝑠, 𝐾 = {1,… , 𝑘}
𝑀: 𝑆𝑒𝑡 𝑜𝑓 𝑠𝑡𝑎𝑟𝑡 𝑡𝑒𝑟𝑚𝑖𝑛𝑎𝑙𝑠 𝑜𝑓 𝑣𝑒ℎ𝑖𝑐𝑙𝑒𝑠,𝑀 = (𝑚1)
𝑀′: 𝑆𝑒𝑡 𝑜𝑓 𝑒𝑛𝑑 𝑡𝑒𝑟𝑚𝑖𝑛𝑎𝑙𝑠 𝑜𝑓 𝑣𝑒ℎ𝑖𝑐𝑙𝑒𝑠,𝑀′ = (𝑚′1 = 𝑚1)
𝑉: 𝑆𝑒𝑡 𝑜𝑓 𝑎𝑙𝑙 𝑙𝑜𝑐𝑎𝑡𝑖𝑜𝑛𝑠, 𝑉 = (𝑁 ∪𝑀 ∪𝑀′)
𝐴: 𝑆𝑒𝑡 𝑜𝑓 𝑜𝑟𝑑𝑒𝑟𝑒𝑑 𝑝𝑎𝑖𝑟𝑠 𝑜𝑓 𝑛𝑜𝑑𝑒𝑠 (𝑖. 𝑒. , 𝑎𝑟𝑐𝑠), 𝐴 = {(𝑖, 𝑗): 𝑖, 𝑗 ∈ 𝑉, 𝑖 ≠ 𝑗}
𝐺:𝐴 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒 𝑢𝑛𝑑𝑖𝑟𝑒𝑐𝑡𝑒𝑑 𝑔𝑟𝑎𝑝ℎ, 𝐺 = (𝑉, 𝐴)
𝑃𝑘: 𝑆𝑒𝑡 𝑜𝑓 𝑝𝑖𝑐𝑘𝑢𝑝 𝑛𝑜𝑑𝑒𝑠 𝑡ℎ𝑎𝑡 𝑐𝑎𝑛 𝑏𝑒 𝑠𝑒𝑟𝑣𝑖𝑐𝑒𝑑 𝑏𝑦 𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑘, 𝑃𝑘 = {1,… , 𝑛1} 𝑎𝑛𝑑 𝑛1 ≤ 𝑛
𝐷𝑘: 𝑆𝑒𝑡 𝑜𝑓 𝑑𝑒𝑙𝑖𝑣𝑒𝑟𝑦 𝑛𝑜𝑑𝑒𝑠 𝑡ℎ𝑎𝑡 𝑐𝑎𝑛 𝑏𝑒 𝑠𝑒𝑟𝑣𝑖𝑐𝑒𝑑 𝑏𝑦 𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑘, 𝐷𝑘 = {1,… , 𝑛1} 𝑎𝑛𝑑 𝑛1 ≤ 𝑛
𝑁𝑘: 𝑆𝑒𝑡 𝑜𝑓 𝑝𝑖𝑐𝑘𝑢𝑝 𝑎𝑛𝑑 𝑑𝑒𝑙𝑖𝑣𝑒𝑟𝑦 𝑛𝑜𝑑𝑒𝑠, 𝑁𝑘 = (𝑃𝑘 ∪ 𝐷𝑘)
𝐾𝑖: 𝑆𝑒𝑡 𝑜𝑓 𝑣𝑒ℎ𝑖𝑐𝑙𝑒𝑠 𝑡ℎ𝑎𝑡 𝑐𝑎𝑛 𝑠𝑒𝑟𝑣𝑒 𝑟𝑒𝑞𝑢𝑒𝑠𝑡 𝑖, 𝐾𝑖 = {1,… , 𝑘1} 𝑎𝑛𝑑 𝑘1 ≤ 𝑘
𝑉𝑘: 𝑆𝑒𝑡 𝑜𝑓 𝑎𝑙𝑙 𝑛𝑜𝑑𝑒𝑠 𝑡ℎ𝑎𝑡 𝑐𝑎𝑛 𝑏𝑒 𝑣𝑖𝑠𝑖𝑡𝑒𝑑 𝑏𝑦 𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝐾, 𝑉𝑘 = ( 𝑁𝑘 ∪ 𝑀𝑘 ∪ 𝑀′𝑘)
𝐴𝑘: 𝑆𝑒𝑡 𝑜𝑓 𝑜𝑟𝑑𝑒𝑟𝑒𝑑 𝑝𝑎𝑖𝑟𝑠 𝑜𝑓 𝑛𝑜𝑑𝑒𝑠 𝑓𝑜𝑟 𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑘, 𝐴𝑘 = {(𝑖, 𝑗): 𝑖, 𝑗 ∈ 𝑉𝑘 , 𝑖 ≠ 𝑗}
𝐺𝑘: 𝐴 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒 𝑢𝑛𝑑𝑖𝑟𝑒𝑐𝑡𝑒𝑑 𝑠𝑢𝑏𝑔𝑟𝑎𝑝ℎ, 𝐺𝑘 = (𝑉𝑘, 𝐴𝑘)
Parameters
𝑄𝑘: 𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑦 𝑜𝑓 𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑘 (𝑘 ∈ 𝐾)
𝑇1:𝑀𝑎𝑥𝑖𝑚𝑖𝑚 𝑑𝑟𝑖𝑣𝑖𝑛𝑔 𝑡𝑖𝑚𝑒 𝑜𝑛 𝑎𝑛𝑦 𝑎𝑟𝑐 (𝑖, 𝑗) 𝑖𝑛 𝑚𝑖𝑛𝑢𝑡𝑒𝑠
𝑇2:𝑀𝑎𝑥𝑖𝑚𝑖𝑛 𝑟𝑜𝑢𝑡𝑒 𝑡𝑖𝑚𝑒 𝑖𝑛 𝑚𝑖𝑛𝑢𝑡𝑒𝑠
�̅�𝑟: 𝑅 𝑛𝑜𝑛𝑑𝑒𝑐𝑟𝑒𝑎𝑠𝑖𝑛𝑔 𝑠𝑝𝑒𝑒𝑑 𝑙𝑒𝑣𝑒𝑙𝑠 (𝑟 = 1,2,… , 𝑅)
𝑐𝑟: 𝑓𝑢𝑒𝑙 𝑐𝑜𝑠𝑡 𝑎𝑡 𝑎 𝑠𝑝𝑒𝑒𝑑 𝑙𝑒𝑣𝑒𝑙 𝑟 𝑝𝑒𝑟 𝑘𝑖𝑙𝑜𝑚𝑒𝑡𝑒𝑟 (𝑟 ∈ 𝑅)
𝑐𝑖𝑗𝑘 : 𝑜𝑡ℎ𝑒𝑟 𝑡𝑟𝑎𝑣𝑒𝑙 𝑟𝑒𝑙𝑎𝑡𝑒𝑑𝑐𝑜𝑠𝑡𝑠 𝑏𝑒𝑡𝑤𝑒𝑒𝑛 𝑛𝑜𝑑𝑒 𝑖 𝑎𝑛𝑑 𝑗 𝑢𝑠𝑖𝑛𝑔 𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑘 (𝑘 ∈ 𝐾, (𝑖, 𝑗) ∈ 𝐴)
𝑑𝑖𝑗: 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝑏𝑒𝑡𝑤𝑒𝑒𝑛 𝑛𝑜𝑑𝑒𝑠 𝑖 𝑎𝑛𝑑 𝑗 (𝑖, 𝑗 ∈ 𝐴)
𝑙𝑖𝑗:𝑀𝑖𝑛𝑖𝑚𝑢𝑚 𝑠𝑝𝑒𝑒𝑑 𝑙𝑒𝑣𝑒𝑙 𝑏𝑒𝑡𝑤𝑒𝑒𝑛 𝑛𝑜𝑑𝑒𝑠 𝑖 𝑎𝑛𝑑 𝑗𝑑
𝑎𝑖: 𝐴 𝑙𝑜𝑤𝑒𝑟 𝑏𝑜𝑢𝑛𝑑𝑜𝑛 𝑡ℎ𝑒 𝑡𝑖𝑚𝑒 𝑤𝑖𝑛𝑑𝑜𝑤 𝑜𝑓𝑐𝑢𝑠𝑡𝑜𝑚𝑒𝑟 𝑖 (𝑖 ∈ 𝑉)
𝑏𝑖: 𝐴𝑛 𝑢𝑝𝑝𝑒𝑟 𝑏𝑜𝑢𝑛𝑑 𝑜𝑛 𝑡ℎ𝑒 𝑡𝑖𝑚𝑒 𝑤𝑖𝑛𝑑𝑜𝑤 𝑜𝑓 𝑐𝑢𝑠𝑡𝑜𝑚𝑒𝑟 𝑖 (𝑖 ∈ 𝑉)
𝑡𝑖: 𝑆𝑒𝑟𝑣𝑖𝑐𝑒 𝑡𝑖𝑚𝑒 𝑜𝑓 𝑐𝑢𝑠𝑡𝑜𝑚𝑒𝑟 𝑖 (𝑖 ∈ 𝑃 ∪ 𝐷)
𝑞𝑖: 𝐴 𝑛𝑜𝑛𝑛𝑒𝑔𝑎𝑡𝑖𝑒 𝑑𝑒𝑚𝑎𝑛𝑑 𝑓𝑜𝑟 𝑒𝑣𝑒𝑟𝑦 𝑖 (𝑖 ∈ 𝑃)
Variables
𝑥𝑖𝑗𝑘 : 𝐴 𝑏𝑖𝑛𝑎𝑟𝑦 𝑣𝑎𝑟𝑖𝑎𝑏𝑙𝑒 𝑒𝑞𝑢𝑎𝑙 𝑡𝑜 1 𝑖𝑓 𝑎𝑟𝑐 (𝑖, 𝑗) 𝑖𝑠 𝑢𝑠𝑒𝑑 𝑏𝑦 𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑘 𝑎𝑛𝑑 0 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒 (𝑘 ∈ 𝐾, (𝑖, 𝑗)
∈ 𝐴)
𝑆𝑗𝑘: 𝑇ℎ𝑒 𝑡𝑖𝑚𝑒 𝑎𝑡 𝑤ℎ𝑖𝑐ℎ 𝑠𝑒𝑟𝑣𝑖𝑐𝑒 𝑠𝑡𝑎𝑟𝑡𝑠 𝑎𝑡 𝑛𝑜𝑑𝑒 𝑗 𝑤𝑖𝑡ℎ 𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑘 (𝑘 ∈ 𝐾, 𝑗 ∈ 𝑉)
𝑂𝑗𝑘: 𝑇ℎ𝑒 𝑡𝑖𝑚𝑒𝑠𝑝𝑒𝑛𝑡 𝑜𝑛 𝑎𝑟𝑜𝑢𝑡𝑒 𝑡ℎ𝑎𝑡 ℎ𝑎𝑠 𝑎 𝑛𝑜𝑑𝑒 𝑗 𝑎𝑠 𝑙𝑎𝑠𝑡 𝑣𝑖𝑠𝑖𝑡𝑒𝑑 𝑏𝑒𝑓𝑜𝑟𝑒 𝑟𝑒𝑡𝑢𝑟𝑛𝑖𝑛𝑔 𝑡𝑜 𝑡ℎ𝑒 𝑑𝑒𝑝𝑜𝑡 𝑤𝑖𝑡ℎ 𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑘 (𝑘
∈ 𝐾, 𝑗 ∈ 𝑉)
𝐿𝑗𝑘: 𝐴𝑚𝑜𝑢𝑛𝑡 𝑜𝑓 𝑙𝑜𝑎𝑑 𝑎𝑡 𝑛𝑜𝑑𝑒 𝑗 𝑜𝑛 𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑘 (𝑘 ∈ 𝐾, 𝑗 ∈ 𝑉)
𝑤𝑖𝑗𝑟 : 𝐴 𝑏𝑖𝑛𝑎𝑟𝑦 𝑣𝑎𝑟𝑖𝑎𝑏𝑙𝑒 𝑒𝑞𝑢𝑎𝑙 𝑡𝑜 1 𝑖𝑓 𝑎𝑟𝑐 (𝑖, 𝑗)𝑖𝑠 𝑡𝑟𝑎𝑣𝑒𝑟𝑠𝑒𝑑 𝑎𝑡 𝑎 𝑠𝑝𝑒𝑒𝑑 𝑙𝑒𝑣𝑒𝑙 𝑟 𝑎𝑛𝑑 0 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒 ((𝑖, 𝑗)
∈ 𝐴, 𝑟 ∈ 𝑅)
An integer linear programming formulation is shown as follows:
35
𝑀𝑖𝑛𝑖𝑚𝑖𝑧𝑒:
{
∑𝑐𝑟𝑟∈𝑅
∑ 𝑑𝑖𝑗𝑤𝑖𝑗𝑟
𝑖,𝑗∈𝐴𝑘
+
∑ ∑ 𝑐𝑖𝑗𝑘𝑥𝑖𝑗
𝑘
𝑖,𝑗∈𝐴𝑘𝑘∈𝐾 }
(1)(2)
Subject to:
∑ ∑ 𝑥𝑖𝑗𝑘
𝑗∈𝑁𝑘𝑘∈𝐾
= 1, ∀𝑖 ∈ 𝑃 (3)
∑ ∑ 𝑥𝑖𝑗𝑘
𝑗∈𝑁𝑘𝑘∈𝐾
= 1, ∀𝑖 ∈ 𝐷 (4)
∑ 𝑥𝑚𝑘,𝑗𝑘 = 1 ∀𝑘 ∈ 𝐾
𝑗∈𝑁𝑘
(5)
∑ 𝑥𝑖,𝑚𝑘′𝑘 = 1 ∀𝑘 ∈ 𝐾
𝑖∈𝑁𝑘
(6)
∑ 𝑥𝑖𝑗𝑘
𝑖∈𝑉𝑘
− ∑ 𝑥𝑗𝑖𝑘
𝑖∈𝑉𝑘
= 0 ∀𝑘 ∈ 𝐾, ∀𝑗 ∈ 𝑁𝑘 (7)
𝑆𝑖𝑘 + 𝑡𝑖 +∑
𝑑𝑖𝑗𝑤𝑖𝑗𝑟
�̅�2𝑟∈𝑟
+𝑀𝑖𝑗𝑘 (1 − 𝑥𝑖𝑗
𝑘 ) ≤ 𝑆𝑗𝑘 ∀𝑘 ∈ 𝐾, ∀(𝑖, 𝑗) ∈ 𝐴𝑘 (8)
𝑎𝑖 ≤ 𝑆𝑖𝑘 ≤ 𝑏𝑖 ∀𝑘 ∈ 𝐾, ∀𝑖 ∈ 𝑉𝑘 (9)
𝑆𝑗𝑘 + 𝑡𝑖 +∑
𝑑𝑗0𝑤𝑗0𝑟
�̅�2𝑟∈𝑟
− 𝐹(1 − 𝑥𝑗0𝑘 ) ≤ 𝑂𝑗
𝑘 ∀𝑘 ∈ 𝐾, ∀𝑗 ∈ 𝐴𝑘 (10)
𝐿𝑖𝑘 + 𝑞𝑖 +𝑊𝑖𝑗
𝑘(1 − 𝑥𝑖𝑗𝑘 ) ≤ 𝐿𝑗
𝑘 ∀𝑘 ∈ 𝐾, ∀(𝑖, 𝑗) ∈ 𝐴𝑘 (11)
𝐿𝑖𝑘 ≤ 𝑄𝑘 ∀𝑘 ∈ 𝐾, ∀𝑖 ∈ 𝑉𝑘 (12)
∑𝑑𝑖𝑗𝑤𝑖𝑗
𝑟
�̅�2𝑟∈𝑅
≤ 𝑇1 ∀𝑘 ∈ 𝐾, ∀(𝑖, 𝑗) ∈ 𝐴 (13)
𝑂𝑗𝑘 ≤ 𝑇2 ∀𝑘 ∈ 𝐾, ∀𝑗 ∈ 𝐴 (14)
𝑥𝑖𝑗𝑘 ∈ {0,1} ∀𝑘 ∈ 𝐾, ∀(𝑖, 𝑗) ∈ 𝐴 (15)
𝑊𝑖𝑗𝑘 ∈ {0,1} ∀(𝑖, 𝑗) ∈ 𝐴, 𝑟 = 1,… , 𝑅 (16)
𝑆𝑖𝑘; 𝐿𝑖
𝑘; 𝑂𝑖𝑘 ≥ 0 ∀𝑘 ∈ 𝐾, ∀𝑖 ∈ 𝑉𝑘 (17)
The objective function, which consists of function (1) and (2), minimizes the total costs associated with
the routing of the vehicles. The first component entails the speed-related costs, where the second
looks at other travel related costs. Constraint (3) states that each of the pickup locations needs to be
visited, where constraint (4) states that all of the delivery locations need to be visited.
Constraints (5)–(7) ensure that each vehicle k starts from its start depot and terminates its route at its
terminal depot. Constraints, (8), (10) and (11) are linearized as in Cordeau (2006). Constraint (8), where
𝑀𝑖𝑗𝑘 = max {0, 𝑏𝑖 + 𝑡𝑖 +
𝑑𝑖𝑗
𝑙𝑖𝑗− 𝑎𝑗} enfores the time window restrictions. We also assume 𝑡𝑖,𝑛+1 + 𝑡𝑖 >
0. Constraints (10), where F is a large number, also enforce the time-window restrictions. The time
between nodes i and j also holds the triangular inequality: 𝑡𝑖𝑗 ≤ 𝑡𝑖𝑙 + 𝑡𝑙𝑗 for all 𝑖, 𝑗, 𝑙 ∈ 𝑉.Constraints
(11) and (12) are the load constrants, where 𝑊𝑖𝑗𝑘 = min {𝑄𝑘, 𝑄𝑘 + 𝑞}. Constraints (13) ensure that the
drving time between nodes i and j must be less than the maximum driving time between arcs.
Constraints (14) ensure that the total route time must be less than the allowed total time. For the
development of this mathematical model, the work of Demir et al. (2014b) was used.
36
Chapter 5: Development of decision support model For the development of the decision support model, first a look at alternatives is made. We distinguish
between communities, applications and engines. These are somewhat ranked from broadest to
narrowest concept of vehicle routing tools. Communities consist of researchers or practitioners who
share interest and aim to come to new understandings. That said, communities might very well
develop applications or engines. Applications are in this setting defined as total packages that can be
used by practitioners to solve instances of the vehicle routing problem. Engines are defined as the
building blocks of which applications consist. This may therefore be the shell in which a piece of code
runs, a web service for geocoding, or the actual code that solves instances of the VRP.
After a look at alternatives is made, a starting point is chosen from which the tailor made model for
the case at IDLV will be made. When choosing a starting point we need to focus on the degree to which
it can be used by IDLV when implementing, the degree to which it can be altered, and the degree to
which its quality can be assessed by assessors.
In the final stage, step by step the starting point is expanded until it can solve practical cases at IDLV
as close to the reality as possible.
5.1 Comparing alternatives To start with developing a routing tool, it suits to check around for solutions that are already
developed. Many research has been done about the vehicle routing problem, and around this research
communities have developed. In these communities, research insights are shared between researchers
or practitioners. Furthermore we distinguish between applications that can autonomously solve
instances of the vehicle routing problem, and engines or web services. These engines or web services
are either pieces of code that can be used to solve instances of the vehicle routing problem together
with an application, or services needed to prepare input or output for an application to work better.
5.1.1 Communities
5.1.1.1 Verolog
The European working group on vehicle routing and logistics optimization (VeRoLog) and its
community are focused on active research in vehicle routing problems. The purpose of this working
group is to constitute a reference point for the research community in order to deepen the knowledge
in vehicle routing problems, develop tools to solve instances of the vehicle routing problem and to be
a place where researchers and practitioners can share their knowledge.
5.1.2 Applications
5.1.2.1 ODL Studio
ODL Studio is an open source program supplied by a small UK-based firm. The firm aims to provide
open source solutions for transport logistics, particularly those requiring modern computational
intelligence techniques. Even though the aim of this company is to provide free solutions with their
open source application, they offer consulting at an hourly rate to tailor fit the application to
practitioner’s needs. The ODL studio also uses the open source engine JSPRIT. For the distance matrices
and mapping, ODL uses a file from GraphHopper. The geocoding is done using a database file that can
couple zip codes to coordinates. The application can thus function as a shell where the user loads an
engine and certain databases, sets constraints and is then able to solve instances of the vehicle routing
problem. However these tasks are not easily performed and require IT expertise. Unfortunately this
makes the application not as accessible to practitioners as may have been meant.
37
5.1.2.2 G. Erdoğan’s VRP Solver
Dr. G. Erdoğan is an associate professor at University of Bath and active member of the VeRoLog
community. His interest is in researching quality solutions for vehicle routing problems, airline
management and ambulance location problems. As an active member of the VeRoLog community, dr.
Erdogan shares the beliefs for a need for an open platform for researchers to share knowledge about
vehicle routing problems. To this end, he has developed an open source vehicle routing tool he names
the VRP Solver. The VRP solver solves instances of the vehicle routing problem with time windows and
uses the Bing API service for geocoding and distance matrix calculation. By choosing for an Excel VBA
script based solver, Dr. Erdogan makes the logic behind the code understandable to most practitioners
and readers, and also easily extended into different applications. In contrast to ODL Studio, this
application is very accessible to practitioners and students. With great accessibility, understandability
and flexibility for which Excel VBA is known, unfortunately also issues arise. The programming style
adopted in this application is called object-oriented programming. For this style of coding, the more
classical C++ programming language is known to be able to run significantly faster (Kimme, 2003).
5.1.2.3 PTV Group’s xTour
The PTV Group’s xTour is an application that consists of several modules. PTV Group started as a
company that provided a tracking service for trucks. From this, it has grown to a large software
developer that offers software for a large scale of logistics purposes, such as mapping, geocoding,
tracking and routing services. The xServer is an application, or more a package, that consists of multiple
modules. By selecting the modules they need, PTV Group’s customers can build the perfect logistics
software for their company’s needs. The modules will be handled in section (5.1.3.5). The main idea is
that the xTour serves an application for planners to work with, however. PTV Group has well
researched and developed products and is therefore a reliable partner for logistics service providers
to cooperate with. The results of the application, as a result of the thorough development, are
supposed to be very good. Supposedly however, the reliability and quality of PTV Group’s products
might come with a high price tag.
5.1.3 Engines and web services
5.1.3.1 JSPRIT Engine
JSPRIT is a GitHub (a platform for developers to share and co-develop code) project where experts aim
to develop heuristics that can solve benchmark instances of the vehicle routing problem. It can
therefore also be seen as a community, but since some applications such as ODL studio use JSPRIT’s
engine, we shall address it as an engine here as well. The engine works in Java and aims to solve
benchmark instances of the VRP. When for some benchmark instances problems arise, the community
aims to codevelop betters heuristics, this way the JSPRIT engine keeps getting better. Since the engine
is Java based, it is possible for people to adapt it to their own application. ODL Studio (5.1.2.1) for
example also runs on the JSPRIT engine. Supposedly integrating the engine with an application takes
some tailoring and specialist programming skills, but when one possesses these skills it can be very
rewarding to implement the JSPRIT engine.
5.1.3.2 Graphhopper
GraphHopper is a young, Germany-based firm that specializes in mapping solutions. It uses the
OpenStreetMaps maps to provide services such as geocoding, distance matrix calculation and even
solving instances of the vehicle routing problem as a web service. For the batch matrix calculation,
customers can post a request and using HTTP style requests, can obtain the distance matrix a few
instances later. These services are offered at a monthly price, depending on the size of the requests.
Graphhopper is also currently looking into online services that can solve VRP instances for customers.
38
5.1.3.3 Openstreetmaps
Openstreetmaps is a project started in Germany that focuses on distributing free geographic data over
the world. There are other geographic data sources such as google and bing, but the use of their
services is rarely 100% free, since technical or legal restrictions exist. This was the incentive for the
project to start. Openstreetmaps aims to be 100% free without restrictions, so that people can also
use the underlying geographical data of maps, such as geocoding. Openstreetmaps is still expanding
their data by contributions and user surveys.
5.1.3.4 Google and Bing APIs
Google and Bing have a vast knowledge of geographical data and allow for individual developers and
corporate to use this underlying in the form of APIs. An API is an Application Programming Interface,
which means a set of definitions which allows applications or programs to communicate with other
programs or services. In this sense, a web API allows for a program to communicate with the web
service, for example post requests and fetch responses. So for an application to need some sort of data
transformation, for example geocoding, where an address string is converted into coordinates, a web
API can be used. This and other mapping services are offered by Google Maps as well as by Bing Maps.
They invite developers to use the APIs and there is well documented information on how to use the
APIs. For small instances or requests, this service is free. However if the service is to be used on a bigger
scale, for commercial purposes the companies might require a fee. To safeguard for someone taking
advantage of these services, there are some user limits that Google and Bing use per IP-address. Limits
cover the times between requests as well as an absolute amount of requests that may be done per IP-
address per day.
5.1.3.5 PTV xServer modules
Basically the PTV modules operate the same way as APIs, in the sense that they also act out a certain
request that is needed for the total routing task of a company. There are some differences however.
The main thing is that when a customer chooses to use a module, they are not posting requests to a
server, but they are more buying the knowledge. In many cases some kind of server or module is
installed at a PTV Group customer. Arguably this guards data-safety for companies a lot better. The
downside is that such a module then immediately also becomes more expensive. Because modules are
installed and knowledge is more or less bought/rented, there also exists little possibilities for
companies to trial the modules. With the web API services developers can set up their code, set up the
interaction and run small use cases to trial the service. If the service is to their liking, a professional
license can be bought to run larger instances at faster speeds. With PTV Group there still is an option
to test the modules to some degree, but the threshold is arguably higher. However together with data-
safety it is also commonly understood that the PTV Group modules are of very high quality.
5.2 VRP-model As described in section 5.1.2.2, the application by Dr. G. Erdoğan is used as a starting point for the
tailor made model. It is chosen because the programming language VBA is fairly simple to understand,
its shell (MS Excel) has an easy and well documented interface to communicate with other programs,
and results are easily documented. In the table (9) below we can see what types of functionalities were
in the original solver, versus the functionalities that were added. In the remainder of section 5.2,
stepwise these functionalities are added. For a screenshot of the original VRP Solver’s console
worksheet, we urge the reader to have a look at appendix (9.1.8).
39
FEATURE IN ORIGINAL SOLVER
IN REVISED SOLVER
TIME WINDOWS ✓ ✓ PICKUPS ✓ ✓ DELIVERIES ✓ ✓ MIXED BACKHAULS (+ VISUALIZATION) X ✓ TAILGATE REQUIREMENTS (+ VISUALIZATION) X ✓ HV/HR REQUIREMENTS (+ VISUALIZATION) X ✓ TAILORED HEURISTIC TO ENSURE TAILGATE AND HVHR REQUIREMENTS
X ✓
MAXIMUM STOPS PER ROUTE X ✓ SAFETY PERCENTAGE FOR VEHICLE CAPACITY X ✓ ADDRESS CONSOLIDATION - PLANNING LINE REDUCTION X ✓ EMISSION MINIMIZATION AND CALCULATION X ✓ LOADING FACTOR CALCULATION X ✓
Table 9: Overview about added features in the revised solver
Load preferences and
customer locations
Construct solution
Improve solution
Evaluate solution
Evaluate route
As long as timer runs
Print solutionTimer ends
Figure 12: Schematic overview of how the solution data construct flows within the VRP Solver
5.2.1 Revised VRP-model with Mixed Backhauls (MB) For a pure pickup or pure delivery problem, the capacity constraints that need to be met can simply
be calculated as an accumulation of the quantities required by customers visited. When a new order
is considered to be added to an existing route, it suffices to check if the total capacity of the vehicle is
met or not. This makes the evaluation of a route very easy and therefore also the heuristic fast. Below
both the capacity calculation method and the decision process for adding another vertex to the route
is shown. Once this fairly simple mathematical logic is shown we can show how complexity increases
when taking mixed backhauls into account.
40
Depot
APickup 2
BPickup 3
CPickup 1
DPickup 5
EPickup 2
(0;A) Carrying: 0
(A:B) Carrying 2
(B;C) Carrying 5 (C;D) Carrying: 6
(D;E) Carrying: 11
(E;0) Carrying: 13
0
2
4
6
8
10
12
14
(0;A) (A;B) (B;C) (C;D) (D;E) (E;0)
Vehicle load
Depot
A
B
C
D
E
Depot
ADeliver/pickup 2
BDeliver/pickup 3
CDeliver/pickup 1
DDeliver/pickup 5
EDeliver/pickup 2
(E) + (A,B,C,D) exceeds vehicle
capacity
(E) + (A,B,C,D) fits within
vehicle capacity
Figure 13: Calculating capacity requirements Figure 14: Decision process for adding new vertex
As can be seen in the examples above, capacity requirements are simply an accumulation of the
quantities that need to be delivered or picked up. For pickups, the same logic applies but the vehicle
starts with a full truck and delivers everything along the route. Note here, that the order in which
customers are visited is not a factor in deciding if capacity requirements are met. From figure (13) we
learn that the maximum capacity carried in the vehicle is 13 loading units, which is equal to the sum of
all the locations’ amounts. This also becomes clear in Figure (14) where the insertion of vertex E could
very well be between any of the other vertices, and the same type of calculation would have needed
to be made.
For mixed backhauls, the order in which customers are within a route is more important, since load
carried on certain arcs other than the first or final one represent the maximum carried load. To
calculate this load, for each different arc also the amount carried needs to be calculated as in figure
(15). Now, the vehicle starts with the sum the load of the delivery orders.
Depot
APickup 5
BDeliver 3
CPickup 2
DPickup 3
EDeliver 5
(0;A) Carrying: ∑Deliveries= 8
(A;B) Carrying: (0;A) + P(A)= 8+5=13
(A;B) Carrying: (A;B)-D(B)= 13-3=10
(C;D) Carrying: (B;C) + P(C)=10+2=12
(D;E) Carrying: (C;D) + P(D)=12+3=15
(E;0) Carrying: (D;E) - D(5)=15-5=10
0
2
4
6
8
10
12
14
16
(0;A) (A;B) (B;C) (C;D) (D;E) (E;0)
Vehicle load
Figure 15: Calculating capacity requirements for mixed backhauls
As can be seen in figure (15), the vehicle load changes over time and the maximum load is realized
somewhere between customer visits. In the example, the load transported on the previous arc is used
to calculate the load on the concerning arc. It becomes clear that the order in which customers are
41
visited is necessary to calculate if capacity requirements are met. The order of customer visits also has
implications for the decision process when adding new vertices to an existing route.
Depot
APickup 5
BDeliver 3
CPickup 2
DPickup 3
EDeliver 5
(E) + (0;A) OR(E) + (A;B) OR(E) + (B;C) OR(E) + (C;D) OR
(D;E)Exceeds vehicle capacity
(E) + (0;A) Fits AND(E) + (A;B) Fits AND(E) + (B;C) Fits AND(E) + (C;D) Fits AND
(D;E) Fitswithin vehicle capacity
Figure 16: Decision process for adding new vertex to a MB route
When a decision needs to be made regarding new vertices, the load on all of the arcs needs to
recalcutated to ensure feasibility. In the original situation a route is evaluated by a function that checks
multiple aspects as well as a capacity check. The capacity check originally looked something like this in
pseudocode (in case of a pickup problem):
Set Carried load at 0
Set Capacity at x
FOR each vertex visited in the route:
Add the amount to be picked up at this vertex to the carried
load
NEXT vertex visited in the route
IF carried load > capacity
The route is infeasible
Penalize the route by (carried load-capacity)/capacity
End if
As can be seen, this only needs one loop, where a summation is made to see if the route exceeds
vehicle capacity. Now we can extend this logic to the situation in which mixed backhauls are allowed.
Note that now for each vertex not just the load is expected to be known, but both a pickup load and a
delivery load.
Set total distribution load at 0
Set capacity at x
42
Set maximum load at 0
FOR each vertex visited in the route:
If the vertex is a delivery address:
Add the amount to be delivered at this vertex to the
total distribution load
End if
NEXT vertex visited in the route
Now the total amount to be distributed is known. This is the load transported from the depot to the
first customer, thus the load on the first arc. Next we can calculate for each of the arcs the loads
transported, update the maximum load variable, in order to be able to do the capacity check.
Set load at vertex() at 0
FOR each vertex i visited in the route:
If this is the first vertex:
Load at vertex(i) = total distribution load –
distribution load this vertex + collection load this
vertex
If load at vertex(i) > maximum load:
Maximum load = load at vertex(i)
End if
End if
If this is not the first vertex:
Load at vertex(i) = load at vertex (i-1) – distribution
load this vertex + collection load this vertex
If load at vertex(i) > maximum load:
Maximum load = load at vertex(i)
End if
End if
NEXT vertex visited in the route
If maximum load > capacity
The route is infeasible
Penalize the route by (maximum load-capacity)/capacity
End if
5.2.2 Revised VRPMB-model with true fleet heterogeneity In some cases as well as the case with the solver model by G. Erdogan (2014), heterogeneity in vehicles
is treated in the following way. Different types of vehicles have their own parameters, such as costs
and capacities. In the solver model by G. Erdogan (2014), vehicle types may differ on the following
43
aspects: capacity, fixed cost per trip and cost per unit distance. Here it becomes clear that this is
intended for when a fleet consists of vehicles of different size, age or cost (for example, rented vehicles
are more expensive than owned vehicles). In a case where some customer locations may only be visited
with a certain type of vehicle, this type of fleet heterogeneity sufficient to model reality. This is the
case at IDLV, where apart from these location-related constraints, also order-related constraints may
require specific vehicle types. Here, some types of orders can be transported in all vehicles, while some
only with one type of vehicle. To avoid confusion a table is given below
Orders may have location-related constraints (L) and/or order-related constraints (O). All orders ={𝐿 ∪
𝑂}. This means that orders can have no constraints, only location-related constraints, only order-
related constraints or both constraints.
Vehicles may be able to transport orders with location-related constraint L (LC) and/or order-related
constraints (OC). All vehicles ={𝐿𝐶 ∪ 𝑂𝐶}. This makes it so that there are four types of vehicles, one
that cannot transport orders with specific constraints, one type that can transport orders with location-
related constraints, one that can transport only order with order-related constraints and one type that
can transport both.
ORDER/VEHICLE NO SPECIFICATIONS LC OC LC + OC
NO CONSTRAINTS ✓ ✓ ✓ ✓ L X ✓ X ✓ O X X ✓ ✓ L + O X X X ✓
Table 10: overview of possible constraints that an order can have versus the ones a vehicle can carry
As can be seen, orders without constraints can be transported in any type of vehicle, and vehicles that
have all possible specifications can transport all orders. Integrating this into the model consists of three
steps:
1. Setting vehicle specifications
2. Setting order constraints
3. Allowing the heuristic to check if orders are coupled to the right vehicle
4. Speeding up the heuristic to not propose changes that are not allowed (section 5.2.2)
For step 3, an excerpt from the pseudocode for checking if a route has orders assigned to it that are
now allowed is given below:
FOR each vertex visited in the route:
IF the vertex has constraint L AND if the vehicle does not have
specification LC THEN
Route is infeasible
Increase L-related infeasibility by 1
END IF
IF the vertex has constraint O AND if the vehicle does not have
specification OC THEN
Route is infeasible
Increase O-related infeasibility by 1
END IF
44
NEXT vertex visited in the route
Penalize the route by the amount of L-related infeasibilities
Penalize the route by the amount of O-related infeasibilities
5.2.2 Revised HFVRPMB-model with faster LNS heuristic The way the different operators of the LNS heuristic work, is that in nested loops, either for one route
or for one vertex, an iteration through all the other routes is or vertices is made to see if some details
can be exchanged. When such an alternation is made, an evaluation is made to assess the associated
differences in total costs and distances traveled. Also, some feasibility checks are made to see if for
example capacity constraints are violated. Everything is weighed and it can be decided to keep the
‘best’ of the two options. For capacity, cost and time window checks, it makes sense to use a separate
procedure because of the complexity that comes with calculating these kinds of route feasibilities. As
described in section 5.2.2, these checks have already been added to the evaluation procedure.
However from a computational point of view, it makes no sense to add an order that has certain
constraints, to a vehicle that cannot transport these goods, only to have a separate procedure decide
that this alternation has made the route infeasible. Therefore it makes sense to only allow mutations
that do not exceed the HV/HR constraints as well as the tailgate constraints. Other theories state that
an unbounded heuristic allows for more ‘creative’ steps, and that thus in the end a better feasible
solution may be achieved, even though the temporary solutions may be infeasible. For our case, both
these assumptions will be tested in section 6.1 with a computational study. However we note that for
IDLV the success factors are time and feasibility. When keeping in mind that the planning department
will still perform alterations to a proposed solution, it makes sense to go for a bounded algorithm to
come to feasible solutions quickly.
This issue is solved fairly simply in three steps. First we must determine if vehicles or vertices are
exchanged. Once this is known, a skip function is built. In the case of a vertex, the route to which it
may be added may only be one that fits the specific needs of the vertex. First a simplified version of
an operator is given
First loop: for each vehicle
First loop: for each vertex in vehicle
Second loop: for each vehicle (start at vehicle from
first loop + 1)
Second loop: for each vertex in vehicle
Switch vertex from first loop with the one from
second loop
Evaluate changes
Next
Next
Next
Next
45
Now we can show the faster version
First loop: for each vehicle i
First loop: for each vertex in vehicle j
Second loop: for each vehicle (start at vehicle from
first loop + 1) k
IF vertex j needs a tailgate and vehicle k has no
tailgate: go to SKIP
IF vertex j needs a HVHR trailer and vehicle k has no
HVHR trailer: go to SKIP
Second loop: for each vertex in vehicle l
Switch vertex from first loop with the one from
second loop
Evaluate changes
Next l
SKIP:
Next k
Next j
Next i
5.3 Revised HFVRPMB-model with green extension (G-HFVRPMB) In the original model, cost and distance are minimized. However with mixed backhauls, instead of load
increasing non-decreasingly with pure pickups or load decreasing non-increasingly with pure
deliveries, the load varies on each arc within the route. This means that when minimizing the distance,
this results in arbitrary load-factors over the arcs. In the heuristic there is already a safeguard to make
sure no capacity constraints are violated, but that is the most that is done with respect to load factor.
Now that load factors are already calculated in terms of taking up trailer space, this can be extended
to weight related load factors. Once weight load factors are known, it can be calculated how these
affect fuel consumption and the emission of unwanted greenhouse gases.
IDLV mainly drives Volvo trucks. In their latest publishing about truck specifications, Volvo has stated
that for distribution traffic, their trucks use on average 22.5 liters of diesel when empty, and 27.5 liters
when fully loaded, per 100km driven. For 1 liter of diesel burnt, it is known that approximately 2.6
kilograms of CO2 are emitted, and 3,15 kilograms of CO2e (Demir et al., 2014a). With these numbers it
is quickly calculated that an empty Volvo truck emits about 0.585 kilogram per kilometer driven,
whereas when the truck is full about 0.715 kilograms of CO2 are emitted. Now if we want to use this
information to calculate emissions, we can assume a ‘base’ emission of 0.585 kilograms CO2 per driven
kilometer. Then we can correct for each arc the load factor multiplied with the surplus emission of a
fully loaded truck (0.13 kilograms CO2). Afterwards, since the relation between CO2 and CO2e is linear,
we can also recalculate the CO2e emissions by correcting the factors with 2,6
3,15.
46
The equation becomes as follows:
Emission to be reduced:
𝐶𝑂2𝑒(𝑘𝑔) =∑𝑥𝑖𝑗 ∗ 𝑒𝑚𝑝𝑡𝑦 𝐶𝑂2𝑒 𝑒𝑚𝑖𝑠𝑠𝑖𝑜𝑛/𝑘𝑚
𝑛
𝑖=𝑜
+∑𝑙𝑓𝑖𝑗 ∗ 𝑥𝑖𝑗 ∗ 𝑠𝑢𝑟𝑝𝑙𝑢𝑠 𝐶𝑂2 𝑒𝑚𝑖𝑠𝑠𝑖𝑜𝑛/𝑘𝑚
𝑛
𝑖=𝑜
𝐶𝑂2(𝑘𝑔) =∑𝑥𝑖𝑗 ∗ 0.585 ∗2,6
3,15
𝑛
𝑖=𝑜
+∑𝑙𝑓𝑖𝑗 ∗ 𝑥𝑖𝑗 ∗ 0.13 ∗2,6
3,15
𝑛
𝑖=𝑜
5.5 Revised geocoding and distance matrix In the available data, zipcodes and country codes are available. As described before, the process
converting address strings to coordinates is called geocoding. The original model uses the web API
from bing. However some research finds that the geocoding API from google generates better results,
in faster times, and can handle more instances per day. Therefore, another geocoding system is used.
The Google API allows for more requests, thus speeding up the code.
For the model to work, a distance matrix that contains all possible distances between the set of
customer locations is needed. There are multiple ways of calculating this matrix. One can calculate the
direct ‘crow flies’ distance using formulas, or when geographical data about road maps is available one
may use this for a distance matrix more close to reality. Also, instead of distances, travel times may be
used. If one wants to use road mapping data, the option exists to use a module or a web API service,
as explained before. For the purpose of this thesis, it does not make sense to buy a module, so there
is looked into web API services. Again, within the web API services, two options exist. One can use a
directions API, to get directions between two points and filter for the total distance or duration. This
way, all the entries for the matrix have to be requested one by one. This is the way the original tool
was organized. This is a fairly simply operation and works fast enough when the amount of customers
is low. However since the matrix has n2 entries, where n is the number of customers, the numbers
grow exponentially and with 300 customers, 90.000 single requests will take a long time, and might
overflow the request limit.
The other option is called a batch distance matrix API, where the user posts all addresses and a matrix
is fed back. These require a bit more code to be set up, but improve the overall quality and
sustainability of the tool. Please note that this extension will cost money. However the code for the
batch distance matrix API by Graphopper is chosen to be set up, to show IDLBV how such requests
work. In the future then the implementation of such a component can be made simple.
Please note that the proposed final model does not yet support these batch style requests due to data
safety concerns and the fact that these larger request require a monthly fee. However the code works
and is implementable in the future. As stated before, Graphhopper is a young company and therefore
their documentation is not that advanced. The code developed to work from excel is also shared with
them and will also be used for customer support.
5.6 Discussion After all extensions have been dealt with, we can verbally give an impression about the purpose of this
tool. The main differences in functionalities added in this chapter can be seen by comparing the
console worksheet of the original solver (9.1.8) with the console worksheet of the updated solver
(9.1.9).
47
This tool can convert source data from planning lines to coordinates with specific information about
how much to pick up or deliver, when and with what type of vehicle. After this, our tool can minimize
either the distance driven needed to visit all customers, or the emission used to visit all customers. The
tool works with penalty costs for crossing constraints and also has hard constraints that cannot be
crossed. Together with penalty costs and profits a cost function is used.
48
Chapter 6: Computational studies Four sets of case studies will be performed. The first case study aims to show the effects of altering
the algorithm to create better efficiency. The unaltered and altered version are compared. The second
case study looks at the different operators of the algorithm and how they behave with different
amount of customers, to check for diversificating or intensificating effects. The term diversification
refers to the ability of a heuristic or operator to visit many regions of the search space, where the term
intensification refers to the ability of an operator or heuristic to obtain high quality solutions in a
certain region (Lozanoa, García-Martínez, 2009). In the third case study, the objective function is
changed from a combination of cost and distance minimization, to a combination of cost and emission
minimization. Finally, a comparison between the results from the planning department and the solver
are compared in a real life case. This final case study will be presented in chapter 7. Throughout the
case studies, multiple quality indicators are used: infeasibilities, iteration lengths, amount of iterations
within the given time, profit, distance driven and CO2e emission. Please note that for the profit quality
indicator, this is only dependent on the amount of orders delivered versus the distance driven. The
load factors and their implications on fuel consumption are not considered. Also, each order is assigned
a ‘profit’ of 100 cost units, to ensure that each order is delivered.
For the source data, actual planning lines from the Benelux department are used. We have two sets of
data, the first dataset is based on shipments that needed collection or distribution on 15-6-2015, we
shall call this dataset A. The second set is of the shipments that needed collection or distribution on 1-
7-2015, henceforth referred as dataset B. Within these datasets, we generate smaller instances to test
the proposed changes. For each set, we select the first N customers, and thus create dataset A-N or B-
N. So, the first 50 customers of the shipments to be executed on 1-7-2015 are referred to as B-50.
Set A has 283 customer locations after consolidation, set B has 313 customer locations after
consolidation. Below we show the entire datasets for A and B. Customer locations for A-50 through A-
250 and B-50 through B-300 can be found in appendices (9.1.6) and (9.1.7).
Figure 17: Customer locations for dataset A. The red dots indicate a HV/HR shipment.
0,
-0,45
-10, LK-5,5, B-13,6, B
-1,2
-0,543
-2, LK-0,5
-1,2
-3,6-9,6
5,6 -13,522
0,8
11,5
-3,2
-4,4
-1,101, E-0,833, E
13,6
-1,2
-0,8
-1,2
-1,6 -1,67,333
0,53-5,7
-4, B
-2,032, LK-0,8
-0,4
13,6, B5,2, LK, E4,4, A
13,6, B
5,9, D
-10-0,5-1,16
-6,8
-1,604
13,6
5, A7, A0, A
-1,5
-0,4
-13,6
-2-0,4
5,6
10
-2,4
-0,8
-1,782-0,4
-2,043
-1,4331,433
-0,4
-0,787-0,041-0,067
-13,6
-0,4
2,65
-0,8
-11,533
-0,1
-3,75-4,05
-13,6, B
-2,0331,1
0,4, LK
-0,4-0,417
13,6, A
-4,2-1,2
2 -0,5-1
-1-0,40,5
-3
-2,173
-0,5
-0,4
0,5
0,8
-1-2
0,439-1
-1-1-1
-3,348, B
-1,5
0,4
-1,2-1,2
-1,6
-0,4
-8,5
-0,4
-0,273
1,2
-2,52 0,2
0,681
-11,60,588
0,8-4,2 0,833
3,6-0,4
13,6
-2,4
-1,2-0,4-0,8, LK
-0,8
-2
0,5
-1,19
-0,47
0,4
5
0,5211,284
3,766
6,3
0,50,5 0,50,400,5 3,5
-1,6, E
13,6
1,6
0,8
1,5, E
0,4
0,5
-0,75
-0,417
-0,521
-0,521
-0,521
-1,6, E
-0,4, E
2,1
-13,6
-0,4
0,40,8-1,6, E
12,8, D2,40,4
2
-0,817
2
-1,363
1,2
0,4
0,4, B
1,6580,531
-0,4-0,438
-0,352
-0,4-0,4
-0,788-1,6
-0,8
-0,8-0,8-0,8
-0,2
0,833
-0,416
-0,596
4
2,15
-0,4, E-2,8, E
-2,8, E
0,6
-1,171, B
-0,448
-1,2
0,5
0,8
1,292
1
0,2
1,2
0,917
1,837
7
-0,4
0,4
1,6
8,8
0,4
0,75
0,924, E
1,5
0,4
1
1,5
3
0,2
5
1
1,93, D
0,4 121,44113,6
1,2111125,5
1,215, E0,20,951,1
9,2
7,61,24,81,152,50,230,41,203
5,45, D13, D
0,577, E
0
4
1,135, E
1,5341,20,3528,4
4,5
1,521
0,82,0550,5
0,4, LK
1,6
2,125
1,01, B
4,4
0,139, E
0,4
2,8341,20,8
2
0,7
3,75, D
0,5, B
2,80,1730,253
49
Figure 18: Customer locations for dataset B. The red dots indicate a HV/HR shipment.
6.1 Computational study: Faster LNS heuristic analysis First of all, the LNS algorithm has been altered to only allow for an alternation to be made to the
solution if that step still ensues feasibility. The aim has been to ensure fast converging to a feasible
final solution, but critics pose that some algorithms need to run more freely (so also into infeasible
solutions) to finally come to a better solution (which then arguably will be feasible again). To test how
the altered, or ‘cramped’ algorithm and the original behave, they can be monitored in a case study.
The reason for an altered algorithm is so that the algorithm speed can increase, and feasible solutions
can be attained as early as possible.
6.1.1 Description of case To measure the difference in speed, one LNS iteration can be measured in both the altered and
unaltered way. We measure the duration of 1 iteration for multiple numbers of customers, for both
the bounded and unbounded heuristic. To measure the differences in outcome, also both the bounded
and unbounded heuristics are ran for multiple sets of customer numbers. We will keep track of
multiple performance indicators: profit, total distance traversed and CO2-emission.
01
23
4
5
6
78910
11
12
13
14
151617
18
19
20
21
2223
24
2526
27
2829
3031
32
33
34
35
36
37
38
39
40
4142
43
4445 46 4748
49
50
51
52
53
54
55
56
57 58
59
606162
63
64
65
66
67
68
69
70
71
72
73
7475
76
77
78
79
80
8182
83 84 85
86
87
88
89
90
91
9293
94
95
969798
99
100101
102
103
104105106
107
108109
110
111
112
113
114
115
116
117118
119
120
121122
123
124
125126
127
128 129130131
132
133134 135
136
137
138
139
140
141
142143
144145
146
147
148
149
150
151152153
154155
156
157
158
159
160
161
162163
164
165166167
168169
170
171
172
173174 175
176
177
178
179
180
181182
183
184185
186187
188
189
190191
192
193
194
195
196
197198
199
200
201
202
203
204
205
206207
208
209
210
211
212
213
214
215
216
217
218
219
220221
222
223
224
225
226
227
228229
230
231232233
234235236237238
239240241
242243244245246247
248
249
250
251
252253254255
256
257
258259260261262263264265 266267268269270
271
272
273274
275
276
277
278279
280
281282283284285286287288
289290
291292
293
294295
296
297298299300
301
302
303
304
305306307308
309
310
311
50
6.1.2 Case study results
6.1.2.1 Iteration lengths
N A B
Revised heuristic Original heuristic Revised heuristic Original heuristic 50 6.46 6.73 5.71 5.83 100 46.84 47.25 37.05 38.12 150 120.16 120.32 202.84 204.17 200 >2hrs >2hrs > 2hrs > 2hrs 250 >2hrs >2hrs > 2hrs > 2hrs 300 - - > 2hrs > 2hrs
Table 11: results for datasets A-50 through A-250 and B-50 through B-300, length of one iteration in seconds
6.1.2.2 Profits
N A B
Revised heuristic Original heuristic Revised heuristic Original heuristic 50 6,046.43 6,137.97 3,506.01 3,652.55 100 7,772.59 7,772.59 7,239.47 7,239.60 150 13,279.54 13,297.54 23,613.95 23,401.16 200 14,123.36 13,919.01 28,036.15 27,859.67 250 23,512.75 23,552.80 69,577.40 69,844.66 300 - - 112,613.34 113,464.47
Table 12: results for datasets A-50 through A-250 and B-50 through B-300, profits after running for 5 minutes
6.1.2.3 Distances
N A B
Revised heuristic Original heuristic Revised heuristic Original heuristic 50 4,812.02 4,720.48 3,282.47 3,135.92 100 7,196.43 7,196.43 6,503.56 6,503.43 150 8,085.76 8,085.76 8,365.63 8,578.43 200 10,983.61 11,187.96 11,940.90 12,117.37 250 12,965.88 12,925.82 13,335.14 13,065.88 300 - - 12,993.19 12,152.06
Table 13: results for datasets A-50 through A-250 and B-50 through B-300, Distances in kilometers after running for 5 minutes
6.1.2.4 CO2e emissions
N A B
Revised heuristic Original heuristic Revised heuristic Original heuristic 50 2,224.96 2,141.71 1,591.88 1,627.55 100 3,681.52 3,681.52 3,155.23 3,156.97 150 4,381.70 4,381.70 4,296.01 4,440.67 200 5,864.54 7,964.79 6,302.19 6,316.74 250 7,117.29 7,088.76 7,088.18 6,831.03 300 - - 6,741.96 6,387.33
Table 14: results for datasets A-50 through A-250 and B-50 through B-300, CO2e emissions in kilograms after running for 5 minutes
What we see is that in terms of heuristic speed, even though the revised one is faster, this difference
is negligible. When we check for the quality with multiple amounts of customers, we see that for the
amount of customer from 50 to 150, the quality of the revised one performs equally well or worse than
the original heuristic. This comes as no surprise when one looks at the amount of iterations possible in
these data instances. The penalties when infeasibilities are proposed are still active, so when a
substantial amount of iterations is possible, the LNS heuristic has enough possibilities to converge to a
51
good solution. It is often said that unrestricted algorithms perform better, and need to be able to
iterate through infeasible solutions to come to a better final solution (Edelkamp, 2012). It highly seems
that this the case for the instances where the amount of iterations can be high.
From 200 customers on, the 5 minutes runtime only allow for one iteration, or part of one iteration.
This means that fast conversion becomes more important than the final solution after multiple
iterations. However the results do not necessarily confirm this. One could argue that for 200
customers, the fraction of an iteration that is done allows for the faster LNS heuristic to reach better
results, and that for 250 customers on, the fraction becomes too small for the faster LNS heuristic to
have better results. However such a conclusion would be ungrounded, as there are too many factors
at stake. First of all we do not know exactly the fractions of iterations that are done with each amount
of customers, nor do we know the amount of time one iteration would take. We know that the LNS
heuristic is somewhat faster, but this is a small relative distance.
The overall conclusion is that it is difficult to prove that the revised heuristic performs better than the
original one. For instances where small amounts of iterations can be done it can be proven that it
works worse. Saying that for bigger numbers of customers the faster LNS heuristic would work better,
would also be speculating, since it seems to only work better when a specific amount of iterations is
allowed.
6.2 Computational study: LNS operator analysis For the final two case studies, several operators of the LNS algorithm can be separately activated over
test cases to see the way they work. As said before, some heuristics can ensure that solutions converge
to better solutions, with a risk of getting into a local optimum, while others explore the large solution
space. The first phenomenon is called intensification and is more desirable in the final stage of a run.
In the first stage, the so called diversification provides for entire solution space exploration. Together
these alternations can result in better optimized results.
To research these phenomena in all operators, a case studies are performed over the two datasets are
done. The time is set fixed. This way also the behavior of CPU time as it increases with more customers
can be monitored and compared with iterations. The operators include:
Swap: customers are swapped within a route, so the order of customer visits within a route is
switched. This is an example of intra-route optimization.
Relocate: the relocate operator looks at each route, and selects if vertices of that route can
better be put on another route. This type of operation is called inter-route optimization, since
two routes interchange vertices with one operation.
Two-Opt: is a simple local search algorithm first proposed by Croes in 1958 for solving the
traveling salesman problem. The main idea behind it is to take a route that crosses over itself
and reorder it so that it does not.
Chain reversal: the chain reversal operator changes the order of a route where the start
becomes the end, and the end the start.
Full swap: a combination of swap, where the order of a route is mixed, and relocate, where
also other vehicles are selected.
6.2.1 Description of case The LNS heuristic consists of five operators, some of which are optimization algorithms. Each of these
operators perform one sort of alteration the solution, which consists of multiple routes. For each
operator, the alteration it performs may result in a better overall saving, but by only running that
operator, the solution might get stuck in a local optimum. When one has multiple operators that run
52
sequentially, the chance of getting stuck in such an optimum is smaller. With some simple alterations
to the solver tool, we can set constraints that only a subset of the operators can run. Now we can
analyze the results and possibly draw conclusions about each of the operators.
6.2.2 Case study results
6.2.2.1 Iterations
ITER
ATI
ON
S
N TYPE OF OPERATOR
Swap Relocate Two-Opt Chain reversal Full swap All All (30 minutes) A-50 384 293 1575 3442 3426 96 580 A-100 24 8 67 426 454 7 24 A-150 6 2 8 104 133 1 1 A-200 1 1 2 51 62 1 1 A-250 1 1 2 25 3 1 1
Table 15: Results for datasets A-50 through A-250, iterations ran in 5 minutes
ITER
ATI
ON
S
N TYPE OF OPERATOR (5 MINUTES RUNTIME)
Swap Relocate Two-Opt Chain reversal Full swap All All (30 minutes) B-50 348 312 1166 2866 2083 71 496 B-100 31 38 98 489 313 6 18 B-150 3 5 10 118 113 1 3 B-200 2 1 5 55 20 1 1 B-250 1 1 1 19 28 1 1 B-300 1 1 1 13 12
Table 16: Results for datasets B-50 through B-300, iterations ran in 5 minutes
6.2.2.2 Profits
N TYPE OF OPERATOR (5 MINUTES RUNTIME)
Swap Relocate Two-Opt Chain reversal
Full swap All All (30 minutes)
A-50 6,174,11 6,172,98 6,215,74 6,357,95 6,100,41 6,049,64 6,078,74 A-100
7,528,81 8,517,88 7,191,46 7,766,74 8,175,58 8103,92 8,118,03
A-150
12,887,58 13,241,54 11,975,66 11,862,24 12,479,96 12,939,90 13,436,91
A-200
14,906,04 15,749,22 13,974,56 12,902,94 14,103,95 14,397,74 15,213,59
A-250
24,604,15 25,867,90 22,704,03 21,860,35 23,420,79 24,290,92 25,762,94
Table 17: Results for datasets A-50 through A-250, profits realized in 5 minutes runtime
53
N TYPE OF OPERATOR (5 MINUTES RUNTIME)
Swap Relocate Two-Opt Chain reversal
Full swap All All (30 minutes)
B-50
3,288.69 3,275.79 3,310.74 3,372.54 3,386.93 3,552.41 3,429.95
B-100
6,801.78 7,388.75 5,571.96 5,543.48 6,254.13 7,245.34 7,239.60
B-150
23,106.71 24,147.47 21,950.80 22,387.50 22,777.46 23,401.16 24,109.93
B-200
29,540.41 30,553.19 27,529.51 28,398.64 28,325.98 29,659.07 30,045.14
B-250
70,996.47 70,357.50 70,406.43 67,055.26 67,212.16 67,430.76 68,518.58
B-300
113,827.88
112,672.73
113,998.06
111,324.01
110,877.74
112,805.36
112,327.63
Table 18: Results for datasets B-50 through B-300, profits realized in 5 minutes runtime
6.2.2.3 Distances
N TYPE OF OPERATOR (5 MINUTES RUNTIME)
Swap Relocate Two-Opt Chain reversal
Full swap All All (30 minutes)
A-50 4686,33 4689,46 4644,70 4504,49 4760,04 4810,81 4781,71 A-100
7444,21 6457,14 7783,56 7206,28 6795,44 6873,10 6856,99
A-150
8487,73 8125,76 9393,64 9505,06 8889,34 8433,40 7932,39
A-200
10208,93 9363,76 11138,41 12202,04 11003,02 10715,24 9893,38
A-250
11888,47 10618,72 13786,59 14620,27 13067,83 12195,70 10721,68
Table 19: Results for datasets A-50 through A-250, distances driven in 5 minutes runtime
N TYPE OF OPERATOR (5 MINUTES RUNTIME)
Swap Relocate Two-Opt Chain reversal
Full swap All All (30 minutes)
B-50 3,497.79 3,512.69 3,477.74 3,415.93 3,401.54 3,236.07 3,358.52 B-100
6,937.24 6,354.28 8,169.07 8,197.55 7,488.89 6,497.69 6,503.43
B-150
8,872.87 7,830.11 10,026.78 9,586,08 9,198.12 8,578.43 7,867.65
B-200
10,438.64 9,425.86 12,459.54 11,572.41 11,647.06 10,313.97 9,927.91
B-250
9938.07 10,549.04 10,524.11 13,845.28 13,690.38 12,477.78 12,380.96
B-300
11,804.65 12,931.81 11,634.47 14,286.52 14,726.80 12,807.18 13,268.90
Table 20: Results for datasets B-50 through B-300, distances driven in 5 minutes runtime
54
6.2.2.4 Emissions
N TYPE OF OPERATOR (5 MINUTES RUNTIME)
Swap Relocate Two-Opt Chain reversal Full swap All All (30 minutes) A-50 2340,99 2394,19 2233,02 2169,98 2402,23 2488,07 2363,93 A-100 3933,23 3173,98 4246,49 3783,96 3398,42 3738,25 3615,13 A-150 4836,02 4392,56 5187,42 5120,89 4905,33 4919,33 4323,78 A-200 5854,82 5188,89 6363,70 7019,41 5995,36 5991,46 5491,80 A-250 6857,42 6133,86 7843,28 8544,94 7760,51 6866,97 5999,67
Table 21: Results for datasets A-50 through A-250, CO2e emitted in 5 minutes runtime
N TYPE OF OPERATOR (5 MINUTES RUNTIME)
Swap Relocate Two-Opt Chain reversal Full swap All All (30 minutes) B-50 1,794.24 1,680.64 1,690.45 1,754.41 1,722.05 1,607.51 1,773.56 B-100 3,368.16 3,150.48 4,183.06 3,938.74 3,951.87 3,261.59 3,156.97 B-150 4,514.15 4,120.38 5,302.66 4,821.19 4,801.63 4,440.67 3,985.83 B-200 5,336.41 4,845.48 6,732.88 6,088.84 6,018.44 5,166.75 4,892.39 B-250 5,361.14 5,325.65 5,673.42 7,490.97 7,112.33 7,007.39 6,594.16 B-300 6,615.39 6,726.10 6,671.49 8,081.50 7,973.79 6,680.97 6,942.74
Table 22: Results for datasets B-50 through B-300, CO2e emitted in 5 minutes runtime
We can clearly see that the relocate operator performs the best from 100 customers on. In the case of
250 and 150 customers, when the entire heuristic is ran for 30 minutes, this can outperform the
operator running only 5 minutes. In the cases of 100 and 200 customers, the Relocate operator even
outperforms the 30 minute full LNS heuristic. It is clear that the relocate can be a diversificating
operator, where the entire LNS then utilizes other operators to intensify the solution. We also note
that for the cases of 200 and 2
6.3 Green extension analysis To analyze the effects of a green extension, an option is built in that can shift away from optimizing
with regards to distance to minimize the emission. In a pure delivery or pure pickup problem, the load
increases non-decreasing or decreases non-increasing steadily, as said before. In a situation with mixed
backhauls, the load carried throughout a route can change quite a lot. Therefore, the shortest route
between a set of points may have serious implications on fuel consumption and therefore CO2 emission
if this is not explicitly considered. To measure differences, a separate optimization procedure is made
where the emission is calculated per alteration made. The main difference here with respect to the
other alterations to the heuristic, is that now the objective function changes.
6.3.1 Description of the case We introduce the green objective function (5.3), coupled to the load factor calculation function (5.1)
but then for weights instead of loading meters. In the tool, a switch is built that can call two different
optimization procedures. One optimization procedure focuses on profit and distance (original), the
other procedure focuses on emission reduction and profit. We then run this with the same use case as
in (6.1) and (6.2). The results will be organized and measured the same way as has been done in section
(6.1).
55
6.3.2 Case study results
6.3.2.1 Profits
N A B
Revised CO2e objective Original objective Revised CO2e objective Original objective 50 6,813.54 5,884.85 3,695.07 3,652.55 100 8,259.13 7,772.59 7,589.56 7,239.60 150 13,285.12 13,279.54 24,561.35 23,401.16 200 14,680.38 14,285.37 30,136.39 27,859.67 250 24,554.10 23,221.56 70,613.60 69,844.66 300 - - 114,561.03 113,464.47
Table 23: results for datasets A-50 through A-250 and B-50 through B-300, profits after running for 5 minutes
6.3.2.2 Distances
N A B
Revised CO2e objective Original objective Revised CO2e objective Original objective 50 4,058.91 4,973.59 3,099.40 3,135.92 100 6,623.89 7,196.43 6,161.47 6,503.43 150 8,094.18 8,085.76 7,430.23 8,578.43 200 10,432.59 10,821.60 9,850.65 12,117.37 250 11,938.52 13,257.06 10,312.94 13,065.88 300 - - 11,068.51 12,152.06
Table 24: results for datasets A-50 through A-250 and B-50 through B-300, distances in kilometers after running for 5 minutes
6.1.2.3 CO2e emissions
N A B
Revised CO2e objective Original objective Revised CO2e objective Original objective 50 1,970.85 2,456.78 1,490.70 1,627.55 100 3,224.26 3,681.52 3,107.89 3,156.97 150 4,118.83 4,381.70 3,960.02 4,440.67 200 5,339.43 5,731.81 5,263.32 6,316.74 250 6,442.69 7,457.81 5,674.21 6,831.03 300 - - 6,150.91 6,387.33
Table 25: results for datasets A-50 through A-250 and B-50 through B-300, CO2e emissions in kilograms after running for 5 minutes
Here we can see the effects of the shift in focus from distance minimization to emission minimization.
The effects of the emission reduction appear to be positive for profits, distance and emission in all
sorts of instances. As stated before, the load factors attribute to the fuel consumption. With the green
extension, the link between load factors and profits is made. Now that this ‘knowledge’ is available,
arguably the solver becomes aware and is able to generate better results.
56
Chapter 7: Real life case studies The final case study compares the work of the planners with that made by the routing tool. Since the
tool cannot re-use vehicles, but can decide the start time for rides, we shall compare the total amount
of rides, not the materials used. We use data of 1 July 2015.
7.1 Description of the case The amount of planning lines that has been handled by the Benelux planning department for the rides
of the fist of July, 2015 is 401. Even though this is the amount of planning lines, the amount of
addresses visited is lower, since these planning lines are not consolidated on addresses. When the
functionality was added to calculate load factors, this was not added as a reverse check in the solution
worksheet, because the worksheet setup would become unstable. Because we do want to know load
factors of plannings made by the planning department, and because IDLV would like to be able to
calculate these numbers autonomously, a separate tool, called load factor tool henceforth, was
developed to be used, reading only planning lines and their assigned vehicles. The load factor tool
calculates load factors as is done in the original solver, weighing the load factors of each arc in the
route, and weighing the average daily load factors with the distances driven per ride. The load factor
tool also can determine for each ride the order in which customers have been visited, which can then
be used as input for the reverse check solution worksheet to calculate distance and emission figures.
For the solver case, to reduce complexity, a macro was written to consolidate the planning lines
(respecting the maximum capacity of 13,7 loading meters) to 311. The macro was set to distance
minimization, with the faster LNS heuristic, and to respect a capacity utilization percentage of 80%.
The capacity check function for mixed backhauls was updated as a reverse check in the solution
worksheet of the solver, so we will use this as a capacity check, and CO2e emissions for both the solver
case and the planning department case. Now for the solver case, a consolidation macro was written to
reduce the planning lines from 401 to 311.
57
7.2 Case study results
7.2.1 Actual results from the planning department The planning made by the planning department uses a distance of 11185,03 km, with a CO2 emission
of 5538,05 kilograms. 56 rides are used. However, 5 locations are not visited and presumably
outsourced. The map of the planning, as designed by the Benelux planning department of IDLV can be
seen below.
Figure 19: the routes as designed by the Benelux planning department
0
-1,249
-4,5
-2,42
-1,6
13,6
-0,4
-9,52,8-2,46,86,8
4,5
-0,4
-1,068
2,917
13,6-13,6-13,6
-2,8
-3,5
-0,768
-0,542
-0,4
-1,6, LK
-2
-0,4
-2,4
-0,667
-0,267
-13,6
-0,6-0,4
-13,2
-0,4
0,5
-7,6
-0,2
-1-1-1-1 -0,5-0,4-1,033
-0,4, LK
4,565
0,458
0,5
-0,2-3
-0,8
-7,6
-0,8330,4
-0,4-13,6
-0,4-0,4
-0,317
-12,5
-0,408
0,8
-1
-0,5
-1,5
-0,5-0,5
-0,4
-0,5
-0,4
13,6 13,6
-0,5-1,994-0,292-0,4
-0,4-2-2
0,986
-1,5
-1,5-0,833
-13,6
1
-4,4, LK
-2,5
0,53
-13,6
-0,8
-0,4 -0,5
-0,4
-3,229
-13,6-13,6
0,4
-0,5
-0,5-0,4-0,4
-13,6
-1,5
-1,5
-1,5
0,5
-7,2-0,40,2 0,6
-2-2,5
-2,5
-1,6
-0,8
-1,653
-1,067
0,013
-1,623
-3,15
1,4
-10,97
2,55-0,375
-0,4
-2,25
-1
0,05
-1,2
-0,4
-0,4-0,4
-1,5, LK
-2,813,6
0,4
0,4, LK
1
-0,4
0,8
4
1,333
8,40,2
2
1
1
1
-2
-2
0,51
0,4
1
1,5
0,50,5
0,40,5
-1,2
13,6
1
1,2 2,024
-0,122
-3
-8,5
2,5
-0,4
2,24
0,5
-0,4, LK
-1,6
-3,5, LK
9
-0,4, LK
-0,4
-2
0,4, LK
0,948
-8,60,8
0,4
3
0,5
1,037
-1,2
-0,8
2,5
-0,859
0,80,642
-4,058
1,2 0,25
-9,2
-1,2-0,4
-1,6
-1,6
-12,7750,4
-3,049
-0,4
-0,4
0,4
1,2
-2,247
0,4, LK
0,8
0,02
-0,4
-1,925
1
1
0,8
-0,2
-0,2
-0,2-0,2
-0,2
-0,2
-0,2
-0,146
-0,208
-0,146
0,4
-0,104
-1,25
-1,369
2,41
1,5
0,5
13,263
-1,92
0,5
-5,159
0,2
-1,2
-0,4, LK
0,825, LK
-0,2
1
0,6
0,8
-0,2
0,4
0,4
0,8
1,5
0,4
3,667
2,4
3
0,2
0,8
40,5
0,6
0,386
0,95,5
-0,448
-0,273
13,6
2,5
0,8
2,50,513,6
3,47219
4
1,008
0,4
0,5
1,1251,83
2,8
0,4
0,117 112
1,2
0,4
11
0,12
1,5
3,5
0,5, LK0,50,50,51,49
13,61,90,80,40,4
4
2,5, LK
11 0,2730,6580,8337,241,64,43,6
1,1150,2731,1130,5
0,5
0,40,4
2
0,40,40,40,80,410
0,4
4,362
0,4
-0,4
3,5
2,7, LK
2,5
10,51,51
0,40,40,4
11
2,788
0,40,5
11,20,5
0,7470,104
0,8330,40,40,2560,4
0,5
0,4
0,4670,375
2,4
0,8
0,6040,5211,7630,063
0,40,238
1,013
1,5
1,24
0,40,2 0,1230,8
1,27
0,61,7250,5690,5
1,254
0,129
1, LK
7,59
0,5, LK
0,767
1,45
0,2061,267
0,8330,4 0,50,399
3,41
0,413
1,9
58
7.2.2 Results from the solver The planning made by the planning department uses a distance of 8238,31 km, with a CO2 emission of
4336,96 kilograms. 54 rides are used. The 5 locations that were not visited in the original planning have
been visited in the solution returned by the solver. The map of the solver’s solution can be seen below.
Figure 20: The routes as designed by the Solver, with 30 minutes runtime
0
-4,5
-2,42
-1,6
13,6
-0,4
-9,52,8-2,413,6
4,5
-0,4
-1,068
2,917
13,6-13,6-13,6
-2,8
-5,5
-0,768
-0,542
-0,4-1,6, LK
-3,6
-11,885
-2,4
-0,667
-0,267
-13,6
-0,6-0,4
-13,2
-0,4
0,5
-7,6
-0,2
-7
-0,4, LK
4,565
0,458
0,5
-0,8
-7,6
0,4-0,4
-13,6-0,808-0,4
-0,317
-12,5
0,8
-1
-1,5
-0,4
-0,4
13,6 13,6
-0,4
-0,4-2-2
3,396
-1,5
-13,6
4,5
-4,4, LK
-2,5
-13,6
-0,4
-0,4
-3,229
-13,6-13,6
0,4
-0,5
-13,6
-1,5
-1,5
-1,5
0,5
-7,2 0,2 0,6
-2,5
-2,5
-1,6
-0,8
-1,653
-1,067
0,013
-1,623
-3,15
1,4
-10,97
2,55-0,375
-0,4
-2,25
-1
0,05
-1,2
-0,4
-0,4-0,4
-1,5, LK
-2,813,6
1,408
0,4, LK
1
-0,4
0,8
4
1,333
9,20,2
2
1
1
1
-2
-2
9
0,4
1,5
0,50,5
0,40,5
-1,2
13,61,2 2,024
-0,122
-3
-8,5
2,5
-0,4
2,24
0,5
-0,4, LK
-1,6
-3,5, LK
9
-0,4, LK
-0,4
-2
0,4, LK
0,948
-8,60,8
0,41,117
1,037
-1,2
-0,8
2,5
-0,859
1,61,242
-4,058
1,2 0,25
-9,2
-1,2-0,4
-1,6
-1,6
-12,7750,4
-3,049
-0,4
-0,4
0,4
1,2
-2,247
0,4, LK0,02
-0,4
-1,925
1
1
1,2
-0,2
-0,2
-0,2-0,2
-0,2
-0,2
-0,2
-0,146
-0,208
-0,146
-0,104
-1,25
-1,369
1,5
0,5
13,263
-7,079
0,5
0,2
-1,2
-0,4, LK
0,825, LK
-0,2
1,4
0,6
-0,2
0,4
0,8
1,5
0,4
3,667
2,4
3
0,2
0,8
4,5
0,6
0,386
6,4
-0,448
-0,273
13,6
0,8
2,50,513,6
3,47219
40,4
0,5
1,1253,32
2,8
0,4112
1,2
0,4
13,7
0,12
1,5
3,5
0,5, LK1,5
13,64,804
4
5,2, LK
11 0,2730,6580,83313,64,43,6
1,1150,2731,1130,5
2,9
13,2
0,4
5,109
-0,4
3,5
2,5
4
11
4,042
0,40,5
0,8331,4560,4
0,4670,375
5,351
0,82,872
1,013
1,5
1,24
0,1230,8
1,27
1,7250,5690,50,129
1, LK
7,59
0,5, LK
1,45
0,2060,8330,50,399
3,41
0,413
1,9
59
7.3 Case study conclusions Both models use a distance matrix based on Euclidian distances, which means that road distance is not
considered. This may have skewed the results slightly in favor of the solver, but we see that only few
of the routes seem impossible, e.g. crossing water. Also, since the distances of both cases were
calculated in the same way, there is a constant error so the relative reduction in distance is still very
relevant.
When one looks at the graph, one might think that the second case has more lines, therefore driving
more distance. This is however not the case, since the lines from the depot to the first customer, and
from the last customer to the depot have not been drawn on the figures above. It has been chosen to
do so since drawing these lines would seriously clutter the image (even more). So what can be seen is
that in the solution returned by the solver, vehicles that come back from a customer far away from the
depot, do a final (assumed pickup) visit at customer locations close to the depot.
It is admitted that the routes returned by the solver are because of the reason above less aesthetically
appealing and therefore more difficult to realize in practice, but nonetheless should the significant
savings not be disregarded:
CO2 emissions are reduced from 5538,05 kilograms to 4336,96 kilograms, a reduction of
21,69%
The total distance is reduced from 11185,03 km to 8238,31 km, a reduction of 26,35%
The amount of vehicles used decreases from 56 to 54.
60
Chapter 8: Conclusions In this section, the findings and implications from the case studies are briefly summarized. Also an
overview is given of the strong and weak point of implementing either this tool or a commercial
application. We conclude with a look ahead for future recommendations for IDLV and the research
community.
We start off with the overall conclusion that for the IDLV Benelux planning department, even though
they have a very specific set of constraints, automated solutions for their ride planning are very well
possible. To this end, a generic tool that could run stably for 20 customers, was adapted into a tailored,
specific tool that can solve instances up to 300 customers. Even though when using a VBA based
program, the calculation speed was an issue, this should not be an issue with other programming
languages.
The other (academic) overall conclusion that can be drawn is that it has proven to be possible to adapt
the original solver tool by G. Erdogan, to a solver that is able to solve a complex VRP with mixed
backhauls, true fleet heterogeneity and a green extension.
As for the quality of the alterations made to the original solver, we can reflect on the case studies and
draw the following conclusion:
The faster LNS heuristic allows for the script to run somewhat faster, but the difference is
insignificant. The relatively small difference in length might be addressable to the fact that only
a small fraction of the addresses have the special Tailgate / HVHR constraints. However it was
not the iteration speed that was expected to set this alteration apart, but the ability to
converge to feasible solutions faster. However presumably because there are more factors at
play for when the faster LNS heuristic runs, only for one dataset we could find positive results.
This leads us to conclude that the effectiveness of the faster LNS cannot be proven and it would
be wise to keep the unaltered LNS heuristic.
Operator analysis allows to make estimations on diversificating and intensificating aspects of
operators. Because of the best results being returned by the Relocate operator, together with
the fact that for bigger customer instances, iterations take over 30 minutes, the Relocate
operator should be placed at the start of the improvement procedure.
The analysis of the green extension shows that for all datasets the emission reduction focus
outperforms the distance minimization focus. It seems that when using a model with mixed
backhauls, simply minimizing distance is not enough as this is not the only cost factor. However
when the solver is ‘aware’ of the costs attributed to load factors, it is able to perform better.
In the real life case we also see that the tool outperforms the manually made planning on all aspects.
The reductions in distance are over 25%, while the solver option still services the 5 customers that are
sourced out by the planning department. At the same time, the CO2 emissions –and therefore, since
the linear relation, also the fuel consumption– are reduced with over 20%.
Apart from the direct cost and distance savings that are addressed, other benefits also emerge: the
time it takes to make a planning or at least an initial planning reduced significantly. In the time it would
take two planners to draw all the addresses and demand on a map, the solver would have already
mapped everything and made an initial solution. Also to the planners, now more cost drivers and KPIs
become automatically visible, so changes made can be directly and uniformly assessed. This tool can
thus take workload away from planners which with the ever growing customer base and therefore
complexity will be very welcome. Also, automating this process can open the door for other automated
solutions. For example, a digital format of rides can be used by the transshipment center to optimize
61
their operations. Also, when a planning can be made in a shorter amount of time, the planning can be
made later in the day, and more orders can be accepted before starting the designing of routes. This
would increase the service towards customers.
8.1 Limitations When addressing limitations of the solver we first take a viewpoint of what the solving limitations are
from an academic perspective. Even though the tool is not developed as a ready to use application, we
shall still address its limitations as if it were so, to come to better recommendations with respect to
implementation of this or other tools.
Academic viewpoint: The tool in itself works. Its alterations work and the tool can propose sound
solutions. Due to some data sensitivity limitations no actual mapping data could be used, this should
be taken into account when valuing the savings obtained by the solver.
For practical use: At this moment, the tool uses the Google Geocoding API, which looks at the zipcode
and country when geocoding into coordinates. The API is fast, but not always reliable. For zipcodes
ending in 0, the coordinates returned sometimes are not correct. It is assumed that the new TMS
comes with a geocoding service, and coordinates can be saved.
The solver works relatively slow compared to other programming languages. The programming style
used is called object oriented programming. For this style, it is known that other languages such as C++
run significantly faster. Also these shells should be more stable, as excel VBA is not meant to run large
programs. For now, the results returned are good, but more savings could be made when the code is
rewritten into another programming language.
As said before, the distance matrices or travel times matrices are not calculated based on road
mapping. This means that when only distance is known, one average speed is set. Achieving travel
times matrices based on road data would not imply the issue of using one average speed.
For now, it is not possible to implement the tool, since the time windows are still entered into the
planning lines manually, in a string form. There is no unified format so it is not possible for a tool to
read these. Other than this it would also make more sense to delay any form of implementation until
after the new TMS runs.
It is known that IDLV uses different rates for locations further away from the depot, so it was chosen
to use this for the internal profit/penalty function of the solver, as actual profits were not directly
possible to calculate. Profits were thus corrected with a factor consistent to the distance from the
depot. However this makes the profitability of each order about the same, leaving the solver incapable
of choosing which orders not to deliver. Therefore, the solver is incapable of making grounded
decisions on which shipments to charter
8.2 Implementation Any form of implementation would only make sense until after the new TMS is installed and works
well. This is because of lost effort when something has to be reinstalled, and more so because the IT
focus now lies on this new TMS. There would simply be no time to implement it any sooner.
That being said, the regression tool should be relatively easy to implement as it is merely a formula,
and can familiarize planners with working with automated solution suggestions.
For implementing a variant of the routing tool proposed in this thesis, the implementation
requirements roughly follow from the limitations as stated in (8.2). It is recommended to use a
different shell/language and use better geocoding and distance matrix services. The VBA code is fairly
62
easy to read and the changes have been documented in pseudocode so this should not be a problem
for an advanced programmer. For the use of better geographical API services, some code (although in
VBA) has already been set up, as to ease the switch to these services.
When one would look at implementing another, more commercial tool, other requirements can be
set. Here it should be controlled that the constraints and the way they can be addressed with an
improvement heuristic, can be added to the package. It would be very useful if the tailoring of such a
tool was done together with IDLV’s IT consultant and if the code is made clear to the consultant. The
code should not be a black box to the employees of IDLV but should be openly changeable. When we
look back at section (5.1) with this in mind, an option like ODL Studio with the JSPRIT engine would be
preferable over an option like PTV Group’s xTour. For full integration with the TMS however, the PTV
Group products would arguably be more preferable.
8.3 Recommendations The first recommendation is that IDLV should implement both the regression model and keep
collecting data as to strengthen the model. It is a fairly simple tool, but the high quality of the model
shows that it is possible to estimate the needed resources very accurately.
The second recommendation is about IDLV implementing a routing tool. It has been shown, even with
a tool that is not yet using the optimal that significant savings can be made. With the ever growing
complexity, more and more of the planners’ time will have to be addressed to troubleshooting and
accepting and planning on-line orders. To this end, a planning that can be generated fast and reliable
would increase customer service while taking load of planners’ backs. The advice is to start looking into
options for implementing a routing software package, as implementing one would be possible for their
operations and also very beneficial.
As the options for implementing tools are now clear, it is also stressed that IDLV focuses on the type
of data they collect with the new TMS. So when implementing the new TMS, it should be possible to
store time windows in multiple ways.
Now for the recommendation of which tool to implement, this decision is to be made by IDLV, as more
options exist. As stated in (8.3), for each of these options some expert level of programming is needed.
When using the tool in this project as a starting point, the programmer will have to set up a new
program and do a lot of re-writing. The modules needed for the tool to work, as well as the streamlining
also need to be added. When implementing other applications such as open source studios, the
constraints have to be coded and implemented. When the choice for a totally streamlined package is
made, it is recommended not to lose control of the implementation and tailoring. Within these three
options, the tailoring of an open source studio seems like the middle ground, and in this case it
probably is. The JSPRIT engine has already made great results, and the ODL studio allows for control
within the company. A total package will relieve IDLV of most insecurities, but may involve a loss of
control and is commonly presumed the most expensive.
So still some options exist, and it is at this point not possible to blatantly advise in any of the options.
Therefore the final recommendation is to get in touch with the companies described in section (5.2)
to get to know the levels of control and costs associated with implementing any of the tools.
8.4 Future research As was originally the purpose of this thesis, some orders that are picked up on day t=1 have a scheduled
delivery for day t=2. This means that this order is to be picked up and stored at the depot on day t=1,
where on day t=2 a delivery is orchestrated from the hub to the delivery address. Common sense says
63
that if the pickup and delivery addresses are close to each other, direct deliveries should be possible.
To the best of my knowledge this has not yet been researched. So in academic terms, this would be
called a VRPMB with a direct Pickup and Delivery extension.
Another request that became clear at IDLV, was that for certain regions, on-line pickup requests are
expected to arrive later on in the day. This stochastical regional capacity reservation problem is also a
very interesting one to research, but to the best of my knowledge has not yet been researched so far.
64
9 Appendix
9.1 tables and images
9.1.1 Planning process according to the quality manual
1. Order administration / planning: The process is described in the order administration manual.
2. Planning: The system makes a routing for the order depending on e.g. the service level. The
routing can be overruled by the planner.
3. Planning: Client specific information is gathered together on behalf of order administration in
their MS file. Client specific information for planning and drivers is gathered together in the
department manual. Specific instructions are in place for HV/HR traffic.
4. Planning: Minimum information in the trip file: truck, trailer, driver and if transport is done by
a charter the charter relation name.
5. Planning: If transport is done by own drivers (or drivers from charters who drive under
supervision of Verhoeven) drivers get instructions about what and where to load and unload
and the sequence of the work. They also will get client specific instructions as time frames to
load or unload.
6. Planning: Transport can be internal and external monitored with help of the truck following
system and active information by drivers and to get information from drivers or subcontractor
and active information from client or (un)loading address.
9.1.2 Order arrival and planning process, gathered from interviews
Image 2: Legend
1
9.1.3 Screenshot planning lines
9.1.4 Screenshot of the obtained per-day overview
1
9.1.5 Benelux fleet emission numbers for January 2015
Brand and type
Build year
E. Norm
Km: Fuel consumed: CO2 emitted CO2 [kg/km]
Driving
Stationary
driving
stationary
Total
VOLVO FH12 2003 4 5984 1965 33,78 5207 90 5296 0,89
VOLVO FH12 2003 4 6670 2378 24,75 6302 66 6367 0,95
VOLVO FH12 2003 4 740 360 26,88 954 71 1025 1,39
VOLVO FH12 2003 4 1232 230 19,78 610 52 663 0,54
VOLVO FH12 2003 4 7273 2183 30,99 5784 82 5866 0,81
VOLVO FH12 2003 3 7659 2268 40,86 6010 108 6118 0,80
VOLVO FH12 2005 4 5455 1632 43,91 4325 116 4442 0,81
VOLVO FH12 2005 4 8402 2128 36,36 5639 96 5735 0,68
VOLVO FH 440
2006 5 7809 2211 26,40 5858 70 5928 0,76
VOLVO FH 440
2006 5 6685 2218 22,40 5877 59 5936 0,89
VOLVO FH 440
2006 5 6855 2119 39,72 5615 105 5720 0,83
VOLVO FH 440
2006 5 7113 2575 44,80 6824 119 6943 0,98
DAF XF95 2005 3+R 7256 1469 22,37 3893 59 3952 0,54
DAF XF95 2005 3+R 6322 1684 25,65 4464 68 4532 0,72
DAF XF95 2005 3+R 7115 2275 34,65 6030 92 6122 0,86
VOLVO FH 440
2009 5 6934 1864 43,30 4940 115 5055 0,73
VOLVO FH 440
2009 5 9139 2805 47,34 7432 125 7558 0,83
VOLVO FH 480
2008 5-EEV 6454 1935 34,67 5129 92 5221 0,81
VOLVO FH 480
2008 5 6727 2157 64,41 5715 171 5885 0,87
DAF XF 105.480
2008 5 7074 1968 29,97 5216 79 5295 0,75
DAF XF105.460
2006 5 6317 1725 26,27 4572 70 4641 0,73
DAF XF105 2007 5 6508 1413 21,53 3746 57 3803 0,58
VOLVO FH42 2008 5 6784 1330 20,25 3525 54 3578 0,53
VOLVO FM9 2005 3+R 5792 1368 47,86 3625 127 3752 0,65
TOTAL: 154299
44260
808,91 117290
2144 119433
0,77
2
9.1.6 Case study customer locations for dataset A-50 through A-250
Figure 21: Customer locations for dataset A-50
0,
-0,45
-10, LK
-5,5, B-13,6, B
-1,2
-0,543
-2, LK-0,5
-1,2
-3,6-9,6
5,6 -13,522
0,8
11,5
-3,2
-4,4
-1,101, E-0,833, E
13,6
-1,2
-0,8
-1,2
-1,6 -1,67,333
0,53-5,7
-4, B
-2,032, LK-0,8
-0,4
13,6, B5,2, LK, E4,4, A
13,6, B
5,9, D
-10-0,5-1,16
-6,8
-1,604
13,6
5, A7, A0, A
-1,5
-0,4
-13,6
-2
A1,Boxtrailer,TailliftA2,Boxtrailer,TailliftA3,Boxtrailer,TailliftA4,Boxtrailer,Taillift
3
Figure 22: Customer locations for dataset A-100
0,
-0,45
-10, LK
-5,5, B-13,6, B
-1,2
-0,543
-2, LK-0,5
-1,2
-3,6-9,6
5,6 -13,522
0,8
11,5
-3,2
-4,4
-1,101, E-0,833, E
13,6
-1,2
-0,8
-1,2
-1,6 -1,67,333
0,53-5,7
-4, B
-2,032, LK-0,8
-0,4
13,6, B5,2, LK, E4,4, A
13,6, B
5,9, D
-10-0,5-1,16
-6,8
-1,604
13,6
5, A7, A0, A
-1,5
-0,4
-13,6
-2
-0,4
5,6
10
-2,4
-0,8
-1,782
-0,4
-2,043
-1,4331,433
-0,4
-0,787-0,041-0,067
-13,6
-0,4
2,65
-0,8
-11,533
-0,1
-3,75-4,05
-13,6, B
-2,0331,1
0,4, LK
-0,4-0,417
13,6, A
-4,2
-1,2
2 -0,5
-1
-1-0,4
0,5
-3
-2,173
-0,5
-0,4
0,5
0,8
-1-2
0,439-1
-1-1
A1,Boxtrailer,TailliftA2,Boxtrailer,TailliftA3,Boxtrailer,TailliftA4,Boxtrailer,Taillift
4
Figure 23: Customer locations for dataset A-150
0,
-0,45
-10, LK
-5,5, B-13,6, B
-1,2
-0,543
-2, LK-0,5
-1,2
-3,6-9,6
5,6 -13,522
0,8
11,5
-3,2
-4,4
-1,101, E-0,833, E
13,6
-1,2
-0,8
-1,2
-1,6 -1,67,333
0,53-5,7
-4, B
-2,032, LK-0,8
-0,4
13,6, B5,2, LK, E4,4, A
13,6, B
5,9, D
-10-0,5-1,16
-6,8
-1,604
13,6
5, A7, A0, A
-1,5
-0,4
-13,6
-2
-0,4
5,6
10
-2,4
-0,8
-1,782
-0,4
-2,043
-1,4331,433
-0,4
-0,787-0,041-0,067
-13,6
-0,4
2,65
-0,8
-11,533
-0,1
-3,75-4,05
-13,6, B
-2,0331,1
0,4, LK
-0,4-0,417
13,6, A
-4,2
-1,2
2 -0,5
-1
-1-0,4
0,5
-3
-2,173
-0,5
-0,4
0,5
0,8
-1-2
0,439-1
-1-1-1
-3,348, B
-1,5
0,4
-1,2-1,2
-1,6
-0,4
-8,5
-0,4
-0,273
1,2
-2,5
2 0,2
0,681
-11,60,588
0,8-4,2
0,833
3,6-0,4
13,6
-2,4
-1,2
-0,4-0,8, LK
-0,8
-2
0,5
-1,19
-0,47
0,4
5
0,5211,284
3,766
6,3
0,50,5 0,50,400,5 3,5
-1,6, E
13,6
1,6
0,8
A1,Boxtrailer,TailliftA2,Boxtrailer,TailliftA3,Boxtrailer,TailliftA4,Boxtrailer,Taillift
5
Figure 24: Customer locations for dataset A-200
0,
-0,45
-10, LK
-5,5, B-13,6, B
-1,2
-0,543
-2, LK-0,5
-1,2
-3,6-9,6
5,6 -13,522
0,8
11,5
-3,2
-4,4
-1,101, E-0,833, E
13,6
-1,2
-0,8
-1,2
-1,6 -1,67,333
0,53-5,7
-4, B
-2,032, LK-0,8
-0,4
13,6, B5,2, LK, E4,4, A
13,6, B
5,9, D
-10-0,5-1,16
-6,8
-1,604
13,6
5, A7, A0, A
-1,5
-0,4
-13,6
-2
-0,4
5,6
10
-2,4
-0,8
-1,782
-0,4
-2,043
-1,4331,433
-0,4
-0,787-0,041-0,067
-13,6
-0,4
2,65
-0,8
-11,533
-0,1
-3,75-4,05
-13,6, B
-2,0331,1
0,4, LK
-0,4-0,417
13,6, A
-4,2
-1,2
2 -0,5
-1
-1-0,4
0,5
-3
-2,173
-0,5
-0,4
0,5
0,8
-1-2
0,439-1
-1-1-1
-3,348, B
-1,5
0,4
-1,2-1,2
-1,6
-0,4
-8,5
-0,4
-0,273
1,2
-2,5
2 0,2
0,681
-11,60,588
0,8-4,2
0,833
3,6-0,4
13,6
-2,4
-1,2
-0,4-0,8, LK
-0,8
-2
0,5
-1,19
-0,47
0,4
5
0,5211,284
3,766
6,3
0,50,5 0,50,400,5 3,5
-1,6, E
13,6
1,6
0,8
1,5, E
0,4
0,5
-0,75
-0,417
-0,521
-0,521
-0,521
-1,6, E
-0,4, E
2,1
-13,6
-0,4
0,4
0,8-1,6, E
12,8, D 2,40,4
2
-0,817
2
-1,363
1,2
0,4
0,4, B
1,658
0,531
-0,4-0,438
-0,352
-0,4-0,4
-0,788-1,6
-0,8
-0,8
-0,8-0,8
-0,2
0,833
-0,416
-0,596
4
2,15
-0,4, E-2,8, E
-2,8, E
0,6
-1,171, B
A1,Boxtrailer,TailliftA2,Boxtrailer,TailliftA3,Boxtrailer,TailliftA4,Boxtrailer,Taillift
6
Figure 25: Customer locations for dataset A-250
0,
-0,45
-10, LK
-5,5, B-13,6, B
-1,2
-0,543
-2, LK-0,5
-1,2
-3,6-9,6
5,6 -13,522
0,8
11,5
-3,2
-4,4
-1,101, E-0,833, E
13,6
-1,2
-0,8
-1,2
-1,6 -1,67,333
0,53-5,7
-4, B
-2,032, LK-0,8
-0,4
13,6, B5,2, LK, E4,4, A
13,6, B
5,9, D
-10-0,5-1,16
-6,8
-1,604
13,6
5, A7, A0, A
-1,5
-0,4
-13,6
-2
-0,4
5,6
10
-2,4
-0,8
-1,782
-0,4
-2,043
-1,4331,433
-0,4
-0,787-0,041-0,067
-13,6
-0,4
2,65
-0,8
-11,533
-0,1
-3,75-4,05
-13,6, B
-2,0331,1
0,4, LK
-0,4-0,417
13,6, A
-4,2
-1,2
2 -0,5
-1
-1-0,4
0,5
-3
-2,173
-0,5
-0,4
0,5
0,8
-1-2
0,439-1
-1-1-1
-3,348, B
-1,5
0,4
-1,2-1,2
-1,6
-0,4
-8,5
-0,4
-0,273
1,2
-2,5
2 0,2
0,681
-11,60,588
0,8-4,2
0,833
3,6-0,4
13,6
-2,4
-1,2
-0,4-0,8, LK
-0,8
-2
0,5
-1,19
-0,47
0,4
5
0,5211,284
3,766
6,3
0,50,5 0,50,400,5 3,5
-1,6, E
13,6
1,6
0,8
1,5, E
0,4
0,5
-0,75
-0,417
-0,521
-0,521
-0,521
-1,6, E
-0,4, E
2,1
-13,6
-0,4
0,4
0,8-1,6, E
12,8, D 2,40,4
2
-0,817
2
-1,363
1,2
0,4
0,4, B
1,658
0,531
-0,4-0,438
-0,352
-0,4-0,4
-0,788-1,6
-0,8
-0,8
-0,8-0,8
-0,2
0,833
-0,416
-0,596
4
2,15
-0,4, E-2,8, E
-2,8, E
0,6
-1,171, B
-0,448
-1,2
0,5
0,8
1,292
1
0,2
1,2
0,917
1,837
7
-0,4
0,4
1,6
8,8
0,4
0,75
0,924, E
1,5
0,4
1
1,5
3
0,2
5
1
1,93, D
0,4121,441
13,6
1,2111125,5
1,215, E
0,2 0,951,1
9,2
7,61,24,8
1,152,5 0,230,4
A1,Boxtrailer,TailliftA2,Boxtrailer,TailliftA3,Boxtrailer,TailliftA4,Boxtrailer,Taillift
7
9.1.7 Case study customer locations for dataset B-50 through B-300
Figure 26: Customer locations for dataset B-50
0,
-4,5
-2,42
-1,6
13,6, B
-0,4
-9,5, B2,8, B-2,4, B13,6
4,5, A
-0,4
-1,068
2,917
13,6, A-13,6, A-13,6, B
-2,8
-5,5, B
-0,768
-0,542
-0,4-1,6, LK
-3,6
-11,885
-2,4
-0,667
-0,267-13,6
-0,6-0,4
-13,2
-0,4, D
0,5
-7,6
-0,2
-7
-0,4, LK
4,565
0,458
0,5
-0,8
-7,6
0,4-0,4 -13,6-0,808-0,4
-0,317
-12,5
A1,Boxtrailer,TailliftA2,Boxtrailer,TailliftA3,Boxtrailer,TailliftA4,Boxtrailer,Taillift
8
Figure 27: Customer locations for dataset B-100
0,
-4,5
-2,42
-1,6
13,6, B
-0,4
-9,5, B2,8, B-2,4, B13,6
4,5, A
-0,4
-1,068
2,917
13,6, A-13,6, A-13,6, B
-2,8
-5,5, B
-0,768
-0,542
-0,4-1,6, LK
-3,6
-11,885
-2,4
-0,667
-0,267-13,6
-0,6-0,4
-13,2
-0,4, D
0,5
-7,6
-0,2
-7
-0,4, LK
4,565
0,458
0,5
-0,8
-7,6
0,4-0,4 -13,6-0,808-0,4
-0,317
-12,5
0,8
-1
-1,5
-0,4
-13,6
-0,4
13,6, D 13,6
-0,4
-0,4-2-2
3,396
-1,5
0,5
-13,6, D
4,5
-4,4, LK
-2,5
-13,6
-0,4
-0,4
-3,229
-13,6-13,6
0,4, E
-0,5
-13,6
-1,5
-1,5
-1,50,5, B
-7,2 0,2 0,6
-2,5
-2,5
-1,6
-0,8
-1,653
-1,067
0,013-1,623
-3,15
1,4
-10,972,55-0,375
-0,4
-2,25
A1,Boxtrailer,TailliftA2,Boxtrailer,TailliftA3,Boxtrailer,TailliftA4,Boxtrailer,Taillift
9
Figure 28: Customer locations for dataset B-150
0,
-4,5
-2,42
-1,6
13,6, B
-0,4
-9,5, B2,8, B-2,4, B13,6
4,5, A
-0,4
-1,068
2,917
13,6, A-13,6, A-13,6, B
-2,8
-5,5, B
-0,768
-0,542
-0,4-1,6, LK
-3,6
-11,885
-2,4
-0,667
-0,267-13,6
-0,6-0,4
-13,2
-0,4, D
0,5
-7,6
-0,2
-7
-0,4, LK
4,565
0,458
0,5
-0,8
-7,6
0,4-0,4 -13,6-0,808-0,4
-0,317
-12,5
0,8
-1
-1,5
-0,4
-13,6
-0,4
13,6, D 13,6
-0,4
-0,4-2-2
3,396
-1,5
0,5
-13,6, D
4,5
-4,4, LK
-2,5
-13,6
-0,4
-0,4
-3,229
-13,6-13,6
0,4, E
-0,5
-13,6
-1,5
-1,5
-1,50,5, B
-7,2 0,2 0,6
-2,5
-2,5
-1,6
-0,8
-1,653
-1,067
0,013-1,623
-3,15
1,4
-10,972,55-0,375
-0,4
-2,25-1
0,05
-1,2
-0,4, E
-0,4, E-0,4
-1,5, LK
-2,813,6
1,408
0,4, LK
1
-0,4, E
0,8
4
1,333
9,20,2
2
1
11
-2
-2
9, D
0,4
1,5
0,5 0,50,40,5
-1,2, E
13,61,2 2,024
-0,122
-3
-8,5
2,5, D
-0,4
2,24
0,5, D
-0,4, LK
-1,6-3,5, LK
9, D
-0,4, LK
-0,4
-2
0,4, LK
A1,Boxtrailer,TailliftA2,Boxtrailer,TailliftA3,Boxtrailer,TailliftA4,Boxtrailer,Taillift
10
Figure 29: Customer locations for dataset B-200
0,
-4,5
-2,42
-1,6
13,6, B
-0,4
-9,5, B2,8, B-2,4, B13,6
4,5, A
-0,4
-1,068
2,917
13,6, A-13,6, A-13,6, B
-2,8
-5,5, B
-0,768
-0,542
-0,4-1,6, LK
-3,6
-11,885
-2,4
-0,667
-0,267-13,6
-0,6-0,4
-13,2
-0,4, D
0,5
-7,6
-0,2
-7
-0,4, LK
4,565
0,458
0,5
-0,8
-7,6
0,4-0,4 -13,6-0,808-0,4
-0,317
-12,5
0,8
-1
-1,5
-0,4
-13,6
-0,4
13,6, D 13,6
-0,4
-0,4-2-2
3,396
-1,5
0,5
-13,6, D
4,5
-4,4, LK
-2,5
-13,6
-0,4
-0,4
-3,229
-13,6-13,6
0,4, E
-0,5
-13,6
-1,5
-1,5
-1,50,5, B
-7,2 0,2 0,6
-2,5
-2,5
-1,6
-0,8
-1,653
-1,067
0,013-1,623
-3,15
1,4
-10,972,55-0,375
-0,4
-2,25-1
0,05
-1,2
-0,4, E
-0,4, E-0,4
-1,5, LK
-2,813,6
1,408
0,4, LK
1
-0,4, E
0,8
4
1,333
9,20,2
2
1
11
-2
-2
9, D
0,4
1,5
0,5 0,50,40,5
-1,2, E
13,61,2 2,024
-0,122
-3
-8,5
2,5, D
-0,4
2,24
0,5, D
-0,4, LK
-1,6-3,5, LK
9, D
-0,4, LK
-0,4
-2
0,4, LK
0,948
-8,60,8
0,41,117
1,037, D
-1,2
-0,8
13,6
2,5
-0,859
1,61,242
-4,058
1,2 0,25-9,2
-1,2-0,4
-1,6
-0,4
-1,6
-12,7750,4, B -3,049
-0,4
-0,4
0,4
1,2
-2,247, D
0,4, LK0,02
-0,4
-1,925
1
1
1,2
-0,2
-0,2
-0,2-0,2
-0,2
-0,2
-0,2
-0,146
-0,208
-0,146-0,104
-1,25
-1,369, B
A1,Boxtrailer,TailliftA2,Boxtrailer,TailliftA3,Boxtrailer,TailliftA4,Boxtrailer,Taillift
11
Figure 30: Customer locations for dataset B-250
0,
-4,5
-2,42
-1,6
13,6, B
-0,4
-9,5, B2,8, B-2,4, B13,6
4,5, A
-0,4
-1,068
2,917
13,6, A-13,6, A-13,6, B
-2,8
-5,5, B
-0,768
-0,542
-0,4-1,6, LK
-3,6
-11,885
-2,4
-0,667
-0,267-13,6
-0,6-0,4
-13,2
-0,4, D
0,5
-7,6
-0,2
-7
-0,4, LK
4,565
0,458
0,5
-0,8
-7,6
0,4-0,4 -13,6-0,808-0,4
-0,317
-12,5
0,8
-1
-1,5
-0,4
-13,6
-0,4
13,6, D 13,6
-0,4
-0,4-2-2
3,396
-1,5
0,5
-13,6, D
4,5
-4,4, LK
-2,5
-13,6
-0,4
-0,4
-3,229
-13,6-13,6
0,4, E
-0,5
-13,6
-1,5
-1,5
-1,50,5, B
-7,2 0,2 0,6
-2,5
-2,5
-1,6
-0,8
-1,653
-1,067
0,013-1,623
-3,15
1,4
-10,972,55-0,375
-0,4
-2,25-1
0,05
-1,2
-0,4, E
-0,4, E-0,4
-1,5, LK
-2,813,6
1,408
0,4, LK
1
-0,4, E
0,8
4
1,333
9,20,2
2
1
11
-2
-2
9, D
0,4
1,5
0,5 0,50,40,5
-1,2, E
13,61,2 2,024
-0,122
-3
-8,5
2,5, D
-0,4
2,24
0,5, D
-0,4, LK
-1,6-3,5, LK
9, D
-0,4, LK
-0,4
-2
0,4, LK
0,948
-8,60,8
0,41,117
1,037, D
-1,2
-0,8
13,6
2,5
-0,859
1,61,242
-4,058
1,2 0,25-9,2
-1,2-0,4
-1,6
-0,4
-1,6
-12,7750,4, B -3,049
-0,4
-0,4
0,4
1,2
-2,247, D
0,4, LK0,02
-0,4
-1,925
1
1
1,2
-0,2
-0,2
-0,2-0,2
-0,2
-0,2
-0,2
-0,146
-0,208
-0,146-0,104
-1,25
-1,369, B
1,5
0,5
13,263
-7,079, B
0,5
0,2
-1,2
-0,4, LK
0,825, LK
-0,2
1,4
0,6
-0,2
0,4
0,8
1,5
0,4
3,667
2,4
3
0,2
0,8
4,5
0,6
0,386
6,4
-0,448
-0,273
13,6
0,8
2,5, D0,5, E13,6, B
3,4721940,4
0,5
1,1253,32
2,8, B
0,4112
1,20,4
13,7, D
0,12
1,5
A1,Boxtrailer,TailliftA2,Boxtrailer,TailliftA3,Boxtrailer,TailliftA4,Boxtrailer,Taillift
12
Figure 31: Customer locations for dataset B-300
0,
-4,5
-2,42
-1,6
13,6, B
-0,4
-9,5, B2,8, B-2,4, B13,6
4,5, A
-0,4
-1,068
2,917
13,6, A-13,6, A-13,6, B
-2,8
-5,5, B
-0,768
-0,542
-0,4-1,6, LK
-3,6
-11,885
-2,4
-0,667
-0,267-13,6
-0,6-0,4
-13,2
-0,4, D
0,5
-7,6
-0,2
-7
-0,4, LK
4,565
0,458
0,5
-0,8
-7,6
0,4-0,4 -13,6-0,808-0,4
-0,317
-12,5
0,8
-1
-1,5
-0,4
-13,6
-0,4
13,6, D 13,6
-0,4
-0,4-2-2
3,396
-1,5
0,5
-13,6, D
4,5
-4,4, LK
-2,5
-13,6
-0,4
-0,4
-3,229
-13,6-13,6
0,4, E
-0,5
-13,6
-1,5
-1,5
-1,50,5, B
-7,2 0,2 0,6
-2,5
-2,5
-1,6
-0,8
-1,653
-1,067
0,013-1,623
-3,15
1,4
-10,972,55-0,375
-0,4
-2,25-1
0,05
-1,2
-0,4, E
-0,4, E-0,4
-1,5, LK
-2,813,6
1,408
0,4, LK
1
-0,4, E
0,8
4
1,333
9,20,2
2
1
11
-2
-2
9, D
0,4
1,5
0,5 0,50,40,5
-1,2, E
13,61,2 2,024
-0,122
-3
-8,5
2,5, D
-0,4
2,24
0,5, D
-0,4, LK
-1,6-3,5, LK
9, D
-0,4, LK
-0,4
-2
0,4, LK
0,948
-8,60,8
0,41,117
1,037, D
-1,2
-0,8
13,6
2,5
-0,859
1,61,242
-4,058
1,2 0,25-9,2
-1,2-0,4
-1,6
-0,4
-1,6
-12,7750,4, B -3,049
-0,4
-0,4
0,4
1,2
-2,247, D
0,4, LK0,02
-0,4
-1,925
1
1
1,2
-0,2
-0,2
-0,2-0,2
-0,2
-0,2
-0,2
-0,146
-0,208
-0,146-0,104
-1,25
-1,369, B
1,5
0,5
13,263
-7,079, B
0,5
0,2
-1,2
-0,4, LK
0,825, LK
-0,2
1,4
0,6
-0,2
0,4
0,8
1,5
0,4
3,667
2,4
3
0,2
0,8
4,5
0,6
0,386
6,4
-0,448
-0,273
13,6
0,8
2,5, D0,5, E13,6, B
3,4721940,4
0,5
1,1253,32
2,8, B
0,4112
1,20,4
13,7, D
0,12
1,5
3,5, D
0,5, LK1,513,6, D
4,804
4
5,2, LK, D
11 0,2730,6580,83313,64,43,6 1,1150,2731,1130,5
2,9
13,2
0,4
5,109, E
-0,4
3,5, D
2,5
4
11
4,042, B
0,40,5
0,8331,4560,40,4670,375
5,351
0,82,872
1,013
1,5
1,24, D
0,1230,8
1,27, D
1,7250,5690,50,129
A1,Boxtrailer,TailliftA2,Boxtrailer,TailliftA3,Boxtrailer,TailliftA4,Boxtrailer,Taillift
13
9.1.8 Screenshot of the original solver’s console worksheet
14
9.1.9 Screenshot of the revised solver’s console worksheet
15
9.2 References Bortfeldt, A., Wäscher, G., 2013. Constraints in container loading – A state-of-the-art review. European
Journal of Operational Research 229 (2013), pp. 1–20
Canhong Lin, K.L. Choy, G.T.S. Ho, S.H. Chung, H.Y. Lam. 2014. Survey of Green Vehicle Routing Problem:
Past and future trends. Expert Systems with Applications, 41(4) 2014, pp.1118-1138
Cordeau J-F (2006) A branch-and-cut algorithm for the dial-a-ride problem. Operations Research. 54(3),
pp. 573–586.
Croes, G. A. 1958. A Method for Solving Traveling-Salesman Problems. Exploration and Production
Research Division, Shell Development Company, Houston, Texas. pp. 791 – 812
Dantzig, G. B. and Ramser, J. H. “The Truck Dispatching Problem,” Management Science, 6(1) 1959, pp.
80-91
Demir, E., Bektas, T. & Laporte, G. (2013). The bi-objective pollution-routing problem. European Journal
of Operational Research, 232(3), pp. 464 478
Demir, E., Bektas, T. & Laporte, G. (2014a). A review of recent research on green road freight
transportation. European Journal of Operational Research, 237(3), pp. 775-793.
Demir, E., Huang, Y., Scholts, S. & Woensel, T. van (2015). A selected review on the negative externalities
of the freight transportation: modeling and pricing. Transportation Research. Part E: Logistics and
Transportation Review, 77, pp. 95-114.
Demir, E., Woensel, T. van & Kok, A.G. de (2014b). Multidepot distribution planning at logistics service
provider Nabuurs B.V. Interfaces, 44(6), pp. 591-604.
Drexl, M., 2012. Rich Vehicle Routing in Theory and Practices. Logistics Research 5.1(2) (2012), pp. 47 –
63
Edelkamp, S. (2012). Heuristic search: theory and applications Chapter 13. Waltham, MA: Morgan
Kaufman Publishers
Edelkamp, S., Elmasry, A., Katajainen, J. 2011. Two constant-factor-optimal realizations of adaptive
heapsrot. Iliopoulos, C.S., Smyth, W.F. 7056, pp 195-208
European Union. (2014). EU Transport Policy. Retrieved 1-7-2015 from
http://europa.eu/pol/trans/index_en.htm
Fowler, R. J. ,Paterson, M. S., Tanimoto, L. (1981): Optimal Packing and Covering the in the plane are NP
Complete. IPL 12, pp 133 - 137
Fuellerera, G., Doernera, K.F., Hartla, R.F., Iori, M., 2009. Ant colony optimization for the two-
dimensional loading vehicle routing problem. Computers & Operations Research 36 (2009), pp. 655 –
673
Gendreau, M., Iori, M., Laporte, G., Martello, S., 2006. A tabu search algorithm for a routing and
container loading problem. Transportation Science 40, pp. 342–350.
16
Kimmel, P. (2003). Excel 2003 VBA Programmer's Reference. Indianapolis: Wriley Publishing
Laporte, G. 2009. Fifty Years of Vehicle Routing. Transportation Science 43(4), pp. 408 - 416
Laporte, G., Y. Nobert, M. Desrochers. 1985. Optimal routing under capacity and distance restrictions.
Operations Research. 33, pp. 1050–1073
Lean and green. (2014). Wat is lean and green? Retrieved 1-7-2015 from http://lean-green.nl/lean-and-
green/
Lozano, C., Garcia-Martinez, C. 2010. Hybrid metaheuristics with evolutionary algorithms specializing in
intensification and diversification: Overview and progress report. Computers & Operations Research,
37(3), 2010, pp. 481-497
Salimifard, K., Shahbandarzaden, H., Raeesi, R. 2012. Green transportation and the role of operation
research. In 2012 international conference on traffic and transportation engineering, Singapore.
Thompson, P. M., H. M. Psaraftis. 1993. Cyclic transfer algorithms for multi-vehicle routing and
scheduling problems. Operations Research. (41), pp. 935–946.
Wäscher, G., Haußner, H., Schumann, H., 2007. An improved typology of cutting and packing problems.
European Journal of Operational Research, 183(3), 2007, pp. 1109-1130