1. Technician Routing and Scheduling
Christian Uldall Pedersen,
Erik Schmidt Taarnhøj &
Søren V¨orts
Supervisor: Thomas K. Stidsen
Kongens Lyngby 2008
2. Technical University of Denmark
Informatics and Mathematical Modelling
Building 321, DK-2800 Kongens Lyngby, Denmark
Phone +45 45253351, Fax +45 45882673
reception@imm.dtu.dk
www.imm.dtu.dk
3. Preface
This master thesis, entitled Technician Routing and Scheduling, has been pre-
pared by Christian Uldall Pedersen, Erik Schmidt Taarnhøj and Søren V¨orts
during the period from September 2007 to January 2008. The thesis has been
written at the Department of Mathematical Modelling (IMM) at the Technical
University of Denmark (DTU) in cooperation with Microsoft Development Cen-
ter Copenhagen (MDCC). The thesis is the result of five months work, equal to
90 ECTS points in total.
The aim of this thesis is to provide MDCC with a proof of concept software
package being able to automate service technician routing and scheduling within
Dynamics AX.
Through the development of the proof of concept, we have conducted a series of
interviews to achieve knowledge about the requirements of technician schedul-
ing. This knowledge has been used in developing a model based on operations
research theory. The model has been used to implement a solver being able to
solve the stated problem. Finally the solver has been integrated with Dynamics
AX.
Acknowledgements
We would like to thank our thesis advisor, associate professor Thomas. K.
Stidsen, for his support and interest in this project. We would also like to thank
Associate Professor Bo Friis Nielsen for providing us with the initial contact at
4. ii
MDCC.
Within MDCC we would like to thank; Program Manager II Mads Ebdrup
our main advisor, Development Lead II Jesper Seeberg for introducing us to
Dynamics AX and the corresponding development environment, Senior Program
Manager Lead Sverre Thune for his interest and guidence regarding the design
phase. Further we would like to thank; Product Unit Manager Hans Jørgen
Skovgaard, Development Lead II Per Vikkelsøe, Program Manager II David
Probst, Senior SDE Jesper Falkebo, Software Architect Thomas Hejlsberg and
Senior Program Manager Thomas Jensen.
The model presented in this thesis is based on four case interviews, and we would
like thank these companies and their representatives: Service Coordinator Berit
Fogt and Service Manager Jan Christoffersen from Endress + Hauser, Office
Manager of Service Management Naard Geerts from Wifac and Office Manager
of Service Management Bjarne Lund from KONE, Teamleader of the Planning
Team of Cable Tasks in Zealand Doris Fischer, Manager of Planning Team
of Installation Denmark Flemming Lund, Project Manager and co-responsible
of buying planning software John Larsen from TDC. Furthermore we thank
Dispatcher Jeanett K. Olsen from BioKube for providing us with test data.
We would like to give thanks to Anders Dohn Hansen, Morten Lorenzen, Jonathan
Bjørk, Niklas Iversen, Søren Westrup Gleie and Resat Dag.
5. Summary
This thesis introduces and examines the Technician Routing and Scheduling
Problem (TRSP). TRSP is a problem arising within companies dealing with
service technician scheduling. The thesis is written in collaboration with Mi-
crosoft who is interested in providing companies with a piece of software being
able to automate the scheduling of service technicians.
This thesis seek to please the potential clients of such software. This is done by
providing a solver based on metaheuristics. Heuristics have been chosen since it
is shown that commercial solvers are unable to solve TRSP on real life instances
of TRSP. TRSP is also proven to be NP-complete.
The metaheuristic is based on a wide range of concepts taken from the general
literature. These concepts include Tabu search, Genetic algorithms, diversi-
fication methods, Hill climbing, semi-greedy construction heuristics and basic
intensification ideas.
The metaheuristic is implemented in an easy-to-use and extendable solver. The
solver has been integrated with Microsoft Dynamics AX.
The results obtained on both randomly generated data as well as real world data
indicate that the provided solver is capable of creating better solutions to TRSP
than what is possible through human dispatching. The solver is compared to
a realized plan by comparing a set of key performance indicators set by the
company providing the data. The solver is shown to improve all these key
performance indicators.
7. Resum´e
Nærværende afhandling introducerer og analyserer Technician Routing and Schedul-
ing Problem (TRSP). TRSP opst˚ar i virksomheder der lægger service tekniker
planer. Denne afhandling er skrevet i samarbejde med Microsoft. Microsoft var
interesserede i, at levere et stykke software i stand til at automatisere planlægn-
ing af service teknikere.
Afhandlingen har som m˚al at tilfredsstille potentielle kunder med et s˚adan
stykke software. Dette er gjort ved lave en solver baseret p˚a metaheuristikker.
Heuristikker er blevet valgt, fordi det har vist sig at kommercielle solvere er
uegnede til løsning af TRSP p˚a real life instanser af TRSP. Det er ligeledes
blevet vist at TRSP er NP-komplet.
Metaheuristikken er baseret p˚a et bredt udvalg af begreber taget fra den kendte
litteratur. Disse begreber omfatter Tabu søgning, Genetiske algoritmer, diversi-
fikationsmetoder, Hill climbing, semi-gr˚adige konstruktion heuristiker og basale
intensifikation ideer. Metaheuristikken er implementeret i en solver. Denne
solver er b˚ade nem at bruge og nem at udvide. Solveren er blevet integreret
med Microsoft Dynamics AX.
Resultaterne i denne afhandling er opn˚aet ved b˚ade at bruge tilfældigt genereret
data samt data baseret p˚a rigtige problemer. Disse resultater viser at den im-
plementerede solver er i stand til at lægge bedre planer end hvad en menneskelig
planlægger er i stand til. Solveren er sammenlignet med en realiseret plan ved
at sammenligne de to ved hjælp af en række key performance indicators. Disse
key performance indicators er specificeret af virksomheden bag den realiserede
plan. Solveren var i stand til at forbedre samtlige key performance indicators.
13. Chapter 1
Introduction
Dynamics AX is an ERP system being developed by Microsoft Development
Center Copenhagen (MDCC). The system integrates a wide range of modules
for solving business related problems. One of these modules deals with service
management, that is how a company services and maintains the products it
sells.
The service management module introduces the concept of a service agreement.
A service agreement describes how a company is going to service its products.
E.g. how often to perform service checks and how quickly to respond in case
of emergency outage. The company fulfils the agreement by creating service
orders, which are carried out by technicians. Currently it is possible for the
user of a Dynamics AX system to perform the matching between service orders
and technicians manually.
This thesis deals with the problem of how to schedule the technicians in an
efficient manner. This is achieved by using operation research theory. It is shown
that it is infeasible to use standard solvers for mixed integer programming and
constraint programming to solve the problem. A study of metaheuristics and
especially Tabu search is therefore conducted, since these methods seems more
promising. It has not been possible to find work in the literature dealing with
this specific problem. A range of custom algorithms are therefore proposed,
which use ideas and insights from similar standardized problems.
14. 2 Introduction
1.1 Problem definition
The problem at hand can be defined in two ways depending on the recipient.
The two recipients are:
1. MDCC.
2. Clients using the service module in Dynamics AX.
The main problem was initially defined in collaberation with MDCC. Their
initial requirement was:
Develop a proof of concept software package being able to schedule
service orders within Dynamics AX.
In addition to this requirement MDCC also wanted a system which could be
used by as many potential service module clients as possible. This is why the
clients of the service module in Dynamics AX is also an important recipient seen
from the authors point of view.
In order to answer the main problem it has been broken into a series of sub
problems. The following sub problems are to be investigated:
1. Determine the requirements set by potential Dynamics AX users.
2. Develop a model based on these requirements.
3. Determine the algorithms to use in trying to solve the problem.
4. Create a proof of concept system based on the model and the chosen
algorithms.
5. Implement a solver using the proposed system and integrate it with Dy-
namics AX.
6. Analyse the performance of the implemented solver.
1.1.1 Thesis structure
Sub problem 1 is answered by conducting a case study, see chapter 2. The
case study consists of four interviews with companies doing service technician
15. 1.1 Problem definition 3
scheduling. Each interview is documented by a short description, and section
2.5 gives a summary of these descriptions.
Chapter 3 contains a model based on the case study, which is therefore an answer
to sub problem 2. See section 3.1 for a list of assumptions made to simplify the
model.
Chapter 4 is an initial attempt at giving an answer to sub problem 3. The initial
attempt is to try and use standard MIP and CP solvers. It is concluded that this
is not a feasible solution, and it is proven that the problem is NP-completeness
to explain why this is the case. Heuristics are chosen as the solution and chapter
5 and 6 are a study in the concepts of the most common ones.
Sub problem 4 is answered by providing a metaheuristic in chapter 7, 8 and 9.
Chapter 7 and 8 will be a thorough description of the basic algorithm developed
to solve the problem. Chapter 9 extends the model to fit further practical
aspects considered earlier in the thesis.
Chapter 10 considers the implementation of the system desribed in chapters 7,
8 and 9. The chapter focus on extendability, since this was a requerement made
by MDCC, and on the speed of the implementation. A running time analysis
is both done by providing a profiling of the code base, as well as by doing an
analysis of two basic data structures. This should answer sub problem 5.
Chapter 11 will test the different concepts introduced throughout the thesis,
thus providing a way of tuning the solver. Since the problem to be solved is
not a standardized problem, it has not been possible to performance test the
tuned solver against other solvers. The performance of the implemented solver
is instead compared to the performance of a human dispatcher. This is done by
using real life data. This should hopefully answer sub problem 6.
Chapter 12 is a discussion of the practical use of the solver as well as a list of
future improvements to be made. Chapter 13 will conclude on whether the main
problem has been answered sufficently.
17. Chapter 2
Case study
As explained in section 1.1 MDCC requested a study in the needs of potential
users of an automated technician scheduling module. This chapter is a case
study trying to do exactly this. Microsoft facilitated interviews with two of
their current Dynamics AX service module users; Endress+Hauser1
and Wifac2
.
These two companies could be potential clients of an automated system being
able to schedule their service technicians.
The two companies mentioned above are currently having rather small schedul-
ing problems. Interviews with companies having larger service organisations
were also of interest, since their scheduling problems could test the limits of the
final product. TDC3
and KONE4
were contacted and both of them agreed on
providing us with an interview concerning their service technician problem.
1http://www.endress.com/
2http://www.wifac.nl/
3http://www.tdc.dk/
4http://www.kone.com/
18. 6 Case study
2.1 Endress + Hauser
The interview was held on Monday the 8th of October. Endress + Hauser
was represented by Service Coordinator Berit Fogt and Service Manager Jan
Christoffersen.
2.1.1 E+H´s service technician problem
E+H has three fulltime service technicians in Denmark. Two of their service
technicians are working at locations on Zealand and Funen, and the third one
within Jutland. The duration of a service job in E+H can be between zero
and eight hours, while most of them being within three to four hours. Service
technicians are therefore able to handle approximately two jobs a day.
Each of the three service technicians are all educated in performing basic service
of E+H’s products. Some service orders do however require specialized service.
The technicians are specialized in different areas.
E+H distinguishes between service jobs and emergency jobs. Service jobs are
scheduled based on a service agreement. A service agreement states how often
E+H is supposed to perform service checks. A typical service agreement states
that maintenance checks should be performed once or twice a year. E+H have
decided to respond to emergency calls within one week.
2.1.2 Service planning in E+H today
On the first of every month the service coordinator and service manager at
E+H creates a long term plan for each of the service technicians. This plan
is optimized based on the following criteria: location, job duration, preferred
technician and job priority. Each week a service technician is given a batch of
jobs, hence it is up to the service technician to make the route planning himself.
This approach is possible contracts between E+H and their customers states
that service should just be handled during a specific month each year.
E+H deals with a concept called emergency planning. The challenge is to plan
urgent jobs, mostly of high priority. These jobs are often due to failures on
products at customer sites, but could also be due to an incapacitated service
technician. When these situations arise, E+H has to re-route one or more of
their service technicians, perhaps reschedule some of the service checks to be able
19. 2.2 Wifac 7
to handle the emergencies. It is obvious that an emergency at a customer site
has a high priority, and therefore it is more important to rectify this emergency.
E+H is normally informed by phone when emergencies occur. The way they
handle this today, is that the service coordinator looks up the nearby service
technicians, and then calls them to hear if they are able to respond to the
emergency call. When the service coordinator has found a service technician he
calls back to the customer with a time and date for when a service technician
will visit.
If necessary E+H lets their service technicians stay overnight to avoid too much
transportation time.
2.2 Wifac
This section is a summary of an interview done on Friday the 12th of October.
The Dutch company Wifac was interviewed in a phone interview. Wifac is
a leading distributor of conventional and digital technology solutions for the
graphics industry. Wifac operates an extensive cross-media publishing division
alongside its conventional pre-press division. Wifac provides consulting services
and software technologies for workflow automation, pre-press, e-business, and
Web-to-print personalization and customization.
Representing Wifac was Naard Geerts, office manager of Wifac´s service man-
agement module. Naard has 5 years of experience in service business.
2.2.1 Wifac´s service technician problem
Since Wifac is a leading distributor of conventional and digital technology solu-
tions for the graphics industry, it means that Wifac operates in the business-to-
business market. Wifac is located at one site in Holland, just outside Amster-
dam. At the moment Wifac has 30 service technicians in their staff. The service
jobs that Wifac operates with can be categorized into four types of service jobs:
1. Installation
2. Contract maintenance
3. Repairs
20. 8 Case study
4. Support - breakdown and emergency
The total number of service jobs is around 10,000 jobs per year. On a typical
day for a service technician, the service technician typically carries out 1 or 2
service jobs. 10,000 jobs per year allocated to 30 service technicians is a fairly
complex planning problem, and because of this complex problem, Wifac has 3
manual dispatchers in their staff, 1 dispatcher per 10 service technicians. The 30
service technicians are of course not capable of doing every job, mainly because
of the difference in mechanical and technical jobs. In Wifac they have A, B
and C technicians and further more they operate with so called senior service
technicians.
2.2.2 Service planning in Wifac today
The human dispatchers plan 1-6 months ahead. Long duration jobs, meaning
jobs lasting for 1 or 2 weeks, are scheduled up to 6 months ahead, and short
duration jobs, lasting for about one day, are scheduled one month ahead.
Wifac has signed service contracts with most of their customers. In these service
contracts Wifac has agreed to help rectify the emergency at the customer site
within 24 hours, most of them have an even more tight time window, e.g. within
4 or 8 hours. The reason for these tight time windows is to be found in the
market that Wifac is in. Breakdowns in a Wifac product at a customer site
mostly means that the production rate goes to zero, and therefore Wifac has to
rectify within few hours. Customers, who do not have a written service contract
with Wifac, must have their problem rectified within 48 hours at the most.
Because of the market situation, Wifac ”optimizes” their service plan mainly
having just one objective. This objective is to be sure every job is handled in
the correct timeframe, meaning that they want to live up to all of their service
contracts. Even though Wifac is mostly interested in just having a feasible plan,
we were able to get a definition of a good plan. This plan takes the following
objectives into account:
• Customer satisfaction
• Robustness
• Apportion of stress periods
Customer satisfaction is self-evident, but robustness needs an explanation. With
21. 2.3 KONE 9
robustness Wifac means the ability of meeting emergencies without being obliged
to reschedule the entire service plan. 3rd and last, Wifac appreciate a plan that
takes into account which service technicians that were overloaded last time pe-
riod, and therefore should go easy on within the next time period.
2.3 KONE
This interview was made on Tuesday the 23rd of October. The company inter-
viewed was the Danish division of the Finnish company KONE. KONE is one of
the world´s leading elevator and escalator companies. It provides its customers
with industry-leading elevators and with innovative solutions for their main-
tenance and modernization. KONE also provides maintenance of automatic
building doors. In 2006, KONE had annual net sales of EUR 3.6 billion and
approximately 29,000 employees.
Representing the Danish division of KONE was Bjarne Lund, office manager of
KONE´s service management department.
2.3.1 KONE´s service technician problem
In KONE they have 110 service technicians to maintenance checks and emer-
gency situations because of their products in Denmark. On a yearly basis, these
service technicians deal with approximately 8.000 maintenance checks and 2.500
emergency calls. The maintenance checks are usually carried out in the daytime
where most of the service technicians are at work, but the emergency calls can
be every hour of the day.
The reason for KONEs many maintenance checks are to be found in the Danish
legislation on elevators and escalators, where it says that these kind of products
are to be maintained at least every 6 weeks. Because of the product variations,
the time of a service job varies from a few minutes up to several hours. Time
windows on the jobs vary too, there exists a hard constraint on the time windows
for maintenance checks because of the legislation, these time windows are pretty
flexible even though they are legislated. The emergency jobs also have hard
constraint time windows, when the emergency situation e.g. considers people
stuck in an elevator then the nearest service technician goes directly to the
emergency site. If it is an emergency job without people involved, then KONE
has 40 minutes to find and assign a service technician to the emergency job, and
then the emergency has to be carried out within the day.
22. 10 Case study
A part from the service technician planning problem, KONE also has a related
problem, the problem of tool management. Tool management in KONE, is
the many tools the service technicians might need apart from the standard
tools. Because of the enormous product assortment, KONE needs an enormous
assortment of tools to. These tools have to be assigned to the people who need
them, and furthermore KONE will have to avoid double-booking of these tools.
2.3.2 Service planning in KONE today
In KONE they have already begun to plan using software on the computer,
but the thing is that this software is specialized for KONE´s service technician
problem. The following describes KONE´s planning system briefly. As main
rule every service technician in KONE are scheduled to a maintenance check
at 120 customers pr. month, in addition to these maintenance checks each
service technician is ready to handle some emergency calls. Each day a service
technician checks his PDA for the customers to be served that day, at 7.00 he
meets at the site of the first customer and at 15.00 he gets into his car and drives
back home5
. The reason for this working plan is the planning system they use,
because it is a bit simpler to plan this way6
. Because of this system KONE pay
their service technicians for the working hours from 7-15 each day and driving
time to and from work these days.
The service technician scheduling is performed every 3rd month. This is done by
optimizing driving distances and technician skills. KONE makes use of Microsoft
MapPoint when finding distances, and skills required are typed in by the only
human dispatcher in KONE today.
To prevent emergency calls to spoil the planned maintenance jobs, several service
technicians are scheduled to handle only 40 customers pr. month instead of the
120 mentioned earlier. If an emergency call is assigned to a ”normal” service
technician, there are several possibilities to avoid issues within the plan. When
an emergency occurs, it is up to the maintenance service technician of this
customer, to decide whether he can respond to the emergency. If he is able to
respond to the emergency, he can skip the remaining plan of the day, and focus
on the emergency and then if there is time left he can return to the original
plan and proceed. When a service technician is allowed to skip a plan, it is
due to the fact, that the plan of the day is scheduled in advance of the time
windows, meaning that it will not violate the time window constraint. If it is
the case, that this was a job with a very inflexible time window, there is the
possibility of assigning the job to the night shift service technician or let the
5This described tour is of course a standard technician´s standard day.
6We´ll discuss this later on in the thesis.
23. 2.4 TDC 11
service technician work over and thereby avoid to spoil the maintenance jobs
of the day. The reason for these options is that KONE do what they can, to
prevent their service technicians from getting stressed.
What defines a good plan in KONE? The management of KONE has focus on
stress, entailing that a good plan is realistic, when seen from the point of view
of the management and the service technicians. Besides the anti-stress point
of view, a good plan also takes into account that short driven distances are
preferable, technician preferences and skills, and up-front scheduling. To avoid
skills being a hard constraint in KONE´s service technician problem, KONE
has arranged that the most skilled service technicians are held home at the
office to assist un-skilled service technicians in the field by phone. This results
in the skill constraint being a soft constraint in KONE. With a view to the
tool management problem, KONE told us, that they have a system besides the
service technician system. But so far it has not been a problem, and therefore
KONE has ignored this problem so far.
The software they use in KONE today has cut down driving expenses with 40%,
and on top of that they only have 1 human dispatcher instead of several as they
used to.
2.4 TDC
On Wednesday the 31st of October an interview was made with the largest
service technician organisation in Denmark. TDC is the leading provider of
communication solutions in Denmark and a strong player in the Nordic business
market. TDC has developed from being a traditional provider of landline and
mobile service into a provider of modern communications solutions.
TDC was represented by the following three people: Team leader Doris Fischer,
Leader of the planning team of cable tasks in Zealand. Team leader Flemming
Lund, Leader of the planning team of installation tasks in Denmark. Project
manager John Larsen, Project manager of processes and project member of the
”Purchasing of planning software” project group.
2.4.1 TDC´s service technician problem
In TDC they have 1500 service technicians for installation, error recovery and ca-
ble projects such as copper and fiber. Furthermore the service technicians carry
24. 12 Case study
out TDC Installations tasks such as ADSL-tasks, broadband-tasks, telephone-
tasks and cable maintenance. On a weekly basis, the 1500 service technicians
deal with approximately 10.000 long-term planned jobs and 10.000 emergency
(short-term planned) jobs. Most of the jobs are usually carried out in the day-
time where most of the service technicians are at work, but the emergency calls
can be every hour of the night and day. The typical duration of a job is 60-75
min, but this is only reliable in some cases, as Doris said during the interview:
”How long time do you think we spent on the construction site when Fields7
was under construction?”
The emergency jobs can be divided into several categories; these categories
differ in when TDC at the latest has to respond after they are aware of the
emergency. A standard contract says that TDC has to respond within 3-4
days, but nowadays when lots of companies are dependent on their internet
connections etc. TDC has agreed signing contracts with respond times down to
3 hours.
2.4.2 Service planning in TDC today
Because of the size and level of complexity of TDC´s service technician prob-
lem, TDC already began using computer software8
several years ago to help
them solve their service technician problem. Besides the problem description
explained in the preceding paragraph, there exists even more making the prob-
lem description even harder to cope with, which we will describe in further
details onwards.
The following describes TDC´s planning system briefly. As a main rule, each
month a planning team repositions resources in the entire country. This is
done because workload vary in each of the regions over time, sometimes because
of fluctuations and sometimes because of regional bargains which induce more
installation jobs in a certain region.
A typical workday starts at 7.15 AM. The technician starts at home and turns on
his laptop to find out where he is planned to service TDC´s customers that day.
Next the technician starts to drive to the first customer site, if the technician
does not have a direct subsequent job, he is ready to handle emergency jobs
in this specific area9
. These areas works like this, Zealand is divided into 5
areas, then each area is divided into an unknown number of sub-areas where
one of them, often the most centralized, subarea works as a central. Each central
7The largest shopping centre in Scandinavia.
8Specialized to work in TDC, and with a cost price approximately 20 mil. Danish Kr.
9Almost 40% of all jobs carried out one day are emergency jobs
25. 2.5 Summary 13
has at least one associated human dispatcher. Almost all of the 40 employed
human dispatchers in TDC are located at a central location near the city Odense
on Funen. Assuming nothing exceptional has happened, the service technician
arrives in his driveway at 15.15 PM.
So what does the system at the TDC service headquarters do? A customer
needs a service technician for some reason, and then contacts TDC regarding
this. When TDC receives the service request, the system runs through all of
the service technicians to find out who is skilled and located to take care of this
service request, then the system contacts the manual dispatcher in charge of the
matching service technician, and then it is up to the service technician and the
manual dispatcher to find a way to take care of the service request.
As mentioned earlier, TDC has the largest and most complex service technician
organization in Denmark. As an example of the complexity it might be worth
mentioning that each technician has 7-13 skills out of 300 skills in total, and
that each job demands 1 or more of these skills10
.
2.5 Summary
This section is a summary of the four case interviews. The aim of the section is
to provide a specification requirements for the software being developed in this
thesis. Further, this section will provide an overview of optimization problems
from each of the interviewed companies.
Comparing the four interviews there seems to be some key functionality, which
a planning tool must offer in order to be attractive. These are:
• Be able to schedule large jobs which require more than one full workday.
This functionality is not time critical.
• Be able to schedule jobs which require less than one workday and therefore
take driving between jobs into consideration. This functionality is not time
critical.
• Be able to schedule emergency jobs into an existing schedule. This func-
tionality is time critical, i.e. this planning can only take a matter of
minutes.
10TDC has found out they have more than 300 combinations of skills within the jobs they
handle.
26. 14 Case study
E+H Wifac KONE TDC
Planning horizon (in days) 14 30 120 1
Jobs to be planned 40 1000 2625 4000
Percentage of emergency jobs ? ? 25% 40%
No. technicians 3 30 110 1200
No. human dispatchers 1 3 1 40
Using planning software today ÷ ÷
√ √
Table 2.1: This table gives an overview of the size of the problems at hand. It
is based on the four case interviews.
• Allow the dispatcher to overrule the planned schedule provided by the
planning tool.
• All schedules delivered by the planning software must be realistic, i.e.
realizeable within the resources available.
• Allow each client to choose an individual setup within a pre-implemented
setup environment.
The individual setup must at least consider the following planning parameters:
• Consider ”job-to-time” priority as a planning parameter.
• Consider ”technician-to-customer” priority as a planning parameter.
• Consider technician transportation- time or distance as a planning param-
eter.
• Consider the ability to schedule new jobs into an existing schedule.
In table 2.1 the interviews are quantified into data describing the different prob-
lems more specific, e.g. number of jobs, number of technicians, etc. An overview
of how the individual settings would be applied for each of the interviewed com-
panies can be seen in table 2.2
27. 2.5 Summary 15
E+H Wifac KONE TDC
Driving
√
÷
√ √
Job-to-time Priority
√
÷
√ √
Job-to-tech Priority
√ √
÷ ÷
Workload balancing ÷
√ √
÷
Robustness ÷
√ √ √
Table 2.2: An overview of the parameters, which each company would like to
take into account, when creating a plan.
29. Chapter 3
Modeling the problem
There are three parties whose interests should be taken into consideration when
modeling the problem. These are:
• MDCC
• Clients using the service module in Dynamics AX.
• The authors of this thesis.
MDCC is interested in a model that integrates well with the existing Dynamics
AX system. Creating a model that requires large changes to the existing system
is therefore not realistic. This fact restricts the modeling of the problem to only
make use of data which Dynamics AX contains1
. The model is, on the other
hand, required to describe real life problems. The interviews in chapter 2 are
a study in what these real life problems require of such a model. Further, the
project is limited by both ressources and time as described in the foreword. This
limitation bounds the scope of the project, and it has therefore been prioritized,
getting a running proof of concept higher than narrowing the scope to a few
interesting research questions. In this chapter the problem will be modeled
while considering these requirements and limitations.
1Or is planned to be added in the future.
30. 18 Modeling the problem
3.1 Assumptions
Assumptions are almost always necessary when modeling a problem. In this
section the assumptions concerning the TRSP are listed and explained. The
reader should be aware that several of these assumptions will be up for further
discussion later on in the thesis. Section 9 does a relaxation of some of the
assumptions and thereby extends capabilities of the final solver, but for now the
assumptions will be necessary in order to come up with a basic model.
1. It is assumed that the durations of all jobs to be assigned are known.
2. It is assumed that none of the jobs to be scheduled have a duration longer
than the longest workingday of any technician. I.e. if a company is inter-
ested in scheduling n jobs to m technicians, then none of the n durations
are allowed to be larger than the longest workingday of the m technicians.
See section 9.1 for a relaxation of this assumption.
3. It is assumed that jobs can only have a fullday time window. E.g. it is not
possible for a company to state that they wish to visit a customer between
1 pm and 2 pm. This assumption entails that either a service technician
is able to handle a job within a working period or he is not able to handle
it at all. See section 12.2.5 for a more comprehensive discussion.
4. It is assumed that transportation time does not vary due to traffic. This
is assumed since transportation time between job locations are calculated
offline using Microsoft Mappoint. A consequence af this assumption is
that the locations are situated in an Euclidean space.
5. It is assumed that tools shared by the service technicians are not part of
the problem, i.e. it is assumed that the model can be informed in advance
whether a service technician is able to handle a job or not. See section
12.2.4 for a more comprehensive discussion.
6. It is assumed that a service technician starts and ends at the same address.
These addresses are not required to be equal among the technicians. See
section 12.2.3 for a more comprehensive discussion.
3.2 Model
The problem can be thought of as an assignment problem, where n jobs need
to be assigned to m technicians over a horizon of h days. Assigning a job j to
31. 3.2 Model 19
a technician i at a specific time t is said to be an assignment. A solution x is a
set of n assignments.
The assignments are subject to a number of constraints. The constraints are
divided into two categories which are fundamentally different. These categories
are:
• Hard constraints are constraints with a requirement that must be sat-
isfied. E.g a job cannot be assigned to a technician during his vacation.
An assignment that does not violate any hard constraints is set to be legal
and a solution where each of the n jobs are assigned exactly once, is said
to be feasible.
• Soft constraints do not set a specific requirement. Soft constraints are
instead used to assign value to a solution, and thereby give the possibility
of prioritizing between them. In an abstract sense, a soft constraint ex-
presses an intension. E.g. minimize the total time used by the technicians
on driving between jobs. There is no limitation on the magnitude of time
used on driving, only that it should be as little as possible.
In short terms; hard constraints are the means for creating feasible solutions,
while soft constraints are used to rank these solutions.
3.2.1 Hard constraints
This section describes the hard constraints used in the model. The constraints
are introduced as abstract as possible, so that they cover a wide variety of real
life scenarios. The number of constraints needed in the model are kept to a
minimum using this approach.
The constraints are:
• n ASSIGNMENTS The n ASSIGNMENTS constraint dictates that
each of the n jobs must be scheduled to a technician exactly once.
• ON LOCATION A job can only be handled at its location, and the
technician has to physically be on that location. The ON LOCATION
constraint dictates that each technician has to start and end at his home-
base each day. During the day he also has to travel between the locations
of the scheduled jobs.
32. 20 Modeling the problem
• ALLOWED The ALLOWED constraint dictates dis-allowed assignments
for one of the following reasons:
– Jobs can only be scheduled to the technician on the days he is avail-
able according to his schedule.
– Each job has a time window in which it must be handled. The job
can only be scheduled inside this time window.
– Each technician has a skill level and each job requires a skill level. A
job can only be assigned to a technician with the required skill level.
• WORKLOAD The technician schedule dictates the duration of each
workday. The length of this period is denoted S for size. In this period
the technician needs to do both the actual work and do the traveling
between the job locations. The time a technician spends on actual work
is denoted handling time (HT), and the time he uses on driving between
the jobs are denoted traveling time (TT). The WORKLOAD constraint
dictates, for each technician on each day, that S ≥ TT + HT.
Earlier in this chapter it was mentioned that an assignment was legal, if all
the above mentioned hard constraints were fullfilled. The n ASSIGNMENTS
constraint is however a constraint concerning whole solutions and not single
assignments, so this constraint is omitted in this context.
3.2.2 Soft constraints
A main conclusion in the interviews from chapter 2 was that, whereas the hard
constraints seemed fairly similar among all the interviewed companies, the soft
constraints seemed more individual. This is a huge challenge, since the aim of
the project is to develop a system useful for many different companies. The
problem is that such a system requires many different types of soft constraints.
More on how this is dealt with in the implementation in chapter 10.
The four most requested soft constraints are described in the following four
sections.
3.2.2.1 Minimize driving
When solving a routing problem, a fairly intuitive soft constraint is to mini-
mize travel. This soft constraint was also requested by all of the interviewed
33. 3.2 Model 21
companies. The soft constraint is to minimize the total amount of hours the
technicians spent in their cars driving between job locations.
Note that the soft constraint is not minimizing the length but the time spent.
This is done for two reasons. First, the transportation time between all job
locations are calculated anyways, since they are needed in the ON LOCATION
constraint, and second, man hours are usually more expensive than fuel. One
could argue that the two minimization criteria really are the same, however,
if someone specifically requests travel length as the minimization criteria, then
such a constraint would be easy to implement.
3.2.2.2 Maximize technician to customer priority
A competitive parameter in many industries with service technicians is the tech-
nician to costumer relationship. Many costumers prefer to have a technician
which they know. This could among other things have the following benefits:
• The technician already knows the location of the equipment which needs
service.
• The technician needs to know an entry code, where it is the costumers
wish, that as few technicians as possible know this code.
The idea is that each assignment of a job j to a technician i gets a number of
points (pij) between zero and five. As mentioned earlier, a solution s contains
a set of assignments. The objective is then to maximize the total number of
priority points given by these assignments.
3.2.2.3 Minimize job to time penalty
Many service technician organizations handle jobs on contracts due to legis-
lations. E.g. it is required by law that elevators are checked once every six
weeks.
Service technician companies in these situations, often offer a contract to the
costumer, where the service organization promises to satisfy the costumers legal
requirement. It is however not stated when these visits should take place or how
many visits there should be. The service organization is naturally interested in
performing as few technician visits as possible, which is done by maximizing the
period between each visit.
34. 22 Modeling the problem
The idea of the minimum job to time penalty is that each job is given a preferred
time, given as a full day. If the job is handled on that day, it is given a penalty
of zero. However, for each day the job is scheduled away from that day (in both
directions), a penalty of one is added. The penalty, when job j is handled at
time t, is denoted cost cjt. The goal is to minimize the sum of costs for all jobs.
To model the situation described above, this soft constraint needs to be sup-
plemented with the ALLOWED constraint. In this way there will be an added
cost for each day away from the sixth week, and all days after the sixth week
would be dis-allowed by the ALLOWED constraint.
This soft constraint can also model emergency jobs. That is jobs which need to
be handled as fast as possible. This is done by setting the preferred time of the
job to the present date.
An example of a company which would need a penalty in both directions is
a company refilling vending machines. If the technician visits early then the
vending machine would still be full and if the visit is postponed the vending
machine might have been emptied.
3.2.2.4 Maximize robustness
Most service organizations handle two different kinds of jobs. These are sched-
uled jobs and emergency jobs. The difference is how long in advance the orga-
nization knows the existence of the jobs. Scheduled jobs are known such that
they can scheduled and a sensible plan can be made. The emergency jobs can
appear at any time and the costumer expects the service organization to solve
the problem either the same day or within very few days.
Wifac solved this problem by keeping a set of backup technicians waiting for
emergency calls. This thesis suggests a different solution to the problem, namely
a measure called robustness.
A solution is said to be robust, if it is easy to schedule emergency jobs as they
arrive. Many service organizations wish to inform their costumers when their
service orders will be handled. A consequence of this is, that already scheduled
jobs can be difficult to move. Robustness tries to keep empty space in each day
in the schedule for emergency calls, such that emergency jobs can be assigned
to the existing plan.
Example 3.1 A service organization needs to handle two jobs with one techni-
cian in two days. Each job takes approximately half a day. The technician can
35. 3.2 Model 23
handle the jobs in two ways:
• Handle both jobs on the first day and thereby save transportation time,
since he can stay at home on the second day.
• Handle a single job on each of the two days.
If he chooses to handle both jobs on the first day, then the plan is not as robust
as in the second case. The reason for this is, that if an emergency appears on the
first day, then the organization can not promise the costumer that a technician
will visit him the same day. On the other hand if they had scheduled one job
each day, then the costumer could get a visit from the service technician the
same day, no matter which day the emergency occurred.
Quantifying robustness
The task of quantifying the abstract measure of robustness is not trivial. This
section gives an example of how this could be done.
What robustness is trying to maximize, is the probability that a new job can be
scheduled into the existing plan without changing it. It is not possible to have a
priori knowledge about the upcoming sequence of jobs, and so the duration, skill
level and location of these jobs are unknown. Instead the idea of a standard job
is introduced. If possible a standard job should represent the expected values of
these three properties. The expected duration of a job is given up front by the
service organisation2
. The expected transportation time for new jobs are also to
be given by the service organisation. Further, it is assumed that all technicians
can handle the standard job.
Instead of having the service organisation estimate these values, one could make
use of learning to estimate them. This was however not the scope of this project.
The objective is to maximize both the number of standard jobs which can be
scheduled in a given solution as well as the spread of these jobs. The objective
value is calculated by introducing the concept of shifts. The idea is to divide the
planning horizon into shifts and keep track on how many standard jobs there can
be scheduled in each shift. A non linear degressive growing function is then used
to make the first standard job in each shift given more robustness points than
the second and so on. The model makes use of the square root function as the
2This value was found to be easily estimated by the interviewed companies.
36. 24 Modeling the problem
non-linear function. The idea is illustrated in figure 3.1, and an equation being
able to calculate robustness is given in section 4.1 along with the MIP-model.
Figure 3.1: Illustrating the calculation of the robustness of a solution. The
robustness in this example is 6.15.
Robustness can also be used without the square root. Then the number of
standard jobs which can be scheduled into a solution is maximized without
considering whether these standard jobs are scheduled in the same shift or not.
3.2.2.5 Prioritisation of soft constraints
So far four different soft constraints have been introduced. In this section it
will be described how to set up the objective function (OBJ) from the four soft
constraints. The idea is to use a linear combination of the four soft constraints
as objective function. The purpose of the coeffcients in the linear combination is
twofold. First, the magnitude of the soft constraints needs to be approximately
the same. This is done by a set of β coefficients. Second, the user should be
able to prioritize the soft constraints. This is done by a set of α coefficients.
Soft constrains can both be minimized and maximized. The soft constraints
which are minimizing are multiplied by minus one, so the final objective function
is to be maximized.
OBJ = −αDRI · βDRI · DRI + αT T C · βT T C · TTC
−αJT T · βJT T · JTT + αROB · βROB · ROB (3.1)
The β coefficients are necessary, since there is no guarantee that the magnitude
of the soft constraints are the same. I.e transportation time is measured in
37. 3.2 Model 25
minutes, so it is quite realistic that a distance between two job locations is 30-
60 minutes. On the other hand the technician to costumer priority is given as a
number between one and five. So if no normalization is made, the transportation
time will have larger impact since the figures are larger. Normalization is done
in the following way:
• The transportation times between the job locations are normalized so the
average is 1.
• The technician to costumer priority is normalized so the average is 1.
• The job to time penalty is normalized so the average is 1.
• The robustness is already normalized.
The α coefficients are used to allow the user of the system to make a prioriti-
zation between the different soft constraints. Each α is chosen in the interval
between zero and one, where the sum of them must be one. In this way the
client must understand, that the α’s are used to prioritize. It is not possible for
the client to claim everything is very important and therefore expect an even
better solution. The α’s can further allow the client to interact with the system.
If the user for some reason is dissatisfied with the obtained solution he can, by
changing the α coefficients, get a new solution which hopefully is satisfying.
This interaction is believed to be necessary, since the interviewed companies
seemed far better at prioritizing the different objectives when given an actual
solution. In this way they were able to tell what was wrong with the presented
solution, and they could change the prioritization. Further, the α values can
exclude a soft constraint by setting the value to zero.
38. 26 Modeling the problem
Symbol Explanations
n The number of jobs
m The number of technicians
h The planning horizon
i The index used for technicians
j The index used for jobs
t The index used for time
p The number of technician plans
k The number of jobs in a technician plan
dj The duration of job j
x A solution, which is a set of n assignments
s The length of a work day
TT Total travelling time in a technician plan
HT Total handling time in a technician plan
rij The time it takes to drive from job location i to j
OBJ The final objective function
DRI The soft constraint minimizing driving
TTC The soft constraint maximizing technician to time priority
JTT The soft constraint minimizing job to time penalty
ROB The soft constraint maximizing robustness
α Coefficient to normalize soft constraint
β Coefficient to prioritize soft constraint
Table 3.1: The introduced notation used when modeling the problem.
39. Chapter 4
Complexity analysis of TRSP
The service technician problem was modeled in the previous chapter. The aim
of this chapter is to get a better understanding of the model in both a practical
as well as a theoretical sense. The practical analysis is done by modeling the
problem as a Mixed Integer Programming (MIP) model and as a Constraint
Programming (CP) model. Commercial solvers are then used in trying to solve
problems described by the two programming models. The theoretical analysis
is done by proving the model to be NP complete.
In both the presented MIP as well as the CP model, a number of assumptions
are made. These assumptions are made to ease the modeling and readability of
the models. The two models are therefore not necessarily the exact same as the
TRSP. However, it should be clear to the reader that the assumptions are no
disadvantage when solving the models.
4.1 Mixed integer programming
Mathematical programming is the study of a system on the form of maximize
f(x), such that x ∈ X, where x is a vector of variables denoted decision variables,
f is a function and X is the set of feasible x. Mathematical programming comes
40. 28 Complexity analysis of TRSP
in several forms depending on the constraints, objective function and decision
variables.
TRSP makes use of binary variables to decide whether a technician handles a
job or not. This problem has a yes or no answer which results in continuous
variables being impossible to use. TRSP is therefore modeled as a Mixed Integer
Programming (MIP) model.
This section models the problem as a MIP problem and investigates the efficiency
of the ILOG CPLEX MIP solver1
.
4.1.1 Decision variables
Three sets of decision variables are introduced:
• xijt is 1 if technician i is to handle job j at time t. The index t can to be
thought of as a day. Otherwise xijt is 0. xijt is therefore a binary variable.
• yijkt is 1 if technician i traverses the arc between job location j and job
location k at time t. Otherwise yijkt is 0. yijkt is a binary variable.
• zijkt is a positive variable. It is a flow variable used to handle the ON
LOCATION constraint.
The index j is used to index the jobs and therefore also for job locations. How-
ever, one extra job location is added, which is the homebase. This is necessary
to ensure that the ON LOCATION constraint is satisfied. Note that only one
homebase is added, i.e. the model assumes that all technicians have the same
homebase.
4.1.2 Objectives
This section introduces the soft constraints. These should all be familiar since
they were introduced in section 3.2.2.
The minimum driving soft constraint is modeled. Recall that rjk is the trans-
1http://www.ilog.com/products/cplex/
41. 4.1 Mixed integer programming 29
portation time between job location j and job location k.
Min
i j k t
rjk · yijkt (4.1)
The technician to customer soft constraint is modeled. Recall that pij is the
priority points obtained by letting technician i handle job j.
Max
i j t
pij · xijt (4.2)
The job to time soft constraint is modeled. Recall that cjt is the penalty for
handling job j at time t.
Min
i j t
cjt · xijt (4.3)
The robustness soft constraint is modeled.
Max
t i
sit − j dj · xijt + j k rjk · yijkt
dstandard
(4.4)
MIP models only consider a single objective. Like in section 3.2.2 the idea is to
use a linear combination of the soft constraints.
4.1.3 Hard constraints
Hard constraints are part of the MIP model to indicate the feasibility of a
solution, i.e. it indicates which x ∈ X. These constraints are similar to those in
the problem model section 3.2.1.
The n ASSIGNMENTS constraint is modeled:
i t
xijt = 1 ∀ j {hb} (4.5)
42. 30 Complexity analysis of TRSP
The ALLOWED contraint is modeled. Recall that aijt is a binary element of
A, which is 1 if technician i is allowed to handle job j at time t and otherwise
0.
xijt ≤ aijt ∀ i, j, t (4.6)
The WORKLOAD constraint is modeled. Recall that dj is the duration of job
j and that sit is the size of technician i’s workday t.
j
xijt · dj +
j k
rjk · yijkt ≤ sit ∀ i, t (4.7)
The ON LOCATION constraint is modeled using four MIP constraints. The
first of the four constraints says, that each job location is being driven towards
once:
j
yijkt = xikt ∀ i, k, t (4.8)
The second constraint says that each job location is being driven away from
once:
k
yijkt = xijt ∀ i, j, t (4.9)
The previous two constraints are not enough to ensure the ON LOCATION
constraint. The reason for this is, that two unconnected tours, denoted subtours,
might exist. Subtours are avoided by letting the homebase distribute flow. The
constraint ensures that each job location, where a technician needs to handle
a job, must receive flow. This is only possible when being connected to the
homebase.
k
zikjt −
k
zijkt = xijt ∀ i, t, j {hb} (4.10)
The last constraint ensures that flow can only pass from job location to job
43. 4.1 Mixed integer programming 31
# techs # days # jobs # binary variables # constraints Time
1 2 4 40 70 0.09 sec.
2 2 4 80 136 0.3 sec.
2 2 5 120 189 1.3 sec.
2 2 6 168 250 17 sec.
3 1 8 216 299 1 min. 20 sec.
2 3 6 252 372 3 min. 40 sec.
2 3 7 336 475 30 min.
2 4 7 448 631 3 hours 50 min.
3 3 7 504 709 11 hours
Any problem larger Never finish
Table 4.1: The computational effort is shown when solving the simplified TRSP
with ILOGs CPLEX solver. The duration of jobs are set to 1 hour, and all
driving distances are set to 30 minutes. Each service technician is capable of
working 8 hours each day. The result is required to be within 10% of optimum.
location, only if a technician is driving between the two job locations.
zijkt ≤ n · yijkt ∀ i, j, k, t (4.11)
4.1.4 Analysis of the MIP model and performance of ILOGs
CPLEX solver
By investigating the model it is concluded that the number of binary variables,
which is the parameter with the most significant impact on the runtime, is
O(n2
·m·h). Further, the number of constraints has a magnitude of O(n2
·m·h).
The model has been implemented in GAMS2
to test the practical time complex-
ity of it. The GAMS model is solved using the ILOG CPLEX MIP solver.
The result of the investigation is presented in table 4.1. This investigation is
only performed on the linear soft constraints, i.e. αROB = 0. This is done since
the CPLEX-solver is expected to perform better when the model is linear.
It can be concluded from table 4.1, that for small instances, the CPLEX solver is
efficient. However, as the problem size increases the computation effort needed
suffers from an exponential blowup.
2The GAMS code is included in appendix D.1.
44. 32 Complexity analysis of TRSP
Figure 4.1: The computational effort used by the ILOG CPLEX solver as a
function of the problem size.
The size of problems solvable by using the MIP model is compared to the size
of real life problems. This is done to conclude that the MIP model does not
have any practical application for instances of TRSP. The case study can be
used when doing this. The interviewed company with the smallest problem is
Endress + Hauser. They have three technicians, they plan for a horizon of 20
days and within this period they handle 90 jobs.
Applying these data to the MIP model gives approximately 5 · 105
binary vari-
ables, which is 1000 times more binary variables than what the CPLEX solver
can handle. Therefore it can be concluded, that using a MIP model is not a
feasible approach in practice.
4.2 Constraint programming
This section models the problem as a Constraint programming (CP) model
and analyzes the efficiency of the Microsoft Optima CP solver. Constraint
Programming is an optimization framework. CP has the advantage over MIP
that logical operators such as implication can be used. Further, CP has a number
of special constraints such as alldifferent, which can be used to require a number
of variables to be different. The presented CP model is strongly inspired by the
model in [3]. In this section it is assumed that the horizon of the optimization
problem is only one day.
45. 4.2 Constraint programming 33
4.2.1 Decision variables and domains
• Nextj = k says that the technician who handles job j will proceed to job
k.
• Endj = a says that after the technician is done handling job j he has used
no more than a minutes.
• τj = i says that technician i will handle job j.
• Cost1j is used in the objective function. Cost1j is set to the cost of the
chosen edge away from job location j.
• Cost2j is used in the objective function. Cost2j is set to priority value of
the technician handling job j. I.e Cost2j = pij if technician i handles job
j.
The index j might need further explanation: j is the index over all jobs. The
set of jobs is extended with 2 · m jobs. These are denoted fake jobs. Each
technician has two fake jobs, one job in the morning and one in the evening.
Both these fake jobs are located at the technicians homebase. The set of jobs
in which the j index is used therefore looks like the following:
fake jobs real jobs fake jobs
j ∈ {1, . ., m , m + 1, . .m + n , m + n + 1, . ., 2m + n}
The first m jobs in j are fake jobs which are used as the technicians start bases.
Each technician has an individual morning homebase. The jobs between number
m + 1 and m + n are the n real jobs. The last m jobs in j are fake jobs. These
jobs are used as end bases for the technicians. Each technician has an individual
afternoon homebase.
• The domain of Endj is {1, s}, where s is the length of each technicians
work day.
• The domain of Nextj is {1,..,2m + n}
• The domain of Cost1j is {1,..,rmax}, where rmax is the largest possible
transportation time.
• The domain of Cost2j is {1,..,pmax}, where pmax is the largest technician
to job priority.
46. 34 Complexity analysis of TRSP
4.2.2 Hard constraints
The ALLOWED constraint is modeled. Recall that aij is a binary element in
the A matrix, which is 1 if technician i is allowed to handle job j and otherwise
0.
aij = 0 ⇒ τj = i ∀ i, j (4.12)
The ON LOCATION constraint is modeled with four Constraint programming
constraints. The first constraint states that each technician has to handle the
morning fake job at his homebase:
τj = j for j ∈ {1, .., m} (4.13)
The second constraint used to model the ON LOCATION constraint states that
each technician needs to handle the fake job at his homebase at the end of the
day:
τj = j − (m + n) for j ∈ {m + n + 1, .., 2m + n} (4.14)
A constraint, which states that for each technician the successor of the afternoon
fake jobs is the morning fake job, is introduced. This constraint is mainly
introduced to allow the use of constraint 4.16.
Nextj = j − (m + n) for j ∈ {m + n + 1, .., 2m + n} (4.15)
The last constraint used to model the ON LOCATION constraint, states that
all jobs must have a different successor job:
alldifferent(Next1, .., Next2m+n) (4.16)
The ON LOCATION constraint is still not necessarily satisfied since there might
exist subtours. These are eliminated by constraint 4.20, which is going to be
presented as one of the WORKLOAD constraints. Since the ON LOCATION
constraint says that each job location must be visited and assign technicians to
handle their fake jobs in the morning. The n ASSIGNMENTS constraint can
47. 4.2 Constraint programming 35
be modeled with a single constraint saying, that if a technician drives from job
location j to job location k then it must be the same technician who handles
both job j and job k.
Nextj = k ⇒ τk = τj ∀ j, k (4.17)
The WORKLOAD constraint is modeled using three constraint programming
constraints. The first one states that after handling his morning fake job each
technician has spent 0 time.
Endj = 0 for j ∈ {1, .., m} (4.18)
The second constraint used to model the WORKLOAD constraint states that,
when each technician handles his afternoon fake job, he has spent no more than
s time, which is the length of his work day. It is assumed that each technician
works the same amount of hours.
Endj ≤ s for j ∈ {m + n + 1, .., 2m + n} (4.19)
The final constraint necessary to model WORKLOAD states, that if a technician
drives from job location j to job location k, and therefore handles both job j
and job k, then he cannot leave job k before he has finished job j, driven from
job location j to job location k and handled job k.
Nextj = k ⇒ Endk ≥ Endj + rjk + dk for j ∈ {1, .., m + n} (4.20)
Note that 4.20 does not include fake jobs in the afternoon. If it did, it would
require a cycle where the time spent in each node is larger than the time spent of
predecessor which is not possible. Constraint 4.20 is therefore also eliminating
subtours.
4.2.3 Objectives
Two extra constraints are introduced. These constraints describe two objectives.
The first objective is to minimize driving. The constraint (4.21) says that Cost1j
48. 36 Complexity analysis of TRSP
is set to the value of the chosen edge away from job j.
Nextj = k ⇒ Cost1j = rjk ∀ j, k (4.21)
The second objective is to maximize job to technician priority. The constraint
(4.22) states that Cost2j is equal to the technician to job priority of the tech-
nician who handles job j.
τj = i ⇒ Cost2j = pij ∀ j, k (4.22)
As objective function a linear combination of minimum driving and maximum
priority is used.
Obj =
j
{−Cost1j + Cost2j} (4.23)
4.2.4 Analysis of the CP model and Optima performance
By analyzing the model we conclude that the number of variables are k1 · n and
the number of constraints are k2 · n2
, where k1 and k2 are constants. The size
of k1 and k2 depends on how many jobs each technician handles each day. The
constants are large if the technicians only handles a few (i.e. 1) job per day,
and small if the technicians handle many (i.e. 5) jobs per day. The sizes of the
constants are: k1 ∈ {7, .., 15} and k2 ∈ {14, .., 30}. One could argue that some
of the constraints are not really constraints but narrowing of the domains. The
above analysis has included all constraints.
The variable domains are also of interest when solving CP models. There are five
types of variables, Nextj, Endj, τj, Cost1j and Cost2j. The domains for Nextj
and τj are both {1, .., 2 · m + n}, i.e. the size of their domain scale linear with
the problem size. The third variable Endj has time as its domain. Therefore
the size of the domain depends on the choice of discretization of time. Since
the model needs to describe driving time with some accuracy we have chosen to
discretize time into 15 minutes time slots. This means that if the technicians
work 8 hours each day, the domain of the Endj variables is {1, .., 32}. Cost1j
has domain {1, ..dmax}, where dmax is the time it will take to travel the longest
distance. Since time has been discretized into quarters of an hour, it can be
49. 4.2 Constraint programming 37
m n variables Time
2 2 30 0.03 sec.
3 2 35 0.32sec.
5 2 45 5.0 sec.
7 2 55 2 min 15 sec.
6 3 60 5 min. 45 sec.
6 4 70 33 min.
Any problem larger Never finish
Table 4.2: Computational effort used by the Microsoft Optima CP-solver on
different problem instances. The duration of each job is set to one hour, while
30 minutes are used for driving between them. Each service technician is capable
of working eight hours.
assumed that dmax is no larger than 16. Cost2j has the domain {1, ..pmax},
where pmax is the largest priority. Our choice is approximately 5.
The model has been implemented3
and the Microsoft Optima CP-solver is used
to solve the problem. The results are shown in table 4.2. Just as for MIP it
is concluded that for small instances the CP solver is efficient. However, the
computational effort needed to sovle the problem, suffers from an exponential
blowup. It never finished for problem with more than 70 variables.
This insight is compared with the number of variables needed to solve real
life problems. Endress + Hauser, which is the interviewed company with the
smallest problem, has three technician. They plan for a horizon of 20 days
and in this period they handle 90 jobs. Since the CP model assumed that the
horizon was one day Endress + Hauser’s problem is converted so they have
60 technicians working one day. This is based on the assumption that three
technician working 20 days is equivalent with 60 technicians working one day.
With these data the Endress + Hauser problem gets 1050 variables, which is
more that ten times the number of variables Optima can handle. Therefore it
is concluded that CP is not a feasible approach when solving TRSP.
3The implemented model is included in appendix E.
50. 38 Complexity analysis of TRSP
4.3 NP completeness
In the previous two sections it was concluded that the standard solvers for both
MIP and CP were efficient only for very small instances of TRSP. As soon as the
problem size, i.e. the number of jobs, got any way near a number which could
be used to solve real life problems, the solvers could not solve the problem since
both of the running times suffered from an exponential blow up. In this section
the theoretical explanation for the exponential running time of the standard
solvers will be given by proving that TRSP is NP-complete.
In this section it is assumed that P = NP, and there will be no discussion of
the consequence in the case it is not true.
The theory of intractability deals with decision problems instead of optimization
problems. Decision problems are problems which seek an answer of either yes
or no, whereas optimization problems seek an objective value. I.e. the problem
would ask: What is the price of the cheapest Hamiltonian cycle? Whereas the
associated decision problem would ask: Does there exist a Hamiltonian cycle
of cost Υ? However, note that if one can solve the optimization problem and
therefore knows the optimal objective value, it is trivial to solve the correspond-
ing decision problem. Further, if one is able to answer the decision problem
and the objective value can be bounded upwards by something which is only
exponential in the input size. Then the optimization problem can be solved
using bisection, and therefore only solving the decision problem a polynomial
number of times. Since the stated model of TRSP from chapter 3 deals with
four soft constraints which each can have their value bounded numerical by a
polynomial in the number of jobs4
, the objective function itself can be bounded
by a polynomial. This leads to the conclusion, that the decision problem and
the optimization problem for TRSP, within a polynomial, is equally hard.
The NP-complete problems are a class of problems in which each problem can
be transformed to every other problem in that class. However, when proving
that a problem is NP-complete, it is sufficient to show that one NP-complete
problem can be transformed by a polynomial transformation into the problem.
A polynomial transformation is a transformation which only has a polynomial
time complexity and the size of the output problem is no more than polynomial
larger than the input problem. Next, the two requirements for NP-completeness
will be shown for TRSP.
4Assuming that the coefficients from each of the soft constraints are independent of the
number of jobs.
51. 4.3 NP completeness 39
4.3.1 TRSP is in NP
The class of NP-complete problems is the class in which problems can be solved
in polynomial time using non-deterministic computing. The idea of this non-
deterministic computing is that one possess an ”oracle” which always makes
optimal guesses, hence the name ”oracle”.
The algorithms for non-deterministic computing are divided into two steps. First
the oracle makes a guess and then the guess is verified. A problem belongs to NP
if and only if, there exists a non-deterministic algorithm which has a polynomial
time complexity. A popular way of explaining what is required of a problem to
belong to the class of NP is, that if a given solution can be verified in polynomial
time, then the problem belongs to NP. Note that the two previous definitions
are equivalent.
To argue that TRSP is in NP, the MIP model is used to verification. However,
the z variables from the MIP model5
need to be constraint to integers since the
NP-theory is defined upon finity language. Note from the model, that this can
be done trivially.
Since the model has only O(n · m2
· h) constraints, which is polynomial, and
each of these constraints can be verified in polynomial time, a solution can be
checked whether it is feasible in polynomial time. Further, since the objective
function, which is a sum function, has a length of only polynomial many terms,
the objective value can be calculated in polynomial time. Therefore the decision
whether there exists a feasible solution with objective value at least Υ, can be
answered in polynomial time. It can therefore be concluded that TRSP belongs
to NP.
Of course the polynomial time algorithm was depending on the oracle ability
to guess. However, when doing non-deterministic computation such an oracle is
always available.
4.3.2 TRSP is NP-complete
The term NP-hard means that the problem is at least, within a polynomial, as
hard as any of the NP-complete problems. To prove a problem X is NP-hard
can be done by providing a polynomial transformation from any NP-complete
problem into an instance of X. The NP-complete problem which in the following
will be transformed into an instance of X, will be denoted Y .
5The z variables are the ones used by the flow constraint
52. 40 Complexity analysis of TRSP
If Y can be transformed into X by a polynomial transformation, then solving X
only requires a polynomial larger effort than solving Y . Recall that a polynomial
transformation specifies two requirements. First, the time complexity of the
transformation must be bounded by a polynomial. Second, the size of the
output problem must only be a polynomial times larger than the input problem.
Since the transformation from Y to X is polynomial, Y can be solved by first
transforming it to an instance of X, and then solving X. To prove that X is
NP-hard, it is therefore sufficient to provide a polynomial transformation from
a known NP-complete problem Y into an instance of X.
4.3.2.1 A polynomial transformation from TSP to TRSP
The transformation is made by exploiting that the Travelling Salesman Problem
is an instance of TRSP. TSP is NP-complete6
.
• Only one technician.
• The technician can handle all jobs.
• Only one day.
• The length of the day is set to infinity.
• αROB = αT T C = αJT T = 0, i.e. only driving is optimized.
The special instance of the TRSP model is stated using the notation from the
MIP-model. Note that the indices i and t are omitted since the problem only
contains one technician working one day. Further, the x variables are omitted
since obviously the only technician handles all jobs.
Min
j k
rjk · yjk
Such that:
j
yjk = 1 ∀ k
k
yjk = 1 ∀ j
k
zkj −
k
zjk = 1 ∀ j {homebase}
6See [6] pp. 453.
53. 4.3 NP completeness 41
zjk ≤ n · yjk ∀ j, k
The above model is recognized as the TSP model. Since the TSP model above
is an instance of the original TRSP it is trivial that there exists a polynomial
transformation. Further, the TRSP solution can be interpret as a solution to
TSP. Therefore TRSP is at least as hard.
Summing the conclusions of the two previous sections, namely that TRSP is NP-
hard and that TRSP is in NP it can be concluded that TRP is NP-complete.
4.3.2.2 TRSP’s relation to Bin packing (BP)
Here another instance of TRSP will be presented, the instance to be presented
is described by the following:
• A planning horizon of one day.
• All technicains have the same homebase
• More technicians than jobs.
• All jobs are located at the home base. I.e all transportation times are set
to zero.
• All technicains have a work day of length 1 hour.
• All technicians are allowed to handle all jobs.
• αDRI = αT T C = αJT T = 0
• Use robustness such that all technicians that do not handle any jobs get
the same objective value. I.e no square root and the length of a standard
job is set to 1.
The instance is presented as a MIP model. Note that the y and z variables are
ommited since these are used to ensure the ON LOCATION constraint which
is trivial satisfied. The t index is omitted.
Max
i
1 −
j
dj · xij
54. 42 Complexity analysis of TRSP
Such that:
i
xij = 1 ∀ j
j
xij · dj ≤ 1 ∀ i
The above model is recognized as the BP since it is equivalent to maximize the
technicians not doing anything and minimizing the ones that are.
4.3.3 Real life instances of TRSP
It seems pretty obvious that even though both TSP and BP are components of
TRSP, neither of them are the instances real life planning problems will give rise
to. This section aims to analyze real life instances of TRSP and thereby extend
the understanding of TRSP, since the understanding is crucial when designing
algorithms.
A constraint which was not used in neither TSP nor BP was the ALLOWED
constraint. The ALLOWED constraint can disallow a technician to handle a
job. If the A matrix is sparse, each job can only be handled by few technicians
on certain days. Therefore the ALLOWED constraint can significant reduce the
number of feasible solutions in the TRSP.
From the case interviews it seemed fair to assume, that no technician can handle
more than a few jobs on a single day due to the WORKLOAD constraint, i.e
the number of jobs handled by one technician on one day will not scale with the
problem size. Recall that the TSP was the instance of TRSP where one techni-
cian handled all jobs. Clearly each technician has to drive a Hamiltonian cycle
each day, i.e solve a TSP. However, these tours might be quite small. Designing
a very good heuristic for a general TSP might not be necessary. Instead one
should focus on developing fast algorithms for small instances of TSP. Further,
the WORKLOAD constraint could, like the ALLOWED constraint, reduce the
number of feasible solutions significant. This should be exploited in a good
TRSP algorithm.
BP seemed to have some relation with TRSP. There exists a quite good approx-
imation algorithm for BP namely the First Fit Decreasing algorithm7
denoted
FFD. The algorithm sorts the elements/jobs by size in increasing order and
then it assigns the jobs to the first bin where these fit. This algorithm has
a runtime of O(n · lg(n)) and a proven bound of 11/9·OPT + 6/9·bin, where
7[1] pp. 1-11
55. 4.3 NP completeness 43
OPT is the optimal solution. However, for several reasons this is not a sensible
approach to TRSP. First, the TRSP approach also needs to consider driving
time. In a BP framework this would mean, that each job has a different size
depending on which other jobs the technician needs to handle that day. E.g.
if more than one job is located at the same costumer, no driving needs to be
done, whereas if a technician is handling jobs in North Zealand it would require
a lot of time to handle a job on Funen even though the job it self could be only
one minute. Second, the FFD algorithm would provide solutions where some
technicians handle many small jobs and therefore needs to do a lot of driving
and others would only handle larger jobs and do significantly less driving. None
of the interviewed companies seemed interested in such a solution. Last but not
least, BP only considers the robustness soft constraint, therefore it would be
difficult to re-design any BP algorithm to be as general as the system seems to
require.
Finally, the insights from this analysis is summed up. TRSP is both a packing
and a routing problem. It seems, that no TSP or BP algorithm will be a
sensible approach. However, one could, in the design phase of an algorithm,
draw benefits by exploiting the WORKLOAD and the ALLOWED constraint
since these seem to significant reduce the feasible solution space. For these
reasons, TRSP seems to have similarities with the Vehicle Routing Problem
(VRP) with capacity constraint, from which one therefore could get inspiration
to the design of an TRSP algorithm.
57. Chapter 5
Metaheuristic concepts
Metaheuristics are optimization methods for solving computationally hard prob-
lems. Metaheuristics are used when wellknown standard solvers like the ILOG
CPlex solver cannot solve the problem at hand. This can happen if the in-
stance of the problem is either very large and or very complex. In [11] pp. 17 a
metaheuristic is defined as follows:
A meta-heuristic refers to a master strategy that guides and modifies
other heuristics to produce solutions beyond those that are normally
generated in a quest for local optimality. The heuristics guided by
such a meta-strategy may be high level procedures or may embody
nothing more than a description of available moves for transforming
one solution into another, together with an associated evaluation
rule.
If a meta-heuristic according to the definition is ”... a master strategy that guides
and modifies other heuristics...”, then one needs to know what a heuristic is.
According to [16] pp. 6, a heuristic is defined in the following way:
A heuristic is a technique which seeks good (i.e. near-optimal) solu-
tions at a reasonable computation cost without being able to guar-
58. 46 Metaheuristic concepts
antee either feasibility or optimality, or even in many cases to state
how close to optimality a particular feasible solution is.
This section will contain a survery of concepts used when designing metaheuris-
tics. None of the algorithms will be presented fully, since the aim is not to
describe algorithms but to scan through the most popular theory searching for
concepts which might be useful for solving TRSP.
5.1 Hill climbing
Local search, or Neighborhood search, is the most used discrete optimization
strategy. The idea is to move iteratively from neighbor solution to neighbor
solution searching for good solutions. In an abstract sense a neighbor solution
can be an arbitrary solution, however usually a neighbor solution is defined as
one where only a few decision varibles are changed. This is done in order to
speed up the search.
The simplest of all local search algorithms is the Hill climber. The idea is to
evaluate the objective function in a number of neighbor solutions and move to
the best one. The Hill climber only moves if the move is an improving move.
5.1.1 Pros & Cons
The main advantage when using the hill climbing algorithm is to be found in its
simplicity which results in it being able to iterate very fast compared to other
search heuristics.
A disadvantage in when using the hill climbing algorithm is that it easily gets
stuck in local maxima, e.g. see figure 5.1 where the concepts of local and global
maxima are shown.
Most real life as well as theoretical combinatorial optimization problems have
linear objectives functions. This could lead to the conclusion that the Hill
climbing would guarantee global optimum which is false. It is true that the
objective function is a linear function of the decision variables, so if one changes
the value of one decision variable the objective value would change proportional.
However, Hill climbing is a neighbor search algorithm, so it moves from neighbor
solution to neighbor solution. These neighbor moves usually results in changes
59. 5.2 Simulated annealing 47
to the solution that are larger than just the adjustment of a single decision
variable.
Most widely the value on the x-axis is interpreted as the value of a decision value.
A better interpretation of the x-axis in figure 5.1, when doing local search, is to
let the value of the axis be different neighbor solutions.
It is possible to extend the neighborhood, i.e. the set of neighbor solutions, so
one can guarantee that the Hill climber will find global optimum. Unfortunately,
the neighborhood needs to be extended so it´s exponential big and therefore it
ruins the idea of getting fast solutions.
Figure 5.1: This figure is illustrating the concept of having more than one local
optimum. The green stars are illustrating where Hill climbing would get stuck
when maximizing the objective function, and the red stars are illustrating where
Hill climbing would get stuck when minimizing the objective function.
Since the problem with Hill climbing is that it often gets stuck in a local opti-
mum, the focus will be on search algorithms being able to avoid local optima.
5.2 Simulated annealing
The name and inspiration behind simulated annealing originate from metallurgy,
a technique involving heating and controlled cooling of a material to increase
size of its crystals and reduce their defects. First, heat causes atoms to become
unstuck from their initial positions (a local minimum of the internal energy)
and wander randomly through states of higher energy; then second, carefully
decreasing gives the atoms more chances of finding configurations with lower
internal energy than the initial one. [10] pp. 187. Simulated annealing is capable
60. 48 Metaheuristic concepts
of avoiding local optima by implementing the mentioned annealing process.
Simulated annealing is a neighbor search algorithm. In each iteration only one
neighbor solution is evaluated and then the move is either accepted or rejected.
If the move is an improving move it is always accepted, and if the move is non-
improving it is accepted with some probability. The probability with which non-
improving moves are accepted is calculated from a decreasing cooling function.
Therefore in the first iterations almost all moves are accepted and later on
almost all non-improving moves are rejected. Further, many implementations
also consider the magnitude of the change in the objective value when deciding
whether a non-improving move is accepted or not.
5.2.1 Pros & Cons
Advantages when using Simulated annealing are its simplicity and its ability
in preventing local optima. Simulated annealing can often provide high-quality
solutions, where no tailored algorithms are available [10] pp. 204. Further, it
is proven that Simulated anneling converges towards the optimal solution as
time goes to infinity [22]. Unfortunatly, no practical problem allows the use of
infinity time, so this property is only of theoretical interest.
The main disadvantage when using Simulated annealing is first and foremost
the computation time needed to obtain high-quality solutions. This is a con-
sequence of the lack of prioritization of neighbor solutions, since only one is
evaluated. Furthermore, it is often difficult to guess a good cooling scheme. If
the temperature is too high; Simulated annealing behaves as Random search,
and if the tempature is to low, Simulated annealing will behave as Hill climb-
ing. In most cases the cooling function needs to fit the specific problem and
especially the objective function.
5.3 Genetic algorithms
Genetic algorithms is the best known type of evolutionary algorithms. An evo-
lutionary algorithm is a generic population-based metaheuristic optimization
algorithm. These algorithms are inspired by biological evolution: reproduction,
mutation, recombination and selection. The typical structure, described in [10]
pp. 98, of how to implement a Genetic algorithm is:
1. Generate initial population.
61. 5.4 Tabu search 49
2. Evaluate candidate solutions.
3. Select two ore more candidate solutions with high value.
4. Crossover items in the chosen solutions into a new solution.
5. Mutate parent solutions.
6. Replace parents in the population.
Where steps 2-6 are repeated until a termination condition is satisfied.
5.3.1 Pros & Cons
The main advantage when using Genetic algorithms is that is effective when
having multiple objectives.
The disadvantages when using Genetic algorithms are that even though the
concepts are intuitive, there exists no easy way to choose god genes from a
solution, choose how to merge good genes to one solution and how to rebuild
the part of the solution which is not explicitly given from the good genes. If one
cannot find efficient strategies to answer these questions Genetic algorithms can
be impossible to use.
5.4 Tabu search
Tabu search is a local search algorithm just like the Hill climbing. Tabu search
is however able to overcome local optima by allowing non-improving moves and
by using memory.
In each iteration an entity of the solution is declared tabu and this entity can
therefore not be used as basis for a possible move. If Tabu search is caught in a
local optimum it will perform a non-improving move, which will not be undone
since a part of this move is now tabu. Tabu search will hopefully be able to
escape the local optima by doing these non-improving moves until it is away
from the local optimum.
62. 50 Metaheuristic concepts
5.4.1 Pros & Cons
The advantage of using Tabu Search are first of all the ability of finding good so-
lutions using only a small amount of computational effort. Second, Tabu search
has a history of providing state of the art solutions to difficult problems such
as the Vehicle Routing Problem. Finally, the Tabu search framework contains
many tuning possibilities which gives rise to good solutions to specific problems.
A disadvantage when using Tabu Search is that it can be difficult to choose
a good neighborhood. If a too large neighborhood is chosen, it will result in
a large amount of solution evaluations in each iteration and Tabu search will
therefore move slowly from solution to solution. This results in poor perfor-
mance. Further, Tabu search has an enourmous number of parameters, which
need to be set and furthermore these can interact on each other. This results in
Tabu search requiring long time to implement since lots of testing is necessary.
5.5 Semi-greedy construction heuristics
Constuction algorithms is a heuristic concept which is very different from local
search. Whereas search algorithms iteratively improves a solution, a construc-
tion algorithm will build a solution from scratch. Semi-greedy construction
heuristics are building the solutions by being greedy. Introducing a bit of ran-
domness into the greedy choice makes it possible to use to algorithm iteratively.
5.5.1 Pros and cons
Construction algortihms are very easy to implement, since it is usually only a
few parameters that need to be specified. If the problem which is being solved
is not very complex, then good greedy solutions can be obtained and therefore
semi-greedy construction algorithm is a natural choice in this scenario. Another
advantage is that a parallel implemention is trivial.
A disadvantage when using a construction scheme seems to be the lack of vari-
ance in the obtained solutions. The effectiveness of greedy construction algo-
rithms will decrease of the complexity of the problems increase.
63. 5.6 Choosing a metaheuristic for TRSP 51
5.6 Choosing a metaheuristic for TRSP
This thesis aims at developing a metaheuristic. A metaheuristic is the product
of a series heuristics as explained in the first paragraph. This section is a
discussion of concepts which are going to be included in the heuristic proposed
in this thesis.
Section 1.1 described Microsofts interest in being able to provide their clients
with emergency handling of new arriving jobs. The running time of the meta-
heuristic to be chosen is therefore a very important factor when choosing among
the introduced heuristic concepts. Further, one cannot be certain which soft
constraints the clients will find useful and so very little information about the
objective function is available. Both of these arguments are strong disadvantages
when using Simulated annealing, and therefore this heuristic is discarded.
TRSP have many similarities wiht VRP as stated in section 4.3.3. Tabu search
has a history of provided state of the art solutions to VRP, and so it seems quite
intuitive to investigate Tabu search further. Tabu seach is the best metaheuristic
at finding good solutions fast since it is initially quite simular to hill climbing.
This is important since emergency planning was one of the requirements stated
in the case study.
A main difference between TRSP and VRP are the ease at which feasible solu-
tion are obtained. VRP can obtain a feasible solution by simple sending each
costumer a separate vehicle. This is not the case for TRSP since one does
not necessarily posses enough service technicians to do this. A construction
algorithm is therefore needed.
T-Cluster and T-Sweep are examples of construction heuristics for VRP. As
explained in [18] pp. 897 both of these algorithms are greedy algorithm which
assigns costumers to vehicles after their geographical position. The ALLOWED
constraint can, if the A matrix is sparse, make both of these construction algo-
rithm diffucult to use. If the A matrix is sparse it is more important to find a
service technicain who can handle critical jobs than obtain a plan where jobs
are assigned by their geographical position.
A greedy construction approach is chosen, since it seems that there is no tailored
algorithm for obtaining feasible solutions to TRSP. The semi-greedy construc-
tion concept is used as the basis of this algorithm. The proposed construction
algorithm will not make use of iterative constructions. The algorithm is how-
ever still going to use non-determinism. This is the case since, if a deterministic
construction fail to find a feasible solution, then randomness can be used as a
way of searching for less greedy solutions.
64. 52 Metaheuristic concepts
Tabu search has been chosen since it is considered the natural choice, when
solving vehicle routing problems. The TRSP is however not only a routing
problem, and so this fact has to be taken into consideration. Genetic algorithms
seems to be a good way of dealing with multiple objectives. Genetic algorithms
are however difficult to use if it is difficult to distinguish good genes from bad
ones. Recall that TRSP is solved by creating deciding a set of assignments.
These assignments can be categorized by technician and day. A gene could be
defined as such a category of assignments. Further, a construction heuristic for
TRSP needs to be desingned any therefore the problem of re-obtaining a feasible
solution is not considered a problem.
The hill climbing algorithm will probably not be very effective on TRSP, since
it will get stuck at local optima. The algorithm is however very fast to imple-
ment so it would be unwise to develop a toolbox for TRSP and not include the
Hill climber. The reason for this is that it could be used to improve solutions
provided by the other heuristics. Another reason for using the Hill climber is
that the planning tool would appear useless if a dispatcher could easily find
improvements to a solutions returned by the solver. The Hill climber can be
used to eliminate these easy improvements.
The conclusion is that Tabu search is chosen as the fundamental optimization
algorithm used in the meta heuristic. Tabu search is therefore going to be
investigated in more detail in the following chapter. Initial solutions will be
obtained using a semi-greedy heuristic. For final improvements, elite solutions
obtained by Tabu search will be merged using ideas borrowed from the Genetic
algorithm framework.
65. Chapter 6
Introduction to Tabu search
In this section the most basic concepts of the Tabu search heuristic will be
explained. The section will only deal with basic knowledge and concepts con-
sidering the Tabu search heuristic. This will hopefully make the reader of this
section capable of understanding chapter 8 considering the implemented Tabu
search heuristic dealing with TRSP. A pseudocode of the basic algorithm can
be found in appendix B on page 157.
6.1 Background
In 1986 Fred Glover proposed an approach which he called Tabu search. The
idea was an local search algorithm which could overcome local optima. In fact
many elements of the Tabu search algorithm was already introduced in 1977 by
Glover i.e. short term memory and longer term memory. The basic principle of
Tabu search is to allow non-improvable moves in the local search algorithm.
